Classificazione documenti in C# senza AI: approccio deterministico, spiegabile e pronto per la produzione

Classificare automaticamente i documenti aziendali è uno di quei problemi che, a prima vista, sembra un caso d’uso ideale per i modelli AI. Ma in ambienti di produzione, la stabilità, la tracciabilità e la prevedibilità del comportamento spesso contano più della flessibilità. In questo articolo vediamo come implementare un classificatore di documenti rule-based, ponderato e completamente spiegabile in C# .NET, senza toccare un singolo modello di machine learning.

Perché non partire dall’AI?

I modelli AI per la classificazione di testo sono potenti, ma introducono una serie di criticità in contesti enterprise:

• Non-determinismo: lo stesso documento può ricevere classificazioni diverse a seconda della versione del modello, del wording del prompt o di aggiornamenti interni del provider.
• Opacità: spiegare a un responsabile compliance perché il modello ha classificato un contratto come “fattura” è praticamente impossibile.
• Dipendenza da pipeline di dati: aggiornare il classificatore richiede raccolta di dati, rietichettatura, riaddestramento e deployment.

Un approccio deterministico e rule-based risolve tutti e tre i problemi: stesso input, stesso output, sempre. Ogni decisione è tracciabile e modificabile senza toccare il codice, solo aggiornando un file di configurazione JSON.

Architettura del classificatore

Il sistema segue una pipeline chiara:

1. Caricamento dei profili di classificazione da file JSON
2. Apertura del documento .docx con TX Text Control
3. Estrazione del testo da corpo, intestazioni e piè di pagina
4. Rilevamento delle regioni strutturali (titolo, heading, corpo, header, footer)
5. Matching delle regole per categoria con strategie configurabili
6. Calcolo degli score ponderati per categoria
7. Restituzione della categoria vincente con confidence score e spiegazione dettagliata

L’elemento chiave è che tutta la logica di classificazione vive nel file JSON, non nel codice. Questo significa che un domain expert (non un developer) può modificare e migliorare il classificatore semplicemente editando la configurazione.

Il file di configurazione

Ogni categoria è descritta da un insieme di regole. Ogni regola specifica:

• term: il termine o la frase da cercare
• weight: il peso del contributo di questa regola allo score
• matchMode: la strategia di matching (Phrase, WholeWord, Contains)
• strength: la forza del segnale (Strong, Weak)

Esempio per la categoria “Resume”:

{
  "name": "Resume",
  "rules": [
    {
      "term": "work experience",
      "weight": 3.0,
      "matchMode": "Phrase",
      "strength": "Strong"
    },
    {
      "term": "email",
      "weight": 1.0,
      "matchMode": "WholeWord",
      "strength": "Weak"
    }
  ]
}

La distinzione tra segnali forti e deboli è cruciale. “Work experience” in un documento è un indicatore molto specifico di un CV, mentre “email” può apparire praticamente ovunque e deve pesare di meno. Questa granularità evita i falsi positivi che affliggono i classifier naïve basati su semplice keyword counting.

Estrazione strutturata con TX Text Control

Il classificatore non tratta il documento come un blocco di testo piatto. Usando TX Text Control .NET Server, estrae il contenuto per regioni strutturali:

using var textControl = new ServerTextControl();
textControl.Create();
textControl.Load(docxPath, StreamType.WordprocessingML);

Vengono estratti separatamente:

• textControl.Paragraphs → testo del corpo
• textControl.Sections → HeadersAndFooters → intestazioni e piè di pagina di ogni sezione

Questa distinzione è fondamentale: nelle fatture, i termini identificativi come “FATTURA N.” appaiono tipicamente all’inizio del documento o nel titolo. Nei report, il tipo di documento è spesso incorporato nell’header. Ignorare queste regioni significherebbe perdere segnali classificatori di primo livello.

Structure Awareness: non tutto il testo vale uguale

Il miglioramento più significativo rispetto al semplice keyword matching è la consapevolezza della struttura. Il classificatore assegna pesi diversi agli stessi termini a seconda della regione in cui appaiono:

• Un termine nel titolo del documento ha peso massimo: è quasi certamente indicativo del tipo di documento
• Un termine in un heading H1/H2 ha peso alto
• Lo stesso termine nel corpo del documento ha peso standard
• Nel footer (tipicamente template boilerplate) il peso è ridotto

Questo approccio riflette come un essere umano leggerebbe effettivamente il documento: prima si guarda il titolo, poi le intestazioni principali, infine il corpo.

Scoring, confidence e spiegabilità

Al termine dell’analisi, il sistema restituisce non solo la categoria vincente, ma anche:

• Il confidence score (rapporto tra lo score della categoria vincente e la somma degli score di tutte le categorie)
• Una spiegazione dettagliata: quali regole hanno fatto match, in quale regione, con quale peso

Questa tracciabilità è essenziale per scenari di audit e compliance. Se un documento viene classificato erroneamente, il problema è sempre identificabile e correggibile: si modifica la regola nel JSON e si riclassifica. Nessun riaddestramento, nessuna nuova pipeline di dati.

Quando usare questo approccio (e quando no)

L’approccio deterministico è ottimale quando:

• Il set di categorie è definito e stabile (fatture, contratti, report, CV, ecc.)
• La compliance e l’auditability sono requisiti primari
• Il volume di documenti è alto e la velocità di classificazione è critica
• Non si dispone di dataset etichettati sufficienti per addestrare un modello

Dove l’AI rimane superiore è nei casi con categorie ambigue, linguaggio naturale molto variabile, o quando il set di categorie evolve rapidamente e non si vuole aggiornare manualmente le regole. Un’architettura ibrida – classificazione rule-based come primo filtro, AI solo per i casi borderline – è spesso la soluzione migliore in produzione.

Conclusione

La classificazione documentale senza AI non è un’alternativa di ripiego: è una scelta ingegneristica deliberata per sistemi che richiedono stabilità, spiegabilità e controllo. Il pattern rule-based, ponderato e configuration-driven descritto in questo articolo è già in uso in ambienti di produzione enterprise e offre vantaggi concreti in termini di manutenibilità e trasparenza.

Se il vostro stack include la gestione di documenti .docx in C#, questo approccio vale la pena di essere valutato prima di introdurre la complessità di un modello ML.

Fonte: Document Classification Without AI: Deterministic, Explainable, and Built for Production in C# .NET – Bjoern Meyer, TX Text Control Blog