Prompt Engineering Öldü, Context Engineering Geldi: Modelin

Büyük dil modellerine (LLM) süslü sıfatlar ve sihirli kelimeler fısıldayarak mucizevi çıktılar alma dönemi kapandı. Bugün yapay zeka entegrasyonlarında başarının anahtarı, modele ne kadar yaratıcı bir “prompt” yazdığınız değil; modelin kısıtlı bellek penceresine (context window) hangi veriyi, hangi sıra ve biçimle soktuğunuzdur. Ben buna context engineering diyorum ve bu disiplin, prompt yazarlığının yerini alan gerçek bir yazılım ve sistem mimarisi disiplinidir.

Sistem ve backend tarafında 20 yılı deviren biri olarak söylüyorum: Yapay zekayı kurumsal sistemlere entegre ederken yaşadığımız sorunların kabaca tamamı “yanlış prompt” yüzünden değil, “kirli ve kontrolsüz context” yüzünden çıkıyor. Modelin önüne ne koyarsanız onu çiğner. Eğer önüne bütün veritabanını kontrolsüzce yığarsanız, hem faturayı şişirirsiniz hem de modelin kafasını karıştırıp yanlış kararlar vermesine (hallucination) sebep olursunuz.

Prompt engineering neden yetersiz kalmaya başladı?

Prompt engineering, modellerin context pencerelerinin küçük olduğu ve mantık yürütme (reasoning) yeteneklerinin emekleme aşamasında olduğu dönemde işe yarayan geçici bir çözümdü. O dönemde “Adım adım düşün”, “Sen bir finans uzmanısın” gibi şablonlarla modeli yönlendirmek bir fark yaratıyordu çünkü modelin elindeki tek kılavuz bu kelimelerdi. Ancak modeller geliştikçe ve context pencereleri yüz binlerce tokene ulaştıkça, bu kelime oyunlarının etkisi belirgin şekilde azaldı.

Bugün karşılaştığımız en büyük sorun promptun kendisi değil, context pencerelerinin büyümesiyle ortaya çıkan “lost in the middle” (ortada kaybolma) fenomenidir. Araştırmalar ve sahada yaptığımız testler net bir gerçeği gösteriyor: LLM’ler kendilerine verilen context’in başındaki ve sonundaki bilgilere odaklanma eğilimindedir; ortadaki devasa veri yığınını ise çoğunlukla görmezden gelirler. Süslü bir prompt yazıp altına 50 sayfalık dökümanı kontrolsüzce yapıştırırsanız, modelin ortalarda bir yerde yazan kritik bir iş kuralını atlama ihtimali çok yüksektir.

Context engineering nedir ve neyi amaçlar?

Context engineering, modele gönderilecek verinin filtrelenmesi, yapılandırılması, önceliklendirilmesi ve en optimize şekilde paketlenmesi sürecidir. Amacı, modele sadece ve sadece o anki görevi tamamlaması için gereken en rafine bilgiyi sunarak gecikmeyi (latency) düşürmek, maliyeti azaltmak ve çıktı kalitesini maksimuma çıkarmaktır. Bu bir kelime sanatı değil, veri boru hattı (data pipeline) tasarımıdır.

İyi bir context tasarımı yaparken veriyi ham haliyle bırakmayız. Veritabanından gelen satırları, logları veya dökümanları temizler, gereksiz gürültüden (boilerplate kodlar, tekrarlayan başlıklar, gereksiz metadata alanları) arındırırız. Ardından bu veriyi modelin en hızlı ve doğru şekilde parse edebileceği Markdown veya yapılandırılmış JSON formatına dönüştürürüz.

graph TD;
A["Ham Veri Kaynakları"] --> B["Veri Temizleme & Chunking"]
B --> C["Metadata Zenginleştirme"]
C --> D["Vektör Veritabanı (RAG)"]
D --> E["Context Re-ranking (Reranker)"]
E --> F["LLM Context Window"]

RAG mimarilerinde context tasarımı nasıl yapılır?

Retrieval-Augmented Generation (RAG) sistemleri kurarken yapılan en büyük hata, vektör veritabanından gelen ilk 5-10 sonucu doğrudan modelin önüne atmaktır. Sadece kosinüs benzerliğine (cosine similarity) güvenerek context oluşturursanız, modelin önüne birbirini tekrar eden veya tamamen alakasız veriler yığabilirsiniz. Bu durum hem token maliyetini artırır hem de modelin kafasını karıştırır.

RAG mimarisinde context’i tasarlarken şu adımları uygulamak zorundayız:

1. Semantic Chunking (Anlamsal Parçalama): Dökümanları sadece karakter sınırına (örneğin her 1000 karakterde bir) göre bölmek anlamsal bütünlüğü bozar. Bunun yerine paragrafları, Markdown başlıklarını veya kod bloklarını takip eden akıllı chunking stratejileri kullanmalıyız.
2. Metadata Enrichment (Metadata Zenginleştirme): Her veri parçasına (chunk) hangi dökümana ait olduğu, oluşturulma tarihi, yetki seviyesi gibi etiketler eklenmelidir. Model, önüne gelen bilginin bağlamını bu etiketlerden okuyabilmelidir.
3. Re-ranking (Yeniden Sıralama): Vektör veritabanından dönen sonuçları, anahtar kelime ve semantik uyumu optimize eden bir reranker modelinden (örneğin Cohere veya BAAI reranker) geçirerek en alakalı ilk 3 sonucu seçmeliyiz.

Token ekonomisi ve context window limitleri nasıl yönetilir?

Bağlam pencerelerinin büyümesi, onları sınırsızca kullanabileceğimiz anlamına gelmez; çünkü token maliyetleri ve ağ gecikmesi hala doğrusal (bazen de üstel) olarak artmaktadır. Üretim ortamında çalışan bir sistemde her istekte 100 bin token göndermek, hem cüzdanınızı hızlıca boşaltır hem de kullanıcı deneyimini (TTFT - Time to First Token) mahveder. Bu yüzden context boyutunu dinamik olarak yönetmek kritik bir sistem mühendisliği görevidir.

Bu durumu yönetmek için “Prompt Caching” (Prompt Önbelleğe Alma) mekanizmalarından yararlanıyoruz. Eğer sisteme gönderdiğimiz sistem talimatları ve sabit dökümanlar değişmiyorsa, bunları destekleyen API sağlayıcılarında (örneğin Anthropic veya OpenAI) cache’leyerek sonraki isteklerde ciddi bir maliyet ve hız avantajı elde ediyoruz. Ayrıca, kullanıcı geçmişini saklarken “sliding window” (kayan pencere) mantığıyla sadece son N adet mesajı context’te tutup, daha eski mesajları özetleyerek tek bir token bloğu haline getirmeliyiz.

# Context optimizasyonu için basit bir sliding window ve özetleme mantığı
def build_context(user_history, current_query, max_tokens=4000):
    context = []
    current_tokens = count_tokens(current_query)
    
    # En son mesajları önceliklendirerek geriye doğru tara
    for message in reversed(user_history):
        msg_tokens = count_tokens(message["content"])
        if current_tokens + msg_tokens < max_tokens:
            context.insert(0, message)
            current_tokens += msg_tokens
        else:
            # Sınırı aşan eski mesajları özet servisinden geçir veya atla
            context.insert(0, {"role": "system", "content": "[Eski konuşmaların özeti...]"})
            break
            
    context.append({"role": "user", "content": current_query})
    return context

LLM agent mimarisinde state ve memory yönetimi nasıl olmalıdır?

Otonom ajanlar (agents) tasarlarken, ajanın geçmişte yaptığı eylemleri ve bunların sonuçlarını hatırlaması gerekir. Ancak bu “bellek” (memory) kontrolsüz büyürse, ajan bir süre sonra kendi döngüleri içinde kaybolur. Memory yönetimi, context engineering’in en karmaşık alanlarından biridir.

Ajan mimarilerinde state verisini Redis veya PostgreSQL gibi hızlı ve kalıcı veri depolarında tutuyoruz. Her adımda tüm geçmişi ajana göndermek yerine, ajanın o anki “state” durumunu temsil eden minimalist bir JSON objesi tasarlıyoruz. Örneğin bir e-ticaret iade ajanı tasarlıyorsak, ajanın context’inde tüm sohbet geçmişi yerine sadece aşağıdaki gibi temiz bir state objesi bulunmalıdır:

{
  "current_step": "verify_invoice",
  "invoice_id": "INV-2026-0042",
  "verification_status": "pending_user_signature",
  "attempts": 2
}

Bu yapılandırılmış veri, ajanın her seferinde ne yapacağını şaşırmadan, doğrudan iş mantığına (business logic) odaklanmasını sağlar.

Gerçek bir üretim ERP’sinde context engineering uygulaması

Bir üretim ERP’sinde, operatörlerin makinelerdeki arıza kodlarını analiz etmesi ve bakım ekiplerine otomatik iş emri açması için bir yapay zeka asistanı tasarlamıştık. İlk denemelerimizde, makineden gelen tüm sensör loglarını ve geçmiş bakım dökümanlarını ham haliyle LLM’e gönderiyorduk. Sonuç tam bir fiyaskoydu: Model sürekli yanlış arıza teşhisleri koyuyor, üstelik her sorgu saniyeler sürüyordu.

Sorunu çözmek için klasik prompt değiştirmeyi bıraktık ve context pipeline’ını baştan tasarladık. Öncelikle sensör verilerini normalize ettik; sadece sapan (anomaly) değerleri context’e ekledik. Bakım dökümanlarını ise hata kodlarına göre indeksleyip, sadece o anki hata koduyla eşleşen paragrafları aldık.

# ERP Context Hazırlama Pipeline Örneği
def prepare_operator_context(machine_id, error_code):
    # 1. Sadece aktif ve sapan sensör verilerini al (Gürültüyü azalt)
    telemetry = get_active_anomalies(machine_id) 
    
    # 2. Hata koduna özel geçmiş bakım kayıtlarını filtrele
    history = query_maintenance_db(error_code, limit=2)
    
    # 3. Context'i modelin en iyi anladığı Markdown formatında birleştir
    context = f"""
    # MACHINE STATUS: {machine_id}
    Active Anomalies: {telemetry}
    
    # RELEVANT MAINTENANCE HISTORY FOR ERROR {error_code}:
    {history}
    """
    return context

Bu yapısal değişiklikten sonra, modelin doğru teşhis koyma oranı belirgin şekilde arttı ve token tüketimini kabaca üçte birine düşürdük.

Sonuç

Net pozisyonum şudur: Yapay zeka projelerinde başarı, kelime cambazlığıyla değil, veri mühendisliğiyle gelir. Prompt yazmayı bir kenara bırakın; veriyi filtrelemeye, önceliklendirmeye ve modelin önüne en rafine haliyle koymaya odaklanın. Context’i doğru yönettiğinizde, en vasat model bile bir dahiye dönüşebilir; context’i kirlettiğinizde ise en gelişmiş model bile size çöp üretmekten başka bir şey sunmaz.