Yapay zeka ajanlarını değerlendirme: evals nasıl kurulur ve güvenilirlik sezgiyle değil ölçümle nasıl izlenir

Ajan çalıştığı açıkça görünüyorsa neden değerlendirme gerekir

Görünen şey tam da kötü ölçülen şeydir. Ajan bir hafta boyunca prompt değiştirdikten sonra hiç takılmadıysa, bu bir düzeltme mi yoksa sadece basit bir haftanın sonucu mu? Bir mühendis yeni şablonun her şeyi değiştirdiğinden emindir, bir diğeri aynı logu okuyup fark görmemiştir. İkisi de hiçbir şey saymadıkları ölçüde haklıdır.

Yapay zeka ajanı değerlendirmesi (evals) hissi bir sayıyla değiştirir. Sabit bir görev seti seçersiniz, ajanı çalıştırırsınız, sonucu otomatik kontrol eder ve bir değişiklikten önce ve sonra metrikleri karşılaştırırsınız. Böylece «daha mı iyi oldu» tartışması bir otoriteyle değil, bir tabloyla çözülür.

Evals olmadan harness'in herhangi bir değişikliği — prompt, AGENTS.md, araç seti, model — körlemesine bir bahistir. Evals ile ise ölçülebilir sonucu olan bir deneye dönüşür.

«Hisler» neden yanıltır

Bir ajanın işini izlenimle değerlendirmenin üç sistematik hatası vardır ve üçü de yanlış bir güvene götürür.

• Hayatta kalan yanlılığı. Başarılı çalıştırmalar hatırlanır ve meslektaşlara gösterilir; başarısız olanlar yeniden çalıştırılıp unutulur. Yalnızca başarılı çalıştırmalardan hesaplanan güvenilirlik, ajanın gerçekte nerede çöktüğü hakkında bir şey söylemez.
• Küçük örneklem. Yarısında başarılı olan bir ajan için üst üste üç başarılı görev olağan bir olaydır. Bunun olasılığı 0,5³ = %12,5'tir, yani yaklaşık sekiz seriden birinde.
• Emin ton. Ajan «hazır, tüm testler geçiyor» cümlesini doğruyken de yanlışken de aynı kendinden emin tonla yazar. Modelin özgüveni kalibre edilmemiştir: yanıtın tonu doğruluğun işareti değildir.

Buradan kural çıkar: kaydedilmeyen ve yeniden hesaplanmayan her şey ölçülmemiş sayılır.

pass@k ve pass^k: karıştırılan iki metrik

Ajan deterministik değildir: aynı görev tekrar çalıştırıldığında biri geçebilir, diğeri başarısız olabilir. Bu yüzden bir görev birkaç kez çalıştırılır ve iki metrikten biri hesaplanır.

pass@k: k denemeden en az biri başarılı

Bu metrik kod üretimi değerlendirmesinden gelir. Sistemin, birden fazla deneme verildiğinde görevi prensipte çözüp çözemeyeceğini sorar. İnsanın birkaç seçenekten en iyisini seçtiği ya da başarısızları eleyen güvenilir bir otomatik kontrol olduğu senaryolar için dürüst bir metriktir.

pass^k: k denemenin hepsi başarılı

Bu metrik farklı bir soruya cevap verir: ajan görevi ne kadar tutarlı çözüyor. Denetimsiz çalışmayı tanımlar — ajan çok kez çalışır ve her başarısızlığın parası ya da zamanı vardır.

Aradaki fark çok büyüktür. Ajanın bir denemede görevi %70 olasılıkla çözdüğünü ve denemelerin bağımsız olduğunu varsayalım:

pass@5'e bakınca ajan neredeyse kusursuz görünür; pass^5'e bakınca güvenilmez. İki rakam da doğrudur, sadece farklı şeyleri tanımlarlar. Ajanı denetimsiz çalıştırmayı düşünüyorsanız pass^k'ye bakın: gerçek işte göreceğinize daha yakındır.

Pratikte nasıl hesaplanır

Her görevi n kez (örneğin 5) çalıştırın ve başarı sayısı c'yi kaydedin. pass^k için, k'nın hepsinin art arda başarılı olduğu çalıştırmaların oranı kabaca hesaplanır; daha basiti, başarı olasılığını p = c / n olarak tahmin edip üssünü almaktır. Görev seti için görevler üzerinden ortalama alınır.

import json
from statistics import mean

# results.jsonl: {"task": "add-pagination", "runs": [true, true, false, true, true]}
rows = [json.loads(line) for line in open("results.jsonl")]

def pass_at_k(runs, k):
    p = sum(runs) / len(runs)
    return 1 - (1 - p) ** k

def pass_pow_k(runs, k):
    p = sum(runs) / len(runs)
    return p ** k

for k in (1, 3, 5):
    print(k,
          round(mean(pass_at_k(r["runs"], k) for r in rows), 3),
          round(mean(pass_pow_k(r["runs"], k) for r in rows), 3))

p üssü k tahmini n küçükken kabadır, ama harness sürümlerini birbiriyle karşılaştırmak için genellikle yeterlidir. Asıl önemli olan, karşılaştırmalar arasında n'nin ve görev setinin değişmemesidir.

Değerlendirme görev seti nasıl oluşturulur

Görev seti asıl varlıktır. İyi bir metrik kötü görevlerde ölçülürse yanlış şeyi ölçer.

Görevleri kendi gerçekliğinizden alın

SWE-bench gibi herkese açık benchmark'lar modelleri karşılaştırmak için faydalıdır, ama görevleri seçilmiştir: açık tanımları ve hazır testleri vardır. Kendi deponuzda gereksinimler bulanıktır, testler bazı yerlerde yoktur; bu yüzden benchmark rakamı neredeyse her zaman ajanın sizde göstereceğinden yüksek çıkar. En iyi görev kaynağı kapatılmış biletler ve günlükteki gerçek ajan başarısızlıklarıdır.

Setin bileşimi

• Başlangıç için 20–50 görev. Daha azı, gürültü sürümler arasındaki farkı yutar. Daha fazlası çalıştırmayı pahalı yapar ve kimse çalıştırmaz hale gelir.
• Farklı türler: yeni özellik, hata düzeltme, yeniden düzenleme, başka bir modül üzerinde görev, bir tuzak içeren görev (doğru cevabın «bunu böyle yapmak olmaz» ya da «açıklama gerekli» olduğu).
• Çalışmada başarısız olan her görev bir teste dönüşür. Böylece set, ajanın nerede zayıf olduğu anlayışıyla birlikte büyür ve gerilemeler fark edilmeden geri gelmez.
• Sabit başlangıç durumu: belirli bir commit, sabitlenmiş bağımlılıklar, aynı ortam. Aksi halde ajanı değil, ortam sapmasını ölçersiniz.

Görev formatı

Her görev bir açıklama, bir başlangıç durumu ve insan gerektirmeden kontrol edilebilen bir başarı kriteridir.

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  GET /payments için sayfalama ekle: limit (varsayılan 20, en fazla 100)
  ve cursor parametreleri. Yanıt next_cursor içersin.
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

Dikkat edin: başarı kriteri, komutlarla yazılmış bir Definition of Done'dur. Bir görev için kriter yazamıyorsanız, bu görevin ajana da belirsiz verildiğinin işaretidir.

Otomatik kontroller mi, LLM hakemi mi

Sonucu koddan ya da başka bir modelden kontrol ettirebilirsiniz. Her yöntemin kendi alanı vardır.

Kural: önce kod, hakem üstüne

Deterministik olarak kontrol edilebilen her şeyi deterministik kontrol edin. LLM hakemini yalnızca kodla ifade edilemeyen özellikler için ekleyin ve asla testlerin yerine koymayın.

LLM hakemini faydalı kılmanın yolları

• Üreticiyle farklı bağlam. Hakem ajanın akıl yürütmelerini görmemeli; yalnızca görevi, kriterleri ve nihai diff'i görmelidir. Aksi halde aynı hataları tekrarlar. Bu, N-sürümlülüktür: tek bakış yerine iki bağımsız bakış.
• «On üzerinden puan ver» yerine rubrik. Evet/hayır ile cevaplanan somut sorular: «limit > 100 için doğrulama var mı?», «app/payments dışındaki dosyalar değişti mi?»
• Elle etiketlenmiş veriyle kalibrasyon. 20–30 sonucu elle etiketleyin ve hakemin kararlarıyla karşılaştırın. Uyum düşükse hakemine daha fazla güvenmek yerine rubriği değiştirin.
• Hataların asimetrisi. Yanlış «hazır» yanlış «hazır değil»den pahalıdır: birincisi üretime çıkar, ikincisi bir yeniden çalıştırma maliyetidir. Hakemi şüphede reddedecek şekilde ayarlayın.

Başarı oranının dışında hangi metrikler sayılmalı

Çözülen görev oranı yalnızca tepesidir. Nerede düzeltme yapılacağını anlamak için klasik mühendislikten güvenilirlik metriklerine ihtiyaç vardır.

• MTBF — ajanın takılmadan kaç adım ya da görev geçtiği. Ne kadar nadir bozulduğunu gösterir.
• MTTR — bir arızadan sonra çalışır duruma dönmek için geçen süre. Bunu düşürmek çoğu zaman MTBF'yi yükseltmekten daha ucuzdur: iyi bir ilerleme dosyası ve tekrarlanabilir bir ortam kurtarmayı katlarca kısaltır.
• Etki yarıçapı — başarısız tek bir adımın kaç kod bozduğu. Diff sınırı ve çalışma kopyasının izolasyonuyla sınırlanır.
• Yanlış «hazır» oranı — ajanın başarı bildirdiği ama kontrolün başarısız olduğu görevler. En tehlikeli metrik budur: ajanın raporuna güvenilip güvenilmeyeceğini gösterir.
• Maliyet ve süre — görev başına token ve dakika. Başarıyı %5 artırıp maliyeti iki katına çıkaran bir harness her zaman kazanan değildir.

Hata günlüğü: gündelik işten evals

Her ekip hemen bir ölçüm aracı kurmaya hazır değildir. Minimum sürüm, üç sütunlu bir hata günlüğüdür.

| Görev                   | Sonuç                              | Katman        |
|-------------------------|------------------------------------|---------------|
| /payments sayfalama     | «hazır», 2 test kırmızı            | doğrulama     |
| webhook zaman aşımı düzeltmesi | 30 dk pip install            | ortam         |
| refunds yeniden düzenleme | eski ORM sözdizimi              | bağlam        |

Katman, ajanın bozulduğu beş yerden biridir: görev spesifikasyonu, bağlam, çalışma ortamı, doğrulama geri bildirimi, durum yönetimi. Yirmi kayıttan sonra gerçek darboğaz görünür olur ve neredeyse hiçbir zaman sandığınız yerde değildir. Günlüğün her satırı, evals görev setinde bir aday olur.

Güçlü model neden tek başına yetmez

Ajanın başarısızlıklarına ilk tepki, daha pahalı bir model almaktır. Bazen işe yarar, ama çoğu zaman benchmark ile gerçekliğiniz arasındaki farkı kapatan şey model değil, etrafındaki ortamdır.

Ajan ortamı kurmak için yarım saat harcıyorsa, bu ortam katmanıdır ve amiral gemisi bir model de aynı yarım saati harcar. Kırmızı testlere rağmen «hazır» diyorsa, bu doğrulama katmanıdır: gerçeği söyleyecek bir komutu yoktur. Projenin stiline uymayan kod yazıyorsa, ona proje konvansiyonları verilmemiştir. Bu sorunların hiçbiri modelin zekâsıyla ilgili değildir.

Evals bunu dürüstçe test etmenizi sağlar. Mevcut modelle ve daha pahalı bir modelle set çalıştırın; sonra mevcut modelle ve komutları içeren bir AGENTS.md ekleyerek çalıştırın. Çoğu zaman ikinci değişiklik sıfır maliyetle birincinden daha fazla kazanç sağlar. Ama bunu söze güvenerek kabul etmeyin: bu tür karşılaştırmalar için set tam da bunun için vardır.

Adım adım plan: bir haftada ajan değerlendirmesi

1. 1. gün. Bir hata günlüğü açın ve ajanın her başarısızlığını katmanıyla birlikte yazın.
2. 2. gün. Kapatılmış biletlerden ve günlükten 20 görev seçin. Her biri için commit'i sabitleyin ve başarı kriterini komutlarla yazın.
3. 3. gün. Bir çalıştırıcı yazın: temiz çalışma kopyası, ajanı görev promptuyla başlatma, kontrolleri çalıştırma, sonucu JSONL'e yazma.
4. 4. gün. Her görevi 3–5 kez çalıştırın. pass@1, pass^3, yanlış «hazır» oranını ve ortalama maliyeti hesaplayın.
5. 5. gün. Harness'te bir şeyi değiştirin ve yeniden çalıştırın. Yalnızca aynı set ve aynı tekrar sayısıyla karşılaştırın.

Her seferinde bir değişken değiştirin. Tek bir denemede model, prompt ve araçları birden değiştirirseniz neyin işe yaradığını anlayamazsınız.

Ajan değerlendirmesinde sık yapılan hatalar

• Görev başına tek çalıştırma. Ajanın belirsizliği bu sonucu bir piyangoya çevirir. En az üç tekrar yapın.
• Karşılaştırmalar arasında set değişir. Yeni görevler ekleyip aynı anda promptu değiştirirseniz sayılar karşılaştırılamaz hale gelir.
• Ajan kontrol testlerini görür. Testler depoda duruyorsa ajan kodu onlara uydurabilir ya da testleri değiştirebilir. Gizli kontrolleri çalışma kopyasının dışında tutun ve ajanın test dosyalarına dokunmadığını doğrulayın.
• Kontrol yerine ajanın raporu. Model yanıtındaki «tüm testler geçti» bir sonuç değildir. Sonuç, çalıştırıcının başlattığı komutun çıkış kodudur.
• Yalnızca pass@k. Sunum için güzel bir rakam, denetimsiz çalışma için kötü bir tahmindir.

Özet

Yapay zeka ajanı değerlendirmesi, sabit bir gerçek görev seti, otomatik kontroller ve her harness değişikliğinden sonra yeniden hesaplanan metriklerdir. pass@k ajanın neye muktedir olduğunu, pass^k ona denetimsiz olarak güvenilip güvenilemeyeceğini gösterir. Otomatik kontroller gerçeği söyler; rubrikli ve ayrı bağlama sahip bir LLM hakemi, kodun yetmediği yerlerde bunu tamamlar. Beş katmana göre tutulan hata günlüğü ise önce neyin düzeltileceğini gösterir ve çoğu zaman bu model değildir. Güvenilirlik metrikleri ve tanı döngüsü kursta uygulamalı olarak işlenir.