原创 孔某人 2025-10-22 00:43 北京
又一个被媒体抬高的工作
其实本来没想说特地评论这个模型，但到现在其实各种分析也都攒得七七八八了，就来凑数一篇模型层相关话题的文章。
https://github.com/deepseek-ai/DeepSeek-OCR/blob/main/DeepSeek_OCR_paper.pdfhttps://huggingface.co/deepseek-ai/DeepSeek-OCR
DeepSeek-OCR的效果
首先DeepSeek OCR论文上跟其他OCR的对比结果，只有跟MinerU 2.0的，没有跟最新的MinerU 2.5比。也没有跟其他最新的OCR模型来比。所以还不能说DeepSeek-OCR已经登顶，或者说目前来看大概率没有登顶。
另外对于文章中着重提到的压缩率问题。该方案的准确率标准是较为严格的，是整页全部正确的比例。但压缩率的指标其实不是很公平。视觉token和文本token其实是很不同的，文本token就是一个几十万~几百万水平的整数，经过embedding之后也仍然只是几十万到几百万的独立向量值。但该方案的视觉token并没有经过离散化过程，而是直接投影到1280维内部表示的，相当于是个1280维的embedding，如果统计视觉token embedding取值的分布，你会发现它是连续分布，有非常多的取值。所以两者虽然维度一样，但本质完全不同。从1维整数的表示到1280维浮点数表示，压缩率10-20x，是不是听起来就正常了很多？甚至会觉得就这？DeepSeek-OCR并没有创造奇迹。
如果你用Gemini模型，输入PDF，你会发现它计算token的方式是每页258个token。说明Gemini其实也是使用了这样视觉token的方式，当然实际上Gemini是全模态的模型，它支持文本和图片token，而不限于它们。当然从一些看到的测试来看，Gemini模型对于中文字符的支持并没有英文那么好。在专门训练的角度来说Gemini 2.5系列模型仍然对于非英语字符有些欠训练。
视觉Tokenizer给我们的启示
当然把文本转成图片再进行tokenize也并不是一无是处。你认真琢磨这个方案和它的效果，你会认识到目前文本token作为一个中间表示的瓶颈。目前的文本token并不能充分地利用LLM模型内部给每个token预留的表示能力。
从这个角度上来说，我们创造一种能够更加充分利用LLM模型对于token表示能力的tokenizer可能是有益的。特别是token的数量直接关联到LLM模型的计算成本，换用一种信息表示密度更高的tokenizer方案至少可以降低计算成本。
但这并非非要通过图片作为中间表示，只是图像作为中间表示适合于一些这方面的数据源，例如文件的扫描件、PDF文件等，模型变得可以直接处理它们。
这里简单抛一个其他表示方案的baseline：把连续的16个token的文本作为一个chunk，再向前padding之前的8个token做overlap，使用一个LSTM结构进行处理，聚合输出为一个embedding表示。这个方式也可以把文本token压缩为一个更高密度的表示，压缩率16：1。
所以其实目前到了一个应该重新review我们上古的文本tokenizer设计的时候了。旧的tokenizer不止输入上的效率不高，输出也是按token来的，效率其实更低。
结语
整体上，我对这个工作技术报告的OCR之外的部分，感觉是噱头成分较高的，相对于DeepSeek的其他工作来说。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 专栏简介 及 联系方式 2024。
本文于2025.10.22 首发于微信公众号。
