论文：金融问答评估语料框架SEC-QA

# 金融问答的“最后一公里”：SEC-QA如何破解多文档定量推理难题 金融行业每天都在和成堆的长文档打交道——年度报告、季度财报、临时公告……这些文件既是决策的基础，也是信息的“金矿”。问题在于，如何让AI真正读懂这些文档，而不是只会做个“文字复读机”？ 先说几个核心判断：当前的检索增强生成方法在处理多文档、多跳推理的复杂金融问题时，表现并不理想。这不是模型不够大、数据不够多的问题，而是评估体系的缺失。你很难判断一个模型到底是真懂，还是只是“撞上了”训练数据里的答案。 这正是SEC-QA要解决的问题。这个框架的核心在于：它能够动态生成基于真实金融文档的定量多跳问答任务。不依赖过时的静态数据集，而是从公开可获取的文档和数据库中持续生成新问题，确保模型在“没见过”的数据上进行评估。 ## 评估体系的“阿喀琉斯之踵” 大语言模型的参数规模已经大到令人咋舌，但幻觉、阅读理解能力差、私有数据泄露等问题依然存在。RAG的初衷是通过检索可靠文档来生成回答，从理论上讲，即使模型不够大，也能给出靠谱的答案。 但问题来了——如何评估RAG系统的真实能力？ 现有的基准测试大多基于维基百科、常识知识这类开放资源。想象一下，如果训练数据里已经包含了这些内容，那再拿它们来测试，就像开卷考试时发现题目都提前告诉过你了一样。更麻烦的是，这些静态基准本身也被“泄露”到互联网上，成为大模型训练数据的一部分。结果是：测试分数越来越“虚”，模型的真实能力反而看不清了。 金融领域的情况更复杂。专业问题通常需要多跳推理——比如“计算某公司过去五年的收入增长率，再与同行比较”——这远不是“苹果的CEO是谁”这种常识问题能比的。而且金融文档有其独特的结构：表格、章节、跨年度的文件集合，这些都不是开放知识库能模拟的。 ## 如何让问题真正“难”起来 SEC-QA的设计思路很清晰：从真实金融数据出发，构建一个可以灵活控制问题复杂度的框架。 具体来说，框架依赖两个关键资源：一个结构化的金融指标数据库，和一个包含对应源文档的文档集合。数据库里记录了公司、财政年度、指标名称、指标值和对应的文档来源。这样设计的好处是，不仅能验证答案是否正确，还能精确追踪检索的准确性——到底是从哪份文档、哪一页找到的信息。 问题复杂度的设计是这篇文章的亮点之一。作者把问题分为几个维度： - **并行引用**：需要从多个实体或时间段提取同一类信息，比如“最近五年苹果的收入增长是多少”。 - **多跳引用**：需要通过逻辑约束进行多步推理，比如“标普500中市值最高的五家公司，过去五年的股价走势如何”。 - **结构引用**：涉及文档内部的特定表格、章节，或者文档集合中的子集筛选。 - **多输出问题**：要求模型同时输出多个值，比如“计算亚马逊过去四个季度的收入增长、毛利率和营业利润率”。 这些维度组合起来，几乎可以覆盖金融分析师日常工作中遇到的各种复杂场景。更重要的是，通过模板填充的方式，可以半自动地生成大量问题，从而控制问题的分布和质量。 ## RAG系统的“滑铁卢” 实验结果相当直白：当前主流的RAG方法，在面对这些精心设计的多文档问题时，表现惨淡。 作者测试了四种系统：普通的RAG（直接检索+生成）、多查询RAG（针对一个问题生成多个检索查询）、基于代码生成的系统（用LLM生成代码来检索和提取数值）、以及带文档选择的代码生成系统。 在单一值提取任务上，带文档选择的代码生成系统表现最佳，准确率达到89.5%。但普通的代码生成系统只有31.6%，普通RAG也不过55.8%。差距从何而来？ 关键在于文档选择。金融文档的结构高度相似——同一家公司多年的报告，文本内容常常重复。没有文档选择，模型很容易检索到错误的财政年度或过时的数据。这一点在案例研究中表现得淋漓尽致：当被问到“Adobe 2022年的员工总数”时，普通RAG系统四次中有三次检索到了Adobe的10-K报告，但年份全错。 复合值提取任务就更难了。例如“计算每位员工的收入”，需要先理解这个指标的计算公式，再检索对应的子指标（员工总数、总收入等）。所有测试系统的准确率都大幅下滑。更麻烦的是，有些子指标本身也是复合指标，或者根本不适用于某些公司——这导致错误提取或重复计算。 到了多文档问答任务，差距进一步拉大。带文档选择的代码生成系统正确回答了80%的问题，而普通RAG只有30%。值得注意的是，前者的性能对检索页面数非常敏感——从4页增加到32页，准确率迅速攀升；而普通RAG几乎没有任何改善。 ## 瓶颈到底在哪里 既然RAG系统表现不佳，问题到底出在哪个环节？ 通过分析准确率与检索指标之间的关系，作者发现了一个关键结论：**召回率是决定多文档问答准确性的核心瓶颈**。页面级别的召回率与准确率的决定系数高达0.94，而精确度的相关系数只有0.12。换句话说，检索环节漏掉关键文档，下游的问答表现就基本“凉了”。 这解释了为什么代码生成系统表现更好——它能够将复杂问题拆解成原子问题，然后针对每个原子问题系统地检索页面。再加上文档选择机制的加持，有效提高了召回率。 不过，高性能是有代价的。代码生成系统的LLM调用次数是普通RAG的四倍左右，这意味着运营成本和延迟都会显著上升。 ## 动态评估的可行性 防止数据泄露是SEC-QA的另一个核心设计目标。通过定期使用最新的财务文件生成新的问答对，可以确保模型在面对“没见过”的数据时进行评估。 那问题来了：不同版本的数据集之间，评估结果是否稳定？ 作者用2019年至2023年的数据构建了五个版本的测试集，结果的标准差很小（1.3%到2.0%）。这意味着不同版本的评估结果可以可靠地相互比较，不会因为数据年份的变化而出现系统性偏差。 ## 实践中的挑战 虽然SEC-QA框架在金融领域表现不俗，但它在公共部门的扩展面临困难。原因很简单：财务报告的标准不一致。作者尝试过使用美国州政府的综合年度财务报告，结果发现要将这些报告逆向工程为一个可用的数据集，难度极大。 这其实引出了一个更深层的问题：高质量的评估数据集，依赖于领域的标准化程度。金融领域因为监管严格、报告格式相对统一，才让SEC-QA的设计成为可能。如果在报告标准参差不齐的领域，这套框架的应用价值就会大打折扣。 ## 总结 SEC-QA的价值，不仅在于它提供了一个金融领域的多文档问答评估框架，更在于它揭示了一个被许多人忽略的事实：当前的RAG系统在处理复杂、专业的定量推理问题时，表现远没有我们想象中那么好。 从更宏观的角度看，这项工作也提醒我们：AI评估不能只依赖“够用”的静态基准。真正有意义的评估，应该能够动态适应真实应用场景的复杂度——而这恰恰是SEC-QA设计中最可贵的地方。