DeepseekOCR的神奇之处揭秘！

现在市面上有很多文字识别工具，但你知道为什么DeepseekOCR突然变得这么火吗？其实，它的厉害之处在于，它不仅能“看清”文本，还能“看懂”内容。从发票到文档，从照片到表格，它让信息处理变得更加简单。

今天我们来聊聊这个让外国人纷纷赞叹的【天才般的想法】DeepseekOCR究竟做了些什么？

作为一个技术爱好者，我决定直接从论文入手，深入了解它的原理，马上就来。

论文结论

看论文的时候，第一步就是要看结论，DeepseekOCR的结论部分原文及翻译如下：

在这份技术报告中，我们提出了DeepSeek-OCR模型，并初步验证了上下文光学压缩的可行性，证明该模型能够从少量视觉标记中有效解码出超过10倍的文本标记。我们相信，这一发现将有助于推动未来视觉语言模型与大型语言模型的发展。此外，DeepSeek-OCR作为一个实用性极高的模型，能够生成大规模的预训练数据，成为大型语言模型的重要助手。当然，单靠OCR技术还不足以完全验证实际的上下文光学压缩，未来我们还需要进行数字与光学文本交错预训练和其它评估工作。从另一个角度看，光学上下文压缩仍有很大的研究和改进空间，未来充满了可能性。

用一句话总结这段话，那就是“我们通过DeepseekOCR模型验证了上下文光学压缩（Context optical compression）确实可以把大量的Text Token压缩成少量的Vision Token。”

这里面有三个关键词需要弄明白，分别是上下文光学压缩（Context optical compression）、视觉Token（Vision Token）和文本Token（Text Token）。

那么什么是视觉Token和文本Token呢？

我们知道大模型实际上是一个复杂的处理和预测Token的神经网络，那什么是Token呢？

Token可以简单理解为大模型的“词汇”。比如在汉语中“我爱你”和英文的“I Love You”意思是一样的，也就是说，汉语中的“我”相当于英文的“I”，而“爱”相当于“Love”。那么大模型是怎么理解“我”的呢？它会把“我”映射成一个索引，以GPT-4O为例，“我爱你”这三字会被转化为[7522, 6414, 12370]这样的三个索引。听起来有点复杂，但其实这就像是模型自己的一种语言，模型里的“7522”就是我们说的“我”，每个模型的索引就是一个token。需要注意的是，一个Token不一定对应一个字，比如“今天月色很美”这句话在模型里变成了[47256, 3181, 4472, 18730, 5084]，为什么六个字变成了五个索引呢？因为“今天”这两个字在模型眼中就是一个Token，类似于英文的“Today”。

理解到这里，就能明白Text Token的含义了，那Vision Token又是什么呢？

我们刚才讨论的是文本层面的模型理解方式，也就是说如何把汉字转化为模型能理解的索引，每个索引就是一个Token。而如果模型处理的是图片呢？论文中提到三种在VLM中常用的处理方式：

PS：这张图片可能有点难理解，别担心，详细的解释会放在最后，因为这部分是技术讨论，不适合放在正文中。

深度探讨DeepseekOCR的创新成就

我们来聊聊处理图片的方式，其实说白了，图片就是由很多小点（像素）构成的。如果把每个像素看作一个Token，那一张1024*1024的图片就得用超过一百万个Token来描述，这个数字听起来是不是很惊人？就像是《战争与和平》的字数一样多。为了简化处理，几乎所有的视觉语言模型（VLM）都会采用“Patch”这一策略，也就是把一些像素合并成一个patch，用一个token来代替这些像素所表达的信息。假设我们把16*16的像素当成一个patch，那么1024*1024的图片就能缩减为4096个token，这些token被称作视觉Token（Vision Token）。

现在，你应该明白什么是视觉Token和文本Token了。接下来，我们再回到DeepseekOCR的核心发现：“我们通过DeepseekOCR模型发现，能够用上下文光学压缩（Context optical compression）技术把数量庞大的文本Token（Text Token）压缩成少量的视觉Token。”理解了这两种Token的定义后，回头再看这句话，你会发现Deepseek团队的智慧之处。他们证明了少量的视觉Token也能携带大量文本Token所包含的信息。这一发现有望解决长文本Token的难题。他们的天才之处在于，当大家都在探讨如何缩短文本Token时，他们却提出了将其转化为视觉信息的想法。有时候，创新真的就这么简单，只需一步之遥。

DeepseekOCR的卓越成就

DeepseekOCR作为一个开源平台，取得了不少令人瞩目的成绩，下面就来看看其中一项：

在上面的图表中，我们可以看到Deepseek-OCR的各个型号在OmniDocBench测试集上的表现，分数从最小的Tiny型号的0.3+一路飙升至Gundam-M的0.1+。这里的分数指的是编辑距离（Edit distances），假设一个模型的编辑距离得分是0.12，意味着它识别出的内容有12%的部分需要修改才能与原文完全吻合。所以，这个分数越低，模型的性能就越好。从数据中我们可以得知，Deepseek-OCR Gundam-M（200dpi）在这一测试中取得了最高分，并且所使用的视觉Token数量大约是dots.ocr（200dpi）的三分之一。值得注意的是，在使用800个视觉Token的情况下，DeepseekOCR的表现竟然比传统使用7000个视觉Token的模型更出色。

分数这么高，数据集会不会太简单呢？让我们来看看这个数据集的一些示例吧：

DeepseekOCR的惊人表现及其背后的技术揭秘

从整体来看，这个数据集的内容可谓五花八门，不光有文字，还有公式、图形等各种符号，甚至包括一些扫描件。这意味着它的难度并不小，因此DeepseekOCR能够取得这么高的分数，真是让人忍不住想说一句“太厉害了”！

技术实现探秘

到目前为止，我们大致了解了DeepseekOCR的突破之处，但真正的技术实现才刚刚开始。接下来，我们要关注两个关键点：DeepEncoder和MoE Decoder。下面的架构图将帮助我们更清晰地理解DeepseekOCR是如何达到如此成就的。

揭秘DeepseekOCR架构，了解图像处理的奥秘

整张图一看就能分成三个部分：第一部分是图像切块，第二部分是DeepEncoder的流程，第三部分则是MoEDecoder产生的输出。

图像切块是什么？

其实，几乎所有视觉模型都需要经过这个步骤。为什么呢？如果直接处理每一个像素，计算压力可就大了。因此，DeepseekOCR跟大多数模型一样，选择对图片进行切块，具体来说就是把16×16个像素拼成一个Patch。这样一来，一张1024×1024的图片就能用4096个Patch来表示，简单又省力。

DeepEncoder是什么？

说白了，Encoder就是一个信息的打包和翻译高手，可以把某种语言A转化成另一种我们看不懂的语言B。在DeepseekOCR中，DeepEncoder的任务就是接收被切块的图片，转化成包含所有信息的Vision Token。

而DeepEncoder的过程其实可以分成三个环节：SAM组件、16卷积压缩组件和CLIP组件。

首先，SAM负责接收Patch，提取视觉特征，也就是从Patch中提取局部信息并将其融入输出的Token中。虽然这一步的计算量很大，但由于SAM参数较少，算力需求也相对较低。经过SAM提取后，输出的Token再经过16卷积压缩组件处理。以1024×1024的图片为例，SAM输出的4096个Vision Token经过卷积压缩后，就变成了256个Vision Token，这些Token会传递给CLIP。CLIP使用VIT架构，计算全局注意力，虽然计算量大，但因为传入的序列较短，所以问题迎刃而解。最终，一张图片在DeepEncoder完整流程后，就会变成256个包含局部和全局信息的Vision Token。

MoEDecoder是什么？

相比于编码器Encoder的工作，Decoder的作用就是把Encoder得到的新语言转回去。在DeepseekOCR中，使用的MoEDecoder是一个多专家架构的解码器，这个架构每次激活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协议