Yazılmış-benchmark yanılsaması
Çoğu agent değerlendirme seti, ekibin zaten aklında olan bir görev listesiyle başlar: uçuş rezervasyonu yap, bir belgeyi özetle, bir destek talebini çöz. Bu görevler smoke-test için faydalıdır, ancak yapısal bir kusuru paylaşırlar. Agent'ı üreten hayal gücünün aynısından çıkarılmışlardır. Ekibin düşündüğü görevler, neredeyse tanımı gereği, agent'ın zaten üstesinden geldiği görevlerdir. Hiç başarısız olmayan bir benchmark, benchmark değildir; bir aynadır.
Önemli olan arızalar kuyrukta yaşar: kimsenin öngörmediği tool-call sıralamaları, kararsız bir upstream'in tetiklediği retry fırtınaları, durumu tutarsız bırakan kısmi yazmalar, bir şemanın yorumunu sessizce değiştiren bir model sürümü. Bu bileşimler tasarlanmaz. Keşfedilirler. Ve keşfedilen arızaların tek güvenilir kaynağı üretimdir.
Bu yüzden agent değerlendirmeleri olay yeniden oynatmaları olmalıdır. Regresyon külliyatı, hayal edilen senaryoların derlenmiş bir kümesi değil; her biri sistemin gerçekten sergilediği bir arızayı kodlayan bir fixture olan, büyüyen bir gerçek yörüngeler arşividir. Bu değişim teknik olduğu kadar kültüreldir: eval seti, ayrı bir yazım egzersizinin değil, operasyonun bir yan ürünü haline gelir.
Bir olay yeniden oynatması aslında ne içerir
Bir üretim izi, bir prompt-response çiftinden daha zengindir. Yeniden oynatılabilir bir olay en az dört katman içerir:
- Girdi durumu: kullanıcı isteği, konuşma geçmişi, alınan bağlam ve her türlü ortam durumu (feature flag'ler, tenant yapılandırması, oturum meta verisi).
- Tool call dizisi: argümanlar, çağıranın kimliği ve egress hedefi dahil olmak üzere sıralı tool çağrıları listesi.
- Ara gözlemler: tool sonuçları, hata yükleri, latency ve her türlü retry veya fallback.
- Nihai yan etkiler: nihai yanıt, ama aynı zamanda agent'ın neden olduğu yazmalar, e-postalar, talepler veya durum mutasyonları.
Bu katmanları yakalamak gerekli ama yeterli değildir. Bir yeniden oynatma deterministik olmalıdır. Harici uç noktalar kaydedilmiş yanıtlarla stub'lanır; saatler dondurulur veya enjekte edilir; model sürümleri izi üreten tam snapshot'a sabitlenir. Determinizm olmadan, bir yeniden oynatma bir yeniden canlandırmadır ve geçti/kaldı sinyali gürültüdür.
Bu nedenle replay fidelity, bir değerlendirme probleminden önce bir veri pipeline problemidir. Tracing'i sonradan akla gelen bir şey olarak gören ekipler, olaylarının yeniden oynatılamaz olduğunu keşfeder: tool yanıtları loglanmamıştır, model sürümü kaydedilmemiştir, saat yakalanmamıştır. Çözüm upstream'dedir: agent'ı, her yörüngenin birinci sınıf, sürümlenmiş bir artifact olduğu şekilde enstrümante edin.
Minimal bir regresyon harness'ı
Burada tarif edilen harness kasıtlı olarak küçüktür. Üç bileşen varsayar: bir trace store, bir replay runner ve bir merge gate.
İzleri sürümlenmiş artifact olarak saklayın
İzler, sürüklenen ayrı bir veritabanında değil, onları üreten kodun yanında saklanır. Bir trace artifact'ı girdi durumunu, tool dizisini, gözlemleri ve nihai yan etkileri, ayrıca model sürümünü ve agent yapılandırmasının bir hash'ini içerir. Artifact'ı sürümlemek, agent'taki bir değişikliğin tam tarihsel bağlama karşı değerlendirilebileceği anlamına gelir.
# trace-2025-03-14-001.yaml
trace_id: 2025-03-14-001
agent_config_hash: 9f2c...
model_version: gpt-4.1-2025-04-14
input_state:
user_request: "reconcile invoice 8842"
conversation: [...]
tool_sequence:
- name: fetch_invoice
args: {id: 8842}
result: {status: 200, body: {...}}
- name: post_ledger_entry
args: {amount: 120.00, account: "AR"}
result: {status: 500, error: "timeout"}
terminal_side_effects:
- type: ledger_entry
status: not_written
Sadece nihai yanıtı değil, yörünge özelliklerini puanlayın
Nihai yanıt doğruluğu, agent'lar için zayıf bir sinyaldir. Tehlikeli bir tool call, yetkisiz bir egress veya bir retry fırtınası gerektiren doğru bir yanıt geçer değildir. Harness yörünge özelliklerini puanlar:
- Tool kümesi: hangi tool'ların çağrıldığı ve herhangi birinin izin verilen kümenin dışında olup olmadığı.
- Sıralama: dizinin bağımlılıklara ve idempotency kısıtlarına uyup uymadığı.
- Egress hedefleri: hangi harici uç noktalarla iletişime geçildiği ve bunların allowlist ile eşleşip eşleşmediği.
- Retry davranışı: kaç retry gerçekleştiği ve bunların sınırlı olup olmadığı.
- Yan etki tutarlılığı: ara arızalar göz önüne alındığında nihai durumun tutarlı olup olmadığı.
Bu özellikler bir judge model olmadan kontrol edilebilir. Deterministik, hızlı ve açıklanabilirdirler. Tool kümesi veya egress üzerinde başarısız olan bir yeniden oynatma, bir kalite regresyonu değil, bir güvenlik veya güvenilirlik
Harness her pull request'te çalışır. Kapı tek bir puan değil, külliyat genelinde bir geçme oranıdır ve regresyonlar için bir politikası vardır: base branch'te geçen ve head branch'te başarısız olan herhangi bir iz, kaydedilmiş bir gerekçeyle açıkça feragat edilmediği sürece merge'ü bloklar. Yeni olaylar zorunlu yeni fixture olarak ele alınır. Bir olay çözüldüğünde, onu yeniden üreten iz, düzeltmeyle aynı pull request'te külliyata eklenir.
Operasyonu değerlendirmeye dönüştüren mekanizma budur. Külliyat, ekibin hayal gücüyle değil, sistemin gerçek arıza yüzeyiyle büyür.
Maliyetler ve sınırlar
Bir replay külliyatı monoton olarak büyür. Her olay bir fixture ekler ve fixture'ları saklamak ucuz ama çalıştırmak pahalıdır. Dürüst ödünleşim, kapsam ile çalışma süresi arasındadır. Yeniden oynatılması bir saat süren bir külliyat atlanır; bir dakika süren bir külliyat ise yetersiz örneklenir. Pragmatik yanıt, silme değil bir budama politikasıdır. İzler katmanlara ayrılır: her commit'te çalışan hızlı bir katman (küçük, yüksek sinyalli bir alt küme), gecelik çalışan tam bir katman ve adli kullanım için saklanan bir arşiv katmanı. Budama, hangi arızaların hâlâ temsili olduğuna dair bir politika kararıdır, bir çöp toplama problemi değil.
Bazı arızalar yapıları gereği yeniden üretilemez. Canlı bir üçüncü taraf durumuna bağlı bir race condition, tek seferlik bir veri bozulması, sağlayıcı snapshot'ları açığa çıkarmadığı için sabitlenemeyen bir model davranışı. Bunlar sadakatle yeniden oynatılamaz. Cazibe onları atmaktır. Daha iyi uygulama, onları bilinen-bilinmeyen fixture olarak kaydetmektir: bir sahibi, şüphelenilen mekanizmanın bir açıklaması ve geçti/kaldı kapısının parçası olmadığına dair bir işaretçisi olan bir iz. Külliyat böylece test edilen ile yalnızca hatırlanan arasında ayrım yapar.
İkinci bir sınır, yeniden oynatmanın gelecek için doğruluğu değil, geçmişe sadakati ölçmesidir. Tamamen olaylardan oluşturulmuş bir külliyat, zaten meydana gelmiş arıza modlarına aşırı ağırlık verecektir. Bu kabul edilebilir, çünkü alternatif — hayal edilen görevlerden oluşturulmuş bir külliyat — asla meydana gelmeyecek arıza modlarına aşırı ağırlık verir. Disiplin, külliyatı bir spesifikasyon değil, yaşayan bir kayıt olarak ele almaktır.
Operasyonel değişim
Argüman, yazılmış benchmark'ların işe yaramaz olduğu değildir. Onboarding, smoke test'ler ve niyeti iletmek için faydalıdırlar. Argüman, agent'lar için birincil değerlendirme yüzeyi olarak yetersiz olduklarıdır. Önemli olan arızalar üretimde keşfedilir ve tekrarlanmalarını önlemenin tek yolu onları yeniden oynatmaktır.
Bu, ekiplerin izleri ele alış biçiminde bir değişim gerektirir: log olarak değil, sürümlenmiş artifact olarak. Ekiplerin olayları ele alış biçiminde bir değişim gerektirir: tek seferlik yangınlar olarak değil, zorunlu fixture olarak. Ve ekiplerin değerlendirmeyi ele alış biçiminde bir değişim gerektirir: hayal edilen görevlerden oluşan statik bir set olarak değil, gerçek yörüngelerden oluşan büyüyen bir arşiv olarak.
Sonuç, sistemin gerçek davranışını yansıtan bir regresyon külliyatıdır. Asla tam olmayacaktır. Her zaman bir sonraki olayın gerisinde kalacaktır. Ama dürüst olacaktır ve faydalı olacaktır.