25  Bağlam Mühendisliği

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 25. bölüm. Ölçümlerde qwen3.5:9b, ollama 0.24.0 üzerinden, gerçek Türkçe haberlerin içine gömülmüş uydurma olgularla sınandı; böylece doğru bir cevap ancak bağlamdan gelmiş olabilir. Bu bölüm, Bölüm 23’teki bir bulgunun doğal sonucudur: transkript, ajanın durumunun kendisidir. Çalıştırmalar arasında neyin kaldığını Bölüm 26 ele alıyor. Uzun bağlam deneyini yeniden koşarsanız bir tekrarlanabilirlik notu: ollama, sunulan num_ctx’ten (bağlam uzunluğu ayarı) uzun bir prompt’u (istemi) sessizce kırpar ve hiçbir uyarı vermez. Bu ayarı en uzun koşulunuzun üstünde açıkça belirleyin ve sunulan uzunluğu varsaymak yerine doğrulayın. Sessizce 4 bine kesilmiş 11 bin token’lık bir prompt artık uzun bağlam koşulu değildir; kesinti bir iğneyi (aranan olguyu) de silmiş olabilir. Bu durumda ne düz bir eğriye ne de bir düşüşe güvenebilirsiniz. Yazılım: NumPy 2.5.2, Python 3.14.5.

Öğrenme hedefleri. Bu bölümün sonunda:

25.1 Kap değil, bütçe

Önce ayrımı koyalım: prompt tasarımı (Bölüm 17) tek bir talimatın nasıl yazılacağıyla ilgilenir; bağlam mühendisliği ise her model çağrısında pencereye neyin girdiğini — sistem prompt’u, araç tanımları, erişilen belgeler, geçmiş — ve neyin dışarıda kaldığını yönetir.

Pencere genellikle bir kapasite olarak tarif edilir: 200 bin token, yani 200 bin token sığdırabilirsiniz. Bu çerçeve önemli bir noktada yanlıştır: tek sorunun bir şeylerin sığıp sığmadığı olduğunu düşündürür.

Önceki bölümlerden üç sonuç aksini söylüyor ve birlikte pencereyi her token’ın yarıştığı bir bütçe olarak görmenin gerekçesini kuruyorlar:

  • Bölüm 20 seçmemenin bedelini ölçtü: önemli olan tek belge yerine seksen belge birebir aynı doğruluk için 148 kat girdi token’ına mal oldu. Modelin fazlalıktan kafası karışmadı. Siz yalnızca bedelini ödediniz; her istekte, sonsuza kadar.
  • Bölüm 23, bir ajanda bağlamın bir kez hazırlayıp değişmeden bıraktığınız bir girdi olmadığını gösterdi: transkript durumun kendisidir, yalnızca büyür ve her model çağrısı hepsini yeniden gönderir.
  • Bölüm 24, bu yüzden bir aracın dönüş değerinin o duruma yapılan bir yazma işlemi olduğunu gösterdi. 50.000 token döndüren bir araç, bu nedenle sonraki adımların ihtiyaç duyacağı yeri kaplayabilir ve sonraki her çağrıya taşınır.

Yani soru bir değil ikidir: “sığıyor mu” — kapasite gerçek bir kısıt — ve sığan her şey için “her token ne kazandırıyor”. Kimsenin sormadığı ise ikincisidir.

Bu bakış açısı değişikliğinin hemen ortaya çıkan pratik bir sonucu var: ikinci soruyu ölçüm altyapısı kurmadan cevaplayamazsınız. Bağlam mühendisliğindeki ilk hamle bir teknik değil, kategori bazında bir bütçedir: kaç token sistem prompt’una, araç tanımlarına, erişilen belgelere, gözlemlere, geçmişe gitti? O sayımı ilk kez yapan neredeyse herkes, varlığından haberi olmadığı ve tahmin edemeyeceği bir kategoriyle karşılaşır.

İnsanları şaşırtan kategoriler, kabaca sıklık sırasına göre: her çağrıda yeniden gönderilen ve araç sayısıyla ölçeklenen araç tanımları; aylardır kimsenin okumadığı talimatlar biriktirmiş bir sistem prompt’u; ve k’sı bir kez ayarlanıp bir daha gözden geçirilmemiş erişilen belgeler. Bunların hiçbiri saymadan görünmez.

25.1.1 Aritmetiği değiştiren tek şey

Bu hesabı kullanmadan önce bir çekinceyi belirtelim. Sağlayıcılar bir prompt’un ön ekini önbelleğe alır (prompt önbellekleme, prompt caching): değişmemiş bir sistem prompt’u ve araç bloğu, sonraki çağrıda yeniden gönderildiğinde ilk çağrı fiyatının bir kesriyle faturalanır ve prefill’in (ilk çıktı token’ından önce prompt’u okuyan geçişin) çoğunu atlar — Bölüm 31, önbellekteki bir ön ekle prefill süresini prompt uzunluğundan bağımsız olarak 12–16 ms’de sabit ölçtü. Yani “her token her çağrıda yeniden gönderilir” ifadesi token’lar için tam olarak doğru, fatura için yalnızca kısmen.

Neden yalnızca ön ek? Çünkü attention (dikkat mekanizması) nedensel (causal) çalışır: i. token için saklanan anahtar ve değerler, yani Bölüm 7.6’daki KV önbelleği, kendisinden önceki her token’a bağlıdır. Tek bir token’ı değiştirirseniz ondan sonraki her şey yeniden hesaplanmak zorundadır; ondan öncesi ise olduğu gibi yeniden kullanılabilir. Pratik kurallar bu tek olgudan çıkar (mekanizma Bölüm 31.5’te anlatılıyor). Ön ek bayt bayt aynı olmalıdır; sistem prompt’unun başına yakın bir zaman damgası ya da kullanıcı adı, altındaki her şey için önbelleği sessizce kapatır. Ayrıca bir önbellek kaydı varsayılan olarak birkaç dakika kullanılmayınca silinir ve bazı sağlayıcılar önbelleğe yazmak için ek ücret alır.

Kısa bir sistem prompt’unda hiç önbellek isabeti görmüyorsanız önce iki şeye bakın. Sağlayıcıların çoğu önbelleğe almak için asgari bir ön ek uzunluğu ister (tipik olarak bin token ve üstü; kesin eşik sağlayıcıya ve modele göre değişir). Bazı API’lerde de önbellek kesme noktasını istekte açıkça işaretlemeniz gerekir. İkisi için de kullandığınız sağlayıcının belgelerine bakın.

Etkinin büyüklüğünü bir örnek somutlaştırır. Sistem prompt’u ve araç tanımları toplam 5.000 token olan, 10 model çağrılık bir ajan çalıştırması düşünün ve 2026 fiyat listelerinde tipik olan çarpanları kullanın (sağlayıcıya ve modele göre değişir): önbelleğe yazma normal girdi fiyatının 1,25 katı, önbellekten okuma 0,1 katı. Önbelleksiz, sabit kısım 10 × 5.000 = 50.000 girdi token’ının fiyatına mal olur. Önbellekle 1,25 × 5.000 + 9 × 0,1 × 5.000 = 10.750 token’ın fiyatına — yani aynı token’lar için yaklaşık 4,7 kat daha ucuz.

Bundan iki sonuç çıkıyor ve ikisi de token kesmenin, ham sayının düşündürdüğünden daha az kazandırdığını gösteriyor. Sabit maliyetler göründüklerinden ucuzdur; dolayısıyla sistem prompt’unu budamak, token sayısını adım sayısıyla çarparak bulunan rakamdan daha az kazandırır. Ve sıkıştırma önbelleği geçersiz kılar: bir bağlamın ortasını yeniden yazmak, önbellekteki ön eki o noktadan itibaren kullanılamaz hâle getirir; yani sıkıştırmadan sonraki ilk çağrı, yeniden yazılan noktadan sonraki her şey için tam fiyat — varsa yazma ücretiyle birlikte — öder. Bağlamı yapabildiğiniz yerde yalnızca ekleme yapılan (append-only) biçimde tasarlayın — durağan ön ek, büyüyen son ek, en sonda yinelenen görev — ve sık sık küçük adımlarla değil, seyrek olarak büyük adımlarla sıkıştırın.

Neye bakacağız. Önce uzun bağlamların gerçekten bozulup bozulmadığına: bu bölümün kendi ölçümü hiçbir şey bulmuyor, yayımlanmış benchmark’lar (kıyaslamalar) ise bir çöküş buluyor — ve bu uyuşmazlığın nedeni, o alt bölümdeki en işe yarar şey. Sonra dört tekniğe: sıkıştırma, yani neyi kaybedeceğinizi önceden seçmeniz gereken kayıplı bir özetleme problemi; yalıtım, yani çoğu zaman elinizdeki en büyük kaldıraç; her şeyi önden yüklemek yerine tam zamanında erişim; ve transkriptin taşıyamayacağı bilgiyi koymak için bir yer olarak dosya sistemi. Son olarak da bunların hepsinin yine de başarısız olduğu duruma bakacağız: verinin aslında hiç metin olmadığı duruma.

25.2 Uzun bağlam gerçekten bozuluyor mu?

Yukarıdaki bütçe argümanı parayla ilgili. İkinci ve daha gürültülü bir iddia var — uzun bağlamların doğruluğu bozduğu — ve birincisinden ayrı tutulmayı hak ediyor, çünkü ikisi farklı mühendisliğe götürüyor.

Bölüm 20 bunu sınadı ve hiçbir şey bulmadı: 640 sorgu, on altı koşul, 16.775 token’a kadar, her bağlam boyutunda ve her konumda %100. Bu bölüm için daha zor bir yerel sürüm çalıştırdık — bulunup toplanacak bir değil iki uydurma rakam — ve eğri yine esasen düzdü:

qwen3.5:9b, 60 tasks, two invented figures to find and sum

 distractor docs  accuracy   95% CI          prompt tokens
               0    100.0%   [94.0, 100.0]             142
               4     93.3%   [84.1,  97.4]             863
              12     88.3%   [77.8,  94.2]           2,319
              28     88.3%   [77.8,  94.2]           5,228
              60     96.7%   [88.6,  99.1]          11,048

Altmış dikkat dağıtıcılı koşul, on ikilikten yüksek puan aldı. Bu monoton olmayan biçim gürültüyle tutarlı, ama gürültü olduğunu kanıtlamıyor — içeriğin ya da konumun gerçek bir etkisi de monoton olmak zorunda değil. Kısacası 78 kat token eklemek, bu örneklemin saptayabileceği bir fark yaratmadı — ki bu, koşulların eşdeğer olduğunun kanıtı değildir — ve ortadaki çukur, 60 görevin her iki yönde de ayırt edebileceği sınırın tam üstünde.

Aralıklar büyük ölçüde örtüşüyor, ama örtüşen aralıklar bir test değildir; o yüzden gerçek bir test yapalım. En büyük fark, 0’a karşı 12 dikkat dağıtıcı (60/60’a karşı 53/60), aynı 60 görev üzerinde; dolayısıyla doğru araç eşleştirilmiş (paired) testtir: yedi uyuşmazlığın hepsi aynı yöne gidiyor ve kesin (exact) McNemar testi iki yönlü \(p = 2 \times 2^{-7} = 0{,}0156\) veriyor. (İki koşulu bağımsız örneklemler sayan Fisher’ın kesin testi 0,013 veriyor — burada sonuç yakın, ama veriyi yanlış modelliyor.) Dört karşılaştırma için Bonferroni eşiği 0,0125’tir; fark iki testte de bu eşiği geçemiyor, o yüzden bunu bir sonuç diye öne sürmüyoruz. Manşetin dayandığı karşılaştırma, yani 0’a karşı 60 dikkat dağıtıcı, p = 0,50 veriyor.

25.2.1 Kolay test neden hiçbir şey bulmuyor

Bu daha gürültülü iddianın adı bağlam çürümesidir (context rot): her şey hâlâ pencereye sığsa bile, girdi büyüdükçe modelin doğruluğu azalır. Bağlam çürümesinin folklor olduğu sonucuna varmak rahat olurdu. Değil. Terimi yaygınlaştıran rapor olan Hong vd. (2025), 18 öncü modeli bilerek basit tutulmuş görevlerde, ilan edilen pencerelerin içinde kalan uzunluklarda koşturdu ve deneylerinin hepsinde girdi büyüdükçe performansın bozulduğunu buldu. Bu iki deney onu bir değil iki nedenle kaçırdı.

Önce basit olan neden: 11.048 token, yayımlanmış benchmark’ların manşetteki düşüşleri raporladığı uzunluğun yaklaşık üçte biri; yani bu deney onların ölçtüğü rejime hiç girmedi. İkinci neden daha ilginç, çünkü kurum içi değerlendirmelerin çoğu, o uzunluğa ulaştığında bile etkiyi aynı nedenle kaçırır.

İki test de birebir eşleşmeye izin verdi. İkisi de needle-in-a-haystack (NIAH, samanlıkta iğne) testiydi: tek bir olgu — iğne — uzun bir dolgu metninin — samanlığın — içine saklanır ve modelden onu bulması istenir. Soru ZRG-14 içeriyordu; iğne de. Attention, sorguda zaten bulunan nadir bir dizgiyi bulmakta son derece iyidir. Modarressi vd. (2025) tam da bu koltuk değneğini kaldırmak için kuruldu — iğneleri soruyla asgari sözcüksel örtüşme paylaşıyor, dolayısıyla model ilişkiyi eşleştiremiyor, çıkarsamak zorunda kalıyor — ve sonuç çarpıcı: 128K bağlam iddia eden 13 modelin 11’i, 32K token’da kısa bağlamdaki kendi baseline’larının (taban puanlarının) yarısının altına düşüyor. Yarının üstünde kalan iki istisnadan biri olan GPT-4o bile %99,3’ten %69,7’ye iniyor.

Hsieh vd. (2024) aynı yere farklı bir yönden varıyor ve tuzağı açıkça belirtiyor: modeller sade needle-in-a-haystack’te neredeyse kusursuz puanlar gösterirken, testi aramanın ötesine — çok adımlı izlemeye ve toplulaştırmaya (aggregation) — genişleten benchmark’ta neredeyse hepsinde bağlam uzadıkça büyük düşüşler ortaya çıkıyor. 32K veya fazlasını iddia eden 17 model içinde yalnızca yarısı 32K’da tatmin edici performansı koruyor.

İkisini birleştiren bir sentez, her birinden tek başına daha yararlıdır:

Üç görev, aynı pencere hakkında üç farklı cevap
ne ölçtüğünüz ne bulacağınız
Sorguda geçen nadir bir dizgiyi bulmak burada sınanan uzunluklarda bozulma ya yok ya da çok az; buradaki iki testin ve sade NIAH’ın ölçtüğü budur
Bilgiyi dizgi eşleşmesiyle değil anlamla bulmak kademeli bozulma; en büyüğü ölçüldüğü yerde: 32K’ya gelindiğinde 13 modelin 11’i kısa bağlam baseline’ının yarısının altına inmiş oluyor; düşüş orada başlamıyor, daha önce başlıyor (Modarressi vd. 2025)
Birkaç olgu üzerinden izleme ya da onları toplulaştırma büyük bozulma, daha erken başlıyor (Hsieh vd. 2024)

Bir modelin ilan edilen bağlam uzunluğu bir kapasitedir, bir yetkinlik değil — modelin etkin bağlam uzunluğu ise ampirik bir niceliktir ve genellikle çok daha kısadır.

Etkin bağlam uzunluğu (effective context length) — modelin kabul ettiği uzunluğun aksine, hâlâ iyi performans gösterdiği uzunluk. Çoğu zaman ilan edilen pencereden çok daha kısadır. ↩︎

Bunun mekanik nedeni ne olabilir. Genellikle iki mekanizma öne sürülür ve bunlar kanıtlanmış değil, akla yatkın açıklamalardır — aşağıdakilerin hiçbiri bu bölümde ölçülmedi. Attention ağırlıkları bağlamdaki her anahtar üzerinde alınan bir softmax’tır; dolayısıyla her yeni anahtar, olasılık kütlesinin dağılabileceği bir yer daha demektir — seyrelme. Bunun bir özdeşlik değil bir eğilim olduğuna dikkat edin: payda büyürken skorlar sabit durmaz ve daha uzun bir bağlamda ilgili token’ı daha yüksek puanlamayı öğrenen bir model payını koruyabilir ya da artırabilir. Birebir bir dizgi eşleşmesi muhtemelen daha iyi dayanır, çünkü anlamsal bir çağrışımın ürettiği birkaç orta skora karşılık tek bir büyük skor üretir — ama büyük bir skor da seyrelir: hedef logiti \(a\) ve \(N\) eşit dikkat dağıtıcı logiti \(b\) iken hedefin ağırlığı \(e^{a}/(e^{a} + N e^{b})\)’dir ve \(a - b\) farkı sonlu olduğu sürece \(N\) büyüdükçe yine düşer. Bunu burada ölçülmemiş, olası bir mekanizma sayın. Ayrıca ilan edilen pencerelerin birçoğu yalnızca kısmen eğitilmiş pencerelerdir. 8K’da ön eğitilmiş bir model, genellikle RoPE konumları yeniden ölçeklenerek (Position Interpolation, YaRN — Bölüm 7.4) ve uzun girdiler üzerinde görece kısa bir ek eğitimle 128K’ya uzatılır. Bu işe yarar, ama model uzun mesafelerin kısa mesafelere göre çok daha az örneğini görmüştür ve kalite mesafeyle düşme eğilimindedir. Kapasite, yetkinlik değil ifadesinin altında yatan olası mekanizma budur.

Yayımlanmış bir sonuç ters yönü gösteriyor ve akılda tutmaya değer. Shi vd. (2023), aritmetik problem metinlerine eklenen alakasız cümlelerin doğruluğu ciddi biçimde düşürdüğünü buldu — üstelik suçlanacak bir uzunluk artışı olmadan. Bizim dikkat dağıtıcılarımız doğruluktan hiçbir şey götürmedi, onlarınki çok şey götürdü — fark görevde. Dikkat dağıtıcılar iş birebir bir dizgiyi bulmak olduğunda ucuzdur, akıl yürütmek olduğunda pahalıdır; çünkü akıl yürütürken neyin ilgili olduğuna karar vermek gerekir, birebir eşleşmede gerekmez.

Sizi rahatlatacak olan yaygın test — needle-in-a-haystack — tam da tasarımına gömülü sözcüksel örtüşme yüzünden kolay olan testtir. Bu alt bölümden uygulamaya dönük tek bir şey alacaksanız bu olsun: uzun bağlamı kendi görevinizde, soruları kendi sözcüklerinizle yeniden ifade ederek (paraphrase) değerlendirin; asla birebir eşleşmelerle değil, çünkü birebir eşleşme sürümü geçer ve size hiçbir şey söylemez.

Bu, Bölüm 20’nin dersinin gerçek paraya mal olduğu bir yerde yeniden karşımıza çıkması: her şeyin geçtiği bir test, test değildir. Yerel deney küçük — tek bir 9B model, 60 görev, 11 bin token’a kadar — ve yayımlanmış sonuçla kolay durum hakkında uyuşuyor; bu deneyin kanıtlayabileceği en fazla şey de budur. Zor durumun kanıtı yayımlanmış benchmark’lardır ve bunlar hiçbir dizüstü bilgisayarın ulaşamayacağı bir ölçekte çalıştırıldı.

İki biçim: hangisini göreceğiniz göreve bağlı
BİREBİR EŞLEŞME — qwen3.5:9b, BU BÖLÜM %100 %80 %60 0 4 12 28 60 dikkat dağıtıcı belge (ölçekli değil) DÜZ: SIFIRDA %100,0, ALTMIŞTA %96,7 60 görev, 11.048 prompt token'ına kadar ANLAM EŞLEŞMESİ — GPT-4o, NoLiMa %100 %80 %60 %99,3 %69,7 kısa 32K bağlam uzunluğu EN İYİLERDEN BİRİNDE BİLE: 32K'DA %99,3 → %69,7 13 modelin 11'i yarının altına düştü; GPT-4o düşmedi BU PANELLER ARASINDA DEĞİŞEN ŞEY PENCERE DEĞİL — GÖREV ikisi de ilan edilen bağlamın rahatça içinde; yalnızca sağdaki çıkarsama gerektiriyor

İki panel farklı modellerden geliyor (soldaki çok daha küçük), dolayısıyla eğriler doğrudan karşılaştırılamaz. Aktarılmak istenen şey biçimdir. Cevap soruyla nadir bir dizgi paylaştığında, en azından bu uzunluklarda sol paneli alırsınız; paylaşmadığında sağdakini. Kolay test, neredeyse herkesin çalıştırdığıdır.

25.3 Sıkıştırma: neyi tutmak, neyi özetlemek, neyi düşürmek

Bölüm 23 transkriptin yalnızca büyüdüğünü ortaya koydu. Sıkıştırma bu konuda yaptığınız şeydir; özünde, alışılmadık bir özelliği olan bir kayıplı veri sıkıştırma (lossy compression) problemidir: neyi kaybedeceğinizi siz seçersiniz ve bunu neye ihtiyaç duyulacağını bilmeden önce seçersiniz.

Sıkıştırma (compaction) — bağlamın büyümesi dursun diye bir ajanın transkriptinin parçalarını özetlemek ya da düşürmek. Kayıplıdır ve kayıp, neye ihtiyaç duyulacağını bilmeden önce seçilir. ↩︎

İşe yarar hamle, transkripti tek bir şey olarak görmeyi bırakmaktır. Token başına değeri çok farklı olan parçaları vardır:

Her token aynı değerde değildir
transkriptin parçası nasıl tutulur neden
Görev — kullanıcının gerçekte sorduğu her zaman birebir; sona yakın bir yerde de yinelenerek kısadır, optimize edilen hedefin ta kendisidir ve geçmiş baskın hâle geldiğinde kaybolan şey odur
Ajanın verdiği kararlar ve gerekçeleri özetlenerek neyin kararlaştırıldığı gerekir; onu üreten müzakere genellikle gerekmez
Hâlâ canlı olan araç sonuçları birebir bunlar cevabın bağlı olduğu olgulardır. Bir sayıyı özetlemek onu kaybetmenin yoludur
Zaten aşılmış ya da tüketilmiş araç sonuçları düşürün ya da tek satıra indirin reddettiğiniz on arama sonucu, reddettiğiniz andan itibaren saf maliyettir
Zaten atlatılmış hatalar stack trace’i (yığın izini) düşürün, öğrettiği tek satırı tutun Bölüm 23’ün vurguladığı nokta: eskimiş bir hata bağlamda durdukça modeli yol açtığı karışıklığa doğru çekmeye devam eder — ama “tarih alanı ISO-8601 istiyor”, bunun tekrarını önleyen cümledir ve sekiz token eder

Bunu kurmadan önce bilmeniz gereken üç kusur biçimi var.

Sayıları özetlemek. Bir özetleyici, bütçe 4.318 liradır’ı memnuniyetle bütçe konuşuldu’ya çevirir. Nihai cevabın içermesi gereken her değer, sıkıştırmadan umutla değil kuralla muaf tutulmalıdır — en güvenli uygulama, düzyazının yanında yapılandırılmış bir facts listesi tutar ve onu asla özetlemez. Biçim ve özetleyiciye verilecek talimat şöyle basit olabilir:

facts (özetlenmez, olduğu gibi kopyalanır):
  [{"key": "butce", "value": "4.318 TL", "source": "adım 7"},
   {"key": "teslim_tarihi", "value": "2026-03-14", "source": "adım 12"}]

özetleyici talimatı:
  Aşağıdaki geçmişi en fazla 150 token'la özetle.
  Verilen kararları ve gerekçelerini tek cümleyle koru.
  Reddedilen arama sonuçlarını ve çözülmüş hataları at;
  bir hatadan çıkan dersi tek satırla bırak.
  Sayı, tarih ve kimlik yazma: onlar facts listesinde.

Görevi sıkıştırıp yok etmek. Geçmiş büyüdükçe özgün istek uzun bir bağlamın ortasına doğru kayar. Liu vd. (2024) bunun neye mal olduğunu ölçtü: bir erişim görevinde doğruluk, ilgili malzeme girdinin başında ya da sonunda olduğunda en yüksek ve ortada belirgin biçimde bozuluyor. Bölüm 20’deki iğne testi bunu yeniden üretmedi — her konumda %100 — ve nedeni başka hiçbir şey bulamamasıyla aynı: birebir bir dizgi eşleşmesi nerede durduğuna bağışıktır. Hedefi bağlamın sonunda yinelemek neredeyse bedavadır — görev kısadır ve sona eklendiği için önbellekteki ön eki bozmaz — ve görevin ortada kaybolmasını büyük ölçüde önler. Ortada kalan kanıt sorununu ise çözmez; onun çaresi, bu bölümün geri kalanının konusu olan seçmek ve azaltmaktır.

Tekrarlandıkça ek bilgi kaybettiren (non-idempotent) sıkıştırma. Bir özetin özetini almak her seferinde daha çok bilgi kaybettirir ve uzun süren ajanlar bunu tekrar tekrar yapar. Yapabildiğiniz yerde özgün metinden sıkıştırın ya da kaymayı kabul edip ölçün.

25.3.1 Somut olarak: kayan geçmiş penceresi (rolling history)

Pratikte işleyen örüntü üç katmanlı bir penceredir:

  [ sistem prompt'u + araçlar ]  sabit, her zaman mevcut
  [ sıkıştırılmış geçmiş      ]  son N adımdan eskisi, bir kez özetlenmiş,
                                 olgu listesi birebir tutularak
  [ son N adım                ]  birebir, çünkü sonraki kararın asıl konusu
                                 yakın zamandaki ayrıntıdır
  [ yinelenen görev           ]  en sonda, böylece hiç ortada kalmaz

N’yi seçmek, cevabı ucuza bulunan ampirik bir sorudur: değerlendirmenizi N = 3, 5 ve 10’da çalıştırın ve doğruluk kaybettirmeyen en küçüğünü alın.

25.4 Yalıtım: uzmana temiz bir pencere verin

Sıkıştırma, zaten kirlettiğiniz bir bağlamı azaltır. Bağlam yalıtımı onu kirletmekten kaçınır.

Bağlam yalıtımı (context isolation) — okuma ağırlıklı bir alt görevi kendi penceresinde çalıştırıp yalnızca sonucunu döndürmek; böylece okunan şey ebeveynin bağlamına hiç girmez. Okumanın bedeli yine ödenir, ama yalnızca bir kez ve alt ajanın penceresinde. ↩︎

Fikir basittir ve bu bölümdeki en büyük kaldıraçtır: çok şey okuması gereken bir alt görev — elli belge ara, bir log dosyasını tara, altı sorgu dene — kendi bağlamında çalışır ve yalnızca sonucunu döndürür. Ebeveyn elli belgeyi hiç görmez. Bir paragraf görür.

  yalıtımsız                    yalıtımlı
  ──────────                    ─────────
  ebeveyn 50 belge okur         alt ajan 50 belgeyi taze bir pencerede okur
  ebeveyn bağlamı: 40 bin       alt ajan 200 token döndürür
  ve sonsuza kadar 40 bin kalır ebeveyn bağlamı: +200

Kazanç 40 bin token değildir. Ebeveyn tarafında kabaca \((40{.}000 - 200) \times M\)’dir; burada \(M\), ebeveynin döngüsünde kalan model çağrısı sayısıdır. Bu brüt bir rakamdır: alt ajanın kendi 40 binlik okuması, sabit prompt’u ve çıktısı, varsa önbellek fiyatlandırması da bundan düşülmeli. Örneğin ebeveynin döngüsünde 10 çağrı kaldıysa brüt kazanç \((40{.}000 - 200) \times 10 = 398{.}000\) token’dır. Bu hesabı bir fatura değil, açıklayıcı bir kaba taslak sayın. \(M\)’nin ne kadar büyük olduğu, Bölüm 23’ün varsaymak yerine ölçtüğü bir şeye bağlı. Adımlar bağımsız olduğunda model araç çağrılarını batch (toplu) hâlinde gönderiyor: o bölümün deneyinde beş arama 2,0 model çağrısına indi ve büyüme karesel olmaya yaklaşmadı bile. Adımlar gerçekten sıralı olduğunda — n. adım n−1’in sonucuna ihtiyaç duyduğunda — çarpan adım sayısıdır ve yalıtım kazancı en büyük değerine ulaşır. Yalıtım en çok, tam da batchlemenin yardım edemediği yerde kazandırır.

Bedeli de aynı ölçüde gerçektir ve genellikle küçümsenir:

  • Ebeveyn, alt ajanın gördüğünü göremez. Döndürülen paragraf yanlış ya da eksikse ebeveynin bunu fark etmesinin yolu yoktur — kanıtı kaybetmiştir. Kısa bir sonuç ve tam malzemenin nerede olduğunu gösteren bir işaretçi (pointer; içeriğin kendisi yerine onu bulmayı sağlayan yol ya da kimlik) döndürün.
  • Eşgüdüm bedava değildir. Her yalıtılmış çağrı en az bir ek gidiş dönüş demektir ve uzmana işini yapacak kadar bağlam verilmesi gerekir; bu da artık bakımını yapmanız gereken ayrı bir prompt demektir.
  • Hatalar sessizce birikir. %90’ı doğru olan bir özeti ebeveyn olgu olarak kullanırsa, ortaya hata mesajı üretmeyen bir kusur biçimi çıkar. Bu konuya ayrılmış bölüm Bölüm 28.

Uygulanacak sezgisel kural: alt görevin girdileri büyük ve çıktısı küçükse yalıtın. Arama, tarama, süzme, doğrulama. Ebeveynin ayrıntıya ihtiyacı olacaksa yalıtmayın — gidiş dönüşün bedelini ödersiniz, sonra ayrıntıyı yine istersiniz. Kuralın nerede tersine döndüğünü Bölüm 28 modelliyor: 200 token’lık sonuçlar üreten altı adım, üç ajan olarak 1,20 kat pahalıya geliyor, çünkü ajan başına sabit maliyet fazladan ödeniyor; 3.000 token’lık sonuçlar üreten yirmi dört adım ise üçte iki tasarruf sağlıyor.

25.5 Tam zamanında erişim, önceden yüklemeyi yener

Bir ajan kurarken içgüdü, ihtiyaç duyabileceğini yüklemektir: şema, belgeler, son destek talepleri (ticket), kullanıcının geçmişi. Bu, bir hata kaynağını ortadan kaldırıyor gibi görünür ve hazırlıklı olmak gibi gelir.

Ama bu, her çağrıda her şeyin bedelini ödemek demektir. Alternatif — ajana getirme yeteneği verip ihtiyaç duyduğunu getirmesine izin vermek — neredeyse her zaman daha ucuzdur ve Bölüm 20’nin ölçümü buna inanmak için iyi bir nedendir: bir belge yerine seksen belge, birebir aynı doğruluk için 148 kat girdiye mal oldu. Önceden yükleme (eager loading), bu ödünleşimi (trade-off) her istekte sessizce kabul etmektir.

Tam zamanında erişimi işleten iki şey var ve ikisi de Bölüm 24’ün konusu:

  • Ajanın neyin mevcut olduğunu bilmesi gerekir. Açıklaması ne zaman kullanılacağını söyleyen find_orders adlı bir araç, talep üzerine getirmeyi mümkün kılan şeydir. İki bölümün art arda gelmesinin nedeni budur.
  • Tanımlayıcılar payload’ları (iletilen verinin kendisini) yener. Sipariş kimliklerini (ID), dosya yollarını ve URL’leri dolaştırın; içerikleri gerektiğinde getirin. Bir işaretçi on token’a, bir belge iki bin token’a mal olur ve çoğu işaretçinin gösterdiği içerik hiç getirilmez.

Bedeli gecikmedir: veriye ihtiyaç duyan adımlarda, önceden yüklemede ödemeyeceğiniz ek bir gidiş dönüş. Bu gerçek bir ödünleşimdir ve bariz bir orta yolu vardır — neredeyse her istekte gereken bir iki şeyi önceden yükleyin, kalan her şeyi talep üzerine getirin. Bunu bir alışkanlık değil bir karar hâline getiren şey, isabet oranını ölçmektir: isteklerin %15’inde kullanılan bir şeyi önceden yüklüyorsanız, kalan %85’inde bedelini boşuna ödüyorsunuz.

25.6 Dış bellek olarak dosya sistemi

Geçici çözüm gibi görünen ama doğru mimariye daha yakın olan bir hamle var: ajanın bir şeyler yazmasına ve geri okumasına izin verin.

Bir karalama dosyası, bir notlar dizini, şimdiye kadarki bulguları tutan yapılandırılmış bir JSON dosyası. Bağlam yalnızca bir referans tutar — findings.md, 340 satır — ve ajan ihtiyaç duyduğunda ihtiyaç duyduğu kısmı okur.

Bu, daha uzun bir pencereden, kapasiteyle hiç ilgisi olmayan nedenlerle daha iyidir:

  • Sıkıştırmadan sağ çıkar. Bir dosyaya yazılan her şey, transkript özetlendikten sonra hâlâ oradadır; bu da onu tam da sıkıştırmanın yok ettiği olguların doğal evi yapar.
  • Adreslenebilirdir. Ajan her şeyi yeniden okumak yerine bir bölümü yeniden okuyabilir; doğrusal bir transkript bunu sunamaz.
  • Siz de inceleyebilirsiniz. Bir dosya, hata ayıklarken incelenebilecek kalıcı bir kayıttır; bir transkript ise bir samanlıktır. Uzun bir çalıştırma ters gittiğinde nedenini genellikle notlar dosyasında bulursunuz.
  • Çalıştırma bittikten sonra da kalır. Bu bölüm burada sözü Bölüm 26’ya bırakıyor; orada konu, bir çalıştırmanın içinde değil çalıştırmalar arasında neyin kalması gerektiği.

İşlemesini sağlayan disiplin: yapılandırılmış yazın, seçerek okuyun. Serbest düzyazıya dönüşen bir notlar dosyası, aynı sorunu taşıyan ikinci bir transkripttir. Dosyayı başlıklara bölün ya da JSON olarak tutun; böylece sonraki bir adım dosyanın tamamını değil, tek bir alanı okuyabilsin.

25.7 Metin erişimi yetmediğinde

Yukarıdakilerin hepsine bir çekince ekleyelim, çünkü iyi kurulmuş bir bağlam hattı bile burada başarısız olur.

Bölüm 20’nin makinesi — parçala, göm, eriş — bilginin yerel anlamı olan metin olduğunu varsayar: kendi başına, belgedeki anlamıyla kabaca aynı şeyi ifade eden bir pasaj. Üç yaygın durum bu varsayımı doğrudan çiğner ve hiçbir miktarda parçalama onları onarmaz:

  • Tablolar ve şemalar. Bir satır, sütun başlıkları olmadan anlamsızdır; bir sütun adı da tablonun amacı bilinmeden anlamsızdır. Bölüm 20 parçalamanın yapıya ne yaptığını ölçtü; buradaki çözüm daha iyi parçalama değil, her satırı kendi kendine yeten bir cümleye dönüştürmek ya da hiç erişim yapmayıp ajanın tabloyu sorgulamasına izin vermektir.
  • Kod. Bir işlevin anlamı çağıranlarına, tiplerine ve modülün geleneklerine bağlıdır — hepsi deponun başka yerlerinde yaşar. Yalnızca işlev gövdesini getirmek en az işe yarar kısmı getirmektir.
  • İlişkisel olan her şey. Mart olayından sonra hangi müşteriler ayrıldı? sorusu bir arama değil, bir join (tablo birleştirme) işlemidir. Satırları gömüp ummak, bir sorgunun vereceğinden kötü bir cevabı almanın pahalı yoludur.

Kural: verinin yapısı olduğunda ajana yapıyı sorgulamanın bir yolunu verin. Yukarıdaki sorgu biçimleri için — toplamalar, join’ler, bu işlevin çağıranlarını izlemek — gerçek bir şema üzerinde bir run_sql aracı satırları embedding’e (gömme vektörüne) çevirmekten, bir grep ve read araç çifti de bir kod tabanını embedding’e çevirmekten iyidir. Bu, o sorgu biçimleri hakkında bir iddia; genel bir sıralama değil: yeniden denemeleri nerede ele alıyoruz? gibi bir sorunun grep ile aranacak birebir bir dizgisi yoktur ve embedding tabanlı aramanın iyi olduğu şey tam da budur. Gerçek sistemlerin çoğu ikisine de ihtiyaç duyar. Bu bir bağlam mühendisliği kararıdır, çünkü hangi bilginin bağlam penceresine gireceğini belirler; sizin verinizde çalışan bir ajanla yalnızca demoda çalışan bir ajan arasındaki fark da genellikle budur.

25.8 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. İkisi ölçümlere dayanıyor — biri yayımlanmış, biri burada çalıştırılmış — diğer dördü bu bölümün savunduğu ve kendi sisteminizde nasıl kontrol edeceğinizi söylediği yargılara.

Hayır; birbirine karıştırılması kolay iki ayrı nedenle. Maliyet nedeni koşulsuza yakındır: her token her model çağrısında yeniden gönderilir, dolayısıyla düzenlemediğiniz bir bağlam sonsuza kadar ödediğiniz bir faturadır — Bölüm 20 birebir aynı doğruluk için 148 kat girdi ölçtü. Prompt önbellekleme, ön ekin değişmeyen kısmını indirimli faturalar; asıl paranın değişen kısımda harcanmasının nedeni de budur. Yetenek nedeni koşulludur ama gerçektir: bir pencere bir kapasitedir, bir yetkinlik değil ve Hsieh vd. (2024), 32K veya fazlasını iddia eden 17 modelin yalnızca yarısının 32K’da dayandığını buldu.

Göreviniz hakkında neredeyse hiçbir şey. NIAH, modelin soruda zaten bulunan nadir bir dizgiyi eşleştirmesine izin verir; ki bu attention’ın yaptığı en kolay şeydir — Bölüm 20’nin çalıştırması her boyutta ve her konumda düz %100 döndürdü, bu bölümün daha zor yerel sürümü ise bağlam uzunluğuna bağlı hiçbir eğilim göstermeden %88,3 ile %100 arasında kaldı. Modarressi vd. (2025) tam o koltuk değneğini kaldırdı ve 13 modelin 11’i 32K’da kısa bağlam baseline’ının yarısının altına düştü; istisnalardan biri olan GPT-4o bile %99,3’ten %69,7’ye indi. Birebir eşleşmelerle değil, yeniden ifade edilmiş sorularla sınayın.

Kategori bazında saymak — sistem prompt’u, araç tanımları, erişilen belgeler, araç sonuçları, geçmiş. Saymak erdemli olduğu için değil, en büyük kategori çoğu zaman başta tahmin edilen kategori olmadığı için. Sabit maliyetler (sistem prompt’u, araç tanımları) döngüdeki her adımla çarpılır; bu yüzden token sayıları göründüğünden büyüktür. Ama önbelleğe alınan bir ön ek bu tekrarları indirimli faturalar. Kategorileri yalnızca token’a göre değil, ölçülen maliyete göre sıralayın.

Girdileri büyük ve çıktısı küçük olduğunda: arama, tarama, süzme, doğrulama. Kazanç alt görevin okuduğu token’lar değil, o token’ların ebeveynin döngüsündeki kalan her model çağrısıyla çarpımıdır — alt ajanın kendi maliyeti düşüldükten sonra. Ebeveynin ayrıntıya ihtiyacı olacaksa yalıtmayın — bir gidiş dönüş ödersiniz ve sonra yine istersiniz. Ve özetin yanında bir işaretçi döndürün, çünkü ebeveyn aksi hâlde kanıtı kaybetmiştir ve yanlış bir sonucu fark edemez.

Sayılar, tanımlayıcılar ve nihai cevabın içermek zorunda olduğu her şey. Bir özetleyici bütçe 4.318 liradır’ı, bunu yaptığına dair hiçbir sinyal vermeden bütçe konuşuldu’ya çevirir. Düzyazının yanında yapılandırılmış bir olgu listesi tutun ve onu kuralla sıkıştırmadan muaf tutun. Korunması gereken bir şey daha: özgün görev, ortaya kaymaya bırakılmak yerine bağlamın sonunda yinelenmiş hâlde.

Genellikle gerçek verinin yapısı olduğu ve hattın ona metin muamelesi yaptığı için. Bir tablo satırı sütun başlıkları olmadan hiçbir şey ifade etmez; bir işlev çağıranları olmadan hiçbir şey ifade etmez; mart olayından sonra hangi müşteriler ayrıldı bir arama değil bir join’dir. Parçalama bunların hiçbirini onarmaz. Satırları gömüp ummak yerine ajana yapıyı sorgulamanın bir yolunu verin — gerçek bir şema üzerinde run_sql, bir depo üzerinde grep artı read.

25.9 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Bu sorular, kitabın kullandığı iki güvenilir açık kaynakta sıkça geçiyor; bunlara bu bölümün ölçümleriyle cevaplanabilen sorular eklendi.

25.9.1 Mekanizmayı anlayıp anlamadığınızı sınayanlar

S: Pencereler büyümeyi sürdürüyorsa bağlam mühendisliği neden önemli?

İki argümanı ayırın, çünkü güçleri farklı. Maliyet koşulsuza yakındır: transkript her model çağrısında yeniden gönderilir, dolayısıyla düzenlenmemiş bir bağlam adım sayısıyla çarpılır — prompt önbellekleme değişmeyen bir ön eki indirimli faturalar ama bağlamın yeniden yazılmış ortasına indirim uygulamaz; sıkıştırmanın bedava olmamasının nedeni de budur — ve Bölüm 20, seçmeyi atladığınızda birebir aynı doğruluk için 148 kat girdi token’ı ölçtü. Yetenek koşulludur ama belgelenmiştir: iddia edilen bir pencere etkin bir pencere değildir ve Hsieh vd. (2024), 17 modelin yarısının, hepsinin desteklediğini iddia ettiği 32K’da dayanamadığını buldu.

S: Biri size kusursuz bir needle-in-a-haystack sonucu gösteriyor. Ne dersiniz?

Bunun kolay sürüm olduğunu söylersiniz ve nedenini açıklarsınız: iğne soruyla nadir bir dizgi paylaşıyor, dolayısıyla model çıkarsama yapmıyor, yalnızca eşleştiriyor. Yapabiliyorsanız karşıt sonucu kaynağıyla anın — Modarressi vd. (2025) sözcüksel örtüşmeyi kaldırdı ve 13 modelin 11’i 32K’da kısa bağlam baseline’ının yarısının altına düştü. Sonra pratikte ne yapılacağını söyleyin: yeniden ifade edilmiş sorularla ve çok olgulu toplulaştırma görevleriyle değerlendirin, çünkü gerçek görevler bu biçimdedir.

S: Bir ajanın bağlamında gerçekte ne büyüyor ve neden göründüğünden pahalı?

Transkript büyür, hem de hiç küçülmeden: her karar ve her gözlem eklenir, hiçbir şey çıkarılmaz. Göründüğünden pahalıdır, çünkü her model çağrısı hepsini yeniden gönderir; dolayısıyla toplam maliyet, son uzunluk değil, büyüyen bir serinin toplamıdır — Bölüm 23’ün gösterdiği gibi, sıralı adım sayısına göre kabaca karesel. Araç tanımları gibi sabit maliyetlerin orantısız biçimde önemli olmasının nedeni budur: çalıştırma başına değil çağrı başına ödenirler.

25.9.2 Gerçekten bir ajan yayına alıp almadığınızı sınayanlar

S: Bir ajan bütçesinin üç katına mal oluyor. Düzeltmeyi anlatın.

Önce kategori bazında ölçerim ve nedenini söylerim: en büyük kategori çoğu zaman başta tahmin edilen kategori değildir. Sonra ölçülen maliyet sırasına göre keserim; ham token sayısını değil, önbellek isabetlerini ve token fiyatlarını hesaba katarım. Olağan adaylar şunlar: araç tanımlarını ve sistem prompt’unu budayın, çünkü her adımla çarpılıyorlar; araçların döndürdüğünü gerçekten kullanılan alanlara indirin; okuma ağırlıklı alt görevi kendi bağlamına yalıtın; sonra olguları birebir tutarak geçmişi sıkıştırın. Her aşamada doğruluğu bir aralıkla yeniden ölçün, çünkü bunların her biri sessizce puana mal olabilir.

S: Önceden yüklemeyle talep üzerine getirme arasında nasıl karar verirsiniz?

Token açısından cevap çoğu zaman “talep üzerine” ve birinci dereceden aritmetiği tek satır: önceden yükleme her istekte T token’a mal olur; tam zamanında erişim ise her istekte getirme aracının tanımı c kadar, ihtiyaç duyan h oranındaki isteklerde de ayrıca T kadar. Yani getirmek, h < 1 − c/T olduğu her yerde kazanır. Yaklaşık yüz token’lık bir araç tanımına karşı iki bin token’lık bir belgede bu eşik 0,95’tir — yalnızca neredeyse her istekte gereken bir şeyi önceden yüklemeye değer. Bu satırın dışarıda bıraktığı gerçek bir maliyet var: her getirme, o ana kadarki bağlamı yeniden gönderen ek bir model çağrısıdır (bağlam önbellekteyse ucuzdur). Bunu söyleyin; tam zamanında erişimin zaman olarak neye mal olduğunu söyleyin — veriye ihtiyaç duyan adımlarda bir gidiş dönüşlük gecikme — ve iki yaklaşımın avantajlarının çoğunu nasıl birlikte alacağınızı anlatın: payload yerine tanımlayıcı dolaştırın ve içeriği ancak bir adım gerçekten ihtiyaç duyduğunda getirin.

25.10 2026 alet çantası

Bu bölümdeki yerel deney aşağıdaki sürümlerle tek bir dizüstü bilgisayarda çalıştı. Dayandığı uzun bağlam sonuçları, hiçbir dizüstü bilgisayarın ulaşamayacağı bir ölçekte çalıştırılmış yayımlanmış benchmark’lardan geliyor.

Bu sayıların çıktığı yığın
kütüphane kullanılan sürüm burada ne işe yarıyor
ollama 0.24.0 11 bin token’a kadar bağlamlarda qwen3.5:9b sunmak
numpy 2.5.2 görev üretimi, puanlama ve güven aralıkları

Bilmeye değer, yukarıda kullanılmadı:

Daha geniş ekosistem, yazıldığı andaki sürümler
kütüphane güncel sürüm ne zaman kullanılır
langgraph 1.2.11 durumu açık bir nesne olarak tutmak; bu da sıkıştırmayı bir tesadüf değil, bilinçli bir tasarım kararı hâline getirir
openai-agents 0.22.0 birinci sınıf bir yapı olarak alt ajan yalıtımı

İhtiyaç duyacağınız diğer üç araç tiktoken, RULER ve NoLiMa. Bunlar sürümleriyle değil bağlantılarıyla Bölüm 25.13’te yer alıyor.

25.11 Lab: bir ajanın token kullanımını doğruluk kaybetmeden kısın

Bu adımların sırası önemli — ölçün, sonra kesin, sonra yeniden ölçün. Başka bir sırayla yapmak, hangi adımdan geldiğini bilemeyeceğiniz tasarruflar üretir. Önce ölçülen maliyete en büyük katkıyı yapan ve güvenle azaltılabilen kategoriyi küçültün. Bu her zaman en çok token’ı olan kategori değildir: bir token’ın maliyetini önbellek isabet oranı ve token fiyatları belirler. 2–5. adımlar olağan adayları sıralıyor; kendi ölçümünüz farklı bir sıra gösteriyorsa ölçümünüze uyun.

25.11.1 Adım 1 — kategori bazında bütçeyi kurun

Gerçek bir çalıştırmaya ölçüm ekleyin. Şunlar için token sayın: sistem prompt’u, araç tanımları, erişilen belgeler, araç sonuçları, konuşma geçmişi. Her sayının yanına maliyetini de yazın; önbellekten okunan ve okunmayan girdi token’larını ayrı fiyatlayın. Tabloyu yazdırın. Tekniklere atlamayın; bu adımın amacı, hangi kategorinin en büyük olduğu konusunda yanıldığınızı görmenizdir.

25.11.2 Adım 2 — faturada ağır basıyorsa sabit maliyetleri düzeltin

Sistem prompt’u ve araç tanımları her çağrıda yeniden gönderilir, dolayısıyla token’ları adım sayısıyla çarpılır. Fatura ise ayrı bir konu: önbelleğe alınan bir ön ek, ilk çağrı fiyatının bir kesriyle faturalanır (bkz. Bölüm 25.1.1). Bu yüzden onları ilk sıraya koymadan önce önbellek isabet oranına ve token fiyatlarına bakın. Ölçülen maliyette gerçekten ağır basıyorlarsa bu genellikle en ucuz büyük tasarruftur: kimsenin kullanmadığı araçları budayın ve birikmiş talimatları silin.

25.11.3 Adım 3 — araçların döndürdüğünü kısın

Bölüm 24’e göre bütün kayıtlar yerine görevin ihtiyaç duyduğu alanları döndürün. Yeniden ölçün. Biçimi de kontrol edin: ajanın yalnızca iki satırını okuduğu 40 satırlık bir sonuç sayfalanmalıdır.

25.11.4 Adım 4 — okuma ağırlıklı bir alt görevi yalıtın

Girdisi büyük, çıktısı küçük olan adımı seçin. Kendi bağlamında çalıştırın ve yalnızca sonucu döndürün. Labdaki en büyük tasarruf genellikle bu adımdan gelir.

25.11.5 Adım 5 — olguları birebir tutarak geçmişi sıkıştırın

Son N adımdan eskisini özetleyin ve yapılandırılmış bir olgu listesini dokunulmadan tutun. N’yi 3, 5 ve 10 değerleri üzerinde tarayın.

25.11.6 Adım 6 — yalnızca token’ları değil doğruluğu da yeniden ölçün

Yukarıdaki her adım sessizce doğruluğa mal olabilir. Değerlendirmenizi çalıştırın — Bölüm 22’ye göre boyutlandırılmış, çünkü 30 maddelik bir küme önemsediğiniz gerilemeyi saptayamaz — ve token’ları ve puanı birlikte raporlayın. Dört puana mal olan %60’lık bir token azalması buna değebilir de değmeyebilir de, ama iki sayı olmadan o konuşmayı yapamazsınız.

25.11.7 Neyi teslim edeceksiniz

Öncesi ve sonrasıyla kategori tablosunu, adım başına token azalmasını, her aşamada aralıklı doğruluğu ve yalnızca birini tutabilseydiniz hangi adımı tutacağınıza dair bir cümleyi.

25.12 Alıştırmalar

  1. Bütçe tablosu. Gerçek bir ajan çalıştırmasına ölçüm ekleyin ve her kategori için kullanılan token sayısını çıkarın. Bakmadan önce hangi kategorinin en büyük olacağını yazın. Çoğu insan yanılıyor.
  2. Adımlarla çarpın. Sistem prompt’unuzu ve araç tanımlarınızı alın ve token sayılarını çalıştırma başına ortalama model çağrısı sayısıyla çarpın. O sayı, onları budamanın token cinsinden değeridir; ön ek önbelleğe alınıyorsa faturadaki tasarruf daha küçüktür.
  3. NIAH testinizi yeniden ifade edin. Uzun bağlam değerlendirmeniz varsa soruları, cevaplarla ayırt edici hiçbir kelime paylaşmayacak şekilde yeniden yazın. Yeniden çalıştırın. İki eğriyi de raporlayın.
  4. Bir adımı yalıtın. En okuma ağırlıklı alt görevinizi bulun, ayrı bir bağlamda çalıştırın ve ebeveynin token sayısını öncesi ve sonrasıyla ölçün.
  5. Sıkıştırmayı bilerek bozun. Cevabın ihtiyaç duyduğu bir sayı içeren bir transkripti sıkıştırın ve sayının sağ çıkıp çıkmadığını kontrol edin. Sonra yapılandırılmış olgu listesini ekleyin ve yeniden kontrol edin.
  6. İsabet oranı denetimi. Önceden yüklediğiniz her şey için gerçekte ne sıklıkla kullanıldığını ölçün. Kullanım oranı kabaca yarının altında kalan her şey tam zamanında erişim adayıdır. (Mülakat sorularındaki token aritmetiği çok daha yüksek bir eşiğe izin verirdi; yarının makul bir başlangıç noktası olmasının nedeni, ek gidiş dönüş ve onun getirdiği gecikmedir.)
  7. Notlar dosyası. Bir ajana bulguları yazmak zorunda olduğu bir karalama alanı ve bölümleri geri okumak için bir araç verin. Sıkıştırma gerektirecek kadar uzun bir görevde, notlar dosyası olmayan aynı ajana karşı token kullanımını ve doğruluğu karşılaştırın.

25.13 Daha derine

Okumadan önce: bir çalıştırmaya ölçüm ekleyin ve kategori bazında token tablosunu üretin. Bir saat sürer ve yukarıdaki alt bölümlerden hangisine gerçekten ihtiyacınız olduğunu gösterir.

Makalelerin ötesi
kaynak ne olduğu
Effective context engineering for AI agents — Anthropic bu bölümün konusunu uygulayıcı gözüyle en eksiksiz ele alan kaynak; sıkıştırma ve alt ajan yalıtımı dâhil
Building effective agents — Anthropic çevredeki mimari ve ek düzenekleri ne zaman eklememek gerektiği
RULER iddia edilen bağlam uzunluğunu etkin olandan ayıran benchmark; kendi modelinizde çalıştırılabilir
NoLiMa sözcüksel örtüşme olmadan kurulmuş iğne kümesi — sade NIAH yerine örnek alınacak değerlendirme
tiktoken token’ları doğru saymak; buradaki her şeyin birinci adımı. Yalnızca OpenAI’ın tokenizer’larını içerir; başka modeller için modelin kendi tokenizer’ını ya da API’nin raporladığı token sayılarını kullanın
langgraph biriken bir liste yerine açık bir nesne olarak durum; bu da sıkıştırmayı bir tasarım kararı yapar
Birincil kaynaklar
konu kaynak
iddia edilen bağlam uzunluğuna karşı etkin olan Hsieh vd. (2024)
iğne testinin gizledikleri Modarressi vd. (2025)
uzun bağlamlarda konum etkileri Liu vd. (2024)
başlı başına zarar kaynağı olarak ilgisiz bağlam Shi vd. (2023)
sabit bir pencereyi işletim sisteminin belleği gibi yönetmek, bağlamı içeri ve dışarı sayfalamak Packer vd. (2023)
daha uzun bir prompt’un alternatifi olarak erişim Lewis vd. (2020)
bağlam çürümesi adını yaygınlaştıran ve onu ölçen rapor Hong vd. (2025)

25.14 Akılda kalması gerekenler

  • Pencere bir kap değil bir bütçedir. İkisine de bakın: girdinin sığıp sığmadığına ve her parçanın maliyetini hak edip etmediğine. Her token her model çağrısında yeniden gönderilir, dolayısıyla düzenlenmemiş bir bağlam adım sayısıyla çarpılır.
  • Kesmeden önce sayın. Kategori bazında token’lar — sistem prompt’u, araç tanımları, erişilen belgeler, araç sonuçları, geçmiş. En büyük kategori çoğu zaman başta tahmin edilen kategori değildir. Sabit maliyetler çalıştırma başına değil çağrı başına ödenir; ama önbelleğe alınan ön ek indirimli faturalanır, bu yüzden kategorileri ölçülen maliyete göre sıralayın.
  • İddia edilen bir bağlam uzunluğu bir kapasitedir, bir yetkinlik değil. 32K veya fazlasını iddia eden 17 model içinde yalnızca yarısı 32K’da dayandı (Hsieh vd. 2024).
  • Needle-in-a-haystack kolay testtir; modeliniz onu geçecektir. Bölüm 20’nin erişim koşusu her konumda ve boyutta %100 aldı; bu bölümün 60 görevlik sürümü ise monoton bir düşüş olmadan %88,3 ile %100 arasında kaldı — ikisi de soruyla nadir bir dizgi paylaşan bir iğneyle. O örtüşmeyi kaldırın, 13 modelin 11’i 32K’da kısa bağlam baseline’ının yarısının altına düşüyor; istisnalardan biri olan GPT-4o bile %99,3’ten %69,7’ye iniyor (Modarressi vd. 2025). Yeniden ifade edilmiş sorularla değerlendirin.
  • Yalıtım, biçim doğruysa en büyük kaldıraçtır. Kendi bağlamındaki okuma ağırlıklı bir alt görev kırk bin token yerine bir paragraf döndürür ve kazanç, o rakamın ebeveynin döngüsündeki kalan her çağrıyla çarpımıdır. Bölüm 28 bunun nerede tersine döndüğünü modelliyor: 200 token’lık sonuçlar üreten altı adım, üç ajan olarak 1,20 kat pahalıya geliyor — çünkü ajan başına sabit maliyet üç kez fazladan ödeniyor; 3.000 token’lık sonuçlar üreten yirmi dört adım ise üçte iki tasarruf sağlıyor. Büyük girdi, küçük çıktı, çok sayıda kalan adım — üçü birden yoksa tasarruf da yok.
  • Sıkıştırma kayıplıdır ve kaybı önceden siz seçersiniz. Görevi ve canlı araç sonuçlarını birebir tutun, kararları özetleyin, tüketilmiş sonuçları ve çözülmüş hataların stack trace’lerini düşürün — aynı hatanın tekrarını önleyeceği yerde tek satırlık bir ders bırakarak. Cevabın gerektirdiği değerleri birebir koruyun.
  • Payload yerine tanımlayıcıyı tercih edin. Bir işaretçi on token’a, bir belge iki bin token’a mal olur ve çoğu işaretçinin gösterdiği içerik hiç getirilmez. Yalnızca neredeyse her istekte kullanılanı önceden yükleyin.
  • Verinin yapısı olduğunda yapıyı sorgulayın. Tablolar üzerindeki toplamalar, join’ler ve birebir kayıt aramaları, gerçek bir şema üzerinde run_sql’in işidir ve parçala-ve-göm yaklaşımı bunları kötü yapar; kod ya da düzyazı üzerinde anlamsal arama ise ayrı bir görevdir ve çoğu sistem ikisini yan yana kullanır.