Egy jól sikerült bemutató könnyen elhiteti, hogy az MI-rendszer készen áll a céges használatra. Az éles munkában azonban hiányos kérdésekkel, elavult dokumentumokkal, szokatlan ügyekkel és jogosulatlan hozzáférési kísérletekkel is találkozik. A tesztelés célja annak bizonyítása, hogy a rendszer ezek között a körülmények között is elfogadhatóan működik.
Először határozd meg, mit jelent a jó eredmény
Az MI-rendszer tesztelése előre meghatározott feladatok, kockázatok és elfogadási feltételek alapján végzett ellenőrzés.
A túl általános elvárások nem mérhetők. Az, hogy az asszisztens adjon jó válaszokat, kevés. Pontosan rögzíteni kell, milyen feladatot végezhet, mekkora hibaarány fogadható el, mikor szükséges emberi jóváhagyás, és mely hibák zárják ki az élesítést.
Egy belső HR-asszisztensnél például elvárás lehet, hogy a válasz mindig a hatályos szabályzatra hivatkozzon, ne jelenítsen meg más munkavállalóra vonatkozó adatot, és jelezze, ha a rendelkezésére álló dokumentumokból nem adható biztos válasz.
Az optimális megoldás az, ha az MI-rendszereket az üzembe helyezés előtt, majd működés közben is rendszeresen tesztelik. A mérési módszert mindig a rendszer céljához és használati környezetéhez kell igazítani.
A tesztkészlet valós munkából épüljön fel
Gyűjts össze legalább 30–50 olyan feladatot vagy kérdést, amely ténylegesen előfordul a kiválasztott munkafolyamatban. A tesztkészletben legyenek egyszerű, összetett, félreérthető és hiányos esetek is.
Érdemes külön kipróbálni:
- a gyakori, jól dokumentált kérdéseket;
- a ritka kivételeket és szélső eseteket;
- az elírásokat vagy pontatlan megfogalmazásokat;
- az egymásnak ellentmondó forrásokat;
- azokat a kérdéseket, amelyekre nincs válasz a tudásbázisban;
- a jogosultsági határokat feszegető kéréseket.
Az utolsó két csoport különösen fontos. Egy megbízható rendszernek fel kell ismernie a tudása és a hozzáférése határait. A hihetően megfogalmazott találgatás vagy egy bizalmas dokumentum megjelenítése akkor is súlyos hiba, ha a többi válasz pontos.
Különítsd el a hibák forrását
Minden hibás eredményt érdemes besorolni. Forráshiba történt, ha a tudásbázis elavult vagy pontatlan információt tartalmazott. Keresési hibáról beszélünk, ha a helyes dokumentum rendelkezésre állt, de a rendszer nem találta meg. Válaszgenerálási hiba esetén a megfelelő forrásból is téves következtetés született.
Ez a különbség határozza meg a javítás módját. A dokumentum frissítése, a keresési beállítás módosítása és az utasítás pontosítása három eltérő feladat. A korábbi, céges MI-tudásbázis építéséről szóló cikkünk segít a forrásoldali problémák rendezésében.
Legyen előre rögzített élesítési küszöb
Az eredmények értékelése ne maradjon általános benyomás. Rögzítsd a helyes válaszok arányát, a hibás hivatkozásokat, a jogosultsági incidenseket, az indokolatlan találgatásokat és az emberi beavatkozást igénylő eseteket.
A kritikus hibák súlya nagyobb, mint az apró megfogalmazási pontatlanságoké. Egy hibásan formázott válasz javítható. Egy téves ár, kiszivárgó személyes adat vagy önállóan elküldött hibás ügyfélüzenet már az élesítés elhalasztását indokolhatja.
A magas kockázatú MI-rendszerek szolgáltatóinál az uniós MI-rendelet 9. cikke előzetesen meghatározott mérőszámok és valószínűségi küszöbök alapján végzett tesztelést ír elő. Egy hétköznapi irodai MI-asszisztensnél ez nem feltétlenül közvetlen jogszabályi követelmény, de az elv minden céges bevezetésnél használható.
Az élesítés után is kell vészfék
A pilot végén legyen kijelölt felelős, hibabejelentési útvonal és egyértelmű visszavonási terv. A cégnek tudnia kell, hogyan állítja le a rendszert, vonja vissza a jogosultságait, javítja a hibás kimeneteket és tér vissza az előző munkafolyamathoz.
Az élesítés egy ellenőrzött következő lépés. A valódi biztonságot az adja, hogy a rendszer hibája gyorsan felismerhető, korlátozható és visszafordítható.
