RAG sui bilanci: perché il chunking testuale fallisce sui documenti finanziari
Un modello che «legge» un bilancio non sbaglia perché non conosce l'italiano: sbaglia perché recupera il contesto sbagliato. In un sistema RAG (retrieval-augmented generation) applicato ai documenti finanziari il collo di bottiglia è il retrieval, non la generazione.
Il documento finanziario non è prosa
Un fascicolo di bilancio è un oggetto strutturato. Stato patrimoniale, conto economico, rendiconto finanziario e nota integrativa hanno semantiche diverse e molti rimandi incrociati: una voce numerica ha senso solo insieme al criterio di valutazione, che spesso si trova altrove. Un deposito in formato XBRL può contenere migliaia di fatti taggati, ciascuno con il suo contesto (entità, periodo, unità, segno).
Il chunking ingenuo a finestra fissa (i classici blocchi da 512–1024 token) ignora tutto questo: spezza le tabelle a metà, separa un importo dalla nota che lo qualifica e mescola periodi diversi. Il risultato è un contesto sintatticamente valido e semanticamente falso.
Perché il ragionamento numerico resta il punto debole
I benchmark accademici sul question answering finanziario lo mostrano da anni: FinQA (Chen et al., 2021) e TAT-QA (Zhu et al., 2021) richiedono ragionamento numerico multi-step su report reali, combinando testo e tabelle, ed è proprio lì che i modelli cedono. Recuperare la frase giusta è relativamente facile; comporre correttamente più numeri presi da celle diverse, molto meno.
La forma più insidiosa di errore non è l'invenzione pura, ma l'allucinazione ancorata: una cifra plausibile, presa però dalla riga sbagliata o dall'esercizio precedente. In revisione è il tipo di errore peggiore, perché supera il controllo di buon senso.
Un'architettura consapevole della struttura
La direzione giusta non è un prompt migliore, ma una pipeline che rispetti il documento:
- Parsing strutturale: dove esiste l'XBRL, usarlo come ground-truth (mappa voce → valore → contesto); sui PDF, layout/table parsing che preservi intestazioni di riga e colonna come unità atomiche.
- Retrieval ibrido: recupero denso (embedding) sui concetti, lessicale (BM25) su codici e denominazioni di voce, con i metadati (anno, entità, sezione) usati come filtri duri, non come suggerimenti.
- Re-ranking e citazione obbligatoria: ogni numero in output deve puntare alla cella sorgente; senza puntatore, non si scrive.
- Separare il fatto dal commento: il valore non lo «genera» il modello, lo cita; la prosa generativa interpreta, non produce le cifre.
Misurare la fedeltà, non la fluidità
La metrica giusta non è quanto suona bene la risposta, ma quanto è ancorata ai dati: faithfulness/groundedness (con framework come RAGAS), quota di affermazioni con citazione verificabile e, soprattutto, tasso di astensione corretta. Un sistema che davanti a un dato non ricavabile risponde «non determinabile dai documenti» vale più di uno sempre sicuro e a volte sbagliato.
- Il problema del RAG sui bilanci è il retrieval, non la generazione.
- Il chunking deve seguire la struttura del documento (XBRL/tabelle), non la lunghezza in token.
- I numeri si citano dalla cella sorgente; non si lasciano scrivere al modello.
- Si valuta la fedeltà e l'astensione corretta, non la scorrevolezza.
Riferimenti
- Chen et al., FinQA: A Dataset of Numerical Reasoning over Financial Data, EMNLP 2021.
- Zhu et al., TAT-QA: A Question Answering Benchmark on a Hybrid of Tabular and Textual Content in Finance, ACL 2021.
- Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, 2023.
- XBRL Italia — tassonomia dei bilanci (it.xbrl.org).