Guida pratica a uno studio di fattibilità riproducibile

Passo 1: scrivi una sola domanda

Uno studio di fattibilità risponde a una domanda, formulata in modo che la risposta si possa misurare:

• Troppo vaga: "L'IA può gestire le nostre pratiche?"
• Misurabile (esempio): "Possiamo estrarre fornitore, data, imponibile, IVA e totale dai nostri 5 formati di fattura più comuni, con meno di 1 documento su 20 da correggere a mano?"

La versione misurabile dice quali dati servono e quando hai finito. Scrivila in cima al documento dello studio, con la data. Se la domanda cambia, aggiungi la nuova versione sotto invece di modificare la vecchia.

Passo 2: fissa presto il materiale di prova, e tienilo separato

Decidi su cosa giudicherai il risultato, idealmente prima di costruire, e tienilo separato:

• un set di sviluppo che puoi guardare mentre costruisci;
• un set di verifica che non guardi fino alla fine.

La nostra demo doc2data mostra sia il valore sia i limiti di questo. Sulle scansioni degradate sintetiche, il set usato durante lo sviluppo di una correzione dell'inclinazione ha ottenuto 131 campi corretti su 141 (92,9%). Un set separato che, secondo il registro dello sviluppatore, non è stato guardato durante quella correzione ha ottenuto 127 su 139 (91,4%). Due avvertenze:

• Entrambi i set vengono dalle stesse famiglie di formati generati, quindi non dicono nulla su formati di fornitori mai visti.
• Questi piccoli set sintetici non stabiliscono una differenza affidabile nelle prestazioni generali; non è stata eseguita un'analisi che tenga conto del raggruppamento dei campi per documento. Lo scarto di 1,5 punti non misura una "perdita di generalizzazione".

Non tutti i nostri set erano veri set di verifica: il terzo set pulito faceva parte dei test automatici (soglia 95%) per tutto lo sviluppo. I risultati su materiale che ha influenzato lo sviluppo possono essere distorti in senso ottimistico, ed è per questo che la separazione conta.

Quando i dati reali sono sensibili, un set sintetico è un modo ragionevole per provare il flusso. Basta dire chiaramente che non misura la precisione su documenti reali.

Passo 3: misura un riferimento

Un risultato ha bisogno di un confronto. Il riferimento è la cosa più semplice che potrebbe funzionare: regole semplici o il processo manuale attuale per l'estrazione da documenti; per un modello, un predittore banale (sempre la classe più frequente) e un metodo standard. Se il nuovo approccio non batte il riferimento di un margine che conta, è un risultato utile.

Passo 4: fissa la soglia in anticipo

Decidi prima di vedere i risultati cosa conta come successo e come fallimento. Esempi:

• una soglia: "almeno il 90% dei campi corretti sul set di verifica";
• una regola di arresto: "se la recall (sensibilità) resta sotto il 90% dopo due cicli di miglioramento, ci si ferma";
• un limite di tempo: "ogni documento deve richiedere meno di N secondi su un normale computer d'ufficio".

Fissare l'asticella dopo aver visto i risultati rende facile ingannare se stessi. Nei confronti tra modelli la stessa idea si chiama regione di equivalenza pratica, decisa in anticipo (vedi Una divisione fortunata).

Passo 5: rendi l'esecuzione ripetibile

Il minimo da registrare:

• Codice sotto controllo di versione, con il commit esatto dietro ogni numero riportato.
• Seed casuali fissi, con le impostazioni in un file di configurazione.
• Versioni del software bloccate, ad esempio in un container (noi usiamo Docker), per poter ricostruire l'ambiente.
• Risultati grezzi conservati: ogni risultato per documento o per fold, così i numeri di sintesi si possono ricondurre all'origine.
• Test automatici, perché le modifiche successive non rompano in silenzio il comportamento misurato.
• La piattaforma usata. Nei nostri test OCR, i risultati sulle scansioni degradate variavano leggermente tra Windows e Linux. Riportiamo come riferimento i numeri del container e segnaliamo la differenza.

La guida di The Turing Way alla ricerca riproducibile tratta queste pratiche in profondità.

Passo 6: riporta con onestà, compreso ciò che è fallito

Un report di fattibilità può essere breve:

1. La domanda, come scritta al passo 1.
2. Il materiale: cos'era, la fonte, se sintetico o reale, cosa è stato tenuto da parte e quando.
3. Il metodo e il riferimento.
4. I risultati, con la data, rispetto alla soglia fissata prima, con i denominatori.
5. I fallimenti: cosa è andato storto, quanto spesso e perché, se si sa.
6. I limiti: cosa lo studio non dimostra.
7. La raccomandazione: sviluppare, cambiare la domanda o fermarsi.

Ogni affermazione ha fonte e data, ogni numero viene da codice effettivamente eseguito, e le ipotesi sono indicate come tali.

Cosa non è uno studio di fattibilità

• Non è un prototipo per la produzione. Le scorciatoie vanno bene, se documentate.
• Non è una garanzia. Riduce l'incertezza su una domanda.
• Non è una validazione regolatoria o clinica. Può supportare la persona qualificata che la firma; non può sostituirla.

Come possiamo aiutarti

Offriamo piccoli studi di fattibilità riproducibili, documentati in report che puoi condividere e rieseguire: software di ricerca, rassegne della letteratura e documentazione tecnica. Descrivi la tua domanda in poche righe. Verifica di fattibilità gratuita

Fonti

• Report di valutazione sintetici di doc2data (set degradati di sviluppo e di verifica, conteggi dei campi), 2 ottobre 2026, commit e4bfc58, ricontrollati alla 708168d; registro dello sviluppatore per la cronologia del set di verifica. Risultati pubblicati con denominatori e limiti: evidenze dei test di doc2data.
• Revisione statistica di questi numeri da parte di company-senior-researcher, 3 ottobre 2026 (interna).
• README di Bayesian-Classifier-Lab (divisioni con seed, file di configurazione, registro dell'esecuzione), https://github.com/Foysal-A-Al/Bayesian-Classifier-Lab (consultato il 2 ottobre 2026).
• The Turing Way Community, The Turing Way, "Guide for Reproducible Research", https://book.the-turing-way.org/reproducible-research/reproducible-research (consultato il 3 ottobre 2026).