Hogyan értékeld az AI-ügynököket: tesztkészletek, értékelők és regressziós ellenőrzések

Minden kiváló MI-termék mögött egy alapos MI-ügynök-értékelési folyamat (angolul evals) áll, amely korán kiszűri a hibákat, és biztosítja az ügynök megfelelő működését. Az értékelések kritikus fontosságúak azoknál az MI-ügynököknél, amelyek nagy kockázatú műveleteket hajtanak végre, például valaki nevében visszatérítést indítanak.

Egy ilyen folyamat kialakításához némi technikai tudás és adatelemzési készség szükséges. Ám közel sem olyan ijesztő vagy megközelíthetetlen, mint amilyennek elsőre hangzik. Hogy könnyebb legyen az indulás, összegyűjtöttünk hat gyakorlati lépést az MI-ügynökök értékeléséhez, valamint azokat a gyakori tévhiteket, amelyek meghiúsítják a folyamatot.

Mit jelent egy MI-ügynök értékelése?

Egy MI-ügynök értékelése azt jelenti, hogy felmérjük, mennyire helyesen végzi el a feladatokat, és hogy döntései megfelelnek-e a szervezet követelményeinek. A gyakorlatban az MI-ügynökök értékelései (angolul evals) olyan konkrét mérőszámok, amelyek segítenek a szervezeteknek eldönteni, hogy az ügynök elég megbízhatóan működik-e a neki szánt szerepkörben.

Vegyünk példának egy gyártóüzem MI-beszerzési ügynökét, amely ellenőrzi a pótalkatrész-készletet, és előkészíti az utánrendelési igényeket. Ha egy jóváhagyott alkatrész nem érhető el, vagy a beszállítói adatok elavultak, vajon jelzi-e az ügynök a problémát, vagy inkább egy jóvá nem hagyott helyettesítőt javasol?

És ha a probléma megoldásához módosítod a rendszerpromptját, honnan tudod, hogy nem idéztél elő egy újabbat?

Értékelés nélkül a termékmenedzserek lényegében csak találgatni tudnak. Az értékelések ezért visszajelzést adnak, amellyel mérhető a teljesítmény, felismerhetők az ismétlődő problémák, és nagyobb magabiztossággal tesztelhetők a változtatások.

Ennek megfelelően az ügynökértékelés egy futtatás több szempontját is vizsgálhatja:

• A végeredmény minősége
• Az ügynök által felhasznált információk
• Az általa meghívott eszközök
• Betartotta-e a viselkedésére vonatkozó szabályokat

Az MI-ügynökök értékelésének gyakori mérőszámai

Az értékelések kvalitatív és kvantitatív adatokkal dolgoznak. A kvalitatív értékelés segít megérteni, mi történik és miért, beleértve az ügynök döntéseinek manuális áttekintését is. A kvantitatív értékelés mérhető jelekké alakítja ezeket a megfigyeléseket, például megszámolja bizonyos hibatípusok gyakoriságát, vagy kiszámítja a feladatok sikerességi arányát.

Az MI-ügynökök értékelésének alapvető mérőszámai:

• A feladatsikeresség azt méri, hogy az ügynök elérte-e a kívánt eredményt; általában az érvényes eredményt hozó futtatások százalékos arányában fejezik ki.
• A műveleti helyesség azt méri, hogy az ügynök megfelelően használta-e az eszközöket, érvényes argumentumokat választott-e, és betartotta-e a jogosultságokat.
• A válaszminőség azt értékeli, hogy a végső kimenet pontos, teljes és hasznos-e. Ide tartozhat a tényszerű helyesség, az utasítások betartása, valamint az is, hogy az ügynök a rendelkezésre álló információkkal alátámasztja-e a döntéseit.
• A megbízhatóság a konzisztenciát méri ismételt próbák, változó bemenetek és szélsőséges esetek során.
• A költség és késleltetés a sikeres eredmény eléréséhez szükséges erőforrásokat méri, beleértve a végrehajtási időt, a tokenfelhasználást és az eszközhívásokat.

Attól függően, hogy mit mérsz, az értékelések vizsgálhatják az ügynök teljes körű teljesítményét, végrehajtási útvonalát, vagy egyes összetevőit, például az eszközhívásokat és a lekérési lépéseket.

1. lépés: Határozd meg, milyen egy sikeres ügynökfuttatás

Először fogalmazd meg egyértelműen, mit kell elérnie az ügynöknek – vagyis a termékkövetelményeket. Magától értetődőnek hangzik, mégis meglepően nehéz lehet. Még neve is van: a specifikációs rés.

Andrey Khomutov, vezető adattudósunk szerint így érdemes hozzáfogni:

„Kezdd két kérdéssel: »Mi számít a feladat elvégzésének?« és »Mi tenne elfogadhatatlanná egy látszólag sikeres futtatást?«

Ügynökök esetében technikai szempontból ez azt jelenti, hogy az eredményt és azt is ellenőrizni kell, hogyan jutott el hozzá az ügynök.”

Egy ügynök úgy is előállíthatja a helyes választ, hogy egy kiszivárgott megoldókulcshoz fér hozzá, vagy jogosulatlan műveleteket hajt végre a feladata teljesítése közben. Khomutov rámutat, hogy a válaszszivárgás és az értékelés közbeni nem biztonságos műveletek konkrét okot adnak arra, hogy ne csak a végső válasz alapján ítéljünk.

„Arra számítok, hogy a végrehajtási útvonal vizsgálata az ügynökértékelési csomagok szokásos részévé válik, és nem csak akkor végezzük el, amikor egy eredmény gyanúsnak tűnik” – teszi hozzá.

Ezután vonj be egy szakterületi szakértőt a sikerkritériumok validálásába. A terület gyakorlati ismerői meg tudják ítélni, hogy az MI-ügynöknek szabott feltételek valóban sikeres eredményt tükröznek-e.

2. lépés. Állíts össze tesztkészletet valós feladatokból és hibákból

Vizsgáld meg az ügynök tényleges viselkedését, hogy megértsd, milyen a jó és a rossz teljesítmény. Állj ellen a kísértésnek, hogy rögtön több tucat tesztet generálj csupán abból kiindulva, hogy szerinted mi romolhat el.

Hamel Husain, a Parlance Lab gépi tanulási mérnöke, és Shreya Shankar, a gépi tanulási rendszerek és az alkalmazott MI-értékelések kutatója, azt javasolják, hogy a hibaelemzéssel kezdjünk, amely a gépi tanulásból és az adattudományból kölcsönzött technika. A folyamat az ügynök végrehajtási nyomkövetéseinek kvalitatív elemzésével indul – ezek a rekordok mutatják a felhasználó bemenetét, az eszközhívásokat, a lekért információkat és az ügynök kimenetét.

1. Tekintsd át az egyes nyomkövetéseket, és jegyzeteld a hibákat (nyílt kódolás). Egy szakterületi szakértő vizsgálja meg az ügynök futtatásait, és írjon rövid megjegyzéseket arról, mi ment félre. Az első jelentős hibára összpontosíts.
2. Csoportosítsd a megfigyeléseket hibatípusok szerint (axiális kódolás). Ha már elég jegyzeted van, kérj egy LLM-től kategóriajavaslatokat a hasonló hibákhoz. Ilyen lehet például a nem kompatibilis alkatrészek ajánlása, a pontatlan készletlekérdezés vagy az emberi munkatársnak történő sikertelen átadás.
3. Számold meg az előfordulásokat. Sorold be az egyes megfigyeléseket egy-egy kategóriába, majd egy táblázatkezelő vagy kimutatás segítségével számítsd ki, milyen gyakran fordulnak elő az egyes hibatípusok.
4. Döntsd el, mivel foglalkozz először, a gyakoriságot és a súlyosságot egyaránt figyelembe véve.
5. Alakítsd a fontos hibákat tesztesetekké. Mentsd el a releváns bemenetet, a kiinduló feltételeket, a várt eredményt és az értékelési kritériumokat, hogy az ügynököt újra ugyanazon a forgatókönyvön lehessen tesztelni.

Hány nyomkövetést érdemes megvizsgálni? Nagyjából 100-at, de nincs bűvös szám. Állj meg korábban, ha eléred az elméleti telítettséget: azt a pontot, ahol további nyomkövetések áttekintése már nem tár fel érdemben új hibamintákat.

Még nem indítottad el az alkalmazást? Szintetikus példákkal is összeállíthatsz egy kezdeti tesztkészletet, de amint elérhetők valós felhasználói adatok, azokra is építs.

Benchmarkok használata az MI-ügynökök értékelésében

A saját tesztesetek létrehozásán túl meglévő, szabványosított értékelési feladatgyűjteményeket, úgynevezett benchmarkokat is használhatsz az ügynökök képességeinek felmérésére.

A benchmarkok azonban nem tévedhetetlenek. A SWE-bench auditjai, az Epoch AI benchmark-áttekintései és a TheoPhysEvalban eredetileg elutasított helyes válaszok jól mutatják, hogyan torzíthatják az értékelési eredményeket a hibás feladatok vagy várt válaszok.

Khomutov azt tanácsolja, hogy válassz naprakész, a szakterületedhez illő benchmarkokat, és vizsgáld meg a meglepő sikereket vagy kudarcokat, mielőtt a pontszámokat az ügynök teljesítményének megbízható bizonyítékaként kezelnéd.

3. lépés. Futtasd az ügynököt megismételhető tesztkörnyezetben

A megismételhető tesztkörnyezet olyan ellenőrzött beállítás, amelyben egy MI-ügynököt ugyanazokon a teszteseteken, ugyanazon kiinduló feltételek mellett futtathatsz, és összevetheted az eredményeket. Ide tartozhat egy teszteseteket tartalmazó mappa, egy Python-szkript, amely az ügynököt futtatja, vagy egy ellenőrzéskészlet, amely kiértékeli az eredményeket.

Kezdésként tárolhatod a reprezentatív bemeneteket JSON-fájlokban, egy Python-szkripttel pedig végrehajthatod az ügynök munkafolyamatát, és assert utasításokkal ellenőrizheted a kimeneteit. Gyártóüzemünk készletkezelő ügynöke esetében egy megismételhető tesztkörnyezet így nézhet ki:

Nagyítás

Megismételhető tesztkörnyezet kialakításához kövesd az alábbi lépéseket:

1. Mentsd el a reprezentatív bemeneteket. A valós eseményeket vagy teszteseteket ugyanabban a struktúrában tárold, amelyben az alkalmazásod éles környezetben megkapja őket. A mi forgatókönyvünkben JSON-fájlként mentenéd el a gép azonosítóját, a szükséges pótalkatrészt és a karbantartás dátumát tartalmazó karbantartási kérelmet, a készletadatok és a jóváhagyott alkatrészek adatainak pillanatképével együtt.
2. Hajtsd végre a munkafolyamatot. Futtasd végig az egyes bemeneteket az ügynökön, beleértve a lekérési lépéseket, az eszközhívásokat és a válaszgenerálást.
3. Rögzítsd az eredményt és a nyomkövetést. Mentsd el a végső kimenetet és a releváns köztes műveleteket (például a készletlekérdezéseket), hogy ne csak azt lásd, hibázott-e az ügynök, hanem azt is, hogy hol.
4. Ismételd meg az eseteket a hiba súlyossága és gyakorisága, valamint a javítás nehézsége alapján. Az LLM-alkalmazások nemdeterminisztikusak (azonos bemenetekre eltérő eredményeket adhatnak), így egy sikeres futtatás nem garantálja, hogy a következő is sikeres lesz. Add meg a sikeres próbálkozások arányát, és vizsgáld meg a hibákat.

Ez utóbbihoz Khomutov a pass@1 (milyen gyakran sikeres az ügynök egyetlen próbálkozásra) és a pass@k (annak valószínűsége, hogy adott számú próbálkozás során legalább egyszer sikerrel jár) mérését javasolja. Ha pass@k értéket jelentesz, add meg a próbálkozások számát, hiszen ha több válasz közül egy helyes, az még nem jelenti, hogy az ügynök tudja, melyiket kell választania.

Ahogy az alkalmazásod növekszik, használj tesztelési keretrendszert (például pytest) a tesztek rendszerezéséhez és futtatásához, a nagy tesztadatkészleteket és eredményeket pedig érdemes lehet adatbázisban tárolni.

4. lépés. Válaszd ki a megfelelő értékelőt minden ellenőrzéshez

Az értékelő (angolul grader, gyakran evaluator néven is emlegetik) olyan mechanizmus – egy kódrészlet, egy értékelési szempontrendszer által irányított LLM vagy egy emberi ellenőr –, amely egy meghatározott kritérium alapján ellenőrzi az ügynök kimenetét vagy műveletét. Az értékelő megfelelt/nem felelt meg ítéletet ad, valamint egy magyarázatot, amely megjelöli a releváns bizonyítékokat.

Infó: Az értékelési szempontrendszer olyan kritériumok és utasítások összessége, amelyek meghatározzák, mi számít helyes vagy elfogadható eredménynek.

A megfelelő értékelőtípus attól függ, mit szeretnél ellenőrizni. Így viszonyul egymáshoz a három megközelítés:

Előfordul, hogy ugyanannak a futtatásnak a különböző szempontjai eltérő értékelési módszereket igényelnek, ezért szükség lehet az értékelők kombinálására.

Hogyan kombinálhatók az értékelők?

Tedd fel a kérdést: „Ellenőrizhető-e az eredmény egy ismert szabály vagy várt érték alapján, vagy emberihez hasonló ítélőképességet igényel?”

• Ha az eredmény pontosan ellenőrizhető, kezdd egy kódalapú értékelővel. A kódalapú értékelők a strukturált kimeneteket, a mezőértékek érvényességét, az eszközargumentumokat vagy egy adatbázis végállapotát is ellenőrizhetik.
• Ha az ellenőrzéshez a kontextus értelmezése szükséges, használd az LLM mint bíró megközelítést.
• A szakterület-specifikus vagy vitatott döntésekhez vonj be emberi ellenőröket.

Fontos! Egy LLM-alapú értékelő félreértelmezheti a bizonyítékokat, vagy helytelenül alkalmazhatja a szempontrendszert. Ezért egy további értékelési lépésre van szükség: az emberi ítéletekhez való kalibrálásra.

Kalibráld az LLM-alapú értékelőt az emberi ítéletekhez.

A kalibráláshoz lényegében egy szakterületi szakértőnek kell értékelnie valós ügynökfuttatásokat. A szakértő ezután összeveti saját ítéleteit az LLM ítéleteivel, és az eltérések alapján finomítja az értékelési szempontrendszert.

Íme egy ötlépéses értékelőkalibrálási folyamat:

1. Gyűjts példákat az ügynök bemeneteiről, kimeneteiről és a releváns nyomkövetésekről.
2. Egy szakterületi szakértő önállóan ítélje meg, hogy az egyes példák megfelelnek-e az értékelési kritériumnak.
3. Futtasd le az LLM-alapú értékelőt ezeken a példákon.
4. Hasonlítsd össze az ember és a modell ítéleteit.
5. Vizsgáld meg az eltéréseket, és finomítsd az értékelő szempontrendszerét, mielőtt új példákon tesztelnéd.

Khomutov azt is hangsúlyozza, hogy az LLM-alapú értékelő konzisztenciáját külön is fontos tesztelni:

„Add oda neki többször pontosan ugyanazt a mentett futtatást és fájlokat, az ügynök újrafuttatása nélkül. Így elkülönítheted az ügynök munkájában jelentkező ingadozást az értékelésben jelentkezőtől.”

Ha ugyanaz a kimenet eltérő ítéleteket kap, ne feltételezd, hogy minden pontszámváltozás az ügynöktől ered. Ehelyett vizsgálj meg egy tévesztési mátrixot, amely megmutatja, mikor ismerte fel helyesen az értékelő a hibákat, mikor siklott el felettük, és mikor jelölt meg tévesen elfogadható kimeneteket.

Az emberi ellenőrzés továbbra is nélkülözhetetlen a referenciaítéletek kialakításához, a vitatott esetek eldöntéséhez és olyan új hibatípusok felderítéséhez, amelyek észlelésére a meglévő értékelőket nem tervezték.

5. lépés. Hasonlítsd össze a verziókat, és futtass regressziós ellenőrzéseket

Tegyük fel, hogy a hibaelemzésből kiderül: a készletkezelő ügynököd gyakran javasol jóvá nem hagyott cserealkatrészeket. Módosítod a rendszerpromptját, hogy kötelezően végezzen kifejezett kompatibilitás-ellenőrzést. Az eredetileg hibás eset most már sikeres. De honnan tudod, hogy a változtatás nem befolyásolt más feladatokat?

Itt jön képbe a regressziós tesztelés.

A regressziós tesztelés azt jelenti, hogy az ügynök promptjának, modelljének vagy munkafolyamatának módosítása után újrafuttatod a korábban sikeres teszteseteket, hogy megbizonyosodj róla: a változtatás nem okozott új hibákat.

1. Reprodukáld az eredeti hibát a tesztkészlet egyik mentett bemenetével.
2. Hajts végre célzott módosítást a prompton, a modellen vagy a munkafolyamaton.
3. Futtasd újra a sikertelen tesztet, hogy ellenőrizd, megoldódott-e a probléma.
4. Futtasd a többi tesztet, hogy meggyőződj róla: a módosítás nem rontotta el a korábban helyesen működő viselkedést.
5. Vizsgáld meg az eredményeket, és járj utána minden új hibának.

A pontos eredmények érdekében az alapverziót és a frissített ügynököt ugyanazokkal a tesztesetekkel és értékelési szempontokkal hasonlítsd össze.

6. lépés: Az AI-ügynök teljesítményének monitorozása éles környezetben

Az ügynökök értékelése nem ér véget az alkalmazás üzembe helyezésével. Ahogy Husain és Shankar kifejti, a fejlesztés során használt értékelők valós, éles adatokon is futtathatók, így mérheted, hogyan teljesít az ügynököd az idő múlásával.

Ezt online értékelésnek nevezik, és egy átfogóbb éles monitorozási folyamat része, amely segít feltárni az ismétlődő és a korábban ismeretlen hibákat.

A folyamat iteratív, és négy, egymást kiegészítő tevékenységből áll:

• Futtass kalibrált LLM-bírákat az éles nyomkövetéseken. Vegyél mintát a valós ügynökinterakciókból, és alkalmazd rájuk azokat az értékelőket, amelyeket már emberi ítéletek alapján validáltál.
• Kövesd nyomon a hibaarányok alakulását. A hibaelemzés során kialakított hibakategóriák segítségével számszerűsítsd az ismétlődő problémákat.
• Továbbra is nézd át kézzel a nyomkövetéseket. Az automatizált értékelők csak azokat a problémákat észlelik, amelyek azonosítására tervezték őket. Vizsgálj meg kézzel mintákat a valós ügynökinterakciókból, hogy új hibákat vagy szokatlan felhasználói kéréseket fedezz fel.
• Használj A/B tesztelést az üzleti eredmények mérésére (csak ha indokolt). Hasonlíts össze különböző promptokat, modelleket vagy munkafolyamatokat olyan mutatók alapján, mint a feladatteljesítés, a felhasználói elégedettség és a megoldási idő. Ez segít eldönteni, hogy egy változtatás az egyes tesztek sikeres teljesítésén túl a tényleges termékélményt is javítja-e.

Egy fontos megjegyzés: az értékeléseket nem kell tökéletesre csiszolni. Elég, ha annyira jók, hogy segítsenek jobbá tenni a termékedet.

Gyakori tévhitek az AI-ügynökök értékelésével kapcsolatban

• Az értékelések csupán egységtesztek. Nem azok: az egységtesztek kis, automatizált ellenőrzések, amelyek az értékelésnek csak egy részét képezik. Az értékelés kvalitatív hibaelemzést, emberi ítéleteket, éles monitorozást és kísérleteket is magában foglal az alkalmazás minőségének mérésére.
• Egy értékelési platform mindent elvégez helyetted. A kész eszközök automatizálhatnak bizonyos ellenőrzéseket, de nem tudják meghatározni, mely hibamódok (hibatípusok vagy nem kívánt ügynökviselkedések) számítanak a termékednél.
• Mindent értékeltethetsz egy LLM-mel. Ez nagy tévedés. Az ember által vezetett hibaelemzés és az értékelők kalibrálása továbbra is elengedhetetlen, mivel az LLM-ekből hiányzik az az üzleti kontextus, amely minden probléma feltárásához szükséges.
• Az A/B tesztelés vagy az ügynök egyszerű használata kiváltja az értékeléseket. Téves. Az A/B tesztek megmutathatják, melyik verzió teljesít jobban a kiválasztott mutatók alapján, de önmagukban nem tudják megmagyarázni a háttérben álló problémákat.

GYIK az AI-ügynökök értékeléséről

1. Mi a különbség az AI-ügynökök értékelése és az LLM-ek értékelése között?

Az LLM-értékelés azt méri, mennyire jól teljesít egy nyelvi modell egy adott feladatban, például egy kérdés megválaszolásában, egy dokumentum összefoglalásában vagy információk kinyerésében. Az AI-ügynökök értékelése olyan rendszert vizsgál, amely egy feladat elvégzéséhez önállóan hajt végre több lépést.

A hagyományos LLM-értékeléssel ellentétben az ügynökértékelés a végeredményt és az eléréséhez vezető műveletsort is vizsgálja, beleértve az eszközhívásokat, a döntéseket és az előre meghatározott szabályok betartását.

2. Az AI-ügynökök értékelésének legfontosabb mutatói

Az AI-ügynökök értékelési mutatói két nagy kategóriába sorolhatók:

• Technikai teljesítménymutatók: feladat-sikerességi arány, a műveletek helyessége, a válaszok minősége, megbízhatóság (pass@1 és pass@k), késleltetés, tokenhasználat és sikeres feladatonkénti költség.
• Üzleti és felhasználói élményt mérő mutatók: ügyfél-elégedettség (CSAT), problémamegoldási arány, eszkalációs arány, konverziós arány, feladat-elvégzési idő, valamint az ügynök szerepére jellemző egyéb eredmények.

Egy ügyfélszolgálati ügynököt például a problémák sikeres megoldása és az ügyfél-elégedettség alapján lehet értékelni, míg egy AI-alapú beszerzési ügynök a készletfeltöltési kérelmek pontosságával, a jóváhagyási arányokkal és a beszerzési ciklusidővel mérhető.

A megfelelő mutatóknak egyszerre kell tükrözniük, mennyire megbízhatóan teljesít az ügynök, és hogy a munkája javítja-e az üzleti eredményeket.

3. Melyek a legjobb eszközök az AI-ügynökök értékeléséhez?

Néhány gyakori lehetőség:

• Tesztelési keretrendszerek: A Python assert utasításai és a pytest hasznosak a megismételhető tesztesetek futtatásához és a pontos feltételek ellenőrzéséhez, például hogy az ügynök a megfelelő eszközt választotta-e, vagy érvényes alkatrész-azonosítót adott-e vissza.
• AI-ügynökértékelési keretrendszerek: A DeepEval és a Google agent-eval eszközkészlete összetettebb értékeléseket is támogat, beleértve a végrehajtási nyomkövetéseket, az LLM-alapú értékelőket és az automatizált regressziós tesztelést.
• Értékelési és megfigyelhetőségi platformok: A LangSmith, az Arize Phoenix és az MLflow segít a csapatoknak megvizsgálni az ügynökök viselkedését, kezelni az értékelési adatkészleteket, összehasonlítani az ügynökverziókat, valamint monitorozni a teljesítményt éles környezetben.

4. Hogyan automatizálhatod az AI-ügynökök értékelését?

Az AI-ügynökök értékelését úgy automatizálhatod, hogy megismételhető teszteket készítesz, automatizált értékelőket alkalmazol, és ezeket az ellenőrzéseket beépíted a fejlesztési és az éles munkafolyamatokba:

1. Hozz létre egy értékelési adatkészletet: Gyűjts reprezentatív felhasználói feladatokat, elvárt eredményeket, ismert hibákat és ügynök-végrehajtási nyomkövetéseket. Vegyél fel szélsőséges eseteket is, például sikertelen eszközhívásokat, hiányzó információkat és jogosulatlan műveleteket.
2. Automatizáld a tesztek végrehajtását és értékelését: Használj olyan keretrendszereket, mint a pytest vagy a DeepEval, hogy teszteseteket futtass, és kódalapú ellenőrzéseket vagy LLM-értékelőket alkalmazz. Mielőtt a pontszámaikra hagyatkoznál, validáld az LLM-értékelőket emberi ítéletek alapján.
3. Építsd be az értékeléseket a CI/CD-folyamatba: Futtasd újra automatikusan a regressziós teszteket, amikor a fejlesztők módosítják egy ügynök promptjait, modelljeit, eszközeit vagy munkafolyamatát. Hasonlítsd össze az eredményeket egy alapállapottal, és határozz meg olyan minőségi küszöbértékeket, amelyek megakadályozzák a kiadást, ha valamelyik kritikus ellenőrzés sikertelen.
4. Alkalmazz kalibrált értékelőket az éles környezetből vett nyomkövetési mintákon, kövesd nyomon a hibaarányokat és más teljesítménymutatókat, és kézi átnézéssel vizsgáld ki az új hibákat.