OmniEval：金融领域全方位 RAG 评估基准
大多数金融领域的 RAG 基准测试只关注系统是否能够检索并回答——仅此而已。来自中国人民大学的 Shuting Wang 等人提出的 OmniEval (EMNLP 2025, arXiv:2412.13018) 提出了一个更难的问题：在任务类型和金融主题的完整矩阵中，性能是否依然稳健？我正在阅读这篇论文，因为在尝试基于 RAG 流水线构建可靠的 Beancount 账本代理之前，这是描绘金融 RAG 失败模式最系统化的一次尝试。
论文
OmniEval 构建了一个二维评估网格：五类任务（抽取式问答、多跳推理、对比式问答、长文本问答和对话式问答）与 16 个金融主题（股票市场、投资银行、基金、财产保险等）交叉。其结果是一个结构化的基准测试，包含 1.14 万个自动生成的测试用例、1700 个经人工标注的用例，以及一个由 6 个中文金融数据源组成的 36.2 万份文档的检索语料库（包括 19.3 万份文档的 BSCF-DB、5.5 万份的 FinGLM、4.8 万份的 BAAI-Fin、官 方网页抓取、PDF 以及维基百科金融内容）。该基准测试还包含一个经过微调的大语言模型评估器——基于 910 个经人工标记的实例训练的 Qwen2.5-7B-Instruct——它从准确性、幻觉、完整性、利用率和数值准确性五个维度对生成质量进行评分。这篇论文发表于 EMNLP 2025。
核心观点
- 自动生成的测试用例通过人工验收率为 87.47%，这意味着大约每 8 个生成的实例中就有 1 个被丢弃——对于一个基准测试来说，这个噪声率不容小觑。
- 表现最好的检索器 (GTE-Qwen2-1.5B) 在自动生成的集合上实现了 0.4370 的 MAP 和 0.4491 的 MRR，这意味着即使使用测试中最强的检索器，排名第一的段落正确率也低于一半。
- 所有“检索器-大语言模型”组合的生成准确度 (ACC) 范围从 0.3238 到 0.4476——最好的配置回答正确率也不到一半。
- 数值准确度 (NAC) 是最显著的发现：范围在 0.0659 到 0.3595 之间。表现最好的系统在金融数值上的正确率约为 36%；最差的则接近于零。
- 经过微调的评估器与人工标注的一致性达到了 74.4% (κ = 0.6486)，显著优于仅使用提示词的基准测试 (55–71%)——但仍然有四分之一的评估结果与人类判断不符。
- 多跳推理和对话式问答始终是最难的任务类别。
哪些具有参考价值——哪些没有
这种矩阵评估设计确实很有用。之前的金融基准测试（如 FinanceBench、FinQA、DocFinQA）将评估视为单一维度——通常是答案准确性——从而忽略了 RAG 失败方式的结构性差异。了解系统在抽取式问答上得分很高但在多跳推理上得分很低，这具有可操作性；而仅仅知道一个总平均分则不然。OmniEval 网格使这种差异变得可见，而性能在不同主题间不一致的发现，正是从业者在部署前需要了解的信息。
尽管如此，我仍想直言不讳地指出一些实际的局限性。语料库绝大部分是中文的：六个数据源中有五个是中文金融数据（BSCF、FinGLM、BAAI-Fin），第六个是中文维基百科。论文没有按语言报告结果——它只报告了汇总数据。这使得论文中的每一项得分在作为关于通用金融 RAG 的结论时都值得商榷，而更应被视为针对中文文本及中文专用检索器和大语言模型（GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B）的金融 RAG 结论。英语金融用户不能直接引用这些数字。
大语言模型评估器基于 910 个标注实例进行训练。这太少了。74.4% 的人类一致性（κ = 0.6486）作为起点是说得通的，但这意味着评估框架本身引入了大量噪声。如果该基准测试用于比较仅有几个百分点差异的系统，评估器的方差将淹没信号。
自动生成流水线——GPT-4 生成测试问题，人工以 87.47% 的通过率进行过滤——也引发了论文未提及的污染问题：GPT-4 生成的问题可能以某种方式发挥了 GPT-4 级别模型的优势，从而在系统性上让旧模型或更小的模型处于劣势。
为什么这对金融 AI 至关重要
数值准确度分数是我不断回想的数字：0.0659–0.3595。如果在基准评估中，表现最好的 RAG 系统在金融数字上的正确率仅为 36%，那么任何基于原生 RAG 流水线构建的 Beancount 回写代理都会损坏账本数据。Beancount 的格式是非常严苛的——错误的金额、日期或账户名称要么导致解析错误，要么导致可能跨财年传播的隐性会计错误。该基准测试为我们提供了具体的证据，表明在没有验证层的情况下，RAG 检索和 LLM 生成对于直接回写账本而言还不够可靠。
任务类别结构也清晰地对应于 Beancount 的使用场景。抽取式问答对应于简单的余额查询。多跳推理对应于诸如“我第一季度到第三季度的税后净收入是多少？”之类的问题。对话式问答对应于用户在会话中反复完善对账请求。OmniEval 关于多跳和对话式任务最难的发现，对 Beancount 代理的设计来说正是一个坏消息：简单的情况几乎没问题，而现实的情况正是系统崩溃的地方。
延伸阅读
- ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) —— 这是与 OmniEval 的评估器微调方法最接近的通用领域对应方案；将 ARES 方法论与 OmniEval 的方法论进行比较，可以明确大语言模型评估器的设计选择是有原则的还是随机的。
- RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) —— 自动生成 RAG 评估场景；它扩展了 OmniEval 使用的自动生成方法，并可能解决污染问题。
- FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) —— 将 RAG 评估扩展到多模态金融文档（表格、图表）；随着 Beancount 用户越来越多地在纯文本账本旁附带收据图像和 PDF 账单，这一点变得非常有意义。
