Pagsusuri ng AI agent: paano bumuo ng evals at sukatin ang pagiging maaasahan, hindi ang vibe

Bakit kailangan ng pagsusuri ng AI agent kung halata namang gumagana ito

Kadalasan, hindi ito halata. Hindi nagkaproblema ang agent sa loob ng isang linggo pagkatapos baguhin ang prompt. Ayos ba ang sanhi, o simpleng madali lang ang mga gawain sa linggong iyon? Sigurado ang isang inhinyero na ang bagong template ang nagpabago ng lahat, habang ang pangalawa, na tiningnan ang parehong log, ay walang nakitang pagbabago. Tama silang dalawa hangga't wala silang binilang.

Pinapalitan ng pagsusuri ng AI agent (evals) ang pakiramdam ng isang numero. Kumukuha ka ng nakapirming hanay ng gawain, pinapatakbo ang agent, awtomatikong sinusuri ang resulta, at inihahambing ang mga sukatan bago at pagkatapos ng pagbabago. Kaya ang pagtatalo kung "gumanda ba" ay nalulutas sa talaan, hindi sa awtoridad.

Kung walang evals, anumang pagbabago sa harness (prompt, AGENTS.md, hanay ng tool, modelo) ay pustang bulag. Kung meron, ito ay eksperimentong may masusukat na resulta.

Bakit nililinlang ng "vibe"

May tatlong sistematikong pagkakamali ang impresyon sa trabaho ng agent, at lahat ay nagtutulak tungo sa maling kumpiyansa.

• Survivorship bias. Naaalala at ipinapakita sa mga kasamahan ang matagumpay na takbo, habang ang mga bigo ay inuulit at nakakalimutan. Ang pagiging maaasahan na kinalkula mula sa matagumpay na takbo ay walang sinasabi kung saan talaga bumabagsak ang agent.
• Maliit na sample. Ang tatlong sunod-sunod na matagumpay na gawain ay karaniwang pangyayari, kahit para sa agent na nagtatagumpay sa kalahati ng kaso. Ang tsansa nito ay 0.5³ = 12.5%, ibig sabihin humigit-kumulang isa sa walong serye.
• Tiyak na tono. Sinasabi ng agent ang "tapos na, pumapasa ang lahat ng test" nang kasing-tiyak kung totoo man o hindi. Hindi na-calibrate ang kumpiyansa ng modelo: ang tono ng sagot ay hindi senyales ng kawastuhan.

Mula dito ang tuntunin: anumang hindi naitala at hindi muling binilang ay ituturing na hindi nasusukat.

pass@k at pass^k: dalawang sukatang madalas malito

Hindi deterministiko ang agent: ang parehong gawain sa pag-ulit ay maaaring pumasa o bumagsak. Kaya pinapatakbo nang ilang beses ang isang gawain at binibilang ang isa sa dalawang sukatan.

pass@k: kahit isa sa k subok ang matagumpay

Galing ang sukatang ito sa pagsusuri ng pagbuo ng code. Sinasagot nito ang tanong na "kaya ba ng sistema sa prinsipyo na lutasin ang gawain, kung bibigyan ito ng ilang subok." Tapat na sukatan ito para sa senaryo kung saan pumipili ang tao ng pinakamahusay sa ilang bersiyon, o kung may maaasahang awtomatikong pagsusuri na nagtatanggal ng mga bigo.

pass^k: lahat ng k subok ay matagumpay

Ibang tanong ang sinasagot nito: "gaano katatag na nalulutas ng agent ang gawain." Inilalarawan nito ang trabahong walang bantay, kung saan pinapatakbo ang agent nang maraming beses at may halaga sa pera o oras ang bawat bigo.

Malaki ang agwat ng dalawa. Ipagpalagay na ang agent ay nalulutas ang gawain sa 70% na tsansa kada subok, at independent ang mga subok:

Sa pass@5, mukhang halos perpekto ang agent; sa pass^5, mukha itong hindi maaasahan. Tama ang dalawang bilang, pero inilalarawan nila ang magkaibang bagay. Kung balak mong patakbuhin ang agent nang autonomous, tingnan ang pass^k: mas malapit ito sa makikita mo sa totoong trabaho.

Paano kalkulahin sa praktika

Patakbuhin ang bawat gawain nang n beses (halimbawa 5) at itala ang bilang ng tagumpay na c. Para sa pass^k, ang tinatayang halaga ay ang bahagi ng mga takbo kung saan sunod-sunod na nagtagumpay ang lahat ng k; mas simple, tantiyahin ang tsansa ng tagumpay na p = c / n at itaas ito sa kapangyarihang k. Para sa hanay ng gawain, i-average ang mga resulta kada gawain.

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))

Magaspang ang pagtatantiya gamit ang p sa kapangyarihang k kapag maliit ang n, pero sapat na ito karaniwan para ihambing ang mga bersiyon ng harness sa isa't isa. Mas mahalaga na hindi nagbabago ang n at ang hanay ng gawain sa pagitan ng mga paghahambing.

Paano bumuo ng hanay ng gawain para sa evals

Ang hanay ng gawain ang pinakamahalagang ari-arian. Ang mahusay na sukatan sa masamang gawain ay sumusukat ng maling bagay.

Kumuha ng gawain mula sa sarili mong realidad

Kapaki-pakinabang ang mga pampublikong benchmark tulad ng SWE-bench sa paghahambing ng mga modelo, pero pinili na ang kanilang mga gawain: malinaw ang paglalarawan at handa na ang mga test. Sa iyong repositoryo, malabo ang mga kinakailangan at kulang ang test sa ilang bahagi, kaya halos palaging mas mataas ang numero ng benchmark kaysa sa ipapakita ng agent sa iyo. Pinakamahusay na pinagmumulan ng gawain ang mga nasarang ticket at ang mga totoong pagkabigo ng agent mula sa journal.

Komposisyon ng hanay

• 20–50 gawain sa simula. Kung mas kaunti, lalamunin ng ingay ang pagkakaiba ng mga bersiyon. Kung mas marami, magiging mahal ang pagtakbo at titigil na ito sa pagpapatakbo.
• Iba't ibang uri: bagong feature, pag-aayos ng bug, refactoring, gawain sa ibang module, gawaing may bitag (kung saan ang tamang sagot ay "hindi dapat gawin ito nang ganyan" o "kailangan ng paglilinaw").
• Bawat gawaing bumagsak sa trabaho ay nagiging test. Kaya lumalaki ang hanay kasabay ng pag-unawa kung saan mahina ang agent, at hindi bumabalik nang hindi napapansin ang mga regression.
• Nakapirming panimulang estado: tiyak na commit, nakapirming dependency, parehong kapaligiran. Kung hindi, hindi ang agent ang sinusukat mo kundi ang pagkakaiba ng kapaligiran.

Format ng gawain

Ang bawat gawain ay isang paglalarawan, panimulang estado, at pamantayan ng tagumpay na maaaring suriin nang walang tao.

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  Magdagdag ng pagination sa GET /payments: mga parameter na limit (default 20, pinakamataas 100)
  at cursor. Ang sagot ay naglalaman ng next_cursor.
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

Pansinin: ang pamantayan ng tagumpay ay ang Definition of Done na nakasulat bilang mga utos. Kung hindi mo maisulat ang pamantayan para sa gawain, senyales iyon na malabo rin ang pagkakabigay nito sa agent.

Awtomatikong pagsusuri o LLM judge

Maaaring suriin ang resulta gamit ang code o ibang modelo. May kanya-kanyang sakop ang bawat paraan.

Tuntunin: code muna, judge sa ibabaw

Ang lahat ng maaaring suriin nang deterministiko ay suriin nang deterministiko. Idagdag ang LLM judge lamang para sa mga katangiang hindi maipapahayag ng code, at hindi kailanman bilang kapalit ng mga test.

Paano gawing kapaki-pakinabang ang LLM judge

• Magkaibang konteksto sa generator. Hindi dapat makita ng judge ang pangangatwiran ng agent, tanging ang gawain, pamantayan, at huling diff. Kung hindi, uulitin lang nito ang parehong pagkakamali: ito ang N-version na prinsipyo, dalawang independent na pananaw sa halip na isa.
• Rubric sa halip na "suriin sa sampung-puntong sukat." Tiyak na tanong na sinasagot ng oo o hindi: "may validation ba ng limit > 100," "may nagbago bang file sa labas ng app/payments."
• Calibration gamit ang manwal na marka. Markahan nang manwal ang 20–30 resulta at ihambing sa hatol ng judge. Kung mababa ang pagkakatugma, baguhin ang rubric, hindi dagdagan ang tiwala sa judge.
• Asimetriya ng mga pagkakamali. Mas mahal ang maling "tapos na" kaysa sa maling "hindi pa tapos": ang una ay napupunta sa production, ang pangalawa ay nagkakahalaga ng isang ulit na takbo. I-configure ang judge para tanggihan kapag may pag-aalinlangan.

Anong mga sukatan ang bibilangin bukod sa bahagi ng tagumpay

Ang bahagi ng nalutas na gawain ay tuktok lamang. Para malaman kung saan dapat ayusin, kailangan ang mga sukatan ng pagiging maaasahan mula sa klasikong engineering.

• MTBF — ilang hakbang o gawain ang kayang tapusin ng agent bago ito matigil. Ipinapakita kung gaano kadalang itong masira.
• MTTR — gaano katagal bago maibalik sa gumaganang estado pagkatapos ng pagkabigo. Halos palaging mas mura ang pagpapababa nito kaysa pagpapataas ng MTBF: ang mahusay na progress file at mauulit na kapaligiran ay nagpapaikli ng pagbawi nang maraming beses.
• Radius ng pinsala — gaano karaming code ang nasisira ng isang masamang hakbang. Nalilimitahan ito ng limitasyon sa diff at ng paghihiwalay ng working copy.
• Bahagi ng maling "tapos na" — mga gawaing ipinahayag ng agent na matagumpay pero bumagsak ang pagsusuri. Ito ang pinakamapanganib na sukatan: ipinapakita nito kung maaari bang paniwalaan ang ulat ng agent.
• Gastos at oras — token at minuto kada gawain. Ang harness na nagtaas ng tagumpay ng 5% pero dumoble ang gastos ay hindi laging nananalo.

Journal ng mga pagkabigo: evals mula sa pang-araw-araw na trabaho

Hindi laging handang bumuo agad ng runner ang isang koponan. Ang pinakamaliit na bersiyon ng pagsusuri ay journal ng pagkabigo na may tatlong hanay.

| Gawain                  | Resulta                            | Layer         |
|-------------------------|------------------------------------|---------------|
| pagination /payments    | "tapos na", 2 test ang pula        | beripikasyon  |
| pag-ayos ng timeout ng webhook | 30 min sa pip install       | kapaligiran   |
| refactoring ng refunds  | lumang syntax ng ORM               | konteksto     |

Ang layer ay isa sa limang lugar kung saan karaniwang pumapalya ang agent: espesipikasyon ng gawain, konteksto, kapaligiran ng pagpapatakbo, feedback ng beripikasyon, at pamamahala ng estado. Pagkatapos ng dalawampung tala, makikita ang tunay na bottleneck, at halos hindi ito kailanman nasa lugar na inakala mo. Bawat hanay ng journal ay kandidato para sa hanay ng evals.

Bakit hindi nakatutulong ang malakas na modelo

Ang unang reaksyon sa pagkabigo ng agent ay kumuha ng mas mahal na modelo. Minsan nakatutulong ito, pero mas madalas, ang kapaligirang nakapalibot sa modelo ang nagsasara ng agwat sa pagitan ng benchmark at realidad, hindi ang modelo mismo.

Kung kalahating oras na nagse-set up ang agent ng kapaligiran, layer iyon ng kapaligiran, at kalahating oras din itong gagawin ng pinakamahal na modelo. Kung sinasabi ng agent na "tapos na" habang pula ang mga test, layer iyon ng beripikasyon: walang utos na magsasabi ng totoo. Kung sumusulat siya ng code sa istilong hindi sa proyekto, hindi siya binigyan ng mga kombensiyon ng proyekto. Walang isa sa mga problemang ito ang tungkol sa talino ng modelo.

Matapat itong masusuri gamit ang evals. Patakbuhin ang hanay gamit ang kasalukuyang modelo at gamit ang mas mahal na modelo, at pagkatapos gamit ang kasalukuyang modelo na may idinagdag na AGENTS.md na may mga utos ng pagsusuri. Madalas, mas malaki ang pakinabang ng ikalawang pagbabago kaysa sa una, at walang gastos. Pero huwag itong paniwalaan nang basta-basta: para sa ganitong paghahambing talaga kailangan ang hanay.

Hakbang-hakbang na plano: pagsusuri ng AI agent sa loob ng isang linggo

1. Araw 1. Gumawa ng journal ng pagkabigo at itala roon ang bawat palya ng agent kasama ang layer.
2. Araw 2. Pumili ng 20 gawain mula sa mga nasarang ticket at sa journal. Para sa bawat isa, i-freeze ang commit at isulat ang pamantayan ng tagumpay bilang mga utos.
3. Araw 3. Sumulat ng runner: malinis na working copy, pagpapatakbo ng agent gamit ang prompt ng gawain, pagpapatakbo ng mga tseke, at pagsulat ng resulta sa JSONL.
4. Araw 4. Patakbuhin ang bawat gawain nang 3–5 beses. Kalkulahin ang pass@1, pass^3, bahagi ng maling "tapos na," at karaniwang gastos.
5. Araw 5. Baguhin ang isang bagay sa harness at patakbuhin ulit. Ihambing lamang kapag pareho ang hanay at ang bilang ng ulit.

Baguhin ang isang variable sa bawat pagkakataon. Kung sabay mong papalitan ang modelo, prompt, at mga tool sa iisang eksperimento, hindi mo malalaman kung ano ang nakatulong.

Mga karaniwang pagkakamali sa pagsusuri ng agent

• Isang takbo lamang bawat gawain. Ang hindi-deterministikong kilos ng agent ay ginagawang loterya ang ganitong resulta. Hindi bababa sa tatlong ulit.
• Nagbabago ang hanay sa pagitan ng mga paghahambing. Nagdagdag ka ng bagong gawain at sabay nagbago ng prompt: hindi na maihahambing ang mga numero.
• Nakikita ng agent ang mga test ng beripikasyon. Kung nasa repositoryo ang mga test, maaaring i-adjust ng agent ang code para tumugma sa mga ito, o baguhin lang ang mga test. Itago ang mga lihim na beripikasyon sa labas ng working copy at tiyaking hindi ginalaw ng agent ang mga test file.
• Ulat ng agent sa halip na beripikasyon. Ang "pumasa ang lahat ng test" sa sagot ng modelo ay hindi resulta. Ang resulta ay ang return code ng utos na pinatakbo ng runner.
• Pass@k lamang. Magandang numero para sa presentasyon, mahinang hula para sa autonomous na trabaho.

Sa madaling sabi

Ang pagsusuri ng AI agent ay isang nakapirming hanay ng totoong gawain, awtomatikong pagsusuri, at mga sukatang muling binibilang pagkatapos ng bawat pagbabago sa harness. Sinasabi ng pass@k kung ano ang kaya ng agent; sinasabi ng pass^k kung maaari mo itong pagkatiwalaan nang walang bantay. Ang awtomatikong pagsusuri ang nagbibigay ng katotohanan, habang ang LLM judge na may rubric at hiwalay na konteksto ay dinadagdagan ito kung saan hindi kayang abutin ng code. At ang journal ng pagkabigo sa limang layer ang nagpapakita kung ano ang dapat ayusin muna, at kadalasan, hindi ang modelo iyon. Ang mga sukatan ng pagiging maaasahan at ang diagnostic loop ay tinatalakay nang praktikal sa kurso ng harness engineering.