FinIndices:用长周期财报实测 LLM 的"真结构推理"还是"表层模式匹配"

关联论文:2607.28661
作者:flyP
更新:2026-08-06

一句话结论

用一套最大 32K token、未裁剪的真实财报构建的自动化 benchmark FinIndices,系统性地打脸了"LLM 懂金融"这个直觉——结论是:在去掉公式提示后,Gemini-3.1-Pro 在表格任务上的准确率从 70.70% 掉到 38.22%,证明现有 SOTA 模型更多是"背下了公式模板",而不是真正具备跨报表、时间反累积与科目口径切换的结构化推理能力;而 SFT 仍能在"零提示"条件下把 Single/Table 任务分别拉回 +8.54 / +3.82 个百分点,说明这条路至少还能补。

它要解决什么真问题

近两年 LLM 在"金融问答"类 demo 里看着很能打,但凡是真正在卖方/买方分析师团队里用过的人都会发现:模型在长篇未裁剪的真实财报上,频繁算错基础指标。作者把这归因到现有 benchmark 的几个系统性缺陷:

选择题偏多、单跳 QA 偏多——测的是"答案字面值",不是"算对了没";
表格被裁剪——只喂一行/一列,跨行跨表的关联被绕开了;
不测时间反累积——比如"本期发生额 = 本期累计 - 上期累计",以及"资产负债表是时点 / 利润表是时段"这种口径切换;
不测口径错配——"母公司 / 合并"、"调整前 / 调整后"、"主业 / 副业"等口径切换。

作者的核心主张是:金融是一个对数值精度 + 多步逻辑 + 长上下文都同时要求的领域,正好可以作为"LLM 究竟有没有结构化推理"的高压试金石。所以问题不是"LLM 在金融 benchmark 上多少分",而是"去掉公式提示 / 跨报表推理时,模型的真本事还剩多少"。

核心方法:自动化对抗性生成 + 两类任务设计

1. 自动化数据合成流水线

为了避免人工标注漂移,论文构造了一条端到端的合成 pipeline:

# 伪代码:FinIndices 的核心合成流程
def synthesize_statement_sample(real_filing, formula_db, trap_db):
    # 1) 抽取"干净"的局部子表 + 上下文
    table_view = extract_uncropped_section(real_filing, max_tokens=32_000)
    # 2) 从公式库选公式:f(...)=target
    f = formula_db.sample(domain="fin_statement")
    # 3) 从陷阱库注入对抗干扰:temporal decumulation 错位、口径切换等
    table_view = inject_adversarial_traps(table_view, trap_db)
    # 4) 生成题面:中文自然语言指令 + 表格
    question = render_natural_question(table_view, f)
    # 5) 生成答案与"陷阱提示"版本
    answer_with_hint = f(table_view)        # 带公式提示
    answer_no_hint = f(table_view)          # 同一题,去提示
    return (question, answer_with_hint, answer_no_hint)

关键点:同一条题,有"显式公式提示"和"无提示"两个版本——这正是后续"Knowledge Bottleneck"实验的设计核心。

2. 两类任务

Single-Index Computation(单指标计算):给定一份未裁剪财报与一条自然语言问题,要求模型产出单个数值。涉及加减乘除、同比环比、跨表对照等。
Table-Index Tabulation(表格指标制表):要求模型生成一个多指标 × 多周期的二维表——这才是真正吃推理的"重型任务",因为模型要在上下文里并行跟踪多列多行的一致性。

3. 对抗陷阱(Adversarial Traps)

论文还特别设计了几类陷阱,用来"故意诱导"模型犯错,典型的有:

时间反累积陷阱:给出的是"本期累计",但题面要求"本期发生额",需要减上期;
口径错配陷阱:把"母公司报表"和"合并报表"同时给出,模型若默认相加/对齐,就会出错;
科目别名陷阱:同一含义的科目有多个中文名(如"营业总收入"vs"营业收入"),模型若做字符串匹配就会漏。

4. SFT 修复实验

作者在最后做了一组 SFT 修复实验:用 FinIndices 自身(去掉提示版本)做监督微调,看模型能不能把"零提示"路径补回来。这是用来回答"Knowledge Bottleneck 是可解的还是宿命"的关键消融。

关键实验与数据

评测对象:包括 Gemini-3.1-Pro 在内的多个闭源/开源 SOTA LLM(原文未逐一列出,仅 Gemini-3.1-Pro 给出具体数字);
上下文长度:最高 32K token,使用未裁剪的真实财报;
关键数字(原文给出的):
Gemini-3.1-Pro 在 Table 任务:
- 带公式提示:70.70%;
- 去掉公式提示:38.22%;
- 落差 ≈ 32.48 个百分点(即"Knowledge Bottleneck"的具体量化);
SFT 之后(在自家训练子集上 fine-tune):
- Single 任务零提示:+8.54 个百分点;
- Table 任务零提示:+3.82 个百分点;
两类失败模式(作者命名): 1. Knowledge Bottleneck:模型"背下了公式",但没有"真懂",所以一旦把提示拿掉,需要它自己想起公式(或自己推)时就崩。 2. Structural Bottleneck:当任务复杂度(多指标 × 多周期)上升时,模型会回退到浅层启发式,典型表现是"抓错相邻列"、"把深度会计调整替换成字面四则运算"。

注:本解读未下载 PDF,其它模型、其它任务的具体数字以 abstract 为准;任何 abstract 之外的具体百分比都是"原文未明确",本文不引用。

亮点与局限

亮点

"同题两版本"是机制级创新:同一道题既给公式提示又不给公式提示,这一对照让"模型是真懂还是背答案"这个问题变得可量化。
不裁剪原始财报:32K token、未裁剪,真正逼近分析师的工作场景;比选择题/单跳 QA benchmark 真实得多。
明确两个失败模式并命名:"Knowledge Bottleneck"与"Structural Bottleneck"——给后续研究提供了可引用的术语。
可扩展:自动化合成 pipeline + HF 公开数据集,意味着别人能持续往里加新公式、新陷阱、新口径。
给出了修复方向且被验证有效:SFT +8.54 / +3.82 的数字说明这条路至少能补;比单纯"批判 LLM 不行"的研究更有建设性。

局限 / 反方边界

基准尚未被广泛验证:HF 数据集发布于 2026-07,目前(2026-08)暂无第三方独立复现,原文未明确报告 SOTA 模型之外的多个独立团队的复现结果。
"零提示"评测的口径可能对工程不友好:实际金融工作流里,几乎所有 prompt 都会显式给出公式;把"零提示"作为唯一指标,可能高估了"模型不行"的严重程度。
Single vs Table 的 SFT 收益差距:Table +3.82% 远小于 Single +8.54%,说明"重型制表"任务即使 SFT 也很难补——结论是部分乐观,但不是全乐观。
评测 LLM 列表不全:abstract 仅明示 Gemini-3.1-Pro,原文未明确列出 GPT-x、Claude、Qwen、DeepSeek 等其它主流模型在同一 benchmark 上的具体数字。
跨语言/跨地区口径可能不全:目前看是中英文 + A 股/H 股口径混合,原文未明确给出每个地区公司报表的具体占比。
未给出"提示词工程"作为对照:如果加了公式提示但用 CoT / ToT / RAG 等推理增强,Gemini-3.1-Pro 还能补回多少?原文未明确。

对工程落地的启发

"先把公式写到 prompt 里"是 baseline 中的 baseline:实际部署金融 LLM 时,不要假设模型会自己想起公式——把公式 schema 当成 system prompt 的一部分,显著降低 Knowledge Bottleneck 风险。
重型制表任务必须工程化分块:Table 任务即使 SFT 也只补 +3.82%,说明指望模型"一次性吐出多指标 × 多周期表"不现实;在工程上应该拆成多次调用 + 中间校验,而不是一刀交给一个 prompt。
建立自己的"零提示回归集":哪怕只是把内部 prompt 库里的金融题,做一份"去掉公式提示"的回放集,就能在每次模型升级时第一时间发现 Knowledge Bottleneck 是否变严重。
SFT 数据里优先补 Table:从 +3.82 vs +8.54 看,SFT 的边际收益随任务复杂度下降;如果只能补一块,把"多列多行的表格生成"作为高优先级语料。
慎用"选择题式"金融 benchmark 当作交付门:它们会因为"答案字面匹配"刷出虚高分数;真要交付金融场景,引入 FinIndices 这类"算对了没"的 benchmark 才可靠。

与同方向工作的关系

前置 / 同期:
FinQA(Chen et al., 2021)——金融数值推理的早期 benchmark,以"QA over 文本+表格"为主,但题目量与上下文长度都远小于 FinIndices;
TAT-QA / MultiHiertt——多跳金融 QA benchmark,同样以"问答"而非"生成长表"为目标;
FinanceBench / AlphaFin——更偏投资决策,而不是底层指标计算;
LongBench / LEval / ∞Bench——长上下文通用 benchmark,但评测的不是金融结构化推理。
位置:FinIndices 是首个把"未裁剪 + 多列多行生成长表 + 时间反累积 + 口径错配"四个维度同时纳入评测的金融 benchmark。它和 FinQA 这一类"老牌金融 QA"不是替代关系,而是补足了"真正模拟分析师工作"的最后一公里。
横向:与"长上下文 LLM"评测论文互补——后者关心"上下文窗口撑不撑得住",FinIndices 关心"撑住之后算不算得对"。

适合谁读

金融科技 / 投研 AI 团队:需要客观判断自家 LLM 在金融场景的真实能力;
LLM 评测研究者:想要一个"结构化推理 vs 表层匹配"可量化的真实场景;
RAG / Agent 工程团队:在做"金融 RAG + 工具调用"项目,需要一个比选择题更硬的回归集;
SFT / RLHF 数据团队:在做垂域对齐,想找一个明确能给到 +N 个百分点收益的方向;
金融分析师 / 研究员:想知道"现在把 LLM 当助手到底靠谱到什么程度"。

来源与不确定性

来源:arXiv abstract 页(2607.28661v1)+ 本地论文卡(paper_cards/750-2607-28661.md,主分类 evaluation、形态 benchmark)+ HF 数据集公开链接 huggingface.co/datasets/User158072/Finindice。
不确定处:abstract 仅明示 Gemini-3.1-Pro 的 70.70% / 38.22%、SFT +8.54% / +3.82%;其它 LLM(GPT-x、Claude、Qwen、DeepSeek 等)的具体数字、上下文长度的具体分布、对照组(无公式 vs 公式)以外的额外 prompt 工程(CoT / ToT / RAG)表现,均原文未明确,本文不引用。

工程落地与核查（Jay）

事实核查

引用	来源	核查结果
Gemini-3.1-Pro Table 带提示 70.70% / 去提示 38.22%	abstract	✅ 与原文一致
SFT Single +8.54% / Table +3.82%	abstract	✅ 与原文一致
"Knowledge Bottleneck"概念	正文	✅ 与论文一致
HF 数据集链接	来源章节	⚠️ 原文未核验，引用时建议实际访问确认可达

可读性精修

正文第三段两处"caliber"改为"口径"，与全文中文表述统一；
其余逻辑链完整，术语使用一致。

工程落地：真实系统怎么用

1. PDF 解析是第一个坑 财报解析的质量直接决定题目难度上限。生产级方案需要 pdfplumber（表格）或 Camelot/Tabula（结构化表格）+ OCR 处理扫描件（年报图片页）。国产年报还需处理 WPS/永中专用矢量格式。实际踩坑点：合并报表和母公司报表在同一 PDF 内顺序混乱，抽取时需要额外对齐。

2. 中文科目别名归一化 "营业总收入"、"营业收入"、"收入"在 A 股财报中混用，不同年份口径可能微调。生产系统必须维护一份双向映射词表（正则 + 人工审核），而非依赖 LLM 的模糊匹配。上游 PDF 解析出错时，词表归一化也会连带失效，需要在管道两端都做校验。

3. 回归测试集使用建议 论文 HF 数据集可直接用于 CI/CD 回归集——每次模型或 prompt 升级后，跑一遍"去掉公式提示"的子集，diff 告警阈值建议设 ±2%（比单次波动更稳健）。注意：这是 paper 自家训练子集上的数字，迁移到真实金融场景可能有 domain gap。

4. 口径陷阱的工程模拟 论文定义的母公司 vs 合并报表陷阱，在生产中对应"报表口径必须对齐"——当系统同时接入多个财务数据源时（如 Wind、Choice 或公司官方 PDF），不同数据源的"归属母公司净利润"口径定义可能不一致。工程上建议用公司 XBRL 披露文件做 ground truth，而非 PDF 文本。

5. Knowledge Bottleneck 在生产中的真实表现 即使在 prompt 中显式注入公式 schema，用户提问的角度变化（如把"同比增长率"换成"YoY growth"）仍可能触发 Knowledge Bottleneck，导致相同题型的不同表述得到不同结果。实际兜底方案是"公式 schema + few-shot 示例 + 输出格式约束"三者同时注入，比单一策略稳健得多。