Context Engineering Rehberi 2026

Güncelleme: 27 Haziran 2026

Context engineering (bağlam mühendisliği), bir LLM'in yanıt üretmeden hemen önce bağlam penceresinde göreceği her token'ı (sistem talimatlarını, çağrılan araç tanımlarını, getirilen belgeleri, geçmiş konuşmayı ve örnekleri) amaca uygun şekilde seçme, sıralama ve sıkıştırma disiplinidir. Prompt engineering tek bir mesajı yazma sanatıyken, context engineering 200K+ token'lık bağlam pencerelerinde modelin dikkatini hangi bilginin alacağına karar veren bir sistem tasarımı pratiğidir. Bu rehberde 2026'nın güncel modelleri (Claude Opus 4.7, Gemini 2.5 Pro, GPT-5) üzerinde context engineering'in temel desenlerini, "context rot" sorununu, prompt caching ekonomisini ve üretim ajanlarında hafıza yönetimini Python kodu ile göreceksiniz.

Context engineering, prompt engineering'in üst kümesidir: tek bir mesaj değil, bağlam penceresine giren tüm token'ların orkestrasyonu üzerine kuruludur.
Modern LLM'lerde bağlam penceresi büyüse de "context rot" nedeniyle 32K token'dan sonra geri çağırma doğruluğu belirgin şekilde düşer. Yani "hepsini at içeri" yaklaşımı çalışmaz.
Anthropic prompt caching ile tekrar eden sistem bağlamı maliyeti %90'a kadar azaltılabilir; cache hit oranını korumak için statik içeriği prompt'un başına yerleştirin.
Üretim ajanlarında üç katmanlı hafıza (çalışma hafızası, oturum hafızası, uzun vadeli vektör hafızası) bağlam taşmasının önüne geçer.
RAG, uzun bağlam pencerelerinin yerini almadı; ikisi birlikte "hibrit getirme" deseni olarak kullanıldığında token başına maliyet ve doğruluk en iyi seviyeye çıkar.

Context engineering nedir ve prompt engineering'den farkı

Andrej Karpathy'nin 2025 sonunda popülerleştirdiği bu terim, sektörde hızla bir disiplin hâline geldi. Prompt engineering tek bir kullanıcı mesajını ne kadar iyi yazdığınızla ilgilenir: rol verme, few-shot örnek ekleme, chain-of-thought tetikleme. Context engineering ise modelin output token'ı üretmeden bir adım önce bağlam penceresinde gördüğü her şeyi mühendislik problemi olarak ele alır. Sistem talimatı, araç şemaları, tool call sonuçları, retrieved chunks, kullanıcı mesajı, geçmiş asistan turları... hepsi bağlamdır ve hepsi modelin dikkatini paylaşır.

Pratik fark şudur. ChatGPT arayüzünde tek seferlik bir özet isterken prompt engineering yaparsınız. 50 kullanıcının paralel sohbet ettiği, MCP araçlarıyla 12 farklı veri kaynağına erişen, RAG ile 200 sayfa dökümandan parça çeken bir üretim ajanı yazıyorsanız context engineering yaparsınız. Bu noktada sorulması gereken sorular değişir: Hangi araç şemasını her turda gönderiyorum, hangisini sadece gerektiğinde? Geçmiş mesajları ne zaman özetlemeliyim? Cache hit oranımı nasıl korurum? Retrieval'dan gelen 8 chunk'ı hangi sırayla yerleştirirsem model en doğru yanıt verir?

Geçen ay bir müşteri ajanında tam da bu duvara çarpmıştık: 18. turda modelin "ben kimim?" demeye başlaması, aslında sistem prompt'una sızan dinamik tarih alanı yüzünden cache'in her turda kırılmasından kaynaklanıyordu. Bağlamı temizlediğimizde hem maliyet üçte birine indi hem de doğruluk geri geldi.

Bu disiplin, Agentic RAG sistemlerinin ve çoklu ajan mimarilerinin ölçeklenmesi için kritik bir altyapı katmanıdır. Her iki desende de "bağlam" tek bir prompt değil, dinamik olarak inşa edilen bir yapıdır.

2026'da bağlam penceresi sınırları ve modeller

Bağlam penceresi, modelin tek bir çıkarımda işleyebildiği maksimum token sayısıdır ve 2024'ten bu yana ciddi şekilde büyüdü. Ama ham sayılar yanıltıcı olabilir; gerçek "kullanılabilir bağlam" çok daha küçüktür. Aşağıdaki tablo 2026 ortası itibarıyla üretim için kullanılan başlıca modelleri özetler.

Model	Bağlam (token)	Çıktı sınırı	Prompt caching	Etkili "needle" doğruluğu
Claude Opus 4.7	200K	8K	Evet (5 dk + 1 saat)	~96% (128K'ya kadar)
Claude Sonnet 4.6	200K	8K	Evet (5 dk + 1 saat)	~95%
GPT-5	400K	16K	Otomatik (50% indirim)	~92% (200K'ya kadar)
Gemini 2.5 Pro	2M	8K	Evet (manuel)	~88% (1M'de düşer)
Llama 4 Scout	10M*	4K	Hayır	~70% (>256K)

*Llama 4 Scout'un teorik 10M penceresi etkileyici olsa da bağımsız benchmark'lar 256K token'dan sonra doğruluğun belirgin şekilde düştüğünü gösteriyor. Detaylı modeller, fiyatlandırma ve API parametreleri için Anthropic'in resmi model dokümantasyonuna bakabilirsiniz.

Context rot ve "lost in the middle" sorunu

2025'te Chroma araştırma ekibi tarafından yayınlanan "Context Rot" raporu, model üreticilerinin reklamladığı bağlam pencerelerinin çoğunun pratikte tutarlı performans göstermediğini ortaya koydu. Ana bulgular: bağlam uzadıkça doğruluk yalnızca needle pozisyonuna göre değil, semantik mesafeye, dağıtıcı bilgi yoğunluğuna ve görev karmaşıklığına göre de düşüyor. Liu ve arkadaşlarının 2023'teki "Lost in the Middle" çalışması bu fenomenin temelini attı: modeller, bağlamın başındaki ve sonundaki bilgileri ortadakilere göre daha güvenilir şekilde geri çağırıyor.

Pratik sonuçlar context engineer'in iş listesini şekillendirir:

U-eğrisi yerleşimi: En kritik bilgiyi bağlamın başına (sistem prompt'tan hemen sonra) veya sonuna (kullanıcı mesajından hemen önce) koyun. Ortadaki konum en zayıf konumdur.
Yoğunluk kontrolü: Bağlamda ne kadar çok "dikkat dağıtıcı" alakasız metin varsa, asıl needle'ı bulma olasılığı o kadar düşer. Retrieval'dan dönen chunk'ları reranker ile filtreleyin.
Görev yakınlığı: Talimatları ve veriyi birbirine bitişik tutun. Talimat sistem mesajında, veri kullanıcı mesajının ortasında olduğunda model arasını birleştirmekte zorlanır.

Aşağıdaki Python örneği, retrieval sonuçlarını U-eğrisi desenine göre yeniden sıralayan basit bir yardımcı fonksiyonu gösterir:

def u_shape_rerank(chunks: list[dict], score_key: str = "score") -> list[dict]:
    """En yüksek skorlu chunk'ları bağlamın başına ve sonuna yerleştirir.

    Lost-in-the-middle'ı azaltmak için kullanılır. Chunk'lar skora göre
    azalan sırada gelir; çift indekslileri öne, tekleri sona koyarız.
    """
    ranked = sorted(chunks, key=lambda c: c[score_key], reverse=True)
    head, tail = [], []
    for i, chunk in enumerate(ranked):
        (head if i % 2 == 0 else tail).append(chunk)
    return head + list(reversed(tail))

# Kullanım: retrieval sonucu
retrieved = [
    {"text": "...", "score": 0.92},
    {"text": "...", "score": 0.88},
    {"text": "...", "score": 0.81},
    {"text": "...", "score": 0.74},
]
context_blocks = u_shape_rerank(retrieved)
# En guclu chunk basta, ikincisi sonda, ucuncusu ikinci, dorduncusu sondan ikinci.

Bağlam penceresinin yedi bileşeni

Bir üretim LLM çağrısındaki bağlam neredeyse hiçbir zaman tek bir string değildir. Aşağıdaki yedi bileşen, modern context engineering pratiğinde ayrı ayrı yönetilmesi gereken katmanlardır:

Sistem talimatı: Modelin rolü, kısıtları, çıktı formatı. Genellikle statik; cache'lenmeye en uygun katman.
Araç tanımları (tool schemas): MCP veya native function calling şemaları. Üretim ajanlarında en büyük token tüketicisidir; gereksiz araçları dinamik olarak çıkarın.
Few-shot örnekler: Domain'e özel örnekler. Statik ise sistem prompt'tan sonra cache'leyin.
Retrieved bilgi (RAG chunks): Dinamik; her sorguya göre değişir. U-eğrisi düzeninde yerleştirin.
Geçmiş konuşma turları: Uzun oturumlarda özetlemeye en uygun katman.
Mevcut araç çağrısı sonuçları: Aynı turda gelen tool result'lar. Büyük JSON'lar geliyorsa modelden önce projekte (özetle/seç) edin.
Kullanıcı mesajı: Tek değişmez katman; bağlamın sonuna yerleştirilir.

Prompt caching ile maliyet optimizasyonu

Prompt caching, aynı bağlam ön ekini birden fazla istekte yeniden kullanan API çağrılarında devasa maliyet düşüşleri sağlar. Anthropic'in implementasyonunda cache yazma 1.25x, cache okuma ise 0.1x baz fiyat üzerinden ücretlendirilir. Yani statik 100K token'lık bir sistem prompt'u 1000 kez tekrar kullanıldığında %90'a varan tasarruf elde edersiniz. Detaylar için Anthropic Prompt Caching dokümantasyonuna bakın.

Aşağıdaki örnek, Claude API'sinde dört katmanlı bir bağlamı doğru cache breakpoint'lerle nasıl yapılandıracağınızı gösterir:

from anthropic import Anthropic

client = Anthropic()

# Statik icerikleri ayri bloklara ayir ve cache breakpoint koy
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Sen bir hukuki danismansin. Turkce yanit ver, "
                    "sadece saglanan mevzuata referans ver.",
            # Sistem talimati asla degismez - uzun TTL cache
            "cache_control": {"type": "ephemeral", "ttl": "1h"},
        },
        {
            "type": "text",
            "text": LEGAL_CORPUS_TEXT,  # ~80K token'lik mevzuat metni
            "cache_control": {"type": "ephemeral", "ttl": "1h"},
        },
    ],
    tools=TOOLS_SCHEMA,  # Arac semalari da otomatik cache'lenir
    messages=[
        {
            "role": "user",
            "content": "TBK madde 49 kapsaminda haksiz fiilin "
                       "sartlarini aciklar misin?",
        }
    ],
)

# usage objesinde cache_creation_input_tokens ve cache_read_input_tokens
# alanlarini izleyin - hit oraninizi bu metrik uzerinden takip edin.
print(response.usage)

Ajanlarda üç katmanlı hafıza tasarımı

Çoklu turlu ajanlar, doğal olarak her turla birlikte büyüyen bir bağlamla başa çıkmak zorundadır. Naive yaklaşım, yani tüm geçmişi her turda göndermek, 30. tura geldiğinde 150K token'a ulaşır ve hem maliyet hem de context rot patlar. Üretimde işe yarayan desen üç katmanlı hafızadır:

1. Çalışma hafızası (working memory)

Mevcut tur için ihtiyaç duyulan ham veriler: son araç çağrısı sonucu, mevcut kullanıcı mesajı, aktif plan adımı. Bu her turda yeniden oluşturulur ve bağlamın "dinamik" alt katmanına yerleştirilir.

2. Oturum hafızası (session memory)

Aynı oturumdaki önceki turlar. Belirli bir token bütçesini aşınca özetlenir. Tavsiye edilen eşik: oturum hafızası bağlamın %30'unu geçmesin. LangGraph'ta bu pattern checkpointer + summarization node ile uygulanır:

from langgraph.graph import StateGraph
from langchain_anthropic import ChatAnthropic

llm = ChatAnthropic(model="claude-sonnet-4-6")

def summarize_if_long(state: dict) -> dict:
    """Mesaj gecmisi 8K token'i asarsa eski mesajlari ozete sikistir."""
    messages = state["messages"]
    token_estimate = sum(len(m.content) // 4 for m in messages)
    if token_estimate < 8000:
        return state

    # Son 4 mesaji koru, oncesini ozetle
    old, recent = messages[:-4], messages[-4:]
    summary_prompt = (
        "Asagidaki konusmayi 200 kelimeyi gecmeyecek sekilde ozetle. "
        "Kullanici tercihlerini ve alinan kararlari koru:\n\n"
        + "\n".join(f"{m.type}: {m.content}" for m in old)
    )
    summary = llm.invoke(summary_prompt).content
    return {"messages": [{"role": "system", "content": f"[Ozet] {summary}"}, *recent]}

graph = StateGraph(dict)
graph.add_node("summarizer", summarize_if_long)
# ... agent node'lari ekle

3. Uzun vadeli vektör hafızası

Oturumlar arası kalıcı bilgi: kullanıcı tercihleri, geçmiş kararlar, alınan notlar. Bir vektör veritabanına (Pinecone, Qdrant, Weaviate) yazılır ve Agentic RAG deseniyle ihtiyaç duyulan tur'larda geri çağrılır. Tüm hafızayı her turda yüklemeyin; yalnızca o turun göreviyle semantik olarak alakalı parçaları çekin.

Uzun bağlam mı RAG mi: hibrit yaklaşım

2024'te "uzun bağlam pencereleri RAG'ı öldürecek mi?" tartışması yapılıyordu. 2026 itibarıyla cevap netleşti: hayır, ikisi tamamlayıcı. 2M token pencereniz olsa bile, her sorguda 2M token göndermek hem ekonomik olarak savunulamaz hem de context rot nedeniyle doğruluğu düşürür. Doğru desen "hibrit getirme":

Vektör araması + BM25 hybrid retrieval ile aday chunk havuzunu daralt
Cross-encoder reranker ile en alakalı 8-20 chunk'ı seç
Seçilen chunk'ları geniş bağlam penceresinin belirli bir bölgesine U-eğrisi düzeniyle yerleştir
Geri kalan bağlamı statik, cache'lenmiş içeriklerle doldur

Pareto bölgesi genellikle 16K-64K aralığındaki "etkili bağlam"tır. Bunun altında kritik bilgi kaçabilir, üstünde ise marjinal doğruluk artışı maliyetin çok altında kalır. Üretim için: küçük dökümanlar için stuff-prompt, büyükler için hybrid RAG + reranker, çoklu turlu ajanlar için RAG + üç katmanlı hafıza birleşimini kullanın. Reranker karşılaştırmaları için RAGatouille deposu başlangıç için iyi bir referanstır.

Üretimde en sık yapılan beş hata

Dinamik içerikleri sistem prompt'una koymak: Her cache miss'iniz olur. Tarih, kullanıcı adı gibi alanları kullanıcı mesajına ya da ayrı bir bloka taşıyın.
Tüm MCP araçlarını her turda göndermek: 30 araç tanımı kolayca 5K token tutar. Bağlamsal araç filtreleme (tool routing) ile her tura uygun alt kümeyi seçin.
Retrieved chunk'ları skor sırasıyla yerleştirmek: Bu klasik "lost in the middle" senaryosudur. U-eğrisi yerleşimi kullanın.
Tool result'ları ham JSON olarak modele vermek: 200 satırlık bir API yanıtının çoğu modele gereksizdir. Tool result'ı ajan içinde projekte edip yalnızca ihtiyaç duyulan alanları geçirin.
Cache hit metriklerini izlememek: cache_read_input_tokens / input_tokens oranınızı bir gözlem panosunda takip edin; düşüş yaşandığında prompt yapısını revize edin.

Sıkça Sorulan Sorular

Context engineering ile prompt engineering arasındaki temel fark nedir?

Prompt engineering tek bir mesajı (sistem veya kullanıcı) optimize etmekle ilgilenir. Context engineering ise modelin bir çıkarımda göreceği tüm bağlamı (sistem talimatı, araç tanımları, retrieved chunk'lar, geçmiş turlar, tool result'lar, kullanıcı mesajı) bir sistem olarak tasarlamayı kapsar. Context engineering, prompt engineering'in üretim ölçeğinde uygulanmış halidir.

Uzun bağlam pencereleri RAG'ın yerini aldı mı?

Hayır. Gemini 2.5'in 2M, Llama 4'ün 10M token gibi pencereleri etkileyici olsa da context rot ve maliyet nedeniyle her sorguda tüm pencereyi doldurmak savunulamaz. 2026'da en iyi pratik, RAG ile aday içeriği daraltıp ardından 16K-64K aralığında etkili bir bağlamda U-eğrisi yerleşimiyle modele sunmaktır.

Prompt caching ne kadar tasarruf sağlar?

Anthropic'te cache okuma ücreti baz girdi fiyatının yaklaşık %10'u; cache yazma ücreti %125'i. Aynı statik bağlam ön ekini 10+ kez tekrar kullanan workload'larda %85-90 arası girdi token tasarrufu yaygındır. OpenAI'da otomatik prompt caching cache hit token'ları için %50 indirim sağlar.

"Lost in the middle" sorununu nasıl önlerim?

Üç teknik birlikte iyi çalışır: (1) retrieval sonuçlarını skor sırasıyla değil U-eğrisi düzeniyle yerleştirin, en güçlü chunk'lar başta ve sonda olsun; (2) bir cross-encoder reranker ile dağıtıcı içeriği eleyin; (3) bağlamı modelin %95+ doğruluk koruduğu pencereye (genelde 32K-64K) sınırlayın.

Üretim ajanlarımda hafızayı nasıl yönetmeliyim?

Üç katmanlı yapı önerilir: çalışma hafızası (mevcut tur), oturum hafızası (özetleme ile sıkıştırılan geçmiş turlar) ve uzun vadeli vektör hafızası (oturumlar arası kalıcı bilgi). LangGraph'ta bu yapı checkpointer + summarization node ile uygulanır; oturum hafızası bağlamın %30'unu geçtiğinde özetleme tetiklenmelidir.