Standart RAG Bir Mimari Değil, Bir Araç Olmalı

Fikrimi değiştiren nokta query ambiguity oldu

Ben bu meseleye çok basit bir sorudan girdim: kullanıcının query’si belirsizse ne oluyor?

Bu teorik bir edge case değil. AmbigQA çalışması, NQ-open içindeki soruların yarısından fazlasının; entity ve event referansları gibi nedenlerle birden fazla yoruma açık olduğunu gösterdi.[1] Daha sonraki clarification-based QA çalışmaları da ambiguity detection ve clarification-question generation adımlarını cevap üretmeden önce ayrı problemler olarak ele aldı.[2]

Bu noktadan sonra “standart RAG” dediğimiz mimariye tekrar bakmaya başladım.

Kabaca şu yapıyı kullanıyoruz:

query → embedding → vector search → top-k chunk → LLM → cevap

Bence asıl problem chunk size değil. Daha temel varsayım şu: kullanıcının ilk query’sinin zaten doğru retrieval query’si olduğunu kabul ediyoruz.

Oysa gerçek hayatta bu varsayım çok kolay bozuluyor.

Kullanıcı ne istediğini tam ifade etmemiş olabilir. Query birden fazla anlama gelebilir. Soru iki ayrı bilgiyi birleştirmeyi gerektirebilir ve bu iki bilgi aynı arama ifadesiyle bulunamayabilir. İlk retrieval sonucunda öğrendiğimiz bir terim, kişi, tarih, istisna veya ilişki ikinci aramanın tamamen farklı yapılmasını gerektirebilir.

Böyle bir durumda retrieval tek işlem değildir. Bir süreçtir.

Agentic retrieval’ı daha kullanışlı bulmamın temel nedeni de bu.

flowchart TD
    A["Kullanıcı query'si"] --> B["Yorumla / ambiguity tespit et"]
    B --> C["Query'yi böl veya yeniden yaz"]
    C --> D["Retrieve et"]
    D --> E["Evidence'i incele"]
    E --> F{"Eksik / çelişkili / yetersiz mi?"}
    F -->|Evet| G["Query'yi değiştir"]
    G --> D
    F -->|Hayır| H["Select / rerank / verify"]
    H --> I["Cevapla"]

Aradaki farkı tek cümlede şöyle görüyorum:

Standart RAG query’yi input olarak görür. Agentic RAG retrieval’ı bir trajectory olarak görür.

Literatür zaten bu yöne gidiyor

Bunun en temiz örneklerinden biri IRCoT. Çalışmanın temel argümanı şu: multi-step sorularda one-step retrieve-and-read yeterli değil, çünkü ikinci aşamada neyi aramanız gerektiği ilk retrieval’dan ne öğrendiğinize bağlı.[3] IRCoT; HotpotQA, 2WikiMultihopQA, MuSiQue ve IIRC üzerinde reasoning ile retrieval’ı iç içe geçirerek retrieval performansında 21 puana kadar, downstream QA performansında ise 15 puana kadar artış raporladı.[3]

FLARE başka bir açıdan aynı probleme geliyor. Retrieval’ı sadece başta bir kez yapmak yerine generation sırasında yeni bilgiye ihtiyaç olup olmadığını aktif olarak değerlendiriyor ve gerektiğinde yeni query üreterek tekrar retrieval yapıyor.[4] Dört long-form knowledge-intensive generation görevinde baseline’lara karşı daha iyi veya rekabetçi sonuçlar raporlandı.[4]

Adaptive-RAG ise mimari problemi doğrudan ortaya koyuyor: her query’ye aynı retrieval stratejisini uygulamak mantıklı değil.[5] Sistem question complexity’ye göre no-retrieval, single-step retrieval veya iterative retrieval arasında seçim yapıyor ve ilgili baseline’lara kıyasla accuracy ile efficiency arasında daha iyi bir denge raporluyor.[5]

SELF-RAG de fixed RAG’in başka bir sorununa dikkat çekiyor: retrieval gerekli olsun veya olmasın sabit sayıda passage çekmek ve bunları modele vermek output kalitesini düşürebiliyor.[6] Bu nedenle modelin ne zaman retrieval yapacağını ve gelen evidence’i nasıl değerlendireceğini daha seçici hale getiriyor.[6]

Yani farklı çalışmaların işaret ettiği yön aslında aynı:

Retrieval, query’ye ve süreç içinde öğrenilen yeni bilgiye adapte olabilmeli.

2026 NVIDIA benchmark’ı trade-off’u çok net gösteriyor

NVIDIA NeMo Retriever ekibi ViDoRe v3 Pipeline benchmark üzerinde agentic retrieval pipeline yayımladı.[7] Burada agent karmaşık query’leri yeniden yazabiliyor, retrieval tool’unu birden fazla kez çağırabiliyor, sub-question’ları araştırabiliyor ve en sonunda top-k evidence’i seçebiliyor.[7]

Agentic pipeline 69.2 nDCG@10, simple dense pipeline ise 64.4 elde ediyor; NVIDIA bunu yaklaşık %7.4 relative improvement olarak veriyor.[7] Fakat search latency de 3.61 saniyeden 136 saniyeye çıkıyor, çünkü agent query rewrite ve multiple retrieval yapabiliyor.[7]

İşte çoğu kişi burada durup “Agentic retrieval çok yavaş” diyor.

Ben bu sonuca katılmıyorum.

Latency gerçek bir problem; ama aynı zamanda ürün tasarımı problemi

Öncelikle streaming 136 saniyelik hesaplamayı 3.6 saniyeye indirmiyor. Fiziksel latency hâlâ orada.

Ama kullanıcı açısından şu ikisi aynı deneyim değil:

136 saniye sessizlik

ile

Soruyu analiz ediyorum…
Ana corpus içinde arıyorum…
8 aday kaynak buldum…
Çelişen evidence'i kontrol ediyorum…
Query'yi yeniden yazıyorum…
İkinci retrieval yapılıyor…
Final evidence set doğrulanıyor…
Cevap oluşturuluyor…

Tool updates, retrieval progress, bulunan kaynaklar, ara sonuçlar ve verification adımlarını stream ettiğimizde black-box bekleme süresini görünür bir çalışma sürecine çeviriyoruz. Compute latency değişmese bile perceived latency ciddi şekilde değişiyor.

Daha önemlisi, agentic mimari her query’de pahalı loop’u çalıştırmak zorunda değil. Adaptive-RAG’den çıkardığım en önemli derslerden biri bu.[5]

Production tarafında şuna benzer bir routing yapılabilir:

basit / açık query
    → one-shot retrieval

ambiguous query
    → clarify veya multiple interpretation

multi-hop query
    → iterative retrieval

zayıf evidence
    → rewrite + retrieve again

çelişkili evidence
    → retrieve + compare + verify

Dolayısıyla agentic latency probleminin çözümü “standart RAG’e geri dönmek” değil.

Bence çözüm budgeted agentic retrieval.

Agentic sistemler de başarısız olabilir

Burada ters sonuç veren deneyleri görmezden gelmek de doğru olmaz.

Reproducible bir open-source HotpotQA benchmark’ı; dataset, embedding, chunking, vector store ve 8B Llama modelini sabit tutup farklı RAG mimarilerini karşılaştırdı.[8] Bu deneyde Basic RAG Recall@5 olarak 0.609, ReAct tabanlı Agentic RAG ise 0.498 elde etti ve median latency yaklaşık iki katına çıktı.[8]

Ben bu sonucu “agentic retrieval işe yaramıyor” şeklinde okumuyorum.

Benim çıkardığım sonuç şu:

Agency, reasoning ve control-loop kalitesini büyütüyor. İyi ise avantajı, kötü ise hatayı büyütüyor.

8B bir model kötü search decision verirse, query’yi yanlış rewrite ederse veya yanlış yerde durursa hatalar loop içinde birikiyor. Kötü bir agent gayet rahat biçimde iyi bir retriever’dan daha kötü olabilir.

Bu bir engineering constraint. Retrieval’ı sonsuza kadar tek adıma kilitlemek için gerekçe değil.

2026’da yayımlanan IEEE Agentic Self-RAG çalışması diğer tarafı gösteriyor. Query Analyzer, Retrieval Critic ve Answer Verifier gibi ayrılmış control adımları kullanıyor.[9] HotpotQA üzerinde Vanilla RAG’in %45.2 exact match sonucuna karşı %54.3, StrategyQA üzerinde ise %59.2 accuracy sonucuna karşı %68.5 raporluyor.[9]

Dolayısıyla bence yanlış soru şu:

“Agentic RAG her zaman standart RAG’den daha mı iyi?”

Elbette değil.

Asıl soru şu:

“İlk retrieval başarısız olduğunda hangi mimari kendini adapte edebilir?”

Standart one-shot RAG burada yapısal olarak sınırlı.

Cursor benim için güçlü bir production signal

Coding agent tarafında bu konu çok daha görünür hale geliyor.

Cursor kendi dokümantasyonunda codebase içindeki değişen dosyaların syntactic chunk’lara ayrıldığını ve semantic search için embedding üretildiğini anlatıyor.[10] Cursor ayrıca agent’ın semantic search ile grep gibi exact-search araçlarını birlikte kullanabildiği agentic bir search yaklaşımını tarif ediyor.[11]

Cursor’ın kendi evaluation’ında semantic search, agent cevaplarının accuracy’sini ortalama %12.5 artırmış; kazanım modele göre değişiyor.[11] Cursor semantic search’ü agent performance’ın önemli sürücülerinden biri olarak tanımlıyor.[10]

Bu, “her agentic RAG her standard RAG’i yener” diyen kontrollü akademik bir benchmark değil. Ben de öyle sunmuyorum.

Ama production açısından önemli bir sinyal:

Güçlü agent’lar nasıl arayacaklarına, ne arayacaklarına ve hangi search aracını kullanacaklarına karar verebildiklerinde daha kullanışlı hale geliyor.

Agentic retrieval gerçekten anlamsız bir yaklaşım olsaydı Cursor gibi büyük coding-agent ürünlerinin indexing, semantic retrieval, exact search, query selection ve tekrar eden tool kullanımına bu kadar mühendislik yatırımı yapmasını açıklamak zor olurdu.

Benim vardığım sonuç

Standart RAG ortadan kalkmalı demiyorum.

Daha farklı bir şey söylüyorum:

Standart RAG mimari olmaktan çıkıp agent’ın kullanabildiği bir tool haline gelmeli.

Dense top-k retrieval faydalı. BM25 faydalı. Hybrid retrieval faydalı. Reranker faydalı. Fixed chunk search faydalı.

Ama bunların hiçbiri en baştan “her kullanıcı sorusu tam olarak bir retrieval pass ile çözülecek” kararını vermemeli.

Daha güçlü mimari, şunlara karar verebilen agent’tır:

• retrieval gerekli mi;
• query ambiguous mı;
• rewrite gerekli mi;
• query decomposition gerekli mi;
• hangi retriever veya search tool kullanılmalı;
• bulunan evidence yeterli mi;
• ikinci retrieval gerekli mi;
• ne zaman durmalı.

Basit soruda agent gidip bizim standart RAG dediğimiz aynı hızlı top-k retrieval’ı kullanabilir.

Ama zor soruda standard RAG’in yapamadığı şeyi yapabilir:

adapte olabilir.

Ben query ambiguity probleminden yola çıktım ve bu yüzden agentic retrieval’ın daha kullanışlı olduğu sonucuna vardım.

Gelecekte baskın olacağını düşündüğüm mimari “retrieval yerine agent” değil.

Retrieval’ı first-class tool olarak kullanan agentic orchestration; standart RAG ise bunun içindeki fast path.

Kaynaklar

1. Min, S. et al. (2020). AmbigQA: Answering Ambiguous Open-domain Questions. EMNLP. Kaynak
2. Lee, D. et al. (2023). Asking Clarification Questions to Handle Ambiguity in Open-Domain QA. Findings of EMNLP. Kaynak
3. Trivedi, H. et al. (2023). Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions. ACL. Kaynak
4. Jiang, Z. et al. (2023). Active Retrieval Augmented Generation. EMNLP. Kaynak
5. Jeong, S. et al. (2024). Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity. NAACL. Kaynak
6. Asai, A. et al. (2024). SELF-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR. Kaynak
7. NVIDIA NeMo Retriever Team (2026). NeMo Retriever’s Agentic Retrieval Pipeline — ViDoRe V3 Pipeline benchmark. Kaynak
8. Pradhan, S. (2026). RAG Architecture Benchmark — HotpotQA. Open-source reproducible benchmark; peer-reviewed değil. Kaynak
9. Agentic Self-RAG: Multi-Agent Reasoning for Self-Correcting Retrieval-Augmented Generation (2026). IEEE ICIT. DOI: 10.1109/ICIT68548.2026.11577708. Kaynak
10. Cursor (2026). Securely indexing large codebases. Kaynak
11. Cursor (2025). Improving agent with semantic search. Kaynak