Agentic RAG Nedir? Dinamik Çok Adımlı Retrieval

Klasik RAG sistemi bir soruyu alır, ilgili belgeleri vector store’dan çeker ve LLM’e tek seferde iletir. Bu yaklaşım pek çok durumda gayet iyi çalışır. Ama bazı sorular doğası gereği tek adıma sığmaz: “2024’te hangi şirketler bu teknolojiyi benimsedi ve ardından rakipleri ne yaptı?” Böyle bir soruyu tek bir retrieval döngüsüyle yanıtlamak güçtür; çünkü cevabın parçaları birbirini gerektirir.

Agentic RAG, LLM agent’larını iteratif retrieval mekanizmalarıyla birleştirerek bu boşluğu kapatır. Model, bir bilgi talep edince durmuş beklemek yerine hangi kaynağı sorgulayacağına, alınan bilginin yeterli olup olmadığına ve gerekiyorsa döngüyü yeniden başlatıp başlatmayacağına kendisi karar verir. 2026 itibarıyla LangChain, LlamaIndex ve CrewAI ekosistemlerinde en çok tartışılan mimari buraya dayanıyor.

Agentic RAG Nedir?

Agentic RAG, retrieval sürecini pasif bir adım olmaktan çıkarıp LLM’in aktif olarak yönettiği bir döngüye dönüştürür. Klasik RAG’de akış bellidir: soru gelir, embedding hesaplanır, en yakın belgeler çekilir, model yanıt üretir. Agentic versiyonda model bir araç kullanıcısına (tool user) dönüşür ve şu kararları kendisi verir:

• Hangi kaynağa git? (vector store, web araması, SQL, harici API)
• Şimdiye kadar toplananlar yeterli mi?
• Sonraki adımda hangi soruyu sor?

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

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 kalitesini bir Critic katmanıyla denetler; yetersiz bulursa yeni retrieval döngüsü açar.
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 olarak gider.

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.

Klasik RAG ile Karşılaştırma

Fark belirgin: Agentic RAG karmaşıklığı ve latency’yi artırır, buna karşılık çok adımlı sorgularda doğruluğu yukarı çeker. Standart Q&A senaryoları ve tek turlu bilgi sorgularında klasik RAG bu maliyeti haklı kılmayabilir. Seçim, kullanım senaryosunun doğasına göre yapılmalı.

Agentic RAG Mimarisi

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. Bu adım, prompt engineering perspektifinden bakıldığında 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? Farklı kaynaklardan gelen bilgiler çelişiyor mu? Critic bu kontrolleri çalıştırır; yetersiz bulmak 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 birlikte oluşturduğu döngü, farklı uygulama modellerinde farklı biçimler alıyor.

Uygulama Modelleri

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.

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.

Daha kısa bir LCEL alternatifi tercih ediyorsanız:

from langchain_core.runnables import RunnableLambda, RunnablePassthrough

chain = (
    RunnablePassthrough()
    | RunnableLambda(planner)
    | RunnableLambda(retriever)
    | RunnableLambda(critic)
    | RunnableLambda(synthesizer)
)

Bu format döngü içermiyor; basit pipeline ihtiyaçlarında daha temiz duruyor.

Gerçek Dünya Kullanım Alanları

Latency maliyeti kabul edilebilir olduğunda Agentic RAG’in doğruluk artışı en net hangi 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.

Araçlar ve Ekosistem

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:

LangChain / LangGraph: StateGraph ve LCEL ile esnek döngü tanımı. ReAct formatı yerleşik; çok-kaynaklı araç entegrasyonu için Tool soyutlaması hazır.

LlamaIndex: AgentRunner ve RouterQueryEngine, çok kaynaklı yönlendirmeyi kolaylaştırır. SubQuestionQueryEngine soruyu otomatik alt sorgulara böler; neredeyse sıfır boilerplate.

CrewAI: Multi-agent orchestration senaryolarında Agentic RAG, her agent farklı bir retrieval sorumluluğu üstlenir ve sonuçları merkezi bir synthesizer birleştirir. Paralel retrieval bu yapıda daha kolay organize edilir.

Haystack: Pipeline API ile modüler yapı. Retriever → Reader → Evaluator zinciri az kod ile kurulabiliyor; enterprise uygulamalarda sıkça tercih edilen bir seçenek.

Avantajlar ve Zorluklar

Artılar

• Çok adımlı ve multi-hop sorgularda belirgin doğruluk kazanımı
• Critic döngüsü halüsinasyon oranını aşağı çeker
• Reasoning trace görünür olduğundan hata ayıklamak kolaylaşır
• Farklı kaynak türleri (vector store, web, SQL, harici API) tek pipeline altında toplanır

Eksiler

• 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 ve dolayısıyla maliyet artar
• Döngü koşulları dikkatli ayarlanmazsa sonsuz döngü riski doğar
• Deterministik olmayan çıktılar benchmark değerlendirmesini güçleştirir

Bunların yanı sıra, Critic prompt’ını iş alanına göre kalibre etmek zaman alır. Genel amaçlı bir “yeterli mi?” sorusu, domain-specific bağlamlarda tutarsız değerlendirmeler üretebilir.

Ne Zaman Klasik RAG, Ne Zaman Agentic RAG?

Bu sorunun yanıtı büyük ölçüde kullanım senaryosunun karmaşıklığına bağlı.

Klasik RAG tercih edin:

• Sorular tek adımda yanıtlanabiliyorsa (ürün adı, fiyat, tarih gibi lookup sorgular)
• Düşük latency birincil öncelikliyse (gerçek zamanlı chatbot uygulamaları)
• Bütçe kısıtlıysa ve token maliyeti belirleyiciyse

Agentic RAG tercih edin:

• Sorular birden fazla kaynağa veya adıma ihtiyaç duyuyorsa
• Araştırma, rapor üretimi veya karmaşık analiz yapılıyorsa
• Öz-düzeltme ve yüksek doğruluk birincil öncelikliyse

Fine-tuning ile karşılaştırıldığında Agentic RAG, güncel ve değişken bilgi gerektiren görevlerde öne çıkar. Fine-tuning ise modele kalıcı bir davranış ya da alan uzmanlığı kazandırmak istediğinizde devreye girer. İkisi birbirinin alternatifi değil, tamamlayıcısıdır: bazı sistemlerde fine-tuned bir model, Agentic RAG pipeline’ının Critic katmanında değerlendirici olarak kullanılır.

Aklını 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.

Nereden Başlamalı?

Mevcut bir klasik RAG sistemini Agentic yapıya taşımak için en az riskli yol, önce tek bir ReAct döngüsü denemesidir. LangGraph’ta birkaç node ve conditional edge yeterli; halihazırda kullandığınız vector store ve embedding altyapısı değişmez.

Critic katmanı başta basit tutulabilir: relevance score için bir eşik değeri bile tek başına mevcut sisteme kıyasla doğruluğu yukarı taşır. Asıl yatırım, Planner ve Critic prompt’larını görev alanına göre kalibre etmektir. Embedding modelleri ve retrieval kalitesi üzerine sağlam bir temel varsa bu geçişin teknik maliyeti çok daha düşük olacak.

Latency kabul edilebilir, bütçe müsait ve soru setiniz gerçekten çok adımlıysa Agentic RAG, klasik bir pipeline’ın açığını kapatır. Değilse klasik RAG genellikle daha pragmatik bir tercih olmayı sürdürür.