论文复现Agent的PDF解析优化：从54分到92分的实战复盘

那段时间我手上正好在搭一个论文复现 Agent，简单说就是扔给它一篇论文的 PDF，它自己读、自己写代码、自己跑实验、最后跟我汇报结果。听起来很美好对吧？真正跑起来才发现，第一步的 PDF 解析就把整个系统拖进了泥潭。第一次完整评测下来，解析模块只有 54 分，代码写得再好也补不回来——因为后面所有环节读到的都是残缺、错位、幻觉遍布的论文内容。后来我把解析管线从一个“能抽出文字就行”的工具，逐步做成了一条带 Agent 自校验的完整链路，最终把分数拉到了 92。整个过程前前后后折腾了三周，踩过的坑能写满一页纸，今天就把这段“西游记”完整复盘一遍。

1. 为什么 PDF 解析会成为论文复现 Agent 的命门

1.1 论文复现 Agent 的完整链路，以及解析模块的位置

先把我当时设计的 Agent 工作流程摆出来，大家就明白问题出在哪了。整个流程分六步：

1. 输入论文 PDF，解析成结构化文本。
2. 基于解析结果，抽取任务描述、模型结构、损失函数、数据集、评估指标、关键超参数。
3. 检索代码仓库和工具库，找到可复用的实现。
4. 生成复现代码，并生成运行配置。
5. 在沙箱环境执行代码，跑训练和评测。
6. 对比论文报告的结果，输出复现报告。

你注意看，第二步到第六步的所有输入，全都来自第一步。解析出来的内容里少一张表，后面复现实验就少一组对比数据；公式错一个下标，代码里就多一个莫名其妙的 bug；图表里的趋势信息没提取出来，报告里就只能写“未能复现该图结论”。这就是典型的漏斗效应——入口处漏掉 20% 的信息，到了最终输出端可能已经丢掉了 50% 的可靠性。所以我在第三次重写系统时立了一个死规矩：解析模块不达标，绝不往下走烂路。

1.2 “54 分”是怎么打出来的

先解释一下这个分数，不然“从 54 到 92”就是一句空话。我当时没有用现成的解析评测集，因为市面上的评测基准偏重自然文档（合同、报表、网页），对论文这种密集排版、含公式表格图表的多栏版式覆盖很少。所以我干脆自建了一个 30 篇论文的黄金集，覆盖机器学习、计算机视觉、自然语言处理几类典型论文，人工标注了每一篇的五个维度，再让解析系统输出同样格式的结构化 JSON，逐字段打分：

那个 54 分就是这套评分体系下的综合结果。单独看各维度的话，文本还原大概 16 分左右，不算太惨；但表格还原只有 8 分，公式还原 9 分，图表信息提取只有 6 分，下游可用性更是惨到 4 分。说直白点，这个 Agent 在当时就是个“能读标题的残疾读者”，连论文里的实验结果都看不明白。

1.3 为什么现成工具全军覆没

我一开始想的很简单：PDF 解析这问题总该有成熟方案吧，直接用现成库不就行了。结果把常见路线挨个试了一遍，没有一个扛得住论文场景。

• 纯文本抽取路线（类似 PDF 文本提取库）：对排版简单的文档很好用，但一碰到双栏论文就乱序，经常把左栏读到一半跳到右栏，表格里的空格被吃掉，公式变成天书。
• 传统 OCR 路线：对扫描版论文有一定效果，但公式和表格结构识别能力很弱，尤其是数学符号密集的区域，输出基本是乱码级别。
• 通用多模态模型直接读图：这个思路看起来最“智能”，把整页 PDF 渲染成图片丢给模型，让它输出 Markdown。实测下来版式理解确实强，但幻觉问题严重——表格里没有的数它能给你编出来，公式里的几个符号它也会自作主张“修正”，这对复现场景是致命的。

试完这几条路之后我确认了一件事：在论文复现这种要求“尽量保真”的场景里，任何单一方案都不够，必须做一套组合管线，让不同引擎各干各擅长的活，再统一收敛到一份可信的结构化文档。这才是整个项目真正的起点。

2. 论文 PDF 解析的四大关卡，每一关都是坑

2.1 第一关：文本与版式——双栏、页眉、脚注和阅读顺序

很多人觉得文本抽取是最没技术含量的，实际上论文版式是普通文档的“地狱难度”。双栏排版是最基础的坑，PDF 的文本对象是按物理位置存储的，不一定按阅读顺序输出。如果不做栏区检测，一段文字读起来就是左右左右跳的。更麻烦的是脚注、页眉页脚、参考文献编号混入正文，还有图表标题被截断成半句话。

我当时给这一关定的方案是：把页面内容按坐标做区域划分，识别出栏区、页眉页脚区、正文区、图表区，再按栏区内的 y 坐标排序重组阅读顺序。这个步骤不做，后面的表格和公式定位全是空中楼阁。效果也立竿见影，文本还原分从 14 提到了 18，下游任务里至少正文上下文不再乱序了。

2.2 第二关：表格——论文里最要命的结构化信息

论文的实验结果表承载了 80% 的对比性信息，一张表读错了，后续复现实验就是在跟空气比。表格识别难在三点：跨页表、三线表、复杂表头。

跨页表是指一张表分两页打印，第一页只有表头和前几行，第二页直接续后半截，如果不做表头复用和表格拼接，解析结果就少一半数据。三线表是论文排版里最常见的样式——只有顶线、栏目线、底线，视觉上特征极弱，OCR 经常把整张表当成三行普通文字。复杂表头更头疼，多级表头带合并单元格，行列对应关系错一个，后续数据处理就崩。

表格这一关让我彻底放弃了“通用模型一步到位”的想法，改成“定位 + 裁剪 + 专用结构识别”的路线：先用版面模型找出表格区域，把区域裁剪成图片，再用表格结构模型去还原行列坐标，最后按坐标把识别出的单元格文字回填成 JSON 二维数组。这个过程很啰嗦，但每一步错了都能单独排查，比黑盒一步输出靠谱得多。

2.3 第三关：公式——LaTeX 还原是复现代码的基础

论文公式是代码生成环节最直接的输入之一。损失函数、注意力计算公式、更新规则，这些在正文里往往用渲染后的公式图片呈现，文本层要么没有，要么是乱的。解析阶段需要把这些公式转成 LaTeX，后续才能翻译成 PyTorch 或 TensorFlow 代码。

公式识别的难点主要在小细节：上下标、多行分段、矩阵括号、求和符号的上下限。主流的公式转换工具对这种密集数学版式都有不错的表现，但一旦遇到多行公式或矩阵，输出里就会出现括号丢失、上下标错位的问题。而这些细节恰恰是复现代码的命门，代码里少一个大括号，损失函数就从字面上变了意思。

所以公式这关我没有直接信任单一工具，而是加了一道“视觉校验”：把公式渲染成图片，用多模态模型对照检测 LaTeX 是否忠实表达，发现问题就触发二次识别。这一步单独把公式还原分从 9 拉到 14 左右，全链路的效果非常直接——代码生成阶段的语法错误明显减少。

2.4 第四关：图表信息提取——正文之外的半壁江山

论文里很多关键结论不在文字里。性能曲线图的趋势、不同模型在长尾分布上的差异、消融实验的柱状对比，这些信息往往只有图，正文只配一句话带过。复现报告如果想“像人一样读懂论文”，图表信息就必须被提取为结构化描述。

图表这关我踩过最深的一个坑是“模型幻觉图表结论”。第一次让多模态模型直接描述整张图，它回复“模型B在低资源设置下显著优于模型A”，我拿原图一看，数据点根本没几条，完全经不起推敲。后来我把图表任务拆成了两步：先让视觉模型做“读数”——提取坐标轴标签、单位、图例、大致趋势，再做“总结”——基于读出的客观事实生成描述，禁止输出数据中没有的对比结论。幻觉比例一下降了很多。

图表信息提取的整体思路就是：不让模型“想象”，只让它“转述”。坐标轴、图例这些是板上钉钉的信息，必须原样提取；趋势分析是推断层，必须在客观信息之后生成，且要有数据支撑。

3. 从 54 到 92 的实操路径：每个关键决策和它背后的理由

3.1 先把评估集和评分脚本固定下来，否则一切优化都是玄学

我在做任何优化之前，先干了一件苦力活：把黄金集的标注规则写死，写评分脚本，每次改动都跑同一个评估流程。这件事看起来慢，实际省了后面好几天的无效调试。

人工标注规范我只定了三条硬性原则：一是结构化 JSON 里每个字段的来源都必须在 PDF 原页有坐标可查；二是表格单元格的数值不允许任何“修正”，原文写错也照抄；三是公式 LaTeX 必须保持语义一致，允许等价形式但禁止省略。三条原则对应三个核心风险：幻觉、篡改、遗漏。评估脚本则逐字段对拍，统计五维分数和总分，每次改完管线自动出一份对比报告。

没有这套评估体系之前，我很容易被“这次好像效果好一点”的感觉带偏。有了固定标尺之后，每次优化是涨了三分还是跌了两分，一眼就能看出来。这也是后面我能准确说出“从 54 到 92”这句话的原因——每一步都有数据支撑。

3.2 核心架构选择：双通道解析加 Agent 自校验循环

单引擎方案全军覆没之后，我定下了整个解析模块的骨架：双通道解析。通道 A 是文本引擎，负责从 PDF 文本层提取坐标、字符、位置关系，适合处理正文、表格文字、页码等“物理存在”的信息；通道 B 是视觉引擎，负责版面识别、图表理解、公式校验，适合处理需要“看”的信息。

两个通道并行输出中间结果，然后做后期融合（late fusion），统一成一份文档 Schema。融合不是简单的拼接，而是以文本引擎的坐标信息为骨架，用视觉引擎补足结构和语义。举个例子：表格区域先用文本引擎定位行列坐标，再用视觉引擎验证合并单元格和跨列关系，两边一致才写入最终 JSON；不一致的字段标记为“存疑”，交给 Agent 校验环节处理。

Agent 自校验循环是当时提升最明显的一步。解析结果生成后，会用一组“信息完整性检查器”去扫：论文里有没有丢失章节，表格行数是否与原文一致，公式里的变量是否都定义了初始值。一旦检查器发现异常，就定位到具体页面区域，触发定向重解析，而不是把整篇 PDF 重跑一遍。这个循环让下游可用性从 4 分直接跳到 12 分，因为很多“残缺问题”其实不是引擎识别不了，而是第一遍漏了，重试一次就能补上。

3.3 分阶段优化的里程碑记录

为了给大家一个可参考的演进路径，我把几个关键节点列出来，每个节点做了什么事、涨了多少分、为什么有效，都写清楚。

第一个里程碑是把文本版式排序重做，文本还原分从 14 涨到 18，总分从 54 到 63。这个阶段的改动不复杂，就是加了更可靠的栏区检测、段落合并规则、表格标题识别，但收益很大，因为后面所有模块都在正确阅读顺序的基础上工作。

第二个里程碑是表格识别升级，从“全页丢给模型”改为“定位裁剪加结构还原”，表格还原分从 8 涨到 16，总分到 71。核心改进是引入了版面模型做表格区域定位，再按表格线坐标做单元格切分。这个方案虽然传统，但稳定性和可解释性远超一步到位的黑盒方案。

第三个里程碑是公式视觉校验链路，公式还原分从 9 涨到 14，总分到 78。这次改动把公式识别的错误模式从“随机错误”变成了“可检测错误”，校验器能拦下相当一部分错误。虽然提分幅度没表格那么大，但因为公式直接影响代码生成，这个 5 分的提升在端到端效果上被放大了。

第四个里程碑是图表信息提取重做，图表信息分从 6 涨到 13，总分到 85。这个阶段的改造核心是“读数、总结分两步走”和“幻觉规则约束”，模型的稳定性上来了，编造结论的情况大幅减少。

最后一个里程碑不是某个模块的升级，而是把前面所有模块接入 Agent 自校验循环，让总分从 85 跳到 92。这一步没有新增识别能力，但补回了大量遗漏和边缘 case，下游可用性直接拉满。

3.4 参数选择与成本控制的实际经验

整套管线里涉及很多参数选择，我在这里挑几个最影响效果的讲讲。

图像渲染分辨率是最基础也最容易翻车的参数。解析模块需要把 PDF 页面渲染成图片时，分辨率低了，小字号字符和表格线模糊；分辨率高了，API 成本和内存都翻倍。实测下来，论文场景里 144 DPI 是一个值得记住的分辨率起点。低于这个值，公式上下标和表格细线经常出问题；高于 200 DPI 收益微乎其微，但成本可能翻几倍。我最后固定在了 144 到 160 DPI 之间，看论文原图质量微调。

视觉模型识别的温度参数必须压到最低。多模态模型做理解任务时，温度越高越容易出现幻觉，在“忠实提取”任务里完全不能容忍。我当时直接把温度设成 0，任何概率性不一致都不允许出现。很多人忽略这一步，导致识别结果不稳定，同一篇论文跑两次获取不同内容，这在复现场景里是灾难。

成本控制则是另一个现实问题。完整跑一遍 30 篇论文的黄金集，视觉引擎的调用量大概在 400 到 600 次之间。缓存做得好的话，同一篇论文的同一页面不会重复调用；Agent 校验循环触发的定向重解析也会因为缓存在第二次跑的时候几乎不产生额外成本。建议所有解析结果都落盘缓存，文件名按“论文 ID + 页面号 + 模块名”组织，排查问题时能快速定位。

4. 那些让人崩溃的疑难杂症：排查实录与避坑指南

4.1 扫描版论文：文本引擎完全失效，只能硬走视觉

论文来源五花八门，有些会议的历史论文只有扫描版，PDF 层里根本没有文本对象。这种论文对双通道架构是个大考验，文本引擎直接输出空结果，所有信息只能靠视觉引擎扛。

我的处理方案是：检测到单页文本字符数低于阈值，就把该页标记为“纯扫描页”，跳过文本引擎，直接渲染高分辨率图片走视觉识别，同时在最终 JSON 里打上“来源：扫描版”的标记，提醒下游 Agent 这部分内容置信度偏弱。这个标记很重要，因为扫描版识别即使做得不错，也难免有识别噪声，下游生成代码时看到标记后会更谨慎地处理数值类信息。

4.2 表格错位，但肉眼看不出来

表格识别里有个非常隐蔽的问题：行列数都对，但某个单元格的内容“串位”了。比如第二行第三列的值本来是 0.832，识别的结果把第三行第三列的 0.841 填了过去。这种错误从结构上看完全不明显，只有跟原文逐格核对才抓得出来。

我在排查中总结了一个有效技巧：对表格数值列做“类型一致性”检查。论文实验结果表通常是浮点数，同一列里的数值格式应该一致。如果某列混入了小数点位数明显异常、带单位文本或用逗号分隔的数，基本可以判定表格识别在这行出了问题。这个检查不需要理解语义，只做格式校验，但能拦下不少隐蔽错误。

表格跨页问题也归入这一类。跨页表被识别成两张独立表之后，下游会把它们当成两个实验，产生大量错误结论。我的解法是在表格结构还原阶段增加“表头连续性检测”：如果第二页某表格的表头与上一页表格完全一致，就把它们合并成一张表，并补上“续表”标记。这个规则简单有效，但最初经常被忽略。

4.3 公式里的“合理错误”比乱码更危险

公式识别最气人的不是输出完全不可读，而是输出看起来很像那么回事、实际细节全错。比如把“L(x, y)”识别成“L(z, y)”，把求和符号下边的“i=1”丢掉，把矩阵的一行给删了。这类错误在人工检查时如果不逐符号对看，很容易蒙混过关。

为了对抗这个问题，我建立了一个“公式语义完整性检查器”：检查 LaTeX 输出里是否所有括号成对、上下标是否都保留、求和极限是否有完整上下界。这些规则不涉及数学理解，只是语法层面，但能拦截掉相当一部分最致命的问题。真正需要理解的地方，再靠视觉校验模型把渲染图和输出 LaTeX 对照，用“双引擎一致性”来兜底。

4.4 成本与性能平衡的几个土办法

视觉模型调用次数一多，成本和延迟都会成为瓶颈。分享几个实测有效的省钱办法：

• 分层调用：先用便宜的文本引擎处理所有页面，只有文本层缺失或版面复杂才触发视觉模型。纯文本页面占比通常超过一半，能省不少费用。
• 区域级裁剪：别把整页图片丢给视觉模型，表格、公式、图表都先定位再裁剪。裁剪后的图片分辨率损失小，识别质量反而更高，一次识别的 token 消耗也更少。
• 结果缓存命中：同一论文可能被多次重复解析，缓存命中后几乎零成本返回。缓存里除了结果，还存当时用的模型版本和参数，避免版本混乱导致的结果漂移。

延迟方面，最笨也最有效的做法是“页面级并行”。论文各页之间相对独立，用多线程并发调用视觉引擎，30 篇论文的解析时间能从两小时压到四十多分钟。前提是做好频率控制和失败重试，不然很容易被限流。

5. 这套解析架构还能怎么用，以及一些留给后来者的建议

做完这个项目之后，我发现这套“双通道加自校验”的解析思路其实不限于论文复现。凡是下游任务对信息保真度要求很高的场景，都值得借鉴，比如技术文档的代码生成、法律文档的信息抽取、产品说明书的自动化测试脚本生成。核心思想都是一样的：不信任单一来源，用不同引擎交叉验证，再用规则检查兜底，最后保留人工可追溯的坐标来源。

在工程上，我建议后来者把评估体系放到与解析管线同等重要的位置。解析这个东西太容易产生“感觉差不多”的错觉，没有量化指标，团队里每个人对好坏的定义都不一样。哪怕只花一天时间把标注规范和评分脚本搭出来，后续所有迭代的效率都会完全不一样。

另外，我强烈建议把解析结果的“置信度”信息保留到下游。不是所有论文解析质量都一样，扫描版的旧论文、格式诡异的双栏稿、压缩得模糊不清的图表，解析结果的置信度天然偏低。Agent 在下游决策时如果能感知到这些低置信度字段，就会采取更保守的策略，比如主动要求人工复核，或跳过依赖该字段的生成步骤。这个设计在提升安全性和可靠性上的价值，可能比单纯提高几个准确率点还要大。

最后再说一个细节教训：解析模块不是一次性工程，模型会升级、工具会换代，我最后把整套评估流程做成了可一键运行的脚本，任何解析算法改动都能在十分钟内拿到新的黄金集分数。这比任何“看起来更智能”的新模型都更值得先做。

这次把 54 分抬到 92 分的“西游记”，技术上并没有用任何惊艳的新模型，全是工程组合、验证闭环和细节打磨的成果。希望这篇复盘能让大家少走我走过的弯路，尤其记住一句话：解析不是终点，是比终点更重要的起点。