一次 92 分一次 8 分，都是同一个系统：EVICALC 用 1730 道题教你做人

💡 一句话总结：这是一篇不刷榜、专发「惨案」的系统报告：同一个文档问答系统，公开验证跑出 92.17% 的答案准确率，官方终测只有 8.61% 的联合准确率——两个数字都不是造假，也不能互相解释。作者老实交代了失败分析：OCR 分块把关键段落并进了无关块，系统对着盆栽花的故事解了一道病毒传播的题。比结论更值钱的是那句话：证据没进来，算术再漂亮也是白算。

导语：你的 RAG 系统，可能正在「一本正经地答错题」

先来看一道「找不同」题。

同一个文档问答系统：在一次公开验证里，答案准确率 92.17%，证据定位 F1 满分 1.00；到了官方终测，1730 道题，联合准确率 8.61%。

如果你第一反应是「这系统是不是被人动了手脚」，恭喜你，掉进了这篇论文想戳的第一个坑：这两个数字根本不可比。验证跑和终测跑用了不同的模型配置、不同的评测口径（验证报答案准确率，终测报「答案+证据都对才算对」的联合准确率），连验证标签都被组委会赛前修正过。把它们并排一放得出「掉了 84 个点」的结论，属于典型的评估事故。

这篇发表在 DocInsights 2026（EMNLP 2026 workshop）shared task 的系统报告，作者 Divya Godara 和 Sachin Gupta（独立研究者）做了一件越来越少见的事：把 8.61% 原样端上来，然后认真复盘它是怎么来的。做文档问答、RAG 的朋友，这篇的教训密度比大多数 SOTA 论文高得多。

想自己动手试？

• 📄 论文：arXiv 2609.39013

这篇论文讲的是什么任务？

DocSem（基于 GSM-SEM 基准）是个「文档算术问答」任务：给你一份纯图像 PDF和一个改写过的问题，系统要同时交出两样东西——数字答案，以及支撑这个答案的段落印刷标识符。答案算对了、但证据块指错了，照样判错。

这比普通 DocVQA 苛刻得多：它强制系统「先找到证据，再做算术」，而且把「找到」这件事本身纳入评分。任何做过企业知识库的人都懂这个设计的现实意义——用户不只想要一个数，还想知道这个数是从哪来的，指错了来源的答案比没有答案更危险。

EVICALC 的架构反而是「教科书式」的简单：Tesseract OCR 提文本并分块 → 启发式选择器挑最相关的块 → LLM 写一个受限的算术表达式 → 本地 Python 用 40 位精度求值。数字计算交给代码，模型只负责理解和选数——这个分工本身没错，问题出在更上游。

惨案是怎么发生的？

作者人工抽查了前 120 个测试 PDF，发现测试集的画风和训练/验证集完全不同：故事化段落、行政备注、重复主题词、风格化徽章、多页混排。然后他们抓到了一个代表性案例，值得逐帧回放：

查询问的是病毒传播。渲染出来的页面上，确实有一段病毒感染的小故事，旁边还有一个印刷徽章。但在 OCR 的分块结果里，这段故事被并进了一个标题为「用途与阅读说明」的块，它自己的标识符压根没被提取出来。于是选择器的三个候选里没有它，系统最终选中了一段讲盆栽花的无关文字——然后基于盆栽花认认真真地列假设、写算式、算出了答案。

注意最后一步：计算环节完美运行，表达式语法正确、求值精确——但它从头到尾没见过真正的证据。这就是标题的含义：Evidence First, Arithmetic Second。证据是第一性的，算术是第二性的；管道下游永远无法修复上游丢掉的东西。

还有个更隐蔽的坑：作者早期试点只测了「标识符转写准确率」——20 个裁剪块读得挺准。但读对一个错误段落的标识符，照样是错的证据。标识符转写和段落选择是两件需要分开审计的事，混在一起测会互相打掩护。

比惨案更有意思的：覆盖率 22%

光看个案还不够，作者做了一个 100 份文档的探索实验：让 claude-haiku-4.5 不看问题、只读页面图像，列出「这份文档里可能有哪些文字题」（页码、开头词、主题、印刷标识符），再用本地代码把问题匹配到这个目录上。

结果很能说明问题：在有输出的那些里，80% 的选中段落被判正确、70% 的标识符转写正确——看起来挺美？但是：

• 100 份文档里 45 份根本没选出任何段落；
• 18 份选了段落但拿不到可用的裁剪位置；
• 15 份标识符读取自相矛盾；
• 最终只有 22 份返回了证据标识符——覆盖率 22%。

就算这 22 份全对，整个系统的联合准确率上限也只有 22%。换句话说，前两个漂亮的百分比是「幸存者正确率」——分母早就被偷偷换成了「成功输出答案的那一小撮」。作者把这写成一条硬建议：评估文档系统必须同时报告 coverage 和 correctness，只看「有输出时的正确率」，你永远不会知道自己丢了 78% 的战场。

做 RAG 的朋友可以对号入座：你的评测脚本里，检索失败的 case 是被记为「错误」还是被静默丢出了分母？

那 92.17% 是怎么回事？

作者的交代相当克制：那次验证用了完全不同的配置——claude-opus-5 顶着最高推理档位、每题只许一次尝试、提示里强制要求引用原文事实和显式假设；而且验证评测的是答案准确率（不含证据联合判定），标签还被修正过一轮。这些观察都是开发过程中的记录，不构成受控比较。

这句话值得单独划出来。对发论文的人：把不可比的数字放在同一张表里、加脚注说「不可比」，比遮遮掩掩只报好数字体面得多。对读论文的人：以后看到「同一系统两个分数」先查配置和口径，别急着惊叹或者群嘲。

能拿来做什么？

这篇没有可复用的 SOTA 方法，但它给的排查清单几乎是免费的：

• 文档 QA 报障时先看证据链：答案离谱，先确认相关段落有没有进入上下文，再去调提示词和模型——顺修上游，下游自愈；逆着修，白费劲。
• 评测分母要审计：把「无输出」「检索为空」「证据缺失」明确计入失败，单独统计覆盖率，别让幸存者偏差美化你的报表。
• 引用质量拆开验：引用文本转写对不对、引用的段落选没选对，分开测、分开报。
• 验证分数不进汇报 PPT：开发和评测配置不同的数字，写进文档时要标注「开发观察，非受控比较」——这篇论文本身就是范本。

泼冷水时间

这篇的局限作者自己也写得明明白白，这里挑三个最需要注意的：

• 没有受控实验：8.61% 到 92.17% 的差距无法归因到单一因素；失败分析是前 120 个 PDF 的方便样本，不是全量统计。
• 100 文档研究的正确性判断是本地人+辅助模型的读图估计，没有评分者间一致性报告，只能当描述性证据。
• 系统本身偏弱：Tesseract OCR + 启发式选择器在 2026 年算相当保守的配置；「证据先行」的教训来自一个弱管线的失败复盘，换成现代强模型管线，各失败模式的占比会很不一样——教训的方向有效，比例不可迁移。

理性看待

在一个人人把「92.17%」写进标题的时代，有人认认真真写了一篇「8.61% 是怎么回事」。这篇论文没有提出新方法，但它示范了两件越来越稀缺的事：一是对不可比数字的诚实标注，二是对失败案例的逐帧解剖。文档问答的真正难点从来不是「算术算得对」——40 位精度的 Decimal 谁都能调——而是「证据有没有被完整、正确地送进上下文」。OCR 的一个分块错误，就让下游最强的推理模型变成了一位「对着盆栽花解病毒题」的认真学生。

下次你的文档系统给出一个荒谬答案时，先别改 prompt。去看一眼，证据到底进没进来。

（数据与结论均来自论文原文，解读部分为作者观点，欢迎交流。）