文字识别工具很多，但 DeepseekOCR 为什么突然火了？答案在于它不仅能“看清”，还能“看懂”。从票据到文档，从图片到表格，它正在让信息处理变得更轻松。

在本技术报告中，我们提出DeepSeek-OCR模型，并通过该模型初步验证了上下文光学压缩的可行性，证明该模型能够从少量视觉标记中有效解码超过10倍数量的文本标记。我们相信这一发现将推动未来视觉语言模型与大语言模型的发展。此外，DeepSeek-OCR作为具备高度实用性的模型，能够实现大规模预训练数据生成，成为大语言模型不可或缺的助手。当然，仅凭OCR技术尚不足以完全验证真正的上下文光学压缩，未来我们将开展数字-光学文本交错预训练、大海捞针测试等评估工作。从另一角度来看，光学上下文压缩仍存在巨大的研究和改进空间，是一个充满前景的新方向。

这一整段话可以用一句话总结，那就是“我们通过DeepseekOCR模型验证了确实能够使用上下文光学压缩（Context optical compression）这一技术将超多的Text Token压缩为少量的Vision Token”。

而这句话，总共有三个关键词要弄清楚，分别是Context optical compression（上下文光学压缩）、Vision Token（视觉Token）、Text Token（文本Token）。

什么是Vision Token与Text Token?

我们知道大模型实际上是一张复杂的 处理/预测 Token的巨大神经网络，而什么是Token？

Token可以理解成大模型的“词汇”，举个例子，在汉语中“我爱你”表示的含义和英文中的“I Love You”相当，也就是说，在汉语中，【我】这个字相当于英文中的【I】，同理，【爱】相当于【Love】，而大模型如何理解【我】呢？它会将【我】映射为一个索引，以GPT-4O为例，【我爱你】三个字会被转化为[7522, 6414, 12370]这样三个索引，我们无法理解，对吧？但是没关系，这就相当于是一门模型专属的语言，模型眼中的【7522】就相当于我们眼中的【我】，而这样每一个模型眼中的索引，即为一个token。值得注意的是，一个Token并不一定代表一个字，打个比方，【今天月色很美】这句话在模型眼中，是【47256, 3181, 4472, 18730, 5084】为什么6个字变成了5个索引？因为【今天】这两个字在模型的语言中就是【47256】，可以类比为英文中的【Today】，即【今天】是一个Token。

理解到这里，其实已经理解了Text Token，那什么是Vision Token呢？

我们刚刚理解的是文本层面的模型理解方式，即把我们所表达的汉字转换成模型理解的索引，每个索引就是一个Token。这很好理解，而如果模型接受的是图片，那会怎么处理呢？论文中提到了三种处理VLM常用的处理方式：

在上图中，我们能够看到Deepseek-OCR各个型号的模型在OmniDocBench这个测试集上的分数从最小Tiny型号的0.3 一路提高到Gundam-M的0.1 ，这里的分数是Edit distances，编辑距离，假设一个模型的编辑距离得分为0.12，意味着它识别出来的内容经过12%的内容修改即可与原文完美匹配，所以理论上这个数值越低，模型性能越好。从表中我们可知：Deepseek-OCR Gundam-M(200dpi)在这个测试上取得了最高分，并且使用的VisonToken数量约是dots.ocr(200dpi)的三分之一。在使用800个Vison Token的情况下，DeepseekOCR的成绩比传统使用7000个Vision Token的模型还要好。

分数这么高，不会是数据集很简单吧？我们来看一下这个数据集的部分示例：

整体上看来，整个数据集的类别比较杂的，涵盖文字、公式、图等多种符号，格式也不只是标准的格式，甚至有扫描件格式，整体上难度较大，因此DeepseekOCR取得这样的成绩确实值得人们高呼“天才”！

看到这里，我们已经大致对DeepseekOCR做了什么有什么突破有了大致的理解，但是涉及技术的实现方面才刚刚开始，接下来我们来看看DeepseekOCR是如何取得这样的成就的，这个章节我们只需要搞懂两个词：DeepEncoder和MoE Decoder。整体的DeepseekOCR架构如下图所示：

整张图放眼望去，可以分为三个部分：第一部分：图片切块，第二部分：DeepEncoder流程，第三部分：MoEDecoder产生输出。

几乎所有的视觉模型都有这个步骤，直接处理图片的每个像素点会带来计算压力过大的问题，因此DeepseekOCR对图片的处理和大部分模型一样，对图片进行Patch，把16*16个像素点切成一个Patch，这样一来，一张1024*1024的图片即可以用1024/16*1024/16=4096个Patch来表示。

Encoder是编码器，通俗来讲就是一个信息打包、翻译的专家，可以把某种形式的语言A，翻译成富含某种信息的另一种语言B，而往往这种语言B是我们所看不懂的。所以，在DeepseekOCR中DeepEncoder的作用就是接受被切块了的图片，将其转化为包含原图片所有信息的Vision Token。

而DeepEncoder的整个过程又可以拆分为三个环节，SAM组件、16卷积压缩组件和CLIP组件。

其中SAM负责接受Patch，并且进行视觉感知特征提取，也就是提取Patch中的局部信息，将这些信息融合进它输出的Token中，这一步的算法，在计算量需求上是较大的，但是因为SAM的整体参数较少，所以使得算力需求也较低。SAM对Patch进行视觉感知特征的提取，将局部特征信息融合进Token中之后，就会经过一个16卷积压缩组件， 把这些VisionToken进一步压缩，仍然以1024*1024的图片输入为例，SAM输出4096个VisionToken，再经过卷积压缩组件之后就变成了1024/16*1024/16/16=256个VisionToken，传入CLIP中，CLIP使用VIT架构，计算全局注意力，会有计算量为序列长度平方倍的算力问题，但是因为传入的序列较短，这个问题也迎刃而解了。因此一张图片经历过一个完整的DeepEncoder之后，就会变成256个富含局部信息（SAM处获得）以及全局信息（CLIP处获得）的VisionToken。

相比起将语言特征抽取融合组成新语言的编码器Encoder，Decoder的概念则是将Encoder转换得到的新语言转换回去，这就是解码器的概念。而DeepseekOCR中使用的MoEDecoder是之前Deepseek提出的一个多专家架构的解码器，每次激活64个路由专家中的6个和2个共享的专家，共计570M的激活参数，论文中说这个架构能够有30亿参数的模型的表达能力，以及5亿参数小模型的推理效率。原文如下：

它的具体架构就不在这篇文章中解释了。

至此，DeepseekOCR的架构我们也大致了解一遍了，总结来说就是由DeepEncoder和MoEDecoder组成，而DeepEncoder又由SAM、16卷积压缩组件、CLIP串联组成。

到这里，这篇文章就结束了，我们已经明白DeepseekOCR的效果以及大致架构实现了！这是一个长足的进步！

如果你还有印象，并且有兴趣，我们可以一起来阅读下面的内容作为补充，这一部分是论文中提到的常见的视觉模型的架构缺陷。

前面提到的这张图是三种常见视觉模型的架构缺陷。本质上，各种视觉模型的架构想要解决的问题只有一个——如何高效处理像素信息？最简单的方法就是将每个像素点都进行计算，而这对算力需求极高；对算力需求最低的方法则是将整张图片处理成一个token，这样算力要求低，但是信息丢失也极大，因此多种架构的本质就是在权衡如何尽可能保留全局信息的同时降低算力需求。

第一种架构是双塔架构，利用类似SAM的组件识别高分辨率的图片后下采样传给模型，如果是低分辨率的图片则走下面的VIT直接提取完传给LLM，这种架构要两条路线，因此天生不适合并行，并且需要训练两个模型（两条路径各一个）。

第二种架构则是密集网格结构，本质就是切块，将图片切块成多块，处理加工后传给LLM，这种架构的问题是它对全局的理解较差，并且切块会大大增加视觉Token的数量，这增加了算力需求。

第三种架构是自适应分辨率结构，该架构是第二种架构的一个优化，使其更能适应各种输入尺寸的图片，但是本质问题仍然没有解决，那就是图片越大，Token越多，难以计算。

相比之下，DeepseekOCR提出的DeepEncoder架构通过SAM（局部专家）->激进压缩->CLIP（全局专家）这样一个非对称的专家流水线，将图片转化为少量Vision Token，一定程度上解决了以上架构面临的问题。

本文由 @石耳叫Ria 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议