30  Ajanları Değerlendirmek

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 30. bölüm. Küçük bir ölçüm: aynı otuz çalıştırma iki şekilde puanlandı, üretmesi dakikalar sürdü. Bölüm 22 bir değerlendirme kümesinin nasıl boyutlandırılacağını ve bir hakemin nasıl denetleneceğini ortaya koydu; bu bölüm ajanların eklediği şeyle ilgili: bir cevabın artık arkasında bir yol var ve cevap doğruyken yol yanlış olabilir. Yazılım: ollama 0.24.0 üzerinden qwen3.5:9b, NumPy 2.5.2, Python 3.14.5.

Öğrenme hedefleri. Bu bölümün sonunda:

30.1 Bir cevabın artık arkasında bir yol var

Bölüm 22’deki her şey hâlâ geçerli: kümeyi saptamanız gereken farka göre boyutlandırın, inanmadan önce hakemi denetleyin, aralıkları raporlayın. Ajanlar tek bir şey ekliyor ve o da “doğru”nun ne anlama geldiğini değiştiriyor.

Bir sınıflandırıcı bir cevap üretir. Bir ajan bir cevap ve bir trajectory üretir — oraya götüren kararlar, araç çağrıları, gözlemler ve yeniden denemeler dizisi.

trajectory — bir ajanı cevabına götüren kararlar, araç çağrıları, gözlemler ve yeniden denemeler dizisi. İki çalıştırma aynı cevaba farklı trajectory’lerle varabilir. Yörünge diye çevrilmez. ↩︎

İki çalıştırma aynı cevabı verip oraya varmak için yaptıklarında tümüyle ayrışabilir; bir doğruluk sayısı ise yalnızca cevaba bakar, yoldaki farkı hiç görmez.

İki değerlendirme, hiçbiri yeterli değil
ne sorar neyi kaçırır
Sonuç değerlendirmesi doğru cevabı üretti mi? neye mal olduğunu, kaç yanlış dönüş yaptığını, oraya şansla varıp varmadığını, yolda yıkıcı bir şey yapıp yapmadığını
Trajectory değerlendirmesi oraya makul biçimde vardı mı? cevabın gerçekten doğru olup olmadığını — yanlış bir cevaba giden verimli bir yol iyi puan alır

Varsayılan yaklaşım yalnızca sonucu değerlendirmektir ve bu, pahalı saçmalıkları gizler. On beş gereksiz araç çağrısından sonra doğru cevaplayan bir ajan, iki çağrıda doğru cevaplayanla aynı puanı alır — fatura gelene ya da o gereksiz çağrılardan biri bir şey yazana kadar.

Neye bakacağız. Önce neredeyse her ajan değerlendirmesini kapsayan altı sayı (bunların ikisi sıklıkla atlanıyor ve ikisi de belirli bir sorunu gizliyor) ve aynı görevin tekrarlı çalıştırmalarını özetlemenin iki yolu. Sonra aynı otuz çalıştırmayı iki şekilde puanlayıp ikinci eksenin gerçekte ne kazandırdığını netleştireceğiz. Trajectory değerlendirmesi için genellikle öne sürülen gerekçe, doğru cevaba kötü bir yoldan varan çalıştırmaları yakalamasıdır; ölçüm ise farklı ve daha sağlam bir neden gösteriyor. Ardından hiçbir kesin metriğin ulaşamadığı kısım gelecek: Bölüm 22’nin hakeminin ek bir uyarıyla geri döndüğü yer. Sonra senaryo testleri; test ortamını fixture (testin önceden hazırlanmış verisi ve başlangıç durumu) olarak düzgün kurduğunuzda bunlar sıradan birim testleridir. Sonra herkese açık benchmark’lar (kıyaslama) ve sıralama tablosundaki (leaderboard) bir konumun neyin kanıtı olduğu. Son olarak da üretimde ortaya çıkan her hatayı kalıcı bir teste dönüştüren döngü.

30.2 Metrik kümesi

Yol da sayılarla ölçülmeli ve bunun için çok sayıda metrik gerekmiyor. Altı tanesi neredeyse her ajan değerlendirmesini kapsıyor. Her birini açıkça tanımlamak gerekiyor, çünkü “araç doğruluğu” dört kişi için dört farklı şey demek.

Altı metrik
metrik tanım neyi yakalar
Sonuç doğruluğu nihai cevap doğru gerçekten istediğiniz şey
Tool-call precision (araç çağrısı kesinliği) yapılan çağrılar içinde gerekli olanların oranı gereksiz iş, tekrarlanan sorgular, hiçbir yere varmayan keşif
Tool-call recall (araç çağrısı duyarlılığı) gerekli çağrılar içinde yapılmış olanların oranı kontrol etmeden cevaplayan ajan — çoğunlukla, ama her zaman değil, parametrik bellekten
Adım sayısı araç çağrıları ve model çağrıları, ayrı sayılmış Bölüm 23’ün bulgusu: bunlar farklı sayılardır ve faturanızı öngören model çağrısı sayısıdır, çünkü her model çağrısı bütün transkripti yeniden gönderir
Sonlanma oranı adım bütçesinin (step cap) sınırına çarpmak yerine kendiliğinden duranların oranı yalnızca sonuç raporunda başarı gibi görünen kusur biçimi
Doğru cevap başına maliyet istek başına ortalama token ÷ 0–1 oran olarak doğruluk (iki sistem farklı modeller ya da fiyatlar kullanıyorsa token yerine para cinsinden) iki sistemi adil karşılaştıran tek maliyet sayısı

Tool-call precision ile recall’un bir anlam taşıması için önce bir şeyin tanımlanması gerekiyor: hangi çağrılar gerekliydi. Tek bir referans yol kolay sürümdür ve genellikle yanlış olanıdır — iki araç birbirinin yerine geçebilir, önbelleklenmiş bir sonuç ikinci çalıştırmada bir çağrıyı gereksiz kılabilir ve bir miktar keşif meşrudur. Tek bir trajectory yerine kabul edilebilir bir trajectory kümesi yazın ya da bir çalıştırmayı yaptığı çağrılara göre değil, ortaya koyması gereken olgulara göre puanlayın. Örneğin A ve B projelerinin bütçelerini toplayan bir görevde gerekli olgular “A’nın bütçesi” ve “B’nin bütçesi”dir: search("A") ile search("B") herhangi bir sırayla kabul edilir, önbellekten okuyan bir get_cached("A") da search("A")’nın yerine sayılır. Recall, her gerekli olgunun kabul edilen en az bir çağrıyla karşılanan payıdır. Precision’da ise hiçbir gerekli olguyu karşılamayan ya da zaten karşılanmış bir olguyu yeniden isteyen çağrılar gereksiz sayılır.

Genellikle atlanan iki metrik recall ve sonlanma oranıdır; ikisi de belirli felaketleri gizler. Düşük tool-call recall genellikle ajanın gerekli kaynağa başvurmak yerine bellekten cevapladığı anlamına gelir. Tek olası sebep bu değil ama en yaygını. Bölüm 24, opak şemalı bir aracın vakaların %41,7’sinde hiç çağrılmadığını ve modelin bunun yerine kendinden emin, uydurma bir metin ürettiğini ölçtü. Düşük bir sonlanma oranı, çalıştırmaların bütçe tükendiği için sona erdiği anlamına gelir; sonuç metriği ise o ana kadar tesadüfen doğru cevaba ulaşmış olanları başarı sayar.

30.2.1 Bir çalıştırma bir örneklemdir: pass@k ve pass^k

Bir ajan çalıştırması bir olgu değil, bir örneklemdir. Sıfırın üzerindeki her sıcaklıkta, çoğu zaman sıfırda bile, aynı görev bir çalıştırmada geçip ötekinde kalabilir. Sıfır sıcaklıktaki oynama bir hata değildir: sunucu istekleri batch (yığın) hâlinde işler ve batch’in bileşimi, kayan nokta toplamalarının sırasını ve dolayısıyla en olası token’ı değiştirebilir. Bu yüzden anlamlı birim “ajan 17. görevi çözdü” değil, “17. görevi \(n\) çalıştırmanın \(c\)’sinde çözdü”dür. Bu tekrarlı çalıştırmaların iki özeti birbirine zıt iki soruyu cevaplar:

  • pass@k — \(k\) denemeden en az birinin başarılı olma olasılığı. Her denemeyi bir şey denetliyor ve işe yarayanı saklıyorsanız doğru sayı budur; üretilen kodu bir test süitinin denetlemesi gibi.
  • pass^k — \(k\) denemenin hepsinin başarılı olma olasılığı. Yayındaki bir ajan için doğru sayı budur: her kullanıcı tek bir deneme alır ve aynı türden istek tekrar tekrar gelir.

Bir görev her çalıştırmada birbirinden bağımsız olarak \(p\) olasılıkla başarılı oluyorsa pass@k \(= 1-(1-p)^k\) ve pass^k \(= p^k\) olur. \(p = 0{,}8\) ve \(k = 4\) için bu, %99,8’e karşı %41 demek. Aynı ajan, yalnızca hangi soruyu sorduğunuza bağlı olarak ya “neredeyse her zaman oraya varıyor” ya da “dört denemenin dördünü birden yarıdan az sıklıkla doğru yapıyor”. Bir görevin \(c\)’si başarılı olan \(n \ge k\) çalıştırmasından elde edilen yansız kestirimler şunlardır (birincisi Chen vd., 2021’den, ikincisi τ-bench’ten):

\[ \text{pass@}k = 1 - \binom{n-c}{k}\Big/\binom{n}{k}, \qquad \text{pass}^k = \binom{c}{k}\Big/\binom{n}{k} \]

Küçük bir örnek: beş çalıştırmanın dördü başarılıysa (\(n = 5\), \(c = 4\)) ve \(k = 2\) ise, yalnızca bir çalıştırma başarısız olduğundan ikisi de başarısız iki deneme seçilemez ve pass@2 \(= 1 - 0/10 = 1\) olur; buna karşılık pass^2 \(= \binom{4}{2}/\binom{5}{2} = 6/10\)’dur.

Bunlar önce görev başına hesaplanır, sonra görevler üzerinden ortalaması alınır. Sıra önemlidir. \(p = 1\) ve \(p = 0{,}6\) olan iki görevin ortalaması \(p = 0{,}8\)’dir ve \(0{,}8^4\) %41 eder; oysa gerçek pass^4 \((1 + 0{,}6^4)/2\), yani %56’dır. \(k = 1\) için iki özet de sıradan doğruluğa indirgenir. Bölüm 23, pass^k’yı ortaya koyan benchmark’ı aktarmıştı: τ-bench’te 2024’te sınanan en iyi ajan görevlerin yarısından azında başarılı oldu ve perakende alanında pass^8 değeri %25’in altındaydı (Yao vd. 2024).

Aşağıdaki ölçüm her görevi bir kez çalıştırdı; yani yalnızca pass^1’i raporluyor ve tutarlılık hakkında hiçbir şey söylemiyor. Bu, ölçümün en büyük sınırlılığı; ona ilk eklenmesi gereken şey, her görevi beş ya da daha fazla kez çalıştırmak.

30.2.2 Aynı çalıştırmaları iki şekilde puanlamak

Peki ikinci eksen gerçekte ne katıyor? Test kümesi, her biri iki arama ve bir toplama gerektiren otuz görevden oluşuyor; veriler, hiçbir şey tahminle bilinemesin diye uydurulmuş. Sonuç, toplam doğruysa geçer. Trajectory ise ajan tam olarak gereken iki çağrıyı yaptıysa — tekrar yok, yanlış hedef yok — ve kendiliğinden durduysa geçer. İki sistem, Bölüm 23’teki iki döngüdür: sağlayıcının araç çağırma API’sini kullanan yerleşik döngü ve modelin araç çağrılarını bizim kodumuzun ayrıştırdığı düz metin olarak yazdığı, elle yazılmış bir metin protokolü. Bu, kendi görevleriyle ayrı bir çalıştırma; dolayısıyla sayıları o bölümün iki aramalı satırıyla örtüşmez.

Çıktıyı okurken: native loop yerleşik döngü, text protocol metin protokolüdür; outcome pass sonuçta, trajectory pass trajectory’de geçen çalıştırmaların oranıdır. Girintili dört satır bu ikisinin 2×2 dökümüdür: ikisinde de geçen (both pass), yalnızca sonuçta geçen (outcome only), yalnızca trajectory’de geçen (trajectory only) ve hiçbirinde geçemeyen (neither). Alttaki satırlar görev başına araç çağrısı (ideali 2), bunların tekrar olanları (of which repeats), adım bütçesine çarpan çalıştırmaların oranı (hit the step cap) ve istek başına ortalama token’dır (1,557 = 1.557).

qwen3.5:9b, 30 tasks, 2 lookups needed

                        native loop    text protocol
 outcome pass                100.0%            36.7%
 trajectory pass             100.0%            33.3%

   both pass                 100.0%            33.3%
   outcome only                0.0%             3.3%
   trajectory only             0.0%             0.0%
   neither                     0.0%            63.3%

 tool calls (ideal 2)           2.00             7.10
   of which repeats             0.00             5.00
 hit the step cap               0.0%            63.3%
 tokens                          829            1,557

Söylenecek ilk şey bu ölçümün çözemediği şey. Genellikle tartışılan uyuşmazlık — sonuçta geçip trajectory’de kalan bir çalıştırma — bir kez oldu. Ama o olayın paydası otuz değil: sonuçta kalan bir çalıştırma onu zaten sergileyemez. Metin protokolünün sayılarını 2×2 tablo olarak yazınca bu görünür hâle geliyor:

Otuz çalıştırmanın iki puanlaması; uyuşmazlığın paydası ilk satırdır
metin protokolü trajectory geçti trajectory kaldı toplam
sonuç geçti 10 1 11
sonuç kaldı 0 19 19
toplam 10 20 30

Sonuçta geçen on bir çalıştırmanın biri trajectory’de kaldı: 1/11 = %9,1, Wilson aralığı [1,6; 37,7]. Bu, iki yönde de bir iddiayı desteklemeyecek kadar geniş. Gerçek oran üst sınıra, %38’e yakın olsaydı trajectory değerlendirmesini tek başına bu neden bile haklı çıkarırdı; %2’ye yakın olsaydı çıkarmazdı.

Ve daha derin sorun şu: yerleşik döngü bu kestirime az şey katıyor. İki eksende de 30/30 geçti, yani o kolda bir uyuşmazlık gözlenmedi. Bu yine de kendi belirsizliği olan bir ölçüm: 0/30, yaklaşık %11’e kadar bir gerçek uyuşmazlık oranıyla bağdaşır (Wilson üst sınırı). Asıl tartışmanın konusu olan rejim — çoğunlukla doğru olan ama bazen oraya kötü varan bir sistem — burada hiç ölçülmüyor. Bu tablonun çözdüğü şey farklı, o sayıya bağlı değil ve daha değerli:

Sistemin ne yaptığını söyler. Metin protokolü 2 gerektiren bir görev için 7,10 araç çağrısı yaptı ve 5,00’i tekrardı — bütün araç çağrılarının %70’i kendisine zaten söylenmiş bir şeyi istedi. Sonuç sayısı (%36,7) bunların hiçbirini yansıtmıyor. Bu sistemi, zamanın üçte birinde çalıştığını bilerek ama çabasının çoğunu aynı soruyu yeniden sormaya harcadığını bilmeden yayına alırdınız.

Çalıştırmaların neden bozulduğunu söyler. %63,3’lük bir sınıra çarpma oranı, bunların yanlış cevaplar değil bitmemiş çalıştırmalar olduğunu söylüyor. Bu, Bölüm 23’ün sonlanma problemidir ve onarımı bir akıl yürütme probleminin onarımından tümüyle farklıdır. Tek başına doğruluk, “yanlış cevapladı” ile “hiç durmadı”yı ayırt edemez. Tekrarların mekanizması da o bölümün transkriptlerinde görülüyor: model aradığı sonucu alıyor, ama metin protokolünde cevap vermek de ARA(...) ile aynı alanda yarışan bir dizgiden (CEVAP(...)) ibaret ve transkript ARA satırlarıyla doldukça en olası sonraki satır yine bir ARA oluyor. Yani buradaki tekrarlar da büyük olasılıkla modelin sonucu görmemesinden değil, protokolün durma kararını ifade ediş biçiminden kaynaklanıyor.

Bu okumanın tablonun geri kalanı için bir sonucu var. Üç çalıştırmadan ikisinin bütçesi bittiyse, %36,7 bu protokolün bu adım bütçesinde verdiği şeydir — yapılandırıldığı hâliyle sistemin gerçek bir ölçümü, ama kısmen de bütçe hakkında bir olgu. Bu yüzden böyle bir sayının yanında bütçe değeri her zaman raporlanmalı. Daha büyük bir bütçedeki başarım ölçülmedi ve daha yüksek olacağı garanti değil: ek adımlar yanlış cevap, tekrar ya da yeni hatalar da üretebilir.

Bunu netleştirecek deney bir duyarlılık analizi (tek bir ayarı değiştirip sonucun nasıl tepki verdiğini ölçmek) ve tek satırlık bir yapılandırma değişikliği: bütçeyi iki katına çıkarıp yeniden koşun. Ya doğruluk yükselir; o zaman metin protokolü yeteneksiz değil, yavaştır. Ya da yükselmez; o zaman protokol, fazladan bütçenin yalnızca beslediği bir döngüde sıkışmıştır. Bu daha ilginç ve daha ağır bir sonuç olur. O deney henüz yapılmadı. Yapılana kadar aşağıdaki 5,1 kat da aynı belirsizliği devralıyor, çünkü bütçe bir çalıştırmanın harcayabileceği token’ı (pay) sınırlıyor ve doğruluğu (payda) etkiliyor.

Maliyet karşılaştırmasını değiştirir. Ham token’da metin protokolü 1,9 kat daha pahalı görünüyor. Doğru cevap başına ise 5,1 kat — 829’a karşı 4.246 token. Sonucu yok sayan maliyet metriği gerçek farkı yaklaşık üç kat küçümsüyor. Bir karşılaştırmaya konacak tek maliyet sayısının doğru cevap başına token olmasının nedeni de bu.

Küçük ölçüm: otuz görev, tek model, görev başına tek çalıştırma. Wilson %95 aralıkları — çünkü 0’a ya da 1’e yakın bir oran onları gerektirir ve Bölüm 22.5 bunu söylüyor: sonuç %100 → [88,6; 100]; sonuç %36,7 → [21,9; 54,5]; sınıra çarpma %63,3 → [45,5; 78,1]; “yalnızca sonuçta geçti” türündeki tek uyuşmazlık → otuz çalıştırmada [0,6; 16,7], olabileceği on birde [1,6; 37,7]. Tablonun sağlam biçimde ortaya koyduğu şey, sonuç metriğinin gizlediği israfın büyüklüğü — 2’ye karşı 7,10 çağrı ve %70’i tekrar — ve maliyet düzeltmesinin yönüdür. Sonuç farkının kendisi şüpheli değil: iki sistem aynı otuz görevi koştu, dolayısıyla karşılaştırma eşleştirilmiş ve hepsi tek yönde olan 19 uyumsuz çift üzerinde McNemar’ın kesin (exact) testi p = 4 × 10⁻⁶ veriyor.

Sonuç sayısı israfı gizliyor ve maliyeti küçümsüyor
GÖREV BAŞINA ARAÇ ÇAĞRISI YERLEŞİK DÖNGÜ 2,00 METİN PROTOKOLÜ 7,10 0 İDEAL: 2 4 6 8 TEKRAR OLMAYAN ÇAĞRILAR TEKRARLAR — YAPTIĞI ÇAĞRILARIN %70'İ İSTEK BAŞINA TOKEN — ÇOĞU KARŞILAŞTIRMANIN ALINTILADIĞI RAKAM YERLEŞİK DÖNGÜ 829 METİN PROTOKOLÜ 1.557 — 1,9× DOĞRU CEVAP BAŞINA TOKEN — TEK ADİL KARŞILAŞTIRMA YERLEŞİK DÖNGÜ 829 METİN PROTOKOLÜ 4.246 — 5,1× 0 1.000 2.000 3.000 4.000 SONUCU YOK SAYAN MALİYET RAKAMI FARKI YAKLAŞIK ÜÇ KAT KÜÇÜMSÜYOR ham token'da 1,9×, doğru cevapların oranına böldüğünüzde 5,1×

Alt paneldeki iki metin protokolü çubuğu aynı sistemi iki ayrı ölçüyle gösteriyor. Ham token’a göre 1,9 kat daha pahalı görünüyor; doğru cevap başına token’a göre — aynı pay, doğru olanların oranına bölünmüş — 5,1 kat. İki rakam da bir doğruluk raporunda görünmez; üst panel farkın nereye gittiğini gösteriyor: yaptığı her yedi çağrının beşi, kendisine zaten söylenmiş bir şeyi istedi.

30.3 Bir trajectory’yi yargılamak

Bazı trajectory sorularının kesin cevapları var — çağrı sayıları, tekrarlar, sonlanma. Bazılarının yok: bu denenmeye değer makul bir şey miydi? Bunlar için ölçüm aleti Bölüm 22’nin hakemidir: o bölümdeki bütün uyarılar burada da geçerli, üstüne trajectory’lere özgü bir uyarı daha ekleniyor.

Bölüm 22, iki aday yer değiştirdiğinde hükmünü maddelerin %38’inde çeviren bir hakem ölçtü. Bir trajectory çok adımlı bir dizidir; dolayısıyla konum etkilerinin devreye girebileceği muhtemelen daha çok yer vardır — örneğin ilk adımlar son adımlardan daha ağır basabilir — ama bu burada ölçülmedi. Herhangi bir rubrik puanına güvenmeden önce:

  • Birebir aynı trajectory kontrolünü çalıştırın. Bir trajectory’yi kendisine karşı puanlayın. Bu bir sağlama kontrolüdür (sanity check): Bölüm 22’deki iki hakem de bunu geçti ve sonra önemli olan probe’larda keskin biçimde ayrıştı; dolayısıyla bunu geçmek yalnızca aletin bozuk olmadığını ortaya koyar.
  • İki trajectory’yi karşılaştırırken iki sırayı da çalıştırın. Hakem önce A’yı, sonra B’yi gördüyse ona önce B’yi, sonra A’yı da gösterin ve yalnızca birbiriyle uyuşan hükümleri tutun. Bu, Bölüm 22’nin konum probe’udur ve %38’lik çevirme oranını yakalayan da oydu.
  • Ölçütleri bütünsel değil ayrı puanlayın. Doğru araçları çağırdı mı, gereksiz işten kaçındı mı, hatalardan toparlandı mı. Bunlar, nedeni belirsiz biçimde oynayan 1–5 arası tek bir puanın aksine, harekete geçebileceğiniz üç ayrı puandır.
  • Kesin metriklerin yapabileceği işi onlara bırakın. Bir hakemden araç çağrılarını saymasını istemeyin. Onları sayın.

Hakemin asıl işi, sayılamayan geri kalan kısımdır: israf gibi görünen keşifsel bir yolun gerçekten makul bir hipotez olup olmadığı ve bir toparlanmanın bilinçli mi yoksa şans eseri mi olduğu.

30.4 Senaryo testleri ve benzetimli kullanıcılar

Metrikler size bir sistemin elinizdeki çalıştırmalarda ne kadar başarılı olduğunu söyler. Senaryolar ise çalıştırmaları, kullanıcılarınız onları sizin yerinize üretmeden önce elde etmenin yoludur.

Bir ajan için birim test bir senaryodur: sabit bir ortam, sabit bir istek ve ne olması gerektiğine dair bir assertion (test koşulu). Zor kısım ortamdır ve onu düzgün kurmak gerekir, çünkü diğer her şey ona bağlıdır.

  • Yalnızca prompt’u (istem) değil, bütün dünyayı fixture’larla sabitleyin. Bir senaryo bilinen bir durumda bir veritabanı, belirlenimci araç yanıtları ve sabitlenmiş bir saat ister; böylece “bugün” her çalıştırmada aynı tarih olur. Aksi hâlde testin dün geçip bugün kalması, ajanınızla ilgisi olmayan nedenlerden kaynaklanabilir.
  • Gerçek izleri kaydedin ve tekrar oynatın. Üretimdeki araç yanıtlarını yakalayın ve tekrar oynatın. Bu, bir olaydan bir regresyon testi çıkarır ve elinize geçecek en ucuz gerçekçi senaryo kaynağıdır.
  • Çok turlu iş için kullanıcıyı benzetin. Kullanıcıyı oynayan ikinci bir model çok turlu değerlendirmeyi mümkün kılar — ve yukarıdaki her hakem uyarısını devralır, çünkü benzetimli bir kullanıcı rubrikli bir modeldir. Onun prompt’u en az dört şeyi sabitler: bir kişilik (sabırsız, teknik bilgisi az), bir hedef (siparişi iptal ettirmek), bir bilgi kısıtı (sipariş numarasını yalnızca sorulursa verir) ve bir bitirme koşulu (hedefe ulaşınca ya da belirli bir tur sayısından sonra ###STOP### yazar; τ-bench’in benzetimli kullanıcısı da konuşmayı böyle bir işaretle bitirir). Benzetimli kullanıcının gerçek kullanıcı dağılımını temsil etmeyebileceğini de unutmayın: genellikle gerçek kullanıcılardan daha işbirlikçi, daha tutarlı ve daha düzgün yazar. Kişilikleri ve istekleri gerçek trafikten türetin ve benzetimli konuşmaların bir örneğini gerçek transkriptlerle yan yana okuyun.
  • Assertion’ları yalnızca yanıta değil trajectory’ye de yazın. place_order’dan önce check_inventory çağırmalı, gerçek bir regresyonu yakalayan türde bir assertion’dır ve yalnızca sonuca bakan bir test bunu ifade edemez.
  • Yalnızca metni değil, dünyanın son durumunu da kontrol edin. Eylemde bulunan bir ajan için sonuç, değişen şeydir: sipariş satırı, iade, rezervasyon. τ-bench bir çalıştırmayı, konuşmanın sonundaki veritabanını etiketlenmiş bir hedef durumla karşılaştırarak puanlar (Yao vd. 2024). Değişmemesi gerekenler için de assertion yazın — yolda yanlış rezervasyonu iptal eden doğru bir yanıt, bir başarısızlıktır.

30.5 Benchmark’lar ve sıralama tablosunun söyledikleri

Çoğu insan bir modelin ajan işlerinde iyi olduğunu ilk kez herkese açık benchmark’lardan duyar. Aşağıdaki altısının her biri gerçek bir şeyi ölçüyor ve her biri onu sizin ürününüz olmayan bir yerde ölçüyor.

Altı benchmark
benchmark ne ölçer neyi ölçmez
τ-bench perakende ve havayolu alanlarında araç-ajan-kullanıcı etkileşimi; kural izleme ve benzetimli bir kullanıcıyla; başarı son veritabanı durumudur, güvenilirlik pass^k ile ölçülür sizin alanınızı, araçlarınızı, kurallarınızı
SWE-bench gerçek GitHub sorunlarını çözme, deponun kendi testleriyle doğrulanmış depolarının dışındaki işi (özgün küme on iki Python projesidir) ve o testlerin denetlemediği her davranışı
GAIA web ve dosya araçlarıyla çok adımlı akıl yürütme; insanlar için kolay, modeller için zor sorularda yeteneğin sizin görevinize aktarılıp aktarılmadığını
WebArena yerelde barındırılan (self-hosted) gerçekçi web sitelerini uçtan uca kullanan ajanlar API tabanlı işi ve süitte olmayan her siteyi
BFCL pek çok şema genelinde işlev çağırma doğruluğu; paralel ve çok adımlı çağrılar dâhil modelin sizin araçlarınızı iyi kullanıp kullanmadığını — Bölüm 24 şemanın buna ne kadar karar verdiğini ölçtü
AgentDojo ajan ortamlarında prompt enjeksiyon saldırılarına gürbüzlük; aynı görevlerde saldırılı ve saldırısız yararlılıkla birlikte raporlanır birkaç benzetimli ortamının (e-posta, bankacılık, seyahat, mesajlaşma) dışındaki yeteneği

Bunları bilmek gerekir, ama Bölüm 22’de anlatılan nedenlerle sisteminiz hakkında zayıf kanıttırlar: kontrol edemeyeceğiniz bulaşma, tablonun tepesinde doyum ve yapı uyumsuzluğu — bir benchmark bir görevi ölçer, sizdeyse bir sistem var. Sonuç denetimleri bile sızıntıya açık olabilir: bir ajanın başarılı sayılan SWE-bench yamalarını inceleyen 2024 tarihli bir denetim, bunların yaklaşık üçte birinde çözümün sorun kaydında ya da yorumlarında zaten yazılı olduğunu, yaklaşık üçte birinin de yalnızca testler yanlış bir yamayı yakalayamayacak kadar zayıf olduğu için geçtiğini buldu (SWE-Bench+). Benchmark’ları aday modelleri ikiye üçe indirmek için kullanın. Aralarında kendi süitinizle karar verin.

30.6 Olaydan regresyon testine

Değerlendirme işinin en değerli kısmı metrik tasarlamak değil; üretimde ortaya çıkan her hatayı kalıcı bir teste dönüştüren döngüdür. Bu da çoğunlukla bir lojistik işidir:

  1. bir hata bildirilir                 iz kimliğiyle birlikte
  2. tam trajectory'yi çekin             her çağrı, argüman, sonuç ve karar
  3. bir senaryoya indirgeyin            araç yanıtlarını sabitleyin, isteği koruyun
  4. olması gerekeni assert edin         sonuç VE trajectory
  5. başarısız olduğunu teyit edin       ilk gün geçen bir test, hatayı
                                         yakalayabildiğini henüz göstermemiştir
  6. düzeltin ve testi kalıcı olarak saklayın

Beşinci adım, insanların atladığı ve geri kalanına anlam kazandıran adımdır. Teste güvenmeden önce hatalı davranışta başarısız olduğunu gösterin: hatalı sürüme karşı koşturun ya da kusuru bilerek geri getirin. Hiç başarısız olduğu görülmemiş bir regresyon testinin duyarlılığı bilinmez; çoğu zaman da test, o kod yolunu hiç çalıştırmadığı için geçiyordur.

İkinci adım ise önceden tasarlanması gereken adımdır. İz kimliği (trace id; korelasyon kimliği de denir), tek bir isteğe ait her model çağrısına, araç çağrısına ve kayıt satırına eklenen bir tanımlayıcıdır; böylece hepsi sonradan bir araya getirilebilir. Tam trajectory’leri korelasyon kimlikleriyle birlikte kalıcı olarak saklamıyorsanız, bir olay size bir test değil yalnızca bir şikâyet bırakır. Bölüm 28 dağıtık izler hakkında aynı şeyi söylemişti; gereken ölçüm altyapısı da aynıdır ve Bölüm 34 onu ayrıntılı olarak kuruyor.

Zamanla katlanarak getiri sağlayan iki alışkanlık:

  • Her olay aynı gün bir teste dönüşür. Süit hayalî değil gerçek hatalardan büyür; üretimi öngören bir değerlendirme kümesiyle durumu olduğundan iyi gösteren bir küme arasındaki fark da budur.
  • Yalnızca testleri değil başarısız izleri de saklayın. Bir düzeltme başka bir şeyi bozduğunda, özgün iz testin neyi koruduğunu açıklar; üç satırlık bir assertion açıklayamaz.

Bu döngünün çevrimdışı yarısı burada; çevrimiçi değerlendirme ve A/B testleriyle üretimdeki yarısını Bölüm 35 ele alıyor.

30.7 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. Üçü bu bölümün iki kez puanladığı otuz çalıştırmayla çözülüyor — bir doğruluk sayısının gizledikleri, ikinci eksenin farklı çalıştırmalar yakalayıp yakalamadığı ve hangi maliyet rakamının raporlanacağı. Diğer üçü yargıya dayalı sorular; bunların ikisi burada çalıştırılan bir şeye değil, Bölüm 24 ve Bölüm 22’deki ölçümlere dayanıyor.

Oraya nasıl vardığıyla ilgili her şeyi: kaç araç çağrısı yaptığını, kaç tanesine ihtiyacı olduğunu, kaçının tekrar olduğunu, kendiliğinden mi durduğunu yoksa bütçesi mi bittiğini ve doğru bir cevabın neye mal olduğunu. Bu bölümdeki ölçümde, sonuç doğruluğu %36,7 olan bir sistem 2 gerektiren bir görev için 7,10 araç çağrısı yapıyor, bunların %70’i tekrardı ve çalıştırmaların %63,3’ünde sınıra çarpıyordu. Bunların hiçbiri bir doğruluk sayısında görünmüyor.

Bu ölçüm bunu söyleyemiyor. Bu durum, gerçekleşebileceği on bir çalıştırmanın yalnızca birinde görüldü (%9,1; aralık %2’den %38’e uzanıyor) ve iki eksende de %100 alan kolun uyuşmazlık göstermesine yer bile yoktu. Yani soruya, sorulduğu biçimiyle verilebilecek cevap “bu örneklem büyüklüğünde çözülmedi”. Trajectory değerlendirmesi yerini, cevaba bağlı olmayan nedenlerle hak eder: size sistemin ne yaptığını, çalıştırmaların neden bozulduğunu (%63,3’lük bir sınıra çarpma oranı yanlış değil bitmemiş çalıştırmalardır) ve doğruluğun gerçekte neye mal olduğunu söyler.

Doğru cevap başına token. Ham token’da buradaki bir sistem diğerinden 1,9 kat daha pahalı görünüyordu; doğru cevap başına 5,1 kattı. Sonucu yok sayan rakam gerçek farkı yaklaşık üç kat küçümsüyordu ve çoğu karşılaştırmanın alıntıladığı rakam odur.

Çünkü düşük recall genellikle ajanın verinize danışmadan cevapladığı anlamına gelir — parametrik bellekten, akıcı biçimde, hiçbir yerde hata olmadan. Her zaman değil: birbirinin yerine geçebilen bir araç ya da önbellekteki bir sonuç da onu düşürebilir; bu yüzden sonuca varmadan önce ize bakın. Bölüm 24 opak şemalı bir aracın vakaların %41,7’sinde hiç çağrılmadığını ve modelin bunun yerine kendinden emin, uydurma bir metin ürettiğini ölçtü. Çağrılmayan bir araç ne kayıt ne hata üretir; dolayısıyla beklediğiniz çağrıları saymaktan başka hiçbir şey onu ortaya çıkarmaz.

Kesin cevabı olmayan kısmı için — bu denenmeye değer makul bir şey miydi — Bölüm 22’nin her uyarısıyla ve bir tane daha. Bir trajectory bir dizidir, dolayısıyla konum etkileri için muhtemelen daha çok yer sunar; o bölüm ise adayların yalnızca yerini değiştirmenin maddelerin %38’inde hükmü çevirdiği bir hakem ölçmüştü. Ölçütleri bütünsel değil ayrı puanlayın, önce birebir aynı trajectory kontrolünü çalıştırın, iki trajectory’yi karşılaştırırken iki sırayı da deneyin ve bir hakemden sayabileceğiniz bir şeyi saymasını asla istemeyin.

Öğrendiğiniz tek şey, ajanın bariz biçimde yetersiz olmadığı. Benchmark’lar Bölüm 22’nin üç problemini taşır: kontrol edemeyeceğiniz bulaşma, tepede doyum ve yapı uyumsuzluğu. Sonuncusu şundan kaynaklanır: bir benchmark bir görevi ölçer, sizdeyse prompt’u, ayrıştırıcısı ve yedek mekanizması olan bir sistem var. Sıralama tablolarını adayları ikiye üçe indirmek için kullanın ve aralarında kendi trafiğinizden çekilmiş senaryolarla karar verin.

30.8 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Bu sorular, kitabın kullandığı iki güvenilir açık kaynakta tekrar tekrar karşımıza çıkıyor; bunlara bu bölümün kendi ölçümünün cevaplanabilir kıldığı sorular da ekleniyor.

30.8.1 Ölçümü anlayıp anlamadığınızı sınayanlar

S: Bir ajanı nasıl değerlendirirsiniz?

İki eksen ve her birinin tek başına neyi kaçırdığını söyleyin. Sonuç: doğru cevapladı mı. Trajectory: tool-call precision ve recall, tekrarlar, araç ve model çağrılarına ayrılmış adım sayısı ve sonlanma oranı. Sonra onları birbirine bağlayan maliyet metriği — doğru cevap başına token, çünkü istek başına rakam sıklıkla yanlış olan bir sistemi olduğundan iyi gösterir. Her görevi birkaç kez çalıştırın ve doğruluğun yanında pass^k’yı raporlayın, çünkü her kullanıcı tek bir örneklem alır ve aynı istek tekrar tekrar gelir; ajan tutarsızsa bu kullanıcıların bir kısmı mutlaka başarısızlığa denk gelir. Deneyimi gösteren ayrıntı: düşük bir sonlanma oranı, çalıştırmaların bir sınıra takılıp bittiği anlamına gelir. Bunun onarımı bir akıl yürütme hatasınınkinden farklıdır ve doğrulukta görünmez.

S: Trajectory değerlendirmesi neden kurmaya değer?

Asıl neden, sonuç değerlendirmesinin geçirdiği çalıştırmaları yakalamak değil: tek bir görev türünde bu, gerçekleşebileceği on bir çalıştırmanın yalnızca birinde oldu ve aralık bir sonuç çıkarmak için fazla geniş. Kurmaya değer, çünkü size sistemin ne yaptığını söyler: %36,7 doğruluktaki bir sistem, 2 gerektiren bir görev için 7,10 araç çağrısı yapıyordu ve bunların %70’i tekrardı. Bunu, zamanın üçte birinde çalıştığını bilerek ama çabanın nereye gittiğini bilmeden yayına alırdınız.

30.8.2 Bir tane yayına alıp almadığınızı sınayanlar

S: Bir kullanıcı ajanın yanlış bir şey yaptığını bildiriyor. Sonra ne olur?

İz kimliğiyle tam trajectory’yi çekin, fixture’larla sabitlenmiş bir senaryoya indirgeyin, hem sonuç hem trajectory için assertion’lar yazın ve bir şey düzeltmeden önce testin başarısız olduğunu teyit edin — ilk gün geçen bir regresyon testi, yazıldığı hatayı yakalayabildiğini henüz göstermemiştir. İkinci adımın mimari bir ön koşul olduğunu söyleyin: kalıcı olarak saklanmış trajectory’ler ve korelasyon kimlikleri olmadan bir olay bir test değil, yalnızca bir şikâyet üretir; o ölçüm altyapısının da olaydan önce kurulmuş olması gerekir.

S: Bir ajan regresyonunu kullanıcılardan önce nasıl yakalarsınız?

Fixture’larla sabitlenmiş bir ortam ve belirlenimci araç yanıtlarıyla gerçek trafikten senaryolar; cevabın yanı sıra trajectory için de assertion yazarak — place_order’dan önce check_inventory çağırmalı, yalnızca sonuca bakan bir testin ifade edemeyeceği bir regresyondur. Sonra ajanı bilinen birkaç şekilde bilerek bozup hangi metriğin hangisini yakaladığını kontrol ederek süiti doğrulayın. Bilerek yerleştirilmiş bir bozulmayı hiç yakalamamış bir süit, duyarlılığı bilinmeyen bir süittir.

30.9 2026 alet çantası

Tek bir yerel modelle yapılan ve iki kez puanlanan otuz çalıştırma o kadar küçük bir iş ki, kullanılan yığın iki satırdan ibaret. İkinci tablodakiler, süitin bir not defterinde (notebook) bir kez değil her commit’te çalışması gerektiğinde önem kazanır.

Bu sayıların çıktığı yığın
kütüphane kullanılan sürüm burada ne işe yarıyor
ollama 0.24.0 iki döngü için de qwen3.5:9b sunmak
numpy 2.5.2 görev kurulumu ve puanlama

Bilinmesi yararlı, yukarıda kullanılmadı:

Daha geniş ekosistem, yazıldığı andaki sürümler
kütüphane güncel sürüm ne zaman kullanılır
langsmith 0.11.2 iz yakalama, veri kümesi yönetimi ve trajectory karşılaştırma
arize-phoenix 20.4.0 kendi sunucunuzda barındırılan, açık kaynak izleme ve değerlendirme
braintrust 0.35.0 CI’a bağlanmış, çalıştırma başına puanlamalı değerlendirmeler
openinference-instrumentation 0.1.59 LLM ve ajan span’leri için OpenTelemetry adlandırma kuralları
ragas 0.4.3 ajan tabanlı bir RAG sisteminin erişim tarafını ayrıca puanlamak
deepeval 4.2.0 birim testler gibi başarısız olan hakem tabanlı metrikler

30.10 Lab: bir bozulmayı yakalayan bir değerlendirme süiti

Bütün işin özü 5. adımda. Bir şey yakaladığını hiç görmediğiniz bir süitin duyarlılığı bilinmezdir ve ajanı kendiniz bozmak, neyi kaçıracağını öğrenmenin tek ucuz yoludur.

30.10.1 Adım 1 — gerçek isteklerden yirmi senaryo

Fixture’larla sabitlenmiş ortam, belirlenimci araç yanıtları. Gerçek ifadeler, dağınık olanlar dâhil.

30.10.2 Adım 2 — sonucu puanlayın

Doğruluk. Zaten elinizde olan sayı budur.

30.10.3 Adım 3 — trajectory metriklerini ekleyin

Her görevin gerektirdiği çağrılara karşı tool-call precision ve recall, tekrarlar, adım sayısı, sonlanma oranı. Toplu değil çalıştırma başına kaydedin. Doğruluğun yanında pass^k’yı da raporlayabilmek için her senaryoyu en az beş kez çalıştırın.

30.10.4 Adım 4 — doğru cevap başına maliyeti hesaplayın

İstek başına değil. Ham token rakamıyla karşılaştırın. Burada iki sistem arasındaki fark ham token’da 1,9 kattan doğru cevap başına 5,1 kata çıktı; yani 2,7 kat büyüdü.

30.10.5 Adım 5 — ajanı bilerek bozun

Her seferinde bir tane olmak üzere üç şekilde: bir araç açıklamasını kaldırın, adım bütçesini yarıya indirin ve bir aracın, ne yapılacağını söyleyen bir hata mesajı yerine çıplak bir "Error" döndürmesini sağlayın. Sonuncusu, Bölüm 24’te toparlanmayı %100’den %1,7’ye düşürdüğü ölçülen değişikliktir. Bu üç bozulmanın üçü de cevabı doğrudan bozar; iki metrik türünü birbirinden ayırmak için 6. adımda trajectory’ye özgü bir bozulma da ekleyeceksiniz.

30.10.6 Adım 6 — hangi metriğin hangi bozulmayı yakaladığını kontrol edin

Tabloyu raporlayın. Sonuç doğruluğu bozulmaların hiçbirini yakalamadıysa ama trajectory metrikleri yakaladıysa, bu metriklerin gerekliliğini az önce göstermiş oldunuz. Sonuç doğruluğu üçünü de yakaladıysa “senaryolar fazla kolay” sonucuna atlamayın — 5. adımda söylendiği gibi bu üç bozulma cevabı doğrudan bozuyor, dolayısıyla onları yakalamak zaten bir sonuç metriğinin işidir. İki metrik türünü ayıran senaryolar, ajanın doğru cevaba kötü bir yoldan vardığı senaryolardır: on kat pahalıya mal olan bir rota ya da istenmeyen bir yan etki. Süitiniz hakkında sonuç çıkarmadan önce her birinden bir tane ekleyip yeniden koşun.

30.10.7 Neyi teslim edeceksiniz

Çalıştırma başına puanları, doğru cevap başına maliyet rakamlarını ve 6. adımdan hangi metriğin hangi bozulmayı saptadığını gösteren tabloyu.

30.11 Alıştırmalar

  1. Tek küme, iki puanlama. Yirmi çalıştırmayı sonuç ve trajectory üzerinden puanlayın. 2×2’lik tabloyu raporlayın. Önce uyuşmazlık oranını öngörün.
  2. Tekrarları sayın. Bir ajanın bir günlük çalışmasını kayda alın ve araç çağrılarının ne kadarının zaten elinde olan bir şeyi istediğini hesaplayın.
  3. Doğru cevap başına maliyet. İki sisteminiz için, istek başına ham token’ların yanında hesaplayın. Hangi karşılaştırma kararı değiştiriyor?
  4. Olaydan teste. Gerçek bir hatanın izini alın ve bir regresyon testine dönüştürün. Düzeltmeden önce başarısız olduğunu teyit edin.
  5. Üç şekilde bozun. Bir araç açıklamasını kaldırın, adım bütçesini yarıya indirin ve bir hata mesajını bozun. Hangi metriğin hangisini yakaladığını kaydedin.
  6. Sonlanma denetimi. Çalıştırmalarınızın ne kadarı model durduğu için, ne kadarı bir sınır tetiklendiği için bitiyor? Cevaplayamıyorsanız ölçülecek ilk şey budur.
  7. Bir kullanıcı benzetin. İki modelli çok turlu bir senaryo kurun, sonra Bölüm 22’nin konum probe’unu benzetimli kullanıcının kendisinde çalıştırın. Benzetimli kullanıcı da rubrikli bir modeldir ve aynı yanlılıkları taşır.
  8. pass@k’ya karşı pass^k. On görevi beşer kez çalıştırın. Bu bölümdeki kestirimlerle \(k = 1\)’den \(5\)’e kadar ikisini de hesaplayın ve iki eğriyi çizin. Önce tahmin edin: \(k = 5\)’te aralarında ne kadar fark olacak?

30.12 Daha derine

Okumadan önce: zaten elinizde olan yirmi çalıştırmayı alın ve araç çağrılarını gereken araç çağrılarına karşı sayın. O oran genellikle ilk sürprizdir.

Makalelerin ötesi
kaynak ne olduğu
τ-bench gerçek bir araç-ve-kullanıcı ajan görevine en yakın açık benchmark; hiç çalıştırmasanız bile bir çalıştırmayı nasıl puanladığını okuyun — son veritabanı durumu bir hedef duruma karşı, pass^k olarak tekrarlanarak
AgentDojo ölçülebilir bir özellik olarak prompt enjeksiyon gürbüzlüğü; çoğu süitin tümüyle atladığı şey
SWE-bench deponun kendi testleriyle doğrulama — tek başına akıcı düzyazıyla geçilemeyen bir sonuç metriği; yine de zayıf testler yanlış bir yamayı geçirebilir
Hamel Husain — değerlendirme üzerine süiti hayalî değil gerçek hatalardan kurmanın uygulamalı gerekçesi
langsmith / arize-phoenix iz yakalama ve trajectory inceleme; regresyon döngüsünün dayandığı ölçüm altyapısı
ragas erişim tarafını ayrıca puanlamak için; Bölüm 20.4’teki yaklaşımla
Birincil kaynaklar
konu kaynak
hakem olarak bir model ve yanlılıkları Zheng vd. (2023); Wang vd. (2024)
iki ajanı karşılaştırmak için eşleştirilmiş test McNemar (1947)
benchmark bulaşması, ölçülmüş hâliyle Sainz vd. (2023)
bir yöntem olarak bütünsel benchmarklama Liang vd. (2023)
büyük ölçekli araç kullanımı benchmark’ları Qin vd. (2024)
pass^k ve son veritabanı durumuyla puanlama Yao vd. (2024)
yararlılık ile saldırı başarısının birlikte ölçülmesi Debenedetti vd. (2024)
değerlendirilen döngü Yao vd. (2023)

30.13 Akılda kalması gerekenler

  • Bir ajan bir cevap ve bir yol üretir; doğruluk yalnızca birini puanlar. Sonuç değerlendirmesi doğru olup olmadığını sorar; trajectory değerlendirmesi oraya varmak için ne yaptığını.
  • Trajectory metriklerinin farklı çalıştırmalar işaretleyip işaretlemediği bu büyüklükte bir ölçümle çözülmüyor. Burada sonuçta geçen on bir çalıştırmanın biri trajectory’de kaldı — aralık %2 ile %38 arasında — ve her şeyi geçen kol zaten bir uyuşmazlık gösteremezdi. Yerlerini o sayıya bağlı olmayan bir nedenle hak ederler: sistemin ne yaptığını ve neden bozulduğunu gösterirler.
  • Sonucun gizlediği israf muazzam olabilir. %36,7 doğruluktaki bir sistem 2 gerektiren bir görev için 7,10 araç çağrısı yaptı, bunların %70’i tekrardı ve çalıştırmaların %63,3’ünde adım bütçesine çarptı. Bu aynı zamanda %36,7’nin kısmen bütçe hakkında bir olgu olduğu anlamına geliyor. Daha büyük bir bütçedeki başarım ölçülmedi; onu gösterecek deney, bütçeyi iki katına çıkarmak.
  • Doğru cevap başına token raporlayın. Ham token bir sistemi 1,9 kat daha pahalı gösterdi; doğru cevap başına 5,1 kattı — sonucu yok sayan rakam farkı yaklaşık üç kat küçümsedi.
  • Sıklıkla atlanan ikisini ölçün: tool-call recall ve sonlanma oranı. Düşük recall genellikle hiçbir yerde hata olmadan parametrik bellekten cevaplamak demektir — ama ize bakın, çünkü birbirinin yerine geçebilen bir araç ya da önbellek de onu düşürebilir. Düşük bir sonlanma oranı, çalıştırmaların bir sınıra takılıp bitmesi demektir ve doğruluk bunu yanlış cevaplardan ayırt edemez.
  • Bir hakem sayılamayan geri kalan kısmı puanlayabilir; sayılabilir kısmı değil. Ondan asla araç çağrısı saymasını istemeyin, ölçütleri bütünsel değil ayrı puanlayın ve önce birebir aynı trajectory kontrolünü, karşılaştırırken de iki sırayı çalıştırın — bir trajectory bir dizidir, dolayısıyla Bölüm 22’nin %38 olarak ölçtüğü konum yanlılığı için muhtemelen daha çok yer sunar.
  • Görev başına tek çalıştırma yalnızca pass^1’i ölçer. Her görevi birkaç kez çalıştırın. pass@k (\(k\) denemeden en az biri başarılı) durumu olduğundan iyi gösterir; pass^k (\(k\) denemenin hepsi başarılı) yayındaki bir ajanın karşılaştığı şeydir — çalıştırma başına 0,8 başarıda dört deneme %99,8’e karşı %41 verir.
  • Benchmark’lar eler; kararı senaryolarınız verir. Bulaşma, doyum ve yapı uyumsuzluğu burada da geçerlidir; bir benchmark bir görevi ölçer, sizdeyse bir sistem vardır. Eylemde bulunan bir ajan için yalnızca yanıtı değil, dünyanın son durumunu da kontrol edin.
  • Her olay aynı gün bir teste dönüşür — ve bir şey düzeltmeden önce başarısız olduğunu teyit edin, çünkü ilk gün geçen bir regresyon testi, hatayı yakalayabildiğini henüz göstermemiştir. Bunun için ilk olaydan önce tasarlanmış, korelasyon kimlikleriyle kalıcı olarak saklanan trajectory’ler gerekir.