Puanlama boşluğu
Çoğu ajan benchmark'ı hâlâ çoktan seçmeli bir sınav gibi notlandırıyor: ajanı çalıştır, nihai yanıtını bir referansla karşılaştır, bir puan üret. Bu, çok adımlı bir yörüngenin tamamını tek bir bite indirger. İki ajan da 1.0 puan alabilir; biri temiz ve geri alınabilir bir işlem gerçekleştirirken diğeri bir üretim tablosunu silmiş, dört kez yeniden denemiş ve doğru yanıta tesadüfen ulaşmış olabilir. Benchmark farkı göremiyorsa, ajanı üreten ekip de göremez.
Bu teorik bir endişe değil. Ajan çerçeveleri giderek gerçek yan etkileri olan görevler için kullanılıyor: veritabanlarına yazma, ödeme API'lerini çağırma, altyapıyı değiştirme, mesaj gönderme. Bu ortamlarda yol, bir uygulama detayı değildir. Ürünün bir parçasıdır. Bunu görmezden gelen bir benchmark, yanlış şey için optimizasyon yapar.
Nihai yanıt puanlaması neden başarısız olur
Nihai yanıt puanlaması, yanıtın görevin kendisi olduğunu varsayar. Soru-cevap için bu kabaca doğrudur. Ajanik işler için değildir. İki veri kümesini uzlaştırması istenen bir araştırma ajanını düşünün. Bir yörünge her iki dosyayı okur, bir diff hesaplar ve bir özet yazar. Bir diğeri dosyaları okur, yanlış dizine bir ara dosya yazar, düzeltilmiş bir yolla yeniden dener, eski bir önbellek kopyasını okur ve sonunda aynı özeti üretir. Aynı çıktı. Farklı güvenilirlik, farklı maliyet, farklı etki alanı.
Üretimde önem taşıyan üç özellik, yalnızca çıktıya dayalı puanlama için görünmezdir:
- Maliyet. Token kullanımı, tool call'lar ve gerçek zamanlı gecikme. Bir görevi tek bir tool call ile çözen ajan ile dokuz tool call ile çözen ajan, yanıtlar eşleşse bile eşdeğer ürünler değildir.
- Yan etkiler. Dokunulan her harici sistem ve bunların hangi terminal durumda olduğu. Bunu kaydetmeyen bir benchmark, salt okunur bir ajanı, durumu değiştirip sonra temizleyen bir ajandan ayırt edemez.
- Yeniden üretilebilirlik. Aynı ajanın aynı görevde farklı seed'lerde aynı yörüngeyi üretip üretmediği. Tek bir başarılı çalıştırma bir ölçüm değil, bir anekdottur.
Neyin kaydedileceği
Değerlendirme birimi yanıt değil, yörünge olmalıdır. Bu, ajanın yapılandırılmış bir eylem izi yayması için enstrümante edilmesi anlamına gelir. En azından her adım şunları kaydetmelidir:
- Tool adı ve tam argümanları, yalnızca adı değil.
write_filebilgilendirici değildir;write_file(path="/etc/hosts", mode="append")bilgilendiricidir. - Tool tarafından döndürülen gözlem, hata yükleri dahil.
- Adım başına zaman damgaları ve token sayıları.
- Çalıştırmanın dokunduğu her harici sistemin terminal durumu: oluşturulan veya değiştirilen dosyalar, eklenen satırlar, gönderilen mesajlar, sağlanan kaynaklar.
Minimal bir iz şeması şöyle görünebilir:
{
"run_id": "...",
"task_id": "...",
"seed": 7,
"steps": [
{
"index": 0,
"tool": "read_file",
"args": {"path": "data/input.csv"},
"observation": {"status": "ok", "bytes": 4096},
"tokens_in": 812,
"tokens_out": 44
},
{
"index": 1,
"tool": "write_file",
"args": {"path": "out/summary.md", "mode": "create"},
"observation": {"status": "ok"},
"tokens_in": 921,
"tokens_out": 130
}
],
"terminal_state": {
"files_created": ["out/summary.md"],
"files_modified": [],
"external_calls": []
},
"retries": 0,
"backtracks": 0
}
Tam şema, disiplinin kendisinden daha az önemlidir: argümanlar, gözlemler ve terminal durum. Argümanlar olmadan niyeti denetleyemezsiniz. Terminal durum olmadan sonucu denetleyemezsiniz.
Yeniden deneme ve geri izleme sayıları, kırılganlık için kullanışlı bir vekildir. Doğru yanıta üç yeniden denemeden sonra ulaşan bir ajan, doğrudan ulaşandan daha kırılgandır ve dağılım kayması altında başarısız olma olasılığı çok daha yüksektir. Bu sayılar sonucun yanında raporlanmalı, içinde saklanmamalıdır.
Yörüngeleri puanlamak
Yörüngeler kaydedildiğinde, puanlama skaler yerine bir vektör haline gelir. Dört boyut çoğu üretim endişesini kapsar:
- Sonuç. Ajan görevin başarı koşulunu sağladı mı? Bu, tanıdık ikili veya dereceli puandır.
- Yol geçerliliği. Yörünge görevin kısıtlarına uydu mu? Kullanılan tool'lar uygun muydu, argümanlar iyi biçimlendirilmiş miydi, ara adımlar tutarlı mıydı?
- Yan etki hijyeni. İstenmeyen harici sistemler dokunulmadan bırakıldı mı? Amaçlanan değişiklikler tam olarak bir kez, idempotent biçimde, doğru sırada uygulandı mı?
- Maliyet. Token'lar, gecikme ve tool call'lar, bir referans yörüngeye veya bütçeye göre normalleştirilmiş.
Bir vektörü raporlamak, bir skaleri raporlamaktan daha bilgilendiricidir, ancak lider tablolarını karmaşıklaştırır. Dürüst bir ödünleşim: vektör puanlarını sıralamak daha zordur. Yan etkileri önemseyen bir ekip ile gecikmeyi önemseyen bir ekip, boyutları farklı şekilde ağırlıklandıracaktır. Benchmark, evrensel olduğunu iddia eden tek bir ağırlıklandırmayı sabitlemek yerine bileşenleri açığa çıkarmalı ve tüketicilerin bunları birleştirmesine izin vermelidir.
İkinci bir ödünleşim: yörünge puanlaması enstrümante edilmiş ortamlar gerektirir. Rastgele harici sistemler için terminal durumu, onları sandbox'a almadan veya adaptörler oluşturmadan kaydedemezsiniz. Bu gerçek bir mühendislik maliyetidir ve birçok benchmark'ın bundan kaçınmasının nedeni budur.
Ayrılmış ortamlar ve varyans
Yörünge puanlaması yalnızca ajan fixture'ı ezberleyemiyorsa işe yarar. Ayrılmış ortamlar bunun mekanizmasıdır. Benchmark, ajanın hiç görmediği görev örneklerini üretmeli veya ayırmalıdır; ideal olarak rastgeleleştirilmiş parametrelerle: dosya adları, dizin düzenleri, API yanıtları ve başlangıç durumları. Ajan fixture'ı eğitim veya ayarlama sırasında gördüyse, yüksek bir puan yeteneği değil, hatırlamayı ölçer.
Varyans raporlaması da aynı derecede önemlidir. Tek bir çalıştırma bir ölçüm değildir. Ajanlar stokastik sistemlerdir: örnekleme sıcaklığı, tool call sıralaması ve ortam zamanlaması varyans getirir. Benchmark her görevi birden fazla seed üzerinde çalıştırmalı ve yalnızca ortalamayı değil, puanların dağılımını raporlamalıdır. Uzun bir başarısızlık kuyruğuyla yüksek bir ortalama, dar varyansla biraz daha düşük bir ortalamadan farklı bir üründür.
Benchmark ekosistemi bu yönde olgunlaşıyor. Vals'in AI benchmark'ı çalışması gibi yeni değerlendirme çabalarının kapsamı, ajanları değerlendirmenin modelleri değerlendirmekle aynı şey olmadığına dair daha geniş bir farkındalığı yansıtıyor. Yalnızca çıktıya dayalı lider tabloları, süreç farkındalıklı değerlendirmeyle tamamlanıyor ve bu haklı bir nedenle böyle.
Somut bir mekanizma: sandbox'lı replay harness
Yörünge puanlamasını uygulamanın pratik bir yolu sandbox'lı bir replay harness'tir. Harness her çalıştırma için taze bir ortam sağlar: bir dosya sistemi, bir mock API sunucusu ve giden çağrıları engelleyen veya kaydeden bir ağ politikası içeren bir konteyner. Ajan bunun içinde çalışır. Tamamlandığında harness ortamın anlık görüntüsünü alır, başlangıç durumuyla karşılaştırır ve hem eylem izini hem de terminal durum diff'ini yayar.
Ortam geçici olduğu için yan etkiler gözlemlenebilir ve sınırlandırılmıştır. API sunucusu mock olduğu için yanıtlar seed başına rastgeleleştirilebilir. Ağ politikası açık olduğu için istenmeyen harici çağrılar sessizce izin verilmek yerine kaydedilir. Harness daha sonra çalıştırmayı yukarıda açıklanan vektör üzerinden puanlar.
Bu, bir ajanı statik bir yanıt anahtarına karşı çalıştırmaktan daha fazla iştir. Aynı zamanda ajan güvenilirliği hakkında üretimle temas ettikten sonra ayakta kalan iddialarda bulunmak için gereken asgari düzeydir.
Neyin raporlanacağı
Yörünge farkındalıklı bir benchmark raporu, görev başına şunları içermelidir:
- Başarı koşulu açıkça belirtilmiş sonuç puanı.
- Belirli ihlallerin sıralandığı yol geçerliliği işaretleri.
- Oluşturulan, değiştirilen ve silinen kaynakların sayıları olarak özetlenen yan etki diff'i.
- Token'lar ve tool call'lar bazında ayrıştırılmış maliyet.
- Yeniden deneme ve geri izleme sayıları.
- Seed'ler arası varyans, tek bir sayı yerine bir dağılım olarak raporlanmış.
Görevler genelinde birleştirildiğinde bu, bir sıralama yerine bir profil verir. Profilleri pazarlamak daha zordur. Aynı zamanda bir ajanın dağıtım için güvenli olup olmadığına karar vermek için daha kullanışlıdır.
Sonuç
Yalnızca nihai çıktıları puanlayan benchmark'lar, doğru yanıtlara güvenli olmayan veya yeniden üretilemeyen yollardan ulaşan ajanları sistematik olarak ödüllendirir. Çözüm daha iyi bir yanıt anahtarı değildir. Farklı bir analiz birimidir: argümanlar, gözlemler, terminal durum ve maliyetle birlikte yörünge. Bir vektör üzerinden puanlayın. Ayrılmış ortamlar kullanın. Varyansı raporlayın. Tek bir çalıştırmayı anekdot olarak değerlendirin.
Ödünleşim gerçektir: yörünge puanlamasını inşa etmek daha pahalıdır ve özetlemek daha zordur. Ancak alternatif, dikkatli bir ajanı şanslı olandan ayırt edemeyen bir lider tablosu ve yanlış sinyal üzerinden verilen bir dağıtım kararıdır.