AI-ügynök tesztfolyamata ellenőrzési, biztonsági, költség- és hibamérési állomásokkal

AI-ügynök élesben: 12 mérőszám, amivel a demóból megbízható rendszer lesz

A szép demó nem üzemi minőség. Mutatók, tesztesetek, trace grading, regresszió és stop-feltételek AI-ügynökök biztonságos bevezetéséhez.

Röviden: egy AI-ügynököt ne csak a végső válasz alapján értékelj. Mérd, hogy jó eszközt választott-e, helyes sorrendben dolgozott-e, időben kért-e emberi segítséget, betartotta-e a jogosultságot, és mennyibe került egy valóban elfogadott eredmény. A minőségi kapu előre rögzített tesztkészletből, futási nyomokból és üzleti stop-feltételekből áll.

Frissítve: 2026. szeptember 8. A legtöbb agentdemó egy gondosan választott boldog útvonalat mutat. Élesben viszont hiányos adat, elavult dokumentum, időtúllépés, jogosultsági hiba és ellentmondó ügyfélkérés érkezik. Az OpenAI hivatalos agent eval útmutatója külön kezeli a teljes futási nyom értékelését, valamint az ismételhető adatkészleteket és eval futásokat. A trace a modellhívásokat, eszközhívásokat, guardraileket és átadásokat is láthatóvá teszi.

A 12 mérőszám

CsoportMutatóMit jelez?
Eredmény1. FeladatsikerA kívánt üzleti eredmény ténylegesen létrejött-e
2. Tény- és forráspontosságA válasz megfelel-e a hiteles adatnak
3. Formai megfelelésÉrvényes-e a JSON, rekord vagy dokumentum
Folyamat4. EszközválasztásA megfelelő rendszert hívta-e meg
5. LépéshatékonyságVolt-e felesleges kör, keresés vagy ismétlés
6. Handoff pontosságÁtadta-e az ügyet, amikor kellett
Kockázat7. Jogosultsági megfelelésCsak engedélyezett adatot és műveletet ért-e el
8. Tiltott műveletPróbált-e jóváhagyás nélkül küldeni, törölni vagy fizetni
9. Bizonytalanság-kezelésMegállt-e hiányos vagy ellentmondó helyzetben
Üzemeltetés10. Elfogadott kimenet költségeA modell, eszköz, retry és emberi javítás együtt
11. p95 válaszidőA lassú, rossz ügyfélélményt okozó szélső esetek
12. Regressziós arányEgy módosítás hány korábban jó esetet rontott el

A feladatsiker nem azonos a szép válasszal

Ha az agent udvariasan azt írja, hogy létrehozta a CRM-feladatot, de valójában rossz ügyfélhez vagy rossz határidővel rögzítette, a futás sikertelen. A teszt elvárt állapota ezért géppel ellenőrizhető legyen: megfelelő rekord, helyes mezők, engedélyezett eszköz és naplózott jóváhagyás.

Építs háromrétegű tesztkészletet

  1. Aranykészlet: 30–100 gyakori, valós, anonimizált eset helyes eredménnyel.
  2. Szélső esetek: hiányzó mező, ellentmondó forrás, többértelmű kérés, zajos dokumentum és időtúllépés.
  3. Támadó esetek: prompt injection, jogosultságkérés, tiltott adattovábbítás, más ügyfél adatának lekérése és jóváhagyás megkerülése.

Minden esethez rögzítsd az elvárt végállapotot, a megengedett eszközöket, a kötelező átadást és a súlyosságot. Ne csak pass/fail eredményt használj: külön címkézd a tényhibát, a folyamat-hibát, a biztonsági hibát és a rossz felhasználói élményt.

Trace grading és regresszió

A trace grading azt vizsgálja, hogyan jutott el az agent a kimenetig: jó eszközt választott-e, szükség esetén átadott-e embernek, és betartotta-e a szabályt. Ezután ugyanazt az adatkészletet minden prompt-, modell-, routing- és eszközváltoztatás előtt és után futtasd le. Egy átlagpontszám mögött maradhat kritikus hiba, ezért a súlyos biztonsági esetek külön kaput kapjanak.

Állíts be stop-feltételeket

  • bármilyen jogosulatlan adat-hozzáférés vagy tiltott külső művelet;
  • kritikus tényhiba pénzügyi, jogi vagy biztonsági ügyben;
  • a kötelező emberi jóváhagyás megkerülése;
  • a hibaarány vagy költség előre rögzített küszöb fölé kerülése;
  • nem visszafordítható művelet napló vagy idempotenciavédelem nélkül.

A stop-feltétel ne csak riasztás legyen: kapcsolja az agentet csak-olvasási módba, állítsa le az érintett eszközt, vagy terelje a forgalmat emberhez.

Heti minőségi rutin

  1. Nézd át az összes kritikus hibát és egy véletlen mintát a sikeres futásokból.
  2. Csoportosítsd a hibát: prompt, tudás, eszköz, jogosultság, modell vagy üzleti szabály.
  3. Adj hozzá minden új hibából legalább egy regressziós tesztet.
  4. Futtasd újra a teljes kaput, ne csak a javított példát.
  5. Dokumentáld a modell-, prompt-, eszköz- és adatverziót.

A gyakorlati pilot felépítéséhez olvasd el az AI-ügynök vállalkozási útmutatót, megvalósításhoz pedig az AI-ügynök fejlesztés szolgáltatást.

Gyakori kérdések

Hány teszteset kell indulás előtt?

Egy szűk pilothoz 30–100 jó minőségű valós eset használható kezdet, de a lefedettség fontosabb a darabszámnál. Legyen benne gyakori, szélső és támadó eset is.

Elég egy másik AI-val lepontoztatni a választ?

Nem. Az AI-grader hasznos skálázáshoz, de gépi állapotellenőrzéssel, szabályalapú teszttel és emberi mintavétellel együtt megbízhatóbb.

Mikor engedhető el az emberi jóváhagyás?

Csak alacsony kockázatú, visszafordítható, jól naplózott műveletnél, ha a saját adatokon mért hibaarány tartósan a küszöb alatt marad. A magas kockázatú lépések jóváhagyását ne a modell önbizalmára bízd.

Vissza a bloghoz