Forgatókönyv-alapú értékelési készlet üzleti MI-rendszerhez

Egy használható értékelési készlet nem látványos mintapromptok gyűjteménye, hanem egy körülhatárolt üzleti munkafolyamat reprodukálható eseteinek rendszere. Képzeljünk el egy beszerzési igényeket előkészítő asszisztenst: a mappában hihető kérés, eltérő szállítóazonosító, elérhetetlen szabályzat és a rendszernek szóló utasítást tartalmazó árajánlat található. A jó teszt megmutatja, hogy a rendszer felismeri-e az ellentmondást, kér-e hiányzó bizonyítékot, ellenáll-e a beágyazott utasításnak, és az engedélyezett emberi jóváhagyási pontra irányít-e. Ehhez előre rögzített lefedettség, esetleírás, értékelési szabály, tiltókapu és elkülönített kiadási teszt kell.

Mit kell lefednie egy forgatókönyv-alapú értékelési készletnek?

A készletnek egyetlen, pontosan körülhatárolt munkafolyamat szokásos feladatait, fontos határhelyzeteit, igazolt hibáit és tiltott működését kell lefednie. Elsőként nevezze meg a vizsgált rendszerverziót, a megengedett felhasználókat és bemeneteket, az elérhető tudást és eszközöket, valamint azt a döntést, amelyhez az eredmény bizonyítékot ad. Egy meghatározatlan „általános asszisztens” tesztelése nem kínál stabil alapot sem a mintavételhez, sem az elfogadható viselkedés megítéléséhez.

A feladattípusok és változatok térképe engedélyezett munkafolyamat-adatokból, támogatási esetekből, felhasználói kutatásból, incidensnyilvántartásból és szakterületi bejárásból állhat össze. A működési napló nem automatikusan teljes, helyesen címkézett vagy újrafelhasználható, ezért a hozzáférési jogot, az adatminimalizálást és a reprezentativitást külön ellenőrizni kell. Ha nincs megbízható forgalmi adat, a tervezett megoszlást előzetes feltételezésként, nem pedig mért tényként érdemes feltüntetni.

• Reprezentatív munka: a gyakori feladattípusok, szerepkörök, bemenetek és működési feltételek az ismert munkamegoszlással arányosan.
• Fontos határesetek: például hiányos vagy ellentmondó információ, szokatlan formátum, jogosultsági korlát, kétértelmű kérés vagy megbízhatatlan eszközeredmény.
• Ismert hibák: ellenőrzött incidensek és panaszok minimalizált, szükség szerint szintetikus vagy személytelenített reprodukciói regressziós célra.
• Tiltott működés: közvetlen vagy közvetett próbák olyan cselekvésre, közlésre vagy állapotváltoztatásra, amelyet a termék, a szabályzat vagy a jogosultsági modell kizár.

A beszerzési asszisztens szokásos esete lehet a teljes, egymással összhangban álló igény és az elérhető aktuális szabályzat. Célzott esetként kerüljön mellé hiányzó melléklet, eltérő összeg vagy szállítóazonosító, bizonyíték nélkül eldönthetetlen következő lépés, jóváhagyás megkerülésére irányuló kérés, dokumentumba rejtett utasítás és hibás lekérdezés. Ezek csak szemléltető, szervezetfüggő szabályok. A jelentendő szeleteket és a tiltókapukat a kimenetek megtekintése előtt kell kijelölni.

Hogyan rögzítsünk egy reprodukálható értékelési esetet?

Minden forgatókönyvet úgy kell rögzíteni, hogy egy másik értékelő ugyanazt a kiinduló helyzetet újra létrehozhassa, felismerhesse az elfogadható változatokat, és külön észlelhesse a tiltott eredményt. Az eset kapjon stabil azonosítót, gazdát, verziótörténetet, lefedettségi és feladatcsaládot, szeletcímkéket, következménybesorolást, származási kategóriát, felhasználási engedélyt és előre kijelölt készletbesorolást. A forrásrekordra mutató hivatkozás csak az alkalmazandó hozzáférési szabályok mellett legyen elérhető.

• Kiinduló helyzet: a szereplő célja, a munkafolyamat és a rendszer állapota, a kérés, a fájlok, a releváns előzmény és a vizsgált eltérés.
• Elérhető környezet: engedélyezett tudás, eszközök, jogosultságok, eszközeredmények, működési feltételek, valamint a rendszernek átadott utasítások.
• Elvárások: kötelező tények vagy állapotváltozások, elfogadható alternatív utak, továbbá a szükséges tisztázás, tartózkodás, elutasítás vagy emberi továbbítás.
• Korlátok és mérés: külön felsorolt tiltott közlések, műveletek és eszközhívások; értékelőtípus, rubrika, kapuk, esetleges referenciamegoldás és döntési szabály.
• Működtetés: szükség esetén előre rögzített próbák és összesítés, értékelői jogosultság, kalibráció, döntőbírói út, valamint a modell, prompt, tudásbázis, eszköz, szabályzat és teszthám verziója.

Nyílt feladatnál ne egyetlen mintamondat legyen az igazság. A referenciamegoldás azt igazolhatja, hogy a feladat elvégezhető, és felsorolhatja a kötelező tényeket, de nem zárhat ki más helyes megfogalmazást vagy munkautat. Nem determinisztikus, több lépésből álló rendszernél a próbák számát és az összesítés módját még a kimenetek vizsgálata előtt kell meghatározni. A hibás vagy megoldhatatlan esetet pedig javítani vagy visszavonni kell, nem rendszerhibaként elszámolni.

A jó értékelési eset nem csupán nehéz kérdést tesz fel: újrateremti a munkát, és megfigyelhetővé teszi a sikert, az elfogadható eltérést és a tiltott működést.

Hogyan pontozzunk anélkül, hogy a rossz viselkedést jutalmaznánk?

Minden esethez azt a legszűkebb értékelési módszert kell választani, amely érvényesen megkülönbözteti a sikert a hibától. Objektíven ellenőrizhető válasznál, sémánál, számításnál, eszközparaméternél vagy rekordállapotnál determinisztikus ellenőrzés használható. Ha több megfogalmazás vagy végrehajtási út elfogadható, de a szükséges tények vagy a végállapot kötött, referenciaelemek segítenek. Nyílt minőségi szempontokhoz külön dimenziókra bontott, megfigyelhető támpontokkal ellátott rubrika szükséges.

• Determinista ellenőrzésnél bizonyítsa, hogy az eset valóban megoldható, a szabály pedig teljes és nem jutalmaz nem kívánt rövid utat.
• Modellalapú értékelőt csak strukturált rubrikával és az adott környezetben jártas emberek ítéletéhez kalibrálva használjon.
• Szakterületi értelmezést vagy jelentős következményt igénylő kimenetet megfelelően felhatalmazott szakértő vizsgáljon; szabályozott döntés maradjon az arra jogosult embernél.
• Adjon részpontot az értelmesen elkülöníthető feladatelemekre, de mutassa meg, melyik elem hibázott, és ne mossa össze a minőségi dimenziókat.

A tiltott közlés, jogosulatlan művelet vagy megengedhetetlen állapotváltozás ne legyen egy átlagba rejtett gyenge pontszám: előre meghatározott, nem kompenzálható kapuként kezelendő. A tényleges tiltásokat és kiadási következményeiket a termék- és kockázati felelősöknek kell a konkrét rendszerhez igazítaniuk. Ugyanígy a rubrika verzióját, a szeleteket, az összesítést és a döntési szabályt is összehasonlítás előtt kell rögzíteni; későbbi módosításuk új értékelési verziót hoz létre.

Hogyan értékeljenek következetesen a felülvizsgálók?

A felülvizsgálók akkor tudják következetesen alkalmazni a feltételeket, ha a kimenet előtt ugyanazt a munkafolyamat-leírást, szerepkört, rendelkezésre álló bizonyítékot, megengedett működést, termékhatárt és rubrikaverziót kapják. Minden pontszinthez megfigyelhető támpontok, pozitív és negatív példák, valamint határesetek tartozzanak. Legyen külön „nem értékelhető” út arra az esetre, ha hiányos az eset, hibás a környezet, vagy a bizonyíték nem teszi lehetővé az ítéletet.

1. A valódi értékelés előtt közös kalibrációs esetekkel ellenőrizzék a rubrika értelmezését.
2. Ismételjék meg a kalibrációt, ha változik a feladatmix, a szabályzat, a rubrika vagy a felülvizsgálói kör.
3. Összehasonlításnál, ahol ez megoldható, rejtsék el a rendszer kilétét és változtassák a kimenetek sorrendjét.
4. A megbeszélés előtt rögzítsék az önálló pontszámot és indoklást, majd a nézeteltérést okként, ne kellemetlenségként vizsgálják.
5. Nevezzenek meg döntőbírót, és őrizzék meg a címkéket, indoklásokat, rubrikaverziókat és végső döntéseket.

A nézeteltérés jelenthet hibás esetet, tisztázatlan küszöböt, hiányzó környezetet, több jogosan elfogadható eredményt vagy még meg nem hozott termékdöntést. Ezeket nem szabad automatikus konszenzussal elfedni. A végrehajtási nyom és az értékelés együttes ellenőrzése segít eldönteni, hogy maga a rendszer hibázott-e, vagy az eset, az értékelő, illetve a tesztkörnyezet volt hibás. A megőrzött emberi indoklások később a rubrika és a modellalapú értékelő újrakalibrálását is támogatják.

Hogyan maradjon használható a készlet fejlesztés és kiadás közben?

A készlet akkor marad használható, ha a gyakran látható fejlesztési eseteket elkülönítik a ritkán futtatott, hozzáférésében védett kiadási teszttől, és mindkettőt verziózott nyilvántartás kezeli. A fejlesztési készlet ismételten támogathatja a prompt, a keresés, az eszközhasználat, a szabályzat és a munkafolyamat javítását. Pontszáma azonban fejlesztési bizonyíték, mert a csapat már látta az eseteket, és változtatásait részben hozzájuk igazította.

• Az eset belépésekor, a rutinszerű futtatás és a kimenetek megtekintése előtt rögzítse a készletbesorolást.
• Keressen pontos és közeli másolatokat, közös forrásrekordokat, átfogalmazásokat és ugyanabból a sablonból származó testvéreseteket.
• Kövesse, ki vagy mely rendszer férhetett hozzá az esethez, a referenciaeredményhez, a rubrikához és a pontszámhoz.
• A fejlesztést érdemben befolyásoló védett esetet helyezze át regressziós bizonyítékba, és készítsen helyette független, verziózott pótlást.
• Az igazolt hibát minimalizált, engedélyezett reprodukcióként őrizze meg; a védett készlet ugyanazt a hibaosztályt csak új, nem duplikált esettel vizsgálja.

A nyilvántartás tartalmazza az eset gazdáját, származását, felhasználási engedélyét, készletbesorolását, kitettségét, verzióit, felülvizsgálati előzményeit, változtatási okát és kivezetési indokát. A lefedettséget újra kell vizsgálni, ha érdemben változik a munkafolyamat, a felhasználói kör, a szabályzat, a tudásbázis, a modell, a prompt, az eszköz, a jogosultság vagy az üzemeltetési környezet. Nincs minden rendszerre érvényes esetszám, felosztási arány vagy frissítési időköz.

Az eredményeket feladatcsalád, lefedettségi család, releváns szelet, következmény és kapu szerint is közölni kell; egyetlen átlag elrejtheti a döntés szempontjából fontos hibát. Az offline értékelés önmagában nem igazolja az üzleti értéket, a biztonságot, a méltányosságot, a megfelelést vagy az éles üzemre való készséget. Egészítse ki működési megfigyeléssel, felhasználói kutatással és incidensvizsgálattal. Jogi, egészségügyi, pénzügyi, foglalkoztatási, biztonsági, adatvédelmi és más szabályozott döntést csak megfelelően képzett és felhatalmazott ember hozzon.