Reproduserbarhet og ende-til-ende-prosjektet: Kombinere alt — Kunstig intelligens i kunstig intelligens og maskinlæringsteknikk

Gevinster:

Evne til å sikre reproduserbarhet med fire pilarer (frøfiksering, dataversjon, mediafrysing, eksperimentovervåking) og produsere det samme resultatet når du gjentar samme kjøring
Evne til å kombinere alle stopp i modulen (metrikk, data, modell, LLM-komponenter, eval, rettferdighet, sikkerhet, distribusjon, overvåking) i en ende-til-ende-kjede
Evne til å verifisere at den kritiske beslutningen forblir hos mennesket ved hvert stopp og dokumentere prosjektet på en kontrollerbar måte

Den mest lumske fiaskoen til et ML-prosjekt er ikke et krasj; "Får ikke samme resultat igjen." Hvis du ikke kan reprodusere poengsummen i dag til modellen du satte i produksjon for tre måneder siden, kontrollerer du egentlig ikke den modellen. I denne avsluttende enheten utdyper vi reproduserbarheten: evnen til pålitelig å oppnå det samme resultatet med de samme inputene og kombinere hele modulen i en ende-til-ende prosjektdisiplin.

Hvorfor reproduserbarhet er vanskelig

I vanlig programvare gir samme kode samme utgang. I ML er det mange flere variabler som bestemmer utfallet:

Tilfeldighet: Datastokking, vektinitialisering, datadeling – alt er avhengig av tilfeldighet.
Data: Samme kode produserer forskjellig modell med forskjellig dataversjon.
Miljø: Bibliotekversjoner, maskinvare (CPU/GPU), til og med operativsystem kan endre resultatet.
Skjult tilfelle: En ulagret hyperparameter, et manuelt forbehandlingstrinn, et unotert utvalg.

Reproduserbarhet er ikke en "hyggelig å ha", men et vitenskapelig og teknisk imperativ. Et resultat som ikke kan reproduseres er en påstand som ikke kan bevises.

Fire søyler for reproduserbarhet

1. Fiks tilfeldighet. Sett alle tilfeldige frø på ett sted: datadeling, modellinitialisering, stokking av data. Fast frø er grunnlaget for "samme resultat når du gjentar samme kjøring"-garanti.

2. Versjon dataene. Registrer hvilken dataversjon hvert eksperiment ble utført med (dataversjon i enhet 2). "Siste data" er vage; "dataversjon v3, hash abc123" er nøyaktig.

3. Frys mediet. Fest alle avhengigheter til deres eksakte versjoner (f.eks. eksakte versjoner som numpy==1.26.4 i requirements.txt, eller et beholderbilde). Den "nyeste versjonen" vil ødelegge alt en dag.

4. Spor alt (eksperimentsporing). Lagre automatisk for hvert eksperiment: kodeversjon (git commit), dataversjon, alle hyperparametre, beregninger og utdatastrukturer. Eksperimentsporingsverktøy som MLflow, Weights & Biases gjør dette systematisk. Uten registrering forblir spørsmålet "hvilken innstilling var best" ubesvart.

Forsiktig: "Jeg husker senere" er den dyreste feilslutningen. To uker senere vil du ikke huske hvilket frø, hvilke data, hvilke hyperparameter du brukte. Automatisk sporing eliminerer avhengighet av minne.

Svak tilnærming / Sterk tilnærming

Svak: "Jeg fant den beste modellen, den er på den bærbare datamaskinen, jeg tror poengsummen var 89 %."

Strong: "Kjør #147 i eksperimentsporingsverktøyet: git commit a3f9c, dataversjon v3 (hash abc123), seed 42, alle hyperparametere registrert, test PR-AUC 0.887. Når jeg kjører samme kommando igjen, får jeg samme resultat bit for bit. Modellen avhenger av denne kjøringen i registeret."

Forskjellen: i den sterke tilnærmingen er resultatet ikke basert på et minne, men på en fast og overvåket kjede. Alle kan produsere det samme resultatet hver gang.

End-to-end-prosjekt: kombinasjon av modul

La oss nå kombinere hele modulen til en enkelt prosjektflyt. Et ekte ML-system går gjennom disse stoppene, og hvert stopp bygger på det forrige:

Problemdefinisjon: Hva løser vi, hvordan måle suksess (enhet 3: riktig metrikk, forretningskontekst). Metrikken og terskelen er tydelig fra starten.
Datapipeline: Innsamling, validering, rensing, lekkasjefri partisjonering, versjonering (enhet 2).
Modellutvikling: Trening, baseline sammenligning, kryssvalidering, hard frø (enhet 3 + denne enheten).
LLM-komponenter (hvis aktuelt): RAG (enhet 4) og/eller midler (enhet 5); finjustering om nødvendig (enhet 6).
Evaluering: eval cluster med kant- og sikkerhetskofferter, flerlags eval i LLM-systemer (enhet 8).
Justis- og etikkrevisjon: Undergruppeanalyse, modellkort, forklarbarhet (enhet 10).
Sikkerhetsrevisjon: Rask injeksjon, personvern, forsyningskjede (enhet 9).
Distribusjon: Emballasje, gradvis distribusjon, tilbakerulling, modellregister (enhet 7).
Overvåking: Trelags overvåking, driftalarm (enhet 8).
Reproduserbarhet: Seed, dataversjon, media og eksperimentsporing gjennom hele kjeden (denne enheten).

I denne flyten er AI en akselerator og blåkopigenerator ved hvert stopp; men metrikkvalg, databeslutninger, rettferdighetsprioritering, distribusjonsterskel og utgivelsesgodkjenning – kritiske beslutninger forblir hos mennesket. Dette er essensen av modulen.

Dokumentasjon: fremtiden vil takke deg

Et godt ML-prosjekt dokumenterer seg selv. Som et minimum bør følgende skrives: problem- og suksesskriterier, datakilde og versjon, modellvalg og begrunnelser, evalueringsresultater (inkludert undergrupper), kjente grenser og risikoer, utplassering og gjenfinningsprosedyre, overvåkingsplan. Dette dokumentet er bestevennen til personen (kanskje det er deg) som kommer tilbake til prosjektet etter seks måneder.

tre minisaker

Tilfelle 1 - Tapt resultat. En ingeniør lærte opp en flott modell, men han fikset ikke frøet og lagret ikke dataversjonen. Da han forlot jobben, var det ingen som kunne gjengi det resultatet; modellen ble en "black box legend" og ble til slutt bygget fra bunnen av. Uker var bortkastet. Leksjon: et ikke-reproduserbart resultat er et ikke-eksisterende resultat.

Sak 2 - Miljøkollaps. Ett team hadde ikke fikset avhengighetene. Når et bibliotek ble oppdatert automatisk, endret modellutgangene seg stille og produksjonen ble forstyrret. Det tok dager å finne problemet. Da avhengighetene ble frosset og containerisert med de definitive versjonene, oppsto ikke problemet igjen. Leksjon: frys miljøet.

Case 3 - Kraften til overvåking. Et team overvåket automatisk hvert eksperiment. Tre måneder senere, under en regulatorisk revisjon, svarte de på spørsmålet "med hvilke data, med hvilke innstillinger, hvilken ytelse fikk den i hvilke grupper?" med et fullstendig opptak innen minutter. Inspeksjonen gikk greit. Leksjon: overvåking er et samsvarsverktøy, ikke bare et teknisk.

Kopierbare maler

Gjør en reproduserbarhetssjekk for dette ML-prosjektet.- Er alle randomness-seeds fikset (splitt, initialiser, shuffle)?- Er dataversjonert?- Er avhengigheter frosset til eksakte versjoner?- Blir hvert eksperiment (kodeforpliktelse, data, hyperparameter, metrikk) sporet? Skriv konkrete trinn for hvordan du fikser det for hver manglende kolonne. Prosjektstruktur: [beskrivelse]

Lag et planskjelett for dette ende-til-ende ML-prosjektet. Problem: [beskrivelse] Dekk til følgende stopp og marker hvor den MENNESKELIGE avgjørelsen er ved hvert stopp: problem/metrikk, pipeline, modell, (RAG/agent/finjustering?), eval, rettferdighet, sikkerhet, distribusjon, overvåking, reproduserbarhet. Skriv hovedrisiko- og verifiseringstrinnet for hvert stopp.

Lag en mal for teknisk dokumentasjon for dette prosjektet. Seksjoner: problem+suksesskriterier, data (kilde+versjon), modellvalg+begrunnelse, evaluering (inkludert undergrupper), kjente grenser+risikoer, deployment+rollback, overvåkingsplan. Oppgi feltene som skal fylles ut for hver del som spørsmål.

Sjekk oppsettet for eksperimentovervåking: Er det automatisk lagret ved hver kjøring: git commit, dataversjon/hash, alle hyperparametre, alle beregninger, miljø (bibliotekversjoner)? Får jeg det samme resultatet når jeg løper det samme løpet igjen? Oppsett: [beskrivelse]. List opp feilene og rettelsen.

Tabell for reproduserbarhetskolonner

kolonne

Hva er fikset

Eksempel på kjøretøy

tilfeldighet

alle frø

frøinnstilling

Data

Dataversjon/hash

DVC

miljø

Bibliotekversjoner

krav pin, Docker

Overvåking

Kode+data+innstilling+beregning

MLflow, W&B

Vanlige feil

Ikke fikser frøet. Resultatet kan ikke gjentas.
Lagrer ikke dataversjonen. "Med hvilke data?" forblir ubesvart.
Ikke fryseavhengighet. En oppdatering vil i det stille bryte alt.
Overlater eksperimenter til minnet. To uker senere huskes ingenting.
Overlater kritiske beslutninger til kunstig intelligens. Beslutninger om beregninger, rettferdighet og distribusjon bør forbli hos folk.
Utsettelse av dokumentasjon. Det fremtidige laget (og du) betaler prisen.

Oppsummert

Reproduserbarhet er signaturen til seriøs ML-teknikk: det ikke-reproduserbare resultatet er den ubeviselige påstanden. Den kommer med fire kolonner - fiks tilfeldighet, versjonsdata, frys miljø, spor hvert eksperiment. Et ende-til-ende-prosjekt kombinerer alle delene av denne modulen (metrikk, data, modell, LLM-komponenter, eval, rettferdighet, sikkerhet, distribusjon, overvåking) i en sammenkoblet kjede; Kunstig intelligens er en akselerator ved hvert stopp, men kritiske beslutninger forblir hos mennesket. Dokumenter alt - for fremtidige team og revisjoner. Denne disiplinen er rammeverket som opprettholder alt du lærer gjennom hele modulen.

Søknadsoppgave

Sjekk et ML-prosjekt mot fire reproduserbarhetspilarer: er frøene uforanderlige, er dataene versjonert, er miljøet frosset, spores eksperimentene? Rett opp eventuelle manglende kolonner og bevis at du kan kjøre samme løp to ganger og få samme resultat. Skriv deretter ut ende-til-ende-flyten av prosjektet (10 stopp) på én side og merk "hvor den menneskelige avgjørelsen er" ved hvert stopp. Skriv til slutt et kort teknisk dokumentasjonsutkast.

sjekkliste

[ ] Alle tilfeldighetsfrø fikset.
[ ] Dataversjon/hash registreres med hvert eksperiment.
[ ] Avhengighetene fryses til faste versjoner (stift/beholder).
[ ] Hvert eksperiment overvåkes automatisk (kode+data+innstilling+metrikk).
[ ] Når jeg gjentar samme løpetur, får jeg samme resultat.
[ ] Jeg bekreftet og dokumenterte at kritiske beslutninger i ende-til-ende-flyten tas av mennesker.

Moduleksamen

1. Som ML-ingeniør, hva er den beste tilnærmingen når du plasserer kunstig intelligens i arbeidsflyten?

A) AI er en akselerator i lavrisikobedrifter; Kritiske beslutninger som beregninger, data og produksjon forblir validert og overlatt til mennesket ✔
B) Så lenge AI-utgangene ser bra ut, er det ikke behov for verifisering
C) Å overlate beslutningen om å sette modellen i produksjon til kunstig intelligens sparer tid.
D) Kunstig intelligens er kun nyttig for å skrive tekst, det har ingenting med data og modellarbeid å gjøre

Beskrivelse: AI er en kraftig akselerator for lavrisiko, lett verifiserte oppgaver som kode, datasammendrag og dokumenter; Ansvaret for avgjørelser som påvirker penger, konfidensialitet og juridisk ansvar, for eksempel metrisk valg, hvilke data som går inn i opplæringen og sette modellen i produksjon, ligger hos den kvalifiserte ingeniøren og teamet. Hver utgang skal ikke brukes uten verifisering.

2. Hvorfor plasseres skjemavalidering i begynnelsen av en datapipeline?

A) Fordi det direkte øker nøyaktigheten til modellen
B) Fordi det gjør dataversjon unødvendig
C) Fordi den fanger opp ødelagte data på det tidligste og billigste punktet og hindrer dem i å lekke inn i de neste trinnene ✔
D) Fordi det eliminerer behovet for merking

Forklaring: Jo tidligere korrupte data fanges opp, jo billigere er det å fikse det. Skjemavalidering forhindrer at korrupte data i det stille lekker inn i trening eller produksjon ved å avvise data utenfor forventet type og rekkevidde på begynnelsen av linjen (f.eks. prisforskyvning 100x med enhetsendring); Den samme feilen som fanges i produksjonen er mange ganger dyrere.

3. Hva er riktig tilnærming når man deler inn data i trening og testing i et problem som involverer tid (tidsserier)?

A) Bruke tilfeldig splitting fordi det alltid er den mest rettferdige metoden
B) Bruk av tidssplitting: forhindre lekkasje ved å trene med fortiden og teste i fremtiden ✔
C) Bruke alle data som både trening og testing
D) Innlemme testdata i skaleringsparametere før trening

Forklaring: Tilfeldig deling på tidsserier gir modellen en "fremtidsskuende" fordel som aldri vil skje i produksjon og kunstig blåser opp metrikkene (temporal lekkasje). Den riktige er tidsdeling: tren med fortiden, test i fremtiden. Dette måler den faktiske ytelsen som holder den i produksjon.

4. Hvorfor er nøyaktighet villedende i en svindeldeteksjonsmodell med en positiv klasserate på 1,5 %?

A) Fordi nøyaktigheten alltid er lav på ubalanserte data
B) Fordi nøyaktighet kun kan brukes på regresjonsproblemer
C) Fordi Nøyaktighetsberegning krever mye prosessorkraft
D) Selv en ynkelig modell som forutsier majoritetsklassen kan være svært nøyaktig, og dermed skjule reell suksess ✔

Forklaring: På ubalanserte data får til og med en grunnleggende modell som sier 'ring alt negativt' omtrent 98,5 % nøyaktighet, men vil ikke fange en eneste svindel. Derfor, i ubalansert klassifisering, brukes presisjon, tilbakekalling, F1 eller PR-AUC i stedet for nøyaktighet, og hver metrikk tolkes i henhold til en basismodell.

5. Hvorfor er grunnlinjesammenlikning viktig når man snakker om en modells beregning?

A) Fordi grunnmodellen alltid er bedre enn den virkelige modellen
B) Fordi det er klart om en beregning er meningsfull eller ikke bare sammenlignet med en enkel grunnlinjemodell ✔
C) Fordi basismodellen gjør kryssvalidering unødvendig
D) Fordi grunnmodellen er lovpålagt i hver rapport

Forklaring: En beregning er ikke god eller dårlig i seg selv; Det er bra eller dårlig i henhold til en grunnleggende modell. Setningen '85% riktig' betyr nesten verdiløs hvis basismodellen allerede får 84%, og perfekt hvis den får 50%. Uten et sammenligningsanker er metrikken meningsløs.

6. Hvilket er det mest kritiske sikkerhetselementet som bør inkluderes i produksjonsmeldingen til RAG-systemet (Retrieval-Augmented Generation)?

A) Instruksjon om å stole kun på kilden som er gitt, å si "jeg vet ikke" hvis kilden ikke eksisterer, og å sitere kilden ✔
B) Be modellen om å produsere så lange og kreative svar som mulig
C) Modellen prioriterer egen pedagogisk kunnskap fremfor ressurser
D) Implementer alle instruksjoner i dokumentene som er tatt med som kommandoer

Forklaring: Den viktigste enkeltinstruksen til RAG er å fortelle modellen at den kun skal stole på kilden som er gitt, og hvis informasjonen ikke er i kilden, si 'jeg vet ikke' og siter kilden uten å finne på det. Uten denne triaden kan modellen ignorere kontekst og produsere hallusinasjoner, og svaret blir uverifiserbart.

7. Et RAG-system gir feil svar. Hvor er det beste stedet å starte diagnose?

A) Måler apport først (Recall@K): kommer det riktige stykket noen gang? ✔
B) Skift ut modellen umiddelbart med en større
C) Endre ledeteksten tilfeldig og fortsett å prøve
D) Innebygging av alle dokumenter i modellen med finjustering

Forklaring: RAGs svakeste ledd er vanligvis apport, ikke produksjon. Hvis den riktige delen aldri blir tatt med, kan ikke modellen produsere den informasjonen, uansett hvor mye forespørselen er forbedret. Derfor måles først Recall@K for å se om den riktige delen har kommet; Hvis apporten er god, undersøkes produksjonen og prompten.

8. Hvilke handlinger bør settes bak menneskelig godkjenning når man gir et verktøy til en agent?

A) Ingen; Agenten må kunne utføre hver handling autonomt
B) Kun reversible handlinger som å lese og søke etter data
C) Irreversible eller høye virkningshandlinger som å overføre penger, slette, sende ✔
D) Handlinger som kun involverer beregninger

Beskrivelse: Handlinger er atskilt etter risikonivå. Hentbare oppgaver som å lese, søke, beregne og generere utkast kan gjøres autonomt; Imidlertid krever irreversible handlinger med stor innvirkning som å overføre penger, sende e-poster, slette data, legge inn bestillinger osv. menneskelig godkjenning. Enhver ugjenkallelig handling må være underlagt samtykke.

9. Hva er den beste designtilnærmingen mot risikoen for indirekte umiddelbar injeksjon?

A) Det er nok å legge til en enkelt setning 'ignorer dårlige instruksjoner' til systemmeldingen
B) Gi mer autoritet til modellen ved å stole på instruksjoner i eksternt innhold
C) Ikke ta noen forholdsregler fordi injeksjon ikke kan forebygges
D) Isolere eksternt innhold som upålitelige data og etablere lagdelte forsvar med minimal autorisasjon, godkjenning og utdatakontroll ✔

Beskrivelse: Eksternt innhold som behandles av agenten eller RAG, for eksempel en nettside, et dokument, e-post osv., er ikke-klarerte data og kan inneholde hemmelige instruksjoner. Den riktige tilnærmingen er lagdelt forsvar: å isolere eksternt innhold som "data, ikke kommandoer" med klare skilletegn, bruke minimal autorisasjon, binde irreversible handlinger til menneskelig godkjenning og revidere utdataene. En enkelt linje med instruksjoner er ikke nok.

10. Hva er hovedskillet når man skal avgjøre om et problem skal løses med finjustering eller RAG?

A) Informasjonsproblemer løses bedre med RAG, atferds-/formatproblemer løses bedre med finjustering ✔
B) Ethvert problem skal alltid løses ved å finjustere
C) RAG brukes kun til kodegenerering, finjustering brukes kun til oversettelse
D) Finjustering kan alltid oppdateres billigere og raskere enn RAG

Forklaring: Finjustering er svakt og risikabelt når det gjelder å lære modellen ny informasjon; men er kraftig i å undervise atferd, format, tone og stil. 'Modelselskapet kjenner ikke våre data' er et informasjonsproblem og tilhører RAG. 'La modellen alltid skrive ut i vårt strenge format' er et atferdsproblem og en kandidat for finjustering. I tillegg bør raske og få bilder tas før finjustering.

11. Hva er obligatorisk for sikker utplassering når en ny modell settes i produksjon?

A) Hvis modellen er god i testing, åpne den direkte for 100 % trafikk
B) Ikke sette opp overvåking i det hele tatt etter utplassering
C) Fasevis distribusjon (skygge/kanarifugl) og en forhåndstestet tilbakerullingsplan ✔
D) Publisering av modellen selv om evalueringsterskelen ikke er oppfylt

Forklaring: Å åpne den nye modellen direkte for all trafikk er risikabelt; Hvis det er feil, er alle berørt. Det riktige er at det er en gradvis distribusjon (skygge, kanarifugl) og hver distribusjon har en testet tilbakerullingsplan. En distribusjon er ikke komplett uten en clawback-plan; Å kunne gå tilbake til forrige versjon innen minutter beskytter brukeren når modellen oppfører seg uventet i produksjonen.

12. Hvordan kan en ML-modell feile 'stille' i produksjonen, og hvordan kan man fange opp dette?

A) Modellen kollapser; serverlogger viser dette
B) Ved å produsere feil spådommer uten å gjøre feil; ✔ Den fanger opp drifts-, input- og output-lagdelt overvåking
C) Modellen kan aldri feile stille, alltid alarm
D) Bare overvåking av latens er nok til å fange opp eventuell forringelse

Forklaring: Modellen kan feile ganske enkelt ved å produsere feil prediksjoner uten å krasje eller gi feil; Hovedårsaken til dette er datadrift og konseptdrift. Bare overvåking av operasjonelle beregninger (latens, feilrate) er ikke nok; input distribusjon og output / prediksjon distribusjon bør også overvåkes. Inndatadrift gir tidlig varsel hvis det faktiske resultatet er forsinket.

13. Hvilket prinsipp er viktig når du bruker LLM-som-dommer for å evaluere et LLM-system?

A) LLM-dommer er alltid korrekt, menneskelig verifisering er unødvendig
B) Dommeren må ta en avgjørelse basert kun på svarlengde.
C) Regelbaserte kontroller og menneskelig evaluering bør forkastes fullstendig når dommere brukes
D) Dommerscore bør kalibreres med en menneskemerket prøve og deres skjevhet måles før de kan stoles på ✔

Beskrivelse: LLM-dommer er også modell; Det kan være hallusinatorisk, partisk (foretrekker lange, sikre svar) og inkonsekvente. Derfor må dommerpoeng kalibreres med en menneskemerket prøve og deres systematiske skjevhet må måles før produksjonsbeslutningen tas. En ubekreftet dommer gir falsk tillit.

14. Hvorfor er det utilstrekkelig å se på den generelle nøyaktigheten når man vurderer modellskjevhet?

A) Samlet nøyaktighet er tilstrekkelig fordi den alltid gjenspeiler ytelsen til den dårligste gruppen
B) Total nøyaktighet alene er utilstrekkelig da det kan skjule systematisk forskjell (skjult diskriminering) mellom undergrupper ✔
C) Fordi nøyaktighet er en metrikk som ikke har noe med skjevhet å gjøre
D) Bias kommer kun fra modellen og har ingenting med dataene å gjøre.

Forklaring: Samlet nøyaktighet kan skjule systematiske forskjeller mellom undergrupper. For eksempel, mens den totale nøyaktigheten er 88 %, kan tilbakekalling være 91 % i én gruppe og 67 % i en annen gruppe; Modellen savner systematisk den gruppen. Derfor bør modellen vurderes ut fra undergrupper (demografi/segment) og hvilken definisjon av rettferdighet som skal prioriteres bør avgjøres med interessenter.

15. Hvilke fire ting må fikses sammen for at et ML-resultat skal være reproduserbart?

A) Bare modellnavn, størrelse, pris og utgivelsesdato
B) Kun GPU-merke og internetthastighet
C) Bare den endelige nøyaktighetsscore for modellen; resten kan holdes i minnet
D) Tilfeldighetsfrø, dataversjon, miljø (avhengighetsversjoner) og eksperimentsporing ✔

Beskrivelse: Reproduserbarhet oppnås gjennom fire pilarer: fikse tilfeldighetsfrø, versjonsdata (versjon/hash), frysing av miljøet (nøyaktige bibliotekversjoner/beholder) og sporing av hvert eksperiment (kodebekreftelse, data, hyperparameter, metrikk). Uten denne kjeden er det ikke mulig å reprodusere det samme resultatet; Et ikke-reproduserbart resultat er en påstand som ikke kan bevises.