Skip to main content

Pipeline di identificazione ed estrazione

Limiti dell'AS IS​

L'implementazione corrente combina regole normative e un'unica estrazione LLM. I falsi positivi possono nascere perché termini come must, should, expected to, proposal o impact compaiono anche in testo narrativo. Inoltre classificazione, atomicizzazione, associazione ai criteri ed evidenze attese vengono richieste nello stesso passaggio.

La pipeline target separa i compiti per rendere ogni decisione osservabile e valutabile.

Passo 1 — Candidate generation​

La generazione dei candidati privilegia il recall. Le sorgenti sono:

  • regole sul linguaggio normativo;
  • forma imperativa;
  • elenchi puntati e numerati;
  • righe di tabelle;
  • sezioni di eligibility e admissibility;
  • application template;
  • evaluation form;
  • generazione candidati tramite LLM.

Ogni candidato conserva documento, sezione, heading, pagina, ordine di lettura e contesto precedente/successivo. In questa fase nessun candidato è ancora un requisito definitivo.

Passo 2 — Classificazione semantica​

Un classificatore assegna una delle classi definite nel modello Requirement Atom. Il risultato include confidence e motivazione codificata. Le classi negative devono essere persistite per audit, benchmark e miglioramento futuro.

Passo 3 — Admission gate​

Un secondo controllo indipendente decide se ammettere il candidato:

{
  "admit": false,
  "reasonCode": "POLICY_OBJECTIVE_ONLY",
  "actor": null,
  "requiredAction": null,
  "verifiableCondition": null,
  "supportingQuote": "citazione esatta",
  "confidence": 0.97
}

Reason code iniziali:

  • NO_APPLICANT_ACTION;
  • POLICY_OBJECTIVE_ONLY;
  • CONTEXT_ONLY;
  • DEFINITION_ONLY;
  • EXAMPLE_ONLY;
  • EXPECTED_OUTCOME_ONLY;
  • INCOMPLETE_FRAGMENT;
  • SOURCE_NOT_GROUNDED;
  • DUPLICATE;
  • AMBIGUOUS.

Il gate viene applicato al testo candidato, non alla concatenazione indiscriminata di tutto il contesto.

Passo 4 — Atomicizzazione​

Solo i candidati ammessi vengono scomposti. Il modello deve restituire actor, action, object, condizioni, qualificatori e segnali di accettazione. Ogni atom conserva la citazione originale e il legame con il candidato padre.

Passo 5 — Validazione strutturale​

La validazione rifiuta output che non rispettano tutte le condizioni:

  • citazione esatta non vuota;
  • identificativo sorgente esistente;
  • citazione contenuta nella sorgente normalizzata;
  • actor e action valorizzati;
  • classe ammessa;
  • strength valida;
  • confidence numerica;
  • nessun riferimento inventato;
  • nessun fallback esterno contrario alla data policy.

Passo 6 — Consolidamento​

Gli atom validi vengono confrontati semanticamente tra documenti. Corrigendum e documenti specifici hanno precedenza sulle regole generali. Duplicati, specializzazioni e conflitti sono registrati esplicitamente.

Passo 7 — Revisione umana​

La UI deve mostrare fianco a fianco:

  • candidato e contesto;
  • classe proposta;
  • atom generati;
  • citazioni;
  • motivazione di ammissione o rifiuto;
  • confidence;
  • eventuali conflitti.

Le correzioni umane alimentano il golden dataset, ma non modificano retroattivamente una versione pubblicata del Call Package.

Pubblicazione​

Un Call Package è pubblicabile solo quando:

  • non contiene requirement senza fonte valida;
  • tutti i mandatory a bassa confidence sono revisionati;
  • i conflitti bloccanti sono risolti;
  • il benchmark della pipeline versionata supera i quality gate;
  • versione del prompt, modello e configurazione sono registrati.