不说废话先交代背景。我们团队在把第一代 OCR 系统往生产环境大规模铺开的过程中被一类问题反复卡了半年单行文本识别精度已经做到 99% 以上但只要遇到复杂版面、多栏排版、图文混排、扫描件里的印章压字结果立刻塌方。第一代方案是典型的识别器思路——模型只负责把图片里的文字抠出来版面和阅读顺序完全靠外部规则补规则补不动的地方就是各种奇葩错误。所以当第二代项目立项时我们定的目标根本不是把准确率再提 0.5 个点而是彻底换一种技术范式让模型自己理解文档结构从图像直接输出带版面的、可消费的结构化内容。这就是 DeepSeek-OCR 2 的核心出发点。这篇文章不打算写一份完整的技术报告更多是从工程实操角度拆解我们做了什么、为什么这么做、踩了哪些坑。适合正在做 OCR 相关项目、或者准备把多模态大模型引入文档理解链路的人参考。内容会涉及模型架构、训练策略、解码优化、后处理管线也有不少实测数据。1. 从字符识别到文档理解二代项目的目标边界先明确一个容易混淆的问题第一代 OCR 和这一代 OCR 到底差在哪。如果还抱着识别准确率这一个指标去做第二代很容易陷入一个陷阱——花大力气把某个 benchmark 刷到 99.5%上线后依然被用户骂。原因是真实文档场景里识别正确的定义是复合的文字内容要正确包括生僻字、标点、上下标版面结构要被理解标题、正文、页脚、注释谁先谁后阅读顺序要符合人眼习惯尤其多栏排版语义单元要完整表格的单元格不能拆散、公式不能断行输出格式要可用Markdown、JSON 或者至少带坐标。这五个要求第一代架构一个都应付不了。我们当初的管线是检测 识别 规则后处理检测模型负责找文本框识别模型负责把文本行转成字符串再用一堆基于坐标的启发式规则去恢复顺序。这套方案最致命的问题在于规则是人写的而真实文档的版面变化远超人的枚举能力。双栏是常见的但三栏、四栏、侧边栏注释、页眉页脚的穿插、带边框的文本框每种情况都是新规则。1.1 第一代系统留下的遗留问题我们自己复盘一代系统有四个最典型的失败场景第一个是跨栏文本被合并。两个相邻栏目的文本行在 y 坐标上几乎重合检测模型经常把两栏文字圈进同一个框识别结果变成两段文字交替穿插完全不可读。第二个是图文遮挡图片盖住部分文字、印章压住正文、手写批注叠在印刷体上检测框要么分裂要么漏检。第三个是阅读顺序错乱坐标排序在处理简单双栏时还能凑合一旦遇到杂志式的复杂版面顺序完全不可控。第四个是结构化输出缺失我们只能给出行级文本加矩形坐标表格、列表、标题层级这些信息全部丢失下游要做知识抽取还得再写一堆规则。这些问题不是靠调参能解决的。它们共同指向一个结论检测和识别解耦的旧范式在信息密度高的复杂文档上已经到头了。1.2 二代项目的目标边界所以 DeepSeek-OCR 2 立项时我们给自己划了几条非常明确的任务边界输入是一整页图像或 PDF 渲染图不再做文本框检测、一行一行识别这种中间步骤输出是带有完整语义结构的文档优先支持 Markdown 和结构化 JSON模型必须具备视觉和语言的联合推理能力——看到表格能重建出表格看到公式能输出 LaTeX实际部署要控制成本单页推理延迟定位在秒级以内显存占用中低端显卡要能跑。换句话说第二代的技术底色是多模态文档理解而不是传统 OCR。这个定位决定了后面所有的技术选型。2. 架构升级视觉编码器、文本解码器与跨模态融合模型架构本身没有发明什么全新的东西我们做的是把已经被验证过的多模态大模型组件按 OCR 场景做深度适配。整体是一个标准的视觉编码器 语言解码器架构但工程细节上有几个值得展开的地方。2.1 视觉编码器的选择与分辨率伸缩视觉编码器直接决定了一个最终极的问题图像细节能不能被模型看到。OCR 对细节的敏感度远高于通用图像理解。通用视觉模型看一张图只需要知道这是一只猫OCR 要能区分l和1、0和O、中文里长得像的己/已/巳这需要非常高的有效分辨率。我们最终选用了 ViT 系编码器并且做了一个关键改动动态分辨率分块。具体做法是把输入图像切分成多个不重叠的 patch 序列每块分辨率控制在 224×224 的整数倍附近然后通过一个二维位置编码把它们拼成一个长序列喂给模型。这样做的直接收益是一张 2000×3000 像素的 A4 扫描件可以不被暴力缩放到固定尺寸细节信息不会因为降采样而丢失。千万别小看这个设计。我们对比过同参数量编码器在固定分辨率和动态分块两种方案下的表现固定缩放的版本在常规测试集上准确率还能看但一旦遇到小字号注脚、角标这类细节密集区域错误率直接翻倍。动态分块之后模型对 8 号字以下的中文文本识别能力明显改善。2.2 解码器侧的细节为什么不用纯 LLaMA 结构解码器我们做过两组消融实验一组是直接的 LLaMA 风格因果语言模型另一组是在交叉注意力层引入视觉 token 的混合结构。实验结果很有意思对短文本行两者几乎没差别对整页文档混合结构能更稳定地保持版面信息。我们的做法是在每个解码器层插入一组交叉注意力专门处理视觉编码器的输出。文本 token 之间的自注意力保持标准因果掩码视觉 token 之间则是全可见的。这个设计的解释是文本生成必须严格保序但视觉理解需要全局上下文。比如判断一个单元格属于第几列模型需要同时看到整个表格而不是只能看到已经生成过的部分。复用现有框架时只需要改注意力掩码的生成逻辑推理框架的改动成本可控。2.3 位置编码与长序列的稳定性整页文档输入带来的位置编码压力比普通对话场景大得多。A4 纸在动态分块后视觉 token 数量经常超过 4000再加上输出的文本 token单样本总序列长度很容易突破 8000。我们对比了 ALiBi 和 RoPE 两种方案最终选择 RoPE并且把旋转基数调大了一个量级。这个调参的动机是OCR 场景里二维空间位置是强语义信号。一行文本的第 10 个字符和第 100 个字符位置变化不只是距离远还意味着可能在另一个句子、另一个单元格里。更大的旋转基数让位置编码在长距离上的分辨率更高避免模型因为位置混淆而重复或者漏读。实测中序列长度超过 6000 时调整基数前后的困惑度差异非常明显。3. 训练管线从合成数据到弱监督对齐的三阶段设计数据是 OCR 项目的真正护城河。架构再好没有合适的数据模型学到的只是表面的形状对应而不是语义理解。我们的训练分三个阶段预训练的合成数据阶段、弱监督真实数据阶段、指令微调对齐阶段。每个阶段解决一个特定问题。3.1 合成数据管线让模型先学会看第一阶段的目标是让模型建立图像像素 → 文本内容的基础映射能力。这个阶段完全使用合成数据没有人工标注成本低、规模可以做到极大。合成管线的核心组件是渲染引擎 扰动引擎。渲染引擎负责把真实语料库里的文本、公式、表格排版成符合真实文档分布的页面。注意这里的关键不是随便把文本往白底上一放而是需要模拟出真实文档的层次结构标题字号大于正文表格有边框和分栏公式有上下标和根号段落有缩进和对齐。扰动引擎则负责加各种真实世界的噪声扫描的倾斜角度、光照不均、纸张纹理、墨迹深浅、模糊、还有印章红色通道的随机覆盖。我们在这条管线上投入非常大因为它是整个模型能力的下限来源。合成数据覆盖的样式越广模型后续在真实数据上需要的学习样本就越少。一批中文古籍样式的合成数据直接让模型对竖排文本的零样本能力提升了一个档次——这个后面讲垂直场景时会再展开。3.2 弱监督真实数据从识别走向理解的关键一跃合成数据能教会模型把字读出来但理解版面语义——哪些是标题、哪些是正文、表格结构怎么重建——必须靠真实数据。这是数据工程最难的部分。我们的做法是弱监督。核心思路用一套现有的传统管线生成粗标注再用规则和人工抽检做清洗不追求像素级完美的标注框而是在文档级别保证正确。具体到数据形态上每一条训练样本就是一张页面图 一个 Markdown 文档字符串。这个 Markdown 既包含文本内容也包含标题层级#、##、列表、表格、代码块、公式的 LaTeX 表达。弱监督的妙处在于它允许标注存在少量错误模型自己会在大规模训练中学会纠错。但前提是错误率不能超过一个阈值所以我们保留了一套针对 Markdown 结构合法性的自动校验表格行列数是否匹配、代码块是否闭合、公式括号是否成对。经过去重和清洗最终真实数据量有一百多万页面级别。3.3 指令微调让输出贴合消费端前两个阶段训练出的模型输出比较任性经常答非所问——让它输出 Markdown 它可能给一段纯文本让它输出 JSON 它可能各种格式抖擞。第三阶段用指令微调解决这个对齐问题。我们构造了几十类指令模板覆盖使用方常见的需求。比如请识别这张图片中的表格并以 Markdown 表格形式输出、提取文档中的所有标题按层级输出 JSON、识别公式为 LaTeX等。这个阶段数据量不需要很大几万条高质量指令样本就够但它决定了产品的手感。一条重要的经验指令模板要和下游调用方式保持一致。我们一开始做了一堆花哨的对话模板结果部署时发现用户调用时根本不会说那么长的要求大部分人就是传一张图、拉一个默认参数。后来我们把默认指令固定为最简洁的请完整识别此文档并输出为 Markdown微调数据也按这个风格来线上成功率反而涨了不少。4. 后处理与结构化输出约束解码、长文本与版面重建很多团队做到训练结束以为就完事了实际上推理阶段的工程优化对最终效果的影响比想象中更大。DeepSeek-OCR 2 在解码环节做了三个关键增强。4.1 约束解码用 FSM 保证输出结构合法纯自回归模型生成 Markdown 是守不住格式的典型症状是表格行数对不上、列表缩进层级混乱、JSON 括号不闭合。与其等生成完再修复不如在解码时就给模型戴上紧箍咒。我们实现了一个基于有限状态机的约束解码器。它的核心逻辑是根据已经生成的 token 序列定义一个当前处于什么结构上下文的状态比如是否在表格行内、是否在代码块里、是否在公式环境中然后从词表中屏蔽掉那些在语法上非法的 token。以 JSON 输出为例模型生成完{title: xxx}后的下一个词必须从,、}或空白 token 里选任何其他内容都会被屏蔽掉。这个状态机是编译成 C 的推理时的额外开销可以控制在 5% 以内。效果非常直接结构非法率从没有约束时的 8% 左右降到接近 0。实现参考开源社区的一个标准套路把 JSON Schema 编译成不确定有限状态自动机再转成确定有限状态自动机解码时对每一步的候选 token 做合法集合过滤。Markdown 的语法相对固定自己手写 Grammar 规则也可以但 JSON Schema 那套更规范后续要扩展 XML 或 YAML 输出直接换 Schema 定义就行。4.2 长文档生成缓存复用和窗口注意力整页 A4 文档解码时输出通常有 500 到 1500 个 token这个长度对大模型不算压力但积累了多个并发请求后内存带宽会变成瓶颈。我们做了两个优化。第一是视觉 token 的 KV 缓存复用。同一个 PDF 连续渲染出来的多页图像视觉编码器部分的输出可以预计算缓存下来。用户反复修改输出格式纯文本换 Markdown时不需要重复跑视觉编码器推理成本直接砍半。第二是解码阶段的窗口注意力。文本侧自注意力不保留完整的全量历史而是用窗口大小 512 的滑动窗口超出窗口的 token 直接截断。这里有个反直觉的经验窗口注意力几乎不影响输出质量。原因在于 OCR 任务生成的文本局部依赖非常强——当前 token 只和最近几十个 token 在语法和语义上相关很少需要回头参考 300 token 之前的内容。我们跑了 2000 条真实页面的评测窗口注意力下的 Edit Distance 和全量注意力相比差距在 0.2% 以内。这个结论不一定适用于长篇小说生成但在 OCR 场景是安全的。4.3 表格与公式结构化输出的两大硬骨头纯文本识别做到 99% 不难表格和公式才是拉开差距的地方。表格重建我们采用先预测坐标系再生成 Markdown的混合方案。模型同时输出表格区域的行列分割点坐标和单元格的文本内容。这在训练时被建模成两个子任务视觉编码器末尾接一个轻量的分割头负责预测行列线位置语言解码器只负责生成单元格文本和对应的结构化包围标记。关键收益是行列线由分割头显式预测不会出现模型脑补出表格里不存在的行或列。公式识别则完全交给解码器直接生成 LaTeX 字符串不做字符级纠错因为 LaTeX 语法错误率在约束解码的加持下已经非常低。实测数据供参考在自建的混合文档测试集上表格结构重建的准确率按行列对齐完全正确计从一代的 67% 提升到 91%公式识别在标准公式数据集上的 BLEU 达到 0.82。5. 实测性能与三类高频翻车场景模型装到生产环境之后我们系统性地收集了线上反馈归纳出三个高频率翻车场景也都针对性做了优化。这部分对想直接落地的人最有参考价值。5.1 中文竖排与古籍样式竖排文本是一代系统完全没处理过的场景。坐标排序的规则在竖排面前直接失效即使能识别出单字跨行阅读顺序也是乱的。二代的视觉编码器天然能感知文本的方向信息配合我们在合成数据阶段加入的竖排渲染管线模型基本学会了从上到下、从右到左的阅读顺序。但竖排和横排混排的文档、竖排中夹杂横排数字的情况依然会偶尔出错。我们的优化措施是在微调阶段针对性地增加了约 6000 条竖排/混排真实样本同时把竖排的阅读顺序作为一个显式的指令选项。输出顺序竖排从右到左这个指令一加测试集准确率又提了约 3 个百分点。这块的经验是遇到新排版类型先不要去改模型架构优先从合成数据和指令微调两头补样本见效最快。5.2 印章遮挡与手写批注红色印章是 OCR 最头疼的真实场景之一。印章压在正文上被遮挡的字迹在灰度图上可能完全和章的颜色混在一起。我们的方案在视觉编码器的输入侧做了一次通道分离把 RGB 图像拆分成 RGB 三通道以及一个颜色概率特征。训练时模型会学会优先使用文字墨色所在的通道信息弱化红色通道的干扰。效果测试下来印章覆盖率低于 40% 的文字识别准确率从原来的 82% 提升到 94%。如果印章完全覆盖文字目前任何方案都很难完美恢复这个得诚实说明。手写批注的问题更复杂我们目前的策略是区分两种情况手写内容紧邻印刷体时用指令控制只输出印刷文本手写本身也是信息比如审批意见时单独部署一个小模型做手写识别。在这个场景上不要指望一个模型通吃合理分流才是工程正解。5.3 扫描件的透视畸变与低分辨率手机拍摄的文档照片透视畸变和光线不均是常态。模型在没有矫正的情况下直接吃原始图效果会有明显下降。我们做过实验加一个轻量的几何矫正前处理仅做四点透视变换端到端文字准确率提升 1.5% 左右再加一个自适应的对比度增强在暗光照片上又能提升 1% 左右。但要注意前处理不是越多越好。过度去噪、二值化、锐化反而会破坏模型已经学习到的原图分布。我们的建议是前处理只解决物理成像带来的几何和光照问题不要做任何面向 OCR 的形态学处理。把增强交给模型自己它比你更懂什么样的特征是有用的。6. 部署层面的量化、推理加速与显存优化最后聊部署。OCR 服务的调用特点很明确单条请求图片大、输出 token 数多、并发波动剧烈。推理侧我们踩了不少坑也做了不少优化。6.1 视觉编码器的独立推理与批量复用和语言解码器不同视觉编码器的计算量大但结果复用率高。一个用户反复上传同一张图、只用不同参数解析多次的情况非常常见。所以我们在服务层把视觉编码器做成独立模块结果写进 Redis 缓存天然支持多副本扩展。视觉编码的耗时只占整条链路的 20% 到 30%但它对显存占用很敏感因为大批量图像输入时中间特征图非常大。实测数据一张 2000×3000 的图片动态分块后的视觉 token 数量是 4096 个前向一次约 45msA10 上。500 并发场景下视觉编码器部分开 2 个 GPU 副本就够真正吃 GPU 的是语言解码器的自回归生成。6.2 量化FP8 与 INT4 的取舍我们把语言模型量化到 FP8 后部署效果几乎没有损失。OCR 任务对 token 级准确率要求极高一经量化损失超过 0.5% 就不能接受。FP8 下实测 token 准确率掉 0.2% 左右可以接受INT4 定量化后 token 准确率掉了近 1.5%在数字和中文标点上错误明显变多不建议用于生产。如果显存实在不够INT4 只适合做离线批量任务并且建议配合约束解码兜底——约束解码能把非法输出的比例压住但不能恢复本来就被量化丢掉的信息。这只是止损不是修复。6.3 并发调度策略OCR 请求耗时普遍偏长我们用最简单的预占式并发控制按照当前 GPU 剩余 KV cache 容量预判最多能撑几个并发解码宁可让少量请求排队也不要一堆请求挤爆显存导致 OOM。KV cache 的申请大头在视觉 token 序列长度上我们做了一次逻辑优化把视觉 token 的 KV cache 单独用静态显存池管理因为它跨请求可以复用。语言 token 的 KV cache 才走动态分配。这个优化把同机最大并发数从 18 提升到了 32显存占用几乎没变。如果你们的业务也是典型的图片多、答案长型 OCR 服务布局这两级 KV cache 的管理收益会非常直接。传统的按 token 数并发估算的方式只适用于纯文本对话模型OCR 场景一定要把图片带来的显存基数算进去。7. 一些可以复用的工程经验最后集中一批零散的实战经验。这些内容不在论文里、不在文档里但每一条都是我们真金白银换来的教训。第一评价指标不要只看字符准确率。我们内部用两套指标一套是内容准确率字符级别的 Edit Distance一套是结构完整率表格行列对齐、标题层级、块顺序是否正确。对客户来说结构错误往往比个别字错误更致命。一个表格行序错乱哪怕所有单元格内容都对用户体验也是完全不能用。第二约束解码要在写模型代码时同步规划。不要等模型训好了再考虑输出格式问题。我们因为在训完模型之后才开始设计状态机导致微调阶段的输出规范和解码器的约束逻辑有细微出入模型总是试图输出一个合法但不合规范的中间状态花了两周时间打补丁。第三合成数据的污染问题。合成数据生成器本身用的字库、模板如果过于单一模型会对特定字体产生隐性依赖。换一个现实中不常见的字体准确率立刻掉 3 个百分点。建议合成管线至少引入二三十种字体并且给字体加随机形变宁可单一样式数据少一点也要保证多样性多一些。第四文档骨架明确的 Markdown 输出永远优先于自由文本输出。我们试过让模型用自然语言描述版面结果后来发现没法解析、没法对齐、没法校验。一切以可解析的结构为标准这应该成为文档理解类模型的默认设计原则。顺便说一句新一代模型做文档理解时很多团队会把注意力放在模型参数变大上但我们测试下来在 OCR 这个具体场景视觉编码器的有效分辨率和训练数据覆盖度对最终效果的贡献远大于解码器参数量的增加。把同样的预算投入在数据管线和分辨率优化上收益比单纯扩大模型高很多。这也是为什么我们在架构上偏保守、在数据上却异常激进。路径判断上行业里已经验证过大参数 长文本 通用视觉能力是一条可行路线但具体到文档理解这个垂直切口效率和精度之间的最优解往往不是最大的那个模型。开源社区里关于文档理解模型的工作越来越多了如果你计划自己做一个类似的系统核心建议其实就一句话先跑通一条包含视觉分块 约束解码 结构化输出的最小链路再回头用数据规模的扩大去换效果上限。架构设计的坑通常不会比数据管线先暴露出来但数据管线做扎实了后面的一切都会顺畅很多。
