Reproducerbarhed og End-to-End-projektet: At kombinere alt

Gevinster:

• Evne til at sikre reproducerbarhed med fire søjler (frøfiksering, dataversionering, mediefrysning, eksperimentovervågning) og producere det samme resultat, når den samme kørsel gentages
• Evne til at kombinere alle modulers stop (metrics, data, model, LLM-komponenter, eval, fairness, sikkerhed, distribution, overvågning) i en ende-til-ende kæde
• Evne til at verificere, at den kritiske beslutning forbliver hos mennesket ved hvert stop og dokumentere projektet på en auditerbar måde

Den mest lumske fiasko i et ML-projekt er ikke et nedbrud; "Får ikke det samme resultat igen." Hvis du ikke kan gengive scoren i dag af den model, du satte i produktion for tre måneder siden, kontrollerer du ikke rigtig den model. I denne afsluttende enhed uddyber vi reproducerbarheden: evnen til pålideligt at opnå det samme resultat med de samme input og kombinere hele modulet i en end-to-end projektdisciplin.

Hvorfor reproducerbarhed er vanskelig

I almindelig software giver den samme kode det samme output. I ML er der mange flere variabler, der bestemmer resultatet:

• Tilfældighed: Blanding af data, initialisering af vægt, dataopdeling - alt sammen afhænger af tilfældighed.
• Data: Samme kode producerer forskellige modeller med forskellige dataversioner.
• Miljø: Biblioteksversioner, hardware (CPU/GPU), selv operativsystem kan ændre resultatet.
• Skjult sag: En ikke-gemt hyperparameter, et manuel forbehandlingstrin, en unoteret markering.

Reproducerbarhed er ikke et "rart at have", men et videnskabeligt og teknisk imperativ. Et resultat, der ikke kan reproduceres, er en påstand, der ikke kan bevises.

Fire søjler af reproducerbarhed

1. Ret tilfældigheder. Sæt alle tilfældige frø ét sted: dataopdeling, modelinitialisering, datablanding. Fast frø er grundlaget for "samme resultat, når du gentager samme kørsel" garanti.

2. Versionér dataene. Registrer hvilken dataversion hvert eksperiment blev udført med (dataversionering i enhed 2). "Seneste data" er vage; "dataversion v3, hash abc123" er nøjagtig.

3. Frys mediet. Fastgør alle afhængigheder til deres nøjagtige versioner (f.eks. nøjagtige versioner som numpy==1.26.4 i requirements.txt eller et containerbillede). Den "nyeste version" vil ødelægge alt en dag.

4. Spor alt (eksperimentsporing). Gem automatisk for hvert eksperiment: kodeversion (git commit), dataversion, alle hyperparametre, metrikker og outputstrukturer. Eksperimenter med sporingsværktøjer som MLflow, Weights & Biases gør dette systematisk. Uden registrering forbliver spørgsmålet "hvilken indstilling var bedst" ​​ubesvaret.

Advarsel: "Jeg husker senere" er den dyreste fejlslutning. To uger senere vil du ikke huske hvilket frø, hvilke data, hvilke hyperparameter du brugte. Automatisk sporing eliminerer afhængighed af hukommelse.

Svag tilgang / Stærk tilgang

Svag: "Jeg fandt den bedste model, den er på notesbogen, jeg tror dens score var 89 %."

Stærk: "Kør #147 i eksperimentsporingsværktøjet: git commit a3f9c, dataversion v3 (hash abc123), seed 42, alle hyperparametre registreret, test PR-AUC 0.887. Når jeg kører den samme kommando igen, får jeg det samme resultat bit for bit. Modellen afhænger af denne kørsel i registreringsdatabasen."

Forskellen: i den stærke tilgang er resultatet ikke baseret på en hukommelse, men på en fast og overvåget kæde. Alle kan producere det samme resultat hver gang.

End-to-end projekt: kombination af modul

Lad os nu kombinere hele modulet i et enkelt projektflow. Et rigtigt ML-system går gennem disse stop, og hvert stop bygger på det forrige:

1. Problemdefinition: Hvad løser vi, hvordan måler vi succes (enhed 3: rigtig metrik, forretningskontekst). Metrikken og tærsklen er klar fra starten.
2. Datapipeline: Indsamling, validering, rensning, lækagefri opdeling, versionering (enhed 2).
3. Modeludvikling: Træning, basislinjesammenligning, krydsvalidering, hårdt frø (enhed 3 + denne enhed).
4. LLM-komponenter (hvis relevant): RAG (enhed 4) og/eller midler (enhed 5); finjustering om nødvendigt (enhed 6).
5. Evaluering: eval cluster med kant- og sikkerhedsetuier, flerlags eval i LLM-systemer (enhed 8).
6. Revision af retfærdighed og etik: Undergruppeanalyse, modelkort, forklarlighed (enhed 10).
7. Sikkerhedsrevision: Hurtig indsprøjtning, privatliv, forsyningskæde (enhed 9).
8. Distribution: Pakning, gradvis distribution, rollback, modelregistrering (enhed 7).
9. Overvågning: Tre-lags overvågning, driftalarmer (enhed 8).
10. Reproducerbarhed: Seed, dataversion, media og eksperimentsporing gennem hele kæden (denne enhed).

I dette flow er AI en accelerator og blueprint-generator ved hvert stop; men metrisk udvælgelse, databeslutninger, retfærdighedsprioritering, implementeringstærskel og frigivelsesgodkendelse - kritiske beslutninger forbliver hos mennesket. Dette er essensen af ​​modulet.

Dokumentation: fremtiden vil takke dig

Et godt ML-projekt dokumenterer sig selv. Som minimum skal følgende skrives: problem- og succeskriterier, datakilde og version, modelvalg og begrundelser, evalueringsresultater (inklusive undergrupper), kendte grænser og risici, implementerings- og genfindingsprocedure, overvågningsplan. Dette dokument er den bedste ven for den person (måske er det dig), der vender tilbage til projektet efter seks måneder.

tre minisager

Case 1 - Tabt resultat. En ingeniør trænede en fantastisk model, men han fiksede ikke frøet og gemte ikke dataversionen. Da han forlod jobbet, kunne ingen gengive det resultat; modellen blev en "black box legend" og blev til sidst bygget fra bunden. Uger var spildt. Lektion: et ikke-reproducerbart resultat er et ikke-eksisterende resultat.

Case 2 - Miljøsammenbrud. Et hold havde ikke rettet afhængighederne. Når et bibliotek blev opdateret automatisk, ændredes modeloutput lydløst, og produktionen blev afbrudt. Det tog dage at finde problemet. Da afhængighederne blev frosset og containeriseret med de endelige versioner, opstod problemet ikke igen. Lektion: fryse miljøet.

Case 3 - Styrken ved overvågning. Et hold overvågede automatisk hvert eksperiment. Tre måneder senere, under en regulatorisk revision, besvarede de spørgsmålet "med hvilke data, med hvilke indstillinger, hvilken ydeevne fik det i hvilke grupper?" med en fuld optagelse inden for få minutter. Eftersynet gik glat. Lektion: overvågning er et overholdelsesværktøj, ikke kun et teknisk.

Kopierbare skabeloner

Foretag et reproducerbarhedstjek for dette ML-projekt.- Er alle tilfældighedsfrø fastsatte (split, initialiser, shuffle)?- Er data versionsbestemt?- Er afhængigheder frosset til nøjagtige versioner?- Bliver hvert eksperiment (kodeforpligtelse, data, hyperparameter, metrisk) sporet? Skriv konkrete trin til, hvordan du løser det for hver manglende kolonne. Projektstruktur: [beskrivelse]

Lav et planskelet for dette ende-til-ende ML-projekt. Problem: [beskrivelse] Dæk følgende stop og markér, hvor den MENNESKEDE beslutning er ved hvert stop: problem/metrik, pipeline, model, (RAG/agent/finjustering?), eval, retfærdighed, sikkerhed, distribution, overvågning, reproducerbarhed. Skriv hovedrisiko- og verifikationstrinnet for hvert stop.

Lav en teknisk dokumentationsskabelon til dette projekt. Sektioner: problem+succeskriterier, data (kilde+version), modelvalg+begrundelse, evaluering (inklusive undergrupper), kendte grænser+risici, implementering+rollback, overvågningsplan. Angiv de felter, der skal udfyldes for hvert afsnit, som spørgsmål.

Tjek mit eksperimentovervågningsopsætning: Gemmes det automatisk ved hver kørsel: git commit, dataversion/hash, alle hyperparametre, alle metrics, miljø (biblioteksversioner)? Får jeg det samme resultat, når jeg løber det samme løb igen? Opsætning: [beskrivelse]. Liste over fejl og rettelser.

Tabel med kolonner med reproducerbarhed

kolonne

Hvad er fast

Eksempel på køretøj

tilfældighed

alle frø

frøindstilling

Data

Dataversion/hash

DVC

miljø

Biblioteksversioner

krav pin, Docker

Overvågning

Kode+data+indstilling+metrik

MLflow, W&B

Almindelige fejl

• Fixer ikke frøet. Resultatet kan ikke gentages.
• Dataversionen gemmes ikke. "Med hvilke data?" forbliver ubesvaret.
• Ikke fryseafhængighed. En opdatering vil lydløst bryde alt.
• Overlader eksperimenter til hukommelsen. To uger senere huskes intet.
• Overlader kritiske beslutninger til kunstig intelligens. Målinger, retfærdighed og distributionsbeslutninger bør forblive hos folk.
• Udsættelse af dokumentation. Det fremtidige hold (og du) betaler prisen.

Sammenfattende

Reproducerbarhed er signaturen på seriøs ML-teknik: det ikke-reproducerbare resultat er den ubeviselige påstand. Den kommer med fire kolonner - ret tilfældighed, versionsdata, frys miljø, spor hvert eksperiment. Et ende-til-ende-projekt kombinerer alle stop i dette modul (metrik, data, model, LLM-komponenter, eval, fairness, sikkerhed, distribution, overvågning) i en sammenkoblet kæde; Kunstig intelligens er en accelerator ved hvert stop, men kritiske beslutninger forbliver hos mennesket. Dokumenter alt - til fremtidige team og revisioner. Denne disciplin er den ramme, der understøtter alt, hvad du lærer gennem hele modulet.

Ansøgningsopgave

Tjek et ML-projekt i forhold til fire reproducerbarhedssøjler: er frøene uforanderlige, er dataene versionerede, er miljøet frosset, spores eksperimenterne? Ret eventuelle manglende kolonner og bevis, at du kan køre det samme løb to gange og få det samme resultat. Udskriv derefter projektets ende-til-ende-flow (10 stop) på én side og marker "hvor den menneskelige beslutning er" ved hvert stop. Skriv til sidst et kort teknisk dokumentationsudkast.

tjekliste

• [ ] Alle tilfældighedsfrø fikseret.
• [ ] Dataversion/hash registreres med hvert eksperiment.
• [ ] Afhængigheder er frosset til faste versioner (stift/beholder).
• [ ] Hvert eksperiment overvåges automatisk (kode+data+indstilling+metrik).
• [ ] Når jeg gentager det samme løb, får jeg det samme resultat.
• [ ] Jeg verificerede og dokumenterede, at kritiske beslutninger i ende-til-ende-flowet træffes af mennesker.

Modul eksamen

1. Som ML-ingeniør, hvad er den bedste tilgang til at placere kunstig intelligens i arbejdsgangen?

• A) AI er en accelerator i lavrisikovirksomheder; Kritiske beslutninger som metrik, data og produktion forbliver valideret og overladt til mennesket ✔
• B) Så længe AI-udgangene ser gode ud, er der ikke behov for verifikation
• C) At overlade beslutningen om at sætte modellen i produktion til kunstig intelligens sparer tid.
• D) Kunstig intelligens er kun nyttig til at skrive tekst, det har intet med data og modelarbejde at gøre

Beskrivelse: AI er en kraftfuld accelerator til lavrisiko, let verificerede opgaver såsom kode, datasammendrag og dokumenter; Ansvaret for beslutninger, der påvirker penge, fortrolighed og juridisk ansvar, såsom metrisk udvælgelse, hvilke data der går til træning og sætte modellen i produktion, ligger hos den kvalificerede ingeniør og team. Hvert output bør ikke bruges uden verifikation.

2. Hvorfor placeres skemavalidering i begyndelsen af ​​en datapipeline?

• A) Fordi det direkte øger modellens nøjagtighed
• B) Fordi det gør dataversionering unødvendig
• C) Fordi den fanger korrupte data på det tidligste og billigste sted og forhindrer dem i at lække ind i de næste trin ✔
• D) Fordi det eliminerer behovet for mærkning

Forklaring: Jo tidligere korrupte data fanges, jo billigere er det at rette dem. Skemavalidering forhindrer korrupte data i at lække ind i træning eller produktion ved at afvise data uden for den forventede type og rækkevidde i begyndelsen af ​​linjen (f.eks. prisskift 100x med enhedsændring); Den samme fejl fanget i produktionen er mange gange dyrere.

3. Hvad er den korrekte tilgang, når man deler data op i træning og test i et problem, der involverer tid (tidsserier)?

• A) Brug af tilfældig opdeling, fordi det altid er den mest retfærdige metode
• B) Brug af tidsmæssig opdeling: forhindre lækage ved at træne med fortiden og teste i fremtiden ✔
• C) Brug af alle data som både træning og test
• D) Inkorporering af testdata i skaleringsparametre før træning

Forklaring: Tilfældig opdeling på tidsserier giver modellen en 'fremtidsseende' fordel, som aldrig vil ske i produktionen, og kunstigt oppuster metrikken (temporal lækage). Den korrekte er tidsmæssig opdeling: Træn med fortiden, test i fremtiden. Dette måler den faktiske ydeevne, der holder den i produktion.

4. Hvorfor er nøjagtigheden vildledende i en svigopdagelsesmodel med en positiv klasserate på 1,5 %?

• A) Fordi nøjagtigheden altid er lav på ubalancerede data
• B) Fordi Nøjagtighed kun kan bruges på regressionsproblemer
• C) Fordi nøjagtighedsberegning kræver meget processorkraft
• D) Selv en sølle model, der forudsiger majoritetsklassen, kan være meget nøjagtig, og dermed skjule reel succes ✔

Forklaring: På ubalancerede data får selv en grundlæggende model, der siger "kald alt negativt", omkring 98,5 % nøjagtighed, men vil ikke fange en eneste svig. I ubalanceret klassificering anvendes derfor præcision, tilbagekaldelse, F1 eller PR-AUC i stedet for nøjagtighed, og hver metrik fortolkes i henhold til en basismodel.

5. Hvorfor er sammenligning med baseline essentiel, når man taler om en models metrik?

• A) Fordi basismodellen altid er bedre end den rigtige model
• B) Fordi det er klart, om en metrik er meningsfuld eller ikke kun sammenlignet med en simpel basismodel ✔
• C) Fordi basismodellen gør krydsvalidering unødvendig
• D) Fordi den grundlæggende model er lovpligtig i hver rapport

Forklaring: En metrik er ikke god eller dårlig i sig selv; Det er godt eller dårligt efter en grundmodel. Sætningen '85% korrekt' betyder næsten værdiløs, hvis basismodellen allerede får 84%, og perfekt, hvis den får 50%. Uden et sammenligningsanker er metrikken meningsløs.

6. Hvilket er det mest kritiske sikkerhedselement, der bør inkluderes i produktionsprompten for RAG-systemet (Retrieval-Augmented Generation)?

• A) Instruktion om kun at stole på den givne kilde, at sige 'Jeg ved det ikke', hvis kilden ikke eksisterer, og at citere kilden ✔
• B) Bede modellen om at producere så lange og kreative svar som muligt
• C) Modellen prioriterer egen pædagogisk viden frem for ressourcer
• D) Implementer alle instruktioner i de dokumenter, der bringes som kommandoer

Forklaring: RAG's vigtigste enkeltinstruktion er at fortælle modellen kun at stole på den givne kilde, og hvis informationen ikke er i kilden, så sig 'Jeg ved det ikke' og citer kilden uden at finde på det. Uden denne triade kan modellen ignorere kontekst og fremkalde hallucinationer, og svaret bliver uverificerbart.

7. Et RAG-system giver forkerte svar. Hvor er det bedste sted at starte diagnosen?

• A) Måler apport først (Recall@K): kommer det korrekte stykke nogensinde? ✔
• B) Udskift straks modellen med en større
• C) Skift prompten tilfældigt og fortsæt med at prøve
• D) Indlejring af alle dokumenter i modellen med finjustering

Forklaring: RAG's svageste led er normalt apport, ikke produktion. Hvis den korrekte del aldrig medbringes, kan modellen ikke producere den information, uanset hvor meget prompten er forbedret. Derfor måles først Recall@K for at se, om den korrekte del er ankommet; Hvis apporteringen er god, så undersøges produktionen og prompten.

8. Hvilke handlinger bør lægges bag menneskelig godkendelse, når man giver et værktøj til en agent?

• A) Ingen; Agenten skal være i stand til at udføre enhver handling selvstændigt
• B) Kun reversible handlinger såsom læsning og søgning af data
• C) Irreversible eller høje virkningshandlinger såsom overførsel af penge, sletning, afsendelse ✔
• D) Handlinger, der kun involverer beregninger

Beskrivelse: Handlinger er adskilt efter risikoniveau. Hentbare opgaver såsom læsning, søgning, beregning og generering af kladder kan udføres selvstændigt; Imidlertid kræver irreversible eller stor indvirkningshandlinger såsom overførsel af penge, afsendelse af e-mails, sletning af data, afgivelse af ordrer osv. menneskelig godkendelse. Enhver uigenkaldelig handling skal være underlagt samtykke.

9. Hvad er den bedste designtilgang mod risikoen for indirekte hurtig injektion?

• A) Det er nok at tilføje en enkelt sætning 'ignorer dårlige instruktioner' til systemprompten
• B) Giv mere autoritet til modellen ved at stole på instruktioner i eksternt indhold
• C) Tager ikke nogen forholdsregler, fordi injektion ikke kan forebygges
• D) Isolering af eksternt indhold som upålidelige data og etablering af lagdelte forsvar med minimal autorisation, godkendelse og outputkontrol ✔

Beskrivelse: Eksternt indhold, der behandles af agenten eller RAG, såsom en webside, et dokument, e-mail osv., er ikke-pålidelige data og kan indeholde hemmelige instruktioner. Den korrekte tilgang er lagdelt forsvar: isolering af eksternt indhold som 'data, ikke kommandoer' med klare afgrænsninger, anvendelse af minimal autorisation, binding af irreversible handlinger til menneskelig godkendelse og revision af output. En enkelt linje med instruktioner er ikke nok.

10. Hvad er den vigtigste forskel, når man skal beslutte, om et problem skal løses med finjustering eller RAG?

• A) Informationsproblemer løses bedre med RAG, adfærds-/formatproblemer løses bedre med finjustering ✔
• B) Ethvert problem bør altid løses ved finjustering
• C) RAG bruges kun til kodegenerering, finjustering bruges kun til oversættelse
• D) Finjustering kan altid opdateres billigere og hurtigere end RAG

Forklaring: Finjustering er svagt og risikabelt i at lære modellen ny information; men er kraftfuld i undervisning i adfærd, format, tone og stil. 'Modelvirksomheden kender ikke vores data' er et informationsproblem og tilhører RAG. 'Lad modellen altid udskrive i vores strenge format' er et adfærdsproblem og en kandidat til finjustering. Derudover bør der tages hurtige og få skud før finjustering.

11. Hvad er obligatorisk for sikker implementering, når en ny model sættes i produktion?

• A) Hvis modellen er god til at teste, skal du åbne den direkte for 100 % trafik
• B) Slet ikke opsætning af overvågning efter indsættelse
• C) Fasevis udrulning (skygge/kanariefugl) og en forudtestet tilbagerulningsplan ✔
• D) Offentliggørelse af modellen, selvom evalueringstærsklen ikke er overholdt

Forklaring: Det er risikabelt at åbne den nye model direkte for al trafik; Hvis det er forkert, er alle berørt. Det korrekte er, at det er en gradvis distribution (skygge, kanariefugle), og hver distribution har en testet tilbagerulningsplan. En distribution er ikke komplet uden en clawback-plan; At kunne vende tilbage til den tidligere version inden for få minutter beskytter brugeren, når modellen opfører sig uventet i produktionen.

12. Hvordan kan en ML-model fejle 'stille' i produktionen, og hvordan kan man fange dette?

• A) Modellen kollapser; serverlogs viser dette
• B) Ved at producere forkerte forudsigelser uden at lave fejl; ✔ Det fanger operationel, input og output lagdelt overvågning
• C) Model kan aldrig fejle lydløst, altid alarm
• D) Bare overvågning af latens er nok til at fange enhver forringelse

Forklaring: Modellen kan fejle blot ved at producere forkerte forudsigelser uden at crashe eller give fejl; Hovedårsagen til dette er datadrift og konceptdrift. Bare overvågning af operationelle målinger (latens, fejlrate) er ikke nok; input distribution og output/forudsigelsesfordeling bør også overvåges. Inputdrift giver tidlig advarsel, hvis det faktiske resultat er forsinket.

13. Hvilket princip er vigtigt, når man bruger LLM-som-dommer til at evaluere et LLM-system?

• A) LLM-dommeren er altid korrekt, menneskelig verifikation er unødvendig
• B) Dommeren skal træffe en beslutning baseret på svarlængde.
• C) Regelbaserede kontroller og menneskelig evaluering bør kasseres fuldstændigt, når der bruges dommere
• D) Dommerresultater skal kalibreres med en menneskemærket prøve og deres skævhed måles, før de kan stoles på ✔

Beskrivelse: LLM-dommeren er også model; Det kan være hallucinatorisk, forudindtaget (begunstiger lange, sikre svar) og inkonsekvente. Derfor skal dommerscores kalibreres med en menneskemærket prøve, og deres systematiske skævhed skal måles, før produktionsbeslutningen træffes. En ubekræftet dommer giver falsk selvtillid.

14. Hvorfor er det utilstrækkeligt at se på den overordnede nøjagtighed, når man vurderer modelbias?

• A) Samlet nøjagtighed er tilstrækkelig, fordi den altid afspejler ydeevnen for den dårligste gruppe
• B) Samlet nøjagtighed alene er utilstrækkelig, da det kan skjule systematisk forskel (skjult diskrimination) mellem undergrupper ✔
• C) Fordi nøjagtighed er en metrik, der ikke har noget at gøre med bias
• D) Bias kommer kun fra modellen og har intet at gøre med dataene.

Forklaring: Samlet nøjagtighed kan skjule systematiske forskelle mellem undergrupper. For eksempel, mens den samlede nøjagtighed er 88 %, kan tilbagekaldelse være 91 % i én gruppe og 67 % i en anden gruppe; Modellen savner systematisk den gruppe. Derfor bør modellen evalueres på baggrund af undergrupper (demografi/segment), og hvilken definition af retfærdighed der skal prioriteres bør besluttes med interessenter.

15. Hvilke fire ting skal sættes sammen for at et ML-resultat kan reproduceres?

• A) Kun modelnavn, størrelse, pris og udgivelsesdato
• B) Kun GPU-mærke og internethastighed
• C) Kun modellens endelige nøjagtighedsscore; resten kan gemmes i hukommelsen
• D) Tilfældighedsfrø, dataversion, miljø (afhængighedsversioner) og eksperimentsporing ✔

Beskrivelse: Reproducerbarhed opnås gennem fire søjler: fiksering af tilfældighedsfrø, versionering af data (version/hash), frysning af miljøet (nøjagtige biblioteksversioner/beholder) og sporing af hvert eksperiment (kodeforpligtelse, data, hyperparameter, metrisk). Uden denne kæde er det ikke muligt at gengive det samme resultat; Et ikke-reproducerbart resultat er en påstand, der ikke kan bevises.