Rövid válasz: A mesterséges intelligencia modellek megfelelő értékeléséhez először is meg kell határozni, hogy mit jelent a „jó” a valódi felhasználó és a döntés szempontjából. Ezután reprezentatív adatokkal, szigorú szivárgás-ellenőrzésekkel és több mérőszámmal kell megismételhető értékeléseket készíteni. Stressz-, torzítás- és biztonsági ellenőrzéseket kell végezni, és valahányszor bármi megváltozik (adatok, promptok, szabályzat), újra kell futtatni a tesztelést, és a bevezetés után is folytatni kell a monitorozást.
Főbb tanulságok:
Sikerkritériumok : A metrikák kiválasztása előtt definiálja a felhasználókat, a döntéseket, a korlátozásokat és a legrosszabb esetet jelentő hibákat.
Ismételhetőség : Építsen fel egy olyan kiértékelési hámot, amely minden változtatásnál összehasonlítható teszteket futtat le.
Adathigiénia : Tartsa fenn a stabil felosztásokat, előzze meg a duplikációkat, és blokkolja a funkcióvesztést korán.
Bizalmi ellenőrzések : Stresszteszt robusztusság, méltányossági szeletek és LLM biztonsági viselkedések egyértelmű rubrikákkal.
Életciklus-fegyelem : Szakaszos bevezetés, az eltérések és incidensek monitorozása, valamint az ismert hiányosságok dokumentálása.
Cikkek, amiket esetleg ezután érdemes elolvasnod:
🔗 Mi az AI etikája?
Fedezze fel a felelős mesterséges intelligencia tervezését, használatát és irányítását irányító alapelveket.
🔗 Mi az AI-elfogultság?
Ismerje meg, hogyan torzítják az elfogult adatok a mesterséges intelligencia döntéseit és eredményeit.
🔗 Mi az AI skálázhatósága?
Ismerje meg a mesterséges intelligencia rendszereinek skálázását a teljesítmény, a költségek és a megbízhatóság szempontjából.
🔗 Mi az a mesterséges intelligencia?
A mesterséges intelligencia, típusok és valós felhasználási módjainak világos áttekintése.
1) Kezdjük a „jó” szó nem túlzó definíciójával
A mérőszámok, az irányítópultok és a benchmarkok bármilyen módosítása előtt döntsd el, hogy mit jelent a siker.
Pontosítás:
-
A felhasználó: belső elemző, ügyfél, klinikus, sofőr, egy fáradt ügyfélszolgálati munkatárs délután 4-kor…
-
A döntés: hitel jóváhagyása, csalás jelzése, tartalomjavaslat, jegyzetek összefoglalása
-
A legfontosabb kudarcok:
-
Hamis pozitívak (bosszantó) vs. hamis negatívak (veszélyesek)
-
-
A korlátok: késleltetés, kérésenkénti költség, adatvédelmi szabályok, magyarázhatósági követelmények, hozzáférhetőség
Ez az a rész, ahol a csapatok a „szép mutatókra” optimalizálnak a „jelentőségteljes eredmény” helyett. Ez sokszor előfordul. Úgy értem… sokszor.
Ennek a kockázattudatos (és nem megérzésalapú) szemléletnek a megőrzésére egy megbízható módszer, ha a tesztelést a megbízhatóság és az életciklus-kockázatkezelés köré csoportosítjuk, ahogyan a NIST is teszi az AI kockázatkezelési keretrendszerben (AI RMF 1.0) [1].
2) Mitől lesz jó egy „hogyan teszteljünk mesterséges intelligencia modelleket” című könyv ✅
Egy megbízható tesztelési megközelítésnek van néhány megkérdőjelezhetetlen pontja:
-
Reprezentatív adatok (nem csak tiszta laboratóriumi adatok)
-
Tiszta hasadékok szivárgásgátlóval (erről bővebben később)
-
Alapvonalak (egyszerű modellek, amelyeket érdemes legyőzni - a fiktív becslőknek okkal léteznek [4])
-
Több mutató (mert egy szám udvariasan, a szemedbe hazudik)
-
Stressztesztek (széles esetek, szokatlan bemenetek, ellenséges forgatókönyvek)
-
Emberi felülvizsgálati ciklusok (különösen generatív modellek esetén)
-
Monitoring az indulás után (mert a világ változik, a termékpaletta meghibásodik, és a felhasználók… kreatívak [1])
Továbbá: egy jó megközelítés magában foglalja annak dokumentálását, hogy mit teszteltél, mit nem, és mitől félsz. Ez a „mitől félek” rész kínosnak érződik – és itt kezd kialakulni a bizalom is.
Két dokumentációs minta, amelyek segítenek a csapatoknak következetesen őszintének maradni:
-
Modellkártyák (mire való a modell, hogyan értékelték, hol vall kudarcot) [2]
-
Adathalmazokhoz tartozó adatlapok (mik az adatok, hogyan gyűjtötték őket, mire szabad/nem szabad használni) [3]
3) Az eszközvalóság: amit az emberek a gyakorlatban használnak 🧰
Az eszközök opcionálisak. A jó értékelési szokások viszont nem.
Ha pragmatikus felállást szeretnél, a legtöbb csapat három csoporttal fog rendelkezni:
-
Kísérletkövetés (futtatások, konfigurációk, műtermékek)
-
Értékelési hám (ismételhető offline tesztek + regressziós csomagok)
-
Monitoring (eltolódásszerű jelek, teljesítmény-proxyk, eseményriasztások)
Példák, amiket sokat láthatsz a szabadban (nem ajánlások, és igen - funkciók/árak változása): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.
ötletet választasz ebből a részből: építs egy megismételhető kiértékelési hámot . Azt szeretnéd, hogy „nyomj meg egy gombot → összehasonlítható eredményeket kapj”, ne pedig azt, hogy „újrafuttasd a jegyzetfüzetet és imádkozz”.
4) Építsd fel a megfelelő tesztkészletet (és állítsd meg az adatszivárgást) 🚧
Megdöbbentően sok „elképesztő” modell csal véletlenül.
Standard ML esetén
Néhány nem túl szexi szabály, ami megmenti a karriert:
-
Tartsa a vonat/érvényesítés/tesztelés felosztásokat (és írja le a felosztási logikát)
-
elkerülése a különböző részeken (ugyanazon felhasználó, ugyanaz a dokumentum, ugyanaz a termék, majdnem ismétlődések)
-
Figyelj a funkciókiszivárgásokra (jövőbeli információk beszivárognak a „jelenlegi” funkciókba)
-
Használj alapértékeket (álbecsléseket), hogy ne ünnepeld a vereséget… semmiben [4]
Szivárgás definíciója (gyorsított változat): bármi, ami a betanításban/kiértékelésben olyan információkhoz ad hozzáférést a modellnek, amelyekkel a döntéshozatal idején nem rendelkezne. Lehet nyilvánvaló („jövőbeli címke”) vagy rejtett („esemény utáni időbélyeg-gyűjtő”).
LLM-ek és generatív modellek esetében
Egy utasítás- és irányelvrendszert építesz , nem csak egy „modellt”.
-
Hozz létre egy aranykészletet a promptokból (kicsi, kiváló minőségű, stabil)
-
Legutóbbi valós minták hozzáadása (anonimizált + adatvédelmet biztosító)
-
Tarts egy élvonalbeli csomagot : elgépelések, szleng, nem szabványos formázás, üres beviteli mezők, többnyelvű meglepetések 🌍
Egy gyakorlatias dolog, amit már többször is láttam: egy csapat „erős” offline pontszámmal küldi el a feladatot, majd az ügyfélszolgálat azt mondja: „Király. Magabiztosan kihagyja azt az egy mondatot, ami számít.” A javítás nem a „nagyobb modell” volt. Jobb tesztkérdések , világosabb rubrikák és egy regressziós csomag, amely pontosan ezt a hibamódot büntette. Egyszerű. Hatékony.
5) Offline értékelés: jelentőségteljes mutatók 📏
A metrikák rendben vannak. A metrikus monokultúra nem.
Besorolás (spam, csalás, szándék, triázs)
Használj többet a pontosságnál.
-
Pontosság, visszahívás, F1
-
Küszöbérték finomhangolása (az alapértelmezett küszöbérték ritkán „helyes” a költségeidhez képest) [4]
-
Konfúziós mátrixok szegmensenként (régió, eszköztípus, felhasználói kohorsz)
Regresszió (előrejelzés, árazás, pontozás)
-
MAE / RMSE (a hibák büntethetőségének módja alapján válasszon)
-
Kalibrációs jellegű ellenőrzések, amikor a kimeneteket „pontszámként” használják (a pontszámok megfelelnek-e a valóságnak?)
Rangsoroló / ajánló rendszerek
-
NDCG, MAP, MRR
-
Szeletelés lekérdezéstípus szerint (fej vs. farok)
Számítógépes látás
-
mAP, IoU
-
Osztályonkénti teljesítmény (a ritka osztályokban zavarba hoznak a modellek)
Generatív modellek (LLM-ek)
Itt kezdenek az emberek… filozofálni 😵💫
Gyakorlati lehetőségek, amelyek valódi csapatokban is működnek:
-
Emberi értékelés (legjobb jel, leglassabb hurok)
-
Páronkénti preferencia / győzelmi arány (A vs B könnyebb, mint az abszolút pontozás)
-
Automatizált szöveges metrikák (bizonyos feladatokhoz hasznosak, mások számára félrevezetőek)
-
Feladatalapú ellenőrzések: „A megfelelő mezőket kinyerte-e?” „Betartotta-e a szabályzatot?” „Megjelölte-e a forrásokat, amikor szükséges?”
Ha egy strukturált, „több metrikát és sok forgatókönyvet magában foglaló” referenciapontot szeretnénk, a HELM jó horgony: kifejezetten a pontosságon túlmutató értékelést helyez előtérbe, olyan dolgokra, mint a kalibráció, a robusztusság, az elfogultság/toxicitás és a hatékonysági kompromisszumok [5].
Egy kis kitérő: az írásminőség automatizált mérőszámai néha olyanok, mintha egy szendvicset mérlegelnénk. Nem semmi, de… na ne már 🥪
6) Robusztussági tesztelés: kicsit izzadj meg 🥵🧪
Ha a modelled csak rendezett bemenetekre működik, akkor gyakorlatilag egy üvegváza. Csinos, törékeny, drága.
Teszt:
-
Zaj: elgépelések, hiányzó értékek, nem szabványos unicode, formázási hibák
-
Elosztási váltás: új termékkategóriák, új szleng, új érzékelők
-
Szélsőséges értékek: tartományon kívüli számok, óriási hasznos terhelések, üres karakterláncok
-
„Ellenséges” bemenetek, amelyek nem hasonlítanak a betanítási halmazodra, de felhasználókra igenis hasonlítanak
LLM-ek esetén a következőket kell tartalmazni:
-
Azonnali injekciózási kísérletek (utasítások a felhasználói tartalomban elrejtve)
-
„Korábbi utasítások figyelmen kívül hagyása” minták
-
Eszközhasználati szélső esetek (hibás URL-ek, időtúllépések, részleges kimenetek)
A robusztusság egyike azoknak a megbízhatósági tulajdonságoknak, amelyek absztraktnak tűnnek, amíg incidensek nem történnek. Aztán… nagyon is kézzelfoghatóvá válik [1].
7) Elfogultság, méltányosság, és kinek működik mindez ⚖️
Egy modell lehet összességében „pontos”, miközben bizonyos csoportok esetében következetesen rosszabb. Ez nem egy apró hiba. Ez egy termék- és bizalomprobléma.
Gyakorlati lépések:
-
Értelmes szegmensek szerinti teljesítményértékelés (jogilag/etikailag megfelelő mérés esetén)
-
Hasonlítsa össze a hibaszázalékokat és a kalibrációt csoportok között
-
Proxy funkciók (irányítószám, eszköztípus, nyelv) tesztelése, amelyek érzékeny tulajdonságokat kódolhatnak
Ha ezt nem dokumentálod valahol, akkor alapvetően a jövőbeli önmagadat kéred meg egy bizalmi válság hibakeresésére térkép nélkül. A modellkártyák jó alkalmat kínálnak erre [2], és a NIST megbízhatósági keretrendszere egy erős ellenőrzőlistát ad arról, hogy mit is kellene magában foglalnia a „jónak” [1].
8) Biztonsági tesztelés (különösen LLM-ek számára) 🛡️
Ha a modelled képes tartalmat generálni, akkor nem csak a pontosságot teszteled. A viselkedést teszteled.
Tartalmazzon teszteket a következőkre vonatkozóan:
-
Tiltott tartalomgenerálás (irányelvek megsértése)
-
Adatvédelmi szivárgás (titkokat tükröz?)
-
Hallucinációk magas téttel bíró területeken
-
Túlzott elutasítás (a modell elutasítja a normál kéréseket)
-
Toxicitás és zaklatás kimenetelei
-
Az adatok kiszűrésére irányuló kísérletek azonnali befecskendezéssel
Egy megalapozott megközelítés a következő: definiálunk szabályzati szabályokat → tesztkérdéseket készítünk → kimeneteket pontozunk emberi + automatizált ellenőrzésekkel → minden alkalommal lefuttatjuk, amikor bármi változik. Ez a „minden alkalommal” rész a bérleti díj.
Ez tökéletesen illeszkedik az életciklus-kockázattal kapcsolatos gondolkodásmódba: irányítás, kontextus feltérképezése, mérés, kezelés, ismétlés [1].
9) Online tesztelés: szakaszos bevezetés (ahol az igazság lakik) 🚀
Az offline tesztek elengedhetetlenek. Az online jelenlét az, ahol a valóság sáros cipőben mutatkozik meg.
Nem kell flancosnak lenned. Csak fegyelmezettnek kell lenned:
-
Futtatás árnyék módban (a modell fut, nem befolyásolja a felhasználókat)
-
Fokozatos bevezetés (először kis forgalom, bővítés, ha egészséges)
-
Kimenetelek és incidensek nyomon követése (panaszok, eszkalációk, szabályzati hibák)
Még ha nem is kapsz azonnal címkéket, monitorozhatod a proxyjeleket és a működési állapotot (késleltetés, meghibásodási arány, költség). A lényeg: egy ellenőrzött módot szeretnél a hibák felfedezésére, mielőtt a teljes felhasználói bázisod ezt megtenné [1].
10) Telepítés utáni monitorozás: sodródás, lecsengés és csendes hiba 📉👀
A modell, amit teszteltél, nem az a modell, amivel végül együtt fogsz élni. Az adatok változnak. A felhasználók változnak. A világ változik. A folyamat hajnali 2-kor megszakad. Tudod, hogy van ez…
Monitor:
-
Bemeneti adatok eltolódása (sémaváltozások, hiányosságok, eloszlásbeli eltolódások)
-
Kimeneti eltolódás (osztálymérleg-eltolódások, pontszám-eltolódások)
-
Teljesítmény-proxyk (mivel a címkék késleltetése valós)
-
Visszajelzési jelek (nem megfelelő értékelés, újraszerkesztés, eszkaláció)
-
Szegmentális szintű regressziók (a csendes gyilkosok)
És állítson be olyan riasztási küszöbértékeket, amelyek nem túl rángatózóak. Egy folyamatosan visító monitort figyelmen kívül hagynak – mint egy autóriasztót a városban.
Ez a „monitorozás + időbeli fejlesztés” ciklus nem opcionális, ha fontos számodra a megbízhatóság [1].
11) Egy praktikus munkafolyamat, amit lemásolhatsz 🧩
Íme egy egyszerű, skálázható ciklus:
-
Siker- és hibamódok meghatározása (költségek/késleltetés/biztonság figyelembevételével) [1]
-
Adatkészletek létrehozása:
-
arany szett
-
éltokos csomag
-
friss valós minták (adatvédelem szempontjából biztonságos)
-
-
Válasszon mutatókat:
-
feladatmetrikák (F1, MAE, győzelmi arány) [4][5]
-
biztonsági mutatók (szabályzat-megfelelési arány) [1][5]
-
működési mutatók (késleltetés, költség)
-
-
Építs fel egy kiértékelő hámot (minden modell/kérdés szerinti változás esetén fut) [4][5]
-
Stressztesztek + versenytesztek hozzáadása [1][5]
-
Emberi felülvizsgálat egy mintán (különösen az LLM kimenetek esetében) [5]
-
Árnyékos szállítás + fokozatos bevezetés [1]
-
Megfigyelés + riasztás + átképzés fegyelmezetten [1]
-
A dokumentum eredményei egy modellkártya stílusú leírásban jelennek meg [2][3]
A képzés csillogó. A tesztelés viszont fárasztó.
12) Záró gondolatok + gyors összefoglaló 🧠✨
Ha csak néhány dologra emlékszel a mesterséges intelligencia modellek teszteléséről :
-
Használjon reprezentatív vizsgálati adatokat és kerülje a szivárgást [4]
-
Válasszon ki valós eredményekhez kapcsolódó mutatót
-
LLM-ek esetében emberi értékelésre és győzelmi arányon alapuló összehasonlításokra [5]
-
Tesztrobusztusság – a szokatlan bemenetek álcázott normál bemenetek [1]
-
Biztonságosan gördüljön ki és figyelje a rendszert, mert a modellek elsodródnak és a csővezetékek elszakadnak [1]
-
Dokumentáld, hogy mit teszteltél, és mit nem (kényelmetlen, de hasznos) [2][3]
A tesztelés nem csak arról szól, hogy „bebizonyítsd, működik”. Hanem arról, hogy „megtaláld, hogyan vall kudarcot, mielőtt a felhasználók megtennék”. És igen, ez kevésbé szexi – de ez az a része, ami talpon tartja a rendszeredet, amikor a dolgok ingataggá válnak… 🧱🙂
GYIK
A legjobb módszer a mesterséges intelligencia modellek tesztelésére, hogy azok megfeleljenek a valós felhasználói igényeknek
Kezd azzal, hogy a „jó” fogalmát a valódi felhasználó és a modell által támogatott döntés szempontjából definiálod, ne csak egy ranglista-metrikát. Azonosítsd a legmagasabb költségű hibamódokat (téves pozitív vs. téves negatív), és határozz meg olyan szigorú korlátokat, mint a késleltetés, a költség, az adatvédelem és a magyarázhatóság. Ezután válassz olyan metrikákat és teszteseteket, amelyek tükrözik ezeket az eredményeket. Ez megakadályozza, hogy egy „szép metrikát” optimalizálj, amely soha nem eredményez jobb terméket.
Sikerkritériumok meghatározása az értékelési mutatók kiválasztása előtt
Írd le, hogy ki a felhasználó, milyen döntést hivatott támogatni a modell, és hogyan néz ki a „legrosszabb eseti hiba” éles környezetben. Add hozzá a működési korlátozásokat, mint az elfogadható késleltetés és a kérésenkénti költség, valamint az irányítási igényeket, mint például az adatvédelmi szabályok és a biztonsági irányelvek. Ha ezek egyértelműek, a mérőszámok a megfelelő dolog mérésének módjává válnak. Ezen keretrendszer nélkül a csapatok hajlamosak a legkönnyebben mérhető dolgok optimalizálása felé sodródni.
Az adatszivárgás és a véletlen csalás megelőzése a modellértékelés során
Tartsa stabilan a betanítási/érvényesítési/tesztelési szakaszokat, és dokumentálja a szakaszok logikáját, hogy az eredmények reprodukálhatók maradjanak. Aktívan blokkolja a duplikátumokat és a majdnem duplikátumokat a szakaszok között (ugyanazon felhasználó, dokumentum, termék vagy ismétlődő minták). Figyeljen a funkciószivárgásra, ahol a „jövőbeli” információk időbélyegeken vagy esemény utáni mezőkön keresztül csúsznak be a bemenetekbe. Egy erős alapvonal (akár álbecslők is) segít észrevenni, mikor ünnepli a zajt.
Mit kell tartalmaznia egy értékelési rendszernek, hogy a tesztek a változások során is megismételhetők legyenek?
Egy praktikus eszköz minden modellen, prompton vagy szabályzatváltozáson összehasonlítható teszteket futtat le ugyanazon adatkészletek és pontozási szabályok használatával. Jellemzően tartalmaz egy regressziós csomagot, átlátható metrikák irányítópultjait, valamint tárolt konfigurációkat és műtermékeket a nyomon követhetőség érdekében. Az LLM rendszerek esetében stabil „aranykészletre” is szükség van promptokból, valamint egy esettanulmány-csomagra. A cél a „gombnyomás → összehasonlítható eredmények”, nem pedig a „jegyzetfüzet újrafuttatása és imádkozás”
Mérőszámok a pontosságon túlmutató AI-modellek teszteléséhez
Használjon több metrikát, mert egyetlen szám elrejthet fontos kompromisszumokat. Osztályozáshoz párosítsa a pontosság/visszahívás/F1 értékeket küszöbhangolással és zavaró mátrixokkal szegmensenként. Regresszióhoz válassza a MAE vagy az RMSE értéket attól függően, hogy hogyan szeretné büntetni a hibákat, és adjon hozzá kalibrációs stílusú ellenőrzéseket, ha a kimenetek pontszámokhoz hasonlóan működnek. Rangsoroláshoz használjon NDCG/MAP/MRR és szeletelést fej és farok lekérdezések segítségével az egyenetlen teljesítmény kiszűrése érdekében.
LLM-kimenetek értékelése, ha az automatizált mérőszámok nem elegendőek
Tekintsd úgy, mint egy prompt-és-szabályzat rendszert, és pontozd a viselkedést, ne csak a szöveg hasonlóságát. Sok csapat az emberi értékelést páros preferenciával (A/B győzelmi arány) kombinálja, valamint feladat-alapú ellenőrzésekkel, mint például a „megfelelő mezőket kinyerte-e?” vagy a „követte-e a szabályzatot”. Az automatizált szöveges metrikák szűk esetekben segíthetnek, de gyakran nem veszik figyelembe azt, ami a felhasználókat érdekli. Az egyértelmű rubrikák és egy regressziós csomag általában többet számít, mint egyetlen pontszám.
Robusztussági tesztek futtatása, hogy a modell ne szakadjon meg zajos bemeneteken
Stressztesztelje a modellt elgépelésekkel, hiányzó értékekkel, furcsa formázással és nem szabványos unicode-dal, mivel a valódi felhasználók ritkán rendesek. Adjon hozzá eloszlásbeli eltolódási eseteket, például új kategóriákat, szlenget, érzékelőket vagy nyelvi mintákat. Adjon hozzá szélsőséges értékeket (üres karakterláncok, hatalmas hasznos adatok, tartományon kívüli számok) a törékeny viselkedés felszínére. LLM-ek esetén tesztelje a prompt injekciós mintákat és az eszközhasználati hibákat, például az időtúllépéseket vagy a részleges kimeneteket is.
Az elfogultsággal és a méltányossággal kapcsolatos problémák ellenőrzése anélkül, hogy elvesznénk az elméletben
Értékelje a teljesítményt értelmes szeleteken, és hasonlítsa össze a hibaszázalékokat és a kalibrációt olyan csoportok között, ahol a mérés jogilag és etikailag helyénvaló. Keressen olyan helyettesítő jellemzőket (például irányítószám, eszköztípus vagy nyelv), amelyek közvetve érzékeny tulajdonságokat kódolhatnak. Egy modell „összességében pontosnak” tűnhet, miközben bizonyos kohorszok esetében következetesen kudarcot vall. Dokumentálja, hogy mit mért és mit nem, hogy a jövőbeni változtatások ne vezessék be csendben újra a regressziókat.
Biztonsági és védelmi tesztek a generatív mesterséges intelligencia és az LLM rendszerek esetében
Teszteljen tiltott tartalomgenerálást, adatvédelmi szivárgást, hallucinációkat magas téttel bíró területeken, valamint túlzott elutasítást, ahol a modell blokkolja a normál kéréseket. Tartalmazzon azonnali injektálási és adatlopási kísérleteket, különösen akkor, ha a rendszer eszközöket használ vagy tartalmat kér le. Egy megalapozott munkafolyamat a következő: definiáljon szabályzatszabályokat, építsen fel egy tesztkérdés-készletet, pontozzon emberi és automatizált ellenőrzésekkel, és futtassa újra, amikor a kérdések, az adatok vagy a szabályzatok megváltoznak. A következetesség a fizetett bérleti díj.
MI-modellek bevezetése és monitorozása a bevezetés után az eltérések és az incidensek észlelése érdekében
Használjon fokozatos bevezetési mintákat, például árnyék módot és fokozatos forgalomnövelést, hogy a hibákat a teljes felhasználói bázis előtt megtalálja. Figyelje a bemeneti eltolódást (sémaváltozások, hiányosságok, eloszlásbeli eltolódások) és a kimeneti eltolódást (pontszám-eltolódások, osztályegyensúly-eltolódások), valamint a működési állapotot, például a késleltetést és a költségeket. Kövesse nyomon a visszajelzési jeleket, például a szerkesztéseket, eszkalációkat és panaszokat, és figyelje a szegmens szintű regressziókat. Ha bármi megváltozik, futtassa újra ugyanazt a kábelköteget, és folyamatosan figyelje.
Referenciák
[1] NIST - Mesterséges Intelligencia Kockázatkezelési Keretrendszer (AI RMF 1.0) (PDF)
[2] Mitchell et al. - „Modellkártyák modelljelentésekhez” (arXiv:1810.03993)
[3] Gebru et al. - „Adatlapok adatkészletekhez” (arXiv:1803.09010)
[4] scikit-learn - „Modellválasztás és értékelés” dokumentáció
[5] Liang et al. - „Nyelvi modellek holisztikus értékelése” (arXiv:2211.09110)