Riproducibilità e progetto end-to-end: combinare tutto

Guadagni:

• Capacità di garantire la riproducibilità con quattro pilastri (fissazione dei semi, controllo delle versioni dei dati, congelamento dei supporti, monitoraggio degli esperimenti) e di produrre lo stesso risultato quando si ripete la stessa analisi
• Capacità di combinare tutte le fasi del modulo (metriche, dati, modello, componenti LLM, valutazione, equità, sicurezza, distribuzione, monitoraggio) in una catena end-to-end
• Capacità di verificare che la decisione critica rimanga nelle mani dell'uomo ad ogni fermata e di documentare il progetto in modo verificabile

Il fallimento più insidioso di un progetto ML non è un incidente; "Non otterrò più lo stesso risultato." Se oggi non riesci a riprodurre la partitura del modello che hai messo in produzione tre mesi fa, non controlli realmente quel modello. In questa unità conclusiva, approfondiamo la riproducibilità: la capacità di ottenere in modo affidabile lo stesso risultato con gli stessi input e di combinare l'intero modulo in una disciplina di progetto end-to-end.

Perché la riproducibilità è difficile

Nel software ordinario, lo stesso codice fornisce lo stesso output. Nel ML ci sono molte più variabili che determinano il risultato:

• Casualità: mescolamento dei dati, inizializzazione del peso, suddivisione dei dati: tutto si basa sulla casualità.
• Dati: lo stesso codice produce modelli diversi con versioni di dati diverse.
• Ambiente: le versioni della libreria, l'hardware (CPU/GPU) e persino il sistema operativo possono modificare il risultato.
• Caso nascosto: un iperparametro non salvato, una fase di preelaborazione manuale, una selezione non annotata.

La riproducibilità non è un "bello da avere", ma un imperativo scientifico e ingegneristico. Un risultato che non può essere riprodotto è un'affermazione che non può essere dimostrata.

Quattro pilastri della riproducibilità

1. Correggi la casualità. Imposta tutti i seed casuali in un unico posto: suddivisione dei dati, inizializzazione del modello, mescolamento dei dati. Il seme fisso è la base della garanzia "stesso risultato quando si ripete la stessa corsa".

2. Versione dei dati. Registrare con quale versione dei dati è stato eseguito ciascun esperimento (versione dei dati nell'unità 2). I “dati più recenti” sono vaghi; "versione dati v3, hash abc123" è esatta.

3. Congelare il terreno. Fissa tutte le dipendenze alle loro versioni esatte (ad esempio versioni esatte come numpy==1.26.4 in require.txt o un'immagine del contenitore). L'"ultima versione" un giorno romperà tutto.

4. Tieni traccia di tutto (monitoraggio degli esperimenti). Salva automaticamente per ogni esperimento: versione del codice (git commit), versione dei dati, tutti gli iperparametri, le metriche e le strutture di output. Gli strumenti di monitoraggio degli esperimenti come MLflow, Weights & Biases lo fanno sistematicamente. Senza registrazione la domanda "quale impostazione fosse la migliore" rimane senza risposta.

Attenzione: "Ricorderò più tardi" è l'errore più costoso. Due settimane dopo non ricorderai quale seme, quali dati, quale iperparametro hai utilizzato. Il tracciamento automatico elimina la dipendenza dalla memoria.

Approccio debole/Approccio forte

Debole: "Ho trovato il modello migliore, è sul notebook, penso che il suo punteggio sia stato dell'89%."

Forte: "Esegui #147 nello strumento di tracciamento dell'esperimento: git commit a3f9c, versione dati v3 (hash abc123), seed 42, tutti gli iperparametri registrati, test PR-AUC 0.887. Quando eseguo nuovamente lo stesso comando, ottengo lo stesso risultato poco a poco. Il modello dipende da questa esecuzione nel registro."

La differenza: nell'approccio forte il risultato non si basa su un ricordo, ma su una catena fissa e monitorata. Tutti possono produrre ogni volta lo stesso risultato.

Progetto end-to-end: combinazione di moduli

Ora combiniamo l'intero modulo in un unico flusso di progetto. Un vero sistema ML passa attraverso queste fermate e ciascuna fermata si basa su quella precedente:

1. Definizione del problema: cosa stiamo risolvendo, come misurare il successo (unità 3: metrica corretta, contesto aziendale). La metrica e la soglia sono chiare fin dall’inizio.
2. Pipeline dei dati: raccolta, convalida, pulizia, partizionamento senza perdite, controllo delle versioni (unità 2).
3. Sviluppo del modello: formazione, confronto di base, convalida incrociata, hard seed (unità 3 + questa unità).
4. Componenti LLM (se applicabile): RAG (unità 4) e/o agenti (unità 5); messa a punto se necessario (unità 6).
5. Valutazione: cluster di valutazione con casi edge e di sicurezza, valutazione multistrato nei sistemi LLM (unità 8).
6. Audit di giustizia ed etica: analisi dei sottogruppi, scheda modello, spiegabilità (unità 10).
7. Audit di sicurezza: tempestiva immissione, privacy, catena di fornitura (unità 9).
8. Distribuzione: Packaging, distribuzione graduale, rollback, registro dei modelli (unità 7).
9. Monitoraggio: monitoraggio a tre livelli, allarmi di deriva (unità 8).
10. Riproducibilità: seed, versione dei dati, supporto e tracciamento degli esperimenti lungo l'intera catena (questa unità).

In questo flusso, l’intelligenza artificiale è un acceleratore e un generatore di progetti ad ogni fermata; ma la selezione delle metriche, le decisioni sui dati, la definizione delle priorità di equità, la soglia di distribuzione e l'approvazione del rilascio: le decisioni cruciali rimangono di competenza umana. Questa è l'essenza del modulo.

Documentazione: il futuro ti ringrazierà

Un buon progetto ML si documenta da solo. Come minimo, dovrebbe essere scritto quanto segue: criteri di problema e successo, fonte e versione dei dati, selezioni e giustificazioni del modello, risultati della valutazione (compresi i sottogruppi), limiti e rischi noti, procedura di implementazione e recupero, piano di monitoraggio. Questo documento è il migliore amico della persona (forse sei tu) che ritorna al progetto dopo sei mesi.

tre mini custodie

Caso 1 – Risultato perso. Un ingegnere ha addestrato un ottimo modello, ma non ha corretto il seme e non ha salvato la versione dei dati. Quando lasciò il lavoro, nessuno riuscì a riprodurre quel risultato; il modello divenne una "leggenda della scatola nera" e alla fine fu costruito da zero. Sono state settimane sprecate. Lezione: un risultato non riproducibile è un risultato inesistente.

Caso 2 – Collasso ambientale. Una squadra non aveva corretto le dipendenze. Quando una libreria veniva aggiornata automaticamente, gli output del modello venivano modificati silenziosamente e la produzione veniva interrotta. Ci sono voluti giorni per trovare il problema. Quando le dipendenze sono state congelate e containerizzate con le versioni definitive, il problema non si è più ripresentato. Lezione: congelare l'ambiente.

Caso 3 – Il potere del monitoraggio. Un team ha monitorato automaticamente ogni esperimento. Tre mesi dopo, durante un audit regolamentare, hanno risposto alla domanda "con quali dati, con quali impostazioni, quali prestazioni ha ottenuto in quali gruppi?" con una registrazione completa in pochi minuti. L'ispezione si è svolta senza intoppi. Lezione: il monitoraggio è uno strumento di conformità, non solo ingegneristico.

Modelli copiabili

Eseguire un controllo di riproducibilità per questo progetto ML.- Tutti i seed di casualità sono fissi (divisione, inizializzazione, riproduzione casuale)?- I dati sono sottoposti a versione?- Le dipendenze sono congelate su versioni esatte?- Ogni esperimento (commit del codice, dati, iperparametro, metrica) viene monitorato? Scrivi passaggi concreti su come risolverlo per ogni colonna mancante. Struttura del progetto: [descrizione]

Produrre uno scheletro del piano per questo progetto ML end-to-end. Problema: [descrizione] Copri le seguenti fermate e segna dove si trova la decisione UMANA ad ogni fermata: problema/metrica, pipeline, modello, (RAG/agente/messa a punto?), valutazione, equità, sicurezza, distribuzione, monitoraggio, riproducibilità. Scrivere il rischio principale e la fase di verifica per ciascuna fermata.

Produrre un modello di documentazione tecnica per questo progetto. Sezioni: problema+criteri di successo, dati (sorgente+versione), selezioni del modello+giustificazione, valutazione (inclusi sottogruppi), limiti noti+rischi, implementazione+rollback, piano di monitoraggio. Assegna come domande i campi da compilare per ciascuna sezione.

Controlla la configurazione del monitoraggio dell'esperimento: viene salvato automaticamente a ogni esecuzione: commit git, versione/hash dei dati, tutti gli iperparametri, tutte le metriche, ambiente (versioni della libreria)? Ottengo lo stesso risultato quando eseguo di nuovo la stessa corsa? Configurazione: [descrizione]. Elenca i difetti e le correzioni.

Tabella delle colonne di riproducibilità

colonna

Cosa è fisso

Esempio di veicolo

casualità

tutti i semi

impostazione del seme

Dati

Versione/hash dei dati

DVC

ambiente

Versioni della libreria

pin dei requisiti, Docker

Monitoraggio

Codice+dati+impostazione+metrica

MLflow, W&B

Errori comuni

• Non fissare il seme. Il risultato non può essere ripetuto.
• Non salvare la versione dei dati. "Con quali dati?" rimane senza risposta.
• Non congelare le dipendenze. Un aggiornamento romperà silenziosamente tutto.
• Lasciare gli esperimenti alla memoria. Due settimane dopo non si ricorda più nulla.
• Lasciare le decisioni cruciali all’intelligenza artificiale. Le decisioni relative a parametri, giustizia e distribuzione dovrebbero restare nelle mani delle persone.
• Rinvio della documentazione. La futura squadra (e tu) ne pagherai il prezzo.

In sintesi

La riproducibilità è la caratteristica distintiva dell'ingegneria ML seria: il risultato non riproducibile è l'affermazione non dimostrabile. Viene fornito con quattro colonne: correzione della casualità, dati della versione, blocco dell'ambiente, traccia di ogni esperimento. Un progetto end-to-end combina tutte le fermate di questo modulo (metrica, dati, modello, componenti LLM, valutazione, equità, sicurezza, distribuzione, monitoraggio) in una catena interconnessa; L’intelligenza artificiale è un acceleratore ad ogni fermata, ma le decisioni cruciali restano nelle mani dell’uomo. Documenta tutto, per team e audit futuri. Questa disciplina è la struttura che sostiene tutto ciò che apprendi durante il modulo.

Compito dell'applicazione

Confronta un progetto ML rispetto a quattro pilastri di riproducibilità: i semi sono immutabili, i dati sono sottoposti a versione, l'ambiente è congelato, gli esperimenti vengono tracciati? Correggi eventuali colonne mancanti e dimostra che puoi eseguire la stessa esecuzione due volte e ottenere lo stesso risultato. Quindi genera il flusso end-to-end del progetto (10 fermate) su una pagina e contrassegna "dove si trova la decisione umana" ad ogni fermata. Infine, scrivere una breve bozza di documentazione tecnica.

lista di controllo

• [] Tutti i semi di casualità sono stati risolti.
• [ ] La versione/hash dei dati viene registrato con ciascun esperimento.
• [ ] Le dipendenze sono congelate nelle versioni firm (pin/contenitore).
• [ ] Ogni esperimento viene monitorato automaticamente (codice+dati+impostazione+metrica).
• [ ] Quando ripeto la stessa corsa, ottengo lo stesso risultato.
• [ ] Ho verificato e documentato che le decisioni critiche nel flusso end-to-end vengono prese dagli esseri umani.

Esame del modulo

1. In qualità di ingegnere ML, qual è l'approccio migliore quando si posiziona l'intelligenza artificiale nel flusso di lavoro?

• A) L’intelligenza artificiale è un acceleratore nelle imprese a basso rischio; Le decisioni cruciali come parametri, dati e produzione rimangono convalidate e lasciate all'essere umano ✔
• B) Finché i risultati dell'intelligenza artificiale sembrano buoni, non è necessaria alcuna verifica
• C) Lasciare all’intelligenza artificiale la decisione di mettere in produzione il modello, si risparmia tempo.
• D) L'intelligenza artificiale è utile solo per scrivere testi, non ha nulla a che fare con i dati e il lavoro su modelli

Descrizione: l'intelligenza artificiale è un potente acceleratore per attività a basso rischio e facilmente verificabili come codice, digest di dati e documenti; Tuttavia, la responsabilità delle decisioni che riguardano denaro, riservatezza e responsabilità legale, come la selezione della metrica, quali dati inserire nella formazione e la messa in produzione del modello, spetta all'ingegnere e al team qualificati. Ciascun output non deve essere utilizzato senza verifica.

2. Perché la convalida dello schema viene posizionata all'inizio di una pipeline di dati?

• R) Perché aumenta direttamente la precisione del modello
• B) Perché rende superfluo il controllo delle versioni dei dati
• C) Perché rileva i dati corrotti nel momento più precoce ed economico e impedisce che si diffondano nei passaggi successivi ✔
• D) Perché elimina la necessità di etichettatura

Spiegazione: prima vengono rilevati i dati corrotti, più economico sarà ripararli. La convalida dello schema impedisce che i dati corrotti si diffondano silenziosamente nella formazione o nella produzione rifiutando i dati al di fuori del tipo e dell'intervallo previsti all'inizio della riga (ad esempio spostamento del prezzo di 100 volte con cambio di unità); Lo stesso errore riscontrato in produzione è molte volte più costoso.

3. Qual è l'approccio corretto quando si dividono i dati in training e test in un problema che coinvolge il tempo (serie temporali)?

• A) Usare la suddivisione casuale perché è sempre il metodo più giusto
• B) Utilizzando la suddivisione temporale: prevenire le perdite allenandosi con il passato e testando il futuro ✔
• C) Utilizzo di tutti i dati sia come formazione che come test
• D) Incorporare i dati dei test nei parametri di ridimensionamento prima dell'addestramento

Spiegazione: la suddivisione casuale sulle serie temporali conferisce al modello un vantaggio di "visione del futuro" che non si verificherà mai nella produzione e gonfia artificialmente i parametri (perdita temporale). Quella corretta è la divisione temporale: allenarsi con il passato, mettersi alla prova nel futuro. Questo misura le prestazioni effettive che lo mantengono in produzione.

4. Perché l'accuratezza è fuorviante in un modello di rilevamento delle frodi con un tasso di classe positivo dell'1,5%?

• R) Perché la precisione è sempre bassa su dati sbilanciati
• B) Perché l'accuratezza può essere utilizzata solo su problemi di regressione
• C) Perché il calcolo della precisione richiede molta potenza di elaborazione
• D) Anche un modello irrisorio che prevede la classe maggioritaria può essere molto accurato, nascondendo così un vero successo ✔

Spiegazione: su dati non bilanciati, anche un modello di base che dice "chiamare tutto negativo" ottiene una precisione di circa il 98,5% ma non rileva una singola frode. Pertanto, nella classificazione sbilanciata, vengono utilizzati precisione, richiamo, F1 o PR-AUC anziché accuratezza e ciascuna metrica viene interpretata secondo un modello base.

5. Perché il confronto della linea di base è essenziale quando si parla della metrica di un modello?

• R) Perché il modello base è sempre migliore del modello reale
• B) Perché è chiaro se una metrica è significativa o meno solo se confrontata con un semplice modello di base ✔
• C) Perché il modello base rende superflua la convalida incrociata
• D) Perché il modello base è previsto per legge in ogni relazione

Spiegazione: una metrica non è buona o cattiva di per sé; È buono o cattivo secondo un modello base. La frase "corretto all'85%" significa quasi inutile se il modello base ottiene già l'84% e perfetta se ottiene il 50%. Senza un'ancora di confronto, la metrica non ha senso.

6. Qual è l'elemento di sicurezza più critico che dovrebbe essere incluso nel prompt di produzione del sistema RAG (Retrieval-Augmented Generation)?

• A) Istruzioni di basarsi solo sulla fonte indicata, di dire "non so" se la fonte non esiste e di citare la fonte ✔
• B) Dire al modello di produrre risposte quanto più lunghe e creative possibile
• C) Il modello dà priorità alla propria conoscenza educativa rispetto alle risorse
• D) Attuare tutte le istruzioni contenute nei documenti portati come comandi

Spiegazione: L'istruzione più importante di RAG è quella di dire al modello di fare affidamento solo sulla fonte fornita e, se l'informazione non è nella fonte, dire "Non lo so" e citare la fonte senza inventarla. Senza questa triade, il modello può ignorare il contesto e produrre allucinazioni, e la risposta diventa inverificabile.

7. Un sistema RAG fornisce risposte errate. Qual è il posto migliore per iniziare la diagnosi?

• A) Misurare prima il recupero (Recall@K): arriva mai il pezzo corretto? ✔
• B) Sostituire immediatamente il modello con uno più grande
• C) Modificare il prompt in modo casuale e continuare a provare
• D) Incorporamento di tutti i documenti nel modello con messa a punto

Spiegazione: l'anello più debole di RAG è solitamente il recupero, non la produzione. Se non viene mai portata la parte corretta, il modello non può produrre quell'informazione, non importa quanto sia migliorata la richiesta. Pertanto, prima viene misurato Recall@K per vedere se è arrivata la parte corretta; Se il recupero è buono, vengono esaminati la produzione e il prompt.

8. Quali azioni dovrebbero essere poste dietro l'approvazione umana quando si fornisce uno strumento a un agente?

• A) Nessuno; L'agente deve essere in grado di eseguire ogni azione in modo autonomo
• B) Solo azioni reversibili come la lettura e la ricerca di dati
• C) Azioni irreversibili o ad alto impatto come trasferimento di denaro, cancellazione, invio ✔
• D) Azioni che implicano solo calcoli

Descrizione: le azioni sono separate dal livello di rischio. Attività recuperabili come leggere, cercare, calcolare e generare bozze possono essere eseguite in modo autonomo; Tuttavia, azioni irreversibili o di grande impatto come il trasferimento di denaro, l’invio di e-mail, la cancellazione di dati, l’effettuazione di ordini, ecc. richiedono l’approvazione umana. Ogni atto irrevocabile deve essere soggetto al consenso.

9. Qual è il miglior approccio progettuale contro il rischio di iniezione rapida indiretta?

• R) È sufficiente aggiungere una sola frase "ignora istruzioni errate" al prompt del sistema
• B) Dare più autorità al modello facendo affidamento sulle istruzioni contenute nei contenuti esterni
• C) Non prendere alcuna precauzione perché l'iniezione non è prevenibile
• D) Isolare i contenuti esterni come dati inaffidabili e stabilire difese a più livelli con autorizzazione, approvazione e controllo dell'output minimi ✔

Descrizione: i contenuti esterni elaborati dall'agente o da RAG, ad esempio una pagina Web, un documento, un'e-mail, ecc., sono dati non attendibili e possono contenere istruzioni segrete. L'approccio corretto è la difesa a più livelli: isolare i contenuti esterni come "dati, non comandi" con delimitatori chiari, applicare un'autorizzazione minima, vincolare azioni irreversibili all'approvazione umana e controllare l'output. Una sola riga di istruzioni non è sufficiente.

10. Qual è la distinzione principale nel decidere se un problema debba essere risolto con il fine tuning o con il RAG?

• A) I problemi di informazione si risolvono meglio con RAG, i problemi di comportamento/formato si risolvono meglio con il fine tuning ✔
• B) Ogni problema dovrebbe sempre essere risolto attraverso la messa a punto
• C) RAG viene utilizzato solo per la generazione del codice, la regolazione fine viene utilizzata solo per la traduzione
• D) Il fine tuning può sempre essere aggiornato in modo più economico e veloce rispetto a RAG

Spiegazione: il fine-tuning è debole e rischioso nell'insegnare al modello nuove informazioni; ma è potente nell’insegnare il comportamento, il formato, il tono e lo stile. "L'azienda modello non conosce i nostri dati" è un problema informativo e appartiene alla RAG. "Lasciare che il modello venga sempre prodotto nel nostro formato rigoroso" è un problema comportamentale e un candidato per la messa a punto. Inoltre, è necessario consumare pochi scatti tempestivi prima della messa a punto.

11. Cosa è obbligatorio per un'implementazione sicura quando si mette in produzione un nuovo modello?

• R) Se il modello è buono in fase di test, aprilo direttamente al traffico al 100%.
• B) Non impostare affatto il monitoraggio dopo la distribuzione
• C) Implementazione graduale (shadow/canary) e un piano di rollback pre-testato ✔
• D) Pubblicare il modello anche se la soglia di valutazione non viene raggiunta

Spiegazione: aprire il nuovo modello direttamente a tutto il traffico è rischioso; Se è sbagliato, tutti ne risentono. La cosa corretta è che si tratta di una distribuzione graduale (shadow, canary) e ogni distribuzione ha un piano di rollback testato. Una distribuzione non è completa senza un piano di recupero; La possibilità di ripristinare la versione precedente in pochi minuti protegge l'utente quando il modello si comporta in modo imprevisto in produzione.

12. In che modo un modello ML può fallire "silenziosamente" nella produzione e qual è il modo per risolverlo?

• A) Il modello crolla; i log del server lo mostrano
• B) Producendo pronostici errati senza commettere errori; ✔ Cattura il monitoraggio a più livelli operativo, di input e di output
• C) Il modello non può mai fallire silenziosamente, sempre in allarme
• D) Il semplice monitoraggio della latenza è sufficiente per rilevare eventuali degradi

Spiegazione: il modello può fallire semplicemente producendo previsioni errate senza bloccarsi o dare errori; La ragione principale di ciò è la deriva dei dati e la deriva dei concetti. Il semplice monitoraggio dei parametri operativi (latenza, tasso di errore) non è sufficiente; dovrebbero essere monitorate anche la distribuzione degli input e la distribuzione degli output/previsioni. La deriva dell'input fornisce un avviso tempestivo se il risultato effettivo viene ritardato.

13. Quale principio è essenziale quando si utilizza LLM come giudice per valutare un sistema LLM?

• A) L'arbitro LLM ha sempre ragione, la verifica umana non è necessaria
• B) L'arbitro deve prendere una decisione basandosi solo sulla lunghezza della risposta.
• C) I controlli basati su regole e la valutazione umana dovrebbero essere completamente scartati quando si utilizzano gli arbitri
• D) I punteggi dei giudici dovrebbero essere calibrati con un campione etichettato come umano e il loro bias dovrebbe essere misurato prima che ci si possa fidare ✔

Descrizione: L'arbitro LLM è anche un modello; Può essere allucinatorio, parziale (favorendo risposte lunghe e sicure) e incoerente. Pertanto, i punteggi degli arbitri devono essere calibrati con un campione umano etichettato e la loro distorsione sistematica deve essere misurata prima che venga presa la decisione sulla produzione. Un arbitro non verificato dà falsa fiducia.

14. Perché l’attenzione all’accuratezza complessiva è inadeguata quando si valuta la distorsione del modello?

• R) La precisione complessiva è sufficiente perché riflette sempre la prestazione del gruppo peggiore
• B) La precisione complessiva da sola non è sufficiente in quanto può oscurare la differenza sistematica (discriminazione nascosta) tra i sottogruppi ✔
• C) Perché l'accuratezza è una metrica che non ha nulla a che fare con il bias
• D) La distorsione deriva solo dal modello e non ha nulla a che fare con i dati.

Spiegazione: l'accuratezza complessiva può oscurare le differenze sistematiche tra i sottogruppi. Ad esempio, mentre l'accuratezza complessiva è dell'88%, il ricordo può essere del 91% in un gruppo e del 67% in un altro gruppo; Il modello trascura sistematicamente quel gruppo. Pertanto, il modello dovrebbe essere valutato sulla base di sottogruppi (dati demografici/segmento) e la definizione di giustizia a cui dare priorità dovrebbe essere decisa con le parti interessate.

15. Quali quattro cose devono essere fissate insieme affinché un risultato ML sia riproducibile?

• A) Solo nome del modello, dimensione, prezzo e data di rilascio
• B) Solo marca della GPU e velocità di Internet
• C) Solo il punteggio finale di accuratezza del modello; il resto può essere tenuto in memoria
• D) Seme di casualità, versione dei dati, ambiente (versioni delle dipendenze) e monitoraggio degli esperimenti ✔

Descrizione: la riproducibilità si ottiene attraverso quattro pilastri: correzione dei semi di casualità, controllo delle versioni dei dati (versione/hash), congelamento dell'ambiente (versioni esatte della libreria/contenitore) e monitoraggio di ogni esperimento (commit del codice, dati, iperparametro, metrica). Senza questa catena non è possibile riprodurre lo stesso risultato; Un risultato non riproducibile è un'affermazione che non può essere dimostrata.