Yapay Zekâ Pilotlarını Prompt Değil Bağlam Kurtarıyor

Prompt yazmaktan bağlam kurmaya geçiş

Kısa süre öncesine kadar şirket içi yapay zekâ eğitimlerinin yıldızı “iyi prompt yazmak”tı. Hangi kelimeyi seçeceğiniz, örnekleri nasıl dizeceğiniz, modele hangi rolü vereceğiniz konuşuluyordu. Drew Breunig'in yayımladığı The State of Context Engineering yazısı, bu dönemin kapandığını oldukça net bir zaman çizelgesiyle anlatıyor.

Breunig'e göre 2023'te tek bir model çağrısı için doğru kelimeleri ve örnekleri seçmek prompt mühendisliğiydi. 2025'te iş bağlam mühendisliğine dönüştü: modelin bağlam penceresi dinamik olarak dolduruluyor ve bunu bir insan elle yazmıyor, sistem kendisi derliyor. 2026'da bu işin daha büyük kısmı bağlamdan çıkıp koda taşındıkça adı “harness engineering” oldu, yani modeli saran düzeneğin mühendisliği.

Farkı en sade anlatan tanım Elastic Search Labs yazısında. Prompt mühendisliği “Bunu nasıl ifade etmeliyim?” diye sorar, bağlam mühendisliği ise “Model şu anda hangi bilgiye erişebilmeli?” diye. Biri tek bir soruyla ilgilenir, diğeri tüm sistemdeki bilgi akışıyla. DataHub de prompt mühendisliğini bağlam mühendisliğinin bir alt kümesi olarak tarif ediyor: neyin getirileceğine, neyin sıkıştırılacağına, neyin bir sonraki adıma taşınacağına ve neyin atılacağına karar veren daha geniş bir iş.

Modelin önündeki masa: bağlam neyden oluşur?

Teknik olmayan biri için en kullanışlı benzetme bir çalışma masası. Yapay zekâ her adımda yalnızca masasına konmuş kâğıtları görür, arşivdeki diğer dosyalar onun için yoktur. Bağlam mühendisliği, o masaya hangi belgelerin, hangi araçların ve hangi talimatların konacağına karar verme işidir.

Anthropic, çok adımlı ve uzun süre çalışan ajanlar için bağlamın tamamının yönetilmesi gerektiğini söylüyor. Masadaki başlıca kalemler aşağıdakiler.

LangChain bağlam mühendisliğini, ajanın işinin her adımında pencereyi tam gereken bilgiyle doldurmak olarak tanımlıyor. Buradaki “her adımda” ifadesi önemli. Bir müşteri şikâyetini çözen ajan önce sipariş kaydına, sonra iade politikasına, sonra kargo durumuna ihtiyaç duyar; üçünü de baştan masaya yığmak işi kolaylaştırmaz, çoğu zaman bulandırır.

• Sistem talimatları: ajanın rolü, sınırları ve nasıl davranacağı.
• Araçlar: ajanın çağırabildiği fonksiyonlar, örneğin sipariş sorgulama ya da takvim okuma.
• Model Context Protocol (MCP) üzerinden bağlanan sistemler.
• Dış veriler: aranıp getirilen belgeler, kayıtlar, tablolar.
• Mesaj geçmişi ve bellek: önceki konuşmalar, kaydedilmiş notlar, kullanıcı tercihleri.

Kötü bağlam yapay zekâyı nasıl yanıltır?

Breunig'in uzun bağlamların nasıl bozulduğunu anlatan önceki yazısı dört hata türü tanımlıyor. Her birinin şirket içinde tanıdık bir karşılığı var.

Ajanlar daha uzun süre çalıştıkça iki yeni hata türü de görünür hale gelmiş. daily.dev özetine göre “ağırlıklarla kavga” modelin eğitimde öğrendiklerine geri dönmesi, “bağlam ataleti” ise ajanın bir fikre takılıp bırakamaması anlamına geliyor. Aynı özete göre Anthropic'in Memento düzeneği ataletle başa çıkmak için çalışma ortamını koruyup bağlamı her 90 dakikada bir temizliyor.

Bu listenin bence en büyük faydası, “yapay zekâ yine saçmaladı” şikâyetini teşhis edilebilir bir sorun haline getirmesi. Pilotta yanlış bir cevap geldiğinde ilk soru “model mi kötü” olmamalı, “o anda masada ne vardı” olmalı. Çoğu vakada cevap ikinci sorudan çıkıyor.

• Bağlam zehirlenmesi: bir halüsinasyon bağlama girer ve sonraki adımlarda doğruymuş gibi tekrar tekrar referans alınır. Örnek: ajanın uydurduğu bir sözleşme maddesi özet notlarına geçer ve sonraki yazışmalarda kaynak gibi kullanılır.
• Bağlam dikkat dağınıklığı: bağlam o kadar büyür ki modelin eğitimde öğrendiklerini bastırır, model önündeki yığını tekrarlamaya başlar.
• Bağlam karışıklığı: gereksiz bilgi cevabı etkiler. Örnek: görevle ilgisi olmayan onlarca aracın tanımı masada durduğu için ajan yanlış aracı çağırır.
• Bağlam çatışması: bağlamın parçaları birbiriyle çelişir. Örnek: iade süresinin hem 14 hem 30 gün yazdığı iki ayrı politika belgesi aynı anda getirilir.

Milyon token'lık pencere neden kurtarmıyor?

Akla ilk gelen kısa yol şu: madem modellerin bağlam penceresi büyüdü, her şeyi verelim, model ayıklasın. Breunig'in konuşması tam tersini savunuyor. daily.dev özetine göre uzun bağlam pencereleri güvenilirliği düzeltmiyor, yalnızca daha fazla hatanın içeri girmesine izin veriyor.

Bunu destekleyen en çok alıntılanan çalışma Chroma'nın Temmuz 2025 tarihli “Context Rot” raporu. WinBuzzer'ın aktardığına göre araştırmacılar 18 önde gelen modeli test etmiş. LongMemEval testinde modeller, yalnızca en ilgili alıntılar verildiğinde, konuşma geçmişinin tamamı verildiğinden tutarlı biçimde daha iyi sonuç vermiş. Araştırmacıların kendi çıkarımı da sonuçların bağlam mühendisliğinin önemine işaret ettiği yönünde.

Anthropic'in önerisi dengeli bir yerde duruyor: beklenen davranışı tam olarak tarif eden en küçük bilgi setini hedefleyin, ama en küçüğün kısa olmak zorunda olmadığını unutmayın. Pratikte bunun anlamı şu. Görev için on sayfalık bir prosedür gerçekten gerekiyorsa koyun; “belki lazım olur” diye eklenen yüz sayfa ise işe yaramadığı gibi zarar veriyor.

Ekiplerin kullandığı teknikler, sade dille

Breunig konuşmasında ekiplerin bu hatalara karşı kullandığı altı çözümü sayıyor, LangChain ise teknikleri yazmak, seçmek, sıkıştırmak ve izole etmek olarak dört kovaya ayırıyor. İsimler farklı olsa da anlatılan iş aynı: masaya doğru şeyi koymak, gereksizini kaldırmak, büyüyeni küçültmek ve birbirine karışmaması gerekenleri ayırmak.

Bellek tarafında öğretici bir örnek var. ZenML'in vaka özetine göre Anthropic'in Applied AI ekibi her oturumun başında yüklenen basit markdown dosyalarıyla başlamış. Bu yapı zamanla sürüm takibi, eşzamanlılık kontrolü ve yetkilendirmesi olan dosya sistemi tabanlı bir belleğe dönüşmüş. Üstüne bir de “rüya görme” süreci eklenmiş: ajanlar geçmiş oturum kayıtlarını gözden geçirip belleğin nasıl iyileştirileceğine dair öneriler getiriyor.

Bu örnekten çıkardığım iki ders var. Birincisi, basit başlamak ayıp değil; bir metin dosyasıyla başlayan bellek, ihtiyaç doğdukça büyüyebilir. İkincisi, bellek büyüdüğü anda belgelerle aynı yönetişim sorularını doğuruyor: kim yazabilir, kim okuyabilir, hangi sürüm geçerli.

• Zenginleştirme (augmentation): soruyla ilgili belgeyi arayıp getirmek; yaygın adıyla RAG.
• Araç seçimi (tool loadout): o görev için yalnızca gereken araçları masaya koymak.
• Karantina: alt görevleri ayrı bağlamlarda çalıştırmak. LangChain'in örneğinde her alt ajanın kendi araçları, talimatları ve bağlam penceresi var.
• Budama (pruning): eskimiş ya da alakasız bilgiyi bağlamdan çıkarmak.
• Dışarı yazma (offloading): bilgiyi bağlam yerine bir dosyaya veya not alanına yazıp gerektiğinde geri çağırmak.
• Özetleme: uzayan geçmişi kısa ve işe yarar bir özete indirmek.

Asıl iş teknik değil, kurumsal

Redis'in 2026 raporu ilginç bir zihniyet değişimini kaydediyor: liderler hayal kırıklığı yaratan ajan davranışı için artık modeli değil bağlamı suçluyor ve ileriye giden yol olarak daha büyük modeller yerine taze, gezilebilir bağlamı öne koyuyor. Aynı ankette en olgun kuruluşların yüzde 69'u kritik kararları hâlâ bayat veriyle beslediğini söylüyor. Yüzde 60'ı bağlama kimin ve neyin erişebileceğini yönetmekte etkisiz olduğunu kabul ediyor, bağlamının iyi yönetildiğinden emin olanlar ise yalnızca yüzde 58.

Atlan aynı soruna başka bir açıdan bakıyor: prompt'ların içine yazılan iş kuralları zamanla eskiyor, denetlenemiyor, sürümlenemiyor ve ajanlar arasında paylaşılamıyor. Somut bir senaryo düşünün. İskonto sınırı bir ajanın talimatına elle yazılmış, finans politikayı değiştirmiş, kimsenin aklına o talimatı güncellemek gelmemiş. Atlan'ın önerdiği yol, tanımları, metadata'yı, veri soy ağacını ve yönetişim politikalarını tüm ajanlara hizmet eden kalıcı bir altyapıda tutmak.

Bu noktada iş, mühendislik ekibinin tek başına çözebileceği bir şey olmaktan çıkıyor. Üç kurumsal görev öne çıkıyor ve üçü de iş tarafının sahiplenmesini gerektiriyor.

Redis anketinde katılımcıların yüzde 73'ü gezilebilir bağlam sistemlerinin deneysel yapay zekâ ile üretimdeki yapay zekâ arasındaki çizgi haline geldiğine katılıyor. Yüzde 69'u sistemler arasında gezinemeyen bir ajanı halüsinasyon gören bir ajandan daha tehlikeli buluyor. Pilotunuz canlıya çıkamıyorsa, sorunu modelde aramadan önce bu çizgiye bakmakta fayda var.

• Doküman hijyeni: aynı prosedürün üç farklı sürümü ortalıkta dolaşıyorsa, bağlam çatışması kaçınılmazdır. Eski sürümleri arşivlemek, sıkıcı ama en yüksek getirili iştir.
• Erişim kontrolü: ajan, onu kullanan kişinin göremeyeceği bir belgeyi masaya getirmemeli. Maaş tablosu, disiplin dosyası, henüz duyurulmamış fiyatlar ilk akla gelenler.
• Bilgi sahipliği: her belge setinin güncel tutulmasından sorumlu, adı belli bir kişi ya da birim olmalı. Sahibi olmayan bilgi, bağlamı en hızlı bayatlatan bilgidir.

Doğru bağlamı aldığını nasıl anlarsınız?

Kaynaklarda herkesin kullandığı standart bir ölçüm seti yok; aşağıdakiler sahada işe yaradığını gördüğüm, mühendis olmayan birinin de takip edebileceği basit göstergeler. Hepsinin ortak noktası, cevabın kalitesinden önce masanın kalitesine bakmaları.

En öğretici test, Chroma'nın bulgusunu kendi verinizde tekrarlamak. Aynı soru setini bir kez tüm geçmiş ve belgelerle, bir kez yalnızca en ilgili birkaç parçayla çalıştırın. Kısa bağlam daha iyi sonuç veriyorsa, sisteminiz masaya fazla şey yığıyor demektir.

Genel memnuniyet puanı tek başına yanıltıcıdır. Kullanıcılar akıcı ama yanlış cevaplardan da memnun kalabiliyor; bayat bir politika belgesine dayanarak verilen kendinden emin bir cevap, ancak biri dönüp kaynağına bakınca fark ediliyor.

• Kaynak isabeti: örnek bir soru setinde, getirilen belgelerin kaçı o soruyla gerçekten ilgiliydi? Elle kontrol edilecek birkaç düzine soru başlangıç için yeterli.
• Kaynak tazeliği: getirilen belgelerin ne kadarı geçerli, güncel sürüm?
• Çelişki sayısı: aynı konuda birbirine zıt bilgi veren belge çiftleri tespit edildi mi, ayıklandı mı?
• Doğru “bilmiyorum” oranı: bilgi gerçekten yokken ajan bunu söylüyor mu, yoksa boşluğu dolduruyor mu?
• İnsan düzeltme oranı: ajanın çıktılarından ne kadarı bir çalışan tarafından düzeltilmek zorunda kalıyor ve düzeltmelerin nedeni eksik mi, yanlış mı, eski mi bilgi?
• Yetki ihlali denemeleri: test kullanıcılarıyla, görmemeleri gereken belgeleri ajana sordurup sonucu kaydedin.

Operasyon ve ürün liderleri için kontrol listesi

Bir yapay zekâ pilotunu onaylamadan ya da genişletmeden önce aşağıdaki soruların cevabı masada olmalı. Bunların hiçbiri kod yazmayı gerektirmiyor, ama hepsi teknik ekibin işini kolaylaştırıyor.

Bir uyarı da eklemek gerekiyor: bu düzenin hepsi her iş için şart değil. Bir çalışanın genel bir sohbet aracıyla e-posta taslağı yazması ya da bir metni özetletmesi için iyi bir talimat hâlâ yeterli. Bağlam mühendisliği, iç veriyle çalışan, birden fazla adım atan ve sonucu bir kararı etkileyen sistemlerde belirleyici hale geliyor. Pilotunuz bu tarife uyuyorsa, bütçenin ve dikkatin önemli bir kısmını modele değil, modelin önüne koyacağınız bilgiye ayırın.

Anthropic'in talimatlar için önerdiği “doğru irtifa” ilkesi burada da geçerli: ne her ihtimali önceden kodlayan kırılgan kurallar yazın, ne de modelin sizin şirket bilginizi paylaştığını varsayan belirsiz yönergelerle yetinin.

• Ajan hangi görevi yapacak ve bu görevin her adımında hangi bilgiye ihtiyaç duyacak? Liste halinde yazıldı mı?
• Kullanılacak belgelerin envanteri çıkarıldı mı, eski ve çelişen sürümler ayıklandı mı?
• Her belge seti için güncellemekten sorumlu bir sahip atandı mı?
• Ajan, kullanıcının yetkisi olmayan bilgiye erişemeyecek şekilde mi kuruldu?
• İş kuralları prompt'lara gömülü mü, yoksa güncellenebilir ve denetlenebilir bir yerde mi tutuluyor?
• Ajanın kullanabileceği araçlar görevle sınırlı mı?
• Uzun süren işlerde geçmiş nasıl özetleniyor ya da temizleniyor?
• Yukarıdaki ölçümlerden en az ikisi için bir başlangıç değeri alındı mı?
• Hatalı bir cevap geldiğinde, o anda ajanın önünde hangi bağlam olduğunu görebiliyor musunuz?