Prompt Mühendisliğinden Bağlam Mühendisliğine: Paradigma Değişimi
2024'te herkes prompt mühendisliğinden bahsediyordu. "Doğru soruyu sor, doğru cevabı al" — mantık basit ve bir o kadar da çekiciydi. Ama 2026'ya geldiğimizde işler değişti. Üretim ortamında çalışan AI sistemlerinin başarısızlıklarına baktığımızda, sorunun çoğunlukla modelin yetersizliğinden değil, bağlam eksikliğinden kaynaklandığını gördük. Yani modele yanlış soru sormuyorduk — doğru cevabı verebilmesi için gereken bilgiyi sunmuyorduk.
İşte tam bu farkındalık, bağlam mühendisliğini (context engineering) sahneye çıkardı.
Peki ikisi arasındaki fark tam olarak ne? Kısaca söylemek gerekirse: prompt mühendisliği modele nasıl sorulacağını tasarlar, bağlam mühendisliği ise modelin yanıt vermeden önce neyi görmesi gerektiğinin tamamını tasarlar. Sistem talimatları, konuşma geçmişi, getirilen belgeler, araç tanımları, bellek durumu — bunların hepsi bağlamın birer parçası. Gartner'ın 2026 tanımıyla söylersek: "Bağlam mühendisliği, AI sistemlerinin niyeti anlayabilmesi, daha iyi kararlar alabilmesi ve bağlama uygun çıktılar üretebilmesi için ilgili verileri, iş akışlarını ve ortamı tasarlama ve yapılandırma disiplinidir."
Bu yazıda, bağlam mühendisliğinin dört temel stratejisini — Yaz (Write), Seç (Select), Sıkıştır (Compress), İzole Et (Isolate) — Python kod örnekleriyle birlikte inceleyeceğiz. Teoriyle sınırlı kalmayıp, her stratejiyi gerçek dünya senaryolarında nasıl uygulayabileceğinizi de göstereceğim.
Bağlam Mühendisliği Neden Bu Kadar Önemli?
Modern LLM'lerin devasa bağlam pencerelerine sahip olduğunu biliyoruz — Claude 200K token, GPT-4o 128K token destekliyor. Kulağa yeterli geliyor, değil mi? Ama büyük bağlam penceresi sorunları çözmek yerine, aslında yeni sorunlar da beraberinde getiriyor.
1. Bağlam Çürümesi (Context Rot)
Bağlam penceresine her eklenen bilgi parçası, modelin dikkatini potansiyel olarak dağıtır. Kalitesiz veya ilgisiz bilgi biriktiğinde performans dramatik biçimde düşer. Cisco'nun Şubat 2026 araştırması bunu çarpıcı bir şekilde ortaya koydu: bağlam mühendisliği teknikleri uygulandığında ortalama yanıt kalitesi 0.41'den 0.79'a yükseldi. Neredeyse iki katına çıkmış — bu küçük bir fark değil.
2. Ortada Kaybolma (Lost in the Middle)
LLM'lerin ilginç (ve biraz sinir bozucu) bir özelliği var: bağlam penceresinin başındaki ve sonundaki bilgilere daha fazla dikkat ederken, ortadaki bilgileri sıklıkla gözden kaçırıyorlar. 100K token'lık bir bağlamda kritik bilginiz 50K civarında bir yere düştüyse, modelin bunu kullanma olasılığı ciddi biçimde azalıyor.
3. Token Maliyeti ve Gecikme
Her ekstra token hem maliyet hem gecikme demek. Cisco'nun aynı araştırmasından bir veri daha: bağlam mühendisliği teknikleri yaklaşık %87 token tasarrufu sağladı ve ortalama uçtan uca gecikmeyi 47.8 saniyeden 8.9 saniyeye düşürdü. Dürüst olmak gerekirse, bu rakamları ilk gördüğümde ben de şaşırmıştım.
Dört Temel Strateji: Write, Select, Compress, Isolate
LangChain ekibinin belirlediği ve 2026 itibarıyla endüstri standardı haline gelen dört temel bağlam mühendisliği stratejisi var. Gelin bunları tek tek inceleyelim.
Strateji 1: Yaz (Write) — Dış Bellek ve Karalama Defteri
İlk strateji aslında çok sezgisel bir fikir: modelin her şeyi hatırlamasını beklemeyin, kritik bilgiyi bağlam penceresinin dışında kalıcı olarak saklayın. Tıpkı bizim karmaşık problemler üzerinde çalışırken not tutmamız gibi, AI ajanları da bir nevi "karalama defteri" (scratchpad) ve uzun süreli bellek kullanabilir.
Python ile Scratchpad Uygulaması
Aşağıdaki örnekte, bir ajanın görev sırasında ara sonuçları kaydetmek için kullandığı basit bir scratchpad mekanizmasını görebilirsiniz:
from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import SystemMessage, HumanMessage
import json
import os
class AgentState(TypedDict):
"""Ajan durumu — scratchpad ile zenginleştirilmiş."""
messages: list
scratchpad: dict # Kalıcı notlar
current_task: str
iteration: int
llm = ChatOpenAI(model="gpt-4o", temperature=0)
SCRATCHPAD_PATH = "./agent_scratchpad.json"
def load_scratchpad() -> dict:
"""Disk üzerinden scratchpad verisini yükler."""
if os.path.exists(SCRATCHPAD_PATH):
with open(SCRATCHPAD_PATH, "r") as f:
return json.load(f)
return {"findings": [], "decisions": [], "open_questions": []}
def save_scratchpad(data: dict) -> None:
"""Scratchpad verisini diske kaydeder."""
with open(SCRATCHPAD_PATH, "w") as f:
json.dump(data, f, ensure_ascii=False, indent=2)
def research_with_notes(state: AgentState) -> AgentState:
"""Araştırma yapar ve bulguları scratchpad'e kaydeder."""
scratchpad = state.get("scratchpad", load_scratchpad())
system_msg = SystemMessage(
content=(
"Sen bir araştırma ajanısın. Verilen görevi araştır.\n"
f"Önceki bulgular: {json.dumps(scratchpad['findings'], ensure_ascii=False)}\n"
"Yeni bulguları JSON formatında döndür."
)
)
response = llm.invoke([system_msg] + state["messages"])
# Yeni bulguyu scratchpad'e ekle
scratchpad["findings"].append({
"iteration": state.get("iteration", 0),
"content": response.content[:500]
})
save_scratchpad(scratchpad)
return {
**state,
"scratchpad": scratchpad,
"iteration": state.get("iteration", 0) + 1
}Bu yaklaşımın asıl güzelliği şu: ajan önceki iterasyonlardaki bulgularına erişebiliyor ve bunları bağlam penceresine kontrollü biçimde ekleyebiliyor. Her şeyi mesaj geçmişinde tutmak yerine, sadece ilgili notları seçerek bağlama dahil ediyorsunuz. Basit ama etkili.
Strateji 2: Seç (Select) — RAG ile Bağlam Seçimi
Bağlam mühendisliğinin belki de en yaygın bilinen tekniği RAG (Retrieval-Augmented Generation). Dış bilgi kaynaklarından sorguyla ilgili parçaları çekip bağlama ekliyorsunuz. Ama şunu söylemem lazım: 2026'da basit bir vektör araması artık yeterli değil. Hibrit arama ve yeniden sıralama (reranking) artık standart yaklaşım haline geldi.
Hibrit Arama + Reranking ile Gelişmiş RAG
Anthropic'in Contextual Retrieval araştırmasına göre, hibrit arama ve reranking kombinasyonu başarısız getirmeleri %67 oranında azaltıyor. Bu oldukça ciddi bir iyileşme. İşte Python uygulaması:
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain_core.documents import Document
def build_hybrid_retriever(documents: list[Document]):
"""Semantik + BM25 hibrit retriever oluşturur."""
# Belgeleri parçala
splitter = RecursiveCharacterTextSplitter(
chunk_size=800,
chunk_overlap=150,
separators=["\n\n", "\n", ". ", " "]
)
splits = splitter.split_documents(documents)
# Semantik retriever (vektör tabanlı)
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(
documents=splits,
embedding=embeddings,
collection_name="hybrid-search"
)
semantic_retriever = vectorstore.as_retriever(
search_kwargs={"k": 6}
)
# BM25 (anahtar kelime tabanlı) retriever
bm25_retriever = BM25Retriever.from_documents(splits)
bm25_retriever.k = 6
# Hibrit birleştirme
ensemble = EnsembleRetriever(
retrievers=[semantic_retriever, bm25_retriever],
weights=[0.6, 0.4] # Semantik aramaya biraz daha ağırlık
)
return ensemble
def rerank_documents(query: str, docs: list[Document], top_k: int = 4):
"""LLM tabanlı yeniden sıralama uygular."""
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
scored_docs = []
for doc in docs:
prompt = (
f"Sorgu: {query}\n\n"
f"Belge: {doc.page_content[:600]}\n\n"
"Bu belgenin sorguyla ilgililiğini 0-10 arasında puanla. "
"Sadece sayıyı döndür."
)
score = llm.invoke(prompt).content.strip()
try:
scored_docs.append((float(score), doc))
except ValueError:
scored_docs.append((0.0, doc))
scored_docs.sort(key=lambda x: x[0], reverse=True)
return [doc for _, doc in scored_docs[:top_k]]Buradaki kilit nokta şu: hibrit arama hem semantik benzerliği hem de anahtar kelime eşleşmesini yakalıyor. Böylece tek başına vektör aramasının kaçırabileceği belgeleri de bulabiliyorsunuz. Reranking adımı ise bu ilk sonuçları kalite açısından filtreleyerek bağlama yalnızca en ilgili belgelerin girmesini sağlıyor.
Strateji 3: Sıkıştır (Compress) — Bağlam Özetleme ve Budama
Uzun konuşmalarda bağlam penceresi kaçınılmaz olarak doluyor. Bu noktada sıkıştırma stratejisi devreye giriyor ve iki temel yöntemle sorunu çözüyor: özetleme (eski mesajları özetleyerek kısaltma) ve budama (ilgisiz bölümleri tamamen kaldırma).
Konuşma Özetleme Middleware'i
Aşağıdaki uygulama, konuşma geçmişi belirli bir token eşiğini aştığında otomatik olarak eski mesajları özetleyen bir middleware. Pratikte çok işe yarayan bir yapı:
from langchain_openai import ChatOpenAI
from langchain_core.messages import (
SystemMessage, HumanMessage,
AIMessage, BaseMessage
)
import tiktoken
class ConversationCompressor:
"""Konuşma geçmişini akıllıca sıkıştırır."""
def __init__(
self,
max_tokens: int = 4000,
keep_recent: int = 6,
model: str = "gpt-4o-mini"
):
self.max_tokens = max_tokens
self.keep_recent = keep_recent
self.llm = ChatOpenAI(model=model, temperature=0)
self.encoder = tiktoken.encoding_for_model("gpt-4o")
def count_tokens(self, messages: list[BaseMessage]) -> int:
"""Mesaj listesinin toplam token sayısını hesaplar."""
total = 0
for msg in messages:
total += len(self.encoder.encode(msg.content))
return total
def compress(
self, messages: list[BaseMessage]
) -> list[BaseMessage]:
"""Gerekirse konuşma geçmişini sıkıştırır."""
token_count = self.count_tokens(messages)
if token_count <= self.max_tokens:
return messages # Sıkıştırmaya gerek yok
# Son N mesajı koru, gerisini özetle
recent = messages[-self.keep_recent:]
old = messages[:-self.keep_recent]
if not old:
return messages
# Eski mesajları özetle
old_text = "\n".join(
f"{m.type}: {m.content}" for m in old
)
summary_prompt = (
"Aşağıdaki konuşma geçmişini kısa ve öz biçimde özetle. "
"Kritik kararları, bulguları ve bağlamı koru. "
"Gereksiz tekrarları ve nezaket ifadelerini çıkar.\n\n"
f"{old_text}"
)
summary = self.llm.invoke(
[HumanMessage(content=summary_prompt)]
).content
# Özeti sistem mesajı olarak ekle
compressed = [
SystemMessage(
content=f"[Önceki konuşma özeti]\n{summary}"
)
] + recent
new_count = self.count_tokens(compressed)
print(
f"Sıkıştırma: {token_count} -> {new_count} token "
f"(%{round((1 - new_count/token_count) * 100)} tasarruf)"
)
return compressed
# Kullanım
compressor = ConversationCompressor(max_tokens=3000)
messages = [
HumanMessage(content="Projemiz için bir veritabanı seçelim."),
AIMessage(content="PostgreSQL ve MongoDB karşılaştırması yapalım..."),
HumanMessage(content="İlişkisel verilerimiz çok fazla..."),
AIMessage(content="Bu durumda PostgreSQL daha uygun olur..."),
# ... 30+ mesaj daha
]
compressed = compressor.compress(messages)Burada altını çizmek istediğim önemli bir nokta var: odaklanmış 300 token'lık bir bağlam, çoğu zaman rastgele doldurulmuş 100K token'lık bir bağlamdan daha iyi performans veriyor. Kulağa çelişkili gelebilir ama daha az ve daha kaliteli bağlam, neredeyse her zaman daha iyi sonuç üretiyor.
Strateji 4: İzole Et (Isolate) — Çoklu Ajan ile Bağlam Ayırma
Belki de en güçlü strateji olan izolasyon, karmaşık görevleri farklı bağlam pencerelerine sahip uzmanlaşmış alt ajanlara bölmeyi önerir. Her ajan kendi bağlam penceresiyle çalışır ve sadece kendi göreviyle ilgili bilgiyi görür. Anthropic'in araştırmalarına göre, izole bağlamlara sahip birden fazla ajan, tek bir ajandan tutarlı biçimde daha iyi performans gösteriyor.
LangGraph ile Bağlam İzolasyonu
from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import SystemMessage, HumanMessage
from typing import TypedDict, Literal
class OrchestratorState(TypedDict):
"""Ana orkestratör durumu — her ajan izole çalışır."""
user_query: str
code_analysis: str
security_review: str
final_report: str
llm = ChatOpenAI(model="gpt-4o", temperature=0)
def code_analyzer(state: OrchestratorState) -> OrchestratorState:
"""Kod analizi — sadece kodla ilgili bağlamı görür."""
response = llm.invoke([
SystemMessage(
content=(
"Sen bir kod analiz uzmanısın. "
"Sadece kod kalitesi, mimari ve performansla ilgilen. "
"Güvenlik konularını GÖRMEZDEN GEL — "
"o başka bir uzmanın işi."
)
),
HumanMessage(
content=f"Bu kodu analiz et:\n{state['user_query']}"
)
])
return {**state, "code_analysis": response.content}
def security_reviewer(state: OrchestratorState) -> OrchestratorState:
"""Güvenlik incelemesi — sadece güvenlik bağlamını görür."""
response = llm.invoke([
SystemMessage(
content=(
"Sen bir güvenlik uzmanısın. "
"Sadece güvenlik açıkları, veri sızıntıları "
"ve OWASP Top 10 riskleriyle ilgilen."
)
),
HumanMessage(
content=f"Bu kodun güvenlik incelemesini yap:\n{state['user_query']}"
)
])
return {**state, "security_review": response.content}
def report_synthesizer(state: OrchestratorState) -> OrchestratorState:
"""Raporları birleştirir — sadece sonuçları görür, ham kodu değil."""
response = llm.invoke([
SystemMessage(
content="Sen bir teknik rapor yazarısın. "
"Farklı uzmanların analizlerini birleştir."
),
HumanMessage(
content=(
f"Kod Analizi:\n{state['code_analysis']}\n\n"
f"Güvenlik İncelemesi:\n{state['security_review']}\n\n"
"Bu analizleri birleştirerek kapsamlı bir rapor oluştur."
)
)
])
return {**state, "final_report": response.content}
# Paralel çalışan izole ajanlar
workflow = StateGraph(OrchestratorState)
workflow.add_node("code_analyzer", code_analyzer)
workflow.add_node("security_reviewer", security_reviewer)
workflow.add_node("report_synthesizer", report_synthesizer)
# Kod analizi ve güvenlik incelemesi paralel çalışır
workflow.add_edge(START, "code_analyzer")
workflow.add_edge(START, "security_reviewer")
# Her ikisi de tamamlanınca raporlama başlar
workflow.add_edge("code_analyzer", "report_synthesizer")
workflow.add_edge("security_reviewer", "report_synthesizer")
workflow.add_edge("report_synthesizer", END)
app = workflow.compile()Bu mimarideki asıl avantajı şöyle düşünebilirsiniz: kod analiz ajanı güvenlik detaylarıyla "kirletilmiyor", güvenlik ajanı da mimari kararlarla uğraşmıyor. Her ajan kendi uzmanlık alanına odaklanıyor ve bağlam penceresi verimli kullanılıyor. Sonunda da bir sentez ajanı her iki sonucu birleştiriyor.
Araç Seçimi İçin Bağlam Mühendisliği
2026'da AI ajanlarının erişebildiği araç sayısı hızla artıyor. Ama bir ajanın bağlam penceresine 50'den fazla araç tanımı yüklemek hem token israfı hem de performans kaybı demek. Peki çözüm ne? Araçlar için de RAG kullanmak.
Anthropic'in Tool Search Tool yaklaşımı bunu güzel bir şekilde gösterdi. Tüm araçları bağlama yüklemek yerine, sorguya göre ilgili araçları dinamik olarak seçmek %85 token tasarrufu sağladı ve doğruluk oranını %49'dan %74'e çıkardı (Opus 4 modeli için). Bayağı etkileyici rakamlar.
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_core.documents import Document
class ToolSelector:
"""Sorguya göre en ilgili araçları dinamik olarak seçer."""
def __init__(self, tools: list[dict]):
self.tools = {t["name"]: t for t in tools}
# Araç açıklamalarını vektör deposuna yükle
docs = [
Document(
page_content=f"{t['name']}: {t['description']}",
metadata={"tool_name": t["name"]}
)
for t in tools
]
self.vectorstore = Chroma.from_documents(
documents=docs,
embedding=OpenAIEmbeddings(
model="text-embedding-3-small"
),
collection_name="tool-search"
)
def select_tools(
self, query: str, max_tools: int = 5
) -> list[dict]:
"""Sorguyla en ilgili araçları seçer."""
results = self.vectorstore.similarity_search(
query, k=max_tools
)
selected = []
for doc in results:
name = doc.metadata["tool_name"]
if name in self.tools:
selected.append(self.tools[name])
return selected
# Kullanım örneği
all_tools = [
{
"name": "search_docs",
"description": "Teknik dokümantasyonda arama yapar"
},
{
"name": "run_sql",
"description": "SQL sorgusu çalıştırır"
},
{
"name": "send_email",
"description": "E-posta gönderir"
},
{
"name": "create_ticket",
"description": "Jira'da yeni ticket oluşturur"
},
{
"name": "analyze_logs",
"description": "Uygulama loglarını analiz eder"
},
# ... 50+ araç daha
]
selector = ToolSelector(all_tools)
# Sorguya göre sadece ilgili araçları seç
query = "Veritabanındaki son siparişleri getir"
relevant = selector.select_tools(query, max_tools=3)
# Sonuç: [run_sql, search_docs, analyze_logs]Model Context Protocol (MCP) ile Standart Bağlam Yönetimi
Model Context Protocol (MCP), 2026 itibarıyla Linux Foundation bünyesindeki Agentic AI Foundation tarafından yönetilen açık bir standart. Anthropic, OpenAI, Google ve Microsoft tarafından benimsenen MCP, AI ajanlarının dış araçlara ve veri kaynaklarına bağlanması için evrensel bir protokol sunuyor.
MCP'nin bağlam mühendisliğindeki rolü oldukça kritik: her araç bağlantısı için farklı bir entegrasyon yazmak yerine, standart tools/list ve tools/call protokolüyle tüm araçlara tek bir arayüzden erişebiliyorsunuz. Bu da bağlam penceresindeki araç tanımlarını standartlaştırıyor ve araç seçimini öngörülebilir hale getiriyor.
# MCP sunucusu ile bağlam yönetimi örneği
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
async def use_mcp_tools():
"""MCP sunucusundan araçları dinamik olarak keşfeder."""
server_params = StdioServerParameters(
command="python",
args=["mcp_server.py"]
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
# Mevcut araçları listele
tools = await session.list_tools()
print(f"Kullanılabilir araç sayısı: {len(tools.tools)}")
# Sadece ihtiyaç duyulan aracı çağır
result = await session.call_tool(
"search_knowledge_base",
arguments={"query": "son güncellemeler"}
)
return resultÜretim Ortamı İçin En İyi Uygulamalar
Bağlam mühendisliğini üretim ortamında uygulamaya alırken dikkat etmeniz gereken bazı pratik kurallar var. Bunları kendi deneyimlerimden de yola çıkarak şöyle sıralayabilirim:
- Basit başlayın: Statik promptlar ve temel araçlarla başlayın. Dinamik bağlam seçimi, sıkıştırma ve çoklu ajan mimarisini yalnızca gerçekten ihtiyaç duyduğunuzda ekleyin. Erken optimizasyon burada da geçerli bir tuzak.
- Bağlam bütçesi belirleyin: Her bileşen için token bütçesi ayırın. Kabaca bir örnek: sistem talimatları %10, getirilen belgeler %30, konuşma geçmişi %40, araç tanımları %20.
- Her değişikliği ayrı ayrı test edin: Bir seferde yalnızca bir bağlam mühendisliği tekniği ekleyin ve etkisini ölçün. Birden fazla değişikliği aynı anda yapmak, hangisinin gerçekten fark yarattığını anlamanızı zorlaştırır.
- Token kullanımını ve gecikmeyi izleyin: Her model çağrısında kaç token gönderildiğini, yanıt süresini ve bağlam penceresi doluluk oranını takip edin. Göremediğiniz şeyi optimize edemezsiniz.
- Bilgi tabanı küçükse RAG kurmayın: Anthropic'in bulgularına göre, toplam bilgi tabanınız yaklaşık 200.000 token'ın altındaysa RAG altyapısı kurmak yerine doğrudan tam bağlam yükleme ve prompt önbellekleme kullanmak daha hızlı ve ucuz olabiliyor. Her duruma RAG uygulamak gerekmez.
- Bağlam kalitesini değerlendirin: Getirilen belgelerin ilgililiğini, özetlerin doğruluğunu ve araç seçimlerinin isabetliliğini düzenli olarak değerlendirmek için otomatik eval döngüleri kurun.
Sıkça Sorulan Sorular
Bağlam mühendisliği ile prompt mühendisliği arasındaki fark nedir?
Prompt mühendisliği, modele gönderilen talimatın kendisini optimize etmeye odaklanır — yani doğru soruyu doğru biçimde sormak. Bağlam mühendisliği ise bundan çok daha geniş bir alanı kapsıyor: modelin bağlam penceresine giren tüm bilgiyi — sistem talimatları, konuşma geçmişi, getirilen belgeler, araç tanımları, bellek durumu — sistematik olarak tasarlamak ve optimize etmek. Kısacası prompt mühendisliği, bağlam mühendisliğinin bir alt kümesi olarak düşünülebilir.
Küçük projeler için bağlam mühendisliği gerekli mi?
Tek turlu basit chatbot uygulamaları için karmaşık bağlam mühendisliği tekniklerine genellikle ihtiyaç yok. Ancak projeniz çoklu konuşma turu, dış veri kaynakları, araç kullanımı veya uzun süreli görevler içeriyorsa, bağlam mühendisliği hemen devreye girmesi gereken bir disiplin. Pratik bir kural olarak: bağlam pencerenizin %50'sinden fazlası dolmaya başladığında sıkıştırma ve seçim stratejilerini düşünmeye başlayın.
Context engineering için en iyi Python framework hangisi?
2026 itibarıyla en yaygın yaklaşım, veri yapılandırma için LlamaIndex ile ajan orkestrasyonu için LangGraph'ı birlikte kullanmak. LlamaIndex belge yükleme, parçalama ve indeksleme konusunda güçlüyken, LangGraph durum yönetimi, checkpoint mekanizması ve koşullu dallanma konusunda öne çıkıyor. Basit RAG uygulamaları için tek başına LangChain de işinizi görebilir.
Bağlam çürümesi (context rot) nasıl önlenir?
Bağlam çürümesini önlemenin en etkili yolu, bağlam penceresine giren her bilgi parçasının ilgililiğini değerlendiren otomatik kalite kontrol mekanizmaları kurmak. Getirilen belgeleri bir grader ile puanlayın, belirli bir eşiğin altında kalanları çıkarın, eski konuşma mesajlarını düzenli olarak özetleyin ve kullanılmayan araç tanımlarını bağlamdan kaldırın. Unutmayın: odaklanmış 300 token, rastgele doldurulmuş 100K token'dan her zaman daha etkili.
MCP (Model Context Protocol) bağlam mühendisliğinde nasıl bir rol oynar?
MCP, AI ajanlarının dış araçlara ve veri kaynaklarına bağlanması için standart bir protokol sağlayarak bağlam mühendisliğini kolaylaştırıyor. Her araç için ayrı entegrasyon yazmak yerine standart bir arayüz kullanıyorsunuz; bu da araç tanımlarının bağlam penceresindeki formatını öngörülebilir ve tutarlı kılıyor. Ayrıca MCP sayesinde araçları dinamik olarak keşfedebilir ve yalnızca o anki göreve uygun olanları bağlama ekleyebilirsiniz.