Bağlam Mühendisliği ve Context

Bağlam mühendisliği (context engineering), bir dil modeline karar anında yalnızca göreve uygun, temiz ve doğrulanabilir bilgiyi verme disiplinidir. Amaç modele olabildiğince çok veri yığmak değil; doğru kaynağı, doğru sırayla ve izlenebilir biçimde önüne koymaktır. Bu yazıda terimin ne anlama geldiğini, bağlam penceresi büyüdükçe neden kalitenin düştüğünü ve üretim ortamında bağlamı küçültmek için kullanılan somut teknikleri anlatıyorum.

Kısa cevap: Model bir depolama alanı değil, sınırlı dikkat bütçesi olan bir işlemcidir. Bağlama ne kadar çok token koyarsanız, modelin oradaki bilgiyi doğru hatırlama yeteneği o kadar azalır. İyi bir kurulum bu yüzden «her şeyi yükle» yerine «ihtiyaç anında getir, işi bitince özetle, geri kalanı bağlam dışında sakla» ilkesiyle çalışır.

Bağlam Mühendisliği (Context Engineering) Nedir?

Bir gün kendi sistemimde çalışan otonom bir ajanı test ediyordum. Modele tüm veritabanını, geçmiş konuşma kayıtlarını ve kılavuzları yükledim. Sonuç: ajan basit bir soruya yüzlerce kelimelik gürültülü bir yanıt verdi. Sebep model değildi; ona gereksiz veri yükleyip dikkatini dağıtmamdı.

LLM'ler akıllı işlemciler gibidir, depolama alanları değil. Modelin performansı ona ne kadar çok veri verdiğinizle değil, karar anında önüne ne kadar temiz ve hedefe yönelik bağlam koyduğunuzla ölçülür. Geniş bağlam pencereleri her şeyi içine yükleme lüksü sunar, ama bu lüksü kullanmak gürültüyü artırır. Bağlam mühendisliği tam olarak bu lüksü kullanmama disiplinidir.

Context Mühendislik ve Prompt Mühendislik Arasındaki Fark

İki terim sık karıştırılır ama farklı şeyleri tarif eder. Anthropic'in ajanlar için etkili bağlam mühendisliği yazısı ayrımı şöyle koyar: prompt mühendisliği, modele verilen talimatların yazılması ve düzenlenmesiyle ilgilenir; bağlam mühendisliği ise çıkarım sırasında bağlama girecek token kümesinin tamamını seçme ve bakımını yapma stratejilerini kapsar — istemlerin dışında oraya düşen her şey dahil.

Aradaki asıl fark süreklilikte gizlidir. Prompt mühendisliği kesikli bir iştir: istemi yazarsınız, iyileştirirsiniz, biter. Bağlam mühendisliği ise yinelemelidir; ajan çalıştıkça neyin bağlamda kalacağına, neyin çıkarılacağına ve neyin özetleneceğine sürekli karar vermek gerekir. Tek seferlik bir sohbet uygulamasında ilk disiplin yeterlidir; çok adımlı, araç kullanan bir ajanda ikincisi olmadan sistem kararlı çalışmaz.

Pratik sonuç şudur: istemi mükemmelleştirmeye harcanan saatler, bağlama giren dosyaların seçimi bozukken sonuç vermez. Önce neyin girdiğine bakın, sonra nasıl söylendiğine.

LLM Bağlam Yönetimi: Dikkat Bütçesi ve Context Rot

LLM bağlam yönetiminin teknik gerekçesi somuttur. Anthropic'in aynı yazısı şunu belirtir: bağlam penceresindeki token sayısı arttıkça, modelin o bağlamdan bilgiyi doğru biçimde hatırlama yeteneği azalır. Bu olguya context rot (bağlam çürümesi) denir ve kaynağı mimaridir: transformer mimarisinde her token diğer tüm tokenlarla ilişkilendirilir, dolayısıyla ilişki sayısı token sayısının karesiyle büyür ve bu ilişkiler geniş bağlamda gerilir.

Aynı yazı kullanışlı bir benzetme kurar: insanların çalışma belleği sınırlı olduğu gibi, dil modellerinin de büyük hacimli bağlamı ayrıştırırken harcadıkları bir dikkat bütçesi vardır. Bütçe kavramı kararı basitleştirir: bağlama eklediğiniz her belge bedava değildir, başka bir şeyin payını azaltır. «Nasıl olsa pencereye sığıyor» cümlesi bu yüzden yanıltıcıdır; sığmak ile işe yaramak aynı şey değildir.

Bu, uzun bağlam pencerelerinin değersiz olduğu anlamına gelmez. Anlamı şudur: pencere kapasitesi bir tavandır, hedef değil. İyi tasarlanmış bir ajan, penceresinin küçük bir kısmını kullanarak çalışır ve büyük pencereyi ancak gerçekten gerektiğinde doldurur.

Bağlamı Küçültmenin Dört Tekniği

Anthropic'in yazısı, uzun soluklu ajanlarda bağlamı yönetmek için dört somut yaklaşım tarif eder:

• Sıkıştırma (compaction): Konuşma geçmişi modele verilip en kritik ayrıntıları koruyan bir özet ürettirilir; ajan bu özetle devam eder. Böylece süreklilik korunurken pencere sınırı aşılmaz.
• Yapılandırılmış not tutma: Ajan notlarını bağlam penceresinin dışında bir belleğe yazar ve gerektiğinde geri çağırır. Kalıcı hafıza, asgari ek yükle bu şekilde elde edilir.
• İhtiyaç anında getirme (just-in-time retrieval): Tüm veriyi önceden yüklemek yerine ajana hafif tanımlayıcılar verilir — dosya yolları, kayıtlı sorgular, bağlantılar — ve veri çalışma anında araçlarla bağlama alınır.
• Alt ajan mimarileri: Odaklı görevler uzmanlaşmış alt ajanlara verilir; her alt ajan geriye yalnız damıtılmış bir özet döndürür (yazıda tipik olarak 1.000-2.000 token aralığı verilir). Ana ajanın bağlamı böylece ayrıntıyla değil sonuçla dolar.

Dördü de aynı ilkenin farklı yüzleridir: ayrıntıyı bağlamda değil, dışarıda tut; bağlama yalnız kararı etkileyeni al. Not tutma ve ihtiyaç anında getirme ikilisi, kişisel bilgi sistemlerinde Karpathy'nin LLM Wiki deseni ile de örtüşür: bilgi bir kez derlenip kalıcı dosyalara yazılır, her sorguda ham yığından yeniden türetilmez.

Alt Ajanlarla Bağlam Bölmenin Ölçülmüş Bedeli ve Faydası

Dört teknik içinde en çok yanlış anlaşılanı alt ajan mimarisidir, çünkü hem en büyük kazancı hem en büyük maliyeti taşır. Anthropic'in çoklu ajan araştırma sistemi üzerine yazısı her iki tarafı da ölçmüştür. Kazanç tarafında: ana ajan olarak Claude Opus 4, alt ajan olarak Claude Sonnet 4 kullanan çoklu ajan sistemi, tek ajanlı Claude Opus 4'ü araştırma değerlendirmesinde %90,2 farkla geçmiştir. Bunun sebebi alt ajanların kendi bağlam pencerelerinde paralel çalışarak sıkıştırma sağlamasıdır; her biri konunun farklı bir yönünü tek başına araştırır ve ana ajanın penceresine yalnız sonucu taşır.

Maliyet tarafı da aynı yazıda açıkça verilir: token tüketimi tek başına başarı farkının %80'ini açıklar; ajanlar sohbet kullanımına göre yaklaşık 4 kat, çoklu ajan sistemleri ise yaklaşık 15 kat token harcar. Bu iki rakam birlikte okunduğunda ortaya pratik bir kural çıkar: alt ajan bölmesi, çıktının değeri bu tüketimi karşıladığında meşrudur. Araştırma, karşılaştırma ve geniş tarama işlerinde karşılar; tek bir kaydı güncellemek gibi dar işlerde karşılamaz.

Bölmenin bağlam mühendisliği açısından asıl kazancı token sayısında değil izolasyondadır. Alt ajanın bulduğu ham malzeme ana ajanın penceresine hiç girmez; ana ajan yalnız damıtılmış sonucu görür. Bu yüzden alt ajanın geriye ne döndürdüğü, kaç alt ajan çalıştırdığınızdan daha önemlidir. Ham çıktısını olduğu gibi döndüren bir alt ajan, çözmek için kurulduğu sorunu büyütür: ana ajanın bağlamı artık hem kendi hem alt ajanın ayrıntısıyla doludur.

Sıkıştırma Ne Zaman Zarar Verir?

Sıkıştırma güçlü bir tekniktir ama bedelsiz değildir: özet çıkarmak, hangi ayrıntının önemsiz olduğuna karar vermektir ve bu karar geri alınamaz. Bir konuşmada müşterinin ikinci mesajda geçerken söylediği bir kısıt özete girmezse, on adım sonra ajan o kısıtı ihlal eden bir öneri üretir ve nedenini kimse anlamaz. Sıkıştırmanın sessiz zararı budur: kayıp anında değil, çok sonra ve başka bir yerde ortaya çıkar.

Bu riski azaltmanın üç yolu vardır. Birincisi, ham geçmişi silmemek: özet bağlama girer, ham kayıt bağlam dışında saklanır ve gerektiğinde geri çağrılabilir. İkincisi, özetin neyi korumak zorunda olduğunu şablonla sabitlemek — taahhütler, kısıtlar, kimlik bilgileri, verilen kararlar. Modele «önemli olanı özetle» demek yerine hangi alanların taşınacağını yazmak, kaybı öngörülebilir kılar. Üçüncüsü, sıkıştırmayı her adımda değil eşiğe bağlı yapmak: pencere doluluğu belirli bir orana ulaştığında devreye giren bir sıkıştırma, sürekli çalışan bir özetleyiciden daha az bilgi eritir.

Genel kural şudur: sıkıştırma bir hafıza yönetimi aracıdır, bir temizlik aracı değil. Bağlamda gereksiz duran belgeler sıkıştırılarak değil, oraya hiç konulmayarak çözülür.

Model Context Protocol (MCP) ve LLM Bağlantıları

İhtiyaç anında getirme ilkesinin işlemesi için modelin veriyi kendi başına alabilmesi gerekir. Eskiden veri kopyala-yapıştır ile modele verilirdi ya da her kaynak için ayrı bir entegrasyon yazılırdı. Model Context Protocol (MCP), bu bağlantıyı tek bir açık sözleşmede standartlaştıran bir protokoldür ve yapay zekâ uygulamaları için «USB-C portu» benzetmesiyle anlatılır.

Bunun bağlam mühendisliği açısından anlamı şudur: model artık statik bir sohbet robotu değil, ihtiyacı olan veriyi çalışma anında bulabilen bir bileşendir. Böylece «ne olur ne olmaz» diye önceden yüklenen dosyalar gereksizleşir. Veri kaynaklarını ajanlara bağlarken izlenecek yolu MCP ile veritabanı bağlama yazısında adım adım anlattım.

Çalışılmış Örnek: Şişmiş Bir Ajanı Küçültmek

Başlangıç durumu: Müşteri sorularını yanıtlayan bir ajan; her çağrıda ürün kataloğunun tamamı, son 50 mesajlık konuşma geçmişi ve 12 sayfalık iç kılavuz bağlama yükleniyor. Yanıtlar uzun, bazen eski fiyatları kullanıyor ve maliyet her çağrıda aynı.

1. Adım — ihtiyaç anında getirmeye geçiş: Katalog bağlamdan çıkarılır; yerine ajana bir arama aracı verilir. Ajan yalnız sorulan ürünün kaydını çeker. Bağlamdaki katalog payı sıfıra iner, doğruluk artar çünkü çekilen kayıt her zaman güncel olandır.

2. Adım — sıkıştırma: 50 mesajlık geçmiş yerine, konuşmanın kritik kararlarını taşıyan bir özet tutulur (müşterinin kim olduğu, hangi ürünle ilgilendiği, hangi taahhütlerin verildiği). Ham geçmiş silinmez, bağlam dışında saklanır.

3. Adım — kılavuzun bölünmesi: 12 sayfalık kılavuzun tamamı her soruda gerekmez. Kılavuz konu başlıklarına bölünür ve ajan yalnız ilgili bölümü çeker. İade politikası sorulduğunda kargo bölümü bağlama girmez.

4. Adım — ölçüm: Değişiklik öncesi ve sonrası aynı 30 soruluk test seti koşturulur. Karşılaştırılan şey yalnız maliyet değil, yanlış yanıt sayısıdır.

Kritik nokta: Bu dört adımın hiçbiri modeli değiştirmedi. Aynı model, daha az ve daha isabetli bağlamla daha iyi çalıştı. «Daha güçlü modele geçelim» kararı, bağlam düzeltilmeden alınırsa pahalı bir erteleme olur.

Etkin Bir Bağlam Yönetimi Nasıl Tasarlanır?

• Sınırları net çizin: Dokümanların tamamını göndermeyin. Sorguya en yakın birkaç bölümü seçip enjekte edin; geri kalanı modele gürültüden başka bir şey vermez.
• Durumu dosyada tutun: Ajanın kurallarını ve geçmiş durumunu bağlam içinde taşımak yerine düz metin dosyalarında saklayın. Model bu dosyaları okur ve günceller; bağlam her koşumda sıfırdan şişmez.
• Kaynağı yanıtla birlikte taşıyın: Üretim sisteminde talep önce sınıflandırılır, sonra yalnız ilgili notlar getirilir ve kullanılan pasaj yanıtla birlikte izlenir. Bu, yanlış dosyadan çıkarım yapılmasını ve eski bir kararın güncel gerçek gibi kullanılmasını görünür kılar.
• Karşıt ajan testleri: Bağlam sistemini yayına almadan önce başka bir ajana verip açıklarını aramasını isteyin. Hangi durumda yanlış dosyanın çekildiğini çoğu zaman ancak böyle görürsünüz.
• Rol ayrımı yapın: Her ajan yalnız kendi işi için gereken araca ve dosyaya erişsin. Bunun üretim ortamındaki karşılığını çoklu ajan mimarisi ve kararlılık yazısında ele aldım.

Bu ilkeler uygulanırken en çok tartışılan karar, veriyi önceden yüklemek ile çalışma anında getirmek arasındaki tercihtir. İkisinin de meşru olduğu durumlar vardır ve seçimi belirleyen üç ölçüt şudur. Birincisi öngörülebilirlik: her istekte kesinlikle gereken küçük bir çekirdek bilgi varsa (marka sesi kuralları, güvenlik sınırları, çıktı biçimi) onu her seferinde aramak boş yere gecikme üretir; bu çekirdek önceden yüklenir. İkincisi hacim: gereken bilgi büyükse ve isteklerin çoğunda yalnız küçük bir kısmı kullanılıyorsa önceden yükleme dikkat bütçesini boşa harcar; ihtiyaç anında getirme doğru seçimdir. Üçüncüsü tazelik: fiyat, stok, durum gibi sık değişen veriler önceden yüklendiğinde bayat bilgi riski doğar ve model kendinden emin biçimde eski gerçeği söyler.

Bu üç ölçüt çoğu zaman aynı yönü gösterir: küçük ve sabit olan yüklenir, büyük ve değişken olan çekilir. Karışık kaldığı durumlarda karar test setiyle verilir — aynı sorular iki kurulumla koşturulur ve yanlış yanıt sayısı karşılaştırılır. Sezgiye dayanan tercihlerin çoğu bu karşılaştırmada yanılır; özellikle «garanti olsun» diye yapılan önceden yüklemeler, ölçüldüğünde çoğu zaman doğruluğu düşürmüş çıkar.

Bir uyarı da mimari değişikliklerin sırası hakkındadır. Bağlamı küçültmeye kaynak seçiminden değil, hiç kullanılmayan belgeleri çıkararak başlayın. Kaynak seçimini iyileştirmek zor bir iştir; oysa çoğu kurulumda bağlamın önemli bir kısmını hiçbir yanıtta kullanılmayan dosyalar oluşturur ve bunları çıkarmak tek bir ölçüm gerektirir. Kolay kazanç tükenmeden zor işe girişmek, hem zaman hem de ölçüm netliği kaybettirir.

• Değişiklikleri teker teker yapın. Aynı anda hem kaynak seçimini hem sıkıştırmayı hem araç katmanını değiştirirseniz, sonuç iyileşse de hangi değişikliğin işe yaradığını bilemezsiniz. Bağlam mühendisliğinde ilerleme, tek değişkenli ölçümlerin birikmesiyle olur.

Ölçüm ve Veri: Bağlam Kalitesi Nasıl Ölçülür?

Bağlam mühendisliğinde ilerlemeyi «daha iyi hissettiriyor» ile ölçmek mümkün değildir. Sabit bir test seti ve dört ölçüt gerekir:

Bu dördü birlikte okunur. Token düşerken yanlış yanıt artıyorsa fazla kırpmışsınızdır; token yüksek ama kaynak isabeti düşükse bağlama giren belgelerin çoğu boşuna oradadır. Her değişiklikten sonra aynı test seti koşturulmadığında, iyileştirme yaptığınızı sanarak gerileyebilirsiniz.

Hata Desenleri ve Sık Görülen Riskler

• Pencereyi hedef sanmak. Bağlam penceresinin büyük olması onu doldurmak için bir gerekçe değildir; token arttıkça hatırlama doğruluğu düşer.
• Her şeyi önceden yüklemek. «Ne olur ne olmaz» diye eklenen dosyalar hem dikkat bütçesini yer hem de bayat bilgi riskini doğurur.
• Geçmişi ham hâliyle taşımak. Uzun konuşmalarda ham geçmiş yerine sıkıştırılmış özet taşımak, sürekliliği korurken pencereyi serbest bırakır.
• Kaynağı yanıttan koparmak. Hangi pasajın kullanıldığı kaydedilmezse yanlış yanıtın nereden geldiği sonradan bulunamaz.
• Modeli suçlamak. Kötü yanıtların çoğu model yetersizliğinden değil, bağlam seçiminden doğar. Model değiştirmeden önce bağlamı ölçün.
• Alt ajanlardan ayrıntı istemek. Alt ajan geriye ham çıktısını döndürürse ana ajanın bağlamı yine şişer; dönen şey damıtılmış özet olmalıdır.

Araçlar, Kaynaklar ve Sonraki Adım

Başlangıç için karmaşık bir altyapı gerekmez. İhtiyacınız olan üç şey vardır: bağlama neyin girdiğini görebildiğiniz bir kayıt, sabit bir test seti ve veriyi çalışma anında çekebilen bir araç katmanı. Üçü kurulduktan sonra sıkıştırma, not tutma ve alt ajan bölmesi sırayla eklenir.

Bu sıralamanın kendisi de bir tasarım kararıdır. Kayıt olmadan yapılan her iyileştirme tahmindir; test seti olmadan yapılan her karşılaştırma izlenimdir. Araç katmanı ise diğer tekniklerin ön koşuludur: ihtiyaç anında getirme, modelin veriyi kendi çekebilmesine bağlıdır. Sıkıştırmayı en başa koyan kurulumlar, henüz hangi bilginin gerçekten gerektiğini bilmeden özet üretmeye başladıkları için çoğu zaman yanlış şeyi korur. Alt ajan bölmesini en sona bırakmanın sebebi de aynıdır: bölme, ölçülmüş bir darboğazın çözümü olduğunda değer üretir, mimari bir refleks olduğunda yalnız token tüketimini artırır.

Son bir hatırlatma: bağlam mühendisliği bir kez yapılıp bitirilen bir kurulum işi değildir. Veri kaynaklarınız değişir, kullanıcıların sorduğu sorular kayar, modelin sürümü güncellenir. Bu değişkenlerin her biri bağlam seçiminin isabetini etkiler. Bu yüzden test setini canlı tutmak ve düzenli aralıklarla yeniden koşturmak, ilk kurulumu doğru yapmaktan daha belirleyicidir. İyi çalışan sistemleri kötülerden ayıran şey genellikle daha zekice bir başlangıç tasarımı değil, ölçmeye devam etme alışkanlığıdır.

Sonraki adım olarak kendi sisteminizde tek bir ölçüm yapın: bir isteğe giren bağlamı yazdırın ve içindeki her belgenin yanıtta gerçekten kullanılıp kullanılmadığını işaretleyin. Çoğu kurulumda bu ilk ölçüm, bağlamın yarısından fazlasının hiçbir işe yaramadığını gösterir. Bilgiyi kalıcı biçimde derleyip her sorguda yeniden türetmemenin nasıl kurulduğunu yapay zekâ tabanlı ikinci beyin sistemi yazısında, kurumsal tarafta belge tabanlı yanıt üretimini ise RAG mimarisi ve kurumsal bilgi bankaları yazısında bulabilirsiniz.