FinanceBench : Pourquoi le RAG avec base de données vectorielle échoue sur les documents financiers réels

FinanceBench arrive à un moment où chaque fournisseur d'IA d'entreprise prétend que son système peut « répondre à des questions à partir de vos documents financiers ». Ce document de Patronus AI met ces affirmations à rude épreuve en utilisant des documents réels de la SEC et des questions à livre ouvert soigneusement sélectionnées. Les résultats sont une lecture inconfortable pour quiconque développe une IA pour la finance.

L'article

Islam et al. présentent FinanceBench: A New Benchmark for Financial Question Answering (arXiv:2311.11944), une suite de tests comprenant 10 231 questions sur des sociétés cotées en bourse, tirées de dépôts réels de la SEC — rapports annuels 10-K, dépôts trimestriels 10-Q, rapports courants 8-K et transcriptions d'appels de résultats. Contrairement aux ensembles de données de QA financière précédents (FinQA, TAT-QA), qui présentent des tableaux et des passages pré-extraits, FinanceBench exige qu'un système récupère les preuves à partir de documents complets avant de répondre. C'est le cadre réaliste. Les questions sont conçues pour être factuellement sans ambiguïté et, selon les termes des auteurs, constituent « une norme de performance minimale ».

L'équipe a évalué 16 configurations couvrant GPT-4-Turbo, Llama2 et Claude2 à travers quatre stratégies de récupération : en circuit fermé (sans récupération), base de données vectorielle partagée, base de données vectorielle par document, et invites à contexte long alimentées par la page pertinente complète. Des annotateurs humains ont examiné manuellement les 2 400 réponses sur 150 cas open-source.

Idées clés

• La récupération n'est pas le goulot d'étranglement. GPT-4-Turbo, lorsqu'on lui donne le passage oracle — la page exacte contenant la réponse — n'atteint encore que 85 % de précision. L'invite à contexte long (alimentant automatiquement la bonne page) obtient un score de 79 %. Une récupération parfaite ne vous fait gagner que six points.
• Le RAG avec base de données vectorielle est le vrai problème. GPT-4-Turbo avec une base de données vectorielle par document : 50 % de réponses correctes, 39 % de refus. Avec une base de données vectorielle partagée entre les entreprises : 19 % de réponses correctes, 68 % de refus. Le gros titre « 81 % de taux d'échec » provient de cette configuration de base partagée — la configuration que la plupart des démonstrations d'IA d'entreprise utilisent réellement.
• Les modèles échouent différemment. Llama2 hallucine de manière agressive (54 à 70 % de réponses incorrectes) ; GPT-4-Turbo refuse de répondre (39 à 68 % de refus plutôt que d'erreurs). Les deux modes d'échec sont inacceptables en production, mais ils ne représentent pas des risques équivalents.
• 66 % des questions nécessitent un raisonnement numérique. Taux de croissance, marges, variations d'une année sur l'autre. C'est là que les modèles errent le plus fréquemment — erreurs de calcul, confusion d'unités, erreurs de signe.
• Le contexte long sauve presque la mise. Claude2 en contexte long : 76 % de réponses correctes. GPT-4-Turbo en contexte long : 79 %. Ce sont les meilleurs chiffres pratiques, obtenus en sautant la récupération et en alimentant directement toute la page pertinente.
• Même l'oracle a des faiblesses. Avec des preuves parfaites, le plafond est de 85 %, pas de 100 %. Quinze pour cent des échecs sont de purs échecs de raisonnement sans composante de récupération.

Ce qui tient la route — et ce qui ne tient pas

La conception du benchmark est solide. Insister sur des documents réels plutôt que sur des extraits pré-identifiés est le bon choix méthodologique — cela teste ce qui compte réellement lors du déploiement. L'évaluation manuelle de 2 400 réponses est coûteuse et crédible.

Ce que je trouve moins convaincant, c'est d'établir des classements à partir de n=150. La différence entre Claude2 en contexte long (76 %) et GPT-4-Turbo en contexte long (79 %) n'a aucune signification statistique à cette taille d'échantillon, mais l'article la présente comme un classement. Le benchmark complet de 10 231 questions existe mais n'est pas scoré publiquement, ce qui limite la reproduction indépendante.

Le résultat de l'oracle est également la découverte la plus importante et la moins analysée. Si les modèles échouent 15 % du temps avec la bonne page en main, le problème réside dans le raisonnement et l'arithmétique, pas dans la récupération. L'article mentionne les outils de calcul et la chaîne de pensée (chain-of-thought) comme travaux futurs — ces expériences auraient dû être au centre de cet article, pas en note de bas de page.

Le benchmark reconnaît également qu'il cible une « performance minimale » : des questions portant sur un seul document avec des réponses sans ambiguïté. Le raisonnement multi-documents, les tendances pluriannuelles et les comparaisons entre entreprises sont exclus. Les articles citant le chiffre de 79 % pour le contexte long mentionneront rarement cette mise en garde.

Pourquoi cela compte pour l'IA financière

Le cas d'utilisation de l'écriture en retour (write-back) de Beancount correspond presque directement aux modes d'échec de FinanceBench. Un agent qui récupère une écriture de transaction et vérifie si le montant correspond à un relevé bancaire effectue la même tâche de récupération puis d'arithmétique que ce benchmark mesure. Le plafond de l'oracle — 85 % même avec un contexte parfait — est la contrainte de conception pertinente : même si l'agent trouve la bonne écriture au grand livre, il existe une probabilité réelle qu'il calcule mal la comparaison, confonde le signe ou lise mal les unités.

La distinction d'échec Llama2/GPT-4 est cruciale pour l'architecture des agents. Un refus est récupérable (renvoi vers une révision humaine) ; une correspondance hallucinante inscrite au grand livre ne l'est pas. Cela plaide pour une préférence pour un comportement de refus conservateur plutôt qu'une hallucination confiante, même au prix d'un taux de réussite apparent plus faible.

L'avantage du contexte long (79 % contre 50 %) est pratiquement frustrant pour les applications de comptabilité. Les fichiers Beancount pluriannuels sont trop volumineux pour être alimentés intégralement. Résoudre la récupération sur des documents numériques denses — et pas seulement la récupération de texte — reste un problème ouvert.

Que lire ensuite

• FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122) — le benchmark précurseur que FinanceBench améliore explicitement ; utile pour comprendre ce que le domaine avait réussi avant que la récupération sur documents réels ne soit exigée.
• DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024) — étend FinanceBench avec des questions multi-étapes plus difficiles nécessitant un raisonnement croisé au sein d'un même dépôt.
• PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — délègue l'arithmétique à un interpréteur Python, répondant directement aux 66 % de questions de FinanceBench qui échouent sur le raisonnement numérique.