? 文 / 老Z

一个智能体拿到一份几十页财报，几秒钟后给出一段像模像样的分析：收入增长、利润改善、现金流承压，语气稳得像投研晨会。问题在于，它可能把去年和今年混在一起，把合并口径当成分部口径，或者漏掉表格旁边那句限定说明。金融场景里，这类硬错误会直接改写判断方向。

这正是 FinanceComplexQA 想抓住的矛盾：大模型和智能体已经很会“回答”，但金融分析要求的是证据、数字、时间、单位、业务含义同时对齐。一个答案只要有一处链条断掉，看起来越专业，风险反而越隐蔽。对技术团队来说，更难的是让系统知道自己到底用了哪张表、哪个期间、哪种口径。

会检索，不代表会做金融分析

过去不少金融问答基准，重点放在表格计算、短上下文抽取、财报片段问答，或者开放式问题的某一个侧面。它们很有价值，但离真实工作台还有距离。分析师读一份报告时，很少只找一句话；更常见的是在正文、表格、脚注、页内说明之间来回跳，再结合会计口径和行业逻辑给出判断。

FinanceComplexQA 把测试对象拉到这种更麻烦的环境里。它包含 1009 份金融文档和 2026 个深度研究任务，中文问题 1013 个，英文问题 1013 个。文档来自公司财报、投资策略报告、市场趋势分析、金融科技研究、银行财务报表、客服记录、监管合规审计、政府财政公告等场景。任务也不只是“查一个数”，还包括比较、隐式推理、多跳判断、摘要、规划等。

表 1 的对比很直观：FinanceComplexQA 同时要求 PDF 解析、长文档、跨版面、开放式回答和多维评价。它考的已经超出从表格里拿一个数字，问题变成：当答案散落在一整份金融材料里时，系统能不能像分析师一样把证据串起来。

还有一个容易被忽略的细节：这些文档并不短。论文统计的平均页数是 16.33 页，平均长度 16493；中文文档平均 18.01 页，英文文档平均 13.58 页。投资策略、市场趋势、银行报表这类材料，本来就有大量章节、表格、说明和跨页引用。把它们粗暴切成碎片，很多关键信号会在切块边界处丢失。

真难点藏在表格、脚注和业务常识之间

这套基准最关键的设计，是“双上下文”。显式上下文来自文档本身，比如段落、表格单元格、图表标签、标题、说明文字；隐式上下文来自金融知识，比如毛利率变化怎么解释、现金流和利润背离意味着什么、周期行业的增长该怎么看、某个监管条款约束的是哪类主体。

这就让问题变得很不适合简单切块检索。一个段落可能说公司加强成本控制，表格显示毛利率上升，另一处说明收入增速放缓。只抓到成本控制那句，答案会显得乐观；把三处证据合在一起，结论可能要克制得多。

数据构造也服务于这个目标。研究团队设计了一个面向金融文档的排版生成技能，用来生成 2000 份专业金融文档和 6000 个高质量问答样本。这批合成数据不混入正式测试集，而是用于开发、压力测试和扩展。正式的 FinanceComplexQA 仍然围绕 1009 份金融文档来做评测。

图 2 展示了任务分类。中文侧有比较、隐式推理、知识查询、多跳推理、摘要、规划；英文侧有数值比较、隐式推理、多跳判断、显式推理、摘要、规划。它们不追求把能力切得很干净，而是模拟真实问题：一个请求往往同时需要找证据、算数字、做判断、写成可交付的分析。

评价也不是只看答案像不像参考文本。它用 Agent-as-a-Judge 检查准确性、数值正确性、证据覆盖、忠实度、完整性和成本。这个设计很贴近金融落地：一个回答可以文字流畅，却少了关键证据；也可以证据都在，却把符号、单位或期间处理错。单一分数很难解释这些问题，多维度评分更适合定位系统短板。

我觉得这里最像生产环境的一点，是它把“能答”和“能交付”拆开了。金融业务里，答案通常要经得起复核：客户问的到底是哪家公司，期间是否一致，口径有没有变，表格旁边的备注是否限制了结论。FinanceComplexQA 把这些复核点做进任务和评价里，才让榜单不只是模型文笔比赛。

榜单很热闹，结论却不适合狂欢

实验里比较了轻量检索、版面感知检索和智能体式系统。结果没有给出一个“全场通吃”的赢家，反而更像一张工程体检单。

PageIndex 相比 LightRAG 的提升很明显。场景级结果里，PageIndex 的中文整体分数是 72.15，LightRAG 是 62.42；英文整体分数是 66.90 对 59.92。中文投资策略报告这一项，LightRAG 得到 41.46，PageIndex 到 64.78，提升 23.32 分。这说明保留页结构、表格上下文、相邻说明，对金融文档问答属于基本能力，谈不上锦上添花。

智能体系统确实更强，但强得不整齐。表 5 里，Claude Code 搭配 Sonnet 5 拿到中文场景整体 76.01、英文场景整体 69.39，是该表最强的整体配置。表 7 从任务均值看，Codex 搭配 GPT-5.5 在封闭模型设置里最高，中文 60.63、英文 62.97；开源配置里，Codex 搭配 DeepSeek-V4-Flash 最强，中文 60.44、英文 61.55。

更有意思的是，任务优势会分裂。PageIndex 在知识查询、多跳推理、数值比较、多跳判断和规划准确性上很有竞争力；Codex 风格系统在隐式推理、显式推理和整体均值上更强；Claude Code 风格系统在若干中文场景，以及规划任务的忠实度、覆盖率上表现突出。这说明金融智能体不是单项能力比赛，检索、计算、规划、证据覆盖很可能不同步提升。

代价也摆在桌面上。LightRAG 平均每题约 12.8k tokens、8.6 秒；PageIndex 约 15.6k tokens、11.9 秒。智能体系统常常升到 31.4k 到 45.8k tokens，耗时 22.8 到 50.6 秒。对金融助手来说，这意味着不能把所有问题都丢给完整智能体循环。简单知识查询走便宜路径，版面敏感问题走结构化检索，高风险推理再启用完整智能体，才更像可落地方案。

这点很硬。

论文的 human evaluation 也在提醒同一件事：自动评审可以扩大规模，但金融答案最终要经得起熟悉材料的人抽查。尤其是开放式生成题，模型可能把证据链写得很顺，却在单位、期间或合并范围上错一格。产品上线时，这种错误比“答不上来”更麻烦，因为它会让审核者放松警惕。

这套 benchmark 还有一个现实价值：它把中文和英文材料放在同一张桌子上。很多金融系统在英文年报上调得不错，换成中文招股书、公告和研报后，问题会立刻变多。原因不神秘，中文材料里的表格标题、项目口径、附注位置和英文披露习惯不完全一样，模型如果只是学会了英文模板，到了中文场景就会把相近栏目硬凑在一起。FinanceComplexQA 把这些差异单独统计出来，提醒团队别用一套英文 demo 的效果去推断双语金融产品的可靠性。

最怕的答案，是错得很专业

我更关注表 8。它列出的失败模式，比排行榜更有价值：数值漂移、证据遗漏、版面混淆、过度综合、弱规划。

数值漂移最典型。系统可能用了看似正确的计算思路，却选错期间、分母、单位或符号。证据遗漏也很常见：答案引用了一个段落，却漏掉必看的表格或图表。版面混淆更隐蔽，行标题、列年份、脚注、表格说明一旦和数值脱钩，模型仍然可以写出流畅解释，只是解释对象已经错了。

过度综合是金融问答里的老问题。模型会补上一些听起来合理的行业判断，但文档并没有支撑。弱规划则出现在规划类任务里：回答给出通用步骤，看着像咨询建议，却没有围绕这份材料里的证据展开。论文里的人类评测样本也提醒了这一点：难度不只由长度决定，有些较短子集依然会让评审结果很差，说明领域结构和证据关系同样关键。

所以 FinanceComplexQA 的意义，不是宣布哪个智能体已经可以替代金融分析师。它真正提醒工程团队的是：金融智能体要可靠，不能只堆更强模型。系统需要在生成答案前列清证据类型，确认段落、表格、说明是否齐全；需要让表格标题、单位、时间范围和数值绑定在一起；需要对计算结果做独立校验；还需要按问题难度做成本路由。

金融文档不是普通长文本。它的难点不只在长度，更在每个数字背后的口径和关系。FinanceComplexQA 把这些麻烦集中摆到台面上：会检索只是起点，会把证据读对、算对、说得有边界，才是金融智能体真正要过的关。

✍️ 老Z ·
欢迎转发，谢绝洗稿