FinDER：真实分析师查询揭示金融 RAG 中 74% 的召回率差距
FinDER (arXiv:2504.15800) 是一个基于一个简单但未被充分重视的观察而建立的检索基准：金融专业人士输入的真实查询，与学术基准中那些经过修饰的问题完全不同。我之所以阅读这篇论文，是因为它处于我一直在关注的两个方向的交汇点——金融 AI 中的检索差距，以及 DocFinQA 和 FinanceBench 开始揭示的实际现实问题。
论文内容
Chanyeol Choi、Jihoon Kwon 及其在一家金融 AI 公司的同事们展示了一个包含 5,703 个专家标注的“查询-证据-答案”三元组数据集，这些数据源自真实的对冲基金分析师问答服务。这些文档是来自 SEC EDGAR 的 490 家标普 500 指数公司的 Form 10-K 文件。FinDER 与之前基准测试的不同之处在于查询端：89.86% 的查询包含三个或更多领域特定的缩写或首字母缩略词。真实的分析师可能不会输入“公司 X 在 2023 财年的总收入是多少？”，而是输入“GOOGL 10-K FY23 revs breakdown by segment”。该数据集发表于 ICLR 2025 金融 AI 进展研讨会，随后出现在 ICAIF 2025 上。
核心观点
- 检索召回率普遍低得惊人：E5-Mistral（最佳密集检索器）总体仅达到 25.95% 的上下文召回率；BM25 仅为 11.68%。“财务（Financials）”类别——与会计直接相关的类别——是最难的：两者的召回率分别为 15.84% 和 6.42%。
- 仅查询歧义就导致精确率下降了 8.2 个百分点：作者在 500 个查询上测试了 E5-Mistral，将规范的释义（精确率 33.9）与真实的缩写查询（精确率 25.7）进行了对比。这一差距完全归因于对缩写/首字母缩略词的处理，而非文档的复杂性。
- 检索质量是生成的主要瓶颈：在没有上下文的情况下，LLM 的得分接近于零（正确率 9-10%）；有了前 10 个检索到的段落，正确率达到 29-34%；而在拥有完美的“金准（oracle）”上下文时，正确率跃升至 60-68%。现实情况与金准条件之间 35 个百分点的差距，比开源模型与前沿模型之间的差距还要大。
- 即使检索良好，组合算术也会失效：在所有四个模型（Claude-3.7-Sonnet、GPT-o1、DeepSeek-R1-Distill 和 Qwen-QWQ）中，多步计算任务（组合查询）的正确率仅为 ~20%，即使提供了前 10 个检索到的段落也是如此。GPT-o1 在乘法任务中以 42.90% 领先，但在除法任务中下降到 27.78%。
- LLM 重排序带来了虽小但持续的提升：在回答之前让模型对 E5-Mistral 的前 10 个命中结果进行重排序，Claude-3.7-Sonnet 的 F1 达到了 63.05，GPT-o1 达到了 62.90。Deepseek-R1-Distill 以 60.01 紧随其后，尽管它在其他结构化推理方面表现强劲。
- 类别难度不均衡：风险类查询最容易检索（E5-Mistral 召回率为 33.07）；财务类查询仍然最难（15.84）。这与查询结构相关——风险披露使用自然语言散文，而财务表格使用密集的数值符号。
哪些论点经得起推敲，哪些不能
核心贡献是扎实的：这是来自在职分析师的真实查询分布，缩写问题是真实存在的。任何基于维基百科或 FinQA 式众包构建的基准测试都会忽略这一点。三层评估结构（无上下文、现实检索、金准上下文）是正确的设计；它清晰地将检索质量与推理质量区分开来，并展示了剩余的生成差距（即使在定性问题上拥有完美上下文，仍有 ~32-34% 的失败率）。
该论文最薄弱的地方在于可复现性。在发表时，该数据集尚未公开——作者称他们“计划稍后公开发布”。对于一篇自荐为评估标准的研讨会论文来说，这是一个重大问题。未发布的基准测试不是基准测试，而是案例研究。此后它已在 ICAIF 2025 上亮相，因此可能已经发布，但 arXiv 版本尚未证实这一点。
检索评估也仅使用了四个单阶段模型（BM25、GTE、mE5、E5-Mistral）。没有混合检索，没有查询扩展，没有 HyDE，也没有针对缩写问题的重写步骤。鉴于作者已经精确地刻画了缩写差距，令人惊讶的是他们没有测试显而易见的修复方法：在检索前扩展查询（例如将“GOOGL”映射 为“Alphabet Inc.”）。论文中缺失了这一实验。
生成结果值得细读。~9-10% 的无上下文表现并不是一个有用的下限——它本质上就是零——但 60-68% 的金准上限比看起来更具信息量。即使手里拿着正确的段落，最好的模型在定性问题上仍有约三分之一会失败，在组合算术上则有五分之四会失败。这个上限很重要：它意味着单纯靠检索无法解决问题。
为什么这对金融 AI 很重要
FinDER 中的查询分布与 Beancount 用户实际上如何与账本智能体互动的场景非常吻合。一个维护账目多年的用户会输入简写的、带有上下文的查询——例如“AMZN card Q3 reimb?”（亚马逊卡第三季度报销？），而不是“亚马逊信用卡在第三季度的报销额是多少？”标准的嵌入模型无法检索到正确的条目，因为它们是在规范的自然语言文本上训练的。在个人账本领域，这种从规范查询到真实查询的 8.2 点精确率下降可能还是保守的，因为个性化的简写（如用“prop mgmt fee”代表“property management fee”）比 SEC 标准缩写离训练数据更远。
E5-Mistral 25.95% 的上下文召回率上限是一个强制约束：任何 Beancount RAG 流水线都需要预留应对大部分证据缺失的预算。其中一个启示是，高召回率的二次检索（多次迭代、多样化的查询表达）比提高单次检索的 F1 更重要。另一个启示是，查询归一化——在检索前将用户的简写映射到规范的账户名称——应该是一个显式的预处理步骤，而不是留给嵌入模型去处理。
即使在金准上下文下，组合算术的准 确率也仅为 20%，这是一个单独的信号：对于 Beancount 计算任务，生成的瓶颈在于推理，而非检索。无论检索变得多么出色，PAL 风格的卸载（生成 Python 算术代码而非自由文本计算）仍然是处理数值任务的正确答案。
下一步读什么
- Fin-RATE (arXiv:2602.07294) —— 针对 SEC 文件的多期追踪伴随基准；在时间相关任务上准确率下降了 18.60%，这直接对应了 Beancount 多年账本的问题。
- IRCoT (arXiv:2212.10509, ACL 2023) —— 将检索与思维链推理交织在一起；多轮检索结构直接解决了 FinDER 揭示的单轮召回率低的问题。
- 利用 LLM 进行针对特定领域检索的查询扩展 —— 目前还没有单一的基准论文能很好地涵盖这一点，但 FinDER 揭示的缩写差距使其成为首要的研究重点；搜索“HyDE financial domain”和“query expansion SEC filings 2025”是正确的起点。
