RAG Neden Hala Önemli? Yeni Nesil RAG Mimarileri
Bir dil modeli, eğitildiği veride olmayan hiçbir şeyi bilmez. Şirketinizin dün imzalanan sözleşmesini, bu sabah değişen fiyat listesini, üç yıllık destek arşivini bilmez ve bilemez. Modelin cevabını bu tür bir kaynağa dayandırma işine kısaca RAG diyoruz. İhtiyaç ortadan kalkmadı; kurumsal veri büyüdükçe daha da belirginleşti.
Buna rağmen "RAG öldü" cümlesi her birkaç ayda bir yeniden dolaşıma giriyor. Gerekçe genelde iki şey oluyor: bağlam pencereleri bir milyon token'ı geçti ve Claude Code artık vektör veritabanı yerine dosya sisteminde grep çalıştırıyor. İkisi de doğru. Çıkarılan sonuç yanlış.
Yanlış olmasının sebebi teknik bir ayrıntı değil, tanım meselesi. Çoğu kişi "RAG" derken 2023'ün alışkanlığını kastediyor: belgeyi sabit uzunlukta parçalara böl, hepsini embed et, soruya en yakın beş parçayı bul, prompt'un başına yapıştır. O alışkanlık gerçekten bitti ve iyi ki bitti. Kullanıcı "ödeme neden reddediliyor" diye sorduğunda cevap üç ayrı belgeye yayılmışsa, benzerlik araması bunlardan ikisini getirip üçüncüsünü kaçırıyordu. Kaçırdığını da fark etmiyordu; model elindeki eksik parçalarla gayet kendinden emin bir cevap yazıyordu.
Yöntem eskidi, ihtiyaç yerinde duruyor. Geriye iki soru kalıyor: bu ihtiyaç bağlam pencereleri bu kadar büyümüşken neden hala duruyor, ve onu karşılayan mimari nereye doğru gelişiyor. Yazının kalanı sırayla bu ikisi.
Bağlam penceresi neden yetmiyor?
En sık duyulan karşı öneri şu: madem model bir milyon token okuyabiliyor, aramayla uğraşmayalım, bilgi tabanını olduğu gibi bağlama koyalım.
Kulağa mantıklı geliyor, ölçümler desteklemiyor. Chroma'nın 18 model üzerinde yürüttüğü Context Rot çalışması, girdi uzadıkça performansın basit görevlerde bile bozulduğunu gösteriyor. Bozulma düzenli de değil: sorunun kelimeleriyle cevabın kelimeleri örtüşmediğinde hızlanıyor, metnin arasına konan tek bir çeldirici cümle bile doğruluğu düşürüyor. Adobe'nin NoLiMa çalışması aynı yere varıyor; yıllardır referans aldığımız "samanlıkta iğne" testleri meğerse yalnızca kelime eşleşmesini ölçüyormuş. Model uzun metni okuyabiliyor olabilir. Okuduğunu aynı kalitede işlediği bambaşka bir iddia ve bu iddia doğrulanmıyor.
İkinci sorun daha sıradan: fatura. Her istekte yüz binlerce token'ı baştan işlemek, hedefli birkaç bin token'a kıyasla tipik iş yüklerinde 8 ila 82 kat pahalıya geliyor, üstüne bir de yavaş. Dikkat mekanizmasının karesel ölçeklenmesi bunu geçici bir fiyatlandırma sorunu olmaktan çıkarıyor.
Kurumsal tarafta üçüncü bir şey devreye giriyor: bu cevabı hangi belgeye dayanarak verdin, kullanıcı o belgeyi görmeye yetkili miydi, belge güncel miydi. Her şeyi bağlama yığan bir yapıda bu soruların cevabı yok. KVKK kapsamında çalışan bir sistemde "yok" kabul edilebilir bir cevap değil.
Aynı soruyu cevaplamanın iki yolu: her şeyi bağlama koymak ile yalnızca gerekeni getirmek.
Aramanın kendisi değişti
Buraya kadarki kısım RAG'in neden hala gerektiğini anlatıyor. Asıl ilginç olan, o ihtiyacı karşılayan mimarinin son iki yılda nasıl değiştiği. Dört yerde kırıldı: aramanın kendisinde, indekslemenin ne anlama geldiğinde, bağlamın nasıl daraltıldığında ve neyin aranabilir sayıldığında.
İlkinden başlayalım. Eskiden arama, model çalışmadan önce bir kez yapılan bir adımdı. Bugün ajanın kendi kararıyla, defalarca ve farklı yöntemlerle yürüttüğü bir iş. Kuba Rogut'un tarifiyle ortada tek bir teknik değil, bir araç kutusu var.
İki kavramın da yaygın karşılığı ile gerçek kapsamı: RAG yalnızca vektör araması değil, agentic search de yalnızca grep değil.
• Vektör arama, anlamsal benzerlik için. Kullanıcı “ödeme başarısız oluyor” yazdığında PaymentDeclinedException sınıfına ulaşmayı sağlayan katman bu.
• BM25 (tam metin arama), kelime eşleşmesi için. Hata kodları, fonksiyon isimleri, ürün kodları, madde numaraları. “Tam olarak bu” gerektiren her yerde embedding'lerden daha güvenilir.
• Programatik araçlar: glob, regex, metadata ve yetki filtreleri. Ucuz, deterministik, denetlenebilir. Arama uzayını modele hiç dokundurmadan küçültüyor.
• Ve döngü. Ajan tek seferde arayıp umut etmiyor; arıyor, bulduğunu değerlendiriyor, sorgusunu yeniden yazıyor, aradığını bulana kadar devam ediyor.
Farkı tek cümleye indirmek gerekirse: eski sistem eksik bilgiyle cevap üretiyordu, yenisi eksikliği fark edip tekrar arıyor.
Eski kalıp: bir kez ara, prompt'u doldur, en iyisini um. Yeni kalıp: adım adım düşün, gerektikçe ara, yalnızca işe yarayanı getir.
LightOn bu davranışa “koşullu dikkat politikası” diyor. Sistem sırayla dört soruya cevap veriyor. Bu soru gerçekten arama gerektiriyor mu, hangi sorguyla aranacak, hangi yöntemle, ve toplanan en küçük bağlamla nasıl cevap yazılır.
Cursor ve Claude Code: aynı soru, zıt cevaplar
İkinci kırılma indekslemede. Bunun en somut laboratuvarı kodlama ajanları, çünkü ikisi de aynı problemi çözüyor: devasa bir kod tabanında doğru dosyayı bul. Ve tam zıt yolları seçmişler.
Cursor kod tabanını önceden analiz ediyor, parçalara ayırıp embed ediyor ve bir vektör veritabanına yazıyor. Başlangıçta bir maliyeti var, büyük depolarda saatler alabiliyor, ama çalışma anında arama milisaniyeler sürüyor. Cursor'ın kendi yayımladığı ölçümde yalnızca grep kullanan yaklaşıma kıyasla semantik arama soruları cevaplamada ortalama %12,5 daha yüksek doğruluk veriyor. 1.000 dosyayı geçen projelerde ajanın yazdığı kodun korunma oranı %2,6 artıyor.
Claude Code indeks tutmuyor. Her sorguda dosya sistemini araçlarla tarıyor. Bedeli her oturumda tekrarlanan keşif yükü ve token maliyeti. Kazancı sadelik: vektör veritabanı yok, embedding servisi yok, indeksi güncel tutma derdi yok, RAG'e içkin güvenlik ve tazelik sorunları da yok.
İkisini rakip gibi okumak yanıltıcı. 50 görevlik bir değerlendirmede ham ajanda okunan dosyaların 3'te 1'i boşunayken, grep ile bu oran 5'te 1'e, grep ve semantik arama birlikte kullanıldığında 8'de 1'e iniyor. Semantik aramanın katkısı daha fazla şey bulmak değil, boşa okunan dosyayı azaltmak. Yani doğrudan token faturası.
İndeksleme bir maliyet kalemi değil, önbellek
Rogut'un tartışmayı en çok netleştiren cümlesi şu: embedding almak "önbelleğe alınmış hesaplama"dır.
Bir belgeyi anlamak için harcanan hesaplamayı bir kez yaparsınız, sonucu vektör veritabanına yazarsınız, ajanlar bunu binlerce kez yeniden kullanır. Grep tabanlı keşif ise aynı anlama işini her oturumda sıfırdan tekrarlar. Rogut'un paylaştığı örnekte, tekrarlanan oturumlarda keşif için harcanan 6.314 token, önceden hesaplanmış retrieval ile aynı görevde 424 token'a iniyor. Tek bir geliştirici için önemsiz bir fark. Günde milyonlarca ajan çağrısı yapan bir platform için altyapı ekonomisinin tamamı.
Her oturumda tekrarlanan keşif ile bir kez indekslenmiş retrieval'ın aynı görevdeki token maliyeti.
Aynı mantığın en temiz örneği Anthropic'in Contextual Retrieval yöntemi. Her parçaya, ait olduğu belgedeki bağlamı açıklayan kısa bir metin önceden ekleniyor ve öyle indeksleniyor. Bir kereye mahsus, belge başına milyon token için yaklaşık 1 dolarlık bir hesaplama.
Bu kazancın tamamı model değiştirmeden, prompt'a dokunmadan elde ediliyor. Son satırdaki reranking adımı ise genellikle eklenmesi en kolay bileşen olduğu halde çoğu ekipte “sonra bakarız” listesinde duruyor. Bu adımı erken almak, hem maliyet hem de cevap kalitesi üzerinde doğrudan etkili.
Bağlam kademeli olarak daralıyor
Üçüncü kırılma bağlamın nasıl toplandığında. Aynı tabloyu Google tarafından da duyuyoruz: Jeff Dean'in argümanı, dikkat mekanizmasının karesel ölçeklenmesi yüzünden bağlam penceresini büyütmenin doğal bir tavanı olduğu. Kendi ifadesiyle bir milyon token yapabileceklerinizin sınırını zorluyor, bunu bir trilyon token'a uygulayamazsınız.
Dean'in önerdiği yol kademeli retrieval. Hafif ve ucuz modellerle trilyonlarca token'lık havuzdan yaklaşık 30.000 aday belge seçiliyor, giderek daha pahalı ve daha isabetli sıralayıcılarla bu küme daraltılıyor, sonunda gerçekten dikkat edilmesi gereken 117 belge asıl modele veriliyor. Hedef trilyonlarca token'a erişmek değil, o kalabalığın içinden doğru olan bir milyonu çıkarabilmek.
Bu, Google Arama'nın onlarca yıldır yaptığı işin LLM'e uyarlanmış hali. İlginç olan kimin söylediği: sektörün en büyük bağlam pencerelerinden birini üreten şirketin baş mimarı, geleceği bağlam penceresinde görmüyor.
Metnin ve tek adımın yetmediği yer
Dördüncü kırılma neyin aranabilir sayıldığında. Buraya kadar anlatılanların sessiz bir varsayımı var: korpus metinden oluşuyor ve sorunun cevabı tek bir yerde duruyor. Kurumsal veride ikisi de çoğu zaman geçerli değil. Yeni nesil mimarilerin geliştiği yönler de tam buradan çıkıyor.
İlk varsayım tek adım. “Bu sözleşmeyi kim onayladı, hangi politikaya dayanarak?” sorusunun cevabı tek belgede yok; onay kaydı bir yerde, politika başka yerde, ikisini bağlayan şey de hiçbir belgede yazmıyor. Benzerlik araması bu ilişkiyi kuramaz, çünkü metinsel olarak benzer olan şeylerle ilişkili olan şeyler farklı kümeler.
Bilgi grafiği üzerine kurulan GraphRAG yaklaşımları burada belirgin fark yaratıyor: çok atlamalı sorularda Recall@5 düz RAG'de %73,4 iken graf destekli kurulumda %87,8'e çıkıyor, karmaşık akıl yürütme gerektiren görevlerde doğruluk graf tarafında %53,4, düz metin parçalarında %42,9 ölçülüyor.
Bu bedava gelmiyor. Tek adımlık olgusal sorularda düz RAG hala önde (F1 64,8'e karşı 63,0), yani her şeyi grafa taşımak ters tepiyor. Graf kurmanın indeksleme maliyeti de ciddi; orta ölçekli bir korpus için yapılan bir hesapta yaklaşık 48 dolar çıkmış, LazyGraphRAG gibi varyantlar bunu birkaç yüzde birine indiriyor. Karar kuralı sade: sorularınızın önemli kısmı ilişki kurmayı gerektiriyorsa graf katmanı ekleyin, gerektirmiyorsa eklemeyin.
İkinci varsayım metin. Kurumsal arşivin ciddi bir kısmı diyagram, mimari şema, tablo, taranmış PDF ve sunum. Klasik hat önce metni çıkarmaya çalışıyor; çıkaramadığı yerde bilgi sessizce kayboluyor ve arama o bilginin var olduğunu bile bilmiyor. ColPali gibi görsel dil modelleri bu adımı atlıyor, sayfayı doğrudan görüntü olarak indeksliyor. Yazarların oluşturduğu ViDoRe kıyaslamasında görsel açıdan zengin belgelerde klasik metin çıkarma hatlarını belirgin biçimde geçiyorlar, üstelik indeksleme hattı daha basit ve hızlı çalışıyor.
Bu modellerin altındaki fikir kendi başına önemli: late interaction. Bir belgeyi tek bir vektöre sıkıştırmak bilgi kaybettirir, çünkü sorgunun hangi ayrıntıya bakacağını indeksleme anında bilemezsiniz. Late interaction eşleştirmeyi arama anına bırakıyor ve token seviyesinde yapıyor. Maliyeti daha büyük indeks, karşılığı da özellikle uzun ve karmaşık belgelerde daha isabetli sıralama.
Üçüncü yön daha yeni: ajan belleği. Bir ajan yalnızca kurumsal korpusu değil, kendi geçmiş oturumlarını da aramak zorunda kalıyor. Neyi saklayacağı, ne zaman geri getireceği, eskiyen bilgiyi nasıl ayıklayacağı sorularının hepsi retrieval sorusu. Bu alanın mimarisi henüz oturmuş değil ama gittiği yer belli: bellek de indekslenip aranan bir korpus haline geliyor.
Üç yönün de ortak noktası şu: hangisine ihtiyacınız olduğunu ancak kendi sorgularınıza bakarak anlarsınız. Sorgularınızı tek adımlık, ilişkisel ve görsel diye ayırıp her birinin oranını ölçmeden graf mı multimodal mı gerektiğine karar veremezsiniz. Ölçmeden verilen bu karar, sektörün son iki yılda en çok kaynak harcadığı alan.
Pratikte ne yapmalıyız?
Kendi sisteminizde retrieval katmanına dokunacaksanız öncelik sırası aslında bellidir. Çoğu ekibin en hızlı kazancı şu beş ilkeyle elde ettiğini görüyoruz:
- Vektör aramayı yalnız bırakmayın. Yanına BM25 (tam metin) koyun. Hata kodları, fonksiyon adları ve özel isimler embedding'lerin en zayıf olduğu yerdir; bu tür sorgularda kelime eşleşmesi çok daha güvenilirdir.
- Reranking'i sonraya bırakmayın. Efor/kazanç oranı en yüksek adım budur ve genellikle eklenmesi en kolay bileşendir.
- Parçalamayı belge yapısına göre yapın. Her parçaya ait olduğu bağlamı ekleyin; filtreleme yeteneğinizin tamamı o parçadaki metadata'ya bağlı kalacaktır.
- Ajana bir durma koşulu verin. "Yeterli bilgiyi buldum mu?" sorusunu soran, adım ve token bütçesiyle sınırlanmış bir döngü kurun.
- Her aşamayı ayrı ölçün. Yalnızca nihai cevaba bakarsanız hatanın retrieval'da mı üretimde mi olduğunu göremezsiniz; bu katmanlarda hatalar zincirleme ilerler.
Bir de bunun tam tersi geçerlidir. Yüz sayfalık sabit bir bilgi tabanınız ve günde yalnızca birkaç yüz sorgunuz varsa, uzun bağlam gerçekten yeterlidir; o ölçekte retrieval altyapısı kurmak kazandırdığından fazlasını götürür.
RAG mimarinizi birlikte kuralım
Kurumsal verinizi doğru, güvenli ve ölçeklenebilir biçimde kullanmak; doğru retrieval mimarisini, doğru modeli ve doğru altyapıyı seçmekle başlar. Mad Cat Labs olarak kurumsal RAG sistemleri, özel dil modelleri, inference altyapıları ve GPU optimizasyonu üzerine çalışıyoruz.
Projeniz için konuşmak isterseniz bize ulaşın.