Pratik
LLM agent'larıyla çalışmanın yaygın bir tarifi, bazı kişilerin "modeli sorguladığı", bazılarının ise ilk cevabı kabul ettiğidir. Bu çerçeveleme, sorgulamayı bir mizaç olarak ele alır. Değildir. Sorgulama bir inceleme yöntemidir: bir çıktının sonuç sayılabilmesi için önce o çıktıya sorulan tanımlı bir soru kümesi. Ayrım önemlidir çünkü yöntemler yazıya dökülebilir, atanabilir, örneklenebilir, denetlenebilir ve iyileştirilebilir. Mizaçlar dökülemez.
Yöntem basittir. Üretilen bir cevabı okuyup kulağa doğru gelip gelmediğini yargılamak yerine, gözden geçiren kişi agent'tan cevabın arkasındaki kanıtı, değerlendirdiği alternatifleri, belirttiği güvenin dayanağını ve onu neyin yanlışlayacağını ister. Bunlar retorik sorular değildir. Her birinin doğru bir cevap şekli vardır ve o şekli üretemeyen bir agent, düzyazısındaki değil pipeline'ındaki bir boşluğu ortaya koymuştur.
Bu, iyi bir kod incelemesinin yaptığı hamlenin aynısıdır. Bir pull request, diff makul göründüğü için merge edilmez; yazar bu değişikliğin neden başka bir değişiklik değil de bu olduğunu, neye bağlı olduğunu ve nasıl test edileceğini açıklayabildiği için merge edilir. Agent çıktısı da aynı muameleyi hak eder ve ekiplerin ilk cevaplara güvenmek yerine model çıktısını sorgulamasına dair son haberler, bu disiplinin yayıldığının tarifidir, ortaya çıkan bir kişilik tipinin değil.
Sorgulama aslında neyi sorar
Faydalı bir sorgulamanın dört sorusu vardır ve bunlar görev sınıfları arasında genellenir:
- Kanıt: bu cevap hangi kaynaklara, tool sonuçlarına veya verilere dayandı?
- Alternatifler: başka hangi dallar değerlendirildi ve neden reddedildi?
- Güven dayanağı: bu cevabı özellikle daha kesin ya da daha belirsiz kılan nedir — kaynakların kapsamı, tool'lar arasındaki uyum, istekteki belirsizlik?
- Yanlışlama: hangi gözlem bu cevabı yanlış yapar ve o gözlem mevcut mu?
Dördüncü soru, incelemeyi teselliden ayıran sorudur. Mevcut hiçbir gözlemle yanlışlanamayan bir cevap bir iddia değildir; bir niyet beyanıdır. Gözden geçirenler de ona göre davranmalıdır.
Yöntem ancak agent ara artefaktları ortaya çıkarabiliyorsa işler. Retrieval, tool kullanımı ve dal seçimi bir kara kutu içinde gerçekleşip yalnızca nihai metin dışarı veriliyorsa, sorgulamanın tutunacak bir şeyi yoktur. Gözden geçiren kişi modelden içebakış yapmasını istemeye indirgenir ki bu, kanıt değil makul görünen bir anlatı üretir. Dolayısıyla mühendislik gereksinimi incelemenin yukarısındadır: gösterilecek artefaktların var olması için run'ın enstrümante edilmesi gerekir.
Bunu mümkün kılmak için nelerin kaydedilmesi gerekir
Üç kayıt kategorisi sorgulamayı mümkün kılar. Yöntemin tiyatrodan fazlası olması için hiçbiri isteğe bağlı değildir.
Retrieval kökeni. Getirilen her pasaj için: belge tanımlayıcısı, belge sürümü veya hash'i, span offset'leri, onu ortaya çıkaran sorgu ve geldiği sıra. Sürüm önemlidir çünkü bir belge run ile inceleme arasında değişebilir ve cevabı güncel metinle karşılaştıran bir gözden geçiren, onu yanlış metinle karşılaştırıyor olabilir. Span offset'leri önemlidir çünkü tüm bir belgeye yapılan atıf kanıt değildir; bir paragrafa yapılan atıf kanıttır.
Tool çağrısı kayıtları. Her tool çağrısı için: tool adı, tam girdi, tam çıktı, zaman damgası ve varsa hata durumu. Bir başarı bayrağı kayıt değildir. Gözden geçirenlerin tool'a ne sorulduğunu ve ne döndürdüğünü görmesi gerekir çünkü agent hatalarının büyük bir kısmı girdi oluşturma hatalarıdır — tool doğru çağrılmış ve ona yanlış şey sorulmuştur.
Reddedilen dallar ve gerekçeleri. Agent bir planı keşfedip onu attığında, atılan plan ve atılma gerekçesi saklanmalıdır. Bir gözden geçirenin hayatta kalan yol yerine arama uzayını görmesini sağlayan budur. Bu olmadan gözden geçiren, agent'ın bariz alternatifi değerlendirip kanıta dayanarak mı reddettiğini yoksa hiç mi değerlendirmediğini ayırt edemez. Bu iki durum nihai çıktıda birebir aynı görünür ve sonuçları açısından tamamen farklıdır.
Somut bir mekanizma: çıktının yanında, yukarıdaki her kategori için bir bölüm içeren yapılandırılmış bir run kaydı yayınlayın ve inceleme arayüzünün o kaydı cevabın yanında göstermesini sağlayın. Gözden geçirenin işi, tek bir artefaktı tahmin etmek yerine iki artefaktı birlikte okumaya dönüşür.
Bunu bir inceleme kapısına dönüştürmek
Yöntem, b
ekir.
Birincisi, görev sınıfı başına küçük bir sorgulama sorusu kümesi tanımlayın. Retrieval ağırlıklı bir soru-cevap görevi köken ve sürüm soruları gerektirir. Bir planlama görevi alternatifler ve yanlışlama soruları gerektirir. Tool ağırlıklı bir görev girdi oluşturma ve hata yönetimi soruları gerektirir. Kümeyi küçük tutun — sınıf başına üç ila beş — böylece bunları yanıtlamak bir proje değil rutin bir adım olur.
İkincisi, bir run tamamlandı olarak işaretlenmeden önce cevapları zorunlu kılın. Bu bir öneri değil, bir durum geçişidir. Sınıf sorularını yanıtlayamayan bir run tamamlanmış değildir; bekleyen durumdadır ve yükseltilir. Yükseltme sinyalin kendisidir: yanıtlayabilmesi gereken bir soruyu yanıtlayamayan bir agent, size retrieval'ı veya tooling'i hakkında belirli bir şey söylemiştir.
Üçüncüsü, run'ları sabit bir oranda insan sorgulaması için örnekleyin. Otomatik kapılar yapısal hataları yakalar; insanlar anlamsal olanları yakalar. Sabit bir örnekleme oranı — yüksek sonuçlu bir sınıfta her run, daha düşük olanlarda bir kesir — insan inceleme yükünü öngörülebilir ve kapsamı dürüst tutar.
Bu kapının en değerli çıktısı bireysel karar değildir. Tekrarlayan yanıtlanamaz sorudur. Aynı soru birçok run'da başarısız olduğunda, düzeltme bir prompt yamasına değil retrieval'a veya tooling'e aittir. Agent'a sahip olmadığı bir cevabı anlattıran bir prompt yaması, başarısızlıktan daha kötüdür çünkü sinyali ortadan kaldırır.
Sınırlar ve ödünleşimler
Kendi bildirdiği güven kanıt değildir. Bir agent güvendiğini söylediğinde, bu üretilmiş bir token dizisidir, bir ölçüm değil. Yöntem dış artefaktlara — getirilen span'lere, tool çıktılarına, dal kayıtlarına — bağlıdır ve bunların olmadığı yerde sorgulama, modelden kendini tanımlamasını istemeye indirgenir. Bu tanımlama bir bulgu olarak değil, bir iddia olarak kaydedilmelidir.
Sorgulama ayrıca gecikme ve maliyet ekler. Yapılandırılmış run kayıtları üretmek, reddedilen dalları saklamak ve kapı sorularını yanıtlamak hesaplama ve depolama tüketir; insan örneklemesi ise gözden geçiren zamanını tüketir. Bu yüzden yöntem önce yüksek sonuçlu yollara aittir: geri alınması pahalı kararlar, müşterilere ulaşan çıktılar veya üretim sistemlerine dokunan eylemler. Daha düşük sonuçlu yollar, pratik yerleşene ve tooling genişletilecek kadar ucuzlayana dek daha hafif enstrümantasyonla çalışabilir.
Dürüst özet şudur: sorgulama, gerçek bir maliyeti ve gerçek bir getirisi olan bir inceleme disiplinidir. Neyin loglandığını değiştirir çünkü kapı, köken ve tool kayıtları olmadan işleyemez. Neyin incelendiğini değiştirir çünkü gözden geçirenler yalnızca nihai metni değil run kayıtlarını okur. Ve neyin sevk edildiğini değiştirir çünkü sınıf sorularını yanıtlayamayan bir run geçmez. Bunu benimseyen ekipler mizaç olarak daha şüpheci değildir. Şüpheciliği, ölçülebilir ve sürdürülebilir olduğu pipeline'a taşımışlardır.
Bunun inceleme sürecinde bıraktığı yer
Bir kenara bırakılacak çerçeve, bazı mühendislerin modelleri sorguladığı, bazılarının sorgulamadığıdır. Benimsenmesi gereken çerçeve, sorgulamanın tanımlı soruları, tanımlı artefaktları ve tanımlı yükseltmesi olan bir kapı olduğudur. Bu kapı, bir değerlendirme pratiği ile bir görüş arasındaki farktır. Aynı zamanda pratiğin bir personel değişimini, bir model değişimini veya bir görev sınıfı değişimini atlatan tek versiyonudur — yani inşa etmeye değer tek versiyonu.