Reproducerbarhet och End-to-End-projektet: Kombinera allt

Vinster:

• Förmåga att säkerställa reproducerbarhet med fyra pelare (fröfixering, dataversionering, mediafrysning, experimentövervakning) och producera samma resultat när samma körning upprepas
• Möjlighet att kombinera alla stopp i modulen (mått, data, modell, LLM-komponenter, eval, rättvisa, säkerhet, distribution, övervakning) i en kedja från slut till slut
• Förmåga att verifiera att det kritiska beslutet ligger kvar hos människan vid varje stopp och dokumentera projektet på ett auditerbart sätt

Det mest lömska misslyckandet i ett ML-projekt är inte en krasch; "Får inte samma resultat igen." Om du inte kan återskapa poängen idag för modellen du satte i produktion för tre månader sedan, så kontrollerar du inte riktigt den modellen. I denna avslutande enhet fördjupar vi reproducerbarheten: förmågan att på ett tillförlitligt sätt få samma resultat med samma indata och kombinera hela modulen i en projektdisciplin från slut till slut.

Varför reproducerbarhet är svårt

I vanlig programvara ger samma kod samma utdata. I ML finns det många fler variabler som avgör resultatet:

• Slumpmässighet: Blandning av data, viktinitiering, datadelning – allt förlitar sig på slumpmässighet.
• Data: Samma kod producerar olika modeller med olika dataversioner.
• Miljö: Biblioteksversioner, hårdvara (CPU/GPU), till och med operativsystem kan ändra resultatet.
• Dolt fall: En osparad hyperparameter, ett manuellt förbearbetningssteg, ett onoterat urval.

Reproducerbarhet är inte ett "trevligt att ha" utan ett vetenskapligt och tekniskt imperativ. Ett resultat som inte går att reproducera är ett påstående som inte kan bevisas.

Fyra pelare för reproducerbarhet

1. Fixa slumpmässighet. Sätt alla slumpmässiga frön på ett ställe: datadelning, modellinitiering, datablandning. Fixed seed är grunden för "samma resultat när du upprepar samma körning"-garanti.

2. Verifiera data. Anteckna vilken dataversion varje experiment utfördes med (dataversionering i enhet 2). "Senaste data" är vag; "dataversion v3, hash abc123" är exakt.

3. Frys in mediet. Fäst alla beroenden till deras exakta versioner (t.ex. exakta versioner som numpy==1.26.4 i requirements.txt eller en containerbild). Den "senaste versionen" kommer att bryta allt en dag.

4. Spåra allt (experimentspårning). Spara automatiskt för varje experiment: kodversion (git commit), dataversion, alla hyperparametrar, mätvärden och utdatastrukturer. Experimentspårningsverktyg som MLflow, Weights & Biases gör detta systematiskt. Utan registrering förblir frågan "vilken inställning var bäst" obesvarad.

Varning: "Jag kommer ihåg senare" är den dyraste villfarelsen. Två veckor senare kommer du inte ihåg vilket frö, vilken data, vilken hyperparameter du använde. Automatisk spårning eliminerar beroendet av minne.

Svagt förhållningssätt / Starkt förhållningssätt

Svag: "Jag hittade den bästa modellen, den finns på den bärbara datorn, jag tror att dess poäng var 89 %."

Stark: "Kör #147 i experimentspårningsverktyget: git commit a3f9c, dataversion v3 (hash abc123), seed 42, alla hyperparametrar registrerade, testa PR-AUC 0.887. När jag kör samma kommando igen får jag samma resultat bit för bit. Modellen beror på denna körning i registret."

Skillnaden: i det starka tillvägagångssättet är resultatet inte baserat på ett minne, utan på en fast och övervakad kedja. Alla kan producera samma resultat varje gång.

End-to-end-projekt: kombination av modul

Låt oss nu kombinera hela modulen till ett enda projektflöde. Ett riktigt ML-system går igenom dessa stopp, och varje stopp bygger på det föregående:

1. Problemdefinition: Vad löser vi, hur man mäter framgång (enhet 3: rätt mått, affärssammanhang). Måttet och tröskeln är tydliga från början.
2. Datapipeline: Insamling, validering, rengöring, läckagefri partitionering, versionshantering (enhet 2).
3. Modellutveckling: Utbildning, baslinjejämförelse, korsvalidering, hårt frö (enhet 3 + denna enhet).
4. LLM-komponenter (om tillämpligt): RAG (enhet 4) och/eller medel (enhet 5); finjustering vid behov (enhet 6).
5. Utvärdering: evalkluster med kant- och säkerhetsfodral, flerskiktsutvärdering i LLM-system (enhet 8).
6. Rättvise- och etikrevision: Undergruppsanalys, modellkort, förklarabarhet (enhet 10).
7. Säkerhetsrevision: Snabb injektion, integritet, leveranskedja (enhet 9).
8. Distribution: Förpackning, gradvis distribution, återställning, modellregister (enhet 7).
9. Övervakning: Treskiktsövervakning, driftlarm (enhet 8).
10. Reproducerbarhet: Seed, dataversion, media och experiment tracking genom hela kedjan (denna enhet).

I detta flöde är AI en accelerator och ritningsgenerator vid varje stopp; men val av mätvärden, databeslut, rättvisa prioritering, driftsättningströskel och godkännande av release – kritiska beslut kvarstår hos människan. Detta är kärnan i modulen.

Dokumentation: framtiden kommer att tacka dig

Ett bra ML-projekt dokumenterar sig själv. Åtminstone bör följande skrivas: problem- och framgångskriterier, datakälla och version, modellval och motiveringar, utvärderingsresultat (inklusive undergrupper), kända gränser och risker, införande och hämtningsprocedur, övervakningsplan. Detta dokument är den bästa vän till personen (kanske är det du) som återvänder till projektet efter sex månader.

tre minifodral

Fall 1 - Förlorat resultat. En ingenjör utbildade en fantastisk modell, men han fixade inte fröet och sparade inte dataversionen. När han lämnade jobbet kunde ingen återskapa det resultatet; modellen blev en "black box legend" och byggdes så småningom från grunden. Veckor var bortkastade. Lektion: ett icke-reproducerbart resultat är ett icke-existerande resultat.

Fall 2 - Miljökollaps. Ett team hade inte fixat beroenden. När ett bibliotek uppdaterades automatiskt ändrades modellutgångarna tyst och produktionen avbröts. Det tog dagar att hitta problemet. När beroenden frystes och containeriserades med de definitiva versionerna, uppstod inte problemet igen. Lektion: frys miljön.

Fall 3 - Kraften i övervakning. Ett team övervakade automatiskt varje experiment. Tre månader senare, under en regulatorisk revision, svarade de på frågan "med vilken data, med vilka inställningar, vilken prestation fick den i vilka grupper?" med en fullständig inspelning inom några minuter. Besiktningen gick smidigt. Lektion: övervakning är ett efterlevnadsverktyg, inte bara ett tekniskt.

Kopierbara mallar

Gör en reproducerbarhetskontroll för detta ML-projekt.- Är alla slumpmässiga frön fixerade (dela, initiera, blanda)?- Är data versionerade?- Är beroenden frysta till exakta versioner?- Spåras varje experiment (kod commit, data, hyperparameter, metrisk)? Skriv konkreta steg om hur du fixar det för varje saknad kolumn. Projektstruktur: [beskrivning]

Ta fram ett planskelett för detta ML-projekt. Problem: [beskrivning] Täck över följande stopp och markera var det MÄNNISKA beslutet är vid varje stopp: problem/mått, pipeline, modell, (RAG/agent/finjustering?), eval, rättvisa, säkerhet, distribution, övervakning, reproducerbarhet. Skriv huvudrisken och verifieringssteget för varje stopp.

Ta fram en teknisk dokumentationsmall för detta projekt. Avsnitt: problem+framgångskriterier, data (källa+version), modellval+motivering, utvärdering (inklusive undergrupper), kända gränser+risker, utplacering+återställning, övervakningsplan. Ange fälten som ska fyllas i för varje avsnitt som frågor.

Kontrollera min inställningar för experimentövervakning: Sparas den automatiskt vid varje körning: git commit, dataversion/hash, alla hyperparametrar, alla mätvärden, miljö (biblioteksversioner)? Får jag samma resultat när jag kör samma löpning igen? Inställning: [beskrivning]. Lista bristerna och korrigering.

Tabell för reproducerbarhetskolumner

kolumn

Vad är fixat

Exempel på fordon

slumpmässighet

alla frön

fröinställning

Data

Dataversion/hash

DVC

miljö

Biblioteksversioner

kravstift, Docker

Övervakning

Kod+data+inställning+mått

MLflow, W&B

Vanliga misstag

• Fixar inte fröet. Resultatet kan inte upprepas.
• Sparar inte dataversionen. "Med vilken data?" förblir obesvarat.
• Inte frysmissbruk. En uppdatering kommer tyst att bryta allt.
• Lämnar experiment till minnet. Två veckor senare minns ingenting.
• Överlåter kritiska beslut till artificiell intelligens. Beslut om mätningar, rättvisa och distribution bör förbli hos människor.
• Att skjuta upp dokumentation. Det framtida laget (och du) betalar priset.

Sammanfattningsvis

Reproducerbarhet är signaturen för seriös ML-teknik: det icke-reproducerbara resultatet är det obevisbara påståendet. Den kommer med fyra kolumner - fixa slumpmässighet, versionsdata, frys miljö, spåra varje experiment. Ett projekt från slut till slut kombinerar alla hållpunkter för denna modul (mått, data, modell, LLM-komponenter, eval, rättvisa, säkerhet, distribution, övervakning) i en sammankopplad kedja; Artificiell intelligens är en accelerator vid varje stopp, men avgörande beslut kvarstår hos människan. Dokumentera allt — för framtida team och revisioner. Denna disciplin är ramverket som upprätthåller allt du lär dig under hela modulen.

Applikationsuppgift

Kontrollera ett ML-projekt mot fyra reproducerbarhetspelare: är fröna oföränderliga, är dataversionerade, är miljön frusen, spåras experimenten? Åtgärda eventuella saknade kolumner och bevisa att du kan köra samma körning två gånger och få samma resultat. Mata sedan ut hela projektets flöde (10 stopp) på en sida och markera "var det mänskliga beslutet är" vid varje stopp. Skriv till sist ett kort utkast till teknisk dokumentation.

checklista

• [ ] Alla slumpmässiga frön fixerade.
• [ ] Dataversion/hash registreras med varje experiment.
• [ ] Beroenden är frysta till fasta versioner (stift/behållare).
• [ ] Varje experiment övervakas automatiskt (kod+data+inställning+mått).
• [ ] När jag upprepar samma körning får jag samma resultat.
• [ ] Jag verifierade och dokumenterade att kritiska beslut i flödet från början till slut fattas av människor.

Modulexamen

1. Som ML-ingenjör, vilket är det bästa sättet att placera artificiell intelligens i arbetsflödet?

• A) AI är en accelerator i lågriskföretag; Kritiska beslut som mätvärden, data och produktion förblir validerade och lämnas åt människan ✔
• B) Så länge AI-utgångarna ser bra ut finns det inget behov av verifiering
• C) Att överlåta beslutet att sätta modellen i produktion till artificiell intelligens sparar tid.
• D) Artificiell intelligens är bara användbar för att skriva text, det har inget med data och modellarbete att göra

Beskrivning: AI är en kraftfull accelerator för lågrisk, lätt verifierade uppgifter som kod, datasammandrag och dokument; Ansvaret för beslut som påverkar pengar, konfidentialitet och juridiskt ansvar, såsom val av mått, vilken data som går till utbildning och sätter modellen i produktion, ligger dock hos den kvalificerade ingenjören och teamet. Varje utgång ska inte användas utan verifiering.

2. Varför placeras schemavalidering i början av en datapipeline?

• A) Eftersom det direkt ökar modellens noggrannhet
• B) Eftersom det gör dataversionering onödig
• C) Eftersom den fångar upp skadad data vid den tidigaste och billigaste punkten och förhindrar att den läcker in i nästa steg ✔
• D) Eftersom det eliminerar behovet av märkning

Förklaring: Ju tidigare korrupta data fångas upp, desto billigare är det att fixa det. Schemavalidering förhindrar korrupta data från att tyst läcka in i utbildning eller produktion genom att avvisa data utanför den förväntade typen och intervallet i början av raden (t.ex. prisförskjutning 100x med enhetsbyte); Samma fel som fångas i produktionen är många gånger dyrare.

3. Vad är det korrekta tillvägagångssättet när man delar upp data i träning och testning i ett problem som involverar tid (tidsserier)?

• A) Använder slumpmässig delning eftersom det alltid är den rättvisaste metoden
• B) Använd temporal splitting: förhindra läckage genom att träna med det förflutna och testa i framtiden ✔
• C) Använda all data som både träning och testning
• D) Att införliva testdata i skalningsparametrar före träning

Förklaring: Slumpmässig uppdelning av tidsserier ger modellen en "framtidsseende" fördel som aldrig kommer att hända i produktionen och på konstgjord väg blåser upp måtten (temporärt läckage). Den korrekta är tidsdelning: träna med det förflutna, testa i framtiden. Detta mäter den faktiska prestandan som håller den i produktion.

4. Varför är noggrannheten vilseledande i en bedrägeriupptäcktsmodell med en positiv klassgrad på 1,5 %?

• A) Eftersom noggrannheten alltid är låg på obalanserad data
• B) Eftersom noggrannhet endast kan användas på regressionsproblem
• C) Eftersom noggrannhetsberäkning kräver mycket processorkraft
• D) Även en ynklig modell som förutsäger majoritetsklassen kan vara mycket exakt och på så sätt dölja verklig framgång ✔

Förklaring: På obalanserad data får även en grundmodell som säger "ringa allt negativt" ungefär 98,5 % noggrannhet men kommer inte att fånga ett enda bedrägeri. I obalanserad klassificering används därför precision, återkallelse, F1 eller PR-AUC istället för noggrannhet, och varje måttenhet tolkas enligt en basmodell.

5. Varför är baslinjejämförelse viktigt när man talar om en modells mått?

• A) För att basmodellen alltid är bättre än den riktiga modellen
• B) Eftersom det är tydligt om ett mått är meningsfullt eller inte bara jämfört med en enkel baslinjemodell ✔
• C) Eftersom basmodellen gör korsvalidering onödig
• D) Eftersom grundmodellen är lagstadgad i varje rapport

Förklaring: Ett mått är inte bra eller dåligt i sig; Det är bra eller dåligt enligt en grundmodell. Meningen '85% korrekt' betyder nästan värdelös om basmodellen redan får 84%, och perfekt om den får 50%. Utan ett jämförelseankare är måttet meningslöst.

6. Vilket är det mest kritiska säkerhetselementet som bör inkluderas i produktionsprompten för RAG-systemet (Retrieval-Augmented Generation)?

• A) Instruktion att endast förlita sig på den angivna källan, att säga "jag vet inte" om källan inte finns, och att citera källan ✔
• B) Att säga till modellen att producera så långa och kreativa svar som möjligt
• C) Modellen prioriterar sin egen utbildningskunskap framför resurser
• D) Implementera alla instruktioner i de dokument som tas med som kommandon

Förklaring: Den enskilt viktigaste instruktionen för RAG är att tala om för modellen att endast förlita sig på den angivna källan, och om informationen inte finns i källan, säg "Jag vet inte" och citera källan utan att hitta på det. Utan denna triad kan modellen ignorera sammanhang och framkalla hallucinationer, och svaret blir omöjligt att verifiera.

7. Ett RAG-system ger felaktiga svar. Var är det bästa stället att börja diagnostisera?

• A) Mätning av apport först (Recall@K): kommer den korrekta biten någonsin fram? ✔
• B) Byt omedelbart ut modellen mot en större
• C) Ändra prompten slumpmässigt och fortsätt att försöka
• D) Bädda in alla dokument i modellen med finjustering

Förklaring: RAG:s svagaste länk är vanligtvis apport, inte produktion. Om den korrekta delen aldrig tas med kan modellen inte producera den informationen, oavsett hur mycket uppmaningen förbättras. Därför mäts först Recall@K för att se om rätt del har kommit; Om apporten är bra undersöks produktionen och uppmaningen.

8. Vilka åtgärder bör läggas bakom mänskligt godkännande när man ger ett verktyg till en agent?

• A) Inga; Agenten måste kunna utföra varje åtgärd självständigt
• B) Endast reversibla åtgärder som läsning och sökning av data
• C) Oåterkalleliga eller stor påverkande åtgärder som att överföra pengar, ta bort, skicka ✔
• D) Åtgärder som endast innebär beräkningar

Beskrivning: Åtgärder separeras efter risknivå. Återtagbara uppgifter som att läsa, söka, beräkna och generera utkast kan utföras autonomt; Men oåterkalleliga eller kraftiga handlingar som att överföra pengar, skicka e-post, radera data, lägga beställningar etc. kräver mänskligt godkännande. Varje oåterkallelig handling måste vara föremål för samtycke.

9. Vilken är den bästa designmetoden mot risken för indirekt snabb injektion?

• A) Det räcker med att lägga till en enda mening "ignorera dåliga instruktioner" till systemprompten
• B) Ge modellen mer auktoritet genom att förlita sig på instruktioner i externt innehåll
• C) Att inte vidta några försiktighetsåtgärder eftersom injektion inte går att förebygga
• D) Isolera externt innehåll som opålitlig data och etablera lagerförsvar med minimal auktorisering, godkännande och kontroll av utdata ✔

Beskrivning: Externt innehåll som behandlas av agenten eller RAG, såsom en webbsida, dokument, e-post, etc., är opålitlig data och kan innehålla hemliga instruktioner. Det korrekta tillvägagångssättet är försvar i lager: isolera externt innehåll som "data, inte kommandon" med tydliga avgränsare, tillämpa minimal auktorisering, binda oåterkalleliga åtgärder till mänskligt godkännande och granska utdata. En enda rad instruktioner räcker inte.

10. Vilken är den huvudsakliga skillnaden när man avgör om ett problem ska lösas med finjustering eller RAG?

• A) Informationsproblem löses bättre med RAG, beteende/formatproblem löses bättre med finjustering ✔
• B) Varje problem ska alltid lösas genom finjustering
• C) RAG används endast för kodgenerering, finjustering används endast för översättning
• D) Finjustering kan alltid uppdateras billigare och snabbare än RAG

Förklaring: Finjustering är svag och riskabel när det gäller att lära modellen ny information; men är kraftfull i att lära ut beteende, format, ton och stil. 'Modellföretaget känner inte till våra uppgifter' är ett informationsproblem och tillhör RAG. "Låt modellen alltid skriva ut i vårt strikta format" är ett beteendeproblem och en kandidat för finjustering. Dessutom bör snabba och få bilder tas innan finjustering.

11. Vilket är obligatoriskt för säker driftsättning när en ny modell tas i produktion?

• A) Om modellen är bra i testning, öppna den direkt för 100 % trafik
• B) Att inte sätta upp övervakning alls efter utplacering
• C) Fasad implementering (skugga/kanarie) och en förtestad återställningsplan ✔
• D) Publicering av modellen även om utvärderingströskeln inte är uppfylld

Förklaring: Att öppna den nya modellen direkt för all trafik är riskabelt; Om det är fel påverkas alla. Det korrekta är att det är en gradvis distribution (skugga, kanariefågel) och varje distribution har en testad återställningsplan. En distribution är inte komplett utan en clawback-plan; Att kunna återgå till den tidigare versionen inom några minuter skyddar användaren när modellen beter sig oväntat i produktionen.

12. Hur kan en ML-modell misslyckas "tyst" i produktionen och hur kan man fånga detta?

• A) Modellen kollapsar; serverloggar visar detta
• B) Genom att producera felaktiga förutsägelser utan att göra misstag; ✔ Den fångar drift-, in- och utdatalagerövervakning
• C) Modellen kan aldrig misslyckas tyst, alltid larm
• D) Att bara övervaka latens är tillräckligt för att fånga upp eventuell försämring

Förklaring: Modellen kan misslyckas helt enkelt genom att producera felaktiga förutsägelser utan att krascha eller ge fel; Den främsta anledningen till detta är datadrift och konceptdrift. Det räcker inte att bara övervaka operativa mätvärden (latens, felfrekvens). ingångsfördelning och output/förutsägelsefördelning bör också övervakas. Ingångsdrift ger tidig varning om det faktiska resultatet är försenat.

13. Vilken princip är väsentlig när man använder LLM-som-domare för att utvärdera ett LLM-system?

• A) LLM-domaren är alltid korrekt, mänsklig verifiering är onödig
• B) Domaren måste fatta ett beslut baserat endast på svarslängden.
• C) Regelbaserade kontroller och mänsklig utvärdering bör kasseras helt när domare används
• D) Domarpoäng bör kalibreras med ett människomärkt prov och deras bias mätas innan de kan litas på ✔

Beskrivning: LLM-domare är också en modell; Det kan vara hallucinatoriskt, partiskt (föredrar långa, säkra svar) och inkonsekventa. Därför måste domarpoängen kalibreras med ett människomärkt prov och deras systematiska bias måste mätas innan produktionsbeslutet tas. En overifierad domare ger falskt förtroende.

14. Varför är det otillräckligt att titta på den övergripande noggrannheten när man bedömer modellbias?

• A) Den totala noggrannheten är tillräcklig eftersom den alltid speglar den sämsta gruppens prestation
• B) Enbart övergripande noggrannhet är otillräcklig eftersom den kan dölja systematisk skillnad (dold diskriminering) mellan undergrupper ✔
• C) Eftersom noggrannhet är ett mått som inte har något med bias att göra
• D) Bias kommer bara från modellen och har ingenting med data att göra.

Förklaring: Övergripande noggrannhet kan skymma systematiska skillnader mellan undergrupper. Till exempel, medan den totala noggrannheten är 88 %, kan återkallelsen vara 91 % i en grupp och 67 % i en annan grupp; Modellen missar systematiskt den gruppen. Därför bör modellen utvärderas utifrån undergrupper (demografi/segment) och vilken definition av rättvisa som ska prioriteras bör beslutas med intressenter.

15. Vilka fyra saker måste fixas ihop för att ett ML-resultat ska vara reproducerbart?

• A) Endast modellnamn, storlek, pris och releasedatum
• B) Endast GPU-märke och internethastighet
• C) Endast modellens slutliga noggrannhetspoäng; resten kan sparas i minnet
• D) Slumpmässighetsfrö, dataversion, miljö (beroendeversioner) och experimentspårning ✔

Beskrivning: Reproducerbarhet uppnås genom fyra pelare: fixering av slumpmässiga frön, versionsdata (version/hash), frysning av miljön (exakta biblioteksversioner/behållare) och spårning av varje experiment (kod commit, data, hyperparameter, metrisk). Utan denna kedja är det inte möjligt att reproducera samma resultat; Ett icke-reproducerbart resultat är ett påstående som inte kan bevisas.