Microsoft ve Hugging Face'in ThinkingBox'u yapay zeka ajanları kelimelere değil terminal durumuna göre değerlendiriyor

Sistemi notlandıran, dökümü değil notlandıran bir benchmark

Igor Eduardo'nun dev.to'daki yazısına göre Microsoft ve Hugging Face, yapay zeka ajanlarını ürettikleri cümleler yerine gerçekten meydana getirdikleri backend durumu ve yan etkilere göre notlandıran ThinkingBox adlı bir benchmark yayımladı. Yazıda belirtildiği kadarıyla benchmark, 507 durum bilgisi taşıyan (stateful) iş akışını kapsıyor ve her görevi 20 kez çalıştırarak bir ajanın başarıyı bir kez tarif etmek yerine güvenilir biçimde doğru bitiş durumuna ulaşıp ulaşamadığını test ediyor. Eduardo, benchmark'ı kendisinin çalıştırmadığını ve bu rakamların yazarlarına ait olduğunu özenle belirtiyor.

Etrafında inşa edildiği başarısızlık

Yazıda aktarıldığı üzere benchmark'ın açılış örneği, düzgün biçimlendirilmiş dokuz tool çağrısı yapan ve bir bileti çözüldü olarak işaretleyen, ancak yanlış olan bir destek ajanı: bir taşıyıcı istisnası hâlâ açıktı, bu yüzden gereken bitiş durumu "beklemede" olmalıydı. Tool çağrılarını okuyan bir değerlendirici dokuz temiz çağrı görür. Veritabanı aynı fikirde değil.

Eduardo'nun daha geniş argümanı, çoğu ajan panosunun "başarılı olduğunu söyledi mi?" sorusuna cevap verdiğidir. Durum dizgileri, trace'ler ve nihai özet, eylemi gerçekleştiren aynı koşuş tarafından üretilir; bu da onları hata ayıklama için yararlı ama not olarak işe yaramaz kılar. Değerlendirme ve ajan aynı tanığı paylaştığında, kendinden emin bir şekilde yanlış bir eylem, doğru bir eylemle aynı puanı alır ve başarısızlık daha sonra bir müşteri şikayeti, bir defter tutarsızlığı veya bir denetim bulgusu olarak yeniden ortaya çıkar. "Tanık Şüphelinin Kendisiydi" başlıklı bir dev.to yazısı aynı noktayı olay tarafından ele alıyor: bir ajan kendi başarı günlüğünü yazdığında, olayın kaydını olayın nedeni yazmış olur.

Aktörü değerlendiriciden ayırmak

Eduardo, sonuç temelli bir değerlendirmenin cevaplaması gereken beş soru taslaklıyor. Birincisi, koşuştan önce yazılmış, görev gerçekten tamamlandığında kaydın nasıl görünmesi gerektiğini belirten zorunlu bir bitiş durumu. İkincisi, ajanın etkileyemeyeceği bir sorgu üzerinden nihai durumun okunması için bağımsız bir okuma yolu. Üçüncüsü, biletler, iadeler, e-postalar ve veritabanı satırları gibi yan değişiklikleri kapsayan bir yan etki defteri; böylece doğru ana kayıt, çevresindeki yanlış yazımlarla sessizce geçemez. Dördüncüsü, durum denetimi başarısızken başarı iddia eden koşuşlar için ayrı sayılan bir başarısızlık modu. Beşincisi, aynı görevin birden çok koşuşta aynı bitiş durumuna ulaşıp ulaşmadığını kontrol eden tekrar tutarlılığı.

Bunun hiçbiri özel bir harness gerektirmiyor, diyor. Koşuştan önce zorunlu bitiş durumunu belirtyecek birine ve koşuştan sonra kayıt sistemini okuyacak bir değerlendiriciye ihtiyaç var.

Yirmi koşuşun önemi

Tekrar tutarlılığı çerçevesi, Eduardo'nun ThinkingBox'ta özellikle öne çıkardığı kısım. Tek bir yeşil koşuş, bir ajanın doğru duruma ulaşabileceğini gösterir; üretim ortamı ise ulaşacak mı olduğunu bilmek ister. Aynı bilet bazı koşuşlarda çözüldü, bazılarında beklemede olarak bitiyorsa, sonuç küçük bir hata oranına sahip bir yetenek değil, ikna edici bir günlüğün arkasına gizlenmiş öngörülemeyen davranıştır. Tutarlılığın, geçme oranının yanında raporlanması gerektiğini, ek bir bölüme itilmemesi gerektiğini savunuyor.

Retrieval'daki aynı ayrım

Retrieval-öncelikli sistemler inşa eden Eduardo, RAG değerlendirmesiyle bir paralel kuruyor. Üretilmiş bir yanıt kaynakları düzgün alıntılayabilir ve yine de onlar hakkında yanlış olabilir; tıpkı bir ajanın düzgün günlük tutabilmesi ama yanlış kayıt bırakabilmesi gibi. Çare her iki durumda da aynıdır: üreticinin üretmediği bir şeye göre not verin. Retrieval için bu, altın kaynak kümesi anlamına gelir; ajanlar içinse terminal durumu anlamına gelir.

Neden önemli

Buradaki ayrıntılar birincil duyuru değil üçüncü taraf bir yazıdan geliyor, ancak bildirilen tasarım, ajanların nasıl ölçülebileceğine dair gerçek bir değişime işaret ediyor. Notu kendi bildirdiği başarıdan doğrulanmış sistem durumuna taşımak, bir ajanın iddia ettiği ile gerçekte yaptığı arasındaki boşluğu kapatıyor ve yanlış başarı başarısızlık modunu adlandırmak, sessiz bir üretim riskini ölçülebilir bir metriğe dönüştürüyor. Ekipler için pratik çıkarım öz: önce zorunlu bitiş durumunu tanımlayın, ajanın dokunamayacağı bir kayıt sisteminden not verin, "başarı iddia edildi ama yanlıştı" durumunu kendi kategorisi olarak sayın ve sonuca inanmadan önce görevi birden fazla kez çalıştırın.