2026.1.27发布的最新Deepseek-OCR2模型剖析

拉姆哥的小屋

848人浏览 · 2026-01-28 16:19:54

拉姆哥的小屋 · 2026-01-28 16:19:54 发布

1.Deepseek OCR2的整体架构：

和之前的非传统OCR的流程基本差不多，大体看上去都是编码器+后面的语言模型，但是差别就是这个encoder里面用到的是视觉编码+语言查询编码两个部分。重点应该是后面的因果查询流。

我认为：

Deepseek这次想把重心放在视觉文档的重要性分配和阅读顺序上，让其在解析、交互的过程更好的与用户"看到的“相匹配，因为有的信息是你真正关心的，但是计算机通过传统视觉编码之后并不知道你最关心文档的什么部分。所以过去的OCR在与用户交互过程中往往抓不到重心。所以这次OCR2的创新应该重点放在后面的因果查询流。

2.DeepseekOCR2的encoder构造：

encoder的构造分为两部分，deepseek也是想让模型兼具（全局视野与局部视野）所以采用了两个部分，并在最后encoder的部分进行两部分的拼接。总token就是: k*144（全局视野）+256(局部视野）

我认为：

但是我在思考这个16*16的patch足够捕捉不同尺度的信息吗？一个文档如果字体足够小，或者图片非常大，它能够捕捉到全部的信息吗？

另一个就是：这里的全局视野允许最大值是6.意思就是最大可以允许看到某一页的前面三页数后两页或者后两页前三页，总共6页。那如果我想要查询的细节信息恰好分布在两个不同的细节页面上面呢？或者我要查询的甚至超出了6页，怎么办？后面的deepseek-MOE是不是做了兜底？（可能是后面的细节问题了）

但是我还是强烈怀疑deepseek凑出的最大的k*144（全局视野）+256(局部视野）=1120=gemini3 pro的最大token数量是为了噱头和攀比，没有专门证明这个数据的相对优势。

下面是encoder的具体构造，分为两部分，全局编码和局部大图编码。(单词编码解析最大6页，更长的只能分次解析，或者利用后面的。

2.核心创新:因果查询流

就是把LLM 的那一套掩码注意力和纯视觉的VIT注意力机制进行了拼接，具体尺寸由查询token长度和视觉编码的token共同决定：

Causal flow query

详细对比：DeepSeek-OCR 与 DeepSeek-OCR 2

对比维度	DeepSeek-OCR (第一代)	DeepSeek-OCR 2 (第二代)
发布时间	2025年10月开源	2026年1月27日发布
核心架构	端到端视觉语言模型（VLM）架构	沿袭VLM架构，但对视觉编码器（Encoder）进行根本性革新
视觉编码器核心	DeepEncoder (基于CLIP风格)：使用窗口注意力压缩视觉token。	DeepEncoder V2：用轻量级大语言模型（LLM，如Qwen2-0.5B）替代CLIP，并引入 “因果流查询” 机制。
视觉处理逻辑	“光栅扫描式”：按固定的空间顺序（左上到右下）处理图像。	“视觉因果流”：模仿人类阅读，根据图像语义动态重排视觉信息的处理顺序。
参数量与压缩	参数量约3B（30亿）。采用“光学压缩”，将文档压缩为少量视觉token，效率极高。	沿用第一代约3B参数的混合专家（MoE）解码器，编码器升级。在更高压缩率下保持甚至提升性能。
关键性能表现	- 高压缩率精度：在<10倍压缩率下，文本还原精度约97%；20倍压缩率下约60%。 - 处理速度：单张GPU日处理超20万页文档，实现秒级解析。	- OmniDocBench v1.5综合得分：91.09%，较前代提升3.73%。 - 阅读顺序编辑距离：0.057，较前代（0.085）显著降低33%。
视觉Token效率	将每页文档的视觉token从传统VLM的数千个降至100-800个，减少90%以上。	视觉token使用上限从1156个降至1120个，使用更少token达到更高精度（如在1120个token下解析能力优于Gemini-3 Pro）。
实际应用效果	已在企业级文档处理（如来也ADP平台）、媒体数字化（如江西融媒大脑）中验证，大幅提升效率。	在实际数据生产流水线中，OCR结果的重复率显著降低（如用户日志图像重复率从6.25%降至4.17%），产出的文本数据质量更高。
技术价值与定位	验证了 “视觉即压缩” 范式的可行性，是一种高效的文档信息提取与数据生产工具，用于生成大模型训练数据。	1. 研究价值：验证了 “LLM作为通用视觉编码器” 的路径，是迈向统一全模态编码器的关键探索。 2. 实用价值：作为更精准、更“智能”的数据生产工具和文档解析引擎。