Bağlam mühendisliği: istemden önceki çalışma
· 5 min read · Filippo Spinella · AI, Agents, Prompting, Developer Tools
Yapay zeka ajanlarının küçük dünyasında şu anın sözcüğü bağlam mühendisliğidir.
Zaten yaptığımız bir şeyi satmak için başka bir etiket icat edilmiş gibi görünüyor. Kısmen öyle. Ancak çoğu zaman olduğu gibi bu etiket dikkat çekiyor çünkü gerçek bir acıya isim veriyor.
Sorun şu: Modeller sırf "düşünmüyorlar" diye başarısız olmuyorlar. Çoğu zaman başarısız oluyorlar çünkü onları çalışmaya yanlış odaya gönderiyoruz.
Onlara eski talimatları veriyoruz. Önemli dosyaları ondan saklıyoruz. Onlara çok uzun ve neyin önemli olduğunu söylemeyen belgeler veriyoruz. Onlara öncelik olmadan günlükleri gösteririz. Ne zaman kullanacaklarını açıklamadan onlara on araç veriyoruz. Sonra ajanın bilinmeyen bir dairede uyanmış biri gibi hareket etmesi bizi şaşırtıyor.
İstem, ona söylediğiniz ifadedir. Bağlam, onun etrafında hazırladığınız dünyadır.
Hızlı mühendislikten bağlam mühendisliğine
Hızlı mühendislik genellikle yazı yazmak olarak düşünülürdü. Doğru kelimeleri seçin, doğru şekilde sorun, örnekler ekleyin, formatı belirtin.
Bağlam mühendisliği mimariye daha yakındır.
Sadece "talebi nasıl formüle edebilirim?" diye sormazsınız. Şunu sorar:
- Gerçekten hangi bilgilere ihtiyaç var?
- gürültü nedir?
- anında neyin kurtarılması gerekiyor?
- ne hatırlanmalı?
- hangi araçlar açığa çıkarılmalıdır?
- hangi talimatlar kararlıdır ve hangileri göreve bağlıdır?
- Temsilcinin neyin yetkili olduğunu anlamasını nasıl sağlayabilirim?
Bu ince ama çok büyük bir değişiklik. Çünkü aracılarla çalıştığınızda bağlam statik bir blok değildir. Her adımda değişiyor.
Aracı bir dosyayı açar, bir şeyler öğrenir, bir test yapar, bir hata alır, planı günceller, bir aracı çağırır, bir bağımlılığı keşfeder. Her turda yanına neleri alıp neyi dışarıda bırakacağına karar vermesi gerekiyor.
Bu mühendisliktir.
Bağlam çöp sahası değil
Büyük bağlam pencerelerine sahip şablonlar bizi baştan çıkardı: hadi her şeyi içine koyalım.
Bu anlaşılabilir bir durum. Bir milyon jetonum varsa neden seçeyim?
Çünkü her şeyi koyabilseniz bile, bu her şeyin işe yaradığı anlamına gelmez. Aslında gürültünün bir bedeli vardır. Belirteçlere mal olur, dikkat gerektirir, gecikmeye mal olur, kaliteye mal olur. Bir model, tıpkı bizim gibi yirmi sekme açtığımızda nedenini hatırlamadığımızda alakasız ayrıntılar içinde kaybolabiliyor.
İyi bağlamın bir hiyerarşisi vardır:
- sistem talimatları ve politikaları;
- özel amaç;
- mevcut durum;
- ilgili veriler;
- kısıtlamalar;
- mevcut araçlar;
- Halihazırda alınmış kararları takip edin.
Her şeyi aynı seviyede ele almaya gerek yok. Bir kullanıcı komutu eski bir nottan daha değerlidir. Başarısız bir test artık üç ay önceki estetik tercihten daha değerli. Bir güvenlik politikası üretim kısayolundan daha değerlidir.
Bağlam mühendisliği aynı zamanda yalnızca verilere değil, ağırlıklara da yer verilmesi anlamına gelir.
Bellek: daha az hatırla, daha iyi hatırla
Ajanlarda hafıza en kaygan konulardan biridir.
Bir kullanıcı olarak temsilcinin sizi tanımasını istersiniz. Onun üslubunu, planını, geleneklerini, önceden kararlaştırılmış şeyleri hatırlamasını istiyorsun. Bir mühendis olarak, her kalıcı hafızanın aynı zamanda bir risk olduğunu da biliyorsunuz: Yanlış, eski, fazla kişisel, fazla genel ve doğrulanamaz olabilir.
Yararlı bir hafızanın en az üç özelliğe sahip olması gerekir:
- kaynak: bu bilgi nereden geliyor?
- tarih: ne zaman doğruydu?
- amaç: ne tür bir görev için kullanılmalı?
Bu üç şey olmadan hafıza batıl inanç haline gelir.
Fail hafızasını büyülü bir zihin olarak değil, bir çalışma kitabı olarak düşünmeyi seviyorum. Geçici notlar, onaylanmış kararlar, stil tercihleri, teknik kısıtlamalar, kaynaklara bağlantılar var. Bazı şeylerin süresi doluyor. Bazılarının yeniden yazılması gerekiyor. Temsilci onları yanlış anladığı için bazılarının elenmesi gerekiyor.
İyi bir sistemin bu bakımı normal hale getirmesi gerekir. Kahramanca değil.
Erişim ve araçlar aynı şey değildir
Bağlam hakkında konuştuğumuzda çoğu zaman kendimizi hemen RAG'da buluruz. Gömme, vektör veritabanı, parçalama, yeniden sıralama.
Hepsi faydalı. Ancak geri alma, bilgiyi modele getirmenin yalnızca bir yoludur. O tek kişi değil.
Bir aracı, dosyaları okuyarak, bir API'yi sorgulayarak, bir MCP sunucusunu arayarak, bir tarayıcı açarak, testler çalıştırarak, Slack'te arama yaparak, kontrol paneline bakarak, insana sorarak bağlam elde edebilir.
İlginç olan, hangi rotanın ne zaman kullanılacağına karar vermektir.
Temsilcinin tarihsel bir soruyu yanıtlaması gerekiyorsa, belki de yalnızca geri almak yeterlidir. Bir hatayı düzeltmek zorundaysa gerçek kodu okumak zorundadır. Bir dağıtımın neden başarısız olduğunu anlaması gerekiyorsa yeni günlüklere bakması gerekir. Bir müşteriye yazmanız gerekiyorsa biletin tonunu, geçmişini ve durumunu almanız gerekir. Eğer üretimle ilgili bir faaliyette bulunacaksa izin istemelidir.
Bağlam bir veritabanı değildir. Bu bir iş akışıdır.
İyi bir temsilci nasıl görmezden gelineceğini de bilir
Temsilcilerde olgunluğun bir işareti şunu söyleyebilmektir: Bu bilgiye ihtiyacım yok.
Önemsiz gibi görünüyor ama çok zor. Pek çok etmenli sistem birikir. Her araç çağrısı metin ekler. Her hata arabellekte kalır. Okunan her dosya yığına eklenir. Sonuçta modelin çok uzun bir geçmişi var ve haritası yok.
Sıkıştırma gereklidir. Ara senteze ihtiyaç vardır. Yapılandırılması gerekiyor.
"Olan bu kadar" değil ama:
- amaç hâlâ geçerli;
- mevcut hipotez;
- dosyalar zaten kontrol edildi;
- alınan kararlar;
- açık riskler;
- sonraki eylem.
Bu, temsilciyi daha az teatral ve daha yararlı kılar. Daha akıllı göründüğü için değil, düzenli bir masayla çalıştığı için.
Hızlı sanatçılar için değil, ekipler için bağlam mühendisliği
Bu konunun ilgimi çekmesinin nedeni sorumluluğun bireyden sisteme kaydırılmasıdır.
Hızlı mühendislikte, modelle en iyi şekilde konuşabilen kişi çoğunlukla kazanır. Bağlam mühendisliğinde işini en iyi organize eden ekip kazanır: dokümantasyon, kurallar, sorunlar, günlükler, testler, sahiplik, adlandırma, kaynaklar.
Temiz bir depo daha iyi bir bağlam haline gelir. İyi yazılmış bir konu daha iyi bir yakıt haline gelir. Güncelleştirilmiş bir runbook, belirteçlerden ve endişelerden tasarruf sağlar. Açık bir değişiklik günlüğü halüsinasyonları azaltır.
Bu iyi ve biraz da rahatsız edici bir haber. Güzel çünkü iyi uygulamaları ödüllendiriyor. Uygunsuz çünkü her şeyi akıllı bir istemle çözemezsiniz.
Ajanlar buldukları sistemin hijyenini artırır.
Yarın bunu nasıl uygulardım
Bağlam mühendisliğini gerçek bir projeye dahil edecek olsaydım küçük şeylerden başlardım:
- kısa ve bakımı yapılmış bir proje talimat dosyası;
- beklenen çıktıya ilişkin iyi örnekler;
- mevcut araçların ve bunların kullanılacağı durumların bir listesi;
- Alıntı yapılabilir bir şekilde yazılmış mimari kararlar;
- asgari zorunlu bağlamla ilgili sorun;
- günlükleri ve testleri almak kolaydır;
- İnsanlar tarafından değiştirilebilen kalıcı hafıza.
Daha sonra basit bir şeyi ölçerdim: Temsilcinin kaç kez açıklama istemesi gerekiyor veya yanlış yöne gidiyor?
Sık sık oluyorsa hemen daha büyük bir model eklemezdim. Bağlama bakardım.
Okumalarım
Bağlam mühendisliği biraz şişirilmiş bir kelime, evet. Ama konsept sağlam.
Bize bir ajanın zekasının sadece modelde olmadığını hatırlatır. Önemli olan onun için hazırladığımız ortamda yatıyor: Ne gördüğü, ne hatırladığı, ne yapabileceği, ne yapmasının yasak olduğu, hangi kaynakları doğru kabul ettiği.
İnsani tarafı şudur: Ortamı iyi hazırlamak bir bakım şeklidir. Bu menajere ve aynı zamanda ekibe şunu söylemektir: "Tahmin etmenizi istemiyorum, ihtiyacınız olan şeye sahip olmanızı istiyorum."
Daha az büyü. Temiz oda. Bizim kadar acentelerin de buna ihtiyacı var.