把 PDF 转成可用文本，难点往往出在文字之外：双栏先读哪一栏，表格里的数值属于哪一列，跨页后能否接上前文。Unlimited-OCR-2 这次让我更关注这些结构问题。本期本地测试中，单页扫描图像任务耗时 2.6 秒，十页 PDF 耗时 39.7 秒；复杂表格、公式和多语言样本的对照结果较好，但竖排繁体暴露了一个明确问题：文字能够识别，列的阅读顺序却反了。
本文依据与本期内容匹配的字幕稿及视频简介整理，并结合官方文档核对模型和部署信息；不是一次独立复跑。文中的识别表现限于本期展示与抽查的样本，不代表逐字、逐页验证后的全量正确率。
为什么值得重新测试文档解析
本期从 00:00 开始介绍背景。第一版的体验没有达到我的预期，这次则重新部署，观察第二版在真实扫描件和复杂排版上的表现。这是前后使用感受，不是控制变量的版本对比实验。
Unlimited-OCR-2 是面向文档解析的 3B 级 MoE 视觉语言模型，不宜按通用聊天模型理解。官方强调的 SR-SWA，会把长序列交互限制在固定规模的活动参考范围内，以降低长文档处理成本。持续解析并不等于保留全文所有信息，涉及全局结构的标题层级仍有局限。官方模型卡与技术报告提供了架构说明。
因此，这次关注三件事：字有没有漏，结构有没有变，读出来的顺序是否还能表达原意。
本地环境与结果应该怎么看
01:20 的部署演示使用 RTX A6000。我让 Codex 开发了 Web UI，左侧放原始文件，右侧放解析结果，同时查看 GPU、显存、内存、CPU 和任务耗时。并排比对比只看一份漂亮的输出更有价值，表格错列和段落错序尤其需要回到原稿检查。
UI 能展示 Markdown，不代表模型原生输出就是 Markdown。官方输出含有 <PAGE>、<BLOCK>、坐标与 <FORK> 等结构标记，后处理再转换正文、保留 HTML 表格并合并跨页片段。接入自己的系统时，应保留原始结果，避免只存最终文本后失去定位依据。官方后处理说明
官方采用 MIT 许可证，提供 Transformers 快速试用和定制 SGLang 服务部署方案。文档中的 A800-80GB 是验证环境，不能当成最低配置；模型权重文件大小也不能直接换算成所需显存。本期 A6000 的结果，不足以回答所有消费级显卡能否运行。部署与许可说明
单页扫描：2.6 秒说明了什么
02:17 首先测试一张扫描书页。记录中的任务耗时为 2.6 秒，原始输出为 761 个字符。字幕记录的对照结果是：这张不太清晰的图像成功提取出正文和公式，展示部分未发现明显错误。
这里的 2.6 秒是这次任务的耗时，不是模型在任何页面上的固定速度。页面分辨率、内容密度、输出长度和推理配置都会影响比较。没有统一条件下的重复测试，就不适合据此推导每分钟处理量，也不能把任务耗时和首内容 Token 等待时间混为一谈。
十页 PDF：完成任务与全量核对是两回事
03:15 换成十页 PDF，任务记录为 39.7 秒。演示对照了第一页、第二页以及最后一页，正文和索引序号在这些检查位置表现正常。
这个结果证明了本次十页任务能够完成，也提供了部分页面的质量观察。但中间页面没有在演示中逐一核对，所以不能写成“十页全部零错误”。同样，十页任务成功不能直接证明百页文档中的所有跨页表格都能稳定衔接。若要用于批量处理，下一步需要补充跨页连接处、长表格和章节交界的定点检查。
双栏报告：先看阅读顺序，再看内容
04:07 开始测试更复杂的 PDF。准备阶段合成了九份文件，但这不等于已经完成九类材料的独立、全量评测；部分样本是合成文档，也应与真实业务材料区分。
双栏研究报告同时包含正文和表格。字幕中的对照按第一栏、第二栏展开，随后查看表格、页码及后续页面，所展示部分的顺序与内容对应较好。
这类文档最容易出现“字都对，段落却串了”的问题。用于论文整理或知识库时，应检查同一栏是否连续、表格说明是否跟在正确位置，而不只是搜索几个关键词来判断成功。
复杂表格：结构比外观更重要
05:06 的样本包含多种复杂表格。演示依次对照了第一页的表格、第二份表格和后续内容，报告的结果是表格结构得到保留，表下文字也能对应原文。
这是一个积极信号：文档解析的价值在于让行列关系继续可用。不过，渲染得整齐只是第一步。实际验收还应核对表头覆盖范围、数值所在行列、单位、负号和小数点。这里没有逐单元格标注后的统计数据，因此更合适的结论是“展示表格的结构还原较好”，而不是宣称复杂表格可以免检入库。
公式与混合元素：可读还要可核验
05:55 使用一份合成 PDF，把公式、表格和其他元素放在一起。演示重点对照了第一页、第二页的复杂公式，并查看表格和流程图相关结果；字幕对这些展示内容给出了正面评价。
公式不像普通段落，少一个上下标或括号就可能改变含义。若要把结果用于论文笔记或后续计算，最好保留公式所在页及位置，对照原式检查，再验证渲染。当前材料没有给出符号级错误率，也没有验证提取后的公式可直接用于计算，不能把“看起来还原了”扩写成数学语义完全正确。
模糊扫描：这份样本有效，不等于任意退化都有效
06:37 测试了清晰度较差、排版也不理想的扫描件，重点对照其中最不清晰的最后一页。字幕记录显示，该页正文和下方小字在展示检查中表现较好。
这说明它值得拿来试自己的旧扫描资料，但当前测试没有量化模糊程度，也没有系统覆盖倾斜、透字、缺损等情况。遇到重要材料，我仍会把低清晰度页面单独标记，保留原图，并优先复核姓名、日期、数字等不容易靠上下文发现的错误。
竖排繁体：识字正确，顺序仍然会错
07:04 是本期最值得保留的失败案例。竖排繁体样本的文字和标点在展示对照中能够识别，但原稿要求从右向左读列，输出却按从左向右排列，导致原本靠后的句子出现在前面。
对古籍整理来说，这会直接影响语义和检索结果，不能作为无关紧要的排版瑕疵略过。视频提出用代码重排的思路，但没有展示修正后的验证结果。工程上可以研究利用列坐标恢复顺序；是否适用于夹注、跨栏标题等更复杂版面，仍需单独测试，不能承诺“倒序一下就全部解决”。
中日韩双栏：语言混排与版式一起检查
07:50 的 PDF 在双栏中包含日语、韩语和中文。演示分别对照这些区域，报告的提取结果较好。
多语言和双栏叠加，比只测试一段横排文字更接近日常资料处理。但一个样本不能代表所有语言或所有字体。真正使用时，可以按语言区域抽查字符，再检查栏间连接与标点，避免文字分别识别出来后，在合并阶段丢失原文关系。
我的结论：值得试用，保留原稿与复核环节
08:39 的总结延续了这次的积极体验。对我而言，最有参考价值的是表格、公式和双栏内容的还原，以及竖排顺序这个明确的边界。它值得进入论文整理、扫描资料数字化和知识库预处理的候选清单。
官方另有 MarathonDocBench：100 份文档、约 1.8 万页，公布的 Overall 77.06 是八项指标的平均值，不是 77.06% 的字符准确率。其竞品基线采用整篇请求，遇到输入限制等失败会按空预测计分，因此榜单同时反映该测试条件下的处理能力，不能直接概括成所有 OCR 场景的胜负。基准说明与榜单
如果要接入自己的流程，我建议先做三件事：
- 保留来源关系：原文件、页码、坐标和解析结果一起保存，让每段内容都能回到原稿。
- 给高风险内容安排复核：数字、表格、公式与阅读顺序单独检查，不用少数成功页面代替整体验收。
- 控制本地服务的数据访问：企业材料先脱敏，限制文件、接口和日志权限。本地运行减少了部分数据外发环节，但不会自动获得安全性。
这次演示支持“值得进一步测试”的判断。是否适合长期使用，最终还要让它处理自己的文档，并把错误记录下来，而不只是留下成功样例。