FinRetrieval: A Benchmark for Financial Data Retrieval by AI Agents

本文介绍了 FinRetrieval 基准，该基准通过 500 个金融检索问题评估了 AI 代理从结构化数据库中提取数值的能力，揭示了工具可用性对性能的决定性影响，并发现推理模式的效果取决于基础能力而非推理本身，同时指出了地理命名惯例带来的性能差异。

要点

这篇论文介绍了一个名为 FinRetrieval 的新测试，就像是一场专门为“金融 AI 助手”举办的寻宝大赛。

想象一下，你雇佣了三个最聪明的机器人管家（分别来自 Anthropic、OpenAI 和 Google），让他们去一个巨大的、由数字组成的金融图书馆里，帮你找几个具体的数字（比如“苹果公司去年第三季度的收入是多少？”）。

这篇论文就是记录这场比赛的过程、结果，以及为什么有些机器人表现神勇，而有些却笨手笨脚。

以下是用大白话和生动比喻对这篇论文核心内容的解读：

1. 比赛规则：不仅仅是“读书”，更是“查库”

以前的测试主要看机器人能不能读懂给它的文件（比如给一段财报，让它做数学题）。
但这次比赛不一样，它给机器人空手，让它们自己去数据库里找答案。

• 场景：就像你问管家“我家冰箱里还有几个鸡蛋？”，管家不能瞎编，必须真的去冰箱（数据库）里翻，或者去网上搜。
• 规模：一共出了 500 道题，涵盖了 14 种不同的机器人配置（有的聪明，有的笨，有的有工具，有的没工具）。

2. 核心发现一：工具比“脑子”更重要（71 分的差距）

这是比赛最惊人的发现。

• 比喻：想象你要找一本藏在图书馆深处的书。
  • 配置 A（有工具）：机器人手里有一张图书馆的精确索引地图（结构化数据 API），它能直接走到书架前把书拿下来。
  • 配置 B（无工具）：机器人手里只有一张模糊的传单（网络搜索），它只能在图书馆大厅里大喊“谁见过这本书？”，然后看着别人给的只言片语猜。
• 结果：
  • 最聪明的机器人（Claude Opus），如果有“索引地图”，准确率高达 90.8%。
  • 一旦没收地图，只让它靠“传单”去搜，准确率直接暴跌到 19.8%。
  • 结论：对于金融找数这种任务，有没有好用的工具，比机器人本身有多聪明重要得多。这就好比给一个普通人配了 GPS 导航，他比一个没导航的赛车手更能找到路。

3. 核心发现二：“深思熟虑”不一定总是好事

现在的 AI 流行一种“思考模式”（Reasoning Mode），就像让机器人在回答前先“打个腹稿”，多花点时间想。

• 发现：
  • OpenAI 的机器人：本来有点“路痴”（基础模式下不太会查工具），一让它“深思熟虑”，它就能把路找对，成绩提升了 9%。
  • Claude 的机器人：本来就是个“老练的向导”（基础模式就很会查工具），再让它“深思熟虑”，成绩只提升了 2.8%。
• 比喻：就像让一个本来就会开车的老司机（Claude）再戴个“思考眼镜”，对他帮助不大；但让一个刚拿驾照的新手（OpenAI）戴上眼镜，反而能帮他避开很多坑。
• 代价：虽然“思考模式”能提高准确率，但它会让回答时间变长（就像思考久了，上菜慢了）。

4. 核心发现三：第一次就找对，效率最高

• 现象：那些一次就找对答案的机器人，用的工具次数少，速度快。那些找错的，往往是因为第一次没找对，然后开始像无头苍蝇一样乱撞，反复搜索，最后反而错了。
• 比喻：就像你在超市找可乐。
  • 高手：看一眼货架标签，直接走过去拿（3 步搞定，93% 成功率）。
  • 新手：先问人，问错了，再去另一个区，再问人，最后累得半死还拿错了（18 步，77% 成功率）。
• 教训：能不能在第一次搜索时就精准定位，是决定成败的关键。

5. 核心发现四：不是机器人“不懂”，是“日历”不一样

比赛发现，机器人回答美国公司的题目比回答非美国公司（如日本、印度）的题目要准一些。

• 真相：这不是因为机器人不懂外语或文化，而是因为会计日历不一样。
• 比喻：
  • 美国公司通常用“自然年”（1 月到 12 月）。
  • 日本公司常用“财年”（4 月到次年 3 月）。
  • 当题目问"2023 财年”时，机器人如果按美国习惯以为是"1 月到 12 月”，而实际数据是"4 月到 3 月”，它就找错年份了。
• 结论：这是数据格式的问题，不是机器人智商的问题。只要把“日历转换规则”教给机器人，这个差距就消失了。

6. 最大的错误来源：搞错了“时间”

在机器人犯错的地方里，63% 都是因为搞错了时间（比如把“宣布时间”当成了“目标时间”，或者搞混了财年）。

• 比喻：就像你问“去年 3 月的生日派对”，机器人却去查了“去年 3 月宣布要办派对”的新闻，结果把时间搞混了。
• 解决：这不需要换更聪明的机器人，只需要把工具的说明书写得更清楚一点（比如明确告诉机器人：日本公司的财年是从 4 月开始算的），就能解决大部分问题。

总结：这篇论文告诉我们什么？

1. 工欲善其事，必先利其器：在金融数据检索上，给 AI 配好专业的数据库接口，比换一个更贵的 AI 模型更重要。
2. 说明书要写清楚：很多错误是因为 AI 不知道数据的“潜规则”（比如财年怎么算）。把规则写进工具说明里，比让 AI 自己“猜”要有效得多。
3. 不要盲目追求“思考”：如果基础能力够强，过度的“思考模式”只会拖慢速度，未必能带来多少提升。

一句话总结：
这篇论文告诉我们，想要 AI 在金融领域当好“数据管家”，别光盯着让它变聪明，得先给它配好精准的“地图”和“说明书”。只要工具给对了，哪怕是普通的 AI 也能干出大师级的活。

技术摘要

1. 研究背景与问题定义 (Problem)

• 现有局限：当前的金融问答（Financial QA）基准测试（如 FinQA, TAT-QA, FinanceBench）主要关注基于提供文档的数值推理或算术计算，或者仅评估从 SEC 文件等文档中检索信息的能力。
• 核心缺口：缺乏一个基准来专门评估 AI 代理从结构化金融数据库（Structured Databases）中检索特定数值的能力。在实际金融研究中，代理需要调用 API 从数据库中提取精确的财务指标（如“苹果 2024 年 Q3 的营收”），而不仅仅是阅读文档。
• 目标：构建一个能够评估 AI 代理在真实金融场景下，利用工具（Tools）从结构化数据源中准确检索数值的能力的基准。

2. 方法论与基准设计 (Methodology)

2.1 数据集构建 (FinRetrieval Dataset)

• 规模：包含 500 个精心设计的金融检索问题，每个问题都有经过验证的“真实答案”（Ground Truth）。
• 数据来源：基于 Daloopa 平台（从 SEC 文件、财报和投资者演示中提取的结构化数据），覆盖 4000+ 家上市公司。
• 生成流程：
  1. 分层采样：按美国/非美国 50:50 比例，随机选择财务类别（如资产负债表、现金流等），并采用加权采样避免过度采样细分指标。
  2. 上下文增强：为每个数据点提供相邻系列（层级上下文）和带有高亮单元格的源文档截图，以消除时间周期歧义。
  3. 问题生成：使用多模态 LLM（GPT-5.1）根据视觉上下文和结构化数据生成自然语言问题。
• 分布：涵盖 6 大财务类别（资产负债表、现金流、运营 KPI、损益表、指引/展望、细分/地理），时间跨度从 2015 年至今，包含季度（59%）和年度（33%）数据。

2.2 实验设置

• 模型与配置：测试了三大前沿提供商（Anthropic, OpenAI, Google）的 14 种配置。
  • 模型：Claude Opus 4.5, Claude Sonnet 4.5, GPT-5.2, Gemini 3 Pro。
  • 模式：基础模式 vs. 推理模式（Reasoning Mode）。
  • 工具环境：
    • MCP 模式：访问结构化金融数据 API（通过 Model Context Protocol），包含 discover_companies, discover_company_series, get_company_fundamentals 三个工具。
    • WebOnly 模式：仅访问网络搜索（模拟无结构化 API 的场景）。
• 评估指标：
  • 准确性：由 LLM 裁判（GPT-5.2）进行二元判断，包含单位归一化（如“十亿”与“百万”的转换）和符号容错处理。
  • 执行追踪：记录完整的工具调用轨迹（Tool Call Traces），包括输入、输出、耗时和调用次数。

3. 关键发现与结果 (Key Results)

发现 A：工具可用性主导性能 (Tool Availability Dominates)

• 数据：Claude Opus 在使用结构化数据 API 时准确率为 90.8%，而仅使用网络搜索时降至 19.8%，差距高达 71 个百分点。
• 对比：这一差距是其他提供商（如 Google 或 OpenAI）的 3-4 倍。
• 原因：
  • 行为因素：Claude 在仅靠搜索时，有 55% 的情况是“放弃回答”（找到了信息但不敢确认），而 Google 仅为 1%。
  • 基础设施：Claude 的搜索工具仅返回片段，无法解析 PDF 表格；而 OpenAI 和 Google 的工具能获取完整页面。
• 结论：工具集成（结构化 API）比模型选择对性能的影响大 3 倍以上。

发现 B：推理模式的收益与基础能力成反比 (Reasoning Benefits Vary Inversely)

• 数据：OpenAI 开启推理模式后准确率提升 +9.0%，而 Claude Opus 仅提升 +2.8%。
• 原因分析：并非推理能力本身更强，而是 OpenAI 的基础模式在工具利用上较弱（API 探索调用较少）。推理模式帮助 OpenAI 更仔细地选择 API 参数，弥补了基础能力的不足。
• 结论：对于基础工具利用能力强的模型，推理模式的边际收益较低。

发现 C：首次查询成功驱动效率 (First-Query Success Drives Efficiency)

• 现象：正确答案通常伴随更少的工具调用。
• 机制：如果第一个 discover_company_series 调用成功（87% 的情况），代理只需 3 步调用即可达到 93% 的准确率。如果失败，代理会进入冗长的搜索循环，准确率降至 77%。
• 瓶颈：首次失败主要源于关键词匹配失败（55%）和周期过滤失败（45%）。

发现 D：地理差异源于数据惯例 (Geographic Gaps Stem from Data Conventions)

• 现象：美国公司的准确率比非美国公司高 5.6%（Claude Opus）。
• 原因：并非模型对非美国数据理解力差，而是财政年度命名惯例的差异。
  • 美国公司多为日历年末（12 月），非美国公司（如日本 3 月、印度 3 月/9 月）财政年度不同。
  • 数据源使用“起始年”标记（如 2022FY 指 2022.4-2023.3），而代理常假设“结束年”标记。
• 结论：这是数据格式问题，而非模型能力缺陷。

4. 主要贡献 (Contributions)

1. 首个结构化金融数据检索基准：填补了现有基准只关注文档检索或数值推理，而忽略结构化 API 检索的空白。
2. 多提供商、多配置对比：在相同问题集上，对比了三大厂商在“基础/推理”和“有/无结构化工具”下的表现，提供了极具参考价值的横向对比。
3. 完整的执行轨迹发布：不仅发布问题和答案，还发布了所有工具调用的输入输出日志，使得对代理决策过程（如为何放弃、为何选错周期）的细粒度分析成为可能。
4. 实证洞见：
   • 证明了在金融领域，工具集成（Structured APIs）的重要性远超模型本身的推理能力。
   • 揭示了当前金融 AI 错误的主要来源是未文档化的工具惯例（如财政年度命名、指引存储时间），而非模型理解力不足。

5. 意义与启示 (Significance)

• 对从业者的指导：
  • 优先集成结构化数据：在金融场景下，接入 MCP 等结构化 API 是提升性能的最关键因素，其效果远超更换模型或开启推理模式。
  • 关注工具描述：将准确率从 90% 提升到更高水平的关键在于完善工具文档（明确财政年度命名、周期定义等），而非微调模型。
  • 评估策略：在缺乏结构化数据时，需仔细评估不同厂商网络搜索工具的解析能力（PDF 解析能力差异巨大）。
• 对研究界的贡献：
  • 提供了一个可复现的、包含详细行为日志的基准，有助于研究代理的决策逻辑、错误模式及工具使用策略。
  • 指出了未来改进方向：解决周期惯例对齐（Period Convention Alignment）和模糊匹配问题。

6. 局限性 (Limitations)

• 单一数据源：基于 Daloopa 数据库，可能无法完全泛化到其他数据提供商的 Schema。
• 单点检索：仅评估单个数值的检索，未涉及多步计算、跨源合成或处理缺失数据。
• 单轮交互：未评估多轮对话和迭代式研究场景。

总结

FinRetrieval 论文通过严谨的实验设计证明，在金融数据检索任务中，“工欲善其事，必先利其器”。AI 代理的性能瓶颈主要在于是否接入了高质量的结构化数据工具，以及工具文档是否清晰消除了财务惯例的歧义，而非模型本身的推理能力。这一发现为构建更可靠的金融 AI 系统指明了清晰的优化路径。