Ajan İzlerini Okumak: Eval'in Veremeyeceği Kararı Verdirir

Bir mühendis, AI Engineer World's Fair için basit bir program oluşturucu ajan geliştirirken, ucuz açık ağırlıklı modellerin anonim kullanıcılara, daha güçlü modellerin ise kayıtlı kullanıcılara sunulduğu bir yönlendirme kurar. Ajana "ünlü konuşmacılar kimler" diye sorulduğunda, sistem yalnızca oturum başlıklarını döndüren getTracks aracını çağırır, ama yanıt olarak gerçek olmayan isimler (biri hiç var olmayan bir kişi) üretir ve sorgulandığında bu veriyi API'den aldığını iddia ederek uydurmayı ikiye katlar. Trace'te "Used Tools: getTracks" yazması, hatayı gerçekmiş gibi gösterir; sorunu ancak aracın gerçekte ne döndürdüğüne bakarak fark etmek mümkün olur.

Yazı, bu tür halüsinasyonların önceden yazılmış bir eval ile yakalanabileceğini ama böyle bir testi ilk etapta yazdıran şeyin, trace'leri okumaktan doğan sezgi olduğunu savunuyor. Kapsamlı doğrulama testleri yerine, ajanın tasarlandığı sınırlı niyet kümesini ve veride karşılığı olmayan durumları (örneğin boş bir konuşmacı tablosuna karşı sorular) hedefleyen, CI'da çalıştırılabilecek küçük ve LLM yargıçsız testler öneriliyor.

Ancak asıl vurgu, evalin veremeyeceği kararlarda: düşük puanlı ama ucuz bir modelin belirli bir kullanıcı kitlesi için "yeterince iyi" olup olmadığına karar vermek, mühendisin sorumluluğunda kalıyor. Yazar; ücretsiz katmanı daha iyi modele geçirmek, yönlendirmeyi düzeltmek, prompt'u sıkılaştırmak, groundedness testi yazmak veya durumu olduğu gibi kabul etmek gibi birbiriyle çelişen seçenekler arasından, trace'leri okuduktan sonra edindiği sezgiyle karar verdiğini anlatıyor.

Son olarak, Sentry üzerinden ajan girdi-çıktılarının ve araç sonuçlarının stabil bir conversation_id ile loglanması, hataları, performans verilerini ve trace'leri aynı yerde bulmayı kolaylaştırdığı için önemli bir pratik olarak öne çıkıyor; çünkü bir eval skoru tek başına, hatanın arkasındaki boş sorguyu veya yanlış yönlendirmeyi göstermiyor.