Validare un modello addestrato

Un modello addestrato può ottenere un buon punteggio su una suite che ha già visto, cambiare risposta quando un input si sposta di poco e capitare su un seed fortunato. Oloproof controlla ciascuna di queste cose prima che il modello vada in produzione: la suite rispetto ai dati di addestramento, ogni previsione sotto un rumore dichiarato e la ricetta di addestramento su più seed. Copia l'esempio con oloproof init --example model-validation: un modello per prestiti addestrato con NumPy, offline, su dati sintetici.

La suite rispetto ai dati di addestramento

oloproof leakage check --training data/training.jsonl --record

Ogni caso viene confrontato con ogni riga di addestramento per corrispondenza esatta, dopo aver portato le stringhe in minuscolo e compresso gli spazi (--round arrotonda i numeri, --field indica le chiavi da confrontare). Il file di addestramento viene letto sulla tua macchina e non viene mai salvato né inviato; il record conserva gli id dei casi e i conteggi. Dichiara leakage: required in release.yaml e il gate resta bloccato (codice di uscita 3) finché non viene registrato un controllo pulito di questa suite. Un caso trovato nei dati di addestramento rende l'evidenza non valida; non è un FAIL del modello. I quasi duplicati non vengono controllati.

Previsioni sotto rumore

metamorphic:
  transforms:
    - name: noise
      field: features
      perturb: {kind: numeric_noise, scale: {income: 1.0, debt_ratio: 0.02}, seed: 7}
evaluators:
  - {type: metamorphic_relation, relation: same_label, transform: noise, field: label, passes_when: flipped}

Ogni caso riceve una copia con rumore a seed fisso sui numeri indicati, e flips_under_noise è la quota di casi la cui etichetta è cambiata. categorical_swap sostituisce valori secondo una mappa dichiarata, e blur, brightness, occlusion e jpeg modificano le immagini. Un regressore usa same_score_within con una tolleranza. Le persone non possono giudicare se il rumore su una riga ne conserva il significato, quindi una perturbazione numerica è dichiarata: il suo tasso è riportato, e una regola su di esso dà INSUFFICIENT_EVIDENCE con transform_declared. Una trasformazione di immagini decide un gate quando le etichette delle persone mostrano che conserva il significato di ogni immagine, come una trasformazione di testo. Il progetto image/ dell'esempio mostra entrambi: una sfocatura verificata dalle sue etichette, il cui tasso di cambi supera un tetto, e una macchia grigia che secondo le etichette a volte nasconde il graffio, la cui regola si astiene.

La ricetta su più seed

Il checkpoint che rilasci viene deciso sulla sua esecuzione, come qualsiasi sistema. Una seconda domanda è se il tuo modo di addestrare sia abbastanza buono: riaddestra il mese prossimo e ottieni un'altra estrazione. Addestra k checkpoint con k seed, esegui ciascuno sulla stessa suite e dai un nome alle esecuzioni:

seeds:
  recipe: loan-model
  checkpoints: {seed_1: latest~4, seed_2: latest~3, seed_3: latest~2, seed_4: latest~1, seed_5: latest}
  rule: {id: recipe_accurate, criterion: correct, min: 0.8}

oloproof seeds seeds.yaml --policy recipe.yaml legge il tasso di successo atteso sui seed, con un intervallo che conta sia i casi della suite sia i seed provati. Nell'esempio cinque seed ottengono dall'85,7% al 90,3%, e la ricetta dà 88,2%, dall'83,2% al 91,9%: PASS rispetto all'80%. L'intervallo è approssimato, quindi la policy richiede allow_approximate_methods: true, altrimenti la risposta è MANUAL_REVIEW. La policy deve contenere almeno una regola; il comando legge il suo livello di confidenza, l'adesione esplicita e le soglie del giudice, e nient'altro. Elenca anche i casi il cui verdetto cambia da un seed all'altro, e --html FILE scrive una pagina offline con ogni caso sotto ogni checkpoint.

Ogni checkpoint conta. Un seed il cui addestramento è fallito viene mantenuto, e ogni caso a cui non ha risposto conta come fallimento per l'estremo inferiore e come successo per quello superiore, quindi allarga l'intervallo. Meno di tre seed danno INSUFFICIENT_EVIDENCE; ne servono circa cinque per decidere qualcosa. Nemmeno un giudice di cui il gate non si fiderebbe decide una ricetta. Ogni checkpoint deve eseguire la stessa suite, con una versione di sistema ciascuno, e una suite che dichiara gruppi viene rifiutata.

Cosa questo non può dirti

• Perturbazioni che nessuno ha dichiarato. Si provano solo le trasformazioni dichiarate, alle dimensioni dichiarate, e un tasso di inversione basso non dice nulla di cambiamenti più grandi o della ricerca di un attaccante.
• Robustezza certificata. Nessun limite viene dimostrato per alcun input; il tasso di inversione è un tasso sui casi della suite.
• Come è stato addestrato il modello. Oloproof non può vedere se i seed sono stati scelti prima di valutare qualsiasi checkpoint, se esecuzioni fallite sono state scartate o se i checkpoint differiscono solo per il seed.
• Un fallimento più raro di circa un seed su k. Se la ricetta fallisce l'addestramento una volta su dieci e nessuno dei cinque seed è fallito, l'intervallo non può saperlo.
• Leakage che il file di addestramento non mostra: quasi duplicati, un'immagine ridimensionata o righe usate per la messa a punto ma escluse dal file.
• Leakage nelle esecuzioni dei seed. oloproof seeds non legge leakage: required; il checkpoint che rilasci passa il gate sulla sua esecuzione, che lo legge.

Ciò che nessuna valutazione può dirti è sulla sua pagina.