Uzun Bağlamda 'Lost in the Middle': Milyon-Token Çağında Bağlam Yönetimi (2026)

TL;DR — Milyon token'lık bağlam pencereleri artık elimizde, ama işin sırrı pencereyi doldurmak değil, içine ne gireceğini mühendislik gibi tasarlamak. Modeller, uzun bağlamın ortasına gömülü bilgiyi en kötü şekilde işliyor; buna literatürde "lost in the middle" deniyor. Bu yazıda prompt mühendisliğinden bağlam mühendisliğine geçişi, bağlam mühendisliğinin dört sütununu (talimatlar, retrieval, bellek, araçlar), sıkıştırma ve Self-RAG, RAPTOR, MemGPT gibi teknikleri, ve sahadan çıkardığım pratik taktikleri anlatıyorum. Sonunda bir "sorun–belirti–çözüm" tablosu ve Türkiye'ye özgü iki gerçek var: Türkçe tokenizasyonun token sayısını şişirmesi ve bağlama giren veride KVKV/KVKK disiplini.

Bir eğitimde, kurumsal bir ekibin mühendisiyle aramızda geçen kısa bir diyalog var ki, bu yazının tüm ruhunu özetliyor. Bana gururla, "Artık modele bütün dokümantasyonu, tüm e-posta geçmişini, hatta CRM kayıtlarını topluca veriyoruz; pencere milyon token, yani niye seçelim ki?" dedi. Ben de ona basit bir soru sordum: "Peki cevaplar iyileşti mi, yoksa kötüleşti mi?" Bir sessizlik oldu. Çünkü herkesin sezgisel olarak bildiği ama itiraf etmek istemediği bir gerçek vardı: pencereyi doldurdukça cevaplar daha da bulanıklaşmıştı.

Sahada gördüğüm en yaygın yanılgı bu. Bağlam penceresi büyüdükçe, "ne kadar çok veri, o kadar iyi cevap" diye bir denklem kuruluyor kafalarda. Oysa gerçek tam tersi. Milyon token'lık pencereye sahip en ileri modeller bile, pencere marjinal alakalı içerikle dolduğunda ölçülebilir şekilde daha kötü çıktılar üretiyor. Yani mesele kapasite değil; mesele o kapasiteye neyi, hangi sırayla, ne kadar koyduğunuz. İşte bu yazının konusu tam da bu: 2026'nın gerçek becerisi olan bağlam mühendisliği.

Yıllardır kurumlara yapay zeka danışmanlığı ve eğitimi veriyorum. Bu süreçte bir şeyi net gördüm: 2023-2024'ün "prompt mühendisliği" hevesi, yerini çok daha olgun, çok daha mühendislik disiplini gerektiren bir pratiğe bıraktı. Artık tek bir cümleyi cilalamakla uğraşmıyoruz. Modelin her çıkarım (inference) çağrısında ne gördüğünü tasarlıyoruz. Bu, bambaşka bir zanaat.

Önce terimleri netleştirelim, çünkü sahada bu iki kavram sürekli birbirine karışıyor.

Prompt mühendisliği, tek bir girdiyi optimize etme sanatıydı. "Sen bir uzmansın" diye başlayan roller, adım adım düşünme talimatları, örnekli (few-shot) kalıplar... Hepsi tek bir mesajın etkisini artırmaya odaklıydı. İşe yarıyordu, hâlâ da yarıyor. Ama ölçeği küçüktü: siz bir soru soruyordunuz, modeli o soruya en iyi cevabı verecek şekilde dürtüyordunuz.

Bağlam mühendisliği ise çok daha geniş bir problemi ele alıyor. Modelin gördüğü tüm bilgi yığınını yönetmek: bellek, retrieval ile getirilen dokümanlar, araç (tool) çıktıları, konuşma geçmişi, kullanıcı profilleri. Yani artık tek bir input'u değil, o input'un içine akan bütün enformasyon katmanını tasarlıyorsunuz. Prompt mühendisliği bir cümleyi cilalamaksa, bağlam mühendisliği modelin çalışma masasını baştan aşağı düzenlemek gibi.

Bu geçişi bir benzetmeyle anlatmayı seviyorum. Prompt mühendisliği, iyi bir soru sormaktır. Bağlam mühendisliği ise, o soruyu soran kişinin masasına hangi dosyaları, hangi notları, hangi referansları koyacağınıza karar vermektir. En zeki uzmanı bile karmakarışık, alakasız kağıtlarla dolu bir masaya oturttuğunuzda performansı düşer. Model de öyle.

2026'ya geldiğimizde ekipler artık "bağlam penceresini tıka basa doldur" mantığından "pencereye neyin gireceğini mühendislik gibi tasarla" mantığına geçti. Bu, benim gözümde son iki yılın en önemli zihniyet değişimi. Ve açıkçası, bu değişimi yakalayan ekiplerle yakalayamayanlar arasındaki kalite farkı gözle görülür hale geldi.

Şimdi işin kalbine gelelim. Araştırmalar tutarlı biçimde şunu gösteriyor: büyük dil modelleri, uzun bir bağlamın ortasına gömülü bilgiyi en kötü şekilde işliyor. Literatürde bu olguya "lost in the middle" — yani "ortada kaybolmak" deniyor.

Bunu ilk kez sahada net gördüğümde şaşırmıştım. Bir müşteri için hukuki döküman analizi yapan bir sistem kuruyorduk. Kritik bir madde, uzun bir sözleşmenin tam ortasındaydı. Model onu ısrarla atlıyordu. Aynı maddeyi metnin başına ya da sonuna taşıdığımızda ise anında yakalıyordu. Metin aynı metindi, model aynı modeldi; değişen tek şey bilginin konumuydu.

Bu neden oluyor? Teknik detaya çok girmeden şöyle özetleyeyim: modeller, bağlamın başındaki ve sonundaki bilgiye orantısız bir dikkat veriyor. İnsan psikolojisindeki "ilklik" ve "sonluk" etkilerine benzetebilirsiniz — bir listenin başını ve sonunu hatırlarız, ortası bulanıklaşır. Model de uzun bir pencerede benzer bir davranış sergiliyor. Ortaya gömdüğünüz o kritik cümle, teknik olarak pencerenin içinde olsa da, modelin "dikkat bütçesi" açısından adeta görünmez hale geliyor.

Buradaki en tehlikeli yanılgı şu: "Bilgi pencerenin içinde, o halde model onu kullanabilir." Hayır. Bilginin pencerede olması, o bilginin etkili biçimde kullanılacağı anlamına gelmiyor. Bu ayrımı kaçıran çok ekip gördüm. Milyon token'lık pencereye 800 bin token'lık ham veri döküyorlar, sonra "model neden bu detayı atladı?" diye şaşırıyorlar. Cevap basit: o detay ortada kayboldu.

"

Bağlam penceresi bir depo değil, bir sahne. Depoya ne koyduğunuz önemli değil; sahneye kimi, nereye çıkardığınız önemli.

Milyon token pencereler ilk çıktığında bir coşku dalgası yaşandı. "Artık RAG'a gerek yok, her şeyi pencereye koyarız" diyenler oldu. Bu iddia birkaç ay içinde sahada çöktü. Nedenini deneyimlerimle anlatayım.

Birincisi, kalite düşüşü. Az önce anlattığım gibi, pencere marjinal alakalı içerikle dolduğunda en ileri modeller bile ölçülebilir şekilde daha kötü çıktı üretiyor. Yani "her şeyi koy" stratejisi, aslında cevabın kalitesini aktif olarak düşürüyor. Sinyal, gürültünün içinde boğuluyor.

İkincisi, maliyet. Her token'ın bir bedeli var. 800 bin token'lık bir bağlamı her çıkarımda modele göndermek, hem parasal hem de gecikme (latency) açısından pahalı. Kullanıcı bir chatbot'a soru soruyor ve cevabın 20 saniye gelmesini bekliyor — çünkü sistem arka planda gereksiz yere devasa bir bağlamı işliyor. Bu, üretim ortamında sürdürülebilir değil.

Üçüncüsü, ve belki en önemlisi: doldurmak tembelliktir. "Her şeyi pencereye at, model halleder" demek, aslında zor işi modele havale etmek demek. Oysa o zor işi — yani neyin alakalı olduğuna karar verme işini — sistemi kuran ekibin yapması gerekiyor. Bağlam mühendisliği tam da bu sorumluluğu üstlenmektir.

İşte bu üç sebepten ötürü ekipler zihniyet değiştirdi. Artık soru "pencereye ne kadar sığar?" değil, "bu çıkarım için modelin gerçekten görmesi gereken minimum ve en alakalı bilgi nedir?" Bu, mühendislik disiplininin ta kendisi.

Bağlam mühendisliğini kavramsal olarak dört sütun üzerine oturtuyorum. Eğitimlerde bu çerçeveyi kullanıyorum çünkü karmaşık konuyu yönetilebilir parçalara ayırıyor. Her sütunu tek tek açalım.

1. Talimatlar (Instructions)

Bu, sistem promptları ve davranışsal çerçeveleme katmanı. Modele "kim olduğunu", nasıl davranması gerektiğini, hangi tonu kullanacağını, nelerden kaçınacağını söylediğiniz yer. Prompt mühendisliğinin klasik alanı büyük ölçüde burada yaşıyor. Ama bağlam mühendisliği perspektifinden bakınca, talimatlar artık izole bir cümle değil; diğer üç sütunla uyum içinde çalışması gereken bir katman.

Sahadan bir gözlem: talimatları ne kadar net ve öz tutarsanız, model o kadar iyi çalışıyor. Uzun uzun, sayfalarca sistem promptu yazmak genelde ters tepiyor. Çünkü o dev talimat bloğu da bağlamın bir parçası ve o da "lost in the middle" etkisine tabi. Talimatlarınızın ortasına gömdüğünüz kritik bir kural, model tarafından pekala görmezden gelinebilir.

2. Retrieval (Getirme / RAG)

Bu sütun, modelin dışarıdan bilgi çekmesini sağlayan katman: RAG (Retrieval-Augmented Generation) ve topraklanmış (grounded) arama. Modelin eğitim verisinde olmayan, güncel ya da kuruma özel bilgiyi çıkarım anında getirmek için bunu kullanıyoruz.

Retrieval'ın kalitesi, tüm sistemin kalitesini belirliyor demek abartı olmaz. Çünkü modele ne getirdiğiniz, cevabın hammaddesi. Yanlış, alakasız ya da gereğinden fazla doküman getirirseniz, model bu gürültüyü işlemek zorunda kalır. İyi bir retrieval katmanı, tam da modelin ihtiyaç duyduğu birkaç doküman parçasını getirir — ne eksik ne fazla.

3. Bellek (Memory)

Bellek iki katmanlı: kısa vadeli konuşma belleği ve uzun vadeli kalıcı durum (persistent state). Kısa vadeli bellek, aynı oturum içindeki konuşma geçmişidir. Uzun vadeli bellek ise oturumları aşan, kullanıcı hakkında biriken kalıcı bilgidir — tercihler, geçmiş kararlar, kurumsal bağlam.

Bellek yönetimi bağlam mühendisliğinin en zorlu kısmı bence. Çünkü konuşma uzadıkça geçmiş büyüyor ve onu olduğu gibi taşımak hem pahalı hem de "lost in the middle" riskini artırıyor. Bu yüzden belleği özetleme, katmanlama ve seçici hatırlama teknikleri devreye giriyor — birazdan MemGPT ve hiyerarşik depolamada değineceğim.

4. Araçlar (Tools)

Son sütun, modelin dış dünyayla etkileşim kurmasını sağlayan araçlar: API çağrıları, hesaplama, veritabanı sorguları, kod çalıştırma. Araç çıktıları da bağlama geri döner ve bağlamın bir parçası haline gelir. Yani bir aracın döndürdüğü devasa bir JSON, aynen ham doküman gibi pencereyi şişirebilir. İyi bir bağlam mühendisi, araç çıktılarını da işler, süzer, sadeleştirir; ham çıktıyı olduğu gibi pencereye geri koymaz.

Bu dört sütun birbirinden bağımsız değil; bir orkestra gibi birlikte çalışıyor. Bağlam mühendisliği, işte bu orkestrayı yönetme sanatı.

Buraya Türkiye'ye özgü, çok az konuşulan ama sahada çok can yakan bir konuyu eklemek istiyorum: Türkçe metinlerin tokenizasyonu.

Çoğu büyük dil modelinin tokenizer'ı ağırlıklı olarak İngilizce metin üzerine optimize edilmiş. Türkçe ise sondan eklemeli (agglutinative) bir dil — "evlerinizden" gibi tek bir kelime, İngilizce'de birkaç kelimeye karşılık gelir ve tokenizer bunu çoğu zaman birden fazla parçaya böler. Sonuç: aynı anlamı taşıyan bir metin, Türkçe yazıldığında İngilizce'ye kıyasla belirgin şekilde daha fazla token tüketir.

Bunun pratik sonuçları ciddi. Birincisi maliyet: Türkçe içerikle çalışan bir kurum, aynı iş için İngilizce çalışan bir kuruma göre token başına daha fazla ödüyor. İkincisi, ve bağlam mühendisliği açısından daha kritik olanı: Türkçe metin bağlam penceresini daha hızlı doldurur. Yani "lost in the middle" riskiniz, Türkçe çalışırken görece daha erken devreye girer. İngilizce'de 100 bin token'lık bir bağlam, aynı içeriği Türkçe taşıdığınızda pekala 130-150 bin token'a çıkabilir.

Bu yüzden Türkiye'deki ekiplere hep şunu söylüyorum: token bütçenizi İngilizce sezgilerinizle planlamayın. Türkçe çalışıyorsanız, sıkıştırma ve budama teknikleri sizin için bir lüks değil, zorunluluk. Aynı "lost in the middle" duvarına daha erken tosluyorsunuz, dolayısıyla disiplininiz de daha sıkı olmak zorunda.

Klasik RAG basittir: sorguyu al, benzer dokümanları getir, modele ver. Ama bu basit yaklaşım çoğu zaman ya çok fazla ya çok alakasız doküman getirir. İşte burada daha akıllı retrieval şemaları devreye giriyor.

Self-RAG, modelin kendi retrieval sürecini değerlendirmesini sağlar. Yani model, getirilen bilginin gerçekten alakalı olup olmadığını, cevaba katkı sağlayıp sağlamadığını kendisi sorgular ve gerektiğinde yeniden getirme kararı verir. Bu, "körlemesine getir ve umut et" yaklaşımından, "getir, değerlendir, gerekirse düzelt" yaklaşımına geçiştir. Getirilen gürültüyü azaltır, dolayısıyla "lost in the middle" riskini de düşürür.

RAPTOR ise dokümanları hiyerarşik bir özet ağacı halinde organize eder. Ham metin parçalarını tek tek getirmek yerine, farklı soyutlama seviyelerinde özetler oluşturur ve sorgunun ihtiyacına göre doğru seviyeden bilgi çeker. Geniş bir "büyük resim" sorusu için üst seviyedeki özeti, spesifik bir detay sorusu için alt seviyedeki ham parçayı getirir. Bu, hem token tasarrufu sağlar hem de modele tam ihtiyaç duyduğu granülariteyi verir.

Bu iki tekniğin ortak felsefesi şu: retrieval pasif bir "arama" değil, aktif bir "mühendislik" işidir. Neyin, ne zaman, hangi seviyede getirileceğine karar veren akıllı bir katman kuruyorsunuz.

Bellek tarafında da benzer bir olgunlaşma yaşandı. Uzun konuşmaları ve oturumlar arası kalıcı durumu yönetmek için geleneksel "tüm geçmişi pencereye taşı" yaklaşımı yetersiz kalıyor.

MemGPT gibi bellek sistemleri, işletim sistemlerindeki bellek yönetiminden ilham alır. Tıpkı bir bilgisayarın RAM ile disk arasında veri taşıması gibi, MemGPT de "aktif bağlam" (pencerede olan) ile "harici bellek" (pencere dışında saklanan) arasında bilgi taşır. Model, o an ihtiyaç duyduğu bilgiyi harici bellekten pencereye çeker, ihtiyaç bitince geri gönderir. Böylece pencere sürekli dolu tutulmaz; sadece o anki görev için gerekli bilgi sahnede olur.

Hiyerarşik depolama ise bu fikri genişletir: bilgiyi farklı katmanlarda, farklı erişim maliyetleriyle saklarsınız. En sık erişilen ve en alakalı bilgi en "yakın" katmanda, nadiren gereken bilgi daha "uzak" katmanda durur. Bu sistemler tek bir oturumun ötesine geçer — kullanıcıyla haftalar önce yaşanan bir konuşmayı, ilgili olduğu anda geri getirebilir.

Bu bellek sistemlerinin bağlam mühendisliği açısından değeri şu: pencereyi bir çalışma alanı olarak görürler, bir arşiv olarak değil. Arşiv dışarıda durur; çalışma alanına sadece o an gereken şey girer. Bu, "lost in the middle" probleminin doğrudan panzehiri.

Teoriyi konuştuk; şimdi masaya oturduğunuzda gerçekten işe yarayan taktiklere gelelim. Bunlar, kurumlarla çalışırken defalarca test ettiğim, işe yaradığını gördüğüm uygulamalar.

Reranking (yeniden sıralama). Retrieval katmanınız 20 doküman getirdiyse, hepsini modele vermeyin. Bir reranking adımı ekleyin: getirilen dokümanları alaka düzeyine göre yeniden sıralayın ve sadece en üsttekileri modele geçirin. Bu tek adım, bağlam kalitesini dramatik biçimde artırır. Gürültüyü kaynağında kesersiniz.

Kritik bilgiyi başa ve sona koyun. "Lost in the middle" biliyorsak, çözümü de biliyoruz: en önemli bilgiyi promptun başına ya da sonuna yerleştirin. Bir talimat, bir kısıt, bir kritik veri parçası varsa, onu ortaya gömmeyin. Bu kadar basit. Bu tek disiplin, birçok "model neden bunu kaçırdı?" vakasını çözer.

Bağlam budama (context pruning). Her çıkarımdan önce sorun: bu bilginin hepsi gerçekten gerekli mi? Alakasız dokümanları, eski araç çıktılarını, tekrar eden bilgiyi budayın. Budama, doldurmanın tam tersi disiplin — ve çok daha değerli.

Geçmişi özetleyin. Konuşma uzadıkça, ham geçmişi taşımak yerine periyodik özetler oluşturun. "Şu ana kadar kullanıcı şunları istedi, şu kararlar alındı" gibi bir özet, on binlerce token'lık ham geçmişin yerini birkaç yüz token'la tutabilir. Detay kaybı olur elbette; ama çoğu görevde bu kabul edilebilir bir takas.

Yapılandırılmış bağlam (structured context). Bilgiyi modele düz bir metin yığını olarak vermeyin. Başlıklar, etiketler, XML/Markdown yapıları kullanın. "İşte kullanıcı profili: ...", "İşte ilgili dokümanlar: ...", "İşte konuşma özeti: ..." gibi net bölümler, modelin bilgiyi ayrıştırmasını kolaylaştırır. Yapı, dikkati yönlendirir.

Sıkıştırma (compression). Uzun dokümanları modele vermeden önce sıkıştırın — özetleyerek, gereksiz kelimeleri atarak, sadece ilgili pasajları çıkararak. Özellikle Türkçe çalışıyorsanız, bu adım token bütçenizi ciddi biçimde rahatlatır.

Tek görev, tek bağlam. Sahada sık gördüğüm bir hata da tek bir devasa promptla birçok işi birden yaptırmaya çalışmak. Model, aynı pencerede hem özet çıkarsın, hem sınıflandırsın, hem de öneri üretsin isteniyor. Bu yaklaşım hem bağlamı şişiriyor hem de dikkati böldüğü için kaliteyi düşürüyor. Görevleri ayırın: her çıkarım tek bir net iş yapsın, ve o iş için gereken bağlam neyse sadece o girsin. Karmaşık bir akışı, her biri kendi dar bağlamıyla çalışan küçük adımlara bölmek, tek bir "her şeyi bilen" devasa çağrıdan neredeyse her zaman daha iyi sonuç veriyor.

Bağlamı sürekli tazeleyin, biriktirmeyin. Uzun süren oturumlarda bağlam bir çöplüğe dönüşme eğiliminde: eski araç çıktıları, artık geçersiz kalmış ara sonuçlar, tekrar eden bilgiler üst üste yığılıyor. Her turda "bu bilgi hâlâ gerekli mi?" diye sormayı bir alışkanlık haline getirin. Bağlam statik bir belge değil, canlı bir çalışma alanı; onu bir bahçe gibi düzenli budayın. Biriktiren ekipler zamanla yavaşlıyor ve kalite kaybediyor; tazeleyen ekipler istikrarlı kalıyor.

Sahada en çok karşılaştığım problemleri, nasıl fark edildiklerini ve nasıl çözüldüklerini tek bir tabloda topladım. Bunu bir kontrol listesi gibi kullanabilirsiniz.

Sorun	Belirti	Çözüm
Lost in the middle	Model, uzun bağlamın ortasındaki kritik detayı atlıyor	Kritik bilgiyi başa/sona taşı; bağlamı kısalt
Pencere şişmesi	Cevaplar yavaş ve kalitesiz; maliyet yüksek	Bağlam budama; sıkıştırma; sadece alakalı içeriği getir
Alakasız retrieval	Model konu dışı ya da yanlış bilgiye dayanıyor	Reranking; Self-RAG ile alaka değerlendirmesi
Geçmiş taşması	Uzun konuşmada model eski detayları unutuyor/karıştırıyor	Geçmişi özetle; MemGPT/hiyerarşik bellek
Türkçe token cezası	Aynı içerik beklenenden fazla token tüketiyor	Agresif sıkıştırma; budama; token bütçesini Türkçe'ye göre planla
Yapısız bağlam	Model bilgiyi karıştırıyor, kaynakları ayırt edemiyor	Yapılandırılmış bağlam: başlık, etiket, bölüm
Şişkin araç çıktısı	Devasa JSON/API cevabı pencereyi dolduruyor	Araç çıktısını süz, özetle; sadece gerekli alanları taşı
Uzun sistem promptu	Sistem promptundaki bir kural görmezden geliniyor	Talimatları kısalt ve önceliklendir; kritik kuralı sona koy

Bu tabloyu ekiplerle bir teşhis aracı gibi kullanıyoruz. Bir sistem beklendiği gibi çalışmıyorsa, önce belirtiye bakıp hangi satırda olduğumuzu buluyoruz, sonra çözümü uyguluyoruz. Çoğu zaman sorun modelin "aptallığı" değil, bağlamın kötü mühendisliğidir.

Türkiye'de çalışıyorsanız, teknik performansın ötesinde bir boyut daha var ki, çoğu ekip bunu sonradan, genelde iş işten geçtikten sonra fark ediyor: bağlama neyin girdiğinin hukuki boyutu.

Bağlam mühendisliği, tanımı gereği, modele ne gördüğünü tasarlamak. Peki o gördüğü şeyin içinde ne var? Retrieval katmanı kurumsal dokümanları getiriyorsa, bellek sistemi kullanıcı geçmişini saklıyorsa, araç çıktıları CRM kayıtlarını çekiyorsa — bunların içinde kişisel veri var demektir. Ve KVKK (Kişisel Verilerin Korunması Kanunu) açısından, bir modele kişisel veri göndermek, o verinin işlenmesi anlamına gelir.

Sahada gördüğüm en yaygın hata şu: ekipler retrieval ve bellek katmanlarını kurarken sadece "en alakalı bilgiyi getir" diye düşünüyor, "bu bilgiyi getirmeye hukuken hakkım var mı?" diye sormuyor. Oysa bağlama giren her veri parçası, bir veri işleme faaliyeti. Uzun vadeli bellek sistemleri özellikle riskli, çünkü kullanıcı hakkında oturumlar arası bilgi biriktiriyorlar — bu, açık bir "kişisel veri saklama" faaliyeti.

Bu yüzden bağlam mühendisliğini kurarken hukuki disiplini de baştan işin içine katın. Bağlama giren veriyi minimize edin — ki bu zaten "lost in the middle" için de iyi. Kişisel veriyi maskeleyin ya da anonimleştirin, mümkünse. Bellek sistemlerinde saklama süreleri ve silme mekanizmaları tanımlayın. İyi haber şu: iyi bağlam mühendisliği ile iyi veri hijyeni aynı yöne bakıyor. Pencereye daha az, daha alakalı veri koymak hem kaliteyi artırır hem de KVKK riskini azaltır. Aynı disiplin, iki fayda.

Bu yazıyı bir teknik reçete listesi gibi okumamanızı isterim. Elbette teknikler önemli — reranking, sıkıştırma, Self-RAG, MemGPT... Ama asıl mesele bir zihniyet değişimi. Ve bu zihniyeti tek cümlede özetleyebilirim: bağlam bir kaynak değil, bir sorumluluktur.

Milyon token'lık pencere size bir özgürlük gibi görünebilir — "artık her şeyi koyabilirim." Ama gerçek özgürlük, neyi koymayacağınıza karar verebilmekte. En iyi bağlam mühendislerini, koydukları şeyden çok koymadıkları şeyle tanıyorum. Onlar, her token'ın bir bedeli ve her alakasız cümlenin bir maliyeti olduğunu biliyor. Sahneye kimi çıkaracaklarına titizlikle karar veriyorlar.

Sahada gördüğüm başarılı ekipler ile başarısız ekipler arasındaki fark, model seçimi ya da bütçe değil neredeyse hiç. Fark, bu disipline sahip olup olmamak. "Pencereyi doldur" diyen ekip, güçlü bir modelle bile vasat sonuçlar alıyor. "Pencereyi mühendislik gibi tasarla" diyen ekip, mütevazı bir modelle bile keskin, güvenilir sonuçlar üretiyor.

Eğer okuduklarınızı bugün uygulamaya dökmek istiyorsanız, size sahada işe yarayan bir sıra öneriyorum. Sırayla ilerleyin; her adım bir sonrakine zemin hazırlıyor.

Birinci adım: ölçün. Önce mevcut sisteminizin bağlamına gerçekten ne girdiğini görün. Her çıkarımda modele giden token'ları loglayın. Çoğu ekip bunu yaptığında şok oluyor — pencerenin yarısının alakasız ya da tekrar eden içerikle dolu olduğunu görüyorlar. Ölçmediğiniz şeyi mühendislik yapamazsınız.

İkinci adım: budayın. Ölçtükten sonra en bariz israfları kesin. Şişkin araç çıktıları, gereksiz doküman parçaları, kabarık sistem promptları. Sadece bu budama bile çoğu zaman kaliteyi ve hızı hissedilir biçimde artırır.

Üçüncü adım: konumlandırın. Kalan bağlamda kritik bilgiyi başa ve sona taşıyın. "Lost in the middle" duvarına toslamamak için bu en ucuz ve en etkili müdahale.

Dördüncü adım: retrieval'ı akıllandırın. Reranking ekleyin. Basit RAG'dan Self-RAG ya da RAPTOR gibi şemalara doğru evrilin. Getirdiğiniz her dokümanın hak ederek pencerede olduğundan emin olun.

Beşinci adım: belleği tasarlayın. Uzun konuşmalar ve oturumlar arası durum için özetleme ve hiyerarşik bellek stratejileri kurun. Ham geçmişi taşımayı bırakın.

Altıncı adım: Türkçe ve KVKK için ayarlayın. Token bütçenizi Türkçe'nin token cezasına göre yeniden planlayın. Bağlama giren kişisel veriyi minimize edin, maskeleyin, saklama sürelerini tanımlayın.

Bu altı adımı sırayla uyguladığınızda, "milyon token'lık pencerem var ama cevaplarım kötü" sarmalından çıkacaksınız. Çünkü artık pencereyi doldurmuyor, tasarlıyor olacaksınız. Ve inanın bana, aradaki fark, kullanıcının aldığı her cevapta kendini gösteriyor. Bağlam mühendisliği, 2026'nın sessiz ama belirleyici becerisi; ne kadar erken benimserseniz, o kadar öndesiniz.