FinanceBench arriva in un momento in cui ogni fornitore di AI aziendale sostiene che il proprio sistema possa "rispondere a domande dai tuoi documenti finanziari". Questo articolo di Patronus AI mette a dura prova tali affermazioni utilizzando documenti SEC reali e domande a libro aperto accuratamente curate. I risultati sono una lettura scomoda per chiunque costruisca AI finanziaria.
L'articolo
Islam et al. introducono FinanceBench: A New Benchmark for Financial Question Answering (arXiv:2311.11944), una suite di test composta da 10.231 domande su società quotate in borsa, tratte da documenti SEC reali: rapporti annuali 10-K, rapporti trimestrali 10-Q, rapporti correnti 8-K e trascrizioni degli utili. A differenza dei precedenti dataset di QA finanziario (FinQA, TAT-QA), che presentano tabelle e passaggi pre-estratti, FinanceBench richiede che un sistema recuperi le prove da documenti completi prima di rispondere. Questa è l'ambientazione realistica. Le domande sono progettate per essere fattualmente inequivocabili e, nelle parole degli autori, "uno standard di prestazione minimo".
Il team ha valutato 16 configurazioni che spaziano tra GPT-4-Turbo, Llama2 e Claude2 su quattro strategie di recupero: a libro chiuso (nessun recupero), archivio vettoriale condiviso, archivio vettoriale per documento e prompt a contesto lungo che forniscono l'intera pagina rilevante. Revisori umani hanno analizzato manualmente tutte le 2.400 risposte su 150 casi open-source.
Idee chiave
- Il recupero non è il collo di bottiglia. GPT-4-Turbo, a cui viene fornito il passaggio oracle (la pagina esatta contenente la risposta), raggiunge solo l'85% di precisione. Il prompting a contesto lungo (fornendo automaticamente la pagina giusta) ottiene il 79%. Un recupero perfetto ti fa guadagnare sei punti percentuali.
- Il RAG basato su archivio vettoriale è il vero problema. GPT-4-Turbo con un archivio vettoriale per documento: 50% corretto, 39% rifiutato. Con un archivio vettoriale condiviso tra le società: 19% corretto, 68% rifiutato. Il titolo "tasso di fallimento dell'81%" proviene da questa configurazione con archivio condiviso, la configurazione che la maggior parte delle demo aziendali utilizza effettivamente.
- I modelli falliscono in modo diverso. Llama2 allucina in modo aggressivo (54-70% di risposte errate); GPT-4-Turbo rifiuta (39-68% di risposte rifiutate piuttosto che errate). Entrambe le modalità di fallimento sono inaccettabili in produzione, ma non rappresentano rischi equivalenti.
- Il 66% delle domande richiede ragionamento numerico. Tassi di crescita, margini, variazioni anno su anno. È qui che i modelli commettono più spesso errori: errori di calcolo, confusione di unità, errori di segno.
- Il contesto lungo quasi lo salva. Claude2 a contesto lungo: 76% corretto. GPT-4-Turbo a contesto lungo: 79%. Questi sono i migliori numeri pratici, ottenuti saltando il recupero e fornendo direttamente l'intera pagina rilevante.
- Anche l'oracle perde. Con prove perfette, il soffitto è dell'85%, non del 100%. Il quindici percento dei fallimenti sono puri fallimenti di ragionamento senza alcuna componente di recupero.
Cosa regge e cosa no
Il design del benchmark è solido. Insistere su documenti reali rispetto a frammenti pre-estratti è la scelta metodologica corretta: testa ciò che conta realmente nell'implementazione. La valutazione manuale di 2.400 risposte è costosa e credibile.
Quello che trovo meno convincente è trarre classifiche da n=150. La differenza tra Claude2 a contesto lungo (76%) e GPT-4-Turbo a contesto lungo (79%) è statisticamente irrilevante con quella dimensione del campione, ma l'articolo la presenta come una classifica. Il benchmark completo di 10.231 domande esiste ma non è valutato pubblicamente, il che limita la riproducibilità indipendente.
Il risultato dell'oracle è anche il risultato più importante e meno analizzato. Se i modelli falliscono il 15% delle volte con la pagina corretta in mano, il problema è il ragionamento e l'aritmetica, non il recupero. L'articolo segnala strumenti di calcolo e catena di pensiero come lavoro futuro: quegli esperimenti avrebbero dovuto essere il fulcro di questo articolo, non una nota a piè di pagina.
Il benchmark riconosce anche di puntare a una "prestazione minima": domande su un singolo documento con risposte inequivocabili. Il ragionamento tra documenti, le tendenze pluriennali e i confronti tra società sono esclusi. Gli articoli che citano il numero del 79% per il contesto lungo raramente riporteranno questa precisazione.
Perché è importante per l'AI finanziaria
Il caso d'uso di scrittura differita di Beancount si mappa quasi direttamente sulle modalità di fallimento di FinanceBench. Un agente che recupera una voce di transazione e verifica se l'importo corrisponde a un estratto conto bancario sta eseguendo lo stesso compito di recupero e poi aritmetica misurato da questo benchmark. Il soffitto dell'oracle (85% anche con un contesto perfetto) è il vincolo di progettazione rilevante: anche se l'agente trova la voce di libro mastro corretta, esiste una probabilità reale che sbagli il confronto, confonda il segno o legga male le unità.
La divisione del fallimento tra Llama2 e GPT-4 è importante per l'architettura dell'agente. Un rifiuto è recuperabile (indirizzalo a una revisione umana); un abbinamento allucinato registrato nel libro mastro non lo è. Questo argomenta a favore di un comportamento di rifiuto conservativo rispetto all'allucinazione fiduciosa, anche a costo di un tasso di successo apparente inferiore.
Il vantaggio del contesto lungo (79% contro 50%) è praticamente frustrante per le applicazioni di libro mastro. I file Beancount pluriennali sono troppo grandi per essere forniti per intero. Risolvere il recupero su documenti numerici densi, non solo il recupero di testo, rimane un problema aperto.
Cosa leggere dopo
- FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122) — il benchmark precursore che FinanceBench migliora esplicitamente; utile per capire cosa il campo aveva capito bene prima che fosse richiesto il recupero da documenti reali.
- DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024) — estende FinanceBench con domande multi-hop più difficili che richiedono ragionamento trasversale all'interno di un singolo documento.
- PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — scarica l'aritmetica su un interprete Python, affrontando direttamente il 66% delle domande di FinanceBench che falliscono sul ragionamento numerico.