Una modifica, dall'inizio alla fine

Il vostro punteggio è salito dopo una modifica. Questa pagina segue una modifica reale attraverso ogni domanda che Oloproof pone prima di lasciarla andare in produzione: il giudice è affidabile, la modifica raggiunge la soglia da sola, è migliore di ciò che sostituisce secondo il giudice e secondo le persone, e che cosa provare dopo. Il sistema è un piccolo bot di supporto che risponde a partire da 40 documenti, eseguito sulla vostra macchina con modelli locali; ogni numero qui sotto è quello che il motore ha stampato. Copiatelo da examples/one_change ed eseguite REVIEWER=yourname ./run_demo.sh.

La modifica

Il prompt di riferimento chiede al bot di mantenere esatti cifre, nomi e unità. Il candidato chiede una o due frasi calde e naturali. Entrambi vengono eseguiti sulle stesse 120 domande, con un controllo deterministico (answer_correct: la risposta contiene il fatto atteso?) e un giudice su modello locale (judge_correct: risponde con lo stesso fatto?):

oloproof run --policy release.yaml
oloproof run --config candidate.yaml --policy release.yaml

Le risposte corrette sono passate dall'80.0% all'82.5%, il tasso di superamento del giudice dall'82.5% all'83.3%. Questo è il miglioramento apparente. Nessuna delle due esecuzioni decide ancora nulla: la regola di rilascio legge il giudice, e il giudice non è stato verificato, quindi la regola dice INSUFFICIENT_EVIDENCE con evaluator_not_validated.

Ci si può fidare del giudice?

Delle persone etichettano un campione casuale cieco delle risposte del candidato, senza il verdetto del giudice, e il motore misura il giudice rispetto a loro:

oloproof review CANDIDATE --criterion judge_correct --by you

Nella sessione registrata il giudice ha concordato su 77 dei 79 casi etichettati (97.5%, estremo inferiore 91.2%) con una distorsione di -2.5 punti, entro le soglie predefinite (accordo 0.70, distorsione 0.35), quindi è stato convalidato e può decidere. In quella sessione le etichette sono state date da un agente al posto di un revisore, il che mostra il flusso di lavoro e non è il giudizio di una persona; quando lo eseguite voi, il revisore siete voi.

Il candidato raggiunge la soglia da solo?

release.yaml chiede un tasso di superamento del giudice di almeno l'80%:

oloproof gate CANDIDATE --policy release.yaml --config candidate.yaml

83.3% con un intervallo da 75.4% a 89.6% sta a cavallo dell'80%, quindi la regola è INSUFFICIENT_EVIDENCE, e il motore dice che circa 592 casi la deciderebbero. Un giudice affidabile non rende chiaro un risultato incerto.

È migliore del riferimento?

compare.yaml pone due domande. Il candidato è migliore secondo il giudice, risultato tenuto solo se le persone mostrano che il giudice sbaglia allo stesso modo su entrambi i prompt (judge_bias_bar: 0.10)? E secondo le etichette delle persone stesse su entrambe le risposte agli stessi casi (people_pass_diff, una metrica human_difference), non è peggiore di oltre 10 punti?

oloproof review CANDIDATE --against BASELINE --criterion judge_correct --by you --sample 40
oloproof compare CANDIDATE BASELINE --policy compare.yaml --config candidate.yaml

La revisione mostra entrambe le risposte come A e B, in un ordine stabilito a testa o croce, senza nominare le esecuzioni. Nella sessione registrata la differenza del giudice era di +0.8 punti (da -5.1 a +7.3): INSUFFICIENT_EVIDENCE, e servirebbero circa 3,690 casi appaiati per deciderla. Le persone hanno promosso il candidato 36 volte e il riferimento 35 volte su 40 coppie: +2.5 punti (da -11.1 a +17.7), quindi anche "non peggiore di 10 punti" era INSUFFICIENT_EVIDENCE. Il gate ha bloccato. La modifica era di stile e i punteggi l'hanno appena notata, e 120 casi non distinguono una modifica di 1 punto da nessuna modifica.

Perché fallisce dove fallisce?

oloproof diagnose CANDIDATE --intervention gold-context --criterion answer_correct --config candidate.yaml

Il motore ha rieseguito i 21 fallimenti passando al modello il brano giusto, e di nuovo senza come controllo. Il controllo non ne ha recuperato nessuno; il brano giusto ne ha recuperati 14: 7 in cui il recupero non aveva mai trovato il brano, 7 in cui era stato trovato ma classificato sotto i primi 3, e 7 falliti comunque. Ha proposto un top_k più profondo come ipotesi, poi l'ha verificata sugli stessi casi:

oloproof diagnose CANDIDATE --intervention top-k --top-k 8 --criterion answer_correct --config candidate.yaml

Tutti i 7 casi esclusi dalla classifica sono stati recuperati, con un controllo che non ne ha recuperato nessuno.

Il seguito

followup.yaml è il candidato con top_k: 8, una nuova versione del sistema eseguita per intero:

oloproof run --config followup.yaml --policy release.yaml
oloproof compare FOLLOWUP CANDIDATE --policy followup_compare.yaml --config followup.yaml

Il suo tasso di superamento del giudice era del 90.0% (da 83.1% a 94.8%), quindi la soglia minima dell'80% era PASS. Rispetto al candidato, più risposte corrette (+3.3 punti) era ancora INSUFFICIENT_EVIDENCE, e il tasso di superamento del giudice non peggiore di oltre 5 punti era PASS. Il giudice è stato verificato sulle risposte del candidato, non su quelle del seguito, e nessuno ha etichettato una coppia del seguito, quindi lì la differenza delle persone non decide nulla.

Che cosa questo non può dirvi

Un piccolo bot, una modifica, 120 casi e modelli locali. Mostra come il motore arriva a ogni decisione su una modifica reale; non dice nulla su un altro sistema. Un campione locale è in buona fede: solo un campione estratto da un workspace viene verificato lì. Il registro completo, con ogni id di esecuzione, è docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md. Vedete Giudici, Regole di confronto, Valutazione RAG e Che cosa una valutazione non può dirvi.