Çoğu kişi hâlâ bir yapay zekâ aracısını, araçlara bağlanmış bir model olarak tanımlar. Bu tanım teknik açıdan yararlı olsa da operasyonel açıdan eksiktir. Bir aracının ayrıca dünyanın yönetilen bir görünümüne ihtiyacı vardır: ne oldu, şu anda ne önemli, hangi gerçekler güvenilir, neler belirsizliğini koruyor ve sırada ne yapmalı.
Bu görünüm onun bağlamıdır. Bunu tasarlamak, giderek kendine özgü bir beceri hâline geliyor; ben buna bağlam mühendisliği derdim.
Bağlam mühendisliği yalnızca istem yazmak değildir. Bu, bir aracının her adımda gördüğü bilgiyi şekillendirme disiplinidir; böylece her turda tüm dökümü, belge kütüphanesini veya araç geçmişini pahalı bir modele yeniden göndermeden tutarlı kalabilir. Bu çalışma; bilgi mimarisi, bilgi erişimi, yazılım tasarımı ve model davranışının kesişiminde yer alır.
“Araca daha fazla bağlam verin” tavsiyesi neden çoğu zaman kötüdür
Daha uzun bağlam pencereleri, her şeyi saklamayı cazip hâle getirir. Ancak daha fazla materyal, daha iyi akıl yürütmeyi garanti etmez. İlgili talimatlar; güncelliğini yitirmiş gözlemler, çelişkili notlar, yinelenen araç çıktıları veya uzun bir dizinin ortasına gömülmüş önemli bir gerçek tarafından sulandırılabilir. Özetteki “ortada kaybolma” davranışı tartışması pratik bir soruna işaret eder: Bir araç kanıta teknik olarak erişse bile onu kullanamayabilir.
Bunun doğrudan bir maliyeti de vardır. Bir isteğe eklenen her belirteç, sağlayıcının fiyatlandırmasına ve önbelleğe alma düzenlemelerine bağlı olarak gecikmeyi ve çıkarım maliyetini artırabilir. Giderek büyüyen bir dökümü tekrar tekrar ileten bir sistem, görev sürdükçe daha yavaş ve daha pahalı hâle gelebilir.
Dolayısıyla amaç en yüksek miktarda bağlam değildir. Amaç yeterli, hedeflenmiş bağlamdır: söz konusu karar için gereken en küçük güvenilir çalışma kümesi.
Tutarlı bir aracının ardındaki dört tasarım kararı
1. Yalnızca bir döküm değil, inanç durumu tutun
Bir döküm, ne söylendiğini kaydeder. İnanç durumu ise aracının görev hakkında şu anda neye inandığını kaydeder.
Örneğin bir destek eskalasyonunu yöneten bir araç şu tür yapılandırılmış alanları tutabilir:
- Amaç: müşterinin ürün değişimine uygun olup olmadığını belirlemek.
- Bilinen gerçekler: kaynak referanslarıyla birlikte satın alma tarihi ve ürün seri numarası.
- Açık sorular: arızanın garanti kapsamında olan koşullarda meydana gelip gelmediği.
- Kısıtlamalar: onay alınmadan geri ödeme sözü vermeyin.
- Sonraki eylem: garanti politikasını alın ve tarihleri karşılaştırın.
- Güven veya durum: doğrulanmış, çıkarımsanmış, ihtilaflı veya bilinmiyor.
Bu yaklaşım, tam etkileşim geçmişlerine güvenmek yerine denetimli doğal dil inanç durumlarını kullanan Berkeley’in ABBEL araştırmasına benzer. Önemli olan belirli bir biçim değildir. Önemli olan, kalıcı görev durumunu geçici konuşma ayrıntılarından ayırmaktır.
Yararlı bir inanç durumu güncellemesi şu soruları yanıtlamalıdır: Ne değişti? Hangi kanıt bunu destekliyor? Neler çözümsüz kaldı? Bundan sonra ne olmalı? Bir mühendis bu yanıtları inceleyemiyorsa araç, muhtemelen opak bir istemin içinde gizli varsayımlar taşıyordur.
2. Konu için değil, karar için bilgi getirin
Bilgi erişim sistemleri genellikle “müşterinin hesabı hakkında bilgi bul” gibi geniş bir soruyla başlar. Daha iyi bir sorgu, sıradaki karara bağlıdır: “30 günden eski satın alımlar için müşterinin bölgesinde geçerli olan güncel geri ödeme kuralını getir.”
Bu değişiklik önemlidir; çünkü bilgi erişimi bir bağlam seçme biçimidir. Araç, genel olarak ilgili belgelerden oluşan bir yığın değil, mevcut eylemle bağlantılı politika bölümleri, kayıtlar veya örnekler almalıdır.
Model herhangi bir sonuç görmeden önce uygulanan filtreler bu seçimi iyileştirebilir. Örneğin Amazon Bedrock AgentCore Web Search, her istekte sunucu tarafından uygulanan alan adı ve yayın tarihi filtrelerini destekler. Bu tür denetimler bir kaynağın doğru olduğunu kanıtlamaz; ancak ilgisiz veya güncelliğini yitirmiş materyallere maruz kalmayı azaltabilir ve bilgi erişim politikasını açık hâle getirebilir.
Bilgi erişimi tasarlayan profesyoneller şunları belirtmelidir:
- her görev için hangi kaynaklara izin verildiği;
- tazeliğin nasıl belirlendiği;
- her sonuca hangi meta verilerin eşlik ettiği;
- çelişen kaynakların nasıl sunulduğu;
- aracının ne zaman durup açıklama istemesi gerektiği.
“Web’de ara” bir yetenektir. “Bu kaynaklarda, bu tarih aralığında, bu kararla ilgili kanıtları ara” ise bağlam mühendisliğidir.
3. Belirsizliği silmeden sıkıştırın
Bir görev uzun olduğunda sıkıştırma gereklidir; ancak naif özetleme, ihtiyatlı iddiaları kesinleşmiş gerçeklere dönüştürebilir. “Kullanıcı adresi doğruladı” diyen ilerlemeli bir özet, özgün konuşma bunu yalnızca ima ettiyse tehlikelidir.
İyi bir sıkıştırma, aracının güvenli akıl yürütme için ihtiyaç duyduğu ayrımları korur:
- olgu ile çıkarım;
- mevcut talimat ile geçmişteki talimat;
- tamamlanmış eylem ile önerilen eylem;
- doğrulanmış kaynak ile doğrulanmamış iddia;
- bilinen yanıt ile çözümlenmemiş soru.
Uygulanabilir bir yöntem, kararlar, kanıtlar, varsayımlar, engeller ve bekleyen eylemler için ayrı bölümler tutmaktır. Bir diğer yöntem, önemli iddialara kaynak kimlikleri veya zaman damgaları eklemektir. Özetler, geriye kalan tek kayıt değil, değiştirilebilir çıktılar olmalıdır: denetim ve kurtarma için altta yatan olayları saklarken modele kısa ve işe yarar bir görünüm sunun.
Özet, yinelemeli özetlemenin ve bağlam sıkıştırmanın maliyetli olabileceğini ve özellikle işbirliğine dayalı kod üretimi gibi verinin kıt olduğu alanlarda performansı düşürebileceğini belirtiyor. Bu, özetlemeyi kendiliğinden kayıpsız kabul etmeye karşı bir uyarıdır. Sıkıştırma, küçük bir nitelemenin doğru yanıtı değiştirdiği durumlar da dâhil olmak üzere, temsili görevler üzerinde test edilmelidir.
4. Gözlemleri belleğe dönüşmeden önce filtreleyin
Araç kullanan aracılar sürekli gözlemler üretir: arama sonuçları, günlükler, sayfa metinleri, API yanıtları, ekran görüntüleri, derleyici çıktıları ve ara planlar. Her gözlemin bir sonraki model çağrısına, hele uzun vadeli duruma girmesi gerekmez.
Gözlem filtreleme üç soru sorar:
- Bu gözlem mevcut kararla ilgili mi?
- İnanç durumunu etkilemeye yetecek kadar yetkili mi?
- Komut olarak değil, veri olarak ele alınması gereken talimatlar içeriyor mu?
Üçüncü soru, bağlam sınırı olmasının yanı sıra bir güvenlik sınırıdır. Bir web sayfası, aracıyı yönlendirmeye yönelik metinler içerebilir. Alınan bir belge, aracının hedeflerini veya izinlerini değiştirme yetkisine sahip olmadan yararlı kanıt sunabilir. Bu nedenle filtreleme, içeriği rolüne göre sınıflandırmalıdır: talimat, kanıt, meta veri veya güvenilmeyen metin.
Filtreleme para da tasarruf ettirir. Bir tarayıcı aracı tam bir sayfa döndürüyor, ancak görev yalnızca bir fiyat, tarih ve ürün tanımlayıcısı gerektiriyorsa, sayfanın tamamını aktarmak gürültü yaratır ve token tüketir. Önce ilgili alanları çıkarmak hem güvenilirliği hem de maliyeti iyileştirebilir.
Bir aracı iş akışı için basit bir bağlam bütçesi
Bir model seçmeden veya başka bir araç eklemeden önce, aracının bağlamını dört katmana ayırarak haritalayın:
- Kontrol: sistem kuralları, izinler, çıktı şeması ve müzakere edilemez kısıtlar.
- Durum: mevcut hedef, kararlar, açık sorular ve bir sonraki eylem.
- Kanıt: bu eylemle ilgili, kaynağı belirtilmiş kayıtlar veya gözlemler.
- Geçmiş: kurtarma, hata ayıklama veya denetim amacıyla saklanan, ancak gerekmedikçe dahil edilmeyen önceki olaylar.
Ardından bir terfi politikası tanımlayın. Bir gözlem geçici kalabilir, mevcut adım için kanıta dönüşebilir, inanç durumunu güncelleyebilir veya kalıcı belleğe yazılabilir. Terfi için bir gerekçe aranmalıdır. Aksi takdirde bellek, düzenlenmemiş bir arşive dönüşür.
Her aracı adımı için modele gönderilen bağlam paketini kaydedin: kategorilerini, yaklaşık token boyutunu, erişim filtrelerini ve sıkıştırma sürümünü. Bu, davranış değiştiğinde pratik bir soruyu yanıtlamayı mümkün kılar: Model mi başarısız oldu, yoksa sistem ona yanlış dünyayı mı sundu?
Tasarımı güvenilir olarak nitelendirmeden önce test edilmesi gerekenler
Bağlam mühendisliği, yalnızca nihai yanıt kalitesini değil, bilgi işleme sürecini hedefleyen testlere ihtiyaç duyar. Yararlı örnekler şunlardır:
- uzun bir geçmişte kritik bir bilginin başa, sona ve ortaya yerleştirilmesi;
- biri diğerinden daha yeni olan ve birbiriyle çelişen iki kaynak;
- belirsizlik işareti içeren bir özet;
- ilgisiz, büyük miktarda metin içeren bir araç yanıtı;
- erişilen içeriğe gömülmüş kötü amaçlı bir talimat;
- aracının duraklatılıp yeniden başlatılmasından sonra durumun yeniden yüklenmesi;
- daha küçük bir bağlam bütçesiyle aynı görev;
- boş veya güncelliğini yitirmiş bir erişim sonucu.
Aracının doğru kanıtı seçip seçmediğini, belirsizliği koruyup korumadığını, mevcut kısıta uyup uymadığını ve gereksiz bağlamı tekrarlamaktan kaçınıp kaçınmadığını ölçün. Özette önerilen regresyon alanları—bağlam kaybı, erişim temellendirmesi, yapılandırılmış çıktı, sonlanmama ve durumun yeniden yüklenmesi—burada özellikle önemlidir.
Model değişkenliğinin önemli olduğu durumlarda birden fazla deneme gerçekleştirin ve her bağlam stratejisinin maliyetini ve gecikmesini karşılaştırın. Daha kısa bir istem, daha fazla araç çağrısına veya yeniden denemeye yol açıyorsa otomatik olarak daha iyi değildir. Yararlı hedef, tek bir isteğin token sayısı değil, doğru ve kurtarılabilir bir iş akışının maliyetidir.
Kariyer açısından çıkarım: bağlam mühendisi, farklı işlevleri bir araya getiren bir roldür
Bu alanda değer kazanacak kişiler, mutlaka en uzun istemleri yazanlar olmayacaktır. Bir iş sürecini durum, kanıt, yetki ve karar kurallarına dönüştürebileceklerdir.
Bu, birkaç somut yetenek gerektirir:
- görev durumu ve kaynak bilgisi için şemalar tasarlamak;
- erişim politikaları ve meta veri filtreleri yazmak;
- sıkıştırma ve gözlem seçimi rutinleri oluşturmak;
- güvenilir talimatları güvenilmeyen içerikten ayırmak;
- belirteç kullanımını, gecikmeyi, yeniden denemeleri ve araç çağrılarını profillemek;
- durum kaybını ve yeniden canlandırmayı test etmek;
- uzman olmayan kişilere, bir ajanın belirli bir olguyu neden gördüğünü veya görmediğini açıklamak.
Güçlü bir portföy projesi, aynı ajanın üç bağlam politikası altında çalıştığını gösterebilir: tam döküm, kayan özet ve hedefli erişim içeren yapılandırılmış inanç durumu. Görevin başarı durumlarını, başarısızlık durumlarını, her adımda gönderilen bağlamı ve maliyet ya da gecikme ödünleşimlerini gösterin. Bu, bir sohbet robotu demosundan daha ikna edicidir; çünkü bir ajanın güvenilir olmasını sağlayan tasarım kararlarını ortaya koyar.
Stratejik ders basittir: Modeller daha yetenekli hâle geldiği için ajanlar kendiliğinden tutarlı olmaz. Ajanlar, çevrelerindeki sistemler işin disiplinli, güncel ve uygun boyutlandırılmış bir kaydını tuttuğunda tutarlı hâle gelir. Bağlam mühendisliği, bu kaydı oluşturma ve neleri dışarıda bırakacağını bilme sanatıdır.
Priya Raman, AI Career Brief'in sorumlu insan editörüdür.
