Reprodukálhatóság és a végpontok közötti projekt: Mindent kombinálunk — Mesterséges intelligencia a mesterséges intelligencia és a gépi tanulás mérnöki területén

Nyereség:

Lehetőség a reprodukálhatóság biztosítására négy pillérrel (magrögzítés, adatverziók, adathordozók lefagyasztása, kísérletfigyelés), és ugyanazt az eredményt produkálja ugyanazon futtatás megismétlésekor
Lehetőség a modul összes állomásának (metrikák, adatok, modell, LLM-komponensek, eval, fairness, biztonság, terjesztés, monitorozás) kombinálására egy végpontok közötti láncban
Képes ellenőrizni, hogy a kritikus döntés az embernél marad-e minden megállónál, és a projektet auditálható módon dokumentálni

Egy ML projekt legálomosabb kudarca nem összeomlás; – Többé nem éri el ugyanazt az eredményt. Ha nem tudja reprodukálni annak a modellnek a pontszámát, amelyet három hónappal ezelőtt gyártásba bocsátott, akkor nem igazán irányítja azt a modellt. Ebben a záróegységben elmélyítjük a reprodukálhatóságot: azt a képességet, hogy ugyanazt az eredményt ugyanazzal a bemenettel megbízhatóan elérjük, és a teljes modult egy végponttól végpontig terjedő projektfegyelemben kombináljuk.

Miért nehéz a reprodukálhatóság?

A közönséges szoftverekben ugyanaz a kód ugyanazt a kimenetet adja. Az ML-ben sokkal több változó határozza meg az eredményt:

Véletlenszerűség: Adatkeverés, súlyozás inicializálása, adatfelosztás – mindez a véletlenszerűségen múlik.
Adatok: Ugyanaz a kód különböző modelleket állít elő különböző adatverziókkal.
Környezet: A könyvtári verziók, a hardver (CPU/GPU), még az operációs rendszer is megváltoztathatja az eredményt.
Rejtett eset: egy nem mentett hiperparaméter, egy kézi előfeldolgozási lépés, egy megjegyzés nélküli kijelölés.

A reprodukálhatóság nem „szép, ha megvan”, hanem tudományos és műszaki követelmény. Nem reprodukálható eredmény olyan állítás, amelyet nem lehet bizonyítani.

A reprodukálhatóság négy pillére

1. Javítsa ki a véletlenszerűséget. Állítsa be az összes véletlenszerű magot egy helyen: adatfelosztás, modell inicializálás, adatkeverés. A fix vetőmag az alapja az "ugyanaz az eredmény, ha megismétli ugyanazt a futtatást" garancia.

2. Verziózza az adatokat. Jegyezze fel, hogy az egyes kísérleteket melyik adatverzióval végezték el (adatverziók a 2. egységben). A „legfrissebb adatok” homályos; A "data version v3, hash abc123" pontos.

3. Fagyassza le a táptalajt. Rögzítse az összes függőséget a pontos verziójukhoz (pl. olyan pontos verziók, mint a numpy==1.26.4 a requirements.txt fájlban, vagy egy tárolókép). A "legújabb verzió" egyszer mindent összetör.

4. Kövessen nyomon mindent (kísérletkövetés). Automatikus mentés minden kísérlethez: kódverzió (git commit), adatverzió, minden hiperparaméter, metrika és kimeneti struktúra. A kísérletkövető eszközök, például az MLflow, Weights & Biases ezt szisztematikusan teszik. Regisztráció nélkül a "melyik beállítás volt a legjobb" kérdés megválaszolatlan marad.

Vigyázat: "Később emlékezni fogok" a legdrágább tévedés. Két hét múlva már nem fog emlékezni arra, hogy melyik magot, melyik adatot, melyik hiperparamétert használta. Az automatikus követés kiküszöböli a memóriától való függést.

Gyenge megközelítés / Erős megközelítés

Gyenge: "Megtaláltam a legjobb modellt, rajta van a notebookon, szerintem 89% volt a pontszáma."

Erős: "Futtatás #147 a kísérletkövető eszközben: git commit a3f9c, adatverzió v3 (hash abc123), seed 42, minden hiperparaméter regisztrálva, teszt PR-AUC 0.887. Amikor újra lefuttatom ugyanazt a parancsot, bitenként ugyanazt az eredményt kapom. A modell ettől a beállításjegyzékbeli futtatástól függ."

A különbség: az erős megközelítésben az eredmény nem egy memória, hanem egy rögzített és felügyelt láncon alapul. Mindenki mindig ugyanazt az eredményt tudja produkálni.

Végponttól végpontig terjedő projekt: modul kombinációja

Most egyesítsük a teljes modult egyetlen projektfolyamattá. Egy igazi ML rendszer átmegy ezeken a megállókon, és mindegyik megálló az előzőre épül:

Probléma meghatározása: Mit oldunk meg, hogyan mérjük a sikert (3. egység: megfelelő mérőszám, üzleti kontextus). A mérőszám és a küszöb kezdettől fogva egyértelmű.
Adatfolyam: Gyűjtés, érvényesítés, tisztítás, szivárgásmentes particionálás, verziókezelés (2. egység).
Modellfejlesztés: Képzés, alapvonal összehasonlítás, keresztellenőrzés, kemény mag (3. egység + ez az egység).
LLM összetevők (ha van): RAG (4. egység) és/vagy ügynökök (5. egység); szükség esetén finomhangolás (6. egység).
Értékelés: eval klaszter él és biztonsági esetekkel, többrétegű eval LLM rendszerekben (8. egység).
Igazságügyi és etikai audit: Alcsoport elemzés, mintakártya, magyarázhatóság (10. egység).
Biztonsági audit: azonnali befecskendezés, adatvédelem, ellátási lánc (9. egység).
Forgalmazás: Csomagolás, fokozatos elosztás, visszaállítás, modellnyilvántartás (7. egység).
Felügyelet: Háromrétegű felügyelet, drift riasztások (8-as egység).
Reprodukálhatóság: vetőmag, adatverzió, adathordozó és kísérletkövetés a teljes láncban (ez az egység).

Ebben a folyamatban az AI egy gyorsító és egy tervgenerátor minden megállónál; de a mérőszámok kiválasztása, az adatokkal kapcsolatos döntések, a méltányos prioritások meghatározása, a telepítési küszöb és a kiadás jóváhagyása – a kritikus döntések az embernél maradnak. Ez a modul lényege.

Dokumentáció: a jövő meghálálja

Egy jó ML projekt dokumentálja magát. Legalább a következőket kell megírni: probléma- és sikerkritériumok, adatforrás és verzió, modellválasztás és indoklás, értékelési eredmények (beleértve az alcsoportokat is), ismert határok és kockázatok, telepítési és visszakeresési eljárás, monitoring terv. Ez a dokumentum annak a személynek a legjobb barátja (talán te vagy), aki hat hónap után visszatér a projektbe.

három mini tok

1. eset – Elveszett eredmény. Egy mérnök kiképzett egy nagyszerű modellt, de nem javította ki a magot, és nem mentette el az adatverziót. Amikor otthagyta a munkát, senki sem tudta reprodukálni ezt az eredményt; a modell "fekete doboz legendává" vált, és végül a semmiből építették. Hetek teltek el. Tanulság: a nem reprodukálható eredmény nem létező eredmény.

2. eset – A környezet összeomlása. Az egyik csapat nem oldotta meg a függőséget. Amikor egy könyvtárat automatikusan frissítettek, a modell kimenetei csendben megváltoztak, és a termelés megszakadt. Napokba telt, mire megtalálták a problémát. Amikor a függőségeket lefagyasztották, és a végleges verziókkal konténerbe helyezték, a probléma nem jelentkezett újra. Tanulság: fagyassza le a környezetet.

3. eset – A megfigyelés ereje. Egy csapat automatikusan figyelt minden kísérletet. Három hónappal később egy hatósági audit során azt a kérdést válaszolták meg, hogy "milyen adatokkal, milyen beállításokkal, milyen csoportokban milyen teljesítményt ért el?" perceken belül teljes felvétellel. Az ellenőrzés zökkenőmentesen zajlott. Tanulság: a monitorozás megfelelési eszköz, nem csak mérnöki eszköz.

Másolható sablonok

Végezzen reprodukálhatósági ellenőrzést ehhez az ML-projekthez.- Minden véletlenszerűségi mag rögzítve van (felosztás, inicializálás, keverés)?- Az adatok verziószámmal vannak ellátva?- A függőségek pontos verziókra vannak rögzítve?- Minden kísérletet (kód véglegesítés, adat, hiperparaméter, metrika) nyomon követnek? Írjon konkrét lépéseket a javításhoz minden egyes hiányzó oszlop esetében. Projektstruktúra: [leírás]

Készítsen tervvázlatot ehhez a teljes körű ML-projekthez. Probléma: [leírás] Fedje le a következő megállókat, és jelölje meg, hol van az EMBER döntése az egyes megállóknál: probléma/metrika, csővezeték, modell, (RAG/ügynök/finomhangolás?), eval, fairness, security, terjesztés, monitoring, reprodukálhatóság. Írja le a fő kockázati és ellenőrzési lépést minden megálláshoz.

Készítsen műszaki dokumentációs sablont ehhez a projekthez. Szakaszok: probléma+sikerkritériumok, adatok (forrás+verzió), modellválasztások+indoklás, értékelés (alcsoportokkal együtt), ismert határok+kockázatok, telepítés+visszaállítás, monitoring terv. Adja meg kérdésként a kitöltendő mezőket az egyes szakaszokhoz.

Ellenőrizze a kísérlet megfigyelési beállításait: Minden futtatáskor automatikusan mentésre kerül: git véglegesítés, adatverzió/hash, minden hiperparaméter, minden metrika, környezet (könyvtárverziók)? Ugyanazt az eredményt kapom, ha újra lefutom ugyanazt a futást? Beállítás: [leírás]. Sorolja fel a hibákat és a javításokat.

Reprodukálhatósági oszlopok táblázata

oszlopban

Mi van rögzítve

Jármű példa

véletlenszerűség

minden mag

vetőmag beállítás

Adatok

Adatverzió/hash

DVC

környezet

Könyvtári verziók

követelmények pin, Docker

Monitoring

Kód+adat+beállítás+mutató

MLflow, W&B

Gyakori hibák

Nem rögzíti a magot. Az eredmény nem ismételhető meg.
Nem menti az adatverziót. – Milyen adatokkal? válasz nélkül marad.
Nem fagyasztó függőség. Egy frissítés csendben megtör mindent.
A kísérleteket az emlékezetre hagyva. Két héttel később semmire sem emlékszünk.
A kritikus döntések meghozatalát a mesterséges intelligenciára bízzuk. A mérőszámoknak, az igazságosságnak és az elosztási döntéseknek az embereknél kell maradniuk.
A dokumentáció elhalasztása. A leendő csapat (és Ön) megfizeti az árát.

Összefoglalva

A reprodukálhatóság a komoly ML tervezés jele: a nem reprodukálható eredmény a bizonyíthatatlan állítás. Négy oszloppal rendelkezik – a véletlenszerűség javítása, a verzióadatok, a környezet lefagyasztása, az egyes kísérletek nyomon követése. Egy end-to-end projekt ennek a modulnak az összes állomását (metrika, adat, modell, LLM-komponensek, eval, fairness, security, terjesztés, monitoring) egyesíti egy összekapcsolt láncban; A mesterséges intelligencia minden megállónál gyorsító, de a kritikus döntések az embernél maradnak. Mindent dokumentáljon – a jövőbeli csapathoz és az auditokhoz. Ez a tudományág az a keret, amely fenntartja mindazt, amit a modul során tanul.

Pályázati feladat

Ellenőrizze az ML projektet négy reprodukálhatósági pillér alapján: a magok változtathatatlanok, az adatok verziószámmal vannak ellátva, a környezet lefagyott, a kísérletek nyomon követhetők? Javítsa ki a hiányzó oszlopokat, és bizonyítsa be, hogy ugyanazt a futtatást kétszer is lefuttathatja, és ugyanazt az eredményt érheti el. Ezután adja ki a projekt végpontok közötti folyamatát (10 megálló) egy oldalon, és jelölje be minden megállóban "hol van az emberi döntés". Végül írjon egy rövid műszaki dokumentáció vázlatot.

ellenőrző lista

[ ] Minden véletlenszerűségi mag javítva.
[ ] Minden kísérletnél rögzítésre kerül az adatverzió/hash.
[ ] A függőségek szilárd verziókra vannak fagyasztva (tű/tároló).
[ ] A rendszer minden kísérletet automatikusan felügyel (kód+adat+beállítás+metrika).
[ ] Ha megismétlem ugyanazt a futást, ugyanazt az eredményt kapom.
[ ] Igazoltam és dokumentáltam, hogy a végpontok közötti áramlásban a kritikus döntéseket az emberek hozzák meg.

Modul vizsga

1. ML mérnökként mi a legjobb megközelítés a mesterséges intelligencia munkafolyamatban való elhelyezéséhez?

A) Az AI egy gyorsító az alacsony kockázatú vállalkozásoknál; Az olyan kritikus döntések, mint a mérőszámok, adatok és termelés, érvényesek maradnak, és az emberre bízzák ✔
B) Amíg az AI kimenetei jól néznek ki, nincs szükség ellenőrzésre
C) Ha a modell gyártásba helyezéséről szóló döntést a mesterséges intelligenciára bízzuk, időt takarít meg.
D) A mesterséges intelligencia csak szövegírásra hasznos, semmi köze az adat- és modellmunkához

Leírás: A mesterséges intelligencia egy erőteljes gyorsító az alacsony kockázatú, könnyen ellenőrizhető feladatokhoz, mint például a kód, az adatkivonatok és a dokumentumok; A pénzt, a titoktartást és a jogi felelősséget érintő döntések felelőssége azonban, mint például a mérőszám kiválasztása, amely az adatok betanításába és a modell gyártásba helyezésébe kerül, a képzett mérnököt és csapatot terheli. Minden kimenetet nem szabad ellenőrzés nélkül használni.

2. Miért kerül a sémaellenőrzés az adatfolyam elejére?

A) Mert közvetlenül növeli a modell pontosságát
B) Mert szükségtelenné teszi az adatok verziószámát
C) Mert a sérült adatokat a legkorábbi és legolcsóbb ponton fogja fel, és megakadályozza, hogy azok a következő lépésekbe szivárogjanak ✔
D) Mert szükségtelenné teszi a címkézést

Magyarázat: Minél korábban észlelik a sérült adatokat, annál olcsóbb a javításuk. A sémaellenőrzés megakadályozza, hogy a korrupt adatok csendben szivárogjanak be a képzésbe vagy a gyártásba azáltal, hogy a sor elején elutasítja az elvárt típuson és tartományon kívüli adatokat (pl. 100-szoros áreltolódás mértékegységváltással); Ugyanez a hiba a gyártás során sokszorosan drágább.

3. Mi a helyes megközelítés, amikor az adatokat tanításra és tesztelésre osztjuk egy idővel (idősorral) kapcsolatos probléma esetén?

A) Véletlenszerű felosztás használata, mert mindig ez a legigazságosabb módszer
B) Időbeli felosztás használata: előzze meg a szivárgást a múltban való tanulással és a jövőbeni teszteléssel ✔
C) Az összes adat felhasználása képzésként és tesztelésként
D) A tesztadatok beépítése a skálázási paraméterekbe az edzés előtt

Magyarázat: Az idősorok véletlenszerű felosztása olyan „jövőbe látó” előnyt biztosít a modellnek, amely soha nem fog megtörténni a gyártás során, és mesterségesen felfújja a mutatókat (időbeli szivárgás). A helyes az időbeli felosztás: edz a múlttal, teszteld a jövőben. Ez azt a tényleges teljesítményt méri, amely a termelésben tartja.

4. Miért félrevezető a pontosság egy 1,5%-os pozitív osztályaránnyal rendelkező csalásfelderítési modellben?

A) Mivel a Pontosság mindig alacsony kiegyensúlyozatlan adatok esetén
B) Mivel a Pontosság csak regressziós feladatoknál használható
C) Mivel a pontosság számítása nagy feldolgozási teljesítményt igényel
D) Még a többségi osztályt előrejelző elenyésző modell is nagyon pontos lehet, így elrejti a valódi sikert ✔

Magyarázat: Kiegyensúlyozatlan adatok esetén még egy alapmodell is, amely azt mondja, hogy „mindent negatívnak hív” körülbelül 98,5%-os pontosságot ér el, de egyetlen csalást sem fog el. Ezért a kiegyensúlyozatlan osztályozásnál a pontosság helyett a precíziót, a visszahívást, az F1-et vagy a PR-AUC-t használják, és minden metrikát egy alapmodell szerint értelmeznek.

5. Miért elengedhetetlen az alapvonal összehasonlítása, amikor egy modell mérőszámáról beszélünk?

A) Mert az alapmodell mindig jobb, mint a valódi modell
B) Mert csak egy egyszerű alapmodellhez képest egyértelmű, hogy egy mérőszám értelmes-e vagy sem ✔
C) Mert az alapmodell szükségtelenné teszi a keresztellenőrzést
D) Mert az alapmodellt minden jelentésben törvény írja elő

Magyarázat: A mérőszám önmagában nem jó vagy rossz; Alapmodell szerint jó vagy rossz. A '85%-ban helyes' mondat azt jelenti, hogy szinte értéktelen, ha az alapmodell már 84%-ot kap, és tökéletes, ha 50%-ot. Összehasonlítási horgony nélkül a mérőszám értelmetlen.

6. Melyik a legkritikusabb biztonsági elem, amelyet a RAG (Retrieval-Augmented Generation) rendszer gyártási promptjában kell szerepeltetni?

A) Utasítás, hogy csak a megadott forrásra hagyatkozz, ha a forrás nem létezik, mondd azt, hogy „nem tudom”, és hivatkozz a forrásra ✔
B) Mondja meg a modellnek, hogy a lehető leghosszabb és kreatív válaszokat adjon
C) A modell saját oktatási tudását helyezi előtérbe az erőforrásokkal szemben
D) Végezze el az összes utasítást a parancsként hozott dokumentumokban

Magyarázat: A RAG egyetlen legfontosabb utasítása, hogy mondja meg a modellnek, hogy csak a megadott forrásra hagyatkozzon, és ha az információ nem szerepel a forrásban, akkor mondja azt, hogy „nem tudom”, és idézze a forrást anélkül, hogy kitalálná. E triász nélkül a modell figyelmen kívül hagyhatja a kontextust, hallucinációkat idézhet elő, és a válasz ellenőrizhetetlenné válik.

7. Egy RAG rendszer helytelen válaszokat ad. Hol a legjobb hely a diagnózis megkezdéséhez?

A) Mérési elővétel (Recall@K): megérkezik-e valaha a megfelelő darab? ✔
B) Azonnal cserélje ki a modellt egy nagyobbra
C) Véletlenszerűen változtassa meg a promptot, és folytassa a próbálkozást
D) Minden dokumentum beágyazása a modellbe finomhangolással

Magyarázat: A RAG leggyengébb láncszeme általában a letöltés, nem az előállítás. Ha a megfelelő alkatrészt soha nem hozza meg, a modell nem tudja előállítani ezt az információt, bármennyire is javítja a promptot. Ezért először a Recall@K-t megmérjük, hogy megnézzük, a megfelelő alkatrész érkezett-e meg; Ha a lekérés jó, akkor a produkciót és a promptot megvizsgáljuk.

8. Milyen tevékenységeket kell emberi jóváhagyás mögé állítani, amikor eszközt adunk át egy ügynöknek?

A) Nincs; Az ügynöknek képesnek kell lennie minden művelet önálló végrehajtására
B) Csak visszafordítható műveletek, például adatok olvasása és keresése
C) Visszafordíthatatlan vagy nagy hatást kiváltó műveletek, mint például pénzátutalás, törlés, küldés ✔
D) Olyan műveletek, amelyek csak számításokat tartalmaznak

Leírás: A tevékenységek kockázati szint szerint vannak elválasztva. Az olyan visszakereshető feladatok, mint az olvasás, keresés, számítás és piszkozatok generálása önállóan is elvégezhetők; Azonban az olyan visszafordíthatatlan vagy nagy hatású tevékenységekhez, mint a pénz átutalása, e-mailek küldése, adatok törlése, rendelések leadása stb., emberi jóváhagyásra van szükség. Minden visszavonhatatlan intézkedéshez beleegyezés szükséges.

9. Mi a legjobb tervezési megközelítés a közvetett azonnali befecskendezés kockázatával szemben?

A) Elég egyetlen mondatot hozzáadni a „rossz utasítások figyelmen kívül hagyása” kifejezéshez
B) Adjon nagyobb tekintélyt a modellnek a külső tartalom utasításaira támaszkodva
C) Nem tesz semmilyen óvintézkedést, mert az injekció beadása elkerülhetetlen
D) A külső tartalom megbízhatatlan adatként való elkülönítése és réteges védelem létrehozása minimális jogosultsággal, jóváhagyással és kimeneti ellenőrzéssel ✔

Leírás: Az ügynök vagy RAG által feldolgozott külső tartalom, például weboldal, dokumentum, e-mail stb., nem megbízható adat, és titkos utasításokat tartalmazhat. A helyes megközelítés a többrétegű védekezés: a külső tartalom elkülönítése „adatként, nem parancsként” egyértelmű elválasztójelekkel, minimális jogosultság alkalmazása, visszafordíthatatlan műveletek emberi jóváhagyáshoz kötése és a kimenet auditálása. Egyetlen utasítássor nem elég.

10. Mi a fő különbség annak eldöntésekor, hogy egy problémát finomhangolással vagy RAG-val kell-e megoldani?

A) Az információs problémák jobban megoldhatók RAG-val, a viselkedési/formátum-problémák jobban megoldhatók finomhangolással ✔
B) Minden problémát mindig finomhangolással kell megoldani
C) A RAG-t csak kódgenerálásra, a finomhangolást csak a fordításra használjuk
D) A finomhangolás mindig olcsóbban és gyorsabban frissíthető, mint a RAG

Magyarázat: A finomhangolás gyenge és kockázatos a modell új információinak tanítása során; de erőteljes a tanítási viselkedés, formátum, hangnem és stílus terén. A „modellcég nem ismeri az adatainkat” információs probléma, és a RAG-hoz tartozik. „A modell mindig a mi szigorú formátumunkban jelenjen meg” viselkedési probléma, és finomhangolásra alkalmas. Ezenkívül a finomhangolás előtt azonnali és néhány felvételt kell készíteni.

11. Melyik kötelező a biztonságos üzembe helyezés érdekében egy új modell gyártásba kerülésekor?

A) Ha a modell jó a tesztelésben, nyissa meg közvetlenül a 100%-os forgalom számára
B) Egyáltalán nem állítja be a felügyeletet a telepítés után
C) Fázisos telepítés (árnyék/kanári) és előre tesztelt visszaállítási terv ✔
D) A modell közzététele akkor is, ha az értékelési küszöb nem teljesül

Magyarázat: Az új modell közvetlen megnyitása a teljes forgalom számára kockázatos; Ha rossz, mindenki érintett. Az a helyes, hogy ez egy fokozatos disztribúció (árnyék, kanári), és minden disztribúciónak van egy tesztelt visszaállítási terve. A disztribúció nem teljes visszakövetési terv nélkül; Az, hogy perceken belül vissza lehet térni az előző verzióra, megvédi a felhasználót, ha a modell váratlanul viselkedik a gyártás során.

12. Hogyan bukhat meg egy ML modell „csendben” a gyártás során, és hogyan lehet ezt elkapni?

A) A modell összeomlik; a szervernaplók ezt mutatják
B) Hibás előrejelzések készítésével tévedés nélkül; ✔ Rögzíti a működési, bemeneti és kimeneti réteges felügyeletet
C) A modell soha nem tud csendben meghibásodni, mindig riaszt
D) Pusztán a késleltetés figyelése elegendő a degradáció észleléséhez

Magyarázat: A modell meghibásodhat egyszerűen azáltal, hogy hibás előrejelzéseket készít anélkül, hogy összeomolna vagy hibákat adna; Ennek fő oka az adatsodródás és a koncepciósodródás. Csak a működési mutatók (latencia, hibaarány) figyelése nem elegendő; A bemeneti eloszlást és a kimeneti/előrejelzési eloszlást is figyelemmel kell kísérni. A bemeneti eltolódás korai figyelmeztetést ad, ha a tényleges eredmény késik.

13. Milyen alapelvre van szükség, ha az LLM-mint bírót használjuk egy LLM-rendszer értékeléséhez?

A) Az LLM-referee mindig helyes, az emberi ellenőrzés szükségtelen
B) A játékvezetőnek csak a válasz hossza alapján kell döntenie.
C) A szabályokon alapuló ellenőrzéseket és az emberi értékelést teljesen el kell vetni, ha játékvezetőket használnak
D) A bírói pontszámokat emberjelölt mintával kell kalibrálni, és meg kell mérni a torzításukat, mielőtt megbízhatnának bennük ✔

Leírás: Az LLM-referee is modell; Lehet hallucinatív, elfogult (hosszú, magabiztos válaszokat részesít előnyben) és következetlen. Ezért a játékvezetői pontszámokat emberileg megjelölt mintával kell kalibrálni, és a gyártási döntés meghozatala előtt mérni kell azok szisztematikus torzítását. Az igazolatlan játékvezető hamis bizalmat ad.

14. Miért nem megfelelő az általános pontosság vizsgálata a modell torzításának értékelésekor?

A) Az általános pontosság elegendő, mert mindig a legrosszabb csoport teljesítményét tükrözi
B) Az általános pontosság önmagában nem elegendő, mivel elfedheti az alcsoportok közötti szisztematikus különbséget (rejtett diszkriminációt) ✔
C) Mert a pontosság egy mérőszám, aminek semmi köze az elfogultsághoz
D) A torzítás csak a modellből származik, és semmi köze az adatokhoz.

Magyarázat: Az általános pontosság elhomályosíthatja az alcsoportok közötti szisztematikus különbségeket. Például míg az általános pontosság 88%, a felidézés 91% lehet az egyik csoportban és 67% egy másik csoportban; A modell szisztematikusan kihagyja ezt a csoportot. Ezért a modellt alcsoportok (demográfia/szegmens) alapján kell értékelni, és az érintettekkel együtt kell eldönteni, hogy az igazságosság melyik definícióját kell előnyben részesíteni.

15. Milyen négy dolgot kell együtt rögzíteni ahhoz, hogy egy ML eredmény reprodukálható legyen?

A) Csak a modell neve, mérete, ára és kiadási dátuma
B) Csak a GPU márka és az internet sebessége
C) Csak a modell végső pontossági pontszáma; a többit meg lehet őrizni a memóriában
D) Véletlenségi mag, adatverzió, környezet (függőségi verziók) és kísérletkövetés ✔

Leírás: A reprodukálhatóság négy pilléren keresztül érhető el: a véletlenszerű magok rögzítése, az adatok verziószámítása (verzió/hash), a környezet lefagyasztása (pontos könyvtári verziók/tároló), és az egyes kísérletek követése (kód véglegesítése, adatok, hiperparaméterek, metrikák). E lánc nélkül nem lehet ugyanazt az eredményt reprodukálni; A nem reprodukálható eredmény olyan állítás, amelyet nem lehet bizonyítani.