> Hogyan értékeld az MI-ügynököket: eredmény- és trajektória-értékelők, egyeztetési módok, pass^k, izolált környezet és megbízható LLM-bírák. > > Web page: https://balazscsorba.com/hu/blog/evaluating-ai-agents-trajectories · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/evaluating-ai-agents-trajectories.md) · [Deutsch](https://balazscsorba.com/de/blog/evaluating-ai-agents-trajectories.md) > Author: Balázs Csorba · Published: 2026-10-16 · Keywords: evaluating AI agents, agent trajectory evaluation, agent evals, tool call accuracy, trajectory match evaluator, pass^k metric, tau-bench, LLM as a judge for agents, agent regression testing, outcome vs trajectory evaluation, agentevals, tool correctness metric [Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés # MI-ügynökök értékelése: trajektóriák, eredmények és megbízhatóság pontozása Hogyan értékeld az MI-ügynököket: eredmény- és trajektória-értékelők, egyeztetési módok, pass^k, izolált környezet és megbízható LLM-bírák. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 16.·9 perc olvasás - Agent evals - Trajectories - Tool calling - pass^k - LLM-as-judge ![Eszközhívásokból álló ügynök-trajektória kétszer pontozva: a trajektória-értékelő a sorrendet és az argumentumokat, az eredményértékelő az adatbázist veti össze a célállapottal.](https://balazscsorba.com/images/blog/evaluating-ai-agents-trajectories/cover.webp?v=d4f9ed74c3) ## A lényeg röviden - Az eredményt a környezet állapotához mérd; az ügynök végső üzenete a siker leggyengébb jele. - A trajektória-ellenőrzést a minden úton kötelező invariánsokra használd, és ne követelj meg egyetlen pontos utat, mert az ügynökök érvényes alternatívákat találnak. - Az agentevals strict, unordered, subset és superset trajektóriaegyeztetést és eszközönkénti argumentumszabályokat kínál; a DeepEval és a Ragas hasonlót fed le. - A pass^k, vagyis hogy mind a k futtatás sikeres, megmutatja a megbízhatatlanságot, amelyet a pass@k elrejt; 75%-os futtatásonkénti aránynál a háromból három kb. 42%. - Minden futtatás tiszta környezetből induljon, az LLM-bírákat kalibráld emberekhez, a feladatokat pedig 20-50 valódi hibából építsd. Ezen az oldalon 1. [Eredmény és trajektória: a két dolog, amit pontozol](https://balazscsorba.com/#outcome-vs-trajectory) 2. [Kód-, modell- és emberi értékelők](https://balazscsorba.com/#three-kinds-of-graders) 3. [Trajektóriaegyeztetés: strict, unordered, subset, superset](https://balazscsorba.com/#trajectory-matching) 4. [Először az eredményt pontozd, az utat csak az invariánsokra](https://balazscsorba.com/#grade-outcomes-not-paths) 5. [pass@k és pass^k: egy futtatás még nem mérés](https://balazscsorba.com/#pass-at-k-vs-pass-hat-k) 6. [Izolált környezet, különben hazudik az eval](https://balazscsorba.com/#isolated-environments) 7. [LLM-bírák trajektóriákhoz](https://balazscsorba.com/#llm-judges-for-trajectories) 8. [Képességmérő és regressziós készletek, és honnan jönnek a feladatok](https://balazscsorba.com/#capability-and-regression-suites) 9. [Eszközök: hol élnek a trace-ek és az értékelők](https://balazscsorba.com/#tooling) 10. [Ellenőrzőlista](https://balazscsorba.com/#checklist) 11. [Források](https://balazscsorba.com/#sources) Cikk meghallgatása 0:000:00 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](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) 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. A trajektóriát azokra a szabályokra pontozd, amelyeknek útközben teljesülniük kell, az eredményt pedig arra, ami ténylegesen megváltozott. A végső üzenet a három közül a legkevésbé megbízható. ## 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: Értékelő Jellemző ellenőrzések Erősségek Gyengeségek tagchildren Eredmény ellenőrzése, használt eszközhívások és paramétereik, lépésszám, tokenhasználat, string- és regex-egyezés, tesztek Gyors, olcsó, objektív, reprodukálható Törékeny az érvényes változatokkal szemben; kevés árnyalat tagchildren Rubrikás pontozás, természetes nyelvű állítások, páros összehasonlítás, referencia alapú értékelés Rugalmas, kezeli a nyitott kimenetet Nem determinisztikus, drágább, emberekhez kell kalibrálni tagchildren Szakértői átnézés, szúrópróbák, A/B tesztek Aranystandard, megfelel a szakértői ítéletnek Lassú és drága; a többiek kalibrálására használd 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](https://github.com/langchain-ai/agentevals) csomagja a négy hasznos választ `trajectory_match_mode` értékekként nevezi meg: Mód Akkor megy át, ha Mire való tagchildren Ugyanazok az üzenetek, ugyanabban a sorrendben, ugyanazokkal az eszközhívásokkal (az üzenetszöveg eltérhet) Folyamatok, ahol a sorrend maga a szabály: előbb ellenőrzés, aztán visszatérítés tagchildren Ugyanazok az eszközhívások, tetszőleges sorrendben Információgyűjtés, ahol minden forrást meg kell nézni tagchildren Az ügynök nem hívott a referencián túli eszközt Védelem a felesleges, drága vagy kockázatos hívások ellen tagchildren Az ügynök legalább a referencia eszközeit meghívta Kötelező lépések, további lekérdezések megengedettek 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](https://balazscsorba.com/hu/tools/deepeval) és a [Ragas](https://balazscsorba.com/hu/tools/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](https://balazscsorba.com/hu/blog/human-in-the-loop-ai-agents) 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. Ugyanaz az ügynök a pass@k szerint szinte tökéletes, a pass^k szerint megbízhatatlan. Az ügyfelekkel érintkező ügynököket a második alapján kell megítélni. 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](https://balazscsorba.com/hu/blog/agent-observability-opentelemetry)), 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. **Olvasd el az átiratokat** Egyetlen metrika sem helyettesíti a sikertelen futtatások elolvasását. Az Anthropic kritikus készségnek nevezi: egy elbukott átiratból kiderül, hogy az ügynök valóban hibázott-e, vagy az értékelőd utasított el egy érvényes megoldást. Szánj rá heti egy órát, és az értékelőket ugyanolyan gyakran javítsd, mint a promptokat. ## 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](https://balazscsorba.com/hu/tools/promptfoo)) a CI-ban futnak. Az olyan observability platformok, mint a [Langfuse](https://balazscsorba.com/hu/tools/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](https://balazscsorba.com/hu/blog/agent-loop-explained) 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](https://balazscsorba.com/hu/blog/rag-evaluation-metrics) 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](https://balazscsorba.com/hu/expertise/ai-engineer) oldalt. ## Források 1. [Anthropic: Demystifying evals for AI agents (Jan 2026)](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) 2. [Yao et al.: τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (2024)](https://arxiv.org/abs/2406.12045) 3. [Barres et al.: τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment (2025)](https://arxiv.org/abs/2506.07982) 4. [LangChain: agentevals (GitHub)](https://github.com/langchain-ai/agentevals) 5. [DeepEval docs: Tool Correctness](https://deepeval.com/docs/metrics-tool-correctness) 6. [Ragas docs: Agentic or tool use metrics](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/agents/) 7. [OpenAI API docs: Trace grading](https://platform.openai.com/docs/guides/trace-grading) ## Gyakori kérdések Mi a trajektória-értékelés MI-ügynököknél? A trajektória-értékelés azokat a lépéseket pontozza, amelyeket az ügynök megtett: mely eszközöket hívta meg, milyen sorrendben és milyen argumentumokkal. Kiegészíti az eredményértékelést, amely a környezet végállapotát vizsgálja, például hogy létezik-e visszatérítési rekord. A trajektóriát főleg a minden úton kötelező szabályokra érdemes használni. Mi a különbség a pass@k és a pass^k között? A pass@k annak valószínűsége, hogy k próbálkozásból legalább egy sikeres, ezért k növekedésével nő. A pass^k annak valószínűsége, hogy mind a k sikeres, ezért csökken. Kódoló ügynököknél elég a pass@k, mert egyetlen működő javítás is elég; az ügyfelekkel érintkező ügynököket a pass^k alapján kell megítélni, mert minden ügyfél egyetlen próbálkozást kap. Megköveteljen-e az ügynök-eval egy pontos eszközhívási sorrendet? Csak ott, ahol a sorrend maga a szabály, például az ügyfél ellenőrzése a visszatérítés előtt. Máshol lazább módokat, például supersetet vagy subsetet használj, vagy az eredményt pontozd. Az Anthropic beszámol egy esetről, amikor egy modell az eval szerint elbukott, mert olyan kiskaput talált a szabályzatban, amely jobb eredményt adott a felhasználónak. Hány feladat kell az ügynök értékelésének elkezdéséhez? Az Anthropic szerint 20-50 egyszerű, valódi hibákból vett feladat jó kezdet, mert a korai változtatásoknak nagy a hatásuk, amelyet kis minta is kimutat. Minden feladatot többször futtass, és bővítsd a készletet, ahogy az ügynök érik. Használhatok LLM-et bíróként az ügynökátiratokhoz? Igen, olyan minőségekre, amelyeket kód nem tud ellenőrizni, például hogy értelmes volt-e egy tisztázó kérdés. Dimenziónként egy rubrikapontot használj, adj a bírónak Unknown lehetőséget, többlépéses feladatoknál adj részpontot, és egy mintán kalibráld emberi pontozáshoz. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [Strukturált kimenet JSON Schemával: mit fed le a garancia, és mit nem](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm) - [LLM-modellmigráció regresszió nélkül: elavulás, evalok, árnyékforgalom](https://balazscsorba.com/hu/blog/llm-model-migration-regression-testing) - [Szemantikus gyorsítótár LLM-alkalmazásokhoz: mikor biztonságos újrahasznosítani a válaszokat, és mikor nem](https://balazscsorba.com/hu/blog/semantic-caching-llm-responses) - [Saját LLM-üzemeltetés a GDPR miatt: mikor kell és mibe kerül](https://balazscsorba.com/hu/blog/self-hosted-llm-gdpr-cost) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)