Reproductibilitatea și proiectul end-to-end: combinând totul

Câștiguri:

• Capacitatea de a asigura reproductibilitatea cu patru piloni (fixarea semințelor, versiunea datelor, înghețarea suportului, monitorizarea experimentului) și de a produce același rezultat atunci când se repetă aceeași rulare
• Abilitatea de a combina toate opririle modulului (metrici, date, model, componente LLM, eval, corectitudine, securitate, distribuție, monitorizare) într-un lanț end-to-end
• Capacitatea de a verifica dacă decizia critică rămâne în mâinile omului la fiecare oprire și de a documenta proiectul într-o manieră auditabilă

Cel mai insidios eșec al unui proiect ML nu este un accident; „Nu obținem din nou același rezultat”. Dacă nu poți reproduce azi scorul modelului pe care l-ai pus în producție acum trei luni, nu prea controlezi acel model. În această unitate de închidere, aprofundăm reproductibilitatea: capacitatea de a obține în mod fiabil același rezultat cu aceleași intrări și de a combina întregul modul într-o disciplină de proiect end-to-end.

De ce reproductibilitatea este dificilă

În software-ul obișnuit, același cod oferă aceeași ieșire. În ML există mult mai multe variabile care determină rezultatul:

• Aleatorie: amestecarea datelor, inițializarea greutății, împărțirea datelor - toate se bazează pe aleatoriu.
• Date: Același cod produce modele diferite cu versiuni de date diferite.
• Mediu: Versiunile bibliotecii, hardware-ul (CPU/GPU), chiar și sistemul de operare pot schimba rezultatul.
• Caz ascuns: un hiperparametru nesalvat, un pas de preprocesare manuală, o selecție neobservată.

Reproductibilitatea nu este un „drăguț de a avea” ci un imperativ științific și de inginerie. Un rezultat care nu poate fi reprodus este o afirmație care nu poate fi dovedită.

Patru piloni ai reproductibilității

1. Remediați aleatorietatea. Setați toate semințele aleatorii într-un singur loc: împărțirea datelor, inițializarea modelului, amestecarea datelor. Sămânța fixă ​​stă la baza garanției „același rezultat când repeți aceeași rulare”.

2. Versiune datele. Înregistrați cu ce versiune de date a fost efectuat fiecare experiment (versionarea datelor în unitatea 2). „Ultimele date” sunt vagi; „Versiunea de date v3, hash abc123” este exactă.

3. Înghețați mediul. Fixați toate dependențele la versiunile lor exacte (de exemplu, versiuni exacte, cum ar fi numpy==1.26.4 în requirements.txt sau o imagine de container). „Ultima versiune” va sparge totul într-o zi.

4. Urmăriți totul (urmărirea experimentului). Salvați automat pentru fiecare experiment: versiunea codului (git commit), versiunea datelor, toți hiperparametrii, valorile și structurile de ieșire. Instrumentele de urmărire a experimentelor precum MLflow, Weights & Biases fac acest lucru în mod sistematic. Fără înregistrare, întrebarea „care setare a fost cea mai bună” rămâne fără răspuns.

Atenție: „Îmi voi aminti mai târziu” este cea mai scumpă eroare. Două săptămâni mai târziu nu vă veți aminti ce sămânță, ce date, ce hiperparametru ați folosit. Urmărirea automată elimină dependența de memorie.

Abordare slabă / Abordare puternică

Slab: „Am găsit cel mai bun model, este pe notebook, cred că scorul lui a fost de 89%.

Puternic: „Run #147 în instrumentul de urmărire a experimentului: git commit a3f9c, versiunea de date v3 (hash abc123), seed 42, toți hiperparametrii înregistrați, testează PR-AUC 0.887. Când rulez din nou aceeași comandă, primesc același rezultat bit cu bit. Modelul depinde de această rulare în registru."

Diferența: în abordarea puternică rezultatul nu se bazează pe o memorie, ci pe un lanț fix și monitorizat. Toată lumea poate produce același rezultat de fiecare dată.

Proiect end-to-end: combinație de modul

Acum să combinăm întregul modul într-un singur flux de proiect. Un sistem ML real trece prin aceste opriri, iar fiecare oprire se bazează pe cea anterioară:

1. Definiția problemei: Ce rezolvăm, cum să măsuram succesul (unitatea 3: metrica corectă, contextul de afaceri). Valoarea și pragul sunt clare de la început.
2. Conducta de date: Colectare, validare, curățare, partiționare fără scurgeri, versiunea (unitatea 2).
3. Dezvoltare model: Antrenament, comparație de bază, validare încrucișată, semințe dure (unitatea 3 + această unitate).
4. Componente LLM (dacă este cazul): RAG (unitatea 4) și/sau agenți (unitatea 5); reglaj fin dacă este necesar (unitatea 6).
5. Evaluare: cluster de evaluare cu cazuri marginale și de securitate, evaluare multistrat în sisteme LLM (unitatea 8).
6. Audit de justiție și etică: analiză subgrup, fișă model, explicabilitate (unitatea 10).
7. Audit de securitate: injectare promptă, confidențialitate, lanț de aprovizionare (unitatea 9).
8. Distribuție: Ambalare, distribuție graduală, rollback, model registry (unitatea 7).
9. Monitorizare: monitorizare pe trei straturi, alarme de deriva (unitatea 8).
10. Reproductibilitate: semințele, versiunea datelor, mediile și urmărirea experimentului de-a lungul întregului lanț (această unitate).

În acest flux, AI este un accelerator și un generator de plan la fiecare oprire; dar selecția valorilor, deciziile privind datele, prioritizarea corectitudinii, pragul de implementare și aprobarea lansării - deciziile critice rămân în sarcina umanului. Aceasta este esența modulului.

Documentare: viitorul vă va mulțumi

Un bun proiect ML se documentează. Trebuie scrise cel puțin următoarele: criterii de problemă și de succes, sursa și versiunea datelor, selecțiile și justificările modelului, rezultatele evaluării (inclusiv subgrupuri), limitele și riscurile cunoscute, procedura de desfășurare și regăsire, planul de monitorizare. Acest document este cel mai bun prieten al persoanei (poate că ești tu) care se întoarce la proiect după șase luni.

trei mini cutii

Cazul 1 - Rezultat pierdut. Un inginer a pregătit un model grozav, dar nu a reparat sămânța și nu a salvat versiunea de date. Când a părăsit locul de muncă, nimeni nu a putut reproduce acel rezultat; modelul a devenit o „legendă cutie neagră” și în cele din urmă a fost construit de la zero. Săptămânile au fost irosite. Lecție: un rezultat nereproductibil este un rezultat inexistent.

Cazul 2 - Colapsul mediului. O echipă nu remediase dependențele. Când o bibliotecă a fost actualizată automat, rezultatele modelului s-au schimbat în tăcere și producția a fost întreruptă. A durat zile pentru a găsi problema. Când dependențele au fost înghețate și containerizate cu versiunile definitive, problema nu a mai apărut. Lecția: îngheța mediul.

Cazul 3 - Puterea monitorizării. O echipă a monitorizat automat fiecare experiment. Trei luni mai târziu, în timpul unui audit de reglementare, au răspuns la întrebarea „cu ce date, cu ce setări, ce performanță a obținut în ce grupuri?” cu o înregistrare completă în câteva minute. Inspecția a decurs fără probleme. Lecție: monitorizarea este un instrument de conformitate, nu doar unul de inginerie.

Șabloane copiabile

Efectuați o verificare a reproductibilității pentru acest proiect ML.- Sunt remediate toate semințele aleatoriei (divizați, inițializați, amestecați)?- Datele sunt versionate?- Sunt dependențele înghețate la versiuni exacte?- Este urmărit fiecare experiment (comitarea codului, date, hiperparametru, metrică)? Scrieți pași concreti despre cum să o remediați pentru fiecare coloană lipsă. Structura proiectului: [descriere]

Produceți un schelet de plan pentru acest proiect ML de la capăt la capăt. Problemă: [descriere] Acoperiți următoarele opriri și marcați unde este decizia UMAN la fiecare oprire: problemă/metric, conductă, model, (RAG/agent/reglare fină?), eval, corectitudine, securitate, distribuție, monitorizare, reproductibilitate. Scrieți riscul principal și pasul de verificare pentru fiecare oprire.

Produceți un șablon de documentație tehnică pentru acest proiect. Secțiuni: problemă+criterii de succes, date (sursă+versiunea), selecții de modele+justificare, evaluare (inclusiv subgrupe), limite cunoscute+riscuri, implementare+rollback, plan de monitorizare. Dați câmpurile de completat pentru fiecare secțiune ca întrebări.

Verificați configurația de monitorizare a experimentului: se salvează automat la fiecare rulare: git commit, versiunea de date/hash, toți hiperparametrii, toate valorile, mediul (versiunile bibliotecii)? Obțin același rezultat când rulez din nou aceeași cursă? Configurare: [descriere]. Enumerați defectele și corectarea.

Tabel coloane de reproductibilitate

coloana

Ce este fix

Exemplu de vehicul

aleatorietatea

toate semințele

aşezarea seminţelor

Date

Versiunea datelor/hash

DVC

mediu

Versiuni de bibliotecă

pin de cerințe, Docker

Monitorizare

Cod+setare+date+metrică

MLflow, W&B

Greșeli comune

• Nu fixează sămânța. Rezultatul nu poate fi repetat.
• Nu se salvează versiunea datelor. — Cu ce ​​date? rămâne fără răspuns.
• Nu îngheța dependențe. O actualizare va rupe totul în tăcere.
• Lăsând experimentele în memorie. Două săptămâni mai târziu, nu se mai amintește nimic.
• Lăsând deciziile critice în seama inteligenței artificiale. Valorile, justiția și deciziile de distribuție ar trebui să rămână în seama oamenilor.
• Amânarea documentării. Viitoarea echipă (și tu) plătești prețul.

Pe scurt

Reproductibilitatea este semnătura ingineriei ML serioase: rezultatul nereproductibil este afirmația nedemonstrabilă. Vine cu patru coloane - remediați aleatoritatea, datele versiunii, înghețați mediul, urmăriți fiecare experiment. Un proiect end-to-end combină toate opririle acestui modul (metric, date, model, componente LLM, eval, fairness, securitate, distribuție, monitorizare) într-un lanț interconectat; Inteligența artificială este un accelerator la fiecare oprire, dar deciziile critice rămân în sarcina omului. Documentați totul - pentru viitoarele echipe și audituri. Această disciplină este cadrul care susține tot ceea ce înveți pe parcursul modulului.

Sarcina de aplicare

Verificați un proiect ML în raport cu patru piloni de reproductibilitate: semințele sunt imuabile, datele sunt versionate, mediul este înghețat, experimentele sunt urmărite? Remediați coloanele lipsă și demonstrați că puteți rula aceeași rulare de două ori și obțineți același rezultat. Apoi scoateți fluxul de la capăt la capăt al proiectului (10 opriri) pe o pagină și marcați „unde este decizia umană” la fiecare oprire. În cele din urmă, scrieți un scurt proiect de documentație tehnică.

lista de verificare

• [ ] Toate semințele aleatorii au fost fixate.
• [ ] Versiunea de date/hash este înregistrată cu fiecare experiment.
• [ ] Dependențele sunt înghețate în versiuni ferme (pin/container).
• [ ] Fiecare experiment este monitorizat automat (cod+date+setare+valoare).
• [ ] Când repet aceeași rulare, obțin același rezultat.
• [ ] Am verificat și am documentat că deciziile critice în fluxul de la capăt la capăt sunt luate de oameni.

Examenul modulului

1. În calitate de inginer ML, care este cea mai bună abordare atunci când poziționați inteligența artificială în fluxul de lucru?

• A) AI este un accelerator în afacerile cu risc scăzut; Deciziile critice, cum ar fi valorile, datele și producția, rămân validate și lăsate în seama omului ✔
• B) Atâta timp cât ieșirile AI arată bine, nu este nevoie de verificare
• C) Lăsând decizia de a pune modelul în producție inteligenței artificiale economisește timp.
• D) Inteligența artificială este utilă doar pentru scrierea textului, nu are nimic de-a face cu datele și munca de model

Descriere: AI este un accelerator puternic pentru sarcini cu risc scăzut, ușor de verificat, cum ar fi cod, rezumate de date și documente; Cu toate acestea, responsabilitatea pentru deciziile care afectează banii, confidențialitatea și răspunderea legală, cum ar fi selectarea metricului, care date sunt în curs de instruire și punerea modelului în producție, revine inginerului și echipei calificate. Fiecare ieșire nu trebuie utilizată fără verificare.

2. De ce este plasată validarea schemei la începutul unei conducte de date?

• A) Pentru că crește direct acuratețea modelului
• B) Pentru că nu este necesară versiunea datelor
• C) Deoarece captează datele corupte în cel mai devreme și cel mai ieftin punct și împiedică scurgerea acestora în următorii pași ✔
• D) Pentru că elimină necesitatea etichetării

Explicație: Cu cât datele corupte sunt capturate mai devreme, cu atât este mai ieftin să le remediați. Validarea schemei previne scurgerea silențioasă a datelor corupte în instruire sau producție prin respingerea datelor din afara tipului și intervalului așteptat la începutul liniei (de exemplu, schimbarea prețului de 100 ori cu schimbarea unității); Aceeași eroare prinsă în producție este de multe ori mai scumpă.

3. Care este abordarea corectă atunci când împărțiți datele în instruire și testare într-o problemă care implică timp (serie temporală)?

• A) Folosind împărțirea aleatorie, deoarece este întotdeauna cea mai corectă metodă
• B) Utilizarea divizării temporale: preveniți scurgerea prin antrenament cu trecutul și testarea în viitor ✔
• C) Utilizarea tuturor datelor atât ca instruire, cât și ca testare
• D) Încorporarea datelor de testare în parametrii de scalare înainte de antrenament

Explicație: Împărțirea aleatorie pe serii cronologice oferă modelului un avantaj de „viziune în viitor” care nu se va întâmpla niciodată în producție și umflă artificial valorile (scurgere temporală). Cea corectă este împărțirea temporală: antrenează-te cu trecutul, testează în viitor. Aceasta măsoară performanța reală care îl menține în producție.

4. De ce este înșelătoare acuratețea într-un model de detectare a fraudei cu o rată de clasă pozitivă de 1,5%?

• A) Deoarece acuratețea este întotdeauna scăzută în cazul datelor dezechilibrate
• B) Deoarece acuratețea poate fi folosită numai în probleme de regresie
• C) Deoarece calculul cu precizie necesită multă putere de procesare
• D) Chiar și un model meschin care prezice clasa majoritară poate fi foarte precis, ascunzând astfel succesul real ✔

Explicație: În cazul datelor dezechilibrate, chiar și un model de bază care spune „sunați totul negativ” obține o acuratețe de aproximativ 98,5%, dar nu va prinde o singură fraudă. Prin urmare, în clasificarea dezechilibrată, precizia, rechemarea, F1 sau PR-AUC sunt folosite în loc de acuratețe, iar fiecare metrică este interpretată conform unui model de bază.

5. De ce este esențială comparația de referință atunci când vorbim despre metrica unui model?

• A) Pentru că modelul de bază este întotdeauna mai bun decât modelul real
• B) Pentru că este clar dacă o măsurătoare este semnificativă sau nu numai în comparație cu un model de bază simplu ✔
• C) Deoarece modelul de bază face inutilă validarea încrucișată
• D) Pentru că modelul de bază este obligatoriu legal în fiecare raport

Explicație: o măsurătoare nu este bună sau rea în sine; Este bine sau rău după un model de bază. Propoziția „85% corectă” înseamnă aproape inutilă dacă modelul de bază obține deja 84% și perfect dacă obține 50%. Fără o ancoră de comparație, metrica este lipsită de sens.

6. Care este cel mai critic element de securitate care ar trebui inclus în promptul de producție al sistemului RAG (Retrieval-Augmented Generation)?

• A) Instrucțiuni de a te baza doar pe sursa dată, de a spune „nu știu” dacă sursa nu există și de a cita sursa ✔
• B) Spune-i modelului să producă răspunsuri cât mai lungi și creative
• C) Modelul prioritizează propriile cunoștințe educaționale față de resurse
• D) Implementează toate instrucțiunile din documentele aduse ca comenzi

Explicație: Cea mai importantă instrucțiune a RAG este de a spune modelului să se bazeze numai pe sursa dată, iar dacă informația nu este în sursă, spuneți „Nu știu” și citați sursa fără a o inventa. Fără această triadă, modelul poate ignora contextul și poate produce halucinații, iar răspunsul devine imposibil de verificat.

7. Un sistem RAG dă răspunsuri incorecte. Unde este cel mai bun loc pentru a începe diagnosticul?

• A) Măsurarea preluării mai întâi (Recall@K): ajunge vreodată piesa corectă? ✔
• B) Înlocuiți imediat modelul cu unul mai mare
• C) Schimbați promptul la întâmplare și continuați să încercați
• D) Încorporarea tuturor documentelor în model cu reglaj fin

Explicație: cea mai slabă verigă a RAG este de obicei preluarea, nu producția. Dacă piesa corectă nu este adusă niciodată, modelul nu poate produce acea informație, indiferent cât de mult este îmbunătățită promptul. Prin urmare, mai întâi se măsoară Recall@K pentru a vedea dacă a sosit piesa corectă; Dacă preluarea este bună, atunci producția și promptul sunt examinate.

8. Ce acțiuni ar trebui puse în spatele aprobării umane atunci când dați un instrument unui agent?

• A) Niciuna; Agentul trebuie să poată efectua fiecare acțiune în mod autonom
• B) Numai acțiuni reversibile, cum ar fi citirea și căutarea datelor
• C) Acțiuni ireversibile sau de mare impact, cum ar fi transferul de bani, ștergerea, trimiterea ✔
• D) Acțiuni care implică doar calcule

Descriere: acțiunile sunt separate după nivelul de risc. Sarcinile recuperabile, cum ar fi citirea, căutarea, calcularea și generarea de schițe pot fi efectuate în mod autonom; Cu toate acestea, acțiunile ireversibile sau cu impact ridicat, cum ar fi transferul de bani, trimiterea de e-mailuri, ștergerea datelor, plasarea comenzilor etc. necesită aprobarea umană. Fiecare acțiune irevocabilă trebuie să fie supusă consimțământului.

9. Care este cea mai bună abordare de proiectare împotriva riscului de injectare promptă indirectă?

• A) Este suficient să adăugați o singură propoziție „ignorați instrucțiunile greșite” la promptul de sistem
• B) Oferiți mai multă autoritate modelului bazându-vă pe instrucțiunile din conținut extern
• C) Nu luați măsuri de precauție deoarece injectarea nu este prevenită
• D) Izolarea conținutului extern ca date nesigure și stabilirea unor apărări stratificate cu autorizare, aprobare și control minime ale ieșirii ✔

Descriere: conținutul extern procesat de agent sau RAG, cum ar fi o pagină web, un document, un e-mail etc., este date nesigure și poate conține instrucțiuni secrete. Abordarea corectă este apărarea stratificată: izolarea conținutului extern ca „date, nu comenzi” cu delimitatori clari, aplicarea unei autorizații minime, legarea acțiunilor ireversibile la aprobarea umană și auditarea rezultatelor. O singură linie de instrucțiuni nu este suficientă.

10. Care este principala distincție atunci când decideți dacă o problemă ar trebui rezolvată cu reglaj fin sau RAG?

• A) Problemele de informare sunt mai bine rezolvate cu RAG, problemele de comportament/format sunt mai bine rezolvate cu reglaj fin ✔
• B) Fiecare problemă trebuie rezolvată întotdeauna prin reglare fină
• C) RAG este folosit doar pentru generarea codului, reglajul fin este folosit doar pentru traducere
• D) Reglajul fin poate fi întotdeauna actualizat mai ieftin și mai rapid decât RAG

Explicație: Reglajul fin este slab și riscant în predarea modelului de informații noi; dar este puternic în predarea comportamentului, formatului, tonului și stilului. „Compania de model nu cunoaște datele noastre” este o problemă de informare și aparține RAG. „Lăsați modelul să iasă întotdeauna în formatul nostru strict” este o problemă de comportament și un candidat pentru reglare fină. În plus, înainte de reglare fină ar trebui să se consume imediat și câteva fotografii.

11. Ce este obligatoriu pentru implementarea în siguranță atunci când introduceți un nou model în producție?

• A) Dacă modelul este bun la testare, deschideți-l direct la trafic 100%.
• B) Nu se configurează deloc monitorizarea după implementare
• C) Desfășurare în etape (umbră/canar) și un plan de rollback pre-testat ✔
• D) Publicarea modelului chiar dacă nu este atins pragul de evaluare

Explicație: Deschiderea noului model direct către tot traficul este riscantă; Dacă este greșit, toată lumea este afectată. Lucrul corect este că este o distribuție graduală (umbră, canar) și fiecare distribuție are un plan de rollback testat. O distribuție nu este completă fără un plan de clawback; Posibilitatea de a reveni la versiunea anterioară în câteva minute protejează utilizatorul atunci când modelul se comportă neașteptat în producție.

12. Cum poate un model ML să eșueze „în tăcere” în producție și care este modalitatea de a surprinde acest lucru?

• A) Modelul se prăbușește; jurnalele serverului arată asta
• B) Producând predicții greșite fără a greși; ✔ Captează monitorizarea operațională, stratificată de intrare și ieșire
• C) Modelul nu poate eșua niciodată în tăcere, întotdeauna alarma
• D) Doar monitorizarea latenței este suficientă pentru a surprinde orice degradare

Explicație: Modelul poate eșua pur și simplu prin producerea de predicții incorecte fără să se prăbușească sau să dea erori; Motivul principal pentru aceasta este deriva de date și deriva de concept. Doar monitorizarea valorilor operaționale (latența, rata de eroare) nu este suficientă; distribuția intrărilor și distribuția ieșirilor/predicțiilor ar trebui, de asemenea, monitorizate. Deviația de intrare oferă o avertizare timpurie dacă rezultatul real este întârziat.

13. Ce principiu este esențial atunci când folosiți LLM-as-judge pentru a evalua un sistem LLM?

• A) Arbitrul LLM este întotdeauna corect, verificarea umană nu este necesară
• B) Arbitrul trebuie să ia o decizie bazată numai pe lungimea răspunsului.
• C) Controalele bazate pe reguli și evaluarea umană ar trebui să fie eliminate complet atunci când sunt folosiți arbitri
• D) Scorurile arbitrilor ar trebui calibrate cu un eșantion etichetat uman, iar părtinirea lor trebuie măsurată înainte de a putea fi de încredere ✔

Descriere: LLM-arbitru este, de asemenea, un model; Poate fi halucinantă, părtinitoare (favorizează răspunsurile lungi și sigure) și inconsecventă. Prin urmare, scorurile arbitrilor trebuie calibrate cu un eșantion etichetat uman și părtinirea lor sistematică trebuie măsurată înainte de a se lua decizia de producție. Un arbitru neverificat oferă o falsă încredere.

14. De ce analiza acurateței generale este inadecvată atunci când se evaluează părtinirea modelului?

• A) Precizia generală este suficientă deoarece reflectă întotdeauna performanța celui mai prost grup
• B) Doar acuratețea generală este insuficientă, deoarece poate ascunde diferența sistematică (discriminare ascunsă) între subgrupuri ✔
• C) Deoarece acuratețea este o măsurătoare care nu are nimic de-a face cu părtinirea
• D) Prejudiciul provine doar din model și nu are nimic de-a face cu datele.

Explicație: Precizia generală poate ascunde diferențele sistematice dintre subgrupuri. De exemplu, în timp ce acuratețea generală este de 88%, amintirea poate fi de 91% într-un grup și de 67% în alt grup; Modelul ratează în mod sistematic acel grup. Prin urmare, modelul ar trebui evaluat pe baza subgrupurilor (demografie/segment) și care definiție a justiției ar trebui să fie prioritizată ar trebui să fie decisă cu părțile interesate.

15. Ce patru lucruri trebuie fixate împreună pentru ca un rezultat ML să fie reproductibil?

• A) Numai numele modelului, mărimea, prețul și data lansării
• B) Numai marca GPU și viteza internetului
• C) Doar scorul de precizie final al modelului; restul poate fi păstrat în memorie
• D) Semințele aleatorii, versiunea datelor, mediul (versiuni de dependență) și urmărirea experimentului ✔

Descriere: Reproductibilitatea se realizează prin intermediul a patru piloni: repararea semințelor aleatoriei, versiunea datelor (versiune/hash), înghețarea mediului (versiuni exacte de bibliotecă/container) și urmărirea fiecărui experiment (comitarea codului, date, hiperparametru, metrică). Fără acest lanț nu este posibil să se reproducă același rezultat; Un rezultat nereproductibil este o afirmație care nu poate fi dovedită.