Büyük dil modelleri (LLM) metin uretirken aslinda tek bir girdiyi okumaz; bağlam penceresi icindeki tüm tokenleri dikkat mekanizmasi uzerinden agirliklandirir. Context engineering, bu pencereyi bilincli olarak tasarlayarak modelin doğru bilgiye erismesini, gereksiz gurultuyu elemeyi ve tutarlı cevaplar uretmesini hedefleyen disiplindir. Prompt yazmak kadar önemli olan sey, hangi bilginin ne sırada ve ne formatta modele sunuldugudur.
Bağlam penceresi ve token ekonomisi
Her modelin sabit bir context limiti vardir: GPT-4o sinifinda modeller 128K tokena kadar destek verse de, pratikte gecikme ve maliyet token sayisiyla dogrusal veya ustel artar. Üretim ortamlarinda ortalama bir kurumsal soru-cevap akisinda sistem promptu, kullanıcı mesaji, önceki konusma gecmisi, RAG ile gelen doküman parcalari ve arac ciktisi ayni pencerede yarismaktadir. Token butcesi tasarımı yapilmadan olceklendirilen sistemlerde ya en eski mesajlar kesilir ya da en önemli doküman parcalari hic eklenmez.
Tipik bir dagilim soyle planlanabilir: sistem talimatlari yüzde on ile yirmi, kullanıcı sorusu yüzde bes ile on, gecmis konusma yüzde yirmi ile otuz, bilgi tabani parcalari yüzde otuz ile kirk bes, arac ciktilari yüzde bes ile on bes. Bu oranlar sabit degildir; destek botunda gecmis konusma onemliyken, tek seferlik analiz gorevlerinde neredeyse tamamini doküman parcalarina ayirmak mantiklidir.
Olcekte gozlemlenebilir metrikler
- Context utilization rate: Gonderilen toplam token / model limiti. Yüzde seksenin uzerinde sürekli çalışan servislerde truncation riski yüksektir.
- Signal-to-noise ratio: Alakali parça sayisi / toplam parça sayisi. RAG pipeline'inda düşük kalite chunklar bu orani dusurur.
- Prompt cache hit rate: Destekleyen saglayicilarda sabit sistem promptu cache'lenir; cache hit maliyeti dusurur ve gecikmeyi azaltir.
- Lost-in-the-middle skoru: Bilgi pencerenin ortasina yerlestirildiginde modelin hatirlama basarisini olcen benchmark sonuclari.
Bağlam katmanlarini ayirmak
Saglam bir context engineering mimarisi genelde dört katmandan olusur. Sistem katmanı rol, ton, güvenlik sınırları ve çıktı formatini tanimlar; nadiren degisir ve cache icin idealdir. Oturum katmanı kullanıcının gecmis mesajlarini tutar; burada sliding window veya ozetleme stratejisi sarttir. Bilgi katmanı RAG, veritabanı sorgusu veya API cevaplarini icerir; en cok değişen ve en cok hata kaynagi olan bolumdur. Arac katmanı function calling sonuclarini, JSON semalarini ve hata mesajlarini tasir.
Katmanları tek bir dev metin olarak birlestirmek yerine yapilandirilmis bloklar halinde sunmak, modelin ayrim yapmasini kolaylastirir. Örneğin XML benzeri etiketler veya Markdown basliklari tutarlılık sağlar:
<system>
Sen kurumsal IT destek asistanisin. Yalnizca verilen kaynaklara dayan.
</system>
<retrieved_docs>
[1] VPN kurulum kilavuzu: ...
[2] Sifre sifirlama proseduru: ...
</retrieved_docs>
<conversation>
Kullanici: VPN baglanamiyorum
Asistan: Hangi istemci surumunu kullaniyorsunuz?
</conversation>
<user_query>
Hata kodu 809 aliyorum
</user_query>Lost in the middle ve konum stratejisi
Liu ve arkadaslarinin 2023 calismasi, LLM'lerin uzun baglamda ortadaki bilgiyi kenarlara kiyasla daha zayif isledigini gosterdi. Bu bulgu pratik tasarım kararlarini dogrudan etkiler: en kritik talimatlar pencerenin basina, en güncel kullanıcı sorusu sona konumlandirilmalidir. RAG parcalari arasinda en yüksek skorlu olanlar basa ve sona yerlestirilir; düşük guvenilirlikteki parçalar ortada birakilir veya tamamen elenir.
Bir destek senaryosunda sistem promptu ve güvenlik kurallari her zaman ilk blokta kalir. Retrieve edilen on doküman parcasindan ilki ve sonuncusu en yüksek cosine benzerligine sahip olanlar secilir; aradaki sekiz parça relevance skoruna gore siralanir ama kritik prosedur adimlari ozetlenerek kisaltilir. Bu yaklaşım hem token tasarrufu sağlar hem de modelin prosedure uygun adimlari kacirmasini azaltir.
Konusma gecmisi yönetimi
Uzun sohbetlerde tüm gecmisi gondermek hem pahali hem de kaliteyi dusurur. Iki ana strateji vardir: sliding window ve ozetleme (summarization). Sliding window son N mesaji tutar; basit ama erken baglami kaybeder. Ozetleme, eski turlari kisa bir ozete indirger; ekstra LLM çağrısı gerektirir ama uzun oturumlarda daha iyi sonuç verir.
Hibrit model uygulanabilir: son dört mesaj ham halde kalir, daha eski mesajlar her on turda bir arka planda ozetlenir. Özet promptu su ilkelere uymali: yalnizca dogrulanmis bilgileri koru, spekulatif ifadeleri at, kullanıcının açık hedefini vurgula. Özet kalitesini olcmek icin summary fidelity testi yapilir: ozetten uretilen cevaplar tam gecmisle uretilen cevaplarla karsilastirilir.
Token butcesi kod ornegi
Asagidaki Python pseudocode, parcalari öncelik ve token limitine gore birlestirir:
def build_context(system, history, chunks, user_msg, max_tokens=12000):
budget = {"system": 2000, "history": 3000, "chunks": 6000, "user": 1000}
parts = []
parts.append(truncate_tokens(system, budget["system"]))
ranked = sorted(chunks, key=lambda c: c.score, reverse=True)
head = ranked[:2]
tail = ranked[-2:] if len(ranked) > 4 else []
middle = [c for c in ranked if c not in head + tail][:4]
ordered = head + middle + tail
chunk_text = format_chunks(ordered)
parts.append(truncate_tokens(chunk_text, budget["chunks"]))
parts.append(truncate_tokens(summarize_history(history), budget["history"]))
parts.append(truncate_tokens(user_msg, budget["user"]))
return "\n\n".join(parts)Prompt sablonlari ve degisken enjeksiyonu
Context engineering ile prompt engineering ic ice gecer. Sablonlarda degisken alanlar açıkça ayrilmali; kullanıcı girdisi hicbir zaman sistem talimatlariyla ayni string birlestirme isleminde kontrolsuz birakilmamali. Prompt injection saldirilarina karşı kullanıcı metni ayri bir blokta tutulur ve sistem promptunda kaynak onceligi vurgulanir: verilen dokumanlar kullanıcı mesajindan ustundur.
Format talimatlari spesifik olmalidir. Belirsiz ifadeler yerine JSON semasi, madde isareti sayisi veya kelime limiti verilir. Örneğin müşteri analiz ciktisi icin schema tanımlamak, serbest metin istemekten daha tutarlıdır. Structured output veya JSON mode destekleyen modellerde şema dogrulamasi sunucu tarafinda tekrarlanir; model hatasi kullanıcıya yansitilmadan retry yapilir.
Üretim tuzaklari ve onleme yontemleri
Birinci tuzak, farklı ekiplerin ayni servise tutarsiz sistem promptlari eklemesidir. Merkezi bir prompt registry ve versiyonlama olmadan A/B testleri bile güvenilir olmaz. Ikinci tuzak, RAG parcalarinin kaynak etiketlerinin kaybolmasidir; model uydurma bilgi urettiginde hangi dokumandan sapildigi izlenemez. Her parça numaralandirilmali ve cevapta referans istenmelidir.
Üçüncü tuzak, arac ciktilarinin sinirsiz buyumesidir. Bir SQL sorgusu binlerce satir donebilir; bunu dogrudan modele vermek pencereyi doldurur. Arac ciktilari sunucu tarafinda ozetlenmeli, sayisal sonuçlar tablo yerine istatistik olarak sunulmalidir. Dördüncü tuzak, cok dilli ortamlarda dil karisikligi yasamaktir. Sistem promptunda yanıt dili sabitlenmeli; retrieve edilen Ingilizce dokumanlar gerekiyorsa cevirme adimi ayri bir pipeline asamasidir.
Değerlendirme ve iterasyon
Context tasarımını olcmek icin offline veri seti sarttir. Her ornekte soru, beklenen kaynak ve beklenen cevap bulunur. Değişiklik sonrasi recall@k, faithfulness ve answer relevance metrikleri karsilastirilir. LangSmith, Phoenix veya açık kaynak Ragas gibi araclar bu metrikleri otomatiklestirir. Uretimde ise latency p95, token maliyeti ve kullanıcı geri bildirim orani birlikte izlenir.
Context engineering tek seferlik bir prompt yazma isi degildir; model guncellemeleri, yeni doküman turleri ve değişen kullanıcı davranislari tasarımı sürekli gunceller. Her major model versiyonunda regression testi calistirmak, geçiş maliyetini erken yakalar. Küçük modellerde çalışan bağlam stratejisi büyük modellerde daha iyi sonuç verebilir; tersi de mumkundur cunku dikkat dagilimi mimariye gore degisir.
Özet karar cercevesi
Baglami doğru kurmak icin once bilgi onceliklerini yazili hale getirin: hangi kaynaklar birbirini ezer, hangi bilgi eksikse cevap uretilmemeli. Token butcesini katmanlara bolun ve kritik içeriği kenarlara yerlestirin. Gecmisi yonetirken ham mesaj ile özet arasinda bilincli seçim yapin. Tüm parcalari etiketleyin ve üretim metriklerini prompt versiyonuyla birlikte loglayin. Bu disiplin, ayni modeli kullanan iki ekibin neden farklı kalite seviyesine ulasabildigini aciklar: fark çoğu zaman modelde degil, baglamda saklidir.
