Az AI-ügynökök értékelése: eszkínhívásoktól a feladatok teljesítéséig

Amikor egy AI-ügynököt élesbe viszünk, a legfontosabb kérdés nem az, hogy a modell „jól hangzik-e”, hanem az, hogy képes-e végrehajtani egy többlépéses munkafolyamot tucatnyi egymásra épülő eszközhívással egy élő környezeten, és helyreállni, ha egy lépés hibára fut. A puszta kimenet nyelvi minőségének pontozása szinte semmit sem mond arról, hogy a feladat valóban befejeződött-e.

Ezért fejlődött az értékelés: a korábbi, egyetlen függvényhívást vizsgáló benchmarkoktól eljutottunk az egész feladat sikerességét vizsgáló rendszerekig, ahol az eszközhívás a lánc ragasztója.

Miért nem elég a hagyományos LLM-benchmark?

A korai mérőrendszerek statikus feladatokra készültek, és elválasztották a modellt az értékelési protokolltól. Az ágensek viszont többlépéses folyamatokban működnek: eszközöket hívnak, hibákat kezelnek és több lépésen át figyelik az eredményt, ezért egyetlen szöveges kimenet nem elegendő.

A Berkeley Function-Calling Leaderboard (BFCL) a funkcióválasztást és az argumentumok pontosságát mérte egy- és többfordulós forgatókönyvekben, de ez csak egyedi hívásokat vizsgál: egy formailag helyes is_resolve_issue() hívás továbbra is kudarcot vallhat, ha az alatta lévő állapotfrissítés kimaradt. Tehát a híváspontosság szükséges, de nem elegendő.

A környezet szintű értékelés felé

A teljes ügynöki értékelés ma már megkövetel egy végrehajtó környezetet, amely futtatja az egyes eszközhívásokat, követi az állapotot a lépések között, és a végén eldönti, hogy a munkát valóban elvégezték-e.

Két értékelési réteg épül erre:

• Lépésszintű (process scoring): adott-e, releváns-e és hasznos-e volt az adott hívás a pillanat állapotához képest?
• Végponti, end-to-end (E2E vagy outcome scoring): csak a végállapotot vizsgálja: például posztolódott-e a visszatérítés, helyesen továbbították-e a jegyet?

A lépésszintű pontozás megmutatja, hol törik meg a lánc — ez hasznos hibakeresésnél és finomhangolásnál. Az E2E viszont azt tükrözi, amit a felhasználó tapasztal; ezért sok termelési kiadásnál az E2E az engedélyezési gate, míg a részletes trace-k a hibakereséshez maradnak.

Mindkét pontszám ugyanannak az objektumnak, a trace-nek két olvasata. A trace egy kísérlet rendezett naplója: a felhasználói üzenet, az egyes lépések és a környezet állapota a kísérlet végén. A process scoring a trace sorait pontozza, az E2E pedig a végállapotot.

Mit mér egy benchmark futás?

Egy eszközhívásos benchmark három dolgot pontoz sorrendben: eldönteni, hogy eszközt kell-e használni; kiválasztani a megfelelő eszközt; és helyesen kitölteni annak argumentumait. Egy modell, amely akkor nyúl eszközhöz, amikor egy direkt válasz nem elég, éppoly hibás, mint amelyik kihagy egy szükséges hívást. A költség és a késleltetés még ezekre jön rá, a hívás részletessége és futamideje határozza őket.

Minden futás egy rögzített hierarchiába szerveződik: Benchmark → Trial → Task → Turn → Step.

• Trial: egy független átjárás a teljes feladatsoron adott konfigurációval.
• Task: egy külön pontozható probléma, egy azonosítóval.
• Turn: egy üzenet-egy válasz határ: a felhasználói üzenet be, az ügynök válasza ki.
• Step: egy atomikus művelet egy turnon belül — általában egy eszközhívás, de lehet tervelemzés vagy végső üzenet is.

A metrikák, amelyeket érdemes követni, három tengelyre esnek: pontosság, részletesség (verbosity) és költség. Néhány kulcsmutató:

• Task success rate = successful_tasks / tasks (pontosság). Ez a kiadási gate: elérte-e a környezet a célállapotot?
• Consistency = sikerességi ráta tartománya 3–5 trial között (pontosság). Egy 90%/74% megoszlás kevésbé megbízható, mint egy stabil 84%.
• Tool-call precision = correct_calls / calls_issued (pontosság). Itt látszanak a kitalált eszköznevek és fölösleges hívások.
• Argument accuracy = correct_args / calls_with_right_tool (pontosság). Különválasztja, ha a rossz API-t hívták, vagy a helyes API-t rosszul töltötték ki.
• Steps per success = steps / successful_tasks (részletesség). Megmutatja, mennyi lépés szükséges egy sikerhez.
• Cost per success = spend / successful_tasks (költség). A tokenek és GPU-seconds csak a sikeres feladat egységében számítanak.

A mutatók párosításai számítanak: például önmagában a sikerességi arány pontértéke nem adja meg a rendszert valódi viselkedését, ha nincs mögötte konzisztencia. A lépésszám gyakran a leginkább változó tengely modellek között ugyanazon a taskon.

A párhuzamos eszközhívás csökkentheti a lépésszámot és a késleltetést, de nem csökkenti a hívásszámot: egy egyfordulatú lépésben négy eszköz hívása még mindig négy hívásnak számít.

Hogyan kell olvasni egy értékelést?

Két benchmark mindkettő azt állíthatja, hogy eszközhívást mér, de az eredmények összehasonlíthatatlanok lehetnek. A legfontosabb különbségeket három tényező magyarázza:

• Task complexity: egyetlen hívás vagy többfordulós tervezés, hibakezelés és állapotkezelés? Egy egyhívásos benchmark nem fed fel, ha egy modell a 8. lépésnél omlik össze egy 15 lépéses folyamatban.
• Statefulness: frissíti-e a környezet az állapotot minden akció után? Az állapotfüggő benchmarkok felhozzák a driftet, kontextusvesztést és a sérült állapotot, amit a statikusok nem érzékelnek.
• Methodology: az executable verification (például DB-frissítés, tesztek átmenete) az aranystandard. Referencia-alapú értékelés fenntartást igényel. Az LLM mint bíró megoldást kínál ott, ahol nincs futtatható ellenőrzés, de ilyen eredményeket mint provizórikusokat kell kezelni az emberi minták validálásáig.

A „contamination” (szennyeződés) problémája túlnőtt a treningadat-szivárgáson: a webes keresést használó ágensek vizsga közben hozzáférhetnek válaszkulcsokhoz, és a publikus adatcsomagok gyorsan bekerülhetnek a pretraining-korpuszba. A privát domain alapú értékelések ezzel szemben kevésbé sérülékenyek.

Példa: egy valódi benchmark trace (SWE-bench Verified)

A publikusan részletezett trace egy valós futásból származik, ahol a feladatsor maga adja az eszközöket, a felhasználói inputot és a befejezési kritériumot.

• Suite: SWE-bench Verified (valódi GitHub-issue-ok, executable test verification)
• Task ID: pytest-dev__pytest-5262 (trial .2, turns 0–4)
• Felhasználói input: „Implement the necessary changes to the repository (/testbed) so that the requirements specified in the issue are satisfied” — az issue lényege: a _pytest.capture.EncodedFile visszaadja a mode értéket "rb+" bináris bufferből, de a write() csak str-t fogad, így külső kód (pl. youtube-dl) összeomlik, ha bájtokat ír.
• Harness: OpenHands agent harness; eszközök: terminal, file_editor, task_tracker, finish; párhuzamos hívás kikapcsolva; repo állapot perzisztál fordulóról fordulóra (valódi fájlrendszer + git).

A runból kivonatolt néhány lépés:

1. Turn 0, terminal(find /testbed -name "capture.py") → visszatér /testbed/src/_pytest/capture.py — valid (a fájl lokálizálása)
2. Turn 1, file_editor(view, capture.py) → a teljes fájl dumpja (400+ sor) — redundant (inefficient)
3. Turn 2, terminal(grep -n "EncodedFile" capture.py) → visszatér 422: return EncodedFile(...), 425: class EncodedFile(object): — recovered (a 2. lépés hatékonysági problémáját korrigálta)
4. Turn 3–4, file_editor(view, view_range=[420,450]/[450,470]) → megmutatja az EncodedFile.init / getattr-et, kiderül, hogy a .mode-t a bináris bufferről delegálja — valid (a gyökérok feltárása)

Az E2E ellenőrzés (tesztek) ÁTMENTEK. E2E score: 1. Lépésszintű pontozás: 3/4 (egy redundáns lépés miatt). Tool-call precision: 3/4. Argument accuracy: 4/4.

A példából látszik, hogy az E2E score jelzi: a tesztek sikeresen ellenőrizték a javítást; a lépésszintű metrikák viszont segítenek megérteni, mely lépések voltak fölöslegesek vagy hibásak.

Miért konvergálnak a benchmarkok az eszközhasználat mérése felé?

A „hívás eszközre” és a „feladat befejezése” közötti különbség elmosódott: a legtöbb általános képességet mérő benchmark ma már az eszközhasználatot is méri, mert a modelleket éles környezetben eszközökkel együtt futtatják. Egy benchmark, amely megtagadja az eszközhozzáférést, egy olyan képességet mér, amit senki sem üzemeltet.

Néhány ismert példa:

• HumanEval futtatja a generált Python kódot unit tesztekkel (executable verification), de nincs eszközhívás és környezet, amelyen a modell munkát végezne.
• SWE-bench: egy valódi GitHub-issue megoldásához kódot kell módosítani és át kell menni a tesztjein — a pálya alatt végig eszközhívások sorozata zajlik.

Az akadémiai benchmarkok általában a modell elméleti képességét mérik, míg az ipari/vállalati benchmarkok azt vizsgálják, hogy a modell képes-e a konkrét vállalati feladatok elvégzésére a vállalati API-k és szabályok szerint. Minél közelebb áll egy benchmark a termeléshez, annál nagyobb súllyal érdemes figyelembe venni az eredményét.

Példaként: NVIDIA Nemotron 3.5 Lightning elemzése

A bemutatott számok szerint a Nemotron 3.5 Lightning kiadott feladatsorait feladat-lezárás és időigény szerint érdemes értelmezni, nem csak izolált híváspontosságként. Néhány adat a publikált eredményekből:

• Banking szekció: többfordulós banki beszélgetésekben pontozzák a visszatérítési folyamatok kiterjesztett nyomon követését — tehát nem egyetlen hívásra, hanem a teljes trace-re adnak értéket.
• GDPval-AA v2: valódi ügynöki munkákat pontoz páros összehasonlítással, LLM-bírók panelje alapján, Elo-t egy 1 000 pontos ember-szakértő alaphoz rögzítve — emberi validációval alátámasztva.
• PinchBench: a Nemotron 3.5 Lightning 86% pontosságot ér el, miközben 10 000 feladatot 30%-kal gyorsabban fejez be, mint a Qwen3.6 35B hasonló pontosság mellett. Ez azt mutatja, hogy egy hatékonyabb, gyorsabban befejező modell jobban teljesíthet a valós feladatokban, mint egy, amely magas izolált pontosságot ér el, de sok lépést és tokent fogyaszt.

Fontos megjegyezni, hogy a publikus eredmények jó jelzést adnak, de nem szabad kizárólagos kiadási gate-ként használni őket: a modell adaptálása a konkrét feladatra és a harness beállítása továbbra is kulcsfontosságú.

Hogyan benchmarkold a saját terhelésedet?

• Állíts fel egy publikus alsó korlátot: futtass egy publikált agentic suite-ot, és rögzítsd a sikerességi arányt és annak tartományát 3–5 trialon.
• Építs domain-specifikus értékelést a saját jegyeidből, trace-eidből és API-idból. A kapuzásnál a környezet állapotára (adatbázis sor, merge-elt PR, lezárt ticket) alapozz, ne csak egy bíró által adott végső üzenet értelmezésére.
• Adaptáld a modellt és a harness-t a saját eloszlásodra.
• Mérd újra: sikerességi arány, konzisztencia, lépésszám sikerenként és költség sikerenként. Tartsd meg a lépésszintű trace-ket hibakereséshez.
• Ellenőrizd a környezeti következményeket futtatható ellenőrzésekkel, használd a bírókat a nyelvi pontozáshoz, és a tool-call precision és argument accuracy segítségével találd meg, hol törik meg a lánc.

A Nemotron publikált számait reprodukálhatod a reproducibility dokumentációk alapján: elérhető súgók és súlyok Hugging Face-en, illetve NIM-guiderek a build.nvidia.com-on.

Következtetés

Az eszközhívás ma már az LLM-benchmarking alapja: az értékelések építésére, olvasására és értelmezésére való képesség elengedhetetlen ahhoz, hogy megalapozott döntést hozzunk arról, melyik modell és konfiguráció illeszkedik a saját felhasználási esetünkhöz.

További frissítésekért és forrásokért érdemes követni az NVIDIA Nemotronhoz kapcsolódó kommunikációs csatornákat és dokumentációkat.