FinDER (arXiv:2504.15800) è un benchmark di recupero costruito attorno a un'osservazione semplice ma sottovalutata: le query che i professionisti finanziari reali digitano non assomigliano alle domande curate dei benchmark accademici. Lo sto leggendo perché si trova all'intersezione di due filoni che sto seguendo — il divario di recupero nell'AI finanziaria e il problema del realismo pratico che DocFinQA e FinanceBench hanno iniziato a evidenziare.
L'articolo
Chanyeol Choi, Jihoon Kwon e colleghi di una società di AI finanziaria presentano un dataset di 5.703 triplette query–prova–risposta annotate da esperti, raccolte da un servizio reale di domande e risposte di analisti di hedge fund. I documenti sono moduli 10-K di 490 società S&P 500, recuperati da SEC EDGAR. Ciò che distingue FinDER dai benchmark precedenti è il lato delle query: l'89,86% delle query contiene tre o più abbreviazioni o acronimi specifici del dominio. Invece di "Qual è il ricavo totale di Società X per l'anno fiscale 2023?", un analista reale potrebbe digitare "GOOGL 10-K FY23 revs breakdown by segment." Il dataset è stato pubblicato al Workshop ICLR 2025 su Advances in Financial AI e successivamente è apparso a ICAIF 2025.
Idee chiave
- Il recall di recupero è sorprendentemente basso in generale: E5-Mistral (miglior retriever denso) raggiunge solo il 25,95% di recall contestuale complessivo; BM25 arriva all'11,68%. La categoria "Financials" — quella più direttamente rilevante per la contabilità — è la più difficile: rispettivamente 15,84% e 6,42%.
- La sola ambiguità delle query costa 8,2 punti di precisione: Testando E5-Mistral su 500 query, gli autori confrontano parafrasi ben formate (precisione 33,9) con le query abbreviate reali (precisione 25,7). Il divario è interamente attribuibile alla gestione di abbreviazioni/acronimi, non alla complessità dei documenti.
- La qualità del recupero è il collo di bottiglia dominante per la generazione: Gli LLM senza contesto ottengono punteggi vicini allo zero (9–10% di risposte corrette); con i primi 10 passaggi recuperati raggiungono il 29–34%; con contesto oracolo perfetto salgono al 60–68%. Questo divario di 35 punti tra condizioni realistiche e oracolo è più ampio del divario tra modelli open-source e modelli di frontiera.
- L'aritmetica composizionale fallisce anche con un buon recupero: I compiti di calcolo multi-fase (query composizionali) raggiungono solo ~20% di correttezza su tutti e quattro i modelli — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill e Qwen-QWQ — anche con i primi 10 passaggi recuperati. GPT-o1 guida i compiti di moltiplicazione al 42,90% ma scende al 27,78% sulla divisione.
- Il ri-ranking LLM aggiunge un miglioramento modesto ma costante: Lasciando che i modelli riordinino i primi 10 risultati di E5-Mistral prima di rispondere, Claude-3.7-Sonnet raggiunge un F1 di 63,05 e GPT-o1 arriva a 62,90. Deepseek-R1-Distill resta indietro a 60,01, nonostante le buone prestazioni nel ragionamento strutturato altrove.
- La difficoltà per categoria è disomogenea: Le query sui rischi sono le più facili da recuperare (E5-Mistral: recall 33,07); le Financials restano le più difficili (15,84). Questo è correlato alla struttura delle query — le divulgazioni sui rischi usano prosa in linguaggio naturale, le tabelle finanziarie usano notazione numerica densa.
Cosa regge — e cosa no
Il contributo centrale è solido: questa è una distribuzione reale di query da analisti in attività e il problema delle abbreviazioni è genuino. Qualsiasi benchmark costruito da Wikipedia o crowdsourcing stile FinQA perde questo aspetto. La struttura di valutazione a tre livelli — nessun contesto, recupero realistico, contesto oracolo — è il design giusto; separa chiaramente la qualità del recupero dalla qualità del ragionamento e mostra il divario residuo di generazione (ancora ~32–34% di fallimento anche con contesto perfetto nelle domande qualitative).
Dove l'articolo è più debole è la riproducibilità. Al momento della pubblicazione, il dataset non era disponibile pubblicamente — gli autori dichiarano di "pianificarne il rilascio pubblico in un secondo momento." Questo è un problema significativo per un articolo di workshop che si presenta come standard di valutazione. I benchmark che non vengono rilasciati non sono benchmark; sono casi di studio. Da allora è apparso a ICAIF 2025, quindi il rilascio potrebbe essere avvenuto, ma la versione arXiv non lo conferma.
Anche la valutazione del recupero usa solo quattro modelli a singolo stadio (BM25, GTE, mE5, E5-Mistral). Non c'è recupero ibrido, nessuna espansione di query, nessun HyDE, nessun passo di riscrittura mirato specificamente al problema delle abbreviazioni. Dato che gli autori hanno caratterizzato precisamente il divario delle abbreviazioni, è sorprendente che non testino la soluzione ovvia: espandere la query ("GOOGL" → "Alphabet Inc.") prima del recupero. Quell'esperimento è assente.
I risultati di generazione meritano una lettura più attenta. La performance senza contesto di ~9–10% non è un limite inferiore utile — è essenzialmente zero — ma il tetto dell'oracolo al 60–68% è più informativo di quanto sembri. Anche con il passaggio corretto in mano, i migliori modelli falliscono su circa un terzo delle domande qualitative e su quattro quinti dell'aritmetica composizionale. Quel tetto conta: significa che il solo recupero non può risolvere il problema.
Perché questo conta per l'AI finanziaria
La distribuzione delle query in FinDER si mappa bene su come gli utenti di Beancount interagiscono effettivamente con un agente di ledger. Un utente che mantiene i propri conti da anni digiterà query abbreviate e contestuali — "AMZN card Q3 rimb?" piuttosto che "Quali sono i rimborsi della carta Amazon nel Q3?" I modelli di embedding standard falliranno nel recuperare le voci giuste perché sono stati addestrati su testo pulito in linguaggio naturale. Il calo di 8,2 punti di precisione da query pulite a query reali è probabilmente conservativo per un dominio di ledger personale, dove la stenografia idiosincratica ("spese gestione prop." per "spese di gestione proprietà") è ancora più lontana dai dati di addestramento rispetto alle abbreviazioni standard SEC.
Il tetto di recall contestuale del 25,95% su E5-Mistral è una funzione forzante: qualsiasi pipeline RAG Beancount deve prevedere una grande frazione di prove mancate. Un'implicazione è che il re-recupero ad alta recall (passaggi multipli, formulazioni di query diversificate) conta più che spingere l'F1 su un singolo passaggio. Un'altra è che la normalizzazione delle query — mappare la stenografia dell'utente a nomi di conto canonici prima del recupero — dovrebbe essere un passo di preelaborazione esplicito, non lasciato al modello di embedding.
L'accuratezza del 20% sull'aritmetica composizionale anche con contesto oracolo è un segnale separato: per i compiti di calcolo Beancount, il collo di bottiglia della generazione è il ragionamento, non il recupero. Lo scarico stile PAL (generare aritmetica in Python piuttosto che calcolo in testo libero) rimane la risposta giusta per i compiti numerici indipendentemente da quanto buono diventi il recupero.
Cosa leggere dopo
- Fin-RATE (arXiv:2602.07294) — il benchmark complementare per il tracciamento multi-periodo sui documenti SEC; l'accuratezza cala del 18,60% sui compiti temporali, che è il problema del ledger Beancount pluriennale dichiarato direttamente.
- IRCoT (arXiv:2212.10509, ACL 2023) — interleaving di recupero e ragionamento a catena di pensiero; la struttura di recupero multi-passaggio affronta direttamente il basso recall a passaggio singolo che FinDER espone.
- Espansione di query con LLM per recupero specifico di dominio — nessun singolo articolo di benchmark copre ancora bene questo aspetto, ma il divario delle abbreviazioni FinDER lo rende una priorità di ricerca di primo ordine; cercare "HyDE financial domain" e "query expansion SEC filings 2025" è il punto di partenza giusto.