RAG'ın Ötesi: Context Engineering ve Derleme Aşamasında Bilgi Katmanı

TL;DR — RAG öldü demiyorum; ama sahada gördüğüm kadarıyla düz vektör RAG'in altın çağı kapandı. Bugün kurumsal projelerde işi kurtaran şey, modeli daha büyük seçmek değil; bilgiyi doğru katmanda inşa etmek. Bu yazıda, düz vektör RAG'den agentic RAG'e, oradan da "context engineering" ve derleme aşamasında hazırlanan bilgi katmanına (compilation-stage knowledge layer) uzanan evrimi anlatıyorum. Ana tezim şu: 2026'da öne çıkan kurumlar, akıl yürütmeyi sorgu anından derleme anına taşıyor; yani model sizin sorunuzu beklemeden önce bilgi zaten yorumlanmış, yapılandırılmış ve yönetişimle sarmalanmış halde hazır bekliyor. KVKK ve EU AI Act tarafında ise bu, "ne veriyi hangi katmana koyduğunuz" sorusunu teknik değil, hukuki bir mesele haline getiriyor.

Danışmanlık yaptığım şirketlerin çoğunda ilk RAG projesi hep aynı hikâyeyle başlıyor. Birileri bir hafta sonu bir vektör veritabanı ayağa kaldırıyor, dökümanları parçalıyor (chunk), embedding çıkarıyor, bir de sohbet arayüzü ekliyor. İlk demo herkesi büyülüyor. Sonra o sistem gerçek kullanıcılarla, gerçek sorularla, gerçek dökümanlarla karşılaşıyor ve iş çığırından çıkıyor.

Neden? Çünkü baştan RAG'i basit bir fonksiyon gibi düşündük: "Soru gir, ilgili parçaları getir, modele ver, cevap al." Oysa retrieval (getirme) hiçbir zaman deterministik, tek adımlı bir fonksiyon olmadı. Sahada gördüğüm en yaygın yanılgı budur ve neredeyse her başarısız projenin kökeninde yatar.

Size somut bir örnek vereyim. Bir üretim şirketinde bakım ekipleri için bir asistan kurduk. Kullanıcı "3 numaralı hattaki pompanın basınç düşüşü nasıl giderilir?" diye sorduğunda, düz vektör RAG "basınç" ve "pompa" kelimelerine semantik olarak yakın parçaları getiriyordu. Ama doğru cevap, bir arıza kayıt tablosunda, bir de PLC log dosyasındaydı; ikisi de serbest metin embedding'iyle yakalanamayacak yapıda. Sistem kendinden emin, akıcı ve yanlış cevaplar üretiyordu. İşte bu "confident but unreliable" (kendinden emin ama güvenilmez) davranış, kurumsal RAG'in en tehlikeli hastalığıdır.

Yıllar içinde onlarca projede aynı üç duvara tosladık. Bunları net biçimde ortaya koymak istiyorum, çünkü çözümün mantığı bu sınırları anlamaktan geçiyor.

1. Sabit boru hattı (fixed pipeline) esnek değildir. Geleneksel RAG'de akış her zaman aynıdır: embed → search → rerank → generate. Ama gerçek sorular türlü türlüdür. Kimi soru tek bir olgu ister, kimi soru karşılaştırma, kimi soru zaman içindeki değişimi, kimi soru bir hesaplama. Tek tip boru hattı, tek tip olmayan sorulara tek tip yanlışla karşılık verir.

2. Semantik benzerlik, doğruluk değildir. Vektör benzerliği, "anlamca yakın" demektir; "doğru kaynak" demek değildir. İki paragraf birbirine anlamca çok benzeyip biri güncel, diğeri iki yıl önce iptal edilmiş bir prosedür olabilir. Benzerlik skoru bunu ayırt etmez.

3. Yönetişimsiz vektör deposu bir kara kutudur. Düz bir vektör deposuna her şeyi doldurduğunuzda, hangi verinin nereden geldiğini, kimin erişebileceğini, ne zaman güncellendiğini izleyemezsiniz. Bu, KVKK açısından tam bir mayın tarlasıdır; birazdan detaylandıracağım.

İşte bu üç sınıra ilk ciddi yanıt agentic RAG oldu. Fikir basit ama dönüştürücü: Retrieval'ı sabit bir boru hattı olmaktan çıkarıp, ajana karar verme özerkliği veriyorsunuz. Ajan artık şu soruları kendisi cevaplıyor:

• Hangi araçla getireyim? Anahtar kelime araması mı, semantik arama mı, bir API çağrısı mı, yoksa doğrudan bir SQL sorgusu mu? Basınç sorusunda ajan, serbest metin yerine arıza tablosuna SQL atmayı seçebilmeli.
• Ne zaman getireyim? Bazı sorular hiç retrieval gerektirmez (model zaten bilir), bazıları birden fazla tur gerektirir. Ajan bunu ayırt etmeli.
• Getirdiğim yeterli mi? Ajan, gelen sonuçlara bakıp "bu yetersiz, bir de şu kaynağa bakayım" diyebilmeli. Buna genelde reflection (öz-değerlendirme) diyoruz.

Sahada agentic RAG'e geçişin getirdiği fark çok net: sistem artık tek atışlık değil, iteratif. Yukarıdaki bakım asistanını agentic mimariye taşıdığımızda, ajan önce semantik aramayla bağlamı çıkarıyor, sonra tespit ettiği ekipman kodunu bir SQL sorgusuyla arıza tablosunda doğruluyor, gerekirse PLC log API'sini çağırıyor. Doğruluk oranı, benim ölçtüğüm senaryolarda çarpıcı biçimde yükseldi.

Ama dürüst olmak gerekirse, agentic RAG bir sihirli değnek değil. Getirdiği bedeller var:

Boyut	Düz Vektör RAG	Agentic RAG
Esneklik	Düşük (sabit akış)	Yüksek (dinamik karar)
Gecikme (latency)	Düşük, öngörülebilir	Yüksek, değişken
Maliyet	Düşük	Yüksek (çok turlu çağrı)
Hata ayıklama	Kolay	Zor (karar zinciri uzun)
Doğruluk potansiyeli	Sınırlı	Yüksek (kaynak seçebilir)

Bu tablo, danışmanlıkta müşterilerime en çok gösterdiğim şeydir. Çünkü ajana özerklik vermek, aynı zamanda öngörülemezlik ve maliyet demektir. Her sorunun her seferinde tam agentic akışa girmesi gerekmez; bazen basit bir soruya beş araç çağrısı yapan bir sistem, hem yavaş hem pahalı hem de gereksizdir.

Agentic RAG kararı iyileştirdi ama bir başka sorun ortada duruyordu: düz vektör deposu, bilgi arasındaki ilişkileri kaybediyor. "Bu tedarikçi hangi parçaları sağlıyor, o parçalar hangi ürünlerde kullanılıyor, o ürünler hangi müşterilere gitti?" gibi çok adımlı ilişkisel sorular, embedding benzerliğiyle çözülmez.

Buradan graph-augmented (graf destekli) mimariler doğdu. Bilgi grafiği (knowledge graph), varlıkları (entity) ve aralarındaki ilişkileri açık biçimde modeller. Retrieval artık sadece "benzer metin" değil, "ilişkili düğümler" üzerinden de yürüyebilir. Sahada gördüğüm en güçlü kurumsal RAG sistemleri, vektör aramasını graf yürüyüşüyle (graph traversal) harmanlayan hibrit sistemlerdi. Vektör "hangi konu" sorusunu, graf "hangi ilişki" sorusunu cevaplıyor.

Türkiye'deki bir enerji şirketinde, saha ekipmanları arasındaki bağımlılıkları bir grafta modelledikten sonra, "şu trafo arızalanırsa hangi fiderler etkilenir" gibi soruları saniyeler içinde ve izlenebilir biçimde cevaplayabilir hale geldik. Düz vektörle bu asla mümkün olmazdı, çünkü cevap tek bir dökümanda değil, ilişkiler ağındaydı.

Şimdi işin kalbine geliyorum. Son bir yılda sektörde en çok olgunlaşan kavram "context engineering" oldu ve bunu bir moda terim olarak görmemenizi rica ediyorum. Context engineering, modele gönderilen bağlamı bir mühendislik disiplini gibi tasarlamak demektir. Prompt yazmaktan çok daha geniş bir şey.

Context engineering'in kapsamı şudur:

1. Ne getirilecek? Doğru kaynaklardan doğru parçalar.
2. Nasıl parçalanacak? Chunking stratejisi; anlam bütünlüğünü koruyan, ne çok küçük ne çok büyük parçalar.
3. Nasıl sıralanacak ve budanacak? Bağlam penceresi sınırlı; en alakalı bilgiyi en verimli biçimde yerleştirmek.
4. Nasıl yapılandırılacak? Modele ham metin yığını değil, yapılandırılmış, etiketlenmiş, kaynağı belli bir bağlam vermek.
5. Nasıl yönetilecek? Erişim kontrolü, kaynak kalitesi, güncellik, denetlenebilirlik.

Dikkat edin: Bu maddelerin çoğu, model çalışırken değil, öncesinde halledilmesi gereken işler. İşte bu gözlem, beni ve sektörü bir sonraki büyük fikre götürdü.

Geleneksel RAG'de akıl yürütmenin büyük kısmı sorgu anında (query time) olur. Kullanıcı sorduğu anda sistem koşturur, getirir, yorumlar, yapılandırır ve cevaplar. Bu, her sorguda aynı yorumlama işini baştan yapmak demektir. Hem yavaş, hem pahalı, hem de tutarsız.

Yükselen fikir şu (bazı ekipler buna "Nexus" benzeri bir yaklaşımla atıfta bulunuyor): Bilgiyi yorumlama ve yapılandırma işini sorgu anından derleme anına (compilation time) taşıyın. Yani herhangi bir ajan sorusu gelmeden önce, ham bilgi kaynağını alıp yorumlayan, ilişkilerini çıkaran, çelişkilerini temizleyen, varlıklarını normalize eden ve önceden yapılandırılmış bir bilgi katmanı (knowledge layer) inşa eden bir "derleme" aşaması çalıştırın.

Yazılım dünyasından bir benzetmeyle anlatayım, çünkü bu benzetme müşterilerimde şimşek çakması etkisi yaratıyor: Yorumlanan (interpreted) dil ile derlenen (compiled) dil arasındaki fark gibi. Düz RAG, her sorguyu yeniden yorumlayan bir yorumlayıcıdır. Bilgi katmanı yaklaşımı ise bilgiyi önceden derleyip optimize eden bir derleyicidir. Ajan artık her seferinde sıfırdan akıl yürütmez; önceden derlenmiş, temizlenmiş, ilişkilendirilmiş bir bilgi zeminine oturur.

Bu neyi değiştirir?

• Tutarlılık: Yorumlama bir kez, merkezi olarak yapıldığı için her sorgu aynı temiz zemine oturur.
• Hız: Sorgu anında yapılacak iş azalır; ağır yorumlama derleme anında bitmiştir.
• Yönetişim: Bilgi katmanı tek bir denetlenebilir varlık haline gelir; neyin girdiğini, kimin eriştiğini, ne zaman güncellendiğini merkezi olarak yönetirsiniz.
• Kalite kontrolü: Çelişkiler, güncelliğini yitirmiş kayıtlar, yinelenen bilgiler derleme aşamasında yakalanır; sorgu anında kullanıcının önüne çöp çıkmaz.

Sahadaki en net gözlemimi paylaşayım. 2025'te herkes "hangi model?" diye sordu. GPT mi, Claude mi, açık kaynak mı, kaç milyar parametre? 2026'da başarılı olan kurumlarda gördüğüm şey ise tam bir zihniyet değişimi: Onlar birincil yatırımı modele değil, bilgi kaynağına yapıyor.

Bunun mantığı çok sağlam. Modeller hızla metalaşıyor (commoditize); bugün öncü olan model, altı ay sonra ortalama oluyor ve fiyatı düşüyor. Ama sizin kurumsal bilginiz, temizlenmiş, yapılandırılmış, ilişkilendirilmiş ve yönetişimle sarmalanmış bilgi katmanınız, sizin gerçek rekabet avantajınız. Modeli değiştirebilirsiniz; bilgi katmanınız kalır ve zamanla değer kazanır.

Bu yüzden danışmanlıkta artık şu cümleyi kuruyorum: Modeli kiralayın, bilgi katmanına sahip olun. Bütçenizin büyük kısmı, veri kalitesine, kaynak yönetimine, bilgi grafiği ve derleme boru hattına gitmeli; en son çıkan modelin peşinde koşmaya değil.

Yıllar içinde biriktirdiğim, neredeyse her başarısız projede tekrar eden tuzakları sıralayayım. Bunları bir kontrol listesi gibi kullanmanızı öneririm.

Tuzak 1 — Retrieval'ı basit bir fonksiyon sanmak. Zaten yazının başında değindim ama tekrar vurgulamaya değer. Retrieval, dinamik karar gerektiren bir süreçtir; tek adımlı bir "getir" çağrısı değil.

Tuzak 2 — Yönetişimsiz düz vektör deposu. Her şeyi tek bir vektör deposuna doldurup erişim kontrolü, kaynak etiketi ve güncellik takibi koymamak. Bu, hem güvenlik hem uyum açısından felakete davetiye.

Tuzak 3 — Kaynak kalitesini görmezden gelmek. "Garbage in, garbage out" burada acımasız işler. Kötü, çelişkili, güncelliğini yitirmiş bir kaynaktan beslenen sistem, kendinden emin biçimde yanlış cevap verir; ki bu, hiç cevap vermemekten daha tehlikelidir.

Tuzak 4 — Değerlendirme (evaluation) olmadan üretime geçmek. Retrieval kalitesini ölçen bir değerlendirme setiniz yoksa, sistemin iyileşip iyileşmediğini bilemezsiniz. Ben her projede önce bir "altın soru-cevap" seti kuruyorum.

Tuzak 5 — İzlenebilirlik eksikliği. Sistem bir cevap verdiğinde "bunu hangi kaynaktan çıkardın?" sorusuna cevap veremiyorsa, o sistemi kurumsal ortamda savunamazsınız.

Şimdi, teknik heyecanın en çok gölgede bıraktığı ama benim danışmanlıkta en çok üzerinde durduğum konuya geliyorum: veri yönetişimi ve KVKK. Bilgi katmanı fikri kulağa ne kadar zarif gelse de, o katmana neyi koyduğunuz sizi doğrudan hukuki sorumluluk altına sokar.

Bir bilgi katmanı inşa ederken kendinize sormanız gereken sorular şunlar:

• Bu katmana kişisel veri giriyor mu? Müşteri kayıtları, çalışan bilgileri, sağlık verisi gibi özel nitelikli veriler bir vektör deposuna veya bilgi grafiğine girdiğinde, KVKK'nın işleme, saklama ve aydınlatma yükümlülükleri tetiklenir. Embedding'e dönüşmüş olması veriyi "anonim" yapmaz; çoğu durumda geri döndürülebilir ya da kişiyi belirlenebilir kılar.
• Erişim kontrolü var mı? Bilgi katmanına kim, hangi rolle erişebilir? Bir çalışanın erişemeyeceği bir belgenin içeriği, RAG üzerinden dolaylı olarak sızıyorsa, erişim ihlali yaşıyorsunuz demektir. Erişim kontrolünü chunk ve kaynak seviyesinde tasarlamalısınız.
• Denetlenebilirlik (auditability) sağlanıyor mu? Hangi veri ne zaman katmana girdi, kim erişti, hangi cevapta kullanıldı? KVKK bir veri sahibi başvurusu geldiğinde, o kişinin verisinin nerede, nasıl işlendiğini gösterebilmeniz gerekir. İzlenemeyen bir vektör deposu bu talebi karşılayamaz.
• Silme ve güncelleme hakkı işletilebiliyor mu? Bir kişi verisinin silinmesini talep ettiğinde, o veriyi hem kaynaktan hem de türetilmiş embedding'lerden ve bilgi grafiğinden çıkarabilmelisiniz. Derleme aşamalı bilgi katmanı burada aslında avantaj sağlar: kaynağı düzeltip yeniden derlediğinizde, türetilmiş katman da temizlenir.

Burada derleme aşamalı bilgi katmanının gizli bir üstünlüğü var. Yönetişimi merkezi bir noktada uyguladığınız için, KVKK yükümlülüklerini tek tek dağınık vektörlerde kovalamak yerine, tek bir derleme boru hattında uygulayabilirsiniz. Kaynak kalite kontrolü, kişisel veri maskeleme, erişim etiketleme, hepsi derleme anında yapılır. Bu, hem teknik hem hukuki açıdan çok daha savunulabilir bir mimaridir.

EU AI Act ile birlikte, yüksek riskli kullanım alanlarında (işe alım, kredi, sağlık, kamu hizmetleri gibi) yapay zeka sistemlerinden şeffaflık, izlenebilirlik ve insan gözetimi bekleniyor. Türkiye'deki ihracatçı ve Avrupa pazarına dokunan şirketler için bu, uzak bir konu değil; müşterileri Avrupa'da olan her kurum bu çerçeveyle er geç muhatap olacak.

İşte bu noktada iyi tasarlanmış bir bilgi katmanı, bir yük değil, bir uyum aracıdır. Çünkü:

• Cevabın hangi kaynaktan çıktığını gösterebilirseniz, açıklanabilirlik yükümlülüğünü karşılarsınız.
• Bilgi katmanının neyi içerdiği denetlenebilirse, veri yönetişimi yükümlülüğünü karşılarsınız.
• İnsan operatör, sistemin dayandığı kaynakları görüp müdahale edebiliyorsa, insan gözetimi yükümlülüğünü karşılarsınız.

Yani bilgi katmanına yaptığınız yatırım, aynı zamanda düzenleyici uyumluluğa yaptığınız yatırımdır. Bunu müşterilerime hep şöyle özetliyorum: İyi mühendislik ile iyi uyum, burada aynı yöne bakıyor.

Teoriyi bırakıp sahaya inelim. Bir kurumda bilgi katmanı kurarken izlediğim adımları paylaşıyorum. Bunu bir reçete değil, bir çerçeve olarak alın; her kurumun bağlamı farklı.

1. Kaynakları envanterleyin ve sınıflandırın. Hangi bilgi nerede? Hangi kaynak güncel, hangisi güvenilir, hangisi kişisel veri içeriyor? Bu envanter olmadan hiçbir şey başlamaz.
2. Kaynak kalitesini kapıda denetleyin. Çelişkili, güncelliğini yitirmiş, düşük kaliteli kaynakları katmana sokmadan ayıklayın. Kalite kontrolü sonradan değil, girişte yapılır.
3. Varlıkları ve ilişkileri modelleyin. İlişkisel sorular bekliyorsanız, bir bilgi grafiği katmanı kurun. Sadece "hangi konu" değil, "hangi ilişki" sorularını da düşünün.
4. Derleme boru hattını kurun. Yorumlama, normalizasyon, çelişki temizliği, kişisel veri maskeleme ve etiketlemeyi bu boru hattında merkezileştirin.
5. Erişim kontrolünü katmana gömün. Chunk ve kaynak seviyesinde roller tanımlayın; retrieval bu rollere saygı göstersin.
6. Retrieval'ı agentic yapın ama ölçülü. Ajana araç seçme özerkliği verin, ama her soruyu tam agentic akışa sokmayın; basit sorulara hızlı yol bırakın.
7. Değerlendirme setiyle sürekli ölçün. Altın soru-cevap setiyle retrieval ve cevap kalitesini düzenli ölçün; regresyonları erken yakalayın.
8. İzlenebilirliği baştan tasarlayın. Her cevap, dayandığı kaynağı gösterebilmeli. Bunu sonradan eklemek çok pahalıdır; baştan mimariye koyun.

Bu sekiz adımın en kritik olanı, bana sorarsanız, ikinci ve sekizinci: kaynak kalitesini kapıda denetlemek ve izlenebilirliği baştan koymak. Çünkü bir RAG sistemini üretimde çökerten şey neredeyse hiçbir zaman model değildir; kirli kaynak ve izlenemeyen cevaplardır.

Bütün bu evrimi tek bir cümlede toplamak istersem: RAG, bir "arama özelliği" olmaktan çıkıp bir "kurumsal bilgi altyapısına" dönüşüyor. Düz vektör RAG bir başlangıçtı; agentic RAG karar zekâsı ekledi; graph-augmented mimariler ilişkileri geri getirdi; context engineering bağlamı bir disipline dönüştürdü; ve derleme aşamalı bilgi katmanı, akıl yürütmeyi sorgu anından çıkarıp önceden inşa edilmiş, yönetilen, denetlenebilir bir varlığa taşıdı.

Size son bir tavsiyem var, sahadan damıtılmış. Bir sonraki RAG projenizde ilk sorunuz "hangi model?" olmasın. İlk sorunuz şu olsun: "Bilgimiz temiz mi, yapılandırılmış mı, yönetiliyor mu?" Bu soruya dürüstçe "evet" diyebildiğiniz gün, hangi modeli kullandığınızın önemi kalmayacak. Çünkü asıl değer, hiçbir zaman modelde değildi; bilgi katmanınızın kalitesinde ve o katmanı ne kadar iyi yönettiğinizde. 2026'da kazanan kurumlar, bunu erken anlayanlar oluyor; ve ben, sahada bu farkı her gün daha net görüyorum.

Bilgi katmanı tartışmasının içinde çoğu kişinin hafife aldığı bir konu var: parçalama, yani chunking. İtiraf edeyim, kariyerimde en çok zaman kaybettiren, en çok "neden çalışmıyor bu sistem" dedirten konu neredeyse hep chunking oldu. Kulağa mekanik bir detay gibi gelir ama sonuçları doğrudan cevabın kalitesini belirler.

Sorun şu: Bir dökümanı nasıl parçalarsanız, retrieval'ın neyi görebileceğini de o belirler. Çok küçük parçalarsanız, bağlam kopar; bir cümle kendi başına anlamsız kalır. Çok büyük parçalarsanız, alakasız bilgi de beraberinde gelir ve bağlam penceresini boşa harcar, hatta modeli yanıltır. Sahada gördüğüm klasik hata, dökümanları sabit karakter sayısına göre kör kesmektir; bir tabloyu ortasından, bir prosedürü adımının yarısından bölersiniz ve sistem asla toparlayamaz.

Benim uyguladığım yaklaşım, yapıya duyarlı (structure-aware) parçalamadır. Bir sözleşmeyi maddelerine, bir teknik kılavuzu bölümlerine, bir tabloyu satır bütünlüğünü koruyarak parçalarım. Anlam birimini korumak, karakter sayısını korumaktan her zaman önce gelir. Derleme aşamalı bilgi katmanının güzelliği tam da burada: parçalama stratejisini merkezi olarak, bir kez, doğru biçimde tasarlar ve tüm sisteme uygularsınız. Her sorguda yeniden parçalama derdi olmaz.

Bir başka az konuşulan ama kritik konu, yeniden sıralama (reranking) ve budamadır (pruning). Retrieval size on parça getirebilir ama modele hepsini vermek çoğu zaman yanlıştır. Bağlam penceresi sınırlı bir kaynaktır ve onu israf etmek, hem maliyeti artırır hem de "lost in the middle" denilen olguyla modelin ortadaki bilgiyi gözden kaçırmasına yol açar.

Sahada şunu öğrendim: Az ama doğru bağlam, çok ama gürültülü bağlamdan her zaman iyidir. Bir reranker modeliyle gelen parçaları alaka düzeyine göre yeniden sıralar, sonra en tepedeki birkaçını seçerim. Geri kalanı, modelin dikkatini dağıtmaktan başka işe yaramaz. Müşterilerime hep şunu söylüyorum: Bağlam penceresini bir vitrin gibi düşünün; oraya her şeyi tıkıştırmazsınız, sadece en iyi ürünleri, en görünür yere koyarsınız.

Teknik boyutu bir kenara bırakıp, danışmanlıkta en çok gözlemlediğim insani gerçeği söyleyeyim. Bir bilgi katmanının kalitesi, sonuçta o bilgiyi üreten ve besleyen insanların disiplinine bağlıdır. En zarif derleme boru hattı bile, kaynak dökümanlar dağınık, güncellenmemiş ve sahipsizse sizi kurtarmaz.

Bu yüzden başarılı projelerde teknik kadar kültürel bir dönüşüm de yaşanır. Kim hangi bilgiden sorumlu? Bir prosedür değiştiğinde kaynağı kim güncelliyor? Güncelliğini yitirmiş bir kaydı kim ayıklıyor? Bu sorular teknik değil, organizasyonel sorulardır ve cevapları netleşmeden hiçbir bilgi katmanı uzun ömürlü olmaz. Sahada gördüğüm en iyi kurumlar, bilgi sahipliğini (data ownership) net biçimde tanımlamış olanlardır. Onlar için bilgi katmanı bir yazılım projesi değil, yaşayan bir kurumsal varlıktır.

Son bir uyarı, çünkü heyecan bazen gözü karartıyor. Agentic RAG ve zengin bilgi katmanları güçlüdür ama pahalıdır. Her soruya beş araç çağrısı, üç retrieval turu ve bir reflection döngüsü koşan bir sistem, hem yavaş hem de fatura kabartıcıdır. Kurumsal ölçekte, günde on binlerce sorgu geldiğinde bu maliyet ciddi rakamlara ulaşır.

Benim uyguladığım prensip, kademeli mimaridir. Basit, sık gelen sorular için hızlı ve ucuz bir yol; karmaşık, nadir sorular için tam agentic akış. Sistemin önüne bir yönlendirici (router) koyar, sorunun karmaşıklığını değerlendirir ve doğru işlem hattına gönderirim. Bu, hem maliyeti kontrol altında tutar hem de kullanıcı deneyimini korur. Her şeyi en pahalı yoldan çözmek, mühendislik değil savurganlıktır.

Bir de Türkiye'ye özgü birkaç gerçeği eklemek isterim, çünkü küresel içerikler bu incelikleri çoğu zaman atlıyor. Öncelikle dil: Türkçe, birçok RAG bileşeni için hâlâ ikinci sınıf vatandaş muamelesi görüyor. Embedding modellerinin Türkçe morfolojisini yakalama başarısı İngilizceye göre değişkendir; ekli yapılar, aynı kökten türeyen kelimeler retrieval'ı zorlaştırabilir. Sahada Türkçe kaynaklarla çalışırken, embedding modelini dikkatle seçmek ve mümkünse Türkçe performansını kendi değerlendirme setinizle ölçmek şart.

İkincisi, kurumsal Türkiye'de bilginin önemli kısmı hâlâ dağınık: taranmış PDF'ler, Excel tabloları, e-posta ekleri, hatta kâğıt arşivler. Bilgi katmanı kurmadan önce çoğu zaman bir dijitalleştirme ve düzenleme safhası gerekiyor. Bunu peşinen kabul etmek, projeyi gerçekçi bir zemine oturtur. Üçüncüsü, KVKK'nın yanı sıra sektörel düzenlemeler (bankacılıkta BDDK, sağlıkta ilgili mevzuat) bilgi katmanına neyin girip neyin çıkamayacağını belirler. Bu yüzden hukuk ve uyum ekibini projeye başında dahil etmek, sonradan yangın söndürmekten çok daha ucuzdur.

Bütün bunları bir araya koyduğumda, sahadan çıkardığım kanaat şu: Bilgi katmanı, Türkiye'deki kurumlar için hem en büyük fırsat hem de en çok sabır isteyen iş. Fırsat, çünkü rakiplerinizin çoğu hâlâ düz vektör RAG'in demosuyla oyalanıyor; sabır isteyen, çünkü temiz, yapılandırılmış ve yönetilen bilgi bir gecede kurulmuyor. Ama bir kez kurulduğunda, o katman sizin en kalıcı yapay zeka varlığınız olacak; ve bunu erken başlatan kurumların, önümüzdeki birkaç yılda aradaki farkı açtığını şimdiden görüyorum.