MI-ügynökök értékelése: trajektóriák, eredmények és megbízhatóság pontozása

Egy ügynök, amely azt írja, hogy "a visszatérítést feldolgoztuk", és egy ügynök, amely ténylegesen fel is dolgozta, a chatnaplóban ugyanúgy néz ki. Ügynököt értékelni annyit jelent, mint az utolsó üzeneten túlra nézni: az eredményre (mi változott a világban) és a trajektóriára (mely eszközöket hívta meg, milyen sorrendben, milyen argumentumokkal). Ha csak a végső szöveget pontozod, olyan ügynököd lesz, amely átmegy az evalokon, de cserben hagyja az ügyfeleket.

Ez a cikk az LLM evalok termékfunkciókhoz című írás ügynökökre szabott folytatása. Szó lesz a fogalmakról, a háromféle értékelőről (grader), a trajektóriaegyeztetésről az agentevals, a DeepEval és a Ragas segítségével, arról, miért fontosabb a pass^k a pass@1-nél az ügyfelekkel érintkező ügynököknél, és hogyan akadályozhatod meg, hogy az eval környezet félrevezessen.

Eredmény és trajektória: a két dolog, amit pontozol

Az Anthropic 2026 januári útmutatója átvételre érdemes fogalomkészletet ad. A feladat (task) egy tesztesetet jelent bemenetekkel és sikerkritériumokkal; minden próbálkozás egy futtatás (trial). Az értékelő (grader) a futtatás valamely aspektusát pontozza. Az átirat (transcript, más néven trace vagy trajektória) a teljes feljegyzés: kimenetek, eszközhívások, érvelés, köztes eredmények. Az eredmény (outcome) a környezet végállapota. Az ottani példa: egy repülőjegy-foglaló ügynök írhatja, hogy "a járatát lefoglaltuk", de az eredmény az, hogy létezik-e foglalás az adatbázisban.

A τ-bench, az egyik referencia ügynök-benchmark, pontosan így értékel: a beszélgetés végén az adatbázis állapotát összeveti egy annotált célállapottal. Ez a legerősebb egyedi ellenőrzés, amit építhetsz, mert nem az érdekli, mit mondott az ügynök, hanem csak az, hogy mit tett.

Kód-, modell- és emberi értékelők

Minden értékelő vagy az átiratot, vagy az eredményt vizsgálja. Az Anthropic útmutatója három családra osztja őket, és egy jó ügynök-eval mindhármat vegyíti:

A pontszámok kombinálhatók súlyozott összegként egy küszöbhöz mérve, binárisan (mindennek át kell mennie) vagy vegyesen. Üzleti ügynököknél nálam az alapeset: bináris a biztonsági szempontból fontos kódellenőrzéseknél (soha nincs visszatérítés ellenőrzés nélkül), súlyozott minden másnál.

Trajektóriaegyeztetés: strict, unordered, subset, superset

Ha van egy referencia-trajektóriád, a kérdés az, mennyire pontosan kell követnie az ügynöknek. A LangChain nyílt forráskódú agentevals csomagja a négy hasznos választ trajectory_match_mode értékekként nevezi meg:

Az argumentumok egyeztetése külön történik. Alapértelmezésben az agentevals azonos argumentumokat vár; a tool_args_match_mode értéke lehet ignore, subset vagy superset, a tool_args_match_overrides pedig eszközönkénti szabályokat fogad, akár saját összehasonlító függvényt is (például kis- és nagybetűtől független városneveket):

from agentevals.trajectory.match import create_trajectory_match_evaluator

# Refund flow: the agent may look things up freely, but must make these calls.
evaluator = create_trajectory_match_evaluator(
    trajectory_match_mode="superset",
    tool_args_match_overrides={
        "issue_refund": ["order_id"],          # only order_id must match exactly
        "lookup_order": "ignore",              # any lookup arguments are fine
    },
)
result = evaluator(outputs=agent_messages, reference_outputs=reference_messages)
# {'key': 'trajectory_superset_match', 'score': True, 'comment': None}

Más keretrendszerek ugyanezt más nevekkel fedik le. A DeepEval ToolCorrectnessMetric metrikája a várt és a meghívott eszközöket veti össze, alapból név szerint, opcionálisan a bemeneti paraméterek és a kimenet alapján is, a sorrendre és a pontos egyezésre vonatkozó kapcsolókkal. A Ragas kínálja a ToolCallAccuracy (alapból szigorú sorrend, rugalmas móddal), a hívások precizitását és fedését mérő ToolCallF1 és az AgentGoalAccuracy metrikát arra az esetre, ha csak az eredmény számít. Projektenként egy keretrendszert válassz; a fogalmak átvihetők. A DeepEval és a Ragas értékelésemben a kompromisszumokról is írok.

Először az eredményt pontozd, az utat csak az invariánsokra

A trajektóriáknál nagy a kísértés, hogy pontosan azt az utat követeld meg, amelyet te választottál volna. Az Anthropic óv ettől: az ügynökök rendszeresen találnak olyan érvényes megoldásokat, amelyekre az eval tervezője nem számított, ezért "gyakran jobb azt pontozni, amit az ügynök létrehozott, nem az utat, amelyen odajutott". A saját példájuk figyelemre méltó. Az Opus 4.5 egy τ²-bench repülőjegy-foglalási feladatot úgy oldott meg, hogy kiskaput talált a szabályzatban; az eval szerint "elbukott", közben a felhasználónak jobb eredményt adott.

Ezért a trajektória-ellenőrzéseket invariánsokra használom, arra a néhány szabályra, amelynek minden úton teljesülnie kell, a sikert pedig az eredményen mérem. Az invariánsok általában rövidek, és könnyen kifejezhetők kódban:

def check_invariants(calls: list[dict]) -> list[str]:
    """calls: tool calls from the transcript, in order: {"name": ..., "args": {...}}"""
    errors, verified = [], False
    for c in calls:
        if c["name"] == "verify_customer":
            verified = True
        if c["name"] == "issue_refund":
            if not verified:
                errors.append("refund before customer verification")
            if c["args"]["amount"] > 500:
                errors.append("refund above approval limit")
        if c["name"] in {"delete_account", "send_bulk_email"}:
            errors.append(f"forbidden tool: {c['name']}")
    if len(calls) > 25:
        errors.append(f"{len(calls)} tool calls, budget is 25")
    return errors

Ez bináris és olcsó, minden futtatáson lefut, és nem bünteti a kreatív utakat. Az adatbázis elleni eredményellenőrzéssel kombinálva elkapod a két legfontosabb hibát: az ügynök rossz dolgot tett, vagy a jó dolgot tiltott módon tette. Arról, hogy mely műveletekhez kell egyáltalán emberi jóváhagyás, a human in the loop MI-ügynököknél című cikkem szól.

pass@k és pass^k: egy futtatás még nem mérés

Az ügynökök nem determinisztikusak, így egy feladat, amely egyszer átment, a következő futtatáson elbukhat. Ezt két metrika írja le. A pass@k annak valószínűsége, hogy k futtatásból legalább egy sikeres; k növekedésével nő. A pass^k annak valószínűsége, hogy mind a k futtatás sikeres; k növekedésével csökken. Az Anthropic útmutatójának számítása: egy 75%-os futtatásonkénti sikerarányú ügynök három futtatásból mindhármat 0,75³ ≈ 42% valószínűséggel teljesíti.

A τ-bench pontosan emiatt a rés miatt vezette be a pass^k-t. A 2024-es cikkben még az olyan korszerű függvényhívó ügynökök is, mint a gpt-4o, a feladatok kevesebb mint felét oldották meg, a kiskereskedelmi tartományban pedig a pass^8 25% alatt volt. Egy kódoló ügynöknek elég a pass@k, mert egyetlen működő javítás is elég. Egy ügyfélszolgálati ügynöknek nem: minden ügyfél egyetlen futtatást kap. Minden feladatot legalább három-öt alkalommal futtass, és mindkét számot jelentsd.

Izolált környezet, különben hazudik az eval

Az eredményalapú értékeléshez valódi környezet kell: feltöltött adatbázis, sandbox a fájl- és shell-eszközökhöz, mockolt külső API-k. Az Anthropic hangsúlyozza, hogy minden futtatásnak tiszta állapotból kell indulnia, mert a megosztott állapot korrelált hibákat okoz, és felfújhatja a pontszámokat. A példájuk: belső evalokban a Claude egyes feladatoknál tisztességtelen előnyhöz jutott azzal, hogy elolvasta a korábbi futtatások által hátrahagyott git-előzményeket.

• Futtatásonként új seed. Indítsd az adatbázist egy fixture-ből, futtass, vesd össze a célállapottal, aztán dobd el.
• Fagyaszd be az időt és a véletlent, ahol az eszközök függnek tőlük ("a múlt heti rendelések").
• A külvilágot determinisztikusan mockold, de a hibaválaszok maradjanak valósághűek: az időtúllépés, a 429-es és a validációs hiba is része annak, amit tesztelsz.
• A harness legyen azonos az élessel: ugyanaz a rendszerprompt, ugyanazok az eszközleírások, ugyanazok a korlátok. Az Anthropic lényegi megállapítása, hogy a modellt és a harnesst együtt értékeled.

LLM-bírák trajektóriákhoz

Bizonyos minőségeket nagy léptékben csak modell tud pontozni: értelmes tisztázó kérdést tett-e fel az ügynök, udvariasan elmagyarázta-e az elutasítást, észszerű volt-e a terv. Az agentevals tartalmazza a create_trajectory_llm_as_judge függvényt egy alapértelmezett trajektória-pontossági prompttal; a legtöbb eval keretrendszerben van megfelelője. A használat szabályai ugyanazok, mint bármely bírónál, csak szigorúbbak, mert az átiratok hosszúak:

• Dimenziónként egy rubrikapont, mindegyikhez konkrét leírás arról, mi számít sikernek és kudarcnak.
• Adj kiutat a bírónak. Az Anthropic kifejezett "Unknown" választ javasol arra az esetre, ha az átiratból hiányzik az információ, hogy a bíró ne találgasson.
• Többlépéses feladatoknál adj részpontot. Egy ügyfélszolgálati ügynök, amely azonosította a problémát és ellenőrizte az ügyfelet, de a visszatérítés nem sikerült neki, jobb annál, amely azonnal elbukik, és ezt a pontszámaidnak is mutatniuk kell.
• Kalibráld emberekhez egy mintán, mielőtt megbízol a bíróban, és ellenőrizd újra, ha bírómodellt cserélsz.

Képességmérő és regressziós készletek, és honnan jönnek a feladatok

Az Anthropic kétféle készletet különít el. A képességmérő evalok azt kérdezik, mire képes az ügynök, és alacsony sikeraránnyal kell indulniuk, hogy legyen hová fejlődni. A regressziós evalok azt kérdezik, tudja-e még, amit korábban tudott, és 100% közelében kell lenniük. Ahogy a képességmérő feladatok megbízhatóvá válnak, átkerülnek a regressziós készletbe. Ha egy képességmérő készlet a 100%-hoz közelít, már semmit sem mond; az ő példájuk a SWE-bench Verified, ahol a pontszámok 30% körül indultak, a frontier modellek pedig mára 80% fölött járnak.

Az, hogy honnan jönnek a feladatok, többet számít, mint a számuk. Az Anthropic azt tanácsolja, hogy korán kezdj 20-50 egyszerű, valódi hibákból vett feladattal, mert a korai változtatásoknak nagy a hatásuk, és kis minta is kimutatja őket. Az én forrásaim, érték szerinti sorrendben: éles trace-ek, ahol valami félrement (az observability pipeline-odból), a kiadás előtti kézi ellenőrzéseid és az ügyfélszolgálati jegyek. A szintetikus feladatok hézagokat töltenek ki; nem ezekre kell építeni.

Eszközök: hol élnek a trace-ek és az értékelők

Három dologra van szükséged: a teljes trace-ek rögzítésére, egy futtatóra, amely a feladatokat többször végrehajtja izolált környezetben, és egy helyre, ahol a pontszámok időben tárolódnak. Az OpenAI platformja trace grading funkciót kínál, amely a dashboardon pontozza az ügynök-trace-eket, és eval futtatásokká alakítja őket. A nyílt forráskódú keretrendszerek (az agentevals pytest- vagy Vitest-integrációval, a DeepEval, a Ragas, a Promptfoo) a CI-ban futnak. Az olyan observability platformok, mint a Langfuse, az éles trace-eket adatkészletekhez kötik. A választás kevésbé fontos, mint a szokás: minden ügynökváltoztatás lefuttatja a regressziós készletet kiadás előtt, és az ügynökhurok keretei is részei annak, amit ellenőrzöl.

Ellenőrzőlista

1. Az eredményt a környezet állapotához mérd, ne a végső üzenethez.
2. A néhány kötelező szabályt kódban írt invariánsként fogalmazd meg a trajektórián.
3. A referencia-trajektóriákhoz a legengedékenyebb egyeztetési módot használd, amely még elkapja a hibát (superset vagy subset a strict előtt).
4. Minden feladatot három-öt alkalommal futtass; jelentsd a pass@1-et és a pass^k-t.
5. Minden futtatás tiszta, feltöltött, az éleshez hasonló környezetből induljon.
6. Az LLM-bírák dimenziónként egy rubrikaponttal, Unknown opcióval és részpontokkal dolgozzanak, emberekhez kalibrálva.
7. Tarts fenn képességmérő és regressziós készletet; a feladatok lépjenek át közöttük.
8. A feladatokat valódi hibákból merítsd, és hetente olvasd el a sikertelen átiratokat.

A dokumentumokban kereső ügynökök visszakeresési oldaláról a RAG értékeléséről szóló cikk írja le a metrikákat. Ha segítség kell ahhoz, hogy a csapatodnak ügynök-evalokat építs, nézd meg az AI engineering oldalt.

Források

1. Anthropic: Demystifying evals for AI agents (Jan 2026)
2. Yao et al.: τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (2024)
3. Barres et al.: τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment (2025)
4. LangChain: agentevals (GitHub)
5. DeepEval docs: Tool Correctness
6. Ragas docs: Agentic or tool use metrics
7. OpenAI API docs: Trace grading