Agent değerlendirme

Başarı oranı (success rate) en yaygın metriktir: agent görevi tamamladı mı, evet ya da hayır. Tek başına gerekli ama yetersizdir. Çünkü tek bir bit, aslında çok farklı iki çalışmayı aynı kefeye koyar: hedefe bir adım kala düşen bir çalışma ile daha ilk adımda dağılan bir çalışma, success rate gözünde ikisi de sıfırdır.

AgentBoard tam da bunu eleştirir ve ara durumu ölçen progress rate'i önerir. WebArena ise en iyi GPT-4 ajanının görevlerin yalnızca küçük bir kısmını bitirebildiğini gösterir; tek sayıya bakmak, neyin nerede kırıldığını saklar. Bu yüzden değerlendirmeyi katmanlara açmak gerekir.

Soldaki tek bitlik damga ile sağdaki çok metrikli karne aynı çalışmayı anlatıyor. Biri "oldu / olmadı" der, diğeri çalışmanın nerede durduğunu gösterir.

Görev başarısını ölçmenin doğru yolu, ajanın attığı adımların bir referans yola birebir uymasını beklemek değildir. WebArena bunu net koyar: önemli olan fonksiyonel doğruluk, yani işlem sonunda dünyanın (web state'inin, veritabanının) kullanıcının hedefini karşılayıp karşılamadığıdır. Aynı hedefe birden çok geçerli yoldan ulaşılabilir.

SWE-bench bunu en sert biçimde uygular: üretilen patch gerçek bir GitHub issue'sunu çözüyor mu? Cevap, patch'i uygulayıp deponun testlerini çalıştırarak verilir. fail-to-pass testleri geçmeli, eski testler bozulmamalı. Burada metrik metni değil, çalıştırmayı (execution) denetler.

Yani validator yolu değil sonucu doğrular. Aşağıda iki ajan farklı uzunlukta adımlarla aynı hedef state'e varıyor; doğrulayıcı ikisini de geçerli sayıyor, çünkü baktığı şey son durum.

Görev başarısı son durumu söyler ama yolculuğu söylemez. AgentBoard bu boşluğu progress rate ile doldurur: trajectory'nin hedefe en iyi eşleşen ara durumunu izler, görev bitince 1'e ulaşır. Böylece hedefe çok yaklaşıp düşen bir çalışma ile hiç başlayamayan bir çalışma ayrışır.

Bunu yapmak için yazarlar alt hedefleri (subgoal) elle tanımlar ve progress rate'i insan değerlendirmesiyle doğrular; raporladıkları Pearson korelasyonu görevler arasında 0.95'in üzerindedir. Bedeli de var: progress rate insan eliyle işaretlenmiş subgoal'lere bağımlıdır ve yazarlar mevcut LLM'lerin bu subgoal'leri kendiliğinden doğru üretemediğini söyler.

Aşağıda iki çalışma aynı subgoal hattında ilerliyor. İkisi de görevi bitiremiyor (success = 0), ama biri 0.9'a kadar gidiyor, diğeri 0.2'de kalıyor. Başarı oranı ikisini eşitler; progress rate ayırır.

Bir agent doğru cevabı verip yanlış yoldan geçebilir: yanlış tool'u seçmek, geçersiz argüman vermek, var olmayan bir API uydurmak. Tool correctness bunu ayrı bir katman olarak ölçer. ToolBench (ToolEval) 16.000'den fazla gerçek API üzerinde tool seçimini, argüman geçerliliğini, çalıştırmayı, hallucination oranını ve çözüm yolunun kalitesini değerlendirir.

tau-bench bir adım ileri gider: ajanı simüle bir kullanıcı, programatik API'ler ve domain policy dokümanlarıyla konuşturur, sonra son veritabanı durumunu beklenen hedefle karşılaştırır. Yani tool'un kulağa makul gelen bir cevabı değil, gerçekten doğru yan etkiyi üretip üretmediğini denetler. Model destekli evaluator (ToolEval gibi) ölçeklenir ama yan etki doğrudan kontrol edilebiliyorsa deterministik validator tercih edilir.

Aşağıda bir tool çağrısı dört kapıdan geçiyor: doğru tool seçildi mi, argümanlar geçerli mi, çalıştırma başarılı mı, yan etki doğru mu. Uydurma bir tool ilk kapıda eleniyor.

Üretimde bir agent'ın "bir denemede tutması" yetmez; her seferinde tutması gerekir. Klasik pass@k iyimser bir metriktir: k denemeden en az biri geçerse başarı sayılır. Kullanıcıya bakan bir sistemde bu yanıltıcıdır, çünkü bir şanslı koşu kötü deneyimi gizler.

tau-bench bunun yerine pass^k'yı öne çıkarır: k bağımsız denemenin hepsi geçmeli. Rapor edilen sonuç çarpıcı: function-calling GPT-4o, tau-retail'de pass^1 ~%61 iken pass^8'de ~%25'e düşer. Yani tutarlılık, tek seferlik başarıdan çok daha zordur.

Aşağıda sekiz bağımsız deneme sırayla sonuçlanıyor. pass@1 "en az biri geçti mi?" diye sorar ve yeşil yanar; pass^8 "hepsi geçti mi?" diye sorar ve tek bir başarısızlık bile onu kırmızıya çevirir.

Maliyet sadece token değildir. WebArena, her görev için Docker reset'i ve LLM inference süresini ihmal edilemez ama küçük bir değerlendirme maliyeti olarak sayar. Tekrar tabanlı metrikler (pass^k) deneme sayısını k katına çıkarır; bu da hem zaman hem para demektir.

METR daha farklı bir eksen önerir: %50 görev tamamlama zaman ufku, yani bir ajanın %50 olasılıkla tamamlayabildiği görevlerin insan-süresi karşılığı. o3 için bu ufuk yaklaşık 110 dakika; ve çalışılan dönemde görev ufku kabaca her 207 günde bir ikiye katlanıyor. Bu, başarıyı ham görev sayısına değil insan zamanına bağladığı için maliyet/efor değerlendirmesinde güçlü bir çerçeve.

Aşağıda bir değerlendirme bütçesinin bileşenleri üst üste biriyor: token, inference süresi, ortam reset'i ve tekrar denemeler.

Birçok agent benchmark'ı tek bir rahatsız edici gerçeği paylaşır: insan ile ajan arasındaki fark hâlâ büyük. WebArena'da insan başarısı %78 iken en iyi GPT-4 ajanı %14; GAIA'da insanlar %92, eklentili GPT-4 %15. METR de ajanları doğrudan insan-süresine göre konumlandırır. İnsan referansı, "iyi" kelimesini somutlaştırır.

Otomatik pass/fail bittiğinde iş bitmez. SWE-bench yazarları, çalıştırma testlerini geçen model patch'lerinin bile insan çözümlerinden daha az kapsamlı, verimli veya okunur olabileceğini söyler. Bakım, policy uyumu, güvenlik ve öznel kalite önemliyse human review hâlâ gerekir. Doğru kurgu, deterministik kontrol artı örnekleme yoluyla insan denetimini birlikte kullanmaktır.

Aşağıda iki benchmark'ta ajan ve insan başarısı yan yana; sağda otomatik kontrolden geçen çıktılar bir review kuyruğuna düşüyor.

Tek bir metrik bir agent'ı anlatamaz. Sağlam bir değerlendirme bir karne gibi katman katmandır: önce görev başarısı (fonksiyonel doğruluk), sonra adım kalitesi (progress rate), tool doğruluğu, tekrar güvenilirliği (pass^k), maliyet (zaman ve runtime) ve en üstte human review.

Bu katmanları birlikte okumak, "ajan iyi mi?" sorusunu "hangi katmanda, ne kadar, ne pahasına iyi?" sorusuna çevirir. İyi bir değerlendirme, modelin neyi başardığını değil, sistemin nerede güvenilir olduğunu söyler.

İyi agent, tek bir testi geçen değil; her katmanda ne kadar güvenilir olduğunu gösterebilen sistemdir.

Bu yüzden "bu agent iyi mi?" diye sormadan önce sorun: hangi katmanı, hangi benchmark'la, kaç tekrarla ve ne pahasına ölçüyorum?