Bağlam Bir Altyapıdır

Bir dil modeli birkaç dakika içinde etkileyici miktarda iş üretebilir. Araştırabilir, yapılandırabilir, karar verebilir, yazabilir, kontrol edebilir ve sonraki işleri başka ajanlara devredebilir. Ancak proje uzadıkça, modelin salt zekâsıyla pek ilgisi olmayan bir sınır daha görünür hale gelir: iyi bir sonuç yalnızca modelin ne yapabildiğine değil, doğru anda projenin hangi durumunu gerçekten önünde bulundurduğuna bağlıdır.

Bir ajan teknik olarak çok güçlü olabilir ve yine de son kararı bilmediği için yanlış yönde ilerleyebilir. Bir sohbet binlerce mesaj içerebilir ama hâlâ eski bir proje durumunu taşıyabilir. Bir proje klasörü onlarca kaynak içerebilir ama hangilerinin o anki görev için bağlayıcı olduğunu açıkça göstermeyebilir. Bir ekip birden fazla yapay zekâ oturumunu paralel çalıştırabilir ama ortak bir bilgi durumuna sahip olmayabilir.

Bu yüzden bağlam, prompta eklenen dekoratif bir unsur değildir.

Bağlam bir altyapıdır.

Veri, arayüz veya yetkiler gibi planlanmalı, sınırlandırılmalı, güncellenmeli, devredilmeli, sürümlenmeli ve gereksiz yükten temizlenmelidir.

Context Window proje belleği değildir

İlk düşünce hatası daha “bağlam” kelimesinde başlar.

Context Window, öncelikle dil modelinin mevcut çıkarım için kullanabildiği çalışma alanıdır. Sisteme göre burada sistem talimatları, mevcut sohbet, önceki mesajların bir bölümü, dosyalar, araç sonuçları, getirilen veriler ve geçici çalışma durumu bulunabilir.

Bu yararlıdır. Ama güvenilir bir proje arşivi değildir.

Uzun bir sohbet, yapay zekânın “artık her şeyi bildiği” hissini kolayca yaratır. Gerçekte sohbet uzadıkça daha fazla bilgi dikkat için rekabet eder. Eski bilgiler özetlenebilir, sıkıştırılabilir, daha düşük ağırlıkla ele alınabilir ya da güncel bir kararın ihtiyaç duyduğu ayrıntıda artık mevcut olmayabilir.

Pratik sonuç açıktır:

Bir proje kendi durumunu yalnızca sohbetin geçici çalışma yüzeyinde saklamamalıdır.

Sohbet bir çalışma alanıdır. Projenin bunun dışında kalıcı durum nesnelerine ihtiyacı vardır.

Bağlamın beş katmanı

Uzun soluklu yapay zekâ projelerinde açık katmanlar faydalıdır.

Bu katmanlar kontrolsüz biçimde birbirine karışmamalıdır.

Her sohbet tüm proje arşivini taşıyorsa aşırı yük oluşur. Yeni bir sohbet yalnızca kısa bir prompt alırsa bağlam kaybı oluşur. Bir bilgi tabanında her şey bulunuyor ama hangi girdilerin şu anda bağlayıcı olduğu belli değilse semantik belirsizlik oluşur.

Bu nedenle mimari şu soruları yanıtlamalıdır: Neler kalıcı olmalı, bu görev için neler yüklenmeli ve çalışma döngüsü bittikten sonra neler tekrar dışarıda kalabilir?

Proje klasörleri sihirli bellek değil, bağlam sınırlarıdır

İyi bir proje klasörü değerlidir çünkü işi toplar: talimatlar, referans dosyaları, sohbetler ve tekrarlanan proje kaynakları aynı yerde bulunabilir.

Ama proje klasörü bağlam problemini otomatik olarak çözmez.

Onu bir Context Boundary, yani belirli materyallerin, kuralların ve konuşmaların hangi projeye ait olduğunu tanımlayan bir sınır olarak görmek daha doğrudur.

Örneğin şu alanlar ayrılabilir: araştırma veya metodoloji alanı, belirli bir müşteri ya da ürün projesi, deneysel prototip, üretim çalışma alanı ve tamamlanmış kararların arşivi.

Bu ayrım bürokrasi değildir. Bağlam kirlenmesini önler.

Genel araştırmalar, kişisel notlar, farklı müşteri projeleri ve deneysel ajan promptları aynı alanda toplanırsa sistemin geçerli ve geçersiz bilgileri karıştırma ihtimali yükselir.

Proje klasörü alaka düzeyini artırıyorsa iyidir. Yalnızca yığın büyütüyorsa kötüdür.

En iyi proje klasörü en fazla dosyaya sahip olan değildir

Bir proje klasörünün kalitesi dosya sayısıyla ölçülemez.

Sağlam bir klasörün az sayıda ama net ankora ihtiyacı vardır:

1. Project Charter: Hedef, kapsam, kapsam dışı, başarı kriterleri.

2. Current State: Şu anda ne geçerli? Hangi sürüm aktif?

3. Decision Register: Hangi temel kararlar bağlayıcı?

4. Constraints: Hangi kurallar, yetkiler, bütçeler ve yasaklar geçerli?

5. Source Index: Hangi kaynak hangi iddiayı destekliyor?

6. Open Issues: Ne belirsiz, bloke veya tartışmalı?

7. Next Actions: Bir sonraki adımda gerçekten ne yapılabilir?

Bunların etrafına uzmanlık kaynakları ve çalışma artefaktları eklenir.

Fark kritiktir: kaynaklar ne biliyor olabileceğimizi söyler. Kanonik proje durumu ise projenin şu anda neyi geçerli kabul ettiğini söyler.

Sohbetler çalışma alanıdır; projenin işletim sistemi değildir

Uzun bir sohbet son derece verimli olabilir. Stil, alan dili ve yerel kararları iyi tutabilir. Ancak belirli bir noktadan sonra güçlü yanı zayıflığa dönüşür.

Geçmiş büyür, yan konular oluşur, varsayımlar değişir, eski talimatlar görünür kalır ve örtük bağımlılıkların sayısı artar.

“Bu sohbette devam etmeli miyim?” sorusu bu yüzden yalnızca rahatlık sorusu değildir. Bir mimari karardır.

Bir sohbet ideal olarak tutarlı bir çalışma birimini temsil etmelidir. Örneğin net tanımlı bir araştırma sorusu, tek bir modülün mimarisi, bir sürümün review’u, belirli bir slice’ın geliştirilmesi veya sınırları belirli bir work-package’ın uygulanması.

Görev, rol mantığı ya da proje aşaması ciddi biçimde değişiyorsa yeni sohbet çoğu zaman daha temizdir.

Hata, yeni sohbeti düzenli bir handoff olmadan başlatmaktır.

Yeni sohbet projenin yeniden başlaması değildir

Yeni sohbetin büyük avantajı yerel yükü temizlemesidir.

Ama aynı anda proje amnezisi yaratmamalıdır.

Hedef şudur:

taze çalışma bağlamı + stabil proje durumu.

Bunun için eski sohbetin tamamı kör biçimde kopyalanmaz. Yeni çalışma alanına kompakt ve açık bir başlangıç paketi verilir: yeni sohbetin görevi, güncel proje durumu, bağlayıcı kararlar, ilgili kaynak ve artefaktlar, açık riskler, bilinen karşı argümanlar, hedef dışı konular ve net sonraki adımlar.

Böylece tarihsel aşırı yük olmadan süreklilik oluşur.

Handoff, seri hale getirilmiş proje durumudur

Bir devir teslim yalnızca özet değildir.

Özet, neler olduğunu anlatır.

Handoff ise doğru şekilde devam edebilmeyi sağlamalıdır.

En az şu alanları içermelidir:

Böyle bir handoff bir durum konteyneridir.

Yeni oturumun eski kararları yeniden uydurmasını, tamamlanmış işi tekrarlamasını veya eski bir ara durumdan devam etmesini zorlaştırır.

İyi handoff her şeyi taşımaz

Devir teslimi olabildiğince eksiksiz yapmak cazip gelir. Ama eksiksizlik, kullanışlılıkla aynı şey değildir.

Seksen sayfalık sohbet geçmişini içeren handoff problemi yalnızca yeni yere taşır. Yeni oturum yine neyin güncel, önemli ve bağlayıcı olduğunu çözmek zorunda kalır.

İyi handoff üç kural izler.

1. Kronolojiden önce durum

“Önce A oldu, sonra B, sonra C” yerine: “Güncel durum X’tir; X, A ve C kararlarından doğdu; B reddedildi.”

2. Bağlayıcılık durumunu işaretle

Sistem şunları ayırabilmelidir: kararlaştırılmış, deneysel, reddedilmiş, açık ve tarihsel.

3. Kaynağı kopyalamak yerine referans ver

Büyük kanıt paketleri adlandırılır veya referanslanır. Handoff içine yalnızca neden önemli oldukları ve hangi iddiayı taşıdıkları yazılır.

Kanonik durum Ghost Decision’ları engeller

Uzun yapay zekâ projelerinde tehlikeli bir durum oluşur: kararlar yalnızca bazı sohbetlerde yaşar.

Bir oturum API A’nın kullanılmamasına karar verir. Diğer oturum bunu bilmez. Üçüncü ajan API A’yı yeniden cazip bulur ve sisteme ekler. Haftalar sonra ilk ret kararının nedeni belirsizdir.

Bunlar Ghost Decisions’dır: proje üzerinde etkili ama stabil ve bulunabilir durumda olmayan kararlar.

Kanonik bir Current State dokümanı bunu azaltır.

Her tartışmayı içermez. Yalnızca şu anda geçerli olanları tutar: güncel kapsam, güncel mimari, güncel sürümler, aktif kısıtlar, açık riskler, son temel kararlar ve sıradaki onaylı işler.

Sohbetler keşif yapabilir.

Kanonik durum yapmamalıdır.

Kanonik demek değişmez demek değildir

Kanonik durum bir dogma değildir.

Şu anda geçerli olan baseline’dır.

Yeni kanıt bir kararı değiştirirse baseline güncellenir. Önemli olan geçişin görünür olmasıdır.

Basit bir durum mantığı yeterli olabilir:

PROPOSED – önerildi, henüz geçerli değil.

ACTIVE – şu anda bağlayıcı.

SUPERSEDED – daha yeni kararla değiştirildi.

REJECTED – bilinçli olarak reddedildi.

ARCHIVED – tarihsel olarak korunuyor, operatif değil.

Böylece ajanlar yeni fikir geliştirebilir ama her fikir anında yeni gerçekliğe dönüşmez.

Bağlamın tazeliği vardır

Her bilgi aynı hızda yaşlanmaz.

Bir şirket hedefi aylarca stabil kalabilir. Bir API spesifikasyonu günler içinde değişebilir. Bütçe durumu birkaç saat sonra eski olabilir. Bir araştırma bulgusu yıllarca doğru kalabilir ama yeni verilerle yeniden yorumlanabilir.

Bu yüzden bağlamın bir Freshness modeli olmalıdır.

Önemli bağlam nesnelerinde en son ne zaman kontrol edildiği, neye dayanarak geçerli olduğu, ne zaman yeniden kontrol edilmesi gerektiği ve hangi sonraki nesnelerin ona bağımlı olduğu görünür olmalıdır.

Freshness yönetilmezse stale truths oluşur: eskiden doğru olan ama bugünün gerçeğiymiş gibi kullanılmaya devam eden bilgiler.

Bağlam seçimi, maksimum bağlam miktarından daha önemlidir

Büyük Context Window’lar her şeyi yükleme isteği yaratır.

Mantık anlaşılır: model daha çok görürse daha iyi karar vermelidir.

Ama bağlamın fırsat maliyeti vardır. İlgisiz veya çelişkili bilgiler, güncel karar için gerçekten gerekli bilgilerle dikkat için yarışır.

Bu nedenle profesyonel soru şu değildir:

Model ne kadar bağlam alabiliyor?

Asıl soru şudur:

Bu görev için doğru karar vermeyi sağlayan en küçük bağlam seti hangisi?

İşte Context Engineering budur.

Her work-package için bir Context Packet

Sınırları belli işler için küçük bir Context Packet, bütün proje klasörünü prompta doldurmaktan daha etkili olabilir.

Bir Context Packet şunları içerebilir: work-package hedefi, definition of done, ilgili kararlar, gerekli girdiler, etkilenen dosyalar, geçerli kısıtlar, bilinen riskler, beklenen çıktı formatı ve handoff hedefi.

Ajan, tüm projenin yorumcusu olmak zorunda kalmadan tam ihtiyaç duyduğu bilgiyi alır.

Bu yaklaşım kontrollü work-package mantığına doğrudan bağlanır ama bir katman daha ekler: iş paketlerinin yalnızca kapsamı değil, bağlam kapsamı da tanımlanmalıdır.

Ortak bilgi alanı, ortak Context Window değildir

Yapılandırılmış bilgi tabanı, vault, doküman havuzu veya proje repository’si gibi ortak bilgi alanları değerlidir; çünkü birden fazla sohbet ve ajan aynı bilgi temelinden yararlanabilir.

Ama “ortak bilgi”, herkesin her anda aynı tam Context Window’a ihtiyacı olduğu anlamına gelmez.

Çoğu zaman tersi daha iyidir.

Bilgi alanı geniş ve kalıcıdır.

Çalışma bağlamı dar ve durumsaldır.

İyi bir mimari şu ayrımı yapar:

Knowledge Pool: daha geniş ilgili bilgi.

Canonical State: şu anda bağlayıcı proje görünümü.

Retrieval Layer: görev için ilgili bilginin seçimi.

Working Context: ajana gerçekten aktarılan kesit.

Böylece bilgi ile bağlam birbirine karıştırılmaz.

Research Pool ile proje bilgisi farklı şeylerdir

Geniş araştırmalar kısa sürede raporlar, çalışmalar, görüşmeler ve analizlerden oluşan büyük bir havuz yaratır.

Bu havuz değerlidir ama henüz proje durumu değildir.

Şunları içerebilir: çelişkili kaynaklar, farklı tarihsel durumlar, doğrulanmamış hipotezler, rakip yöntemler ve yalnızca başka nişler için geçerli bilgiler.

Research’ten proje bilgisine geçiş bu nedenle bir yoğunlaştırma ister:

kaynak → bulgu → yorum → karar → kanonik durum.

Bu geçiş olmazsa proje klasörü kütüphanecisi olmayan bir kütüphaneye dönüşür.

Paralel sohbetler ayrı çalışma alanları ve ortak entegrasyon noktaları ister

Birden fazla paralel oturum güçlüdür. Biri araştırabilir, diğeri uygulayabilir, üçüncüsü review yapabilir.

Ama paralellik ortak bilinçle karıştırılmadığında işe yarar.

İki sohbet aynı yerel ara adımları otomatik bilmez. İki coding worktree aynı repository’ye dayanabilir ama farklı branch durumları taşıyabilir. İki ajan aynı görevi farklı yorumlayabilir.

Bu nedenle paralel çalışma şunlara ihtiyaç duyar: ayrı yerel çalışma alanları, net girdiler, açık çıktı artefaktları, entegrasyon noktaları, çatışma kuralları ve ortak baseline.

Yazılım geliştirmede bu desen tanıdıktır: aynı repository’ye bağlı birden fazla worktree, farklı branch’lerde paralel çalışmayı mümkün kılar. Ama ortak repository merge disiplininin yerine geçmez.

Yapay zekâ çalışmasında da aynı şey geçerlidir.

Ortak köken, ortak durum demek değildir.

Merge’den önce handoff

Paralel bir çalışma kolu entegre edilmeden önce yalnızca sonucu değil, kısa bir handoff da teslim etmelidir: Ne değişti? Hangi varsayımlar kullanıldı? Hangi dosya veya durumlar etkilendi? Ne test edildi? Hangi belirsizlikler kaldı? Baseline ile hangi çatışmalar mümkün? Integrator’ın neye karar vermesi gerekiyor?

Böylece “çıktım burada” yaklaşımı yerine entegre edilebilir bir iş sonucu oluşur.

Context Drift: Oturumlar yavaşça farklı projeler üretmeye başladığında

Context Drift için büyük bir hata gerekmez.

Yavaşça oluşabilir: bir sohbet eski kapsam sürümünü kullanır, bir ajan yeni kısıtı bilmez, reviewer uygulayıcıdan farklı başarı kriterleri kullanır, bir handoff reddedilmiş varsayımı hâlâ taşır veya bilgi tabanında statüsü belirtilmemiş çelişkili sürümler bulunur.

Birkaç döngü sonra herkes aynı projede çalışıyor gibi görünür ama aslında hafif farklı zihinsel modellere göre çalışmaktadır.

Tehlikeli tarafı, yerel çıktılar tek tek mantıklı görünebilir.

Context Drift için dört sinyal

1. Kapanmış kararların yeniden açılması

Yapay zekâ daha önce kararlaştırılmış konuları tekrar tekrar tartışır.

2. Çelişkili durum iddiaları

Bir sohbet sürüm 3’ü, diğeri sürüm 4’ü güncel kabul eder.

3. Farklı Definition of Done

Ajanlar biçimsel olarak bitmiş ama proje açısından eksik işler teslim eder.