Az NVIDIA szerint így érdemes mérni az AI-ügynökök valódi teljesítményét

A különálló eszközhívások mérése kevés az ügynököknél

Az NVIDIA Developer 2026. szeptember 21-én megjelent írása szerint az AI-ügynökök értékelése azért változott meg, mert ezek a rendszerek már nem egyetlen választ adnak, hanem több lépésen keresztül eszközöket hívnak meg, hibákat kezelnek, és egy élő környezet állapotából dolgoznak.

A cikk szerint a korábbi, statikus feladatokra épülő LLM-tesztek nem fedik le ezt a működést. Egy ügynök esetében egyetlen kimeneti szöveg nem mutatja meg, hogy a rendszer végig tudott-e vinni egy munkafolyamatot. A Berkeley Function-Calling Leaderboard, röviden BFCL, a függvényválasztást és az argumentumok pontosságát méri egyszeres és többfordulós helyzetekben, de az NVIDIA szerint ez csak az egyes hívásokat értékeli.

A cikk példája szerint egy érvényes issue_refund hívás még nem jelenti azt, hogy a visszatérítés ténylegesen megtörtént, ha a szükséges ellenőrzések vagy frissítések kimaradtak. A híváspontosság ezért szükséges, de nem elégséges feltétel.

A végső állapot lett a döntő mérce

Az NVIDIA szerint a teljes ügynöki értékeléshez olyan futtatható környezet kell, amely végrehajtja az eszközhívásokat, lépésről lépésre követi az állapotot, majd a végén ellenőrzi, hogy a munka elkészült-e. Erre két pontozási réteg épül.

Az egyik a lépésszintű folyamatpontozás, amely azt vizsgálja, hogy az adott hívás az adott állapotban érvényes, releváns és hasznos volt-e. A másik a végponttól végpontig tartó eredménypontozás, amely nem az útvonalat nézi, hanem a végső állapotot: például megtörtént-e a visszatérítés, vagy megfelelő helyre került-e a hibajegy.

A cikk szerint a két réteg ugyanannak az objektumnak, a trace-nek a két olvasata. A trace egyetlen próbálkozás rendezett naplója: tartalmazza a felhasználói üzenetet, az egyes lépéseket és azt a környezeti állapotot, amelynél a próbálkozás leáll. A folyamatpontozás a sorokat értékeli, a végponttól végpontig tartó pontozás pedig a végső állapotot.

Az NVIDIA megfogalmazása szerint a lépésszintű pontozás abban segít, hogy kiderüljön, hol törik meg a lánc, ami hibakeresésnél vagy finomhangolási célok kijelölésénél fontos. A felhasználók viszont a végeredményt érzékelik, ezért a cikk szerint a legtöbb éles üzemű értékelésnél a kiadás kapuja a végponttól végpontig tartó mérés.

Három fő tengely: pontosság, bőbeszédűség és költség

Az NVIDIA leírása alapján egy eszközhívásos benchmark először azt méri, hogy a modell felismeri-e, mikor kell eszközt használnia, majd azt, hogy a megfelelő eszközt választja-e, végül pedig azt, hogy helyesen tölti-e ki az argumentumokat. A költség és a késleltetés ehhez kapcsolódik, a hívások bőbeszédűsége és futásideje alapján.

A futások rögzített hierarchiában épülnek fel: benchmark, trial, task, turn és step. A trial egy független végigfuttatás az egész feladatkészleten, azonos konfiguráció mellett. A task egy önállóan pontozható feladatpéldány, a turn egy üzenetváltási határ, a step pedig egy atomi művelet, például eszköz vagy parancs meghívása, illetve eszköz nélküli kimenet, például terv vagy végső üzenet.

A cikkben felsorolt alapmutatók három tengelyre rendeződnek: pontosság, bőbeszédűség és költség. A pontossághoz tartozik a feladatsiker aránya, a 3 és 5 közötti próbafutáson mért sikerarány konzisztenciatartománya, az eszközhívási precizitás és az argumentumpontosság. A bőbeszédűséget a sikerre jutó lépések száma, a költséget pedig a sikerre jutó kiadás jelzi.

Az NVIDIA hangsúlyozza, hogy ezeket párokban érdemes jelenteni. A sikerarány konzisztencia nélkül csak pontbecslés egy sztochasztikus rendszerről: a cikk példája szerint egy 90 százalékos, majd 74 százalékos eredmény nem ugyanaz, mint egy stabil 84 százalék. A párhuzamos eszközhívás csökkentheti a lépésszámot és a késleltetést, de a hívások számát nem: ha egyetlen lépésben négy eszköz indul el, az továbbra is négy hívás.

Miért nem mindig összevethetők a benchmarkok

Az NVIDIA szerint két benchmark egyaránt állíthatja, hogy eszközhívást mér, az eredményeik mégsem feltétlenül hasonlíthatók össze. A különbséget főként három tényező magyarázza: a feladat összetettsége, a környezet állapottartása és az alkalmazott módszertan.

Egy egyfordulós, egyetlen eszközt igénylő teszt nem mutatja meg, hogy egy modell összeomlik-e egy tizenöt lépéses folyamat nyolcadik lépésénél. Az állapottartó benchmarkok olyan hibákat is felszínre hoznak, mint az elcsúszás, a kontextusvesztés vagy a sérült állapot, amelyeket a statikus tesztek nem látnak.

A módszertannál a cikk az executable verification, vagyis a futtatható ellenőrzés megközelítését nevezi arany standardnak: például frissült-e az adatbázis, vagy átmentek-e a tesztek. A referenciaalapú értékeléshez karbantartott, annotált válaszkészlet kell. Az LLM-as-a-Judge ott pótolhat hiányt, ahol nincs futtatható ellenőrzés, de az NVIDIA szerint az ilyen pontszámokat ideiglenesnek kell tekinteni, amíg mintán nem validálták őket emberi értékelésekkel.

A cikk a szennyeződés kockázatát is említi. Ez már nemcsak a tanítóadatokba szivárgó tesztadatokat jelenti, hanem élő változatokat is, például amikor webes keresést használó ügynökök értékelés közben válaszkulcsokat találnak meg, vagy amikor a Hugging Face-en lévő adathalmazokat gyorsan újra begyűjtik előtanítási korpuszokba. A privát, szakterületi értékelések ezt az NVIDIA szerint azzal kezelik, hogy nem kaparhatók le.

Mit jelent ez a vállalati felhasználóknak

Az NVIDIA következtetése szerint vállalati bevezetésnél a döntést olyan szakterületi értékelésekre kell építeni, amelyek valódi hibajegyekből és API-kból készülnek, és nem elszigetelt híváspontosságon, hanem a környezet állapotán alapulnak. Ez azt jelenti, hogy az ügynököt azon kell mérni, eljut-e a kívánt végállapotig a saját munkakörnyezetében.

A cikk példaként a Nemotron 3.5 Lightning modellt említi, amely az NVIDIA összefoglalója szerint 86 százalékos pontosságot ért el a PinchBench benchmarkon, miközben a feladatokat 30 százalékkal gyorsabban fejezte be, mint az összehasonlítható modellek. A forrás a következő lépések között a reprodukálhatósági dokumentáció áttekintését, a modell kipróbálását a build.nvidia.com oldalon, valamint a Nemotron 3.5 Lightning éles telepítéséhez a NIM útmutató követését jelöli meg.

A felhasználói oldalról a cikk üzenete egyértelmű: az ügynökök értékelésében a hangzatos válaszoknál fontosabb, hogy a rendszer végrehajtsa a teljes munkaláncot, kezelje a hibákat, és a végén ellenőrizhetően elérje a célt.