Reprodutseeritavus ja otsast lõpuni projekt: kõike kombineerides

Kasu:

• Võimalus tagada reprodutseeritavus nelja sambaga (seemne fikseerimine, andmete versioonide loomine, andmekandja külmutamine, katse jälgimine) ja anda sama tulemust sama käitamise kordamisel
• Võimalus ühendada kõik mooduli peatused (mõõdikud, andmed, mudel, LLM-i komponendid, eval, õiglus, turvalisus, levitamine, jälgimine) otsast lõpuni ahelasse
• Võimalus kontrollida, kas kriitiline otsus jääb inimesele igas peatuses, ja dokumenteerida projekt auditeeritaval viisil

ML-projekti kõige salakavalam ebaõnnestumine ei ole krahh; "Ei saa enam sama tulemust." Kui te ei suuda täna kolm kuud tagasi tootmisse pandud mudeli skoori reprodutseerida, ei saa te seda mudelit tegelikult kontrollida. Selles lõpuosas süvendame reprodutseeritavust: võimalust saada usaldusväärselt sama tulemust samade sisenditega ja kombineerida kogu moodul otsast lõpuni projektidistsipliini.

Miks on reprodutseeritavus keeruline

Tavatarkvaras annab sama kood sama väljundi. ML-is on tulemuse määramiseks palju rohkem muutujaid:

• Juhuslikkus: andmete segamine, kaalu lähtestamine, andmete jagamine – kõik põhinevad juhuslikkusele.
• Andmed: sama kood loob erineva mudeli erineva andmeversiooniga.
• Keskkond: teegi versioonid, riistvara (CPU/GPU), isegi operatsioonisüsteem võivad tulemust muuta.
• Peidetud juhtum: salvestamata hüperparameeter, käsitsi eeltöötlusetapp, märkimata valik.

Reprodutseeritavus ei ole "tore omada", vaid teaduslik ja tehniline kohustuslik. Tulemus, mida ei saa reprodutseerida, on väide, mida ei saa tõestada.

Reprodutseeritavuse neli sammast

1. Parandage juhuslikkus. Seadke kõik juhuslikud seemned ühte kohta: andmete poolitamine, mudeli lähtestamine, andmete segamine. Fikseeritud seeme on "sama jooksu kordamisel sama tulemuse" garantii aluseks.

2. Versioonige andmed. Registreerige, millise andmeversiooniga iga katse läbi viidi (andmete versioon 2. üksuses). "Viimased andmed" on ebamäärased; "Data version v3, hash abc123" on täpne.

3. Külmutage sööde. Kinnitage kõik sõltuvused nende täpsetele versioonidele (nt täpsed versioonid, nagu numpy==1.26.4 failis needs.txt või konteineri kujutis). "Viimane versioon" lõhub ühel päeval kõik.

4. Jälgige kõike (katse jälgimine). Salvestage automaatselt iga katse jaoks: koodiversioon (git commit), andmeversioon, kõik hüperparameetrid, mõõdikud ja väljundstruktuurid. Eksperimentide jälgimise tööriistad, nagu MLflow, Weights & Biases, teevad seda süstemaatiliselt. Ilma registreerimata jääb küsimus "milline seadistus oli parim" vastuseta.

Ettevaatust: "Ma mäletan hiljem" on kõige kallim eksitus. Kaks nädalat hiljem ei mäleta te enam, millist seemet, milliseid andmeid, millist hüperparameetrit kasutasite. Automaatne jälgimine välistab sõltuvuse mälust.

Nõrk lähenemine / tugev lähenemine

Nõrk: "Leidsin parima mudeli, see on märkmikus, arvan, et selle tulemus oli 89%.

Tugev: "Käitage katse jälgimise tööriistas nr 147: git commit a3f9c, andmeversioon v3 (hash abc123), seed 42, kõik hüperparameetrid registreeritud, test PR-AUC 0.887. Kui ma sama käsku uuesti käivitan, saan biti haaval sama tulemuse. Mudel sõltub sellest käivitamisest registris."

Erinevus: tugeva lähenemise korral ei põhine tulemus mälul, vaid fikseeritud ja jälgitud ahelal. Igaüks võib anda iga kord sama tulemuse.

Otsast lõpuni projekt: mooduli kombinatsioon

Nüüd ühendame kogu mooduli üheks projektivooks. Tõeline ML-süsteem läbib need peatused ja iga peatus tugineb eelmisele:

1. Probleemi määratlus: mida me lahendame, kuidas edu mõõta (üksus 3: õige mõõdik, ärikontekst). Mõõdik ja lävi on algusest peale selged.
2. Andmekonveier: kogumine, valideerimine, puhastamine, lekkevaba partitsioonid, versioonide loomine (üksus 2).
3. Mudeli väljatöötamine: koolitus, algtaseme võrdlus, ristvalideerimine, kõva seeme (üksus 3 + see üksus).
4. LLM-i komponendid (vajaduse korral): RAG (üksus 4) ja/või agendid (üksus 5); vajadusel peenhäälestus (üksus 6).
5. Hindamine: eval-klaster serva- ja turvajuhtumitega, mitmekihiline hindamine LLM-süsteemides (üksus 8).
6. Õigus- ja eetikaaudit: Alarühma analüüs, näidiskaart, seletatavus (üksus 10).
7. Turvaaudit: kiire süstimine, privaatsus, tarneahel (üksus 9).
8. Levitamine: pakendamine, järkjärguline levitamine, tagasipööramine, mudeliregister (üksus 7).
9. Järelevalve: Kolmekihiline monitooring, triivi alarmid (plokk 8).
10. Reprodutseeritavus: seemnete, andmete versiooni, kandja ja katse jälgimine kogu ahela ulatuses (see üksus).

Selles voos on AI kiirendi ja jooniste generaator igas peatuses; kuid mõõdikute valik, andmetega seotud otsused, õigluse prioriteedid, juurutamise lävi ja vabastamise heakskiit – kriitilised otsused jäävad inimese teha. See on mooduli olemus.

Dokumentatsioon: tulevik tänab teid

Hea ML-projekt dokumenteerib ennast. Kirjutada tuleks vähemalt: probleemi- ja edukriteeriumid, andmeallikas ja versioon, mudelite valikud ja põhjendused, hindamistulemused (sh alarühmad), teadaolevad limiidid ja riskid, kasutuselevõtu ja otsingu protseduur, seireplaan. See dokument on selle inimese (võib-olla teie) parim sõber, kes kuue kuu pärast projekti naaseb.

kolm minikarpi

Juhtum 1 – kaotatud tulemus. Insener õpetas välja suurepärase mudeli, kuid ta ei parandanud seemet ega salvestanud andmete versiooni. Kui ta töölt lahkus, ei suutnud keegi seda tulemust reprodutseerida; mudelist sai "musta kasti legend" ja see ehitati lõpuks nullist. Nädalad olid raisatud. Õppetund: mittereprodutseeritav tulemus on olematu tulemus.

Juhtum 2 – keskkonna kokkuvarisemine. Üks meeskond ei olnud sõltuvusi fikseerinud. Kui teeki automaatselt värskendati, muutusid mudeli väljundid vaikselt ja tootmine katkes. Probleemi leidmiseks kulus päevi. Kui sõltuvused külmutati ja lõplike versioonidega konteinerisse paigutati, probleem enam ei ilmnenud. Õppetund: külmuta keskkond.

Juhtum 3 – seire võimsus. Meeskond jälgis automaatselt iga katset. Kolm kuud hiljem, regulatiivse auditi käigus, vastasid nad küsimusele "milliste andmetega, milliste seadistustega, millise jõudluse see millistes rühmades saavutas?" täissalvestusega mõne minuti jooksul. Ülevaatus läks ladusalt. Õppetund: monitooring on mitte ainult insenertehniline, vaid nõuetele vastavuse tööriist.

Kopeeritavad mallid

Kontrollige selle ML-projekti reprodutseeritavust.- Kas kõik juhuslikkuse seemned on fikseeritud (tükeldamine, lähtestamine, segamine)?- Kas andmed on versioonitud?- Kas sõltuvused on külmutatud täpsete versioonideni?- Kas iga katset (koodi sisestamine, andmed, hüperparameeter, mõõdik) jälgitakse? Kirjutage iga puuduva veeru jaoks konkreetsed sammud selle parandamiseks.Projekti struktuur: [kirjeldus]

Koostage selle täieliku ML-projekti jaoks plaani skelett. Probleem: [kirjeldus] Katke järgmised peatused ja märkige, kus igas peatuses on INIMESE otsus: probleem/mõõdik, torujuhe, mudel, (RAG/agent/peenhäälestus?), eval, õiglus, turvalisus, levitamine, jälgimine, reprodutseeritavus. Kirjutage iga peatuse peamine risk ja kontrollimise etapp.

Koostage selle projekti jaoks tehnilise dokumentatsiooni mall. Jaotised: probleem+edukuse kriteeriumid, andmed (allikas+versioon), mudelivalikud+põhjendus, hindamine (sh alarühmad), teadaolevad piirid+riskid, kasutuselevõtt+tagasivõtmine, seireplaan. Esitage küsimustena iga jaotise jaoks täidetavad väljad.

Kontrollige minu katse jälgimise seadistust: kas see salvestatakse automaatselt igal käitamisel: git commit, andmete versioon/räsi, kõik hüperparameetrid, kõik mõõdikud, keskkond (teegi versioonid)? Kas ma saan sama tulemuse, kui jooksen uuesti sama jooksu? Seadistamine: [kirjeldus]. Loetlege vead ja parandused.

Reprodutseeritavuse veergude tabel

veerus

Mis on fikseeritud

Sõiduki näide

juhuslikkus

kõik seemned

seemnete seadistus

Andmed

Andmete versioon/räsi

DVC

keskkond

Raamatukogu versioonid

nõuete pin, Docker

Järelevalve

Kood+andmed+seade+mõõdik

MLflow, W&B

Levinud vead

• Seemet ei kinnita. Tulemust ei saa korrata.
• Andmeversiooni ei salvestata. "Mis andmetega?" jääb vastuseta.
• Ei külmuta sõltuvusi. Värskendus murrab vaikselt kõik.
• Jättes katsed mällu. Kaks nädalat hiljem ei mäletata enam midagi.
• Kriitiliste otsuste langetamine tehisintellekti hooleks. Mõõdikud, õiglus ja jaotusotsused peaksid jääma inimestele.
• Dokumentatsiooni edasilükkamine. Tulevane meeskond (ja teie) maksate selle hinna.

Kokkuvõttes

Reprodutseeritavus on tõsise ML-i inseneritöö tunnus: mittereprodutseeritav tulemus on tõestamatu väide. Kaasas neli veergu – parandage juhuslikkust, versiooniandmeid, külmutage keskkond, jälgige iga katset. End-to-end projekt ühendab kõik selle mooduli peatused (meetria, andmed, mudel, LLM-i komponendid, eval, õiglus, turvalisus, levitamine, jälgimine) omavahel ühendatud ahelas; Tehisintellekt on igas peatuses kiirendiks, kuid kriitilised otsused jäävad inimese teha. Dokumenteerige kõik – tulevase meeskonna ja auditite jaoks. See distsipliin on raamistik, mis toetab kõike, mida kogu mooduli jooksul õpite.

Rakenduse ülesanne

Kontrollige ML-projekti nelja reprodutseeritavuse samba suhtes: kas seemned on muutumatud, kas andmed on versioonistatud, kas keskkond on külmunud, kas katseid jälgitakse? Parandage kõik puuduvad veerud ja tõestage, et saate sama käitamise kaks korda käivitada ja saada sama tulemuse. Seejärel väljastage ühele lehele projekti otsast lõpuni voog (10 peatust) ja märkige igas peatuses "kus on inimese otsus". Lõpuks kirjutage lühike tehnilise dokumentatsiooni mustand.

kontrollnimekiri

• [ ] Kõik juhuslikkuse seemned on fikseeritud.
• [ ] Andmete versioon/räsi salvestatakse iga katsega.
• [ ] Sõltuvused on külmutatud kindlateks versioonideks (pin/konteiner).
• [ ] Iga katset jälgitakse automaatselt (kood+andmed+seade+mõõdik).
• [ ] Kui ma kordan sama jooksu, saan sama tulemuse.
• [ ] Kontrollisin ja dokumenteerisin, et kriitilised otsused ots-otsani voos teevad inimesed.

Mooduli eksam

1. Mis on ML-insenerina parim lähenemine tehisintellekti töövoos positsioneerimisel?

• A) AI on madala riskiga ettevõtete kiirendus; Kriitilised otsused, nagu mõõdikud, andmed ja tootmine, jäävad valideerituks ja jäetakse inimese otsustada ✔
• B) Kuni AI väljundid näevad head välja, pole kontrollimist vaja
• C) Mudeli tootmisse panemise otsuse jätmine tehisintellekti hooleks säästab aega.
• D) Tehisintellekt on kasulik ainult teksti kirjutamisel, sellel pole andmete ja mudelitööga mingit pistmist

Kirjeldus: AI on võimas kiirendi madala riskiga ja hõlpsasti kontrollitavate toimingute jaoks, nagu kood, andmete kokkuvõtted ja dokumendid; Vastutus raha, konfidentsiaalsust ja juriidilist vastutust mõjutavate otsuste eest, nagu mõõdiku valik, mille andmed lähevad koolitusse ja mudeli tootmisse, lasub aga kvalifitseeritud inseneril ja meeskonnal. Iga väljundit ei tohiks ilma kontrollita kasutada.

2. Miks paigutatakse skeemi valideerimine andmekonveieri algusesse?

• A) Kuna see suurendab otseselt mudeli täpsust
• B) Kuna see muudab andmete versioonimise tarbetuks
• C) Kuna see püüab rikutud andmed kinni kõige varem ja odavamalt ning takistab nende lekkimist järgmistesse sammudesse ✔
• D) Kuna see välistab märgistamise vajaduse

Selgitus: mida varem rikutud andmed kinni püütakse, seda odavam on neid parandada. Skeemi valideerimine takistab rikutud andmete vaikselt väljaõppesse või tootmisse lekkimist, lükates rea alguses tagasi andmed, mis jäävad väljapoole oodatud tüüpi ja vahemikku (nt hinna nihkumine 100 korda ühiku muutusega); Tootmisel tabatud sama viga on kordades kallim.

3. Milline on õige lähenemine andmete jagamisel koolituseks ja testimiseks aega hõlmava probleemi (aegridade) puhul?

• A) Juhusliku jagamise kasutamine, kuna see on alati kõige õiglasem meetod
• B) Ajalise jaotuse kasutamine: vältige leket, treenides minevikuga ja katsetades tulevikus ✔
• C) Kõigi andmete kasutamine nii koolituse kui ka testimise eesmärgil
• D) Testiandmete lisamine skaleerimisparameetritesse enne treeningut

Selgitus: Aegridade juhuslik jagamine annab mudelile "tulevikku nägeva" eelise, mida tootmises kunagi ei juhtu, ja suurendab mõõdikuid kunstlikult (ajaline leke). Õige on ajaline jaotus: treeni minevikuga, katseta tulevikku. See mõõdab tegelikku jõudlust, mis hoiab seda tootmises.

4. Miks on 1,5% positiivse klassimääraga pettuste tuvastamise mudeli täpsus eksitav?

• A) Kuna tasakaalustamata andmete puhul on täpsus alati madal
• B) Kuna täpsust saab kasutada ainult regressiooniülesannete puhul
• C) Kuna täpsuse arvutamine nõuab palju töötlemisvõimsust
• D) Isegi tühine mudel, mis ennustab enamusklassi, võib olla väga täpne, varjates nii tõelist edu ✔

Selgitus. Tasakaalustamata andmete korral on isegi põhimudel, mis ütleb, et "kutsu kõike negatiivseks", umbes 98,5% täpsusega, kuid ei taba ühtegi pettust. Seetõttu kasutatakse tasakaalustamata klassifikatsioonis täpsuse asemel täpsust, tagasikutsumist, F1 või PR-AUC ning iga mõõdikut tõlgendatakse vastavalt baasmudelile.

5. Miks on mudeli mõõdikust rääkides oluline lähtetaseme võrdlus?

• A) Sest baasmudel on alati parem kui pärismudel
• B) Sest on selge, kas mõõdik on mõttekas või mitte, ainult võrreldes lihtsa baasmudeliga ✔
• C) Kuna baasmudel muudab ristvalideerimise ebavajalikuks
• D) Kuna põhimudel on seadusega nõutud igas aruandes

Selgitus: mõõdik ei ole iseenesest hea ega halb; Põhimudeli järgi on see hea või halb. Lause "85% õige" tähendab peaaegu väärtusetut, kui baasmudel saab juba 84%, ja täiuslik, kui see saab 50%. Ilma võrdlusankruta on mõõdik mõttetu.

6. Milline on kõige kriitilisem turvaelement, mis tuleks RAG (Retrieval-Augmented Generation) süsteemi tootmisviipa lisada?

• A) Juhend tugineda ainult antud allikale, öelda "ma ei tea", kui allikat pole olemas, ja viidata allikale ✔
• B) Öelge mudelile, et ta esitaks võimalikult pikad ja loovad vastused
• C) Mudel eelistab oma haridusteadmisi ressurssidele
• D) Rakenda kõik käskudena toodud dokumentides olevad juhised

Selgitus: RAG-i kõige olulisem juhis on käskida mudelil tugineda ainult antud allikale ja kui teavet allikas ei ole, öelda "ma ei tea" ja viidata allikale ilma seda välja mõtlemata. Ilma selle triaadita võib mudel konteksti ignoreerida ja tekitada hallutsinatsioone ning vastus muutub kontrollimatuks.

7. RAG süsteem annab valesid vastuseid. Kust on parim koht diagnoosi alustamiseks?

• A) Mõõtmine too esimesena (Recall@K): kas õige tükk saabub kunagi? ✔
• B) Vahetage mudel kohe suurema vastu
• C) Muutke viipa juhuslikult ja jätkake proovimist
• D) Kõigi dokumentide manustamine mudelisse peenhäälestusega

Selgitus: RAGi nõrgim lüli on tavaliselt toomine, mitte tootmine. Kui õiget osa kunagi ei tooda, ei saa mudel seda teavet toota, hoolimata sellest, kui palju viipa on täiustatud. Seetõttu mõõdetakse kõigepealt Recall@K, et näha, kas õige osa on kohale jõudnud; Kui toomine on hea, kontrollitakse tootmist ja viipa.

8. Milliseid tegusid tuleks agendile tööriista andmisel inimliku heakskiidu taha panna?

• A) Puudub; Agent peab suutma sooritada iga toimingu iseseisvalt
• B) Ainult pöörduvad toimingud, nagu andmete lugemine ja otsimine
• C) Pöördumatud või suure mõjuga toimingud, nagu raha ülekandmine, kustutamine, saatmine ✔
• D) Toimingud, mis hõlmavad ainult arvutusi

Kirjeldus: toimingud on eraldatud riskitaseme järgi. Otsitavaid ülesandeid, nagu lugemine, otsimine, arvutamine ja mustandite genereerimine, saab teha iseseisvalt; Kuid pöördumatud või suure mõjuga toimingud, nagu raha ülekandmine, e-kirjade saatmine, andmete kustutamine, tellimuste esitamine jne, nõuavad inimese nõusolekut. Iga tagasivõtmatu toiming peab olema nõus.

9. Milline on parim lahendus kaudse kiire süstimise ohu vastu?

• A) Piisab, kui lisada süsteemiviipale üks lause "ignoreeri halbu juhiseid".
• B) Andke mudelile rohkem autoriteeti, tuginedes välise sisu juhistele
• C) Ärge rakendage ettevaatusabinõusid, kuna süstimist ei saa vältida
• D) Välise sisu eraldamine ebausaldusväärsete andmetena ja kihilise kaitse loomine minimaalse loa, heakskiidu ja väljundi kontrolliga ✔

Kirjeldus: agendi või RAG-i poolt töödeldud väline sisu, nagu veebileht, dokument, meil jne, on ebausaldusväärsed andmed ja võib sisaldada salajasi juhiseid. Õige lähenemisviis on kihiline kaitse: välise sisu eraldamine andmete, mitte käskudena selgete eraldusmärkidega, minimaalse volituse rakendamine, pöördumatute toimingute sidumine inimeste heakskiiduga ja väljundi auditeerimine. Ühest reast juhistest ei piisa.

10. Mis on peamine erinevus, kui otsustatakse, kas probleem tuleks lahendada peenhäälestusega või RAG-iga?

• A) Infoprobleeme saab paremini lahendada RAG-iga, käitumise/vormingu probleeme paremini peenhäälestusega ✔
• B) Iga probleem tuleb alati lahendada peenhäälestusega
• C) RAG-i kasutatakse ainult koodi genereerimiseks, peenhäälestust kasutatakse ainult tõlkimisel
• D) Peenhäälestust saab alati uuendada odavamalt ja kiiremini kui RAG

Selgitus: Peenhäälestus on mudelile uue teabe õpetamisel nõrk ja riskantne; kuid on võimas käitumise, vormingu, tooni ja stiili õpetamisel. "Mudelettevõte ei tea meie andmeid" on teabeprobleem ja kuulub RAG-le. „Las mudel väljastaks alati meie ranges vormingus” on käitumisprobleem ja peenhäälestuse kandidaat. Lisaks tuleks enne peenhäälestamist teha kiireid ja väheseid võtteid.

11. Mis on uue mudeli tootmisse laskmisel ohutuks kasutuselevõtuks kohustuslik?

• A) Kui mudel on testimisel hea, avage see otse 100% liiklusele
• B) Pärast kasutuselevõttu ei seadista järelevalvet üldse
• C) etapiviisiline kasutuselevõtt (vari/kanaarilind) ja eeltestitud tagasipööramise plaan ✔
• D) Mudeli avaldamine isegi siis, kui hindamislävi ei ole täidetud

Selgitus: uue mudeli avamine otse kogu liiklusele on riskantne; Kui see on vale, mõjutab see kõiki. Õige on see, et tegemist on järkjärgulise distributsiooniga (vari, kanaarilind) ja igal distributsioonil on testitud tagasipööramise plaan. Distributsioon ei ole täielik ilma tagasinõudmisplaanita; Võimalus naasta eelmisele versioonile mõne minuti jooksul kaitseb kasutajat, kui mudel käitub tootmises ootamatult.

12. Kuidas saab ML-mudel tootmises "vaikselt" ebaõnnestuda ja kuidas seda tabada?

• A) Mudel kukub kokku; serveri logid näitavad seda
• B) koostades valesid ennustusi ilma vigu tegemata; ✔ See salvestab töö-, sisend- ja väljundkihilise monitooringu
• C) Mudel ei saa kunagi vaikselt ebaõnnestuda, alati alarm
• D) Piisab vaid latentsuse jälgimisest, et tuvastada degradatsioon

Selgitus: mudel võib ebaõnnestuda lihtsalt valede ennustuste tegemisel ilma kokkujooksmiseta või vigade andmiseta; Selle peamiseks põhjuseks on andmete ja kontseptsioonide triiv. Ainult töömõõdikute (latentsus, veamäär) jälgimisest ei piisa; Samuti tuleks jälgida sisendi jaotust ja väljundi/ennustuse jaotust. Sisendtriiv annab varajase hoiatuse, kui tegelik tulemus hilineb.

13. Milline põhimõte on oluline LLM-i kui kohtuniku kasutamisel LLM-süsteemi hindamisel?

• A) LLM-kohtunik on alati õige, inimese kontrollimine pole vajalik
• B) Kohtunik peab tegema otsuse ainult vastuse pikkuse põhjal.
• C) Reeglipõhised kontrollid ja inimeste hinnangud tuleks kohtunike kasutamisel täielikult kõrvale jätta
• D) Kohtuniku hinded tuleks kalibreerida inimese märgistatud prooviga ja mõõta nende kallutatust enne, kui neid saab usaldada ✔

Kirjeldus: LLM-kohtunik on ka modell; See võib olla hallutsinatsiooniline, kallutatud (soodsab pikki ja enesekindlaid vastuseid) ja ebajärjekindel. Seetõttu tuleb kohtunike hinded kalibreerida inimese märgistatud prooviga ja enne tootmisotsuse tegemist tuleb mõõta nende süstemaatilist kallutatust. Kontrollimata kohtunik annab vale enesekindluse.

14. Miks on üldise täpsuse vaatamine mudeli kallutatuse hindamisel ebapiisav?

• A) Üldine täpsus on piisav, sest see peegeldab alati halvima rühma tulemusi
• B) Üldine täpsus üksi ei ole piisav, kuna see võib varjata süstemaatilisi erinevusi (varjatud diskrimineerimine) alarühmade vahel ✔
• C) Kuna täpsus on mõõdik, millel pole eelarvamusega midagi pistmist
• D) Kallutatus tuleneb ainult mudelist ja sellel pole andmetega mingit pistmist.

Selgitus: üldine täpsus võib varjata süstemaatilisi erinevusi alarühmade vahel. Näiteks kui üldine täpsus on 88%, võib meeldetuletus ühes rühmas olla 91% ja teises rühmas 67%; Mudel jätab sellest rühmast süstemaatiliselt mööda. Seetõttu tuleks mudelit hinnata alagruppide (demograafia/segment) alusel ja milline õigluse definitsioon tuleks eelistada, tuleks koos sidusrühmadega otsustada.

15. Millised neli asja tuleb kokku fikseerida, et ML-i tulemus oleks reprodutseeritav?

• A) Ainult mudeli nimi, suurus, hind ja väljalaskekuupäev
• B) Ainult GPU kaubamärk ja Interneti kiirus
• C) Ainult mudeli lõplik täpsusskoor; ülejäänu võib mällu jätta
• D) Juhuslikkuse seeme, andmete versioon, keskkond (sõltuvusversioonid) ja katse jälgimine ✔

Kirjeldus: reprodutseeritavus saavutatakse nelja samba kaudu: juhuslikkuse seemnete fikseerimine, andmete versioonide loomine (versioon/räsi), keskkonna külmutamine (täpsed teegi versioonid/konteiner) ja iga katse jälgimine (koodi sidumine, andmed, hüperparameeter, mõõdik). Ilma selle ahelata pole sama tulemust võimalik reprodutseerida; Mittereprodutseeritav tulemus on väide, mida ei saa tõestada.