Reproduceerbaarheid en het end-to-end-project: alles combineren

Winst:

• Mogelijkheid om reproduceerbaarheid te garanderen met vier pijlers (zaadfixatie, gegevensversiebeheer, mediabevriezing, experimentmonitoring) en hetzelfde resultaat te produceren bij herhaling van dezelfde run
• Mogelijkheid om alle registers van de module (statistieken, data, model, LLM-componenten, evaluatie, eerlijkheid, beveiliging, distributie, monitoring) te combineren in een end-to-end keten
• Mogelijkheid om te verifiëren dat de cruciale beslissing bij elke stop bij de mens blijft en het project op een controleerbare manier te documenteren

De meest verraderlijke mislukking van een ML-project is niet een crash; "Ik krijg niet opnieuw hetzelfde resultaat." Als je vandaag de partituur van het model dat je drie maanden geleden in productie hebt genomen niet kunt reproduceren, heb je niet echt controle over dat model. In deze afsluitende unit verdiepen we de reproduceerbaarheid: het vermogen om op betrouwbare wijze hetzelfde resultaat te verkrijgen met dezelfde input en de hele module te combineren in een end-to-end projectdiscipline.

Waarom reproduceerbaarheid moeilijk is

In gewone software geeft dezelfde code dezelfde uitvoer. In ML zijn er veel meer variabelen die de uitkomst bepalen:

• Willekeurigheid: het schudden van gegevens, het initialiseren van gewichten, het splitsen van gegevens: ze zijn allemaal afhankelijk van willekeur.
• Gegevens: Dezelfde code produceert een ander model met een verschillende gegevensversie.
• Omgeving: Bibliotheekversies, hardware (CPU/GPU), zelfs het besturingssysteem kunnen het resultaat wijzigen.
• Verborgen geval: een niet-opgeslagen hyperparameter, een handmatige voorverwerkingsstap, een niet-genoteerde selectie.

Reproduceerbaarheid is geen ‘nice to have’, maar een wetenschappelijke en technische noodzaak. Een resultaat dat niet kan worden gereproduceerd, is een claim die niet kan worden bewezen.

Vier pijlers van reproduceerbaarheid

1. Los willekeur op. Zet alle willekeurige zaden op één plek: het splitsen van gegevens, het initialiseren van modellen, het schudden van gegevens. Fixed Seed is de basis van de garantie "hetzelfde resultaat als u dezelfde run herhaalt".

2. Versie de gegevens. Registreer met welke gegevensversie elk experiment is uitgevoerd (gegevensversiebeheer in eenheid 2). “Laatste gegevens” zijn vaag; "dataversie v3, hash abc123" is exact.

3. Bevries het medium. Zet alle afhankelijkheden vast aan hun exacte versies (bijvoorbeeld exacte versies zoals numpy==1.26.4 in require.txt, of een containerimage). De "nieuwste versie" zal op een dag alles kapot maken.

4. Volg alles (experimenten volgen). Bewaar automatisch voor elk experiment: codeversie (git commit), dataversie, alle hyperparameters, metrieken en uitvoerstructuren. Experiment-trackingtools zoals MLflow, Weights & Biases doen dit systematisch. Zonder registratie blijft de vraag “welke instelling het beste was” onbeantwoord.

Let op: "Ik zal het me later herinneren" is de duurste misvatting. Twee weken later weet je niet meer welk zaad, welke data, welke hyperparameter je hebt gebruikt. Automatische tracking elimineert de afhankelijkheid van geheugen.

Zwakke aanpak / Sterke aanpak

Zwak: "Ik heb het beste model gevonden, het staat op de notebook, ik denk dat de score 89% was."

Strong: "Voer #147 uit in de tool voor het volgen van experimenten: git commit a3f9c, dataversie v3 (hash abc123), Seed 42, alle hyperparameters geregistreerd, test PR-AUC 0.887. Wanneer ik hetzelfde commando opnieuw uitvoer, krijg ik beetje bij beetje hetzelfde resultaat. Het model hangt af van deze run in het register."

Het verschil: bij de sterke aanpak berust het resultaat niet op een herinnering, maar op een vaste en bewaakte keten. Iedereen kan elke keer hetzelfde resultaat behalen.

End-to-end project: combinatie van module

Laten we nu de hele module combineren in één enkele projectstroom. Een echt ML-systeem doorloopt deze stops en elke stop bouwt voort op de vorige:

1. Probleemdefinitie: Wat lossen we op, hoe kunnen we succes meten (unit 3: juiste maatstaf, zakelijke context). De maatstaf en drempelwaarde zijn vanaf het begin duidelijk.
2. Datapijplijn: verzameling, validatie, opschoning, lekvrije partitionering, versiebeheer (eenheid 2).
3. Modelontwikkeling: training, basislijnvergelijking, kruisvalidatie, harde start (eenheid 3 + deze eenheid).
4. LLM-componenten (indien van toepassing): RAG (eenheid 4) en/of agenten (eenheid 5); indien nodig fijnafstemming (unit 6).
5. Evaluatie: evaluatiecluster met edge- en security cases, meerlaagse evaluatie in LLM-systemen (unit 8).
6. Justitie en ethiek audit: Subgroepanalyse, modelkaart, verklaarbaarheid (unit 10).
7. Beveiligingsaudit: snelle injectie, privacy, toeleveringsketen (eenheid 9).
8. Distributie: verpakking, geleidelijke distributie, terugdraaien, modelregistratie (eenheid 7).
9. Monitoring: Drielaags monitoring, driftalarmen (unit 8).
10. Reproduceerbaarheid: Seed-, dataversie, media- en experimenttracking door de hele keten (deze eenheid).

In deze stroom is AI bij elke stop een versneller en blauwdrukgenerator; maar metrische selectie, databeslissingen, prioritering van eerlijkheid, implementatiedrempel en goedkeuring van releases: cruciale beslissingen blijven bij de mens. Dit is de essentie van de module.

Documentatie: de toekomst zal u dankbaar zijn

Een goed ML-project documenteert zichzelf. Het volgende moet minimaal worden geschreven: probleem- en succescriteria, gegevensbron en -versie, modelselecties en rechtvaardigingen, evaluatieresultaten (inclusief subgroepen), bekende limieten en risico's, implementatie- en ophaalprocedure, monitoringplan. Dit document is de beste vriend van de persoon (misschien ben jij het) die na zes maanden terugkeert naar het project.

drie minikoffers

Geval 1 - Verloren resultaat. Een ingenieur trainde een geweldig model, maar hij repareerde het zaad niet en bewaarde de gegevensversie niet. Toen hij de baan verliet, kon niemand dat resultaat reproduceren; het model werd een "black box-legende" en werd uiteindelijk helemaal opnieuw gebouwd. Er werden weken verspild. Les: een niet-reproduceerbaar resultaat is een niet-bestaand resultaat.

Geval 2 - Instorting van het milieu. Eén team had de afhankelijkheden niet opgelost. Wanneer een bibliotheek automatisch werd bijgewerkt, veranderde de modeluitvoer stilletjes en werd de productie verstoord. Het kostte dagen om het probleem te vinden. Toen de afhankelijkheden werden bevroren en samen met de definitieve versies in containers werden geplaatst, deed het probleem zich niet meer voor. Les: bevries het milieu.

Case 3 - De kracht van monitoring. Een team hield elk experiment automatisch in de gaten. Drie maanden later beantwoordden ze tijdens een regelgevingsaudit de vraag "met welke gegevens, met welke instellingen, welke prestaties leverde het op in welke groepen?" met een volledige opname binnen enkele minuten. De keuring verliep vlot. Les: monitoring is een compliance-instrument, niet alleen een technisch instrument.

Kopieerbare sjablonen

Voer een reproduceerbaarheidscontrole uit voor dit ML-project. - Zijn alle willekeurzaden vastgelegd (splitsen, initialiseren, shuffle)? - Worden gegevensversies bepaald? - Worden afhankelijkheden bevroren tot exacte versies? - Wordt elk experiment (codevastlegging, gegevens, hyperparameter, statistiek) bijgehouden? Schrijf voor elke ontbrekende kolom concrete stappen over hoe u dit kunt oplossen.Projectstructuur: [beschrijving]

Maak een planskelet voor dit end-to-end ML-project. Probleem: [beschrijving] Behandel de volgende stops en markeer waar de MENSELIJKE beslissing bij elke stop ligt: ​​probleem/metriek, pijplijn, model, (RAG/agent/verfijnen?), evaluatie, eerlijkheid, veiligheid, distributie, monitoring, reproduceerbaarheid. Schrijf voor elke stop het belangrijkste risico en de verificatiestap op.

Maak een technisch documentatiesjabloon voor dit project. Secties: probleem+succescriteria, gegevens (bron+versie), modelselecties+verantwoording, evaluatie (inclusief subgroepen), bekende limieten+risico's, implementatie+rollback, monitoringplan. Geef de in te vullen velden per onderdeel als vragen op.

Controleer de instellingen van mijn experimentmonitoring: wordt deze bij elke run automatisch opgeslagen: git commit, dataversie/hash, alle hyperparameters, alle statistieken, omgeving (bibliotheekversies)? Krijg ik hetzelfde resultaat als ik dezelfde run opnieuw loop? Opstelling: [beschrijving]. Maak een lijst van de gebreken en correcties.

Tabel met reproduceerbaarheidskolommen

kolom

Wat staat vast

Voertuig voorbeeld

willekeur

alle zaden

zaad instelling

Gegevens

Gegevensversie/hash

DVC

omgeving

Bibliotheekversies

vereistenpin, Docker

Toezicht

Code+gegevens+instelling+metrisch

MLflow, W&B

Veel voorkomende fouten

• Het zaad niet fixeren. Het resultaat kan niet worden herhaald.
• De gegevensversie wordt niet opgeslagen. "Met welke gegevens?" blijft onbeantwoord.
• Verslavingen niet bevriezen. Een update zal alles stilletjes kapot maken.
• Experimenten in het geheugen achterlaten. Twee weken later wordt er niets meer herinnerd.
• Cruciale beslissingen laten we over aan kunstmatige intelligentie. Maatregelen, rechtvaardigheid en verdelingsbeslissingen moeten bij de mensen blijven.
• Documentatie uitstellen. Het toekomstige team (en jij) betaalt de prijs.

Samengevat

Reproduceerbaarheid is het kenmerk van serieuze ML-engineering: het niet-reproduceerbare resultaat is de onbewijsbare claim. Het wordt geleverd met vier kolommen: willekeur corrigeren, versiegegevens, omgeving bevriezen, elk experiment volgen. Een end-to-end project combineert alle registers van deze module (statistiek, data, model, LLM-componenten, evaluatie, eerlijkheid, beveiliging, distributie, monitoring) in een onderling verbonden keten; Kunstmatige intelligentie is een versneller bij elke stop, maar cruciale beslissingen blijven bij de mens. Documenteer alles — voor toekomstige team- en audits. Deze discipline is het raamwerk dat alles ondersteunt wat je tijdens de module leert.

Applicatie taak

Controleer een ML-project aan de hand van vier reproduceerbaarheidspijlers: zijn de zaden onveranderlijk, is er versiebeheer van de gegevens, is de omgeving bevroren, worden de experimenten gevolgd? Corrigeer eventuele ontbrekende kolommen en bewijs dat u dezelfde run tweemaal kunt uitvoeren en hetzelfde resultaat kunt behalen. Voer vervolgens de end-to-end-stroom van het project (10 stops) uit op één pagina en markeer bij elke stop 'waar de menselijke beslissing ligt'. Schrijf ten slotte een kort concept voor technische documentatie.

controlelijst

• [ ] Alle willekeurzaden opgelost.
• [ ] Bij elk experiment wordt de gegevensversie/hash geregistreerd.
• [ ] Afhankelijkheden worden bevroren naar vaste versies (pin/container).
• [ ] Elk experiment wordt automatisch gemonitord (code+data+setting+metric).
• [ ] Als ik dezelfde run herhaal, krijg ik hetzelfde resultaat.
• [ ] Ik heb geverifieerd en gedocumenteerd dat cruciale beslissingen in de end-to-end-stroom door mensen worden genomen.

Module-examen

1. Wat is als ML-ingenieur de beste aanpak bij het positioneren van kunstmatige intelligentie in de workflow?

• A) AI is een versneller in bedrijven met een laag risico; Kritieke beslissingen zoals statistieken, data en productie blijven gevalideerd en worden aan de mens overgelaten ✔
• B) Zolang de AI-resultaten er goed uitzien, is er geen noodzaak voor verificatie
• C) Het bespaart tijd om de beslissing om het model in productie te nemen over te laten aan kunstmatige intelligentie.
• D) Kunstmatige intelligentie is alleen nuttig voor het schrijven van tekst, het heeft niets te maken met data- en modelwerk

Beschrijving: AI is een krachtige versneller voor eenvoudig te verifiëren taken met een laag risico, zoals code, gegevenssamenvattingen en documenten; De verantwoordelijkheid voor beslissingen die van invloed zijn op geld, vertrouwelijkheid en wettelijke aansprakelijkheid, zoals de selectie van metrische gegevens, welke gegevens in de training worden gebruikt en het in productie nemen van het model, ligt echter bij de gekwalificeerde ingenieur en het gekwalificeerde team. Elke uitgang mag niet zonder verificatie worden gebruikt.

2. Waarom wordt schemavalidatie aan het begin van een datapijplijn geplaatst?

• A) Omdat het de nauwkeurigheid van het model direct vergroot
• B) Omdat het versiebeheer van gegevens overbodig maakt
• C) Omdat het beschadigde gegevens op het vroegste en goedkoopste punt onderschept en voorkomt dat deze naar de volgende stappen lekken ✔
• D) Omdat het de noodzaak van etikettering elimineert

Uitleg: Hoe eerder corrupte gegevens worden ontdekt, hoe goedkoper het is om deze te repareren. Schemavalidatie voorkomt dat corrupte gegevens stilletjes in training of productie lekken door gegevens buiten het verwachte type en bereik aan het begin van de regel te weigeren (bijvoorbeeld een prijsverschuiving van 100x bij verandering van eenheid); Dezelfde fout die tijdens de productie wordt gemaakt, is vele malen duurder.

3. Wat is de juiste aanpak bij het opdelen van data in training en testen bij een tijdsprobleem (tijdreeksen)?

• A) Het gebruik van willekeurige splitsing omdat dit altijd de eerlijkste methode is
• B) Gebruik maken van temporele splitsing: voorkom lekkage door te trainen met het verleden en te testen in de toekomst ✔
• C) Alle gegevens gebruiken voor zowel training als testen
• D) Testgegevens opnemen in schaalparameters vóór de training

Uitleg: Willekeurige opsplitsing van tijdreeksen geeft het model een 'toekomstgericht' voordeel dat nooit zal gebeuren in de productie en verhoogt de metrieken kunstmatig (temporele lekkage). De juiste is de indeling in tijd: train met het verleden, test in de toekomst. Dit meet de daadwerkelijke prestaties waardoor het in productie blijft.

4. Waarom is nauwkeurigheid misleidend in een fraudedetectiemodel met een positief klassenpercentage van 1,5%?

• A) Omdat de nauwkeurigheid altijd laag is bij onevenwichtige gegevens
• B) Omdat nauwkeurigheid alleen kan worden gebruikt bij regressieproblemen
• C) Omdat nauwkeurigheidsberekeningen veel rekenkracht vereisen
• D) Zelfs een schamel model dat de meerderheidsklasse voorspelt, kan zeer accuraat zijn en daarmee echt succes verbergen ✔

Uitleg: Op basis van onevenwichtige gegevens haalt zelfs een basismodel dat zegt 'noem alles negatief' een nauwkeurigheid van ongeveer 98,5%, maar zal geen enkele fraude ontdekken. Daarom worden bij onevenwichtige classificatie precisie, terugroepen, F1 of PR-AUC gebruikt in plaats van nauwkeurigheid, en wordt elke metriek geïnterpreteerd volgens een basismodel.

5. Waarom is vergelijking van de uitgangssituatie essentieel als het over de metriek van een model gaat?

• A) Omdat het basismodel altijd beter is dan het echte model
• B) Omdat het alleen duidelijk is of een metriek zinvol is of niet, wanneer deze wordt vergeleken met een eenvoudig basismodel ✔
• C) Omdat het basismodel kruisvalidatie overbodig maakt
• D) Omdat het basismodel wettelijk verplicht is in elke rapportage

Uitleg: Een metriek is op zichzelf niet goed of slecht; Het is goed of slecht volgens een basismodel. De zin '85% correct' betekent vrijwel waardeloos als het basismodel al 84% haalt, en perfect als het 50% haalt. Zonder een vergelijkingsanker is de metriek zinloos.

6. Wat is het meest kritische beveiligingselement dat moet worden opgenomen in de productieprompt van het RAG-systeem (Retrieval-Augmented Generation)?

• A) Instructie om alleen op de gegeven bron te vertrouwen, om 'Ik weet het niet' te zeggen als de bron niet bestaat, en om de bron te citeren ✔
• B) Het model vertellen om zo lange en creatieve antwoorden mogelijk te maken
• C) Het model geeft voorrang aan de eigen onderwijskennis boven middelen
• D) Implementeer alle instructies in de documenten die als opdrachten zijn aangeleverd

Uitleg: De allerbelangrijkste instructie van RAG is om het model te vertellen alleen te vertrouwen op de gegeven bron, en als de informatie niet in de bron staat, zeg dan 'Ik weet het niet' en citeer de bron zonder deze te verzinnen. Zonder deze triade negeert het model mogelijk de context en produceert het hallucinaties, en wordt het antwoord oncontroleerbaar.

7. Een RAG-systeem geeft onjuiste antwoorden. Waar kan ik het beste beginnen met de diagnose?

• A) Eerst het ophalen meten (Recall@K): komt het juiste stuk ooit aan? ✔
• B) Vervang het model onmiddellijk door een groter exemplaar
• C) Wijzig de prompt willekeurig en blijf proberen
• D) Het inbedden van alle documenten in het model met finetuning

Uitleg: De zwakste schakel van RAG is doorgaans het ophalen en niet de productie. Als het juiste onderdeel nooit wordt gebracht, kan het model die informatie niet produceren, hoezeer de prompt ook wordt verbeterd. Daarom wordt er eerst bij Recall@K gemeten of het juiste onderdeel is aangekomen; Als de fetch goed is, wordt er gekeken naar de productie en de prompt.

8. Welke acties moeten achter de menselijke goedkeuring worden geplaatst als er een hulpmiddel aan een agent wordt gegeven?

• A) Geen; De agent moet elke actie autonoom kunnen uitvoeren
• B) Alleen omkeerbare acties zoals het lezen en zoeken van gegevens
• C) Onomkeerbare acties of acties met grote impact, zoals geld overmaken, verwijderen, verzenden ✔
• D) Acties waarbij alleen berekeningen betrokken zijn

Beschrijving: Acties worden gescheiden op risiconiveau. Ophaalbare taken zoals lezen, zoeken, berekenen en concepten genereren kunnen autonoom worden uitgevoerd; Onomkeerbare of ingrijpende handelingen zoals het overmaken van geld, het versturen van e-mails, het verwijderen van gegevens, het plaatsen van bestellingen etc. vereisen echter menselijke goedkeuring. Elke onherroepelijke handeling moet onderworpen zijn aan toestemming.

9. Wat is de beste ontwerpaanpak tegen het risico van indirecte injectie?

• A) Het is voldoende om een enkele zin 'negeer slechte instructies' aan de systeemprompt toe te voegen
• B) Geef het model meer autoriteit door te vertrouwen op instructies in externe inhoud
• C) Geen voorzorgsmaatregelen nemen omdat injectie niet te voorkomen is
• D) Het isoleren van externe inhoud als onbetrouwbare gegevens en het opzetten van gelaagde verdedigingen met minimale autorisatie, goedkeuring en uitvoercontrole ✔

Beschrijving: Externe inhoud die door de agent of RAG wordt verwerkt, zoals een webpagina, document, e-mail, enz., zijn niet-vertrouwde gegevens en kunnen geheime instructies bevatten. De juiste aanpak is een gelaagde verdediging: het isoleren van externe inhoud als 'data, niet als commando's' met duidelijke scheidingstekens, het toepassen van minimale autorisatie, het binden van onomkeerbare acties aan menselijke goedkeuring, en het controleren van de output. Eén enkele regel instructies is niet voldoende.

10. Wat is het belangrijkste onderscheid bij de beslissing of een probleem moet worden opgelost met fine-tuning of RAG?

• A) Informatieproblemen worden beter opgelost met RAG, gedrags-/formaatproblemen worden beter opgelost met fijnafstemming ✔
• B) Elk probleem moet altijd worden opgelost door middel van fine-tuning
• C) RAG wordt alleen gebruikt voor het genereren van code, fijnafstemming wordt alleen gebruikt voor vertaling
• D) Fine-tuning kan altijd goedkoper en sneller worden bijgewerkt dan RAG

Uitleg: Het nauwkeurig afstemmen is zwak en riskant bij het aanleren van nieuwe informatie aan het model; maar is krachtig in het aanleren van gedrag, format, toon en stijl. 'Het modelbedrijf kent onze data niet' is een informatieprobleem en hoort bij RAG. 'Laat het model altijd in ons strikte format uitvoeren' is een gedragsprobleem en een kandidaat voor verfijning. Bovendien moeten er snelle en weinig opnamen worden gemaakt voordat er wordt verfijnd.

11. Wat is verplicht voor een veilige implementatie bij het in productie nemen van een nieuw model?

• A) Als het model goed is getest, open het dan direct voor 100% verkeer
• B) Na de inzet helemaal geen monitoring meer opzetten
• C) Gefaseerde implementatie (schaduw/kanarie) en een vooraf getest rollback-plan ✔
• D) Het model publiceren, zelfs als de evaluatiedrempel niet wordt gehaald

Uitleg: Het rechtstreeks openstellen van het nieuwe model voor al het verkeer is riskant; Als het verkeerd is, wordt iedereen getroffen. Het juiste is dat het een geleidelijke distributie is (schaduw, kanarie) en dat elke distributie een getest terugdraaiplan heeft. Een uitkering is niet compleet zonder een terugvorderingsplan; De mogelijkheid om binnen enkele minuten terug te keren naar de vorige versie beschermt de gebruiker wanneer het model zich tijdens de productie onverwacht gedraagt.

12. Hoe kan een ML-model 'stil' falen in productie en wat is de manier om dit op te vangen?

• A) Het model stort in; serverlogboeken laten dit zien
• B) Door verkeerde voorspellingen te doen zonder fouten te maken; ✔ Het legt operationele, input- en outputgelaagde monitoring vast
• C) Model kan nooit stil falen, altijd alarmeren
• D) Alleen het monitoren van de latentie is voldoende om eventuele degradatie op te vangen

Uitleg: Het model kan simpelweg mislukken door onjuiste voorspellingen te doen, zonder te crashen of fouten te geven; De belangrijkste reden hiervoor is datadrift en conceptdrift. Alleen het monitoren van operationele statistieken (latentie, foutenpercentage) is niet voldoende; Ook de inputverdeling en de output/voorspellingsverdeling moeten worden gemonitord. Invoerdrift geeft vroegtijdige waarschuwing als het daadwerkelijke resultaat wordt uitgesteld.

13. Welk principe is essentieel bij het gebruik van LLM-als-rechter om een ​​LLM-systeem te evalueren?

• A) LLM-scheidsrechter heeft altijd gelijk, menselijke verificatie is niet nodig
• B) De scheidsrechter moet een beslissing nemen die alleen gebaseerd is op de lengte van het antwoord.
• C) Op regels gebaseerde controles en menselijke evaluatie moeten volledig achterwege worden gelaten wanneer scheidsrechters worden gebruikt
• D) De scores van juryleden moeten worden gekalibreerd met een door mensen gelabeld monster en hun bias moet worden gemeten voordat ze kunnen worden vertrouwd ✔

Beschrijving: LLM-scheidsrechter is ook model; Het kan hallucinerend, bevooroordeeld (voorkeur voor lange, zelfverzekerde antwoorden) en inconsistent zijn. Daarom moeten scheidsrechterscores worden gekalibreerd met een door mensen gelabeld monster en moet hun systematische bias worden gemeten voordat de productiebeslissing wordt genomen. Een niet-geverifieerde scheidsrechter geeft vals vertrouwen.

14. Waarom is het kijken naar de algehele nauwkeurigheid onvoldoende bij het beoordelen van modelbias?

• A) De algehele nauwkeurigheid is voldoende omdat deze altijd de prestaties van de slechtste groep weerspiegelt
• B) De algehele nauwkeurigheid alleen is onvoldoende omdat het systematische verschillen (verborgen discriminatie) tussen subgroepen kan verdoezelen ✔
• C) Omdat nauwkeurigheid een maatstaf is die niets met vooringenomenheid te maken heeft
• D) Vooroordelen komen alleen voort uit het model en hebben niets te maken met de gegevens.

Uitleg: De algehele nauwkeurigheid kan systematische verschillen tussen subgroepen verdoezelen. Hoewel de algehele nauwkeurigheid bijvoorbeeld 88% is, kan de herinnering in de ene groep 91% zijn en in een andere groep 67%; Het model mist die groep systematisch. Daarom moet het model worden geëvalueerd op basis van subgroepen (demografie/segment) en moet samen met de belanghebbenden worden besloten welke definitie van rechtvaardigheid prioriteit moet krijgen.

15. Welke vier dingen moeten aan elkaar worden gekoppeld om een ​​ML-resultaat reproduceerbaar te maken?

• A) Alleen modelnaam, maat, prijs en releasedatum
• B) Alleen GPU-merk en internetsnelheid
• C) Alleen de uiteindelijke nauwkeurigheidsscore van het model; de rest kan in het geheugen worden bewaard
• D) Willekeurigheidszaad, gegevensversie, omgeving (afhankelijkheidsversies) en het volgen van experimenten ✔

Beschrijving: Reproduceerbaarheid wordt bereikt door middel van vier pijlers: het vaststellen van willekeurzaden, versiebeheer van gegevens (versie/hash), het bevriezen van de omgeving (exacte bibliotheekversies/container) en het volgen van elk experiment (codevastlegging, gegevens, hyperparameter, statistiek). Zonder deze keten is het niet mogelijk hetzelfde resultaat te reproduceren; Een niet-reproduceerbaar resultaat is een claim die niet kan worden bewezen.