Bu pano soldan sağa tek bir argüman olarak okunur: problem → en ucuz çözüm → ucuz kazanımlar → pahalı kazanımlar → ölçüm.

Tek kural

Bir basamağa ancak altındakini ölçtükten sonra çık. Farklı bir chunk boyutunu hiç denemeden agentic RAG’e atlamak, en ucuz problemin üstüne en pahalı çözümü koymaktır.

Bir modelin bildiği her şey eğitim verisinde donmuş durumda. Bu yüzden üç şeyi aynı anda yapamaz: güncel olmak, senin alanını bilmek, kaynak göstermek.

RAG tek cümleyle: modelin bilmediğini, cevap vermeden önce önüne koy. Retrieval-augmented generation — önce getir, sonra üret.

En kısa ayrım: RAG bilgi için, fine-tuning biçim için. Her hafta değişen olguları ağırlıklara gömmek, her hafta yeniden eğitmek demek.

Vanilla RAG iki ayrı pipeline’dır ve ikisini karıştırmamak işin yarısıdır: biri offline çalışıp index’i kurar, öteki her istekte çalışır.

Vanilla’da olmayan her şey

Router yok, çok adımlı planlama yok, geri bildirim yok. Model bir kez getirir, bir kez cevaplar. Asıl iş retrieval ile generation arasındaki sözleşmeyi kurmak: modele ne veriyorsun, karşılığında ne bekliyorsun.

Referans baseline — çalışan, sade, bilerek numarasız bırakılmış bir vanilla RAG servisi. Her ölçümün kıyaslandığı sıfır noktası bu.

İki hat

Naif RAG bozulduğunda dışarıdan model hatası gibi görünür. Neredeyse her zaman bir retrieval hatasıdır.

İki ayrı hastalık

• Düşük precision context’i gürültüyle doldurur. Model doğru chunk’ı görüp yine de ortada kaybedebilir — lost in the middle. Cevap yakın ama yanlış çıkar.
• Düşük recall, modelin sentezleyeceği malzemeyi hiç görmemesi demek. Cevap ya eksik ya uydurma olur.

Chunk boyutunu ayarlamak ölçülebilir en ucuz kazanım — ama asıl önemli olan boyut değil, sınır. Bir fikrin tam ortasından kesilmiş 512 token’lık bir chunk, temiz bir 1024’ten daha kötüdür.

Bu sırayla dene

1. Sabit token sayısına göre değil, başlıklara göre böl. Başlık zincirini her chunk’a taşı.
2. %10–15 overlap. Sınıra denk gelen cümleyi iki tarafta da tut.
3. Contextual retrieval. Her parçanın önüne — ucuz bir modele ürettirdiğin — hangi dokümanın neresinde durduğunu söyleyen 50–100 token’lık bir satır ekle, sonra onu embed et.

Metadata, her chunk’a enjekte edebileceğin context’tir: yıl, doküman başlığı, sayfa, bölüm, sahip. Ham semantik arama bunları birbirine karıştırır — sonuç düşük precision.

Sorunun içindeki 2021 bir anlam değil, bir filtre. Vektör benzerliği 2020 ve 2021 dokümanlarını neredeyse aynı görür.

Ne saklamalı

Dense vektörler anlamı yakalar ve birebir eşleşmeleri kaçırır: hata kodları, SKU’lar, kişi adları, sürüm numaraları. BM25 tam da bunlarda iyidir.

Neden bu sıra

• Geniş getir, dar ver. top-50 çekip top-5’e kesmek, ham bir top-20’yi context’e boca etmekten hem daha ucuz hem daha iyi.
• RRF iki listeyi skorlarını normalize etmeye hiç kalkışmadan birleştirir; onun yerine sıraları toplar.
• Cross-encoder soruyla chunk’ı birlikte okur. Bi-encoder’ın kaçırdığı ilişkiyi yakalar — latency pahasına; o yüzden en sona ve az sayıda aday üzerine gelir.

Benim için hâlâ çözülmemiş: retrieval biriminin embedding birimine göre nerede durması gerektiği.

Etrafında dönüp durduğum seçenekler:

1. Chunk’ı embed et, chunk’ı döndür. Basit ve herkesin başladığı yer. Anlamın bölümler arasına yayıldığı dokümanlarda kırılıyor.
2. Chunk’ı embed et, parent’ı döndür. Küçük vektörler, geniş context. Context bütçesini hızla yiyor.
3. Üretilmiş bir özeti embed et, orijinali döndür. Retrieval kalitesi artıyor; artık ingest pipeline’ında kaynaktan sapabilecek bir generation adımının sahibisin.

Sezgi: büyük bir metin bloğunu embed etmek kötü fikir. Vektör bulanıklaşır ve sorunun sorduğu o tek cümle gürültüde boğulur.

Çözüm: küçük şeyi embed et, büyük şeyi cevaba ver.

Ölçülmüş fark

Kaynak: LlamaIndex advanced-retrieval benchmark’ları. Mutlak sayılar corpus’a göre değişir; sıralama genellikle korunur.

Kullanıcının yazdığı cümle, arama için yazılmış bir cümle değil. Retrieval’dan önce sorguya dokunmak, index’e dokunmadan elde edilebilecek en büyük kazanım.

Vanilla RAG tek atış: yanlış şeyi getirdiyse toparlayamaz. Kaliteyi gerçekten yükselten şey, retrieval’ı kapalı bir döngüye çevirmek.

Döngüyü kapatan üç kontrol

• Relevance kontrolü. Getirilen chunk’lar soruyla ilgili mi? Değilse üretmeden önce tekrar ara. Corrective RAG’in çekirdeği bu.
• Groundedness kontrolü. Cevaptaki her iddia gösterilen context’te var mı? Yoksa daralt ya da "bilmiyorum" de.
• Bir durma koşulu. En fazla N tur. Yoksa döngü sonsuza kadar döner ve sen bunu ay sonunda öğrenirsin.

Agentic RAG sabit bir "getir ve üret" pipeline’ı değil; modelin kendi arama sürecini yürüttüğü bir orchestrator.

Geleneksel RAG’den farkı

Agentic RAG tek bir mimari değil, bir pattern ailesi. Hepsini birden kurma — hangi hatayı düzelttiğini bilerek teker teker ekle.

Hangi derde hangisi

• Sorular farklı kaynaklara gidiyor → Router.
• Soruların çoğu kolay, birkaçı zor → Adaptive (agentic kalitenin bedelini yalnızca zor olanlarda ödersin).
• Retrieval bazen boş dönüyor → Corrective.
• Cevaplar birkaç dokümanın birleştirilmesini gerektiriyor → Multi-agent.

Agentic RAG doğrulukta kazanır; bedelini latency, token ve hata yüzeyinde gerçek mühendislik emeğiyle öder. Karar, tam olarak bu takas.

Agent, durma koşulu olan bir döngüdür. Mühendisliğin çoğu o durma koşulunda yaşar.

Döngüler nerede bozulur

Onun yerine ne vermeli

• Sert bir adım bütçesi ve bir token bütçesi; ikisi de modele görünür olsun.
• Tool hataları, modelin okuyup üzerine aksiyon alabileceği metin olarak dönsün; asla gizlenmesin.
• Daha az ama daha geniş tool’lar; ne zaman kullanılmayacağını dürüstçe anlatan açıklamalarla.
• Yazabileceği bir scratchpad, ki N+1. adım N. adımın öğrendiğini görebilsin.

Büyük bir context window kova değil, bütçedir. İçine koyduğun her şey modelin dikkati ve senin latency hedefin için yarışır.

Hep döndüğüm kurallar

• Kararlı kısmı başa koy — system prompt, tool tanımları, uzun referans dokümanlar. Prompt caching’in yeniden kullanabildiği şey kararlı prefix’ler.
• Değişken kısmı sona koy — kullanıcının turu, yeni getirilen chunk’lar. Üst taraftaki tek bir düzenleme, sonrasındaki her şey için cache’i geçersiz kılar.
• Geçmişi her turda değil, bir eşikte özetle. Her tur kendini yeniden yazan yuvarlanan özetler cache’i yok eder ve sapar.

Fine-tuning olgular için değil, biçim için. Her hafta değişen bilgiyi ağırlıklara yakmak, her değişiklikte yeniden eğitmek demek.

İki meşru iş

1. Distillation. Güçlü bir modelin davranışını küçük, ucuz, hızlı bir modele taşı. Kazandığın şey maliyet ve latency.
2. Kalıntıyı sabitlemek. Prompt’un tutamadığı ton, çıktı şeması ve ret kalıpları. Hiç %100’e ulaşmayan uzun kuyruk.

Sıfırdan eğitmek neredeyse hiçbir ürün ekibinin işi değil. Pratikte seçim, hangi parameter-efficient yöntem olduğu.

Retrieval’ı iyileştirmenin en az konuşulan yolu: modeli değil, embedding’i fine-tune etmek. Alan jargonuyla dolu bir corpus’ta bu, olabilecek en ucuz kazanım.

Genel amaçlı bir embedding modeli şirketinin kısaltmalarını, parça numaralarını ya da iç kelime dağarcığını hiç görmedi. Sentetik soru üretimi bu açığı tek bir elle yazılmış etiket olmadan kapatır.

Neden işe yarıyor

• Eğitim çiftleri herkese açık bir benchmark’tan değil, senin corpus’undan geliyor.
• Retriever’ı iyileştirmek pipeline’daki her sorguyu iyileştirir — bir prompt değişikliğinin aksine, birikir.
• Aynı sentetik set, retrieval eval’leri için ground truth olarak yeniden kullanılabilir.

RAG’i uçtan uca ölçmeden önce izole ölç: verili bir soru için getirilen chunk’lar doğru olanlar mıydı? Cevap kalitesi bu cevaba bağlı.

Veri seti

Girdi bir soru, çıktı onu cevaplayan ground-truth doküman id’leri. Elle 20 tane yaz, sonra chunk’lardan sentetik sorular üreterek büyüt.

İzole eval’ler retrieval’ı denetler; uçtan uca eval’ler kullanıcının gördüğü cevabı denetler. İkisi de gerekli, hiçbiri diğerinin yerine geçmez.

İki mod

• Etiketsiz. Referans cevap yok: faithfulness, relevancy, ton, toksisite. Her commit’te çalıştıracak kadar ucuz.
• Etiketli. Ground-truth cevaplar var: doğruluk, kapsam. Yazması pahalı, regresyonları en keskin yakalayan da bu.

Eval’siz prompt ayarlamak, üstüne birkaç adım eklenmiş vibe’dan ibaret. Eval’in sofistike olması gerekmiyor; prompt değişmeden önce var olması gerekiyor.

Başlangıç seti

Modelle puanlamak

Cevap gerçekten açık uçluysa kullan, ve o zaman:

• Her seferinde tek boyut puanla. Tek bir "bu iyi mi" skoru gürültüdür.
• Judge’a rubriği ve bir referans cevabı ver.
• Bir örneklem üzerinde judge/insan uyumunu takip et. Hiç denetlemediğin bir judge, görgülü bir rastgele sayı üretecidir.