Toistettavuus ja päästä päähän -projekti: kaiken yhdistäminen

Voitot:

• Kyky varmistaa uusittavuus neljällä pilarilla (siemenkiinnitys, tietojen versiointi, median jäädytys, kokeen seuranta) ja tuottaa sama tulos toistettaessa samaa ajoa
• Kyky yhdistää kaikki moduulin kohdat (metriikka, data, malli, LLM-komponentit, eval, oikeudenmukaisuus, turvallisuus, jakelu, seuranta) päästä päähän -ketjuun
• Kyky varmistaa, että kriittinen päätös jää ihmiselle jokaisella pysähdyksellä ja dokumentoida projekti auditoitavalla tavalla

ML-projektin salakavalin epäonnistuminen ei ole kaatuminen; "Ei saada samaa tulosta uudestaan." Jos et pysty toistamaan sen mallin tulosta, jonka otit tuotantoon kolme kuukautta sitten, et todellakaan hallitse tätä mallia. Tässä loppuosassa syvennämme toistettavuutta: kykyä saada luotettavasti sama tulos samoilla tuloilla ja yhdistää koko moduuli päästä päähän -projektin kurinalaiseksi.

Miksi toistettavuus on vaikeaa

Tavallisissa ohjelmistoissa sama koodi antaa saman tulosteen. ML:ssä on monia muita muuttujia, jotka määräävät tuloksen:

• Satunnaisuus: Tietojen sekoittaminen, painon alustus, tietojen jakaminen – kaikki riippuvat satunnaisuudesta.
• Data: Sama koodi tuottaa eri mallin eri dataversioilla.
• Ympäristö: Kirjastoversiot, laitteisto (CPU/GPU), jopa käyttöjärjestelmä voivat muuttaa tulosta.
• Piilotettu tapaus: Tallentamaton hyperparametri, manuaalinen esikäsittelyvaihe, huomioimaton valinta.

Uusittavuus ei ole "kiva saada", vaan tieteellinen ja tekninen välttämättömyys. Tulos, jota ei voida toistaa, on väite, jota ei voida todistaa.

Toistettavuuden neljä pilaria

1. Korjaa satunnaisuus. Aseta kaikki satunnaiset siemenet yhteen paikkaan: tietojen jakaminen, mallin alustus, tietojen sekoittaminen. Kiinteä siemen on "sama tulos, kun toistat saman ajon" -takuun perusta.

2. Versioi tiedot. Kirjaa ylös, millä dataversiolla kukin koe suoritettiin (tietojen versiointi yksikössä 2). "Viimeisimmät tiedot" on epämääräinen; "dataversio v3, hash abc123" on tarkka.

3. Pakasta väliaine. Kiinnitä kaikki riippuvuudet tarkkoihin versioihinsa (esim. tarkat versiot, kuten numpy==1.26.4, vaatimusten.txt-tiedostossa tai säilön kuva). "Uusin versio" rikkoo kaiken jonain päivänä.

4. Seuraa kaikkea (kokeilun seuranta). Tallenna automaattisesti jokaista kokeilua varten: koodiversio (git commit), dataversio, kaikki hyperparametrit, mittarit ja tulosrakenteet. Kokeiluseurantatyökalut, kuten MLflow, Weights & Biases, tekevät tämän järjestelmällisesti. Ilman rekisteröitymistä kysymys "mikä asetus oli paras" jää vastaamatta.

Varoitus: "Muistan myöhemmin" on kallein virhe. Kaksi viikkoa myöhemmin et muista mitä siementä, mitä tietoja, mitä hyperparametria käytit. Automaattinen seuranta eliminoi riippuvuuden muistista.

Heikko lähestymistapa / Vahva lähestymistapa

Heikko: "Löysin parhaan mallin, se on muistikirjassa, mielestäni sen pistemäärä oli 89%.

Vahva: "Suorita #147 kokeen seurantatyökalussa: git commit a3f9c, dataversio v3 (hash abc123), siemen 42, kaikki hyperparametrit rekisteröity, testaa PR-AUC 0.887. Kun suoritan saman komennon uudelleen, saan saman tuloksen bitti kerrallaan. Malli riippuu tästä ajosta rekisterissä."

Ero: vahvassa lähestymistavassa tulos ei perustu muistiin, vaan kiinteään ja valvottuun ketjuun. Jokainen voi tuottaa joka kerta saman tuloksen.

Päästä päähän -projekti: moduulien yhdistelmä

Yhdistetään nyt koko moduuli yhdeksi projektivuoksi. Todellinen ML-järjestelmä käy läpi nämä pysähdykset, ja jokainen pysähdys perustuu edelliseen:

1. Ongelman määritelmä: Mitä ratkaisemme, kuinka menestystä mitataan (yksikkö 3: oikea mittari, liiketoimintakonteksti). Mittari ja kynnys ovat selvät alusta alkaen.
2. Tietojen käsittely: Keräys, validointi, puhdistus, vuotamaton osiointi, versiointi (yksikkö 2).
3. Mallin kehittäminen: Koulutus, lähtötilanteen vertailu, ristiinvalidointi, kova siemen (yksikkö 3 + tämä yksikkö).
4. LLM-komponentit (jos sovellettavissa): RAG (yksikkö 4) ja/tai agentit (yksikkö 5); hienosäätö tarvittaessa (yksikkö 6).
5. Arviointi: eval-klusteri reuna- ja turvakoteloineen, monikerroksinen eval LLM-järjestelmissä (yksikkö 8).
6. Oikeus- ja eettinen auditointi: Alaryhmäanalyysi, mallikortti, selitettävyys (yksikkö 10).
7. Tietoturvatarkastus: Pikainjektio, yksityisyys, toimitusketju (yksikkö 9).
8. Jakelu: Pakkaus, asteittainen jakelu, palautus, mallirekisteri (yksikkö 7).
9. Valvonta: Kolmikerroksinen valvonta, ryömintähälytykset (yksikkö 8).
10. Toistettavuus: Siementen, dataversioiden, välineiden ja kokeiden seuranta koko ketjussa (tämä yksikkö).

Tässä virtauksessa AI on kiihdytin ja suunnitelmageneraattori jokaisessa pysähdyksessä; mutta metrien valinta, datapäätökset, oikeudenmukaisuuden priorisointi, käyttöönoton kynnys ja julkaisun hyväksyntä – kriittiset päätökset jäävät ihmiselle. Tämä on moduulin ydin.

Dokumentaatio: tulevaisuus kiittää sinua

Hyvä ML-projekti dokumentoi itsensä. Vähintään seuraavat asiat tulee kirjoittaa: ongelma- ja onnistumiskriteerit, tietolähde ja versio, mallivalinnat ja perustelut, arviointitulokset (mukaan lukien alaryhmät), tunnetut rajat ja riskit, käyttöönotto- ja hakumenettely, seurantasuunnitelma. Tämä asiakirja on sen henkilön (ehkä se olet sinä) paras ystävä, joka palaa projektiin kuuden kuukauden kuluttua.

kolme minilaukkua

Tapaus 1 - Menetetty tulos. Insinööri koulutti hienon mallin, mutta hän ei korjannut siementä eikä tallentanut dataversiota. Kun hän jätti työnsä, kukaan ei voinut toistaa tätä tulosta; mallista tuli "mustan laatikon legenda" ja se rakennettiin lopulta tyhjästä. Viikot menivät hukkaan. Oppitunti: ei-toistettavissa oleva tulos on olematon tulos.

Tapaus 2 - Ympäristön romahdus. Yksi joukkue ei ollut korjannut riippuvuuksia. Kun kirjasto päivitettiin automaattisesti, mallin lähdöt muuttuivat hiljaa ja tuotanto keskeytettiin. Kesti päiviä löytää ongelma. Kun riippuvuudet jäädytettiin ja säilytettiin lopullisilla versioilla, ongelma ei toistunut. Oppitunti: jäädyttää ympäristö.

Tapaus 3 – Valvonnan teho. Ryhmä seurasi automaattisesti jokaista kokeilua. Kolme kuukautta myöhemmin, viranomaistarkastuksen aikana, he vastasivat kysymykseen "millä tiedoilla, millä asetuksilla, minkä suorituskyvyn se sai missä ryhmissä?" täydellä tallennuksella muutamassa minuutissa. Katsastus sujui mutkattomasti. Oppitunti: seuranta on vaatimustenmukaisuuden työkalu, ei vain suunnittelutyökalu.

Kopioitavat mallit

Tee toistettavuustarkistus tälle ML-projektille.- Ovatko kaikki satunnaisuussiemenet kiinteät (jakaa, alustavat, sekoitetaan)?- Onko data versioitu?- Onko riippuvuudet jäädytetty tarkkoihin versioihin?- Seurataanko jokaista kokeilua (koodisitoumus, data, hyperparametri, metriikka)? Kirjoita konkreettiset vaiheet sen korjaamiseksi jokaiselle puuttuvalle sarakkeelle. Projektin rakenne: [kuvaus]

Tuota suunnitelmarunko tälle päästä päähän ML-projektille. Ongelma: [kuvaus] Peitä seuraavat pysähdykset ja merkitse kussakin pisteessä IHMISPÄÄTÖS: ongelma/metriikka, putkisto, malli, (RAG/agentti/hienosäätö?), eval, oikeudenmukaisuus, turvallisuus, jakelu, seuranta, toistettavuus. Kirjoita kunkin pysähdyksen pääriski ja varmennusvaihe.

Tuota tätä projektia varten teknisen dokumentaation malli. Osat: ongelma+menestyskriteerit, data (lähde+versio), mallivalinnat+perustelut, arviointi (mukaan lukien alaryhmät), tunnetut rajat+riskit, käyttöönotto+palautus, seurantasuunnitelma. Anna jokaisen osan täytettävät kentät kysymyksinä.

Tarkista kokeilun valvonta-asetukset: Tallennetaanko se automaattisesti joka ajon aikana: git-commit, dataversio/hash, kaikki hyperparametrit, kaikki mittarit, ympäristö (kirjastoversiot)? Saanko saman tuloksen, kun juoksen uudelleen? Asennus: [kuvaus]. Listaa puutteet ja korjaukset.

Toistettavuussarakkeiden taulukko

sarakkeessa

Mikä on korjattu

Esimerkki ajoneuvosta

satunnaisuus

kaikki siemenet

siemenasetus

Data

Tietojen versio/hash

DVC

ympäristöön

Kirjaston versiot

vaatimusten pin, Docker

Valvonta

Koodi+tiedot+asetus+mittari

MLflow, W&B

Yleisiä virheitä

• Ei korjaa siementä. Tulosta ei voi toistaa.
• Tietoversiota ei tallenneta. "Millä tiedoilla?" jää vastaamatta.
• Ei jäädyttävä riippuvuuksia. Päivitys rikkoo hiljaa kaiken.
• Kokeilut jätetään muistiin. Kahden viikon kuluttua ei muista enää mitään.
• Kriittiset päätökset jätetään tekoälylle. Mittareiden, oikeudenmukaisuuden ja jakelupäätösten tulisi jäädä ihmisille.
• Dokumentoinnin lykkääminen. Tuleva tiimi (ja sinä) maksat hinnan.

Yhteenvetona

Toistettavuus on vakavan ML-tekniikan tunnusmerkki: ei-toistettava tulos on todistettamaton väite. Siinä on neljä saraketta – korjaa satunnaisuus, versiotiedot, pysäytysympäristö, seuraa jokaista kokeilua. Päästä päähän -projekti yhdistää kaikki tämän moduulin pysähdykset (metriikka, data, malli, LLM-komponentit, eval, oikeudenmukaisuus, tietoturva, jakelu, seuranta) toisiinsa yhdistetyksi ketjuksi; Tekoäly on kiihdytin joka pysäkillä, mutta kriittiset päätökset jäävät ihmiselle. Dokumentoi kaikki – tulevaa tiimiä ja auditointeja varten. Tämä tieteenala on kehys, joka tukee kaikkea moduulin aikana oppimaasi.

Sovellustehtävä

Tarkista ML-projekti neljää toistettavuuspilaria vastaan: ovatko siemenet muuttumattomia, onko data versioitu, onko ympäristö jäädytetty, seurataanko kokeita? Korjaa puuttuvat sarakkeet ja todista, että voit suorittaa saman ajon kahdesti ja saada saman tuloksen. Tulosta sitten projektin päästä päähän -kulku (10 pysähdystä) yhdelle sivulle ja merkitse "missä ihmisen päätös on" jokaisessa pysähdyksessä. Kirjoita lopuksi lyhyt teknisten asiakirjojen luonnos.

tarkistuslista

• [ ] Kaikki satunnaisuuden siemenet korjattu.
• [ ] Tietojen versio/hash tallennetaan jokaisen kokeen yhteydessä.
• [ ] Riippuvuudet jäädytetään kiinteisiin versioihin (pin/säiliö).
• [ ] Jokaista koetta valvotaan automaattisesti (koodi+tiedot+asetus+metriikka).
• [ ] Kun toistan saman ajon, saan saman tuloksen.
• [ ] Todistin ja dokumentoin, että kriittiset päätökset päästä päähän -virtauksessa tekevät ihmiset.

Moduulin tentti

1. Mikä on ML-insinöörinä paras tapa sijoittaa tekoälyä työnkulkuun?

• A) Tekoäly on kiihdytin vähäriskisissä yrityksissä; Kriittiset päätökset, kuten mittarit, tiedot ja tuotanto, pysyvät validoituina ja jätetään ihmiselle ✔
• B) Niin kauan kuin AI-lähdöt näyttävät hyviltä, varmentamista ei tarvita
• C) Mallin tuotantopäätöksen jättäminen tekoälylle säästää aikaa.
• D) Tekoälystä on hyötyä vain tekstin kirjoittamiseen, sillä ei ole mitään tekemistä datan ja mallityön kanssa

Kuvaus: AI on tehokas kiihdytin vähäriskisiin, helposti tarkistettaviin tehtäviin, kuten koodiin, datan tiivistelmiin ja asiakirjoihin. Vastuu rahaan, luottamuksellisuuteen ja juridiseen vastuuseen vaikuttavista päätöksistä, kuten mittarien valinnasta, jonka tiedot menevät koulutukseen ja mallin tuotantoon, on kuitenkin pätevällä insinöörillä ja tiimillä. Jokaista lähtöä ei saa käyttää ilman varmennusta.

2. Miksi skeeman validointi sijoitetaan dataliukuhihnan alkuun?

• A) Koska se lisää suoraan mallin tarkkuutta
• B) Koska se tekee tietojen versioinnista tarpeetonta
• C) Koska se kerää vioittuneet tiedot aikaisintaan ja halvimmalla pisteellä ja estää niitä vuotamasta seuraaviin vaiheisiin ✔
• D) Koska se poistaa merkintöjen tarpeen

Selitys: Mitä aikaisemmin vioittuneita tietoja saadaan kiinni, sitä halvempaa se on korjata. Kaavion validointi estää korruptoituneiden tietojen vuotamisen hiljaa koulutukseen tai tuotantoon hylkäämällä tiedot odotetun tyypin ja alueen ulkopuolella rivin alussa (esim. hintasiirtymä 100x yksikön muutoksella); Sama tuotannossa havaittu virhe on monta kertaa kalliimpi.

3. Mikä on oikea lähestymistapa, kun data jaetaan koulutukseen ja testaukseen aikaongelmassa (aikasarja)?

• A) Satunnaisen jakamisen käyttäminen, koska se on aina oikeudenmukaisin menetelmä
• B) Ajallisen jakamisen käyttö: estä vuodot harjoittelemalla menneisyyttä ja testaamalla tulevaisuudessa ✔
• C) Kaikkien tietojen käyttäminen sekä koulutuksena että testauksena
• D) Testitietojen sisällyttäminen skaalausparametreihin ennen harjoittelua

Selitys: Aikasarjojen satunnainen jakaminen antaa mallille "tulevaisuuden näkemisen" edun, jota ei koskaan tapahdu tuotannossa, ja lisää mittareita keinotekoisesti (ajallinen vuoto). Oikea on ajallinen jako: harjoittele menneisyyden kanssa, testaa tulevaisuutta. Tämä mittaa todellista suorituskykyä, joka pitää sen tuotannossa.

4. Miksi tarkkuus on harhaanjohtava petosten havaitsemismallissa, jonka positiivinen luokkaaste on 1,5 %?

• A) Koska Tarkkuus on aina alhainen epätasapainoisissa tiedoissa
• B) Koska tarkkuutta voidaan käyttää vain regressioongelmissa
• C) Koska tarkkuuslaskenta vaatii paljon prosessointitehoa
• D) Jopa vaatimaton malli, joka ennustaa enemmistöluokkaa, voi olla erittäin tarkka, piilottaen siten todellisen menestyksen ✔

Selitys: Epätasapainoisilla tiedoilla jopa perusmalli, joka sanoo "soita kaikki negatiiviseksi", saa noin 98,5 %:n tarkkuuden, mutta se ei saa kiinni yhtäkään petosta. Siksi epätasapainoisessa luokittelussa käytetään tarkkuutta, palautusta, F1:tä tai PR-AUC:ta tarkkuuden sijasta ja jokainen metriikka tulkitaan perusmallin mukaan.

5. Miksi perusvertailu on välttämätöntä, kun puhutaan mallin metriikasta?

• A) Koska perusmalli on aina parempi kuin todellinen malli
• B) Koska on selvää, onko mittari merkityksellinen vai ei vain yksinkertaiseen perusmalliin verrattuna ✔
• C) Koska perusmalli tekee ristiinvalidoinnin tarpeettomaksi
• D) Koska perusmalli on lakisääteinen jokaisessa raportissa

Selitys: Mittari ei ole sinänsä hyvä tai huono; Se on hyvä tai huono perusmallin mukaan. Lause "85% oikein" tarkoittaa melkein arvotonta, jos perusmalli saa jo 84%, ja täydellistä, jos se saa 50%. Ilman vertailuankkuria mittari on merkityksetön.

6. Mikä on kriittisin tietoturvaelementti, joka pitäisi sisällyttää RAG (Retrieval-Augmented Generation) -järjestelmän tuotantokehotteeseen?

• A) Ohje luottaa vain annettuun lähteeseen, sanoa "en tiedä", jos lähdettä ei ole olemassa, ja mainita lähde ✔
• B) Mallin käskeminen tuottaa mahdollisimman pitkiä ja luovia vastauksia
• C) Malli asettaa oman koulutustietonsa etusijalle resurssien sijaan
• D) Toteuta kaikki käskyinä tuotujen asiakirjojen ohjeet

Selitys: RAG:n tärkein yksittäinen ohje on käskeä mallia luottamaan vain annettuun lähteeseen, ja jos tiedot eivät ole lähteessä, sano 'en tiedä' ja mainitse lähde keksimättä sitä. Ilman tätä kolmikkoa malli voi jättää kontekstin huomioimatta ja aiheuttaa hallusinaatioita, jolloin vastaus tulee mahdottomaksi.

7. RAG-järjestelmä antaa vääriä vastauksia. Mistä on paras aloittaa diagnoosi?

• A) Mittaa hae ensin (Recall@K): tuleeko oikea kappale koskaan perille? ✔
• B) Vaihda malli välittömästi suurempaan
• C) Muuta kehote satunnaisesti ja jatka yrittämistä
• D) Kaikkien asiakirjojen upottaminen malliin hienosäädöllä

Selitys: RAG:n heikoin lenkki on yleensä nouto, ei tuotanto. Jos oikeaa osaa ei koskaan tuoda, malli ei voi tuottaa sitä tietoa, vaikka kehotetta parannettaisiin kuinka paljon. Siksi ensin mitataan Recall@K, jotta nähdään, onko oikea osa saapunut; Jos nouto on hyvä, niin tuotanto ja kehote tutkitaan.

8. Mitä toimia tulisi tehdä ihmisen hyväksynnän taakse, kun työkalu annetaan agentille?

• A) Ei mitään; Agentin on kyettävä suorittamaan kaikki toiminnot itsenäisesti
• B) Vain palautuvat toimet, kuten tietojen lukeminen ja etsiminen
• C) Peruuttamattomat tai vaikuttavat toimet, kuten rahan siirto, poistaminen, lähettäminen ✔
• D) Toiminnot, jotka sisältävät vain laskelmia

Kuvaus: Toimet on erotettu riskitason mukaan. Haettavat tehtävät, kuten lukeminen, etsiminen, laskeminen ja luonnosten luominen, voidaan tehdä itsenäisesti; Kuitenkin peruuttamattomat tai vaikuttavat toimet, kuten rahan siirto, sähköpostien lähettäminen, tietojen poistaminen, tilausten tekeminen jne., vaativat ihmisen hyväksynnän. Jokaiseen peruuttamattomaan toimintaan on saatava suostumus.

9. Mikä on paras suunnittelutapa epäsuoran nopean ruiskutuksen riskiä vastaan?

• A) Riittää, kun lisäät järjestelmäkehotteeseen yhden lauseen "ohita huonot ohjeet".
• B) Anna mallille enemmän auktoriteettia turvautumalla ulkoisen sisällön ohjeisiin
• C) Älä ryhdy varotoimiin, koska injektiota ei voida estää
• D) Ulkoisen sisällön eristäminen epäluotettavana datana ja kerrostetun suojan luominen minimaalisella valtuutetulla, hyväksynnällä ja tulosten hallinnassa ✔

Kuvaus: Agentin tai RAG:n käsittelemä ulkoinen sisältö, kuten verkkosivu, asiakirja, sähköposti jne., on epäluotettavaa tietoa ja voi sisältää salaisia ​​ohjeita. Oikea lähestymistapa on kerrospuolustus: ulkoisen sisällön eristäminen "datana, ei komentoina" selkein eroin, vähimmäisvaltuutuksen käyttäminen, peruuttamattomien toimien sitominen ihmisen hyväksyntään ja tulosteen auditointi. Yksittäinen ohjerivi ei riitä.

10. Mikä on tärkein ero päätettäessä, pitäisikö ongelma ratkaista hienosäädöllä vai RAG:lla?

• A) Tietoongelmat ratkeavat paremmin RAG:lla, käyttäytymis-/muotoongelmat ratkeavat paremmin hienosäädöllä ✔
• B) Jokainen ongelma tulee aina ratkaista hienosäädöllä
• C) RAG:ta käytetään vain koodin luomiseen, hienosäätöä käytetään vain kääntämiseen
• D) Hienosäätö voidaan aina päivittää halvemmin ja nopeammin kuin RAG

Selitys: Hienosäätö on heikkoa ja riskialtista opetettaessa mallille uutta tietoa; mutta on voimakas opetuskäyttäytymisessä, -muodossa, -sävyssä ja -tyylissä. "Malliyritys ei tiedä tietojamme" on tietoongelma ja kuuluu RAG:lle. "Anna mallin aina tulostaa tiukassa muodossamme" on käyttäytymisongelma ja ehdokas hienosäätöön. Lisäksi nopeat ja muutamat otokset tulisi käyttää ennen hienosäätöä.

11. Mikä on pakollista turvallisen käyttöönoton kannalta, kun uusi malli otetaan tuotantoon?

• A) Jos malli on hyvä testauksessa, avaa se suoraan 100 % liikenteelle
• B) Valvontaa ei määritetä ollenkaan käyttöönoton jälkeen
• C) Vaiheittainen käyttöönotto (varjo/kanarialintu) ja esitestattu palautussuunnitelma ✔
• D) Mallin julkaiseminen, vaikka arviointikynnys ei täyttyisi

Selitys: Uuden mallin avaaminen suoraan kaikelle liikenteelle on riskialtista; Jos se on väärin, se vaikuttaa kaikkiin. Oikea asia on, että se on asteittainen jakelu (shadow, canary) ja jokaisella jakelulla on testattu palautussuunnitelma. Jakelu ei ole täydellinen ilman takaisinperintäsuunnitelmaa; Mahdollisuus palata edelliseen versioon muutamassa minuutissa suojaa käyttäjää, jos malli käyttäytyy odottamatta tuotannossa.

12. Kuinka ML-malli voi epäonnistua "hiljaisesti" tuotannossa ja miten tämä saadaan kiinni?

• A) Malli romahtaa; palvelinlokit osoittavat tämän
• B) Tuottamalla vääriä ennusteita tekemättä virheitä; ✔ Se kaappaa toiminnallisen, tulo- ja tuloskerroksellisen seurannan
• C) Malli ei voi koskaan pettää hiljaa, aina hälyttää
• D) Pelkkä latenssin seuranta riittää havaitsemaan huonontuminen

Selitys: Malli voi epäonnistua yksinkertaisesti tuottamalla vääriä ennusteita kaatumatta tai antamatta virheitä; Pääsyy tähän on tiedon ajautuminen ja konseptien ajautuminen. Pelkkä toiminnallisten mittareiden (latenssi, virheprosentti) seuranta ei riitä; panosten jakautumista ja tuotos/ennustejakaumaa tulisi myös seurata. Syöttöpoikkeama antaa ennakkovaroituksen, jos todellinen tulos viivästyy.

13. Mikä periaate on olennainen, kun LLM-tuomarina käytetään LLM-järjestelmän arvioinnissa?

• A) LLM-tuomari on aina oikeassa, ihmisen tarkistus on tarpeeton
• B) Erotuomarin on tehtävä päätös vain vastauksen pituuden perusteella.
• C) Sääntöihin perustuvat kontrollit ja ihmisen arviointi tulee hylätä kokonaan, kun käytetään erotuomareita
• D) Tuomareiden pisteet tulee kalibroida ihmisleimatulla näytteellä ja mitata niiden harha, ennen kuin niihin voidaan luottaa ✔

Kuvaus: LLM-tuomari on myös malli; Se voi olla hallusinatorista, puolueellinen (suunnittelee pitkiä, varmoja vastauksia) ja epäjohdonmukainen. Tästä syystä erotuomarin pisteet on kalibroitava ihmisillä merkityllä näytteellä ja niiden systemaattinen harha on mitattava ennen tuotantopäätöksen tekemistä. Vahvistamaton erotuomari antaa väärää luottamusta.

14. Miksi yleisen tarkkuuden tarkastelu ei ole riittävää arvioitaessa mallin harhaa?

• A) Kokonaistarkkuus on riittävä, koska se kuvastaa aina huonoimman ryhmän suorituskykyä
• B) Pelkkä kokonaistarkkuus ei riitä, koska se voi hämärtää alaryhmien välisen systemaattisen eron (piilotettu syrjintä) ✔
• C) Koska tarkkuus on mittari, jolla ei ole mitään tekemistä harhan kanssa
• D) Bias tulee vain mallista, eikä sillä ole mitään tekemistä datan kanssa.

Selitys: Yleinen tarkkuus saattaa hämärtää alaryhmien väliset systemaattiset erot. Esimerkiksi vaikka kokonaistarkkuus on 88 %, muistaminen voi olla 91 % yhdessä ryhmässä ja 67 % toisessa ryhmässä; Malli ohittaa järjestelmällisesti tämän ryhmän. Siksi mallia tulisi arvioida alaryhmien (demografiset tiedot/segmentit) perusteella ja sidosryhmien kanssa olisi päätettävä, mikä oikeudenmukaisuuden määritelmä tulisi priorisoida.

15. Mitkä neljä asiaa on korjattava yhteen, jotta ML-tulos olisi toistettavissa?

• A) Vain mallin nimi, koko, hinta ja julkaisupäivä
• B) Vain GPU-merkki ja Internet-nopeus
• C) Vain mallin lopullinen tarkkuuspistemäärä; loput voidaan säilyttää muistissa
• D) Satunnaisuuden siemen, dataversio, ympäristö (riippuvuusversiot) ja kokeen seuranta ✔

Kuvaus: Uusittavuus saavutetaan neljällä pilarilla: satunnaisuussiementen korjaaminen, tietojen versiointi (versio/hash), ympäristön jäädyttäminen (tarkat kirjastoversiot/säilö) ja kunkin kokeen seuranta (koodisitoumus, data, hyperparametri, metriikka). Ilman tätä ketjua ei ole mahdollista toistaa samaa tulosta; Ei-toistettavissa oleva tulos on väite, jota ei voida todistaa.