Agentic RAG Nedir? Dinamik Bilgi Erişimi Rehberi 2026

“Hangi sağlayıcının son 18 aydaki güvenlik açığı raporunu getir, rakipleriyle karşılaştır ve toplam zararı hesapla.” Bu soruyu klasik bir RAG sistemine yönelttiğinizde büyük olasılıkla tek bir retrieval turunda bulunabilecek en yakın belgeyi alırsınız. Oysa sorunun yanıtı üç farklı kaynakta dağınık hâlde duruyor; her bulgu bir sonrakini bağlamlandırıyor.

İşte bu boşluk, Agentic RAG’in çözdüğü problem. LLM agent, retrieval sürecini statik bir adım olmaktan çıkarıp dinamik, çok turlu ve araç odaklı bir karar döngüsüne dönüştürür. 2026 itibarıyla bu yaklaşım, araştırma asistanlarından kurumsal bilgi sistemlerine kadar geniş bir yelpazede klasik RAG’in yerini almaya başlıyor.

Agentic RAG Nedir?

Agentic RAG, retrieval sürecinin LLM tarafından aktif olarak planlandığı, yürütüldüğü ve değerlendirildiği bir mimaridir. Klasik RAG’da retrieval sabit bir fonksiyon çağrısıdır: kullanıcı sorusu embedding’e dönüşür, en yakın belgeler çekilir, model yanıt üretir. Agentic yaklaşımda bu zincir yerini esneklik ve özerkliğe bırakır.

LLM agent şu soruları kendisi yanıtlar:

• Hangi kaynaklardan bilgi alınmalı?
• Mevcut soru, retrieval için yeterince spesifik mi?
• Getirilen bilgiler soruyu gerçekten karşılıyor mu?
• Sonraki adımda ne yapılmalı?

Bu yapıyı klasik RAG’dan ayıran üç temel özellik var:

1. Dinamizm: Sorgu sayısı ve içeriği önceden sabit değildir. Model, her adımda bir sonraki hamlesini belirler.
2. Öz-değerlendirme: Alınan bilginin kalitesi bir Critic katmanıyla denetlenir; yetersizse yeni retrieval döngüsü açılır.
3. Çok adımlılık: Multi-hop sorular birden fazla alt sorguda çözülür; her adımın çıktısı bir sonrakine girdi olur.

Chain of Thought prompting ile bağlantısı kuvvetlidir: CoT’ta model düşünce zincirini iç metinle oluşturur; Agentic RAG’de bu zincir dış bilgi erişimiyle de doğrulanır. Karar yeteneği pratikte üç temel dinamik üzerinden işler: sorgu yeniden yazma, araç seçimi ve iteratif retrieval. Her biri tek başına bile klasik RAG’ın üzerinde ciddi bir kalite farkı yaratabilir.

Sorgu Yeniden Yazma: Bilgiye Giden En Kısa Yolu Bulmak

Kullanıcıların doğal dildeki soruları çoğunlukla retrieval açısından verimsizdir. “Bu teknoloji işe yarıyor mu?” sorusu bir insana anlam taşır; ama vector store için gereksiz yere genel bir sorgudur. Hangi teknoloji? Neye göre işe yaramak?

Sorgu yeniden yazma (query rewriting) bu sorunu, orijinal kullanıcı sorusunu bir ya da birkaç daha spesifik retrieval sorgusuna dönüştürerek çözer.

Yeniden yazma stratejileri üç kategoride değerlendirilebilir:

Genişletme (Expansion): Orijinal sorguya eş anlamlı ifadeler veya ilişkili kavramlar eklenir. “LLM latency” sorusu “token üretim hızı”, “inference süresi” ve “GPU throughput” sorgularıyla genişletilirse farklı terminolojiyle yazılmış belgeler de bulunabilir.

Parçalama (Decomposition): Karmaşık soru alt sorulara bölünür. “Yapay zeka mevzuatı AB ile ABD’de nasıl farklılaşıyor?” sorusu “AB AI Act temel gereksinimler” ve “ABD federal AI düzenlemeleri 2024-2025” gibi iki bağımsız retrieval işlemine dönüşür.

Yeniden çerçeveleme (Reframing): Soru, daha iyi sonuç verecek bir perspektiften yeniden ifade edilir. “Modeli iyileştir” gibi belirsiz bir görev “retrieval kalitesini düşüren hataların listesi” ve “embedding modelini değiştirmenin etkisi” gibi somut alt hedeflere çevrilir.

Bu adım, sisteme ek bir LLM çağrısı maliyeti yükler. Ama araştırmalar ve üretim uygulamalarından gelen geri bildirimler, uygun prompt tasarımıyla bu yatırımın retrieval doğruluğunda %20-40 kazanıma dönüştüğünü gösteriyor. Özellikle belirsiz veya çok boyutlu sorularda fark belirginleşir.

Araç Seçimi: Doğru Kaynağa Doğru Zamanda Gitmek

Klasik RAG tek bir retrieval mekanizması kullanır: genellikle bir vector store’a yapılan embedding tabanlı arama. Agentic yaklaşımda LLM agent elindeki araç setine göre kaynağa karar verir.

Tipik bir araç seti şöyle görünebilir:

Araç seçim kararı, modelin function calling yeteneğiyle entegre çalışır. OpenAI, Anthropic ve Google’ın API’leri bu yapıyı doğrudan destekler: her araç bir JSON şemasıyla tanımlanır, model hangi aracı ve hangi parametrelerle çağıracağına kendisi karar verir.

LLM guardrails bağlamında araç seçimi önemli bir güvenlik katmanı oluşturur: hangi araçların ne koşullarda kullanılabileceği, bütçe limitlerinin nasıl uygulanacağı ve hassas kaynaklara erişim kısıtlamaları burada yapılandırılır.

İteratif Retrieval: Cevap Yeterliyse Dur, Değilse Devam Et

Klasik RAG’ın en büyük kısıtı retrieval döngüsünün yalnızca bir kez çalışmasıdır. Getirilen belgeler soruyu karşılamazsa sistem yine de yanıt üretmeye çalışır. Bu da halüsinasyon riskini yükseltir.

Agentic RAG’de iteratif döngü şu şekilde işler:

1. Kullanıcı sorusu → Sorgu yeniden yazma
2. Retrieval → Belgeler toplanır
3. Değerlendirme → "Bu belgeler yeterli mi?"
   - EVET → Yanıt sentezi
   - HAYIR → Yeni sorgu üret, 2'ye dön
4. Nihai yanıt üretimi

Değerlendirme katmanı (Critic) üç farklı sinyale bakabilir:

Alaka düzeyi: Getirilen belgeler soruyla ne kadar ilgili? Embedding benzerlik skoru bunun için temel bir göstergedir; ama bazen yüksek benzerlik skoru gerçek alaka anlamına gelmez.

Tamlık: Sorunun tüm boyutları ele alındı mı? Çok parçalı bir sorunun yarısına yanıt verilebilecek belgeler var ama diğer yarısı için hiçbir şey yoksa döngü devam etmelidir.

Çelişki: Farklı kaynaklardan gelen bilgiler birbiriyle çelişiyor mu? Bu durum ya ek retrieval ya da modelin bağlam üretim sırasında çelişkiyi açıkça belirtmesini gerektirir.

Production ortamında döngü sınırı (max_iterations veya max_tokens_budget) zorunludur. Sınır olmadan çalışan bir döngü hem bütçeyi tüketir hem de kullanıcıya yanıt vermeden askıda kalabilir.

Agentic RAG Mimarisi: Dört Ana Bileşen

Yukarıdaki dinamikleri hayata geçiren tipik bir Agentic RAG sisteminde dört ana bileşen birlikte çalışır ve her biri bir öncekinin çıktısına muhtaçtır:

Planner, gelen soruyu analiz edip alt görevlere böler. Karmaşık bir soruyu tek bir retrieval isteğine sıkıştırmak yerine, “önce X’i bul, ardından Y ile karşılaştır” şeklinde adımlı bir plan hazırlar. Prompt engineering perspektifinden bakıldığında bu, esasen modelin göreve özel bir decomposition gerçekleştirmesidir.

Retriever, her adım için uygun kaynağı ve sorguyu belirler. Bir adımda dahili vector store’a gidebilir, bir sonrakinde web arama API’sine ya da yapılandırılmış bir SQL veritabanına yönelebilir. Kaynak seçimi de modelin kendi kararı; önceden yazılmış kural setlerine bağımlı değil.

Critic / Evaluator, retrieval sonucunun kalitesini sorgular. Belge alındı, ama gerçekten soruyla ilgili mi? Bilgi güncel mi? Kaynaklar çelişiyor mu? Yetersiz bulunması durumunda döngü yeniden başlar ve Retriever farklı bir yöne çekilir.

Synthesizer, tüm adımların bulgularını bir araya getirerek nihai yanıtı üretir. Bunun yanı sıra, üretilen yanıtın kaynaklarla tutarlılığını denetler ve halüsinasyon riskini retrieval günlüğüne bakarak baskılar.

Bu dört bileşenin oluşturduğu döngü, farklı uygulama modellerinde farklı biçimler alıyor.

Uygulama Modelleri: ReAct, FLARE, CRAG ve Plan-and-Execute

ReAct (Reason + Act): Her adımda model önce bir düşünce (Thought) yazar, ardından bir araç çağırır (Action), sonucu okur (Observation) ve döngüyü sürdürür. Basit ama güçlü bu yapı, CoT ile araç kullanımını tek bir formatta birleştirir. LangChain ve LlamaIndex’in varsayılan agent formatı ReAct’a dayanır.

FLARE (Forward-Looking Active Retrieval): Model metin üretirken güvenilirliği düşük tokenlarla karşılaştığında retrieval başlatır. Yüksek entropili noktalar belirsizliğin işareti olarak yorumlanır; bu noktalarda dış kaynaklara başvurulur. Üretim kalitesi odaklı uygulamalar için farklı bir denge kurar.

CRAG (Corrective RAG): Retrieval sonucunu önce bir değerlendirme modeli (genellikle küçük bir classifier) filtreler. Alınan belge düşük kaliteliyse web aramasıyla güncelleme yapılır. Latency ile kalite arasındaki denge FLARE’e kıyasla farklı bir noktada konumlanır.

Plan-and-Execute: Planner önce tüm görevi adım adım planlar, ardından executor her adımı sırasıyla çalıştırır. Uzun araştırma görevleri ve rapor üretimi için tercih edilebilir; adımlar arası bağımlılıklar bu yapıda daha açık biçimde ifade edilir.

Klasik RAG ile Agentic RAG: Karşılaştırmalı Tablo

Bu karşılaştırma, Agentic RAG’in her zaman daha iyi olduğu anlamına gelmiyor. Latency öncelikli gerçek zamanlı uygulamalarda, sabit ve iyi tanımlı soru setlerinde ya da bütçe kısıtlı deployment’larda klasik RAG hâlâ doğru tercih olabilir. Her LLM çağrısı gecikme ekler; 3-5 adımlı bir döngü 10-30 saniyelik yanıt sürelerine ulaşabilir, token tüketimi artar ve deterministik olmayan çıktılar benchmark değerlendirmesini güçleştirir. Buna karşılık reasoning trace görünür olduğundan hata ayıklamak kolaylaşır ve Critic döngüsü halüsinasyon oranını aşağı çeker.

Fine-tuning ile karşılaştırıldığında ise ayrım şudur: Fine-tuning, modele kalıcı davranış ve alan uzmanlığı kazandırır ama güncelleme maliyetlidir. Agentic RAG, bilgiyi model ağırlıklarına değil dış kaynaklara bırakır ve retrieval sürecini dinamik tutar. İkisi birbirinin alternatifi değil, tamamlayıcısıdır: fine-tuned bir model, Agentic RAG pipeline’ının Critic katmanında değerlendirici olarak kullanılabilir.

Akıl yürüten AI modelleri ile olan örtüşme de dikkat çekici: o3 ve DeepSeek-R1 gibi reasoning modelleri, Planner ve Critic rollerini daha güvenilir biçimde üstlenebiliyor; bu da Agentic RAG pipeline’larının doğruluk tavanını yükseltiyor.

Multimodal Agentic RAG

Agentic RAG’in güçlü yönleri, multimodal RAG ile birleştiğinde genişler. Agent yalnızca metin belgelerini değil, PDF sayfalarını, tabloları ve görselleri de retrieval kapsamına alabilir. Bu entegrasyon özellikle iki senaryoda kritik önem taşır:

Karışık doküman tabanları: Şirket bilgi bankasında hem teknik belgeler hem görsel sunumlar hem de yapılandırılmış veri sayfaları varsa, agent her modalite için uygun retrieval aracını seçer ve sonuçları tek bir bağlamda birleştirir.

Vizüel doğrulama döngüsü: Critic katmanı, metin yanıtının destekleyici bir diyagram veya grafikteki verilerle çelişip çelişmediğini kontrol edebilir. Bu, halüsinasyon tespitini anlamsal metin ötesine taşır.

Python Örneği: LangGraph ile Minimal Agentic RAG

Aşağıdaki kod, LangGraph’ın StateGraph API’siyle planner → retriever → critic döngüsünü kuran minimal bir uygulama:

from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage
from typing import TypedDict, List

class AgentState(TypedDict):
    question: str
    sub_queries: List[str]
    retrieved_docs: List[str]
    quality_ok: bool
    answer: str

llm = ChatOpenAI(model="gpt-4o", temperature=0)

def planner(state: AgentState) -> AgentState:
    resp = llm.invoke([HumanMessage(content=
        f"Bu soruyu alt sorgulara böl: {state['question']}\n"
        "Her satıra bir sorgu yaz."
    )])
    state["sub_queries"] = [l for l in resp.content.strip().split("\n") if l]
    return state

def retriever(state: AgentState) -> AgentState:
    # Gerçek uygulamada burada vector store çağrısı yapılır
    docs = []
    for q in state["sub_queries"]:
        docs.append(f"[Belge: {q}]")
    state["retrieved_docs"] = docs
    return state

def critic(state: AgentState) -> AgentState:
    resp = llm.invoke([HumanMessage(content=
        f"Soru: {state['question']}\nBelgeler: {state['retrieved_docs']}\n"
        "Belgeler soruyu yanıtlamak için yeterli mi? Sadece EVET veya HAYIR yaz."
    )])
    state["quality_ok"] = "EVET" in resp.content.upper()
    return state

def synthesizer(state: AgentState) -> AgentState:
    resp = llm.invoke([HumanMessage(content=
        f"Soru: {state['question']}\nKaynaklar: {state['retrieved_docs']}\n"
        "Kapsamlı bir yanıt üret."
    )])
    state["answer"] = resp.content
    return state

def should_retry(state: AgentState) -> str:
    return "synthesizer" if state["quality_ok"] else "retriever"

graph = StateGraph(AgentState)
graph.add_node("planner", planner)
graph.add_node("retriever", retriever)
graph.add_node("critic", critic)
graph.add_node("synthesizer", synthesizer)

graph.set_entry_point("planner")
graph.add_edge("planner", "retriever")
graph.add_edge("retriever", "critic")
graph.add_conditional_edges("critic", should_retry)
graph.add_edge("synthesizer", END)

app = graph.compile()
result = app.invoke({
    "question": "2024'te en çok kullanılan LLM framework'leri hangileri?"
})
print(result["answer"])

Önemli bir nokta: add_conditional_edges("critic", should_retry) satırı, Critic “HAYIR” dönerse sistemi yeniden retriever’a yönlendirir. max_iterations sınırı olmadan çalışan bu döngü production ortamında sonsuz döngüye girebilir; LangGraph’ın recursion_limit parametresini mutlaka ayarlayın.

Gerçek Dünya Kullanım Alanları

Latency maliyeti kabul edilebilir olduğunda Agentic RAG’in doğruluk artışı en net şu alanlarda görünüyor:

Hukuki araştırma: Bir dava için birden fazla içtihat, yönetmelik ve sözleşme belgesinin taranması gerekir. Her belge bir öncekinin bulgusunu bağlamlandırıyor olduğunda tek turlu retrieval yetersiz kalır; Agentic bir pipeline her bulguyu bir sonraki sorguya girdi olarak kullanabilir.

Müşteri destek sistemleri: Ticket geçmişi, bilgi bankası ve CRM kayıtlarının aynı anda sorgulanması. Müşterinin geçmiş şikayetleri, aktif aboneliği ve ürün versiyonu bir arada değerlendirildiğinde daha isabetli yanıtlar üretilir.

Kod asistanı: Dokümantasyon, kaynak kodu ve issue tracker üçlüsünü kapsayan araştırma. “Bu fonksiyon neden deprecated edildi ve alternatifi nerede?” sorusu tek seferlik retrieval ile yanıtlanamaz; Agentic yaklaşım her kaynağa ayrı bir alt sorgu atar.

Akademik araştırma: Çok kaynaklı literatür taraması. Aranan kavram farklı makalelerde farklı terminolojiyle geçiyorsa, model sinonim sorgular üreterek kapsamı genişletebilir ve ilgisiz sonuçları Critic döngüsüyle eleyebilir.

Framework Seçimi ve Başlangıç Noktası

AI agent framework karşılaştırmasında ele alınan araçların büyük bölümü Agentic RAG senaryolarını doğrudan destekliyor:

LangGraph döngü ve durum yönetiminde güçlüdür. StateGraph API ile planner → retriever → critic → synthesizer döngüsünü add_conditional_edges ile kurmak birkaç düzine satır kod alır. recursion_limit parametresi sonsuz döngü riskini ortadan kaldırır.

LlamaIndex çok kaynaklı indexleme ve SubQuestionQueryEngine ile soruyu otomatik alt sorgulara böler. AgentRunner ve RouterQueryEngine, kaynak yönlendirmesini az boilerplate ile halleder. RAG odaklı uygulamalarda tercih edilen ekosistem.

CrewAI multi-agent senaryolarında öne çıkar: farklı kaynaklardan sorumlu bağımsız agent’lar paralel retrieval yapar, merkezi bir synthesizer agent sonuçları birleştirir.

Haystack ise Pipeline API ile modüler yapı sunuyor: Retriever → Reader → Evaluator zinciri az kod ile kurulabiliyor ve enterprise uygulamalarda sıkça tercih ediliyor.

Başlangıç için öneri: Mevcut vector store altyapınızı ve embedding modelinizi değiştirmeden, LangGraph’ta minimal bir ReAct döngüsüyle deneyin. Critic için başlangıçta embedding benzerlik skoru eşiği yeterlidir; karmaşık doğal dil değerlendirmesi sonraki aşamaya bırakılabilir. Asıl yatırım, Planner ve Critic prompt’larını görev alanına göre kalibre etmektir: genel amaçlı bir “yeterli mi?” sorusu, domain-specific bağlamlarda tutarsız değerlendirmeler üretebilir.

Ne Zaman Agentic, Ne Zaman Klasik RAG?

Klasik RAG yeterli:

• Sorular tek adımda yanıtlanabiliyorsa (ürün fiyatı, tarih, basit lookup)
• Gerçek zamanlı düşük latency gerekiyorsa
• Kaynak tabanı homojen ve iyi tanımlıysa (tek formatlı belgeler)
• Token bütçesi sıkıysa

Agentic RAG değer katıyor:

• Sorular birden fazla kaynağı gerektiriyorsa
• Retrieval sonuçlarının doğrulanması kritikse (hukuk, tıp, finans)
• Karmaşık analiz veya raporlama yapılıyorsa
• Bilgi dinamik ve sık güncellenen bir alanda yer alıyorsa

Kararı netleştiren pratik bir test: Aynı soruyu deneyimli bir araştırmacıya sorsanız, tek kaynağa tek bakışla mı yanıtlardı, yoksa birden fazla yere bakıp bulgularını doğrular mıydı? İkincisi geçerliyse Agentic RAG doğru yöndür.

Agentic RAG, klasik RAG mimarisinin zayıf noktalarını — tek turlu retrieval, sabit kaynak yapısı ve öz-değerlendirme eksikliği — doğrudan hedef alır. Sorgu yeniden yazma, araç seçimi ve iteratif retrieval döngüsü bir arada çalıştığında, karmaşık ve çok boyutlu sorgularda doğruluk artışı belirginleşir. Başlangıç maliyeti gerçektir; ama mevcut altyapıyı koruyarak adım adım geçiş yapılabilir ve Critic katmanı basit tutularak erken değer elde edilebilir.