Benchmark e quality gate
Perché serve un golden dataset
La qualità non può essere valutata osservando alcuni output o modificando iterativamente il prompt. Serve un corpus stabile, annotato manualmente, sul quale confrontare regole, prompt, modelli API e modelli self-hosted.
Composizione del corpus
La prima versione deve includere almeno 5–10 Topic Horizon rappresentativi e documenti di tipo diverso:
- Topic Page;
- Work Programme;
- General Annex;
- Application Template;
- Evaluation Form;
- FAQ e Programme Guide;
- almeno un Corrigendum.
Il corpus deve contenere sia casi positivi sia hard negative:
- obblighi espliciti;
- condizioni implicite;
- requisiti distribuiti su più paragrafi;
- elenchi e tabelle;
- expected outcome;
- policy objective;
- narrativa di contesto;
- definizioni;
- esempi;
- frasi con termini normativi riferiti a soggetti diversi dal proponente.
Annotazione
Per ogni candidato vengono registrati:
- classe attesa;
- decisione admit/reject;
- reason code;
- span sorgente;
- atom attesi;
- actor, action e object;
- strength;
- criterio eventualmente associato;
- annotatore e revisore;
- eventuale disaccordo.
I casi controversi richiedono adjudication e non devono essere forzati arbitrariamente in una classe.
Metriche
| Metrica | Gate iniziale |
|---|---|
| Precision sui requirement | ≥ 95% |
| Recall sui mandatory | ≥ 95% |
| Recall complessivo | ≥ 90% |
| Citazioni sorgente valide | 100% |
| Accuratezza requirement/context | ≥ 95% |
| Atomicizzazione corretta | ≥ 90% |
| Duplicati residui | < 3% |
La precisione ha priorità sul recall generale perché un falso requisito inquina coverage, assegnazioni, testo finale e scoring. Il recall dei mandatory deve invece restare molto alto.
Evaluation harness
Il runner deve:
- caricare fixture e annotazioni versionate;
- eseguire una configurazione di pipeline;
- confrontare candidate, classi, span e atom;
- produrre confusion matrix e lista degli errori;
- separare risultati per documento e classe;
- registrare modello, prompt, quantizzazione, temperatura e latenza;
- confrontare il risultato con la baseline precedente;
- fallire CI quando un gate obbligatorio regredisce.
Versionamento
Ogni report deve essere legato a:
dataset version
pipeline version
prompt version
model profile e model version
parser version
runtime configuration
Un nuovo modello o prompt non viene promosso perché ottiene uno score medio migliore: deve rispettare tutti i gate critici e non introdurre regressioni sui mandatory.
Feedback operativo
Le decisioni HUMAN_ACCEPTED e HUMAN_REJECTED raccolte durante l'uso diventano candidate per il dataset successivo. L'ingresso nel golden dataset richiede comunque una revisione, per evitare di apprendere errori o preferenze incoerenti di un singolo utente.