OCR 分野：百页文档一次读完的两种路线

你是一家咨询公司的数据工程师。桌上是一份 200 页的扫描版行业报告——混合了表格、图表、多栏排版，还有几十页的手写批注。任务很明确：把这份报告转成结构化数据，导入分析管线。

几年前的你会怎么做？写一个脚本，把 PDF 切成 200 张图片，逐页送进 OCR 引擎，然后把 200 段文本拼回去——中间大概率漏掉跨页表格的列标题，打乱多栏阅读顺序，还可能在切页边界处截断句子。

2026 年 6 月 23 日，Hacker News 首页同时出现了两条帖子：百度开源的 Unlimited OCR（428 points）和 Mistral 发布的 OCR 4（420 points）。两件事撞在同一天，指向同一个信号：OCR 长文档时代来了。但怎么来，两家给了完全不同的答案。

一个老问题：为什么长文档 OCR 这么难？

OCR 本身不是新问题。Tesseract 已存在四十年，云厂商的文档识别 API 也做了很多年。但这些方案在长文档面前都倒在同一堵墙上：KV cache 膨胀。

用大语言模型做 OCR 的思路大致是：把文档图像编码成一串视觉 token，让 LLM 逐 token 地「读」出文字。每生成一个 token，模型都要回顾之前所有 token 的状态——这些状态存在一个叫 KV cache 的结构里。文档越长，生成内容越多，KV cache 线性增长 O(N)，直到显存撑不住。

工业界对这一问题的标准应对，就是前面提到的「切页拼接」——把长文档拆成单页，逐页处理，用外部调度器管理流程。HN 用户 robotswantdata 在 Unlimited OCR 讨论区的评论很精准：「开发者被迫写脏代码，把 PDF 切成一页一页，逐个处理，再把文本粘回去（janky code that chops PDFs into individual pages, processes them one by one, and glues the text back together）。」

这能跑，但它不是真正的长文档理解。跨页上下文丢失、表格被切碎、阅读顺序混乱——这些都是「工程补丁」的代价。

百度路线：用 R-SWA 把 KV cache 压到常数

百度 Unlimited OCR 的核心创新叫 Reference Sliding Window Attention（R-SWA），一种把 KV cache 从 O(N) 压到 O(1) 的注意力机制。

不用公式，用直觉来理解。

想象你在抄写一本书。你一边看着原文（Reference），一边写下文字（Generation）。你不需要每写一个字就重读一遍之前抄过的所有内容——你只需要偶尔扫一眼最近写的那几行，确认自己没有抄串行。原文始终在你眼前，不会模糊，不会消失。

R-SWA 做的就是这件事。它把注意力通路拆成两条：

• Global Reference 通路：每一个生成的 token 始终关注全部视觉 token（即文档图像）和 prompt——原文永远清晰，跨页上下文不丢失。
• Local Generation 通路：每一个生成的 token 只关注最近 128 个已生成的 token——短期记忆只需要一个滑动窗口，旧的 token 状态可以被安全遗忘。

关键设计在于，视觉 token 不参与「状态更新」。它们只被读取，不被修改。这规避了滑动窗口注意力的一个经典缺陷：视觉特征随状态更新逐渐「模糊」，最终导致识别精度下降。

结果是，KV cache 在整个解码过程中保持常数大小。40 页 PDF 扔进模型，一次推理全部读完——不需要切页，不需要外部调度器，不需要写那个「页码拼接的脏代码」。

技术细节上，Unlimited OCR 以 DeepSeek OCR 为基线，保留了其 DeepEncoder 的 16× 高压缩率，但把解码器 LLM 中全部注意力层替换为 R-SWA。模型参数 3B，推理时只激活 500M（MoE 架构），在 OmniDocBench v1.5 上拿到 93% 的综合分，超出 DeepSeek OCR 基线 6 个百分点。

论文发在 arXiv，代码开在 GitHub（MIT 协议），模型权重挂在 HuggingFace 和 ModelScope。典型的学术路线：发论文、开源代码、公开权重、让社区去扩展。

Mistral 路线：用产品化方案定义文档智能

Mistral 在同一天发布了 OCR 4，距离上次 OCR 产品更新隔了一年。

OCR 4 的卖点是工程交付的完整性。它把 OCR 从「提取文字」升级到了「理解文档结构」：输出不止是文本，还附带 bounding box（定位每个文本块在页面中的位置）、block classification（标题、表格、公式、签名区域的分类标注）和 inline confidence score（每个字符或单词的置信度）。

支持 170 种语言、10 个语系。单个容器即可完成自托管部署。在 OlmOCRBench 上拿到 85.20 分，人工偏好测试中平均胜率 72%。

从 Mistral 的定位来看，OCR 4 是它的文档智能管线的一个「摄入组件」——配合 Search Toolkit 做企业搜索、RAG 和领域检索。Bounding box 让搜索结果可以在原文档中高亮定位；置信度分数驱动人工复核流程；结构化 block 输出让下游数据管线更可靠。

闭源、商业 API、按量计费——典型的产品公司路线。

HN 评论区跑偏：手写地址才是真正的 OCR 奇迹？

Mistral OCR 4 的 HN 评论区出现了一个有意思的转向。最高赞评论来自 ericyd：

「我一直觉得美国邮政服务是个技术奇迹。他们居然能识别和路由数十亿封邮件，而地址书写极其不标准——同一个地址可以写成好几种形式……」

随后 idoubtit 接力讲述了一个更极端的故事：父亲在 70 年代收到一封从阿尔及利亚寄来的信，信封上只有三个词——他的名字、城市名「Créteil」和「France」。在没有互联网、没有中央数据库的年代，邮政系统硬是把信送到了。

在笔者看来，这些故事和 Mistral OCR 4 的发布之间有种微妙的张力。它们提醒从业者：OCR 的终极目标是真实世界中那种极度不标准化、极度依赖上下文的识别任务。手写地址路由可能是这个领域最早的「长文档 OCR」——只是它的「文档」是信封，它的「模型」是邮递员对社区的记忆。

两条路的分岔：选择的维度

在笔者看来，百度的 Unlimited OCR 和 Mistral 的 OCR 4 代表了同一赛道上两种不同的交付哲学。

选择百度的路线，得到的是：一篇可以读的论文，一个可以改的代码库，一种可以迁移到其他任务（论文中提到 ASR、翻译）的通用注意力机制。代价是需要自己部署、自己调参、自己处理工程问题。适合有工程能力的团队、学术研究、或需要自己 finetune 的场景。

选择 Mistral 的路线，得到的是：一个 API endpoint，结构化的 JSON 输出，开箱即用的文档智能管线。代价是看不到模型权重，改不了内部逻辑，按 token 付费。适合企业级部署、快速集成、需要 bounding box 和置信度的生产场景。

两者不是非此即彼。同一家公司的文档管线可能同时用到两个方案：用 Unlimited OCR 的思路优化长文档处理效率，再用 OCR 4 的结构化输出做下游定位和检索。

真正的拐点：从「能读」到「能一次读完」

无论选择哪条路，2026 年 6 月 23 日这一天值得被记住。不是因为两个产品同时上了 HN 首页——这只是表面现象。而是因为 OCR 领域正式跨过了一条线：从「勉强可用」进入了「零样本长文档解析」。

一年前，让一个模型一次读完 40 页扫描文档还是幻想。今天，它成了两个不同技术路线的共同起点。R-SWA 证明了注意力机制上的数学创新可以打开新的可能性空间；OCR 4 证明了结构化输出的工程打磨可以让 OCR 融入真正的生产管线。

对那个面对 200 页报告的工程师来说，答案不再是「写个 for 循环切页拼接」。至于是用开源的 R-SWA 方案还是调 Mistral API，那就是另一个故事了。