Honnan tudod, hogy jól működik az AI ügynököd? Mérés a gyakorlatban

Mit jelent az, hogy egy AI ügynök jól működik?

Akkor működik jól, ha egy előre rögzített kérdéskészleten mérhetően és megismételhetően teljesíti a feladatát. A demó erre nem bizonyíték: ott öt kérdés van, és mind az ötöt a fejlesztő választotta ki. Az éles rendszer ezerszám kap olyan bemenetet, amire senki nem készült fel. A különbség egyetlen számban látszik: mekkora a feladat-teljesítési arány kétszáz ismert eseten.

A magyar piacon ez a mérési réteg gyakorlatilag hiányzik. Végignéztük tizenkét magyar AI-ügynökség publikus anyagát, és egyikük sem ír arról, hogyan méri a saját rendszere minőségét. Van ár, van technológialista, van esettanulmány. Nincs sem eval-készlet, sem hallucináció-arány, sem regressziós teszt. Ezt a hiányt szerintem nem véletlen, hanem kényelmes: amit nem mérsz, azt nem is kell megvédened.

A MIT Project NANDA 2025 nyári felmérése 300-nál több bejelentett bevezetést, 52 interjút és 153 vezetői választ dolgozott fel. A 95%-os szám mögött nem gyenge modellek állnak, hanem az, hogy a rendszer nem tanul a javításokból, két munkamenet között elfelejti a kontextust, és kívül esik azon, ahol a munka zajlik. Mind a három hiba mérhető lenne. Ugyanez a kutatás azt is mérte, hogy belső szakértő és külső partner együtt 67%-os sikerrátát hoz, a csak belső IT-vel épített projekt 22%-ot.

A Gartner 2025. június 25-i előrejelzése három okot nevez meg a leállításokra: kicsúszó költség, tisztázatlan üzleti érték, elégtelen kockázatkezelés. Mind a három olyan, amit egy működő mérési rendszer hetekkel előbb kimutat, mint a vezetői türelemvesztés.

Hogyan állítasz össze egy golden datasetet?

A golden dataset olyan esetek gyűjteménye, ahol tudjuk, mi a helyes válasz. Minden elem három részből áll: a bemenet, az elvárt kimenet, és az elfogadási kritérium, ami leírja, mitől számít jónak a válasz. Ez a készlet lesz a rendszer szerződése önmagával. Minden későbbi mérés ehhez képest mér.

Honnan jönnek az esetek

Ne a fejlesztő találja ki őket. A legjobb forrás a valós forgalom: egy ügyfélszolgálati rendszernél a beérkezett levelek, egy dokumentumfeldolgozónál a tavalyi számlák, egy belső tudásbázisnál a kollégák tényleges kérdései. Ha a rendszer még nem él, a szakértő kollégák egy órás közös ülésen össze tudnak dobni nyolcvan valódi kérdést, ez tapasztalatunk szerint elég a nulladik verzióhoz.

Az arányokra van egy egyszerű ökölszabály, amit használunk. A készlet fele legyen tipikus, mindennapi eset. Negyede legyen a ritka, de fontos, tehát a szabálytalan formátum, a hiányos adat, a kétértelmű kérdés. Tizede legyen olyan, amire a helyes válasz az, hogy nem tudom vagy embert kérek. A maradék pedig kifejezetten támadás: prompt injection kísérlet, kérés a rendszer utasításainak kiadására, olyan adat kérése, amihez a felhasználónak nincs joga.

Hány elem és ki írja alá

80–150 esettel érdemes indulni, és fél év éles üzem után jellemzően 300–500 lesz belőle. Ennél nagyobb készlettel a futási idő és a modellszámla kezd fájni, viszont a hozzáadott információ egyre kevesebb. Az elvárt választ mindig a szakterületi kolléga hagyja jóvá, nem a fejlesztő. Ez a lépés az, amit a projektek háromnegyede kihagy, és utána hónapokig vitatkoznak arról, hogy a rendszer hibázott-e.

Tarts vissza a készletből 20–30 esetet, amit soha nem használsz fejlesztés közben. Ez a befagyasztott holdout. Ha csak azon a készleten javítasz, amit látsz, előbb-utóbb arra fogsz optimalizálni, a holdout pedig megmutatja, mennyi a valódi javulás.

Mikor frissítsd

Havonta egyszer, plusz minden incidens után azonnal. Ha egy felhasználó talál egy hibás választ, az az eset még aznap kerüljön be a készletbe az elvárt kimenettel együtt. Így a hibából regressziós teszt lesz, és ugyanaz a hiba nem tud kétszer kijutni. Ez a legolcsóbb minőségi intézkedés, amit ismerek, és nagyjából senki nem csinálja.

Milyen metrikák mutatják meg, hogy jó-e az ügynök?

Hét számot érdemes együtt nézni. Négy a minőségről szól, három a működési költségről. Egyikük sem elég önmagában: egy 99%-os feladat-teljesítés is használhatatlan, ha kérésenként 40 másodperc és 80 forint. Az alábbi küszöbök a mi alapértelmezéseink magyar KKV- és középvállalati projektekben, nem iparági szabvány.

Feladat-teljesítési arány

A legfontosabb szám, és a legkönnyebb elrontani. A definíció azon áll vagy bukik, mit írsz az elfogadási kritériumba. Ha az „a válasz tartalmazza a helyes összeget”, akkor gépileg ellenőrizhető. Ha az „a válasz hasznos”, akkor mérhetetlen. Minden esethez konkrét, ellenőrizhető feltétel kell. Többlépéses ügynöknél érdemes szétbontani a részlépésekre is, mert így derül ki, hogy a hetedik lépésnél bukik minden futás fele.

Hallucináció-arány

Az a válasz hallucinál, ami olyan tényt állít, ami sem a megadott forrásokban, sem az elvárt kimenetben nem szerepel. RAG-nál ez viszonylag jól mérhető, mert megvan a kontextus, amihez képest ellenőrzöl. Nyílt végű generálásnál nehezebb, ott a szakértő címkéz. Mi mondatonként számoljuk, nem válaszonként: egy húszmondatos összefoglaló egyetlen kitalált dátummal ugyanúgy rossz, mint egy teljesen hibás válasz, de a válaszszintű számolás ezt elfedi.

Forrás-pontosság RAG-nál

Két külön dolgot mérj. Az egyik, hogy a keresés visszahozta-e egyáltalán a releváns szövegrészt (retrieval recall). A másik, hogy a modell a helyes forrásra hivatkozik-e a válaszban. A kettő gyakran szétválik: a rendszer megtalálja a jó dokumentumot, aztán egy másikat idéz. Az Anthropic saját mérésében a sima beágyazásos keresés 5,7%-os hibaaránya kontextualizált embeddinggel 3,7%-ra, kontextualizált BM25-tel kiegészítve 2,9%-ra, rerankinggel 1,9%-ra esett. Ha a te rendszered ennél sokkal rosszabb, a probléma nagy eséllyel a keresésben van, nem a modellben.

Emberi felülbírálati arány

Ez az egyetlen metrika, amit éles üzemben ingyen kapsz, ha a folyamatban van jóváhagyási lépés. Azt méri, hányszor nyúl bele a kolléga a kimenetbe. Az abszolút érték kevésbé fontos, mint a trend. Ha három hónap alatt nem csökken, a rendszer nem tanul, és a jóváhagyó előbb-utóbb rá fog kattintani mindenre olvasás nélkül. Ez utóbbi a legveszélyesebb állapot, mert a papíron meglévő emberi kontroll ilyenkor már nem létezik.

Késleltetés és költség kérésenként

Átlag helyett p95-öt nézz. Egy 2 másodperces átlag mögött simán lehet 25 másodperces p95, és a felhasználó azt fogja megjegyezni. A költségnél a lépésszám dönt, nem a modell választása: az Anthropic mérésében egy Drive-ból Salesforce-ba másoló feladat 150 000 tokenről 2 000-re esett, amikor eszközhívás-sorozat helyett kódvégrehajtás lett belőle. A hivatalos Anthropic-árlista szerint a Claude Sonnet 5 2 USD bemeneti és 10 USD kimeneti token millióanként, a cache-találat a bemeneti ár tizede, a Batch API pedig mindkét oldalon felez. Ezek a tételek a trace-szintű költségbontásban látszanak, nem a havi számlán.

Eszközhívási hibaarány

Ha az ügynök API-kat hív, külön számold a rossz paraméterrel indított hívásokat, a sémasértéseket és a szolgáltatói hibákat. Sémasértésnek nulla a tűréshatára, mert azt strukturált kimenettel és séma-kényszerítéssel meg lehet szüntetni. A rossz paraméterezés viszont modellminőség kérdése, és jól jelzi, ha egy eszköz leírása félreérthető. A legtöbb esetben egy jobb tool-leírás többet javít, mint egy drágább modell.

Mi az az eval-harness, és mikor futtasd?

Az eval-harness egy script, ami végigfuttatja a golden datasetet a rendszeren, pontozza a válaszokat, és összeveti az eredményt az előző kiadáséval. Minden prompt-, modell-, retrieval- és eszközváltozás előtt lefut, a CI-ben, és megbukhat a build tőle. Ez a különbség a mért és a remélt minőség között.

CASES = load_jsonl("golden/ugyfelszolgalat_hu_v7.jsonl")   # 140 eset

for case in CASES:
    for _ in range(3):                        # nemdeterminizmus: 3 futas
        out = agent.invoke(case["input"], model=PINNED_MODEL)

        assert_hard(out.schema_valid)         # kemeny: sema, PII, tool-hivas
        assert_hard(out.no_pii_leak)
        assert_hard(out.steps <= MAX_STEPS)

        scores.add(
            grounded = judge_grounded(out.text, case["context"]),
            correct  = rubric_or_exact(out.text, case["expected"]),
            cost_usd = out.usage.cost,
            latency  = out.latency_ms,
        )

report = aggregate(scores)                    # atlag + p95 + szoras
gate(report, baseline="v6", tolerance=0.02)   # 2 pontnal nagyobb eses = bukas

Miben más ez, mint egy unit teszt

A klasszikus unit teszt determinisztikus: adott bemenetre pontosan egy helyes kimenet van, és bármilyen eltérés bukás. Nyelvi modellnél a kimenet eloszlás, nem érték. Ugyanaz a kérdés kétszer futtatva két különböző, egyaránt helyes választ adhat. Ezért a tesztelés logikája is más.

A nemdeterminizmust két rétegre bontva lehet kezelni. Az egyik réteg kemény, gépi ellenőrzés, ahol nincs tűrés: a JSON séma érvényes, nem szivárgott ki személyes adat, a lépésszám a plafon alatt maradt, meghívta-e a kötelező eszközt. Ez determinisztikusan eldönthető, és bármelyik sérülése azonnali bukás. A másik réteg pontszám, ahol a tűrés a lényeg: ha az előző kiadás 0,91-et hozott, és most 0,88, az bukás, ha 0,905, az elfogadható zaj. A tűréshatárt abból számold, hogy mekkora szórást mértél ugyanazon a készleten két egymás utáni futásban.

Mikor bízhatod egy másik modellre az értékelést?

Akkor, ha a feladat nyelvi ítélet, és előtte megmérted, mennyire egyezik a bíró emberi címkékkel. Alátámasztottság, hangnem, formai megfelelés, utasításkövetés: ezekben egy erős modell jól ítél. Numerikus helyesség, jogszabályi megfelelés, szakmai korrektség: ezekben nem, mert ugyanaz a tudáshiány van benne, ami a mért rendszerben.

Ahol az LLM-bíró jól működik

• Alátámasztottság ellenőrzése, ha a bíró megkapja a forrásszöveget és azt kell eldöntenie, hogy a válasz minden állítása levezethető-e belőle.
• Rubrika alapú pontozás referenciaválasszal, ahol a bíró azt nézi, a válasz lefedi-e a referencia kulcselemeit.
• Formai és stílusbeli megfelelés, például hogy a válasz magázódik-e, elfér-e a hosszkorláton, tartalmazza-e a kötelező jogi mondatot.
• Két kimenet páros összehasonlítása, ami stabilabb, mint abszolút pontszámot kérni.

Ahol megbukik

• Számolás, dátumlogika, mértékegység. Ezt determinisztikus kóddal ellenőrizd, ne modellel.
• Saját kimenet értékelése. A modellek hajlamosak a saját fogalmazásukat előnyben részesíteni, ezért a bíró soha ne ugyanaz a modell legyen, amelyik a választ adta.
• Tízfokú skálák. Használj kétértékű vagy háromértékű ítéletet, mert a finom skálán az egyezés emberi címkékkel gyorsan romlik.
• Magyar nyelvi árnyalat. Erre nincs publikus mérési alapunk, ezért itt különösen kell az emberi validáció.

Hogyan validáld magát a bírót

Végy 50–100 esetet a golden datasetből, és címkéztesd fel emberrel, ugyanazzal a rubrikával, amit a bírónak adnál. Futtasd le a bírót, számold ki az egyezési arányt, és nézd meg külön a hamis pozitívokat, tehát azokat, ahol a bíró elfogadott egy rossz választ. Ez a veszélyesebb hibatípus. 80% alatti egyezésnél a bíró használhatatlan arra a feladatra. A bíró promptját és modelljét ugyanúgy verziózd, mint a rendszerét, és a validációt futtasd újra, valahányszor bármelyik változik.

Az Anthropic ügynök-tervezési ajánlásában szereplő evaluator-optimizer minta ugyanezt a logikát használja futásidőben: egy modell generál, egy másik értékel, és a visszajelzés alapján javul a kimenet. Ugyanaz az ajánlás mondja ki azt is, hogy a legtöbb feladatra az előre kódolt munkafolyamat jobb, mint az autonóm ügynök. Ezt a mérés is alátámasztja: kevesebb szabadságfok mellett a szórás kisebb, tehát a rendszer kiszámíthatóbb.

Hogyan figyeled meg az ügynököt éles üzemben?

Az eval offline fut ismert válaszokkal, a megfigyelés éles forgalmon fut ismert válaszok nélkül. Ott közvetett jelekre támaszkodsz: eszközhívási hibák, emberi felülbírálás, hüvelykujj-visszajelzés, késleltetési kiugrás, költségugrás. Minden futás nyoma trace-ként eltárolódik, és a gyanús trace-ekből lesznek az új eval-esetek.

A három árlap nem hasonlítható össze közvetlenül, mert a Langfuse „unit”, a LangSmith „trace” és a Braintrust „score” nem ugyanaz a mértékegység, és az átváltás nem publikus. Ajánlathoz saját volumenbecslés kell. A mi alapértelmezésünk magyar és EU-s ügyfélnél az önállóan üzemeltetett Langfuse, mert a licencdíja nulla, és az adat nem hagyja el a saját infrastruktúrát. Ha a stack amúgy is LangGraph, a LangSmith kényelmesebb, de nagy forgalomnál a trace-alapú árazás gyorsan drágábbá válik. Ha a fő fájdalom az összehasonlító kísérletezés és nem a nyomkövetés, a Braintrust eval-központú. A részletes szembeállítást megírtuk a Langfuse és LangSmith összehasonlításban.

A naplózásnak megfelelőségi vetülete is van. Az EU AI Act 50. cikke szerinti átláthatósági kötelezettségek 2026. augusztus 2. óta élnek: a felhasználóval közölni kell, hogy nyelvi modellel beszél. A magas kockázatú rendszerekre vonatkozó naplózási kötelezettség határideje a 2026/1744 rendelettel 2027. december 2-re csúszott az Annex III szerinti önálló rendszereknél. Aki most épít trace-tárolást, az ezt a határidőt gyakorlatilag ingyen teljesíti.

Mit csinálj, ha a szállító lecseréli alattad a modellt?

Lefuttatod ugyanazt az eval-készletet az új verzión, összeveted a régivel, és csak akkor váltasz, ha nem esik a pontszám. Ez az egész mérési munka legkézzelfoghatóbb hozadéka: a modellváltás húszperces döntéssé válik ahelyett, hogy hetekig tartó találgatás lenne a felhasználói panaszok alapján.

Két külön jelenséggel érdemes számolni. A modelldrift az, amikor a szolgáltató alattad frissíti a súlyokat vagy a routingot, és a viselkedés megváltozik. A promptdrift az, amikor a saját csapatod hónapok alatt egyesével rárak tizennégy javító mondatot a system promptra, mindegyik egy konkrét panaszra válaszul, és a végén senki nem tudja, melyik minek a megoldása. A második gyakoribb, és nagyobb kárt okoz. Ellene az segít, ha minden prompt-módosítás a harness-en keresztül megy, és látod, mit rontott el a javítás máshol.

A váltás menete

1. Az új verzió lefut a teljes golden dataseten, esetenként háromszor, változatlan prompttal.
2. A riport összeveti a hét metrikát a bázissal, esetkategóriánként bontva. A globális átlag elfedheti, hogy egy szűk, de fontos kategória összeomlott.
3. Ha a pontszám tartja magát, canary indul: a forgalom 5–10%-a megy az új verzióra, egy hétig, éles metrikákkal.
4. Teljes átállás, a régi verzió pedig még két hétig visszakapcsolható marad.

Az árváltozás ugyanilyen kockázat. A Google árlapja szerint a Gemini Flash 0,75 és 3,75 USD-s tarifája promóciós, és 2026-12-31 után duplázódik. Az Anthropic ezzel szemben véglegesítette a Sonnet 5 bevezető árát. Ha a költség kérésenként metrikád fut, egy ilyen változás számként jelentkezik a következő heti riportban, nem meglepetésként a negyedéves zárásban. A TechCrunch 2026. júniusi cikke szerint az Uber már áprilisra elköltötte a teljes évre szánt AI-kódolási keretét, a Priceline Cursor-megújítása pedig négy-ötszörös áron jött vissza. Egyik esetben sem a modell volt a hibás.

Mit írj bele egy AI rendszer SLA-jába?

Két külön számot. Egy rendelkezésre állásit az infrastruktúrára, és egy minőségit, amit a golden dataseten mérnek újra havonta. A 99,9% önmagában csak annyit jelent, hogy a végpont havi 43 percnél kevesebbet hallgat. A válasz helyességéről semmit nem mond, márpedig az AI rendszereknél a hiba jellemzően nem leállás, hanem magabiztosan előadott tévedés.

Mi a fallback egy nyelvi modellnél

Négy lépcső, ebben a sorrendben. Először újrapróbálkozás rövid várakozással, mert a hibák egy része átmeneti. Másodszor másik szolgáltató vagy másik modell ugyanarra a feladatra, ehhez a rendszert modellfüggetlenre kell építeni. Harmadszor determinisztikus tartalék: gyorsítótárazott korábbi válasz, sablon, szabályalapú útvonal. Negyedszer emberi sor, ahol a kérés emberhez kerül, a felhasználó pedig tájékoztatást kap a várható időről. Az ötödik, rossz megoldás az, ha a rendszer kitalál valamit, csak hogy legyen válasza.

A mérési réteg költsége egyébként kisebb, mint amire a legtöbben számítanak. Egy 3–8 millió forintos RAG-projektben az eval-készlet összeállítása és a harness felépítése néhány embernap, a futtatás havonta pár dollár modellköltség. Az igazi tétel a karbantartás, tehát az esetek frissítése és a bíró újravalidálása. Ezt nálunk az üzemeltetési díj tartalmazza, mert eval nélküli üzemeltetést nem tartunk értelmesnek.

Összegzés és gyakori kérdések

Ha most tervezel ügynököt, a mérést az első héten kezdd, ne az utolsón. A fogalmi alapokhoz az AI ügynökök alapjai cikkünk ad hátteret, a retrieval-oldalhoz a RAG rendszerekről szóló írás. Ha még az architektúra a kérdés, az AI chatbot, n8n és egyedi ügynök összevetése ott kezdődik. Amit mi építünk és üzemeltetünk, azt a folyamatautomatizálás oldalon írtuk le, éles projektek pedig az AI portfólióban vannak, köztük a kultura.hu popkulturális archívumára épített MI-kereső.

Források

• MIT Project NANDA: The GenAI Divide, State of AI in Business 2025 (2025. július)
• Gartner: 40%-nál több agentic AI projekt leállítása 2027 végéig (2025-06-25)
• Anthropic: Introducing Contextual Retrieval (2024-09-19)
• Anthropic: Building Effective Agents (2024-12-19)
• Anthropic: Code execution with MCP (2025-11-04)
• Anthropic modellárak (lekérve 2026-08-14)
• Google Gemini API árlap (lekérve 2026-08-14)
• Langfuse árlap (lekérve 2026-08-14)
• LangSmith árlap (lekérve 2026-08-14)
• Braintrust árlap (lekérve 2026-08-14)
• Harang Péter: Mennyire tudnak magyarul az embeddingek? (2025-01-09)
• Hatvani Péter et al.: Training Embedding Models for Hungarian
• TechCrunch: The token bill comes due (2026-06-05)
• (EU) 2026/1744 rendelet, Official Journal (2026-07-24)