Context Engineering Çağı: Prompt Caching, Long Context vs RAG ve Runtime State Management (2026 Rehberi)

2023-2024'te "prompt engineer" pozisyon ilanları LinkedIn'i kapladı. 2025 sonunda aynı pozisyonlar büyük şirketlerde context engineer veya AI systems engineer olarak yeniden başlığa kavuştu. Bu sadece bir isim değişikliği değil, mesleğin önceliğinin değişmesidir.

Prompt engineering, modelin tek bir çağrısı için talimatların nasıl yazılacağı problemiydi — string formatlama, few-shot example seçimi, chain-of-thought tetikleyicileri. Context engineering, modelin tüm çalışma ömrü boyunca bağlamının nasıl kurulacağı, ne kadarının cache'leneceği, ne zaman güncelleneceği, ne zaman yeniden başlatılacağı problemidir.

Anthropic'in 2026 Ocak'taki Engineering Blog post'unda Christopher Olah ve takım bu shift'i şöyle özetledi: "Bir agent'ı production'a almak, daha iyi bir prompt yazmaktan çok daha fazlasıdır. Hangi context'in, hangi turn'da, hangi cache TTL'iyle, hangi state store'da tutulacağı — bu kararlar performansı, maliyeti ve doğruluğu prompt seçiminden daha çok belirliyor."

Bu rehberin hedef kitlesi

• Production'da LLM uygulamaları geliştiren mühendisler
• Aylık LLM faturası $1K+ olan ekipler (caching ROI hızla pozitif olur)
• RAG, long context ve agent state arasında karar vermesi gereken mimarlar
• KVKK kısıtlı ortamlarda Türkçe AI uygulaması inşa eden CTO'lar

Prompt caching, Anthropic'in 2024 Ağustos'ta beta olarak duyurduğu, 2025 yılında GA'ya alınan ve 2026 itibarıyla tüm Claude modellerinde standart hale gelen bir özelliktir. Temel fikir: prompt'un başında değişmeyen büyük metin bloklarını (system prompt, document context, tool definitions, few-shot examples) sunucuda 5 dakikalık (veya 1 saatlik) bir cache'e koyar; sonraki çağrıda aynı prefix tekrar gönderildiğinde token tekrar billing edilmez.

2.1. Fiyatlandırma mekaniği

• Cache write: Standart input token fiyatının 1.25x'i (5-dk TTL) veya 2x'i (1-saat TTL)
• Cache hit (read): Standart input token fiyatının %10'u
• Output: Etkilenmez, normal fiyat

Yani prompt'unuzun 90K token'ı static system prompt + document context ve 1K token'ı user query ise:

• Cache yok: Her çağrıda 91K input token billing
• Cache var, hit: 90K cached (her cache TTL'i yenilenirken 1.25x ödenir; cache hit'lerinde %10) + 1K standart

Tipik scenario: bir agent oturumu 20 turn sürer; ilk turn cache write, sonraki 19 turn cache hit. Maliyet tasarrufu: ~%85.

2.2. Don't Break the Cache prensibi

Cache, prompt'un başından itibaren prefix-based hash ile çalışır. Yani prompt'un başında tek bir karakter değişirse cache miss. Bu, context engineering'in altın kuralını doğurur:

Cache'lenebilir prefix'i en başa koy, dinamik içeriği en sona koy.

Tipik yanlış pattern:

System: "Bugun {{tarih}}. ..."
Document context: 50K token (static)
User: "..."

Burada her gün tarih değiştiği için sistem prompt'unun başı her gün değişir → cache miss. Düzeltme:

System: "Sen bir asistansin. ..."   # static
Document context: 50K token         # static, cache_control: ephemeral
Conversation start: "Bugun {{tarih}}. Sorular:"   # dynamic
User: "..."

2.3. Cache breakpoint'leri (Anthropic explicit)

Anthropic'te en fazla 4 cache breakpoint koyabilirsiniz. Tipik yerleştirme:

1. System prompt sonunda — uzun süreli, neredeyse hiç değişmez
2. Document context sonunda — dökümanlar uzun-ömürlü ama bazen yenilenebilir
3. Tool definitions sonunda — agent değişene kadar sabit
4. Conversation history'nin n-1'inde — son user mesajı hariç tüm geçmiş

2.4. Cache invalidation tetikleyicileri

Cache aşağıdaki durumlarda otomatik invalidate olur:

• 5dk (veya 1sa) TTL geçerse
• Cache prefix'inin herhangi bir token'ı değişirse
• Model versiyon değişirse (örn. claude-opus-4-7 → claude-opus-4-7-1m geçişi)
• Tool definitions değişirse
• System message değişirse

2.5. Türkiye için somut tasarruf hesabı

Bir Türk fintech şirketinin müşteri hizmetleri agent'ı:

• System prompt: 8K token (KVKK talimatları, ton, format)
• KB context (top-10 chunk): 12K token
• Tool definitions: 4K token
• Conversation history (ortalama): 6K token
• User query: 200 token
• Toplam input: ~30K token

Günde 50K query. Cache YOK senaryosu (Claude Opus 4.7):

• 50K × 30K × $15/1M = $22,500/gün = ~$675K/ay

Cache VAR senaryosu (24K cached + 6K dynamic):

• 24K cache write (%20'sinde yenileme): 50K × 24K × 0.2 × $18.75/1M = $4,500/gün (cache write %25 premium)
• 24K cache hit (%80): 50K × 24K × 0.8 × $1.5/1M = $1,440/gün
• 6K dynamic: 50K × 6K × $15/1M = $4,500/gün
• Toplam: $10,440/gün = ~$313K/ay

Aylık tasarruf: $362K (~%54). Yıllık: $4.3M.

2026 itibarıyla long context modeller "RAG'a gerek yok" tartışmasını tetikledi:

• Claude Opus 4.7: 1M token (1M context tier)
• Gemini 3.1 Pro: 2M token (long-mode)
• GPT-5.5: 272K input + 128K output
• Claude Sonnet 4.5: 200K (standard)
• Llama 4 70B: 256K

1M token = yaklaşık 750K kelime = bir orta uzunluk roman + tüm Wikipedia girişleri belirli bir konuda. Bu kapasite, bazı use-case'lerde RAG'ı tamamen ikame eder. Ama "her zaman" değil — tradeoff'lar var.

3.1. Karar matrisi

3.2. Maliyet karşılaştırması (Claude Opus 4.7, 1 günlük operasyon)

Senaryo: 200K token belge, günde 1,000 sorgu

RAG yaklaşımı:

• Embedding (one-time): $0.10
• Retrieval (top-5, ~5K context): 1K × 5K × $15/1M = $75/gün
• Yıllık: ~$27,000

Long context (cache YOK):

• 1K × 200K × $15/1M = $3,000/gün
• Yıllık: ~$1,100,000

Long context (cache VAR, doc static):

• Cache write (günde 1 kez yenileme): 200K × $18.75/1M = $3.75/gün
• Cache hit: 1K × 200K × $1.5/1M = $300/gün
• Yıllık: ~$111,000

RAG hâlâ 4x daha ucuz, ama Long context + cache makul. Karar belge sayısı + doğruluk gereksinimine bağlı.

3.3. Doğruluk karşılaştırması: "Lost in the Middle" hâlâ var mı?

Liu et al. 2023'te ünlü "Lost in the Middle" paper'ında, modellerin 200K+ context'te ortadaki bilgileri ihmal ettiğini gösterdi. 2026'da bu sorun azaldı ama tamamen yok olmadı:

• Claude Opus 4.7: 1M context'te needle-in-haystack %96 doğruluk (Anthropic'in iç testi)
• Gemini 3.1 Pro: 2M context'te %93 (Google'ın iç testi)
• GPT-5.5: 272K context'te %94 (OpenAI'nin iç testi)

Ama bu "needle" testleridir — gerçek long-document QA'da doğruluk %75-85'e iner. RAG ile birleştirildiğinde (top-20 retrieve + 100K context) doğruluk %90+'a çıkar. Pratik: long context tek başına RAG'dan iyi değil; RAG + makul context = en iyi.

3.4. Gecikme karşılaştırması

• RAG (top-5, 5K context): p50 1.2s, p95 2.8s
• Long context (200K): p50 8.5s, p95 18s
• Long context (1M): p50 45s, p95 90s

Gerçek-zamanlı chat için 1M context kabul edilemez. Async (batch, research workflow) için tolere edilebilir.

OpenAI 2026 Şubat'ta GPT-5.5'i duyurdu. Ana yenilik: input tier sistemi.

• Standard tier: İlk 128K input — standart fiyat
• Long tier: 128K-272K input — 2x fiyat
• Output: Tüm tier'larda aynı

Bu tier yapısı, context budget allocation'ı kritik kılar. 130K token bir input, 128K token'lık inputtan 2x pahalıdır. Mühendisin işi: input'u 128K altında tutmak veya 200K+'ya gerçekten ihtiyaç olduğunu doğrulamak.

4.1. 128K threshold'da kalmanın taktikleri

1. Aggressive chunking + dynamic retrieval. Static document context yerine sorguya göre dinamik retrieve.
2. Summarization fallback. Eski conversation history'yi özetle, son 10 turn'ü full bırak.
3. Tool definition compression. JSON schema'ları sıkıştır (kısa anahtarlar, kısa descriptions).
4. Few-shot example reduction. 10 example yerine 3 yüksek-kaliteli.
5. System prompt audit. Her ay system prompt'unu gözden geçir, gereksiz kuralları çıkar.

Claude Opus 4.7, 2026 Mart'ta 1M context tier'ını GA'ya aldı. Standart 200K context'in 5 katı. Fiyatlandırma:

• 0-200K: Standart fiyat
• 200K-1M: 2x fiyat
• Cache hit: hâlâ %10 (1M tier'da bile)

1M context'in pratik use-case'leri:

• Tüm bir codebase'i context'e koy (orta-büyük: 500K-1M token)
• Multi-document research (10-20 büyük belge birden)
• Long-running agent memory (1-2 saatlik agent oturumlarının tüm geçmişi)
• Genomic/scientific data analysis

5.1. 1M Context + Cache Pattern

1M context'i her sorguda göndermek pahalı. Pattern:

1. İlk turn'de 1M context cache'e yazılır (cache write: $18.75/1M = $18.75)
2. Sonraki 5-10 turn cache hit (her biri $1.5)
3. Cache TTL 5dk → 5dk içinde 5+ turn varsa tasarruf büyük

Tipik long-research workflow'larda 20+ turn oluyor → cache ekonomisi pozitif.

Context engineering'in en az konuşulan ama en kritik kısmı: agent'ın çoklu turn arasında state'i nerede tutar?

6.1. Üç ana seçenek

6.2. Redis Pattern (Orta Ölçek)

In-memory + persistent — sıcak data Redis'te, snapshot'lar Postgres'e periyodik.

import redis
import json

r = redis.Redis(host="redis.internal", decode_responses=True)

def save_agent_state(thread_id: str, state: dict, ttl=3600):
    r.setex(f"agent:{thread_id}", ttl, json.dumps(state))

def load_agent_state(thread_id: str) -> dict:
    raw = r.get(f"agent:{thread_id}")
    return json.loads(raw) if raw else {}

KVKK için Redis'in AOF (Append-Only File) ile kalıcılığa yazılması ve disk encryption gerekli. Cloud Redis'te AWS ElastiCache, GCP Memorystore tercih edilir; Türkiye için BulutSpeed, Turkcell Bulut da kullanılabilir.

6.3. Postgres + LangGraph Checkpointer (Production)

from langgraph.checkpoint.postgres import PostgresSaver

checkpointer = PostgresSaver.from_conn_string(
    "postgresql://user:pass@postgres.internal:5432/agentdb"
)
app = workflow.compile(checkpointer=checkpointer)

# Otomatik: her node sonrası state Postgres'e yazılır.
# Thread_id ile resume edilebilir.

LangGraph checkpointer şunları otomatik sağlar:

• Her node sonrası state snapshot
• Thread_id bazlı resume
• Replay (geçmiş bir state'e dön, yeniden çalıştır)
• Audit log (her geçişin timestamp + state delta'sı)

6.4. State Pruning Stratejileri

Agent'lar uzun çalıştıkça state şişer. Üç pruning yaklaşımı:

1. Sliding window. Son N turn'ü tut, eskileri sil. Basit; ama uzun bağlam kaybeder.
2. Summarization. Eski turn'leri özetle, özet'i hafıza olarak tut. Bağlamı korur; LLM çağrısı maliyetli.
3. Hierarchical memory. Hot (son 10 turn), warm (özet), cold (vector DB). En ölçeklenebilir.

Türkçe, LLM tokenization'da İngilizceden ~%30 daha pahalıdır. Bu, context budget'ı doğrudan etkiler.

7.1. Tokenizer karşılaştırması

Aynı paragraph (250 İngilizce kelime ≈ 200 Türkçe kelime):

• GPT-4 tokenizer İngilizce: 312 token
• GPT-4 tokenizer Türkçe: 410 token (+%31)
• Claude tokenizer İngilizce: 295 token
• Claude tokenizer Türkçe: 385 token (+%30)
• Gemini tokenizer Türkçe: 360 token (+%22 — en iyi)

7.2. Türkçe için context budget planı

Aynı kullanım, %30 daha az effective context demek. Pratik etki:

• GPT-5.5 128K threshold → Türkçe için effective ~98K kelime
• Claude Opus 4.7 200K → Türkçe için effective ~150K kelime
• Gemini 3.1 Pro 2M → Türkçe için effective ~1.5M kelime

7.3. Türkçe için cache stratejisi

• System prompt'u kısa tut. Her 100 İngilizce kelime = 130 Türkçe kelime maliyeti.
• Tek dilli sistem promptu. Mixed Türkçe-İngilizce prompt cache miss riski yüksek (model versiyonlarında tokenization farkları olabilir).
• Cache breakpoint'leri Türkçe'de daha erken koy. Token sayısı hızlı artar; 50K token = ~38K kelime.

Production agent'larında kullandığım context hiyerarşisi:

Tier 1: Static (Asla Değişmez)

• System prompt
• Tool definitions
• Few-shot examples
• Brand guidelines

Cache stratejisi: En agresif (1-saat TTL eğer destekleniyorsa) TTL: Maximum

Tier 2: Semi-Static (Saatlik-Günlük)

• Document context (KB chunks)
• User profile
• Permissions

Cache stratejisi: 5-dakika TTL Refresh: TTL expire + manual invalidate (yeni belge yüklenince)

Tier 3: Dynamic (Turn Başına)

• Last user message
• Current timestamp
• Live API data
• Tool call results

Cache: Yok — her turn yeniden Cost: Standart fiyat

Bu hiyerarşi LangGraph'ta şöyle implement edilir:

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=2048,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,  # Tier 1
            "cache_control": {"type": "ephemeral"}
        },
        {
            "type": "text",
            "text": TOOL_DEFINITIONS,  # Tier 1
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": KB_CONTEXT,  # Tier 2
                    "cache_control": {"type": "ephemeral"}
                },
                {
                    "type": "text",
                    "text": user_query  # Tier 3
                }
            ]
        }
    ]
)

8.1. Dynamic Retrieval Pattern

Static document context yerine, query-time retrieve:

def build_context(user_query: str, conversation_history: list):
    # Tier 1: System + tools (cached)
    system_blocks = [
        {"type": "text", "text": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": TOOL_DEFS, "cache_control": {"type": "ephemeral"}},
    ]

    # Tier 2: Retrieved context (cached for 5min)
    retrieved = vector_db.search(user_query, top_k=10)
    kb_block = {
        "type": "text",
        "text": format_chunks(retrieved),
        "cache_control": {"type": "ephemeral"},
    }

    # Tier 3: Dynamic
    messages = conversation_history + [
        {"role": "user", "content": [kb_block, {"type": "text", "text": user_query}]}
    ]

    return system_blocks, messages

8.2. Summarization Fallback Pattern

Conversation history 50+ turn'e ulaştığında:

def maybe_summarize_history(history: list, threshold=50):
    if len(history) < threshold:
        return history
    # Eski turn'leri ozetle
    old_turns = history[:-10]
    summary = summarize_with_haiku(old_turns)
    return [{"role": "system", "content": f"Onceki konusma ozeti: {summary}"}] + history[-10:]

KVKK uyumu, state store seçimini doğrudan etkiler.

9.1. Veri yerleşimi

• Redis/Postgres Türkiye veya AB'de hosted
• AWS ElastiCache eu-central-1 (Frankfurt) tercih
• GCP Memorystore europe-west3 (Frankfurt)
• Azure Cache for Redis West Europe

Türkiye'de BulutSpeed, Turkcell Bulut, Garanti BBVA Teknoloji gibi yerel sağlayıcılar tercih ediliyor — özellikle BDDK kısıtlı sektörlerde.

9.2. State'te PII

Agent state'inde kişisel veri tutulması KVKK'nın özel kategorisine girer:

• Veri minimizasyonu. State'te sadece zorunlu PII (örn. user_id) tut. İsim, telefon, IBAN tutma.
• Şifreleme at-rest. Redis AOF + disk encryption, Postgres TDE (Transparent Data Encryption).
• Şifreleme in-transit. TLS zorunlu.
• Erişim logları. Hangi servis hangi state'e ne zaman erişti — Postgres audit extension veya Redis ACL log.
• Veri silme. Kullanıcı silme isteği (KVKK Madde 11) → 30 gün içinde state purge.

9.3. Cache'lerde PII

Anthropic cache'i, AB instance kullanılsa bile Anthropic'in sunucularında tutuluyor. Cache'lediğiniz context'te PII varsa bu, KVKK Madde 9 kapsamında yurt dışına aktarım sayılır.

Çözüm: PII'yi cache'e koymadan önce maskele:

def prepare_for_cache(text: str) -> str:
    # PII maskele (regex veya ML)
    text = mask_tc_kimlik(text)
    text = mask_phone(text)
    text = mask_email(text)
    text = mask_iban(text)
    return text

9.4. BDDK ve Türkiye Cumhuriyet Merkez Bankası Yaklaşımı

BDDK 2025 sonu rehberinde "AI sistemlerinde context cache" konusunu özel olarak ele aldı. Üç beklenti:

1. Cache içeriği inventory'lenmeli — hangi context, hangi TTL, hangi cache key
2. Cache temizleme prosedürü — incident veya audit talebinde 24 saat içinde
3. Cache audit log'u — hangi cache hit hangi user'a hizmet verdi

Bir orta-büyük Türk e-ticaret platformu (anonim), 2025'in son çeyreğinde naive prompt mimarisinden context-engineered mimariye geçti.

10.1. Önce

• Müşteri hizmetleri chatbot'u, GPT-4 ile çalışıyor
• Her turn'de 25K token system + KB context + history gönderiyor
• Cache yok — saf token billing
• Günlük 80K query → ~$120K/ay
• Latency p50 4.2s, p95 9.8s

10.2. Sonra (context engineering migration)

1. System prompt audit. 8K → 4K token (gereksiz kurallar temizlendi)
2. KB context dynamic retrieval. Static 15K → dynamic 4K (top-5 chunks)
3. Anthropic Claude Opus 4.7'ye geçiş (prompt caching için)
4. Cache breakpoint'leri: System (4K), tools (3K), conversation prefix
5. Conversation history summarization. 20+ turn'lerde otomatik özetleme
6. Redis state store (in-memory yerine — distributed deploy için)

10.3. Sonuç (3 ay sonra)

• Token per turn: 25K → 12K (-%52)
• Cache hit rate: %0 → %72
• Aylık maliyet: $120K → $34K (-%72)
• Latency p50: 4.2s → 1.8s (-%57)
• Latency p95: 9.8s → 3.4s (-%65)
• Customer satisfaction: 7.2/10 → 8.6/10
• Operational complexity: +%30 (cache invalidation, Redis ops)

Net: Maliyet -%72, gecikme -%60, satisfaction +20%. Operational complexity artışı kabul edilebilir.

11.1. Cache hit rate monitoring

Production'da metrikler:

• Cache hit rate (hedef: %60+)
• Cache TTL hit/expire ratio (hedef: hit > expire)
• Cache key cardinality (anormal artış → cache key drift)
• Cost per request (hedef: aylık azalış)

11.2. A/B test context engineering değişiklikleri

Cache pattern değişiklikleri, küçük bir değişiklikle %100 cache miss yaratabilir. A/B test zorunlu:

• %5 trafik yeni pattern'a
• Cache hit rate, cost, latency monitor
• 24-48 saat içinde rampa veya geri al

Context engineering'i production'a almanın yol haritası:

1. Audit (1 hafta). Mevcut LLM uygulamanın token kullanımı, cache hit rate (varsa), state store yapısını çıkar.
2. Tier'lama (1 hafta). Context'i Tier 1/2/3'e ayır. Cache breakpoint'leri yerleştir.
3. State store seçimi (1 hafta). Ölçek + KVKK gereksinimine göre Redis veya Postgres.
4. A/B canary deploy (1-2 hafta). %5 trafik, cache hit rate ve maliyet izle.
5. Tam rollout (1 hafta). Eval ile kalite doğrula, observability set et.
6. Monitoring + alerting (sürekli). Cache hit rate, cost per request, state store latency.

Toplam: ~6-8 hafta tipik bir orta-karmaşıklık uygulama için.

Sitedeki contact formundan ulaşabilirsiniz; context engineering audit veya implementation danışmanlığı için.

Bu rehber yaşayan bir belgedir; context engineering ekosistemi (caching, tier'lama, state stores) her çeyrek değişmektedir. Çeyreklik olarak güncellenmektedir.