OmniEval : un benchmark d'évaluation RAG omnidirectionnel pour le domaine financier

La plupart des benchmarks RAG en finance se demandent si un système peut récupérer des informations et y répondre — point final. OmniEval (EMNLP 2025, arXiv:2412.13018) de Shuting Wang et al. de l'université RUC pose une question plus difficile : les performances se maintiennent-elles à travers toute la matrice des types de tâches et des sujets financiers ? Je le lis actuellement car c'est la tentative la plus structurée de cartographier la forme des échecs du RAG en finance avant de tenter de construire des agents de registre Beancount fiables sur des pipelines RAG.

L'article

OmniEval construit une grille d'évaluation bidimensionnelle : cinq classes de tâches (QA extractive, raisonnement multi-sauts, QA de contraste, QA longue forme et QA conversationnel) croisées avec 16 sujets financiers (marchés boursiers, banque d'investissement, fonds, assurance immobilière, et autres). Le résultat est un benchmark structuré comprenant 11,4k exemples de test générés automatiquement, 1,7k exemples annotés par l'homme et un corpus de récupération de 362k documents assemblé à partir de six sources de données financières chinoises (BSCF-DB à 193k documents, FinGLM à 55k, BAAI-Fin à 48k, des crawls web officiels, des PDF et du contenu financier de Wikipédia). Le benchmark inclut également un évaluateur LLM affiné — Qwen2.5-7B-Instruct entraîné sur 910 instances étiquetées par l'homme — qui évalue la qualité de la génération selon la précision, l'hallucination, l'exhaustivité, l'utilisation et la précision numérique. L'article a été publié à l'EMNLP 2025.

Idées clés

• Les cas de test générés automatiquement ont passé un contrôle d'acceptation humain à 87,47 %, ce qui signifie qu'environ 1 instance générée sur 8 a été rejetée — un taux de bruit non négligeable pour un benchmark.
• Le meilleur moteur de récupération (GTE-Qwen2-1.5B) a atteint un MAP de 0,4370 et un MRR de 0,4491 sur l'ensemble auto-généré, ce qui signifie que le passage le mieux classé est correct moins de la moitié du temps, même avec le meilleur récupérateur testé.
• La précision de la génération (ACC) à travers toutes les combinaisons récupérateur-LLM variait de 0,3238 à 0,4476 — la meilleure configuration répond correctement à moins de la moitié des questions.
• La précision numérique (NAC) est la conclusion la plus marquante : de 0,0659 à 0,3595. Le meilleur système donne les bons chiffres financiers environ 36 % du temps ; le pire est proche de zéro.
• L'évaluateur affiné a atteint un accord de 74,4 % avec l'annotation humaine (κ = 0,6486), surpassant nettement les références basées uniquement sur le prompt (55–71 %) — mais laissant toujours une évaluation sur quatre en décalage avec le jugement humain.
• Le raisonnement multi-sauts et le QA conversationnel ont été systématiquement les classes de tâches les plus difficiles.

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

La conception de l'évaluation par matrice est réellement utile. Les benchmarks financiers précédents (FinanceBench, FinQA, DocFinQA) traitent l'évaluation sur un seul axe — généralement la précision des réponses — et manquent la variation structurelle de la façon dont le RAG échoue. Savoir qu'un système obtient de bons résultats en QA extractive mais de mauvais résultats en raisonnement multi-sauts est exploitable ; savoir qu'il obtient une note moyenne globale ne l'est pas. La grille OmniEval rend cette variation visible, et la conclusion selon laquelle les performances sont incohérentes selon les sujets est exactement le type de résultat que les praticiens doivent voir avant tout déploiement.

Cela dit, il y a des limites réelles que je tiens à souligner. Le corpus est majoritairement chinois : cinq des six sources de données sont des données financières chinoises (BSCF, FinGLM, BAAI-Fin), et la sixième est le Wikipédia chinois. L'article ne présente pas les résultats ventilés par langue — il ne rapporte que des chiffres agrégés. Cela rend chaque score suspect en tant qu'affirmation sur le RAG financier en général, par opposition au RAG financier sur des textes chinois avec des récupérateurs et des LLM spécialisés pour le chinois (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Les utilisateurs financiers anglophones ou francophones ne peuvent pas utiliser directement ces chiffres.

L'évaluateur LLM est entraîné sur 910 instances étiquetées. C'est peu. L'accord humain de 74,4 % à κ = 0,6486 est défendable comme point de départ mais signifie que le cadre d'évaluation lui-même introduit un bruit substantiel. Si le benchmark est utilisé pour comparer des systèmes qui diffèrent de quelques points de pourcentage, la variance de l'évaluateur submergera le signal.

Le pipeline de génération automatique — GPT-4 produit les questions de test, les humains filtrent avec 87,47 % d'acceptation — soulève également une question de contamination que l'article n'aborde pas : les questions générées par GPT-4 pourraient favoriser les modèles de la classe GPT-4 d'une manière qui désavantage systématiquement les modèles plus anciens ou plus petits.

Pourquoi c'est important pour l'IA en finance

Les scores de précision numérique sont les chiffres sur lesquels je reviens sans cesse : 0,0659–0,3595. Si le meilleur système RAG testé ne donne les chiffres financiers corrects que 36 % du temps dans une évaluation de référence, tout agent d'écriture Beancount construit sur un pipeline RAG naïf va corrompre les données du registre. Le format de Beancount est impitoyable — un montant, une date ou un nom de compte incorrect produit soit une erreur d'analyse, soit une erreur comptable silencieuse qui peut se propager sur plusieurs exercices fiscaux. Ce benchmark nous donne la preuve concrète que la récupération RAG et la génération LLM ne sont pas encore assez fiables pour une écriture directe dans le registre sans une couche de validation.

La structure des classes de tâches correspond également parfaitement aux cas d'utilisation de Beancount. Le QA extractif correspond aux simples consultations de solde. Le raisonnement multi-sauts correspond à des questions telles que « quel est mon revenu net après impôts sur les trimestres T1 à T3 ? ». Le QA conversationnel correspond à un utilisateur affinant itérativement une demande de rapprochement au cours d'une session. Le constat d'OmniEval selon lequel les tâches multi-sauts et conversationnelles sont les plus difficiles est exactement la mauvaise nouvelle pour la conception d'un agent Beancount : les cas simples s'en sortent presque ; les cas réalistes sont ceux où le système s'effondre.

Que lire ensuite

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — l'analogue le plus proche en domaine général de l'approche d'affinage de l'évaluateur d'OmniEval ; comparer la méthodologie ARES à celle d'OmniEval permettrait de clarifier si les choix de conception de l'évaluateur LLM sont fondés sur des principes ou ad hoc.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — génération automatisée de scénarios pour l'évaluation RAG ; étend la méthodologie d'auto-génération utilisée par OmniEval et pourrait répondre aux préoccupations concernant la contamination.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — étend l'évaluation RAG aux documents financiers multimodaux (tableaux, graphiques) ; pertinent alors que les utilisateurs de Beancount disposent de plus en plus d'images de reçus et de relevés PDF aux côtés de registres en texte brut.