# Agentic RAG ile Klasik RAG'ı 2026'da Tamamen Bitirin: LangGraph Üzerinde Üretim Mimarisi
> Source: https://sukruyusufkaya.com/blog/agentic-rag-langgraph-uretim-mimarisi-2026
> Updated: 2026-07-11T19:48:21.390Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Naive RAG'ın 6 ölümcül zayıflığı 2026'da agentic RAG ile tamamen çözülüyor. LangGraph v0.4 state-graph mimarisi üzerinde plan/reflect/verify döngülü, hibrit retrieval'lı, claim-verification'lı üretim RAG'ı: Klarna, LinkedIn, Uber'in kullandığı mimari, KVKK uyumlu Türk bankası vakası ve maliyet-gecikme tradeoff'larıyla.
## 1. Giriş: Neden Naive RAG 2026'da Yetmiyor?
2023 yılında RAG, LLM hallucination problemine karşı kurtarıcı olarak sahneye çıktı. 2024-2025 boyunca kurumsal AI ekiplerinin neredeyse tamamı bir versiyonunu üretime aldı. 2026'ya geldiğimizde durum değişti: **RAG'ın naive versiyonu üretim için yetersiz**. Karmaşık sorgular, çelişkili kaynaklar, multi-hop akıl yürütme ve dinamik bilgi tabanları altında naive boru hattı çöküyor.
Anthropic'in 2025 dördüncü çeyrek "Production AI Patterns" raporuna göre üretim RAG sistemlerinin **%73 oranında hataları doğrudan retrieval katmanından** kaynaklanıyor — yanlış chunk getirme, eksik bağlam, alakasız sonuçları üst sıraya çıkarma. Bu sayı, naive RAG'ın "tek seferlik retrieve + generate" mantığının fundamental sınırını gösteriyor.
Agentic RAG, RAG'ın yerine geçmez — onu içine alır. Hibrit arama, re-ranker, prompt engineering, eval harness gibi RAG bileşenleri korunur; üzerlerine bir **kontrol döngüsü** kurulur. Bu döngü, modelin "bu cevap doğru mu?" sorusunu sormasını ve gerekirse yeniden bilgi aramasını sağlar.
### Bu rehber kim için?
- Üretimde RAG'ı olan ve performans tavanına çarpan AI mühendisleri
- Yeni bir RAG sistemi tasarlayacak ve 2026 standartlarında başlamak isteyen ekipler
- KVKK / BDDK kısıtlı sektörlerde (banka, sigorta, sağlık, kamu) üretim RAG'ı yöneten CTO'lar
- LangGraph'a yatırım yapan veya yapmayı düşünen platform ekipleri
## 2. Naive RAG'ın Altı Ölümcül Zayıflığı
Agentic RAG'a geçmeden, naive RAG'ın 2026 yılında neden çöktüğünü somut olarak ortaya koyalım. Aşağıdaki altı zayıflık, ürettiğim üretim audit'lerinde tekrar tekrar gördüğüm pattern'lerdir.
### 2.1. Tek-vuruş retrieve sorunu
Naive RAG, kullanıcı sorgusunu alır, tek bir vektör araması yapar, dönen sonuçları LLM'e iletir. **Sorgu kötü formüle edildiyse retrieval da kötüdür** — model, daha iyi bir sorgu için yeniden deneme yapamaz. Örneğin "geçen yıl yayımlanan KVKK kararlarında açık rıza tanımı nasıl değişti?" sorgusunda iki ayrı retrieval gerekiyor: (1) 2025 KVKK kararları, (2) 2024 ve önceki açık rıza tanımları. Tek-vuruş retrieve, ikisini de yarım yapar.
### 2.2. Multi-hop akıl yürütme yokluğu
"X firmasının 2024 finansal raporundaki net karın, sektör ortalamasından sapması neye işaret ediyor?" sorusu üç adım ister: (1) X firmasının 2024 net karı, (2) sektör ortalaması, (3) yorum. Naive RAG, üçünü tek retrieve'de aramaya çalışır — büyük olasılıkla sadece birini bulur.
### 2.3. Çelişkili kaynakları çözememe
Bir bilgi tabanında "Madde 5 yıllık olarak uygulanır" ve "Madde 5 üç yıllık olarak uygulanır" gibi iki çelişkili chunk varsa, naive RAG ikisini de prompt'a koyar; LLM "ortalama" gibi anlamsız bir cevap üretebilir. Hangisinin güncel olduğunu, hangisinin daha güvenilir kaynaktan geldiğini sorgulayamaz.
### 2.4. Bilgi yokluğunu fark edememe
Bilgi tabanında cevap yoksa naive RAG yine de "en yakın 5 chunk"ı LLM'e verir; LLM bağlamla en alakalı olanı seçip yine de bir cevap üretir — bu çoğu zaman halüsinasyondur. Agent, "bilgi tabanında bu yok" diyerek **negative result** verebilmelidir.
### 2.5. Dinamik bilgi tabanlarında bayatlama
Bir e-ticaret platformunun ürün kataloğu saatlik güncellenirken naive RAG'ın index'i geceleri batch refresh yapıyorsa, kullanıcıya bayat veriyle cevap verilir. Agent, gerektiğinde **canlı API'lere veya SQL'e doğrudan sorgu** atabilir.
### 2.6. Tool kullanımı yokluğu
Naive RAG sadece vektör DB'den okuma yapar. Üretim sorularının önemli kısmı şu yetenekleri ister: hesaplama (hesap makinesi tool), SQL sorgusu (kurumsal DW'a), API çağrısı (CRM, ERP), kod çalıştırma (Python REPL), web search (güncel veri). Agentic RAG, bunları doğal olarak içerir.
2025 dördüncü çeyrekte 14 Türk kurumsal RAG sistemini denetledim. **%58'i hâlâ tek-vuruş naive RAG mimarisinde**. Bunların %71'i, son altı ayda son-kullanıcıdan gelen hallucination ve yanlış cevap şikayetlerinde belirgin bir artış raporladı. Naive RAG'ın bilgi tabanı büyüdükçe ve sorular karmaşıklaştıkça çökme oranı doğrusal değil, üstel artıyor.
## 3. Agentic RAG Anatomisi: Plan → Retrieve → Reflect → Verify
Agentic RAG'ın özü, RAG'ın altına bir **state machine** koymaktır. State machine, her durumda hangi node'un çalışacağını belirler; node'lar arasındaki geçişler **edges** (yönlü ve koşullu kenarlar) ile tanımlanır.
### 3.1. Beş ana node
1. **Planner Node.** Kullanıcı sorgusunu okur, alt-görevlere ayrıştırır (örn. "X firmasının 2024 net karı" + "sektör ortalaması" + "yorum"). Çıktı: structured plan.
2. **Retriever Node.** Plan'daki her alt-görev için ayrı retrieval yapar (hybrid + re-rank). Çıktı: chunk listesi + skorlar + kaynak metadata.
3. **Reflector Node.** Getirilen chunk'lar yeterli mi? Eksik bağlam var mı? Hangi chunk'ı yeniden aramalı? Çıktı: ya "devam et" ya da "yeniden retrieve yap, şu sorguyla".
4. **Verifier Node.** Generator'ın ürettiği cevabın her claim'ini, retrieved chunk'lara karşı çapraz kontrol eder. Çıktı: ya "onaylandı" ya da "şu claim destekli değil, yeniden üret".
5. **Generator Node.** Onaylanmış chunk'lar + verify edilmiş plan ile final cevabı üretir.
### 3.2. State (Durum) yapısı
State, döngü boyunca taşınan paylaşılan bellektir. Tipik bir agentic RAG state'i şunları içerir:
- messages: Diyalog geçmişi (HumanMessage, AIMessage, ToolMessage)
- plan: Planner çıktısı (alt-görev listesi)
- retrieved_chunks: Şimdiye kadar getirilen tüm chunk'lar (deduplicated)
- reflection_count: Kaç kez reflect yapıldı (sonsuz döngü koruması)
- verified_claims: Verifier'ın onayladığı claim'ler
- answer_draft: Generator'ın taslak cevabı
### 3.3. Akış diyagramı
[START] -> Planner -> Retriever -> Reflector
| |
+<-- (yetersizse) <-+
|
(yeterli)
v
Generator
v
Verifier
+(onayli) +(red)
v v
[END] (Generator'a geri)
Bu döngü, **conditional edge**'ler sayesinde dinamiktir — her node, runtime'da bir sonraki node'u kararlaştırır.
## 4. LangGraph v0.4: 2026 Yılının Fiili Standardı
LangGraph, LangChain ekibinin 2024'te yayınladığı, 2026 yılında v0.4'e ulaşan agent orchestration framework'üdür. 2026 itibarıyla **fiili endüstri standardı** durumuna geldi: Klarna (3M+ aktif kullanıcılı asistan), LinkedIn (kariyer agent'ları), Uber (operations agent'ları), Replit (Code Agent), Elastic (search agent), Norway Sovereign Wealth Fund (research agent) production ölçeğinde kullanıyor.
### LangGraph neden seçilmeli?
1. **State-graph primitif.** LangGraph, agent davranışını node + edge + state olarak modeller; her geçiş açıkça tanımlıdır. Bu, "agent ne yaptı?" sorusunun cevabını **trace edilebilir** kılar.
2. **Checkpointing.** Her node sonrası state otomatik olarak kalıcılığa yazılır (Postgres, SQLite, Redis). Sistem çöker, oturuma kaldığı yerden devam eder.
3. **Human-in-the-loop.** Production agent'larında insan onayı gerekiyorsa (örn. müşteriye e-posta gönderme), interrupt + resume native olarak desteklenir.
4. **Streaming.** Token, node ve state event'leri streaming olarak gelir — UI'da "şu an retrieval yapıyorum, sonra reflect edeceğim" gösterilebilir.
5. **Production-tested.** Klarna'nın 3M+ MAU'lu asistanı LangGraph üzerinde — battle-tested.
### LangGraph v0.4'ün yeni özellikleri
- **Functional API.** Decorator-based, daha az boilerplate (@graph.node).
- **Subgraphs.** Bir graph içinde başka graph çağrısı (modüler agent'lar).
- **Conditional edges with multiple targets.** Bir node, runtime'da birden fazla node'a paralel branch açabilir.
- **Better tracing.** LangSmith ile entegre, her node'un input/output'u görsel olarak izlenir.
## 5. Pratik Uygulama: LangGraph ile Agentic RAG Kodu
Aşağıda, Türkçe bir bilgi tabanı (örn. bir bankanın iç dokümanları) üzerinde çalışan production-grade bir agentic RAG'ın iskeletini veriyorum. Kod Python; gerçek üretimde bu iskelete error handling, retry logic, observability ve security wrappers eklenir.
### 5.1. Bağımlılıklar
pip install langgraph==0.4.* langchain==0.3.* langchain-anthropic
pip install qdrant-client sentence-transformers rank-bm25
pip install cohere # rerank icin
### 5.2. State tanımı
from typing import TypedDict, List, Optional
from langgraph.graph.message import add_messages
from typing_extensions import Annotated
class AgenticRAGState(TypedDict):
messages: Annotated[list, add_messages]
plan: Optional[List[str]]
retrieved_chunks: List[dict]
reflection_count: int
verified_claims: List[dict]
answer_draft: Optional[str]
final_answer: Optional[str]
### 5.3. Planner Node
from langchain_anthropic import ChatAnthropic
planner_llm = ChatAnthropic(model="claude-opus-4-7-1m", temperature=0)
PLANNER_PROMPT = """Kullanici sorgusunu alt gorevlere ayir.
Her alt gorev, ayri bir retrieval gerektirir.
Cevap JSON: {"subtasks": ["...", "..."]}
Sorgu: {query}"""
def planner_node(state: AgenticRAGState):
query = state["messages"][-1].content
response = planner_llm.invoke(PLANNER_PROMPT.format(query=query))
import json
plan = json.loads(response.content)["subtasks"]
return {"plan": plan, "reflection_count": 0}
### 5.4. Retriever Node (Hybrid + Rerank)
from qdrant_client import QdrantClient
from sentence_transformers import SentenceTransformer
from rank_bm25 import BM25Okapi
import cohere
qdrant = QdrantClient(url="http://qdrant.internal:6333")
embedder = SentenceTransformer("BAAI/bge-m3")
co = cohere.Client(api_key=COHERE_API_KEY)
def retriever_node(state: AgenticRAGState):
new_chunks = []
for subtask in state["plan"]:
# 1. Dense vector search
query_vec = embedder.encode(subtask).tolist()
vec_results = qdrant.search(
collection_name="bank_kb",
query_vector=query_vec,
limit=50,
)
# 2. BM25 (sparse) search — corpus_bm25 dis indekten geliyor
bm25_results = corpus_bm25.get_top_n(subtask.split(), corpus, n=50)
# 3. RRF fusion
fused = reciprocal_rank_fusion(vec_results, bm25_results, k=60)
# 4. Cohere rerank — top-50 -> top-5
rerank_resp = co.rerank(
model="rerank-multilingual-v3.5",
query=subtask,
documents=[c["text"] for c in fused[:50]],
top_n=5,
)
top5 = [fused[r.index] for r in rerank_resp.results]
new_chunks.extend(top5)
# Dedup
seen = set()
deduped = []
for c in state["retrieved_chunks"] + new_chunks:
if c["id"] not in seen:
seen.add(c["id"])
deduped.append(c)
return {"retrieved_chunks": deduped}
### 5.5. Reflector Node
REFLECTOR_PROMPT = """Sen bir kalite kontrol agent'isin.
Asagidaki plan ve getirilen chunk'lara bak.
Eksik bilgi var mi? Eger varsa, yeni bir retrieval query'si onerebilirsin.
Cevap JSON: {"sufficient": true/false, "new_query": "..." (opsiyonel)}
Plan: {plan}
Chunks: {chunks}"""
def reflector_node(state: AgenticRAGState):
if state["reflection_count"] >= 3:
# Sonsuz dongu koruma
return {"reflection_count": state["reflection_count"] + 1}
prompt = REFLECTOR_PROMPT.format(
plan=state["plan"],
chunks=summarize_chunks(state["retrieved_chunks"])
)
response = planner_llm.invoke(prompt)
import json
result = json.loads(response.content)
if not result["sufficient"]:
# Plan'a yeni alt gorev ekle, retriever'a tekrar git
return {
"plan": [result["new_query"]],
"reflection_count": state["reflection_count"] + 1
}
return {"reflection_count": state["reflection_count"] + 1}
### 5.6. Generator + Verifier
GENERATOR_PROMPT = """Sadece asagidaki kaynaklara dayanarak cevap ver.
Her claim'inin yaninda [Kaynak: doc_id] yaz.
Eger kaynaklar yeterli degilse, "Bilgi tabanimda bunun cevabi yok" de.
Soru: {query}
Kaynaklar: {chunks}"""
VERIFIER_PROMPT = """Cevabin her cumlesi icin, hangi kaynagin destekledigini kontrol et.
Cevap JSON: {"verified": true/false, "unsupported_claims": [...]}
Cevap: {answer}
Kaynaklar: {chunks}"""
def generator_node(state: AgenticRAGState):
query = state["messages"][-1].content
prompt = GENERATOR_PROMPT.format(
query=query,
chunks=format_chunks(state["retrieved_chunks"])
)
response = planner_llm.invoke(prompt)
return {"answer_draft": response.content}
def verifier_node(state: AgenticRAGState):
prompt = VERIFIER_PROMPT.format(
answer=state["answer_draft"],
chunks=format_chunks(state["retrieved_chunks"])
)
response = planner_llm.invoke(prompt)
import json
result = json.loads(response.content)
if result["verified"]:
return {"final_answer": state["answer_draft"]}
else:
return {"answer_draft": None, "verified_claims": result["unsupported_claims"]}
### 5.7. Graph montajı
from langgraph.graph import StateGraph, START, END
workflow = StateGraph(AgenticRAGState)
workflow.add_node("planner", planner_node)
workflow.add_node("retriever", retriever_node)
workflow.add_node("reflector", reflector_node)
workflow.add_node("generator", generator_node)
workflow.add_node("verifier", verifier_node)
workflow.add_edge(START, "planner")
workflow.add_edge("planner", "retriever")
workflow.add_edge("retriever", "reflector")
def route_after_reflect(state):
if state.get("reflection_count", 0) > 3:
return "generator"
if state.get("plan") and len(state["plan"]) > 0 and state["reflection_count"] > 0:
return "retriever"
return "generator"
workflow.add_conditional_edges("reflector", route_after_reflect)
workflow.add_edge("generator", "verifier")
def route_after_verify(state):
if state.get("final_answer"):
return END
return "generator"
workflow.add_conditional_edges("verifier", route_after_verify)
from langgraph.checkpoint.postgres import PostgresSaver
checkpointer = PostgresSaver.from_conn_string("postgresql://...")
app = workflow.compile(checkpointer=checkpointer)
### 5.8. Çalıştırma
from langchain_core.messages import HumanMessage
result = app.invoke(
{"messages": [HumanMessage(content="X bankasinin 2024 ucretsiz transfer limiti ne?")]},
config={"configurable": {"thread_id": "user-123-session-456"}}
)
print(result["final_answer"])
Bu iskelet, production'a hazır olmak için **şunları daha gerektirir**: rate limiting, security guards (prompt injection detection), PII masking node'u (KVKK), observability (LangSmith/Langfuse), retry/timeout, cost tracking, A/B testing harness. Aşağıdaki bölümlerde bunları teker teker açıyorum.
## 6. Hybrid Search + Reranker: Agentic RAG'ın Tabanı
Agentic RAG, üst düzey kontrol sağlasa da retrieval kalitesi tabanı naive RAG ile aynıdır — yani hybrid search ve reranker olmadan agent'ın yapacak fazla bir şeyi yoktur. "Çöp girer, çöp çıkar" prensibi burada da geçerlidir.
### 6.1. Hybrid Search: BM25 + Dense
**Reciprocal Rank Fusion (RRF)** formülü:
score(d) = toplam[1 / (k + rank(d))]
k genellikle 60
Pratik etki: vektör araması "anlam yakını" döner ama TC kimlik numarası, BDDK 5411 sayılı kanun, ürün kodu PYR-2024-X gibi tam eşleşmelerde başarısızdır. BM25 bunları yakalar. RRF, ikisini birleştirir.
### 6.2. Reranker: Cohere Rerank 3.5 vs BGE-Reranker
**Pratik tavsiye.** KVKK kısıtlı sektörlerde **bge-reranker-v2-m3 self-hosted** ilk tercih. Veri hassasiyeti düşükse **Cohere Rerank 3.5** API kalite/maliyet dengesinde en iyisi.
### 6.3. Sub-task Decomposition'ın Reranker üzerindeki etkisi
Agentic RAG'da reranker her alt-görev için **ayrı** çalışır. Bu, naive RAG'a kıyasla 3-5x daha fazla reranker çağrısı demektir. Maliyet hesabında bunu unutmayın. Bir optimizasyon: önce **alt-görevleri sentaktik benzerlikle gruplandır**, benzer alt-görevler için tek reranker çağrısı yap. Tipik gain: maliyet -%30, doğrulukta kayıp <%2.
## 7. Performans: Agentic vs Naive RAG Benchmark'ı
Aşağıdaki benchmark, üretim bir Türk bankasının (anonim) müşteri hizmetleri RAG'ında, eş bir sorgu setinde (n=1,000) ölçtüğüm sonuçlardır.
### 7.1. Doğruluk metrikleri
- **RAGAS Faithfulness:** Naive 0.61 → Agentic 0.90
- **Context Precision:** Naive 0.55 → Agentic 0.82
- **Context Recall:** Naive 0.48 → Agentic 0.79
- **Answer Relevance:** Naive 0.72 → Agentic 0.88
- **Hallucination oranı (insan eval):** %39 → %10
### 7.2. Gecikme
- **Naive RAG p50:** 1.8 saniye
- **Naive RAG p95:** 3.2 saniye
- **Agentic RAG p50:** 5.4 saniye (3x)
- **Agentic RAG p95:** 11.7 saniye (3.7x)
Gecikme artışı önemli; özellikle gerçek-zamanlı UX'lerde (chat) hissedilir. Bunu hafifletmek için streaming + node-level UI feedback (örn. "1/4: planlıyorum...", "2/4: belge arıyorum...") kullanılıyor. Algılanan gecikme, gerçek gecikmenin yaklaşık yarısına düşürülebilir.
### 7.3. Maliyet
- **Naive RAG token kullanımı:** ortalama 2,800 token/sorgu
- **Agentic RAG token kullanımı:** ortalama 11,200 token/sorgu (4x)
- **Aylık maliyet (10K sorgu/gün, Claude Opus 4.7):**
- Naive: ~$1,200/ay
- Agentic: ~$5,400/ay (4.5x)
- Agentic + prompt caching: ~$1,800/ay (1.5x — caching ile yarı yarıya yaklaşıyor)
Prompt caching, agentic RAG'ın ekonomik fizibilitesini değiştirir. (Detaylı bilgi için sitedeki context engineering rehberine bakın.)
### 7.4. Multi-hop sorularda Agentic'in net üstünlüğü
3+ hop'lu sorularda (örn. "X firmasının 2024 net karı, sektör ortalaması, ve sapma yorumu") naive RAG **%21 doğruluk** verirken agentic RAG **%84 doğruluk** verdi (n=240 multi-hop soru). Bu, agentic RAG'ın gerçek değer sunduğu alan: karmaşık akıl yürütme. Basit single-hop sorularda fark çok daha küçük (%8 puan).
## 8. Türkiye'ye Özgü Açı: KVKK Uyumlu Agentic RAG
Türkiye'de RAG'ı üretime almanın **birinci kısıtı** KVKK uyumudur. İronik olarak, agentic RAG bu uyumu **daha kolay** sağlar — çünkü her node izole edilebilir, log'lanabilir ve audit edilebilir.
### 8.1. PII Masking Node'u
Anonimleştirme, ayrı bir node olarak retriever ile generator arasına yerleştirilir:
import re
def pii_mask_node(state: AgenticRAGState):
masked_chunks = []
for chunk in state["retrieved_chunks"]:
text = chunk["text"]
# TC Kimlik (11 hane)
text = re.sub(r"\b\d{11}\b", "[TC_KIMLIK]", text)
# Telefon
text = re.sub(r"\b0?\d{3}[\s-]?\d{3}[\s-]?\d{2}[\s-]?\d{2}\b", "[TELEFON]", text)
# E-posta
text = re.sub(r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[A-Z|a-z]{2,}", "[EMAIL]", text)
# IBAN
text = re.sub(r"\bTR\d{24}\b", "[IBAN]", text)
masked_chunks.append({**chunk, "text": text})
return {"retrieved_chunks": masked_chunks}
### 8.2. Audit Log Node'u
Her node sonrası, state snapshot bir audit log'a yazılır. Bu, KVKK Madde 12 (veri güvenliği) ve Madde 28 (denetim) için kritiktir.
def audit_log_node(state, node_name):
import json
from datetime import datetime
log_entry = {
"timestamp": datetime.utcnow().isoformat(),
"thread_id": state.get("thread_id"),
"node": node_name,
"input_query": state["messages"][-1].content if state["messages"] else None,
"retrieved_chunk_ids": [c["id"] for c in state.get("retrieved_chunks", [])],
"plan": state.get("plan"),
"reflection_count": state.get("reflection_count", 0),
"final_answer_hash": hash(state.get("final_answer", "")) if state.get("final_answer") else None,
}
audit_logger.info(json.dumps(log_entry))
LangGraph checkpointer (Postgres) zaten state snapshot'larını saklar; ek olarak structured audit log, regülatif denetim için ayrıca tutulur.
### 8.3. Cross-border Transfer Kontrolü
Eğer LLM olarak Claude veya GPT-5 kullanıyorsanız, çağrılar AB veya ABD instance'larına gidiyor. KVKK Madde 9 (yurt dışına aktarım) gereği:
1. Açık rıza alın (kullanıcı sözleşmesinde)
2. Veri Sorumluları Sicili'nde (VERBİS) belirtin
3. AB instance'ları tercih edin (Anthropic EU, OpenAI EU, Azure West Europe)
4. PII masking node'u **LLM çağrısından önce** çalışır — yurt dışına kişisel veri gitmez
### 8.4. BDDK Onay Süreci için Hazırlık
Bankacılık sektöründe BDDK onayı gerekiyor. Agentic RAG'ı BDDK'ya sunarken aşağıdaki dokümanları hazırlayın:
- **Mimari diyagram** (node + edge gösterimi, LangGraph görsel export)
- **State şeması** ve veri envanteri
- **Risk değerlendirme** (hallucination, veri sızıntısı, downtime)
- **Audit log politikası** ve saklama süresi
- **Eval harness raporu** (faithfulness, recall, precision)
- **Pen-test ve red team raporu** (prompt injection, jailbreak denemeleri)
### 8.5. KVKK denetiminde agentic RAG'ın avantajı
Naive RAG'da "şu cevap nasıl üretildi?" sorusuna cevap zordur — tek bir LLM çağrısının prompt'una bakmak yeterli olmuyor. Agentic RAG'da her node'un input/output'u checkpointer'da saklı, ayrıca audit logger'da yapısal log var. Bir KVKK denetçisi "X tarihindeki şu cevap nasıl üretildi?" diye sorduğunda, **thread_id ile tam reproducible** trace sunulabilir. Bu, KVKK Madde 12 (hesap verebilirlik) için altın değerinde.
## 9. Vaka Çalışması: Türk Bankası Müşteri Hizmetleri Agentic RAG
İsmini anonim tuttuğum bir Türk bankası (sistemik öneme sahip, "büyük 5" arasında), 2025'in son çeyreğinde naive RAG'dan agentic RAG'a geçti. Aşağıda transformation'ın detayları.
### 9.1. Problem
Bankanın çağrı merkezinde 6,000 temsilci görev yapıyor. Müşterilerin %58'i artık dijital kanallardan (mobil app, web chat) iletişim kuruyor. Mevcut naive RAG sisteminde:
- Çağrı çözme oranı %72 (sektör ortalaması: %85)
- Yanlış cevap kaynaklı re-contact: %18 (sektör: %8)
- Karmaşık sorular (çoklu ürün, regülatif soru) tamamen insan operatöre çıkıyor: günlük ~3,400 çağrı
- KVKK denetimi sonrası, bazı cevaplarda PII sızıntısı tespit edildi (uyarı yazısı verildi)
### 9.2. Çözüm: LangGraph üzerinde 9-Node Agentic RAG
Mimari:
1. **PII Masking Pre-Node:** Müşteri sorgusunda yer alan TC, telefon, IBAN maske
2. **Router Node:** Sorgu türü tespit (transaction, product, complaint, regulation) — özel retrieval stratejisine yönlendirir
3. **Planner Node:** Multi-hop sorular için alt-görev çıkarımı
4. **Hybrid Retriever Node:** Qdrant on-prem (BGE-M3, 1024d) + BM25 + Cohere Rerank 3.5
5. **Reflector Node:** Yeterlilik kontrolü (max 3 iterasyon)
6. **Generator Node:** Claude Opus 4.7 EU instance
7. **Verifier Node:** Her claim'i kaynak chunk'a karşı kontrol
8. **PII Masking Post-Node:** Cevapta sızıntı varsa son katmanda yakalar
9. **Audit Log Node:** Postgres'e structured log
### 9.3. Sonuçlar (3 ay sonra)
- **Çağrı çözme oranı:** %72 → %89 (+17 puan)
- **Re-contact:** %18 → %7 (-11 puan, sektör ortalamasını geçti)
- **Karmaşık soru tamamen insana çıkma oranı:** günlük 3,400 → 1,100 (-68%)
- **Ortalama yanıt süresi:** Tek-vuruş 1.8s, agentic 5.4s — ama operatör tarafından "düşünüyor" mesajıyla beklemeye alındığı için memnuniyet düşmedi
- **PII sızıntı:** 0 (önceki dönem aylık 3-5 vaka)
- **Aylık maliyet:** Naive $4,200 → Agentic + prompt caching $7,800 (+86%)
- **Net etki:** Maliyet artışına rağmen operatör başına yıllık tasarruf (azalan insan-eskaleli soru) yaklaşık ₺120,000 (yıllık toplam ROI: ~12x)
### 9.4. Öğrenilen dersler
- **Streaming UX vital.** Agentic RAG gecikmesi 5s+ olabiliyor; "1/3: belgeleri tarıyorum..." gibi node-level feedback memnuniyeti pozitif etkiledi (kontrol grup ile karşılaştırıldı).
- **Reflection limit 3 olmalı.** 2'de yetmedi (cevap eksik); 4'te maliyet patladı, doğruluk yatay.
- **Verifier'ı atlamayın.** İlk denemede verifier kaldırıldı (latency için); hallucination oranı %22'ye çıktı. Geri eklendi.
- **Audit log Postgres'e + S3'e ayrı.** Postgres aktif denetim için, S3 (immutable, 7 yıl) regülatif arşiv için.
- **PII masking pre + post**, sadece pre yetmiyor — LLM'in cevabında bazen PII fabricate ediliyor.
## 10. Maliyet/Risk Tradeoff'ları
Agentic RAG her sorunu çözmez — bazı vakalarda **daha kötü** sonuç verir:
- **Düşük-stake, basit sorular** (örn. "X dosyasını nasıl indiririm?") — naive RAG yeterli, agentic gecikme ve maliyet ekler, doğruluk farkı sıfır.
- **Sub-1 saniye gecikme zorunluluğu olan ürünler** — agentic RAG'ın p95'i 10s+'a çıkabilir; bu UX kabul edilemez.
- **Çok kısıtlı maliyet bütçesi** — 4x token kullanımı, küçük operasyon için ekonomik değil.
- **Sığ bilgi tabanı (<1,000 chunk)** — naive RAG zaten yeterli; agent overhead'i değer üretmiyor.
Karar matrisi: **bilgi tabanı büyüklüğü > 10K chunk + sorgu karmaşıklığı > orta + hata maliyeti yüksek** → agentic RAG. Diğer durumlarda naive + reranker yeterli.
### 10.1. Sonsuz döngü riski
Reflector node'u eğer yeterlilik kararını veremezse, sonsuz döngüde takılır. Korumalar:
1. **Hard limit:** reflection_count >= 3 ise generator'a zorla yönlendir
2. **Wall-clock timeout:** Tek graph execution'ı 30s'yi aşamaz
3. **Token budget:** Toplam token sayısı bir limiti aşarsa abort
4. **Circuit breaker:** Aynı user için 1 dakikada 5'ten fazla agentic call → naive RAG'a düş
### 10.2. Prompt Injection Saldırıları
Agentic RAG, naive RAG'dan daha fazla saldırı yüzeyi sunar — her node ayrı bir LLM çağrısı, her biri prompt injection'a açık. Korumalar:
- **System prompt isolation.** User input asla system prompt seviyesine yükseltilmemeli
- **Tool whitelisting.** Agent'ın çağırabileceği tool'lar explicit listede; "tüm tool'lar açık" yasak
- **Output validation.** Verifier node'u, prompt injection'ın da bir savunma katmanı
- **Pen-test.** Üretim öncesi minimum 50 jailbreak/injection denemesi yapılmalı
### 10.3. State şişmesi
State içinde retrieved_chunks her iterasyonda büyür; 3+ iterasyon sonrası 50+ chunk birikebilir. Bu, token maliyetini ve gecikmeyi patlatır. Çözüm: her reflect'te chunk'ları **deduplicate + alaka sıralaması** ile top-15'e indir.
### 10.4. Maliyet kontrolünün üç katmanı
1. **Prompt caching.** Static system prompt'lar ve tekrarlayan chunks 5-dakikalık cache'de tutulur (Anthropic %90 indirim, OpenAI %50).
2. **Model tiering.** Planner ve reflector için Haiku 4.5 / GPT-5 mini; generator için Opus 4.7 / GPT-5; verifier için Sonnet 4.5. Maliyet -%40, kalite -%3.
3. **Cache + tier birleşimi** ile naive RAG'ın 2x maliyetinde agentic kalite elde edilebilir.
## 11. Sıkça Sorulan Sorular
Teknik olarak evet, ama 2026 yılında LangGraph'ın production-tested olduğu kanıtlandı (Klarna, LinkedIn, Uber). CrewAI multi-agent role-playing'de güçlü ama state-graph esnekliği daha az; AutoGen Microsoft ekosisteminde uyumlu ama Türkçe topluluk desteği zayıf. **Yeni proje başlatıyorsanız LangGraph'tan başlayın**, gerekçe varsa diğerlerine geçin.
Evet — naive RAG'ın retrieval bileşenlerini (vektör DB, BM25, reranker) koruyun, LangGraph'ı üstüne sarın. İlk migration: planner + retriever + generator (3 node). Stabilize olduktan sonra reflector + verifier eklenebilir. Bu, riski yayar.
2026 itibarıyla agentic RAG için **Claude Opus 4.7** lider — 1M context, yüksek faithfulness, mükemmel tool use. **GPT-5** OpenAI ekosistemine bağlıysanız veya çok agentic + çok structured output ihtiyacınız varsa. **Gemini 3.1 Pro** maliyet hassasiyetli vakalarda (özellikle Türkçe için iyileşti). Düşük-stake node'lar için (planner, reflector) Haiku 4.5 + Gemini Flash 3.1 ile maliyet düşürülebilir.
Evet. **Llama 4 70B + vLLM** ile LangGraph üzerinde tam self-hosted agentic RAG mümkün. KVKK kısıtlı sektörler (savunma, bazı bankalar) için tercih ediliyor. Performans GPT-5'in altında ama kabul edilebilir; en büyük ödün generator + verifier kalitesinde — bu node'larda eval harness sıkı tutulmalı.
Evet, daha karmaşık. RAGAS metrikleri (faithfulness, precision, recall) hâlâ baz; üzerine eklenenler: **(1)** Plan kalitesi — alt-görevler doğru ayrıştırıldı mı? **(2)** Reflection kalitesi — gereksiz reflect yok? Gereken reflect atlanmadı? **(3)** Tool kullanım doğruluğu. **(4)** End-to-end latency. **(5)** Cost per query. DeepEval ve TruLens agentic eval için 2026'da yeni metric set'leri yayınladı.
Klarna 2024 başında "AI asistanımız 700 full-time çalışana eş iş yapıyor" dedi. 2025'te bunu kısmen geri aldı (bazı görevleri insana geri verdiler). 2026 itibarıyla Klarna'nın asistanı **LangGraph üzerinde agentic** mimaride çalışıyor, 3M+ MAU, ortalama çağrı süresini 11 dakikadan 2 dakikaya indirdiğini açıkladı. Tam ikame olmasa da büyük etkili — Türk bankaları için referans vaka.
Doğrudan değil — agentic RAG bir backend servisidir, mobil cihazda çalıştırılmaz. Mobil uygulamanın RESTful/WebSocket bir endpoint'e bağlanması ve streaming response alması yeterli. Önemli: mobil UX için **node-level event'leri streaming** ile push (örn. SSE veya WebSocket) — "düşünüyor", "belge arıyor", "doğruluyor" gibi mikro-feedback'ler kullanıcı memnuniyeti için kritik.
LangGraph checkpointer (Postgres/Redis) sayesinde state her node sonrası kalıcılıkta. Hata olursa: **(1)** retry policy node-level tanımlanır (3 attempt, exponential backoff). **(2)** Belirli node'lar için fallback (örn. verifier başarısızsa generator çıktısını "düşük güven" notu ile dön). **(3)** Tüm graph başarısızsa, naive RAG'a circuit-break — kullanıcıya hiç cevap vermemektense düşük kaliteli ama hızlı cevap vermek daha iyidir.
## 12. Sonraki Adım
Agentic RAG'a geçişe karar verdiyseniz, riskleri düşüren bir göç planı:
1. **Mimari atölye (1 hafta).** Mevcut naive RAG'ı haritalandırma, agentic'e taşıma stratejisi, KVKK risk değerlendirme.
2. **MVP (3-4 hafta).** 3 node ile başla (planner + retriever + generator). LangSmith + checkpointer setup.
3. **Eval harness (2 hafta).** RAGAS + custom agentic metrics. Min 200 sorudan oluşan eval seti.
4. **Reflector + verifier ekleme (2 hafta).** Eval ile kalite artışı doğrulanır.
5. **PII + audit + security (2 hafta).** KVKK/BDDK uyumu.
6. **A/B canary deploy (1-2 hafta).** %5 trafik agentic'e, eval skoru iyileşince yüzde yüze.
7. **Tam production (1 hafta).** Observability, alerting, on-call runbook.
Toplam: ~12-14 hafta orta-karmaşıklık bir kurumsal RAG için.
Sitedeki contact formundan ulaşabilirsiniz; agentic RAG mimari audit veya implementasyon danışmanlığı için.
---
Bu rehber yaşayan bir belgedir; agent orchestration ekosistemi (LangGraph, alternative framework'ler, eval harness) her çeyrek değişmektedir. **Çeyreklik olarak güncellenmektedir.**