DeepSeek OCR究竟解决了什么问题？

在AI模型泛滥的时代，OCR技术似乎早已“卷无可卷”。但DeepSeek OCR的出现，却重新定义了“识别”的边界。它不仅提升了识别精度，更在多语言、多场景、多任务之间实现了统一架构的突破。本文将深入解析DeepSeek OCR的技术路径与产品定位，探讨它究竟解决了哪些长期被忽视的痛点。

打开今日头条查看图片详情

DeepSeek-OCR采用“看图识字”的机制替代传统大模型“逐字阅读”的机制，在超长文本（比如读长文档、读书等）场景，实现保证内容识别精度的前提下，让算力成本降低将近10倍，并极大的提升模型计算效率、改善记忆负载；所以这次又是一次“降本增效”的升级。

以上是对DeepSeek-OCR的一个快速理解，这篇文章，我不去关注这项技术多牛逼和以及怎么实现的等相关的问题，更多的是站在产品经理实用的角度去理解DeepSeek-OCR，我将重点理解清楚如下几个问题：

1.DeepSeek-OCR到底解决了哪些目前存在的行业问题和痛点？与传统OCR的区别？

2.DeepSeek-OCR的性能和表现数据如何？

3.从应用层的角度看DeepSeek-OCR将影响哪些应用场景？

4.技术社区和专家观点评价

5.DeepSeek OCR将带来哪些行业思考？

6.企业和AI应用怎么使用？

1.DeepSeek-OCR解决了什么行业问题？

1.AI应用领域目前存在的行业痛点

在实际的AI应用场景中，特别是办公场景，相信大家有大量的应用场景是跟文档（包括PDF和word文档等）有关的，比如阅读文档、基于文档的内容生成等，大模型在文档处理这个领域的技术，会影响到相当多的AI应用和使用场景，因此这个领域的痛点，也是一个普遍存在的行业痛点。

只要是做过跟文档处理相关的 AI 应用的朋友，都会知道文档处理是一个充满技术挑战的难题。以 AI 快研侠在实现 AI生成报告的场景为例，我们主要遇到了如下3个问题：

1）文档内容识别和信息提取问题

大家平时提交给大模型和AI应用的大部分文档里面，有很多是以PDF或者Word的格式存在的，通常这些文档里面可能不仅仅只有文字，还可能存在图片、图表、表格等比较复杂的内容。

这些内容大模型是无法直接识别和理解的，通用大模型目前只能处理文本信息的内容，所以现有的AI读文档的应用，实现机制大部分是只提取文档中的文本内容，然后把它们提交给大模型用于内容生成，而其中的图片、表格、图表这些基本上会被忽略，这就很容易导致信息丢失从而影响AI应用的效果的问题。

可是如果想要去识别这些信息，现有的方式主要是通过OCR和多模态大模型来处理，将信息提取转来转换成文本之后交给大模型，然而，这种方式的识别成本非常高，除了面向企业的应用场景有可能会使用之外，普通面向C端的产品基本不太可能使用这种方式来实现。

2）生成成本巨大和处理时间很长的问题

基于文档生成的场景还有一个普遍存在的问题，就是生成成本巨大的问题，比如大家随便上传几个文档，可能字数就会超过十几万字，和AI聊天的场景等不同的是，生成一篇长文的时候，其token的消耗很容易就会达到百万级别的消耗，所基于文档生成的场景也是一个非常消耗成本的应用场景。

因为处理的文件数量和字数比较多，所以也通常导致了模型需要很长时间去处理的问题，最后导致的结果就是生成文本的时候，用户需要更多的等待时间，从而影响用户的体验。

3）超长文本情况下，大模型出现失忆的问题会更严重

大家都知道，大模型存在上下文长度的窗口，一旦输入的内容太长，大模型就很容易出现失忆的情况，相信大家也经常会遇到，在使用chatgpt类产品用于文档对话问答的情况下，常常会出现对话了几轮之后模型就出现了失忆的情况，所以，失忆的问题也是AI应用场景经常需要面临的挑战。

2. DeepSeek OCR 如何解决以上的行业问题？

1）DS-OCR采用将文本“画”成图像再压缩读取的方式解决内容识别问题

对于文档内容识别的问题，DeepSeek OCR采用了光学压缩的机制来实现，该机制的实现方式是：

• 它先把长篇的文字内容“绘制”成一张（或多张）图像。
• 然后，利用视觉模型（后文会提到的DeepEncoder）把这张信息量巨大的图像，压缩成极少数的“视觉token”（你可以理解为“视觉信息单元”）。
• 最后，语言模型（解码器）再从这些高度浓缩的视觉token中，把原文解码并恢复出来。

这个方式相比传统OCR的识别方式，可以做到在保证识别率精度的情况下，把识别成本进一步压缩的更低，DeepSeek-OCR 的实验数据显示，在 10 倍压缩率下（例如，把一篇 1000 个词的文章压缩成 100 个视觉 token），原文的恢复率高达 97%，几乎做到了无损。

对于AI应用开发者来说，相当于我们拥有了一种成本更低的方式去解决文档识别的问题，因此对于AI应用层来说，DeepSeek-OCR是我们听到的福音；

2）“看图阅读”的方式极大提升信息处理效率，也降低了生成成本

光学压缩的方式，简单一点理解，就是用少量视觉token表示大量文本token，以此来大幅降低后续语言模型处理时的计算开销。

前面也提到，用这种方式实现的情况下，同样处理比如1000个文本token对应长度的内容（比如1700个汉字），之前的大模型处理的方式需要阅读1000个文本token，而视觉压缩的方式，只需要阅读100个视觉token，因此信息处理量明显下降，处理的效率大幅提升，同时也降低了生成成本。

通俗一点理解，这种方式的意义在于，它让AI从“逐字阅读”（处理海量的文本 token）转变为“看图阅读”（处理极少的视觉 token）。这就好比你看书时，不是一个字一个字地读，而是一眼扫过去就抓住了整页的核心内容，信息处理的效率得到了根本性的提升。

值得注意的是，前面部分节省的是OCR的成本，如果AI应用开发者放弃了支持图片和图表等信息识别的能力，这部分成本也没啥区别，但是文本处理部分是一定会发生的，Deepseek-OCR目前的机制，意味着可以让应用开发者在处理文本部分的成本就直接大幅下降（可能是降低10倍）。

3）改善大模型失忆的问题

前面提到，大模型失忆的主要问题是因为输入内容过长，超过了上下文长度而导致的，DeepSeek OCR 目前的实现方式直接通过视觉压缩的方式，可以把文本token的长度压缩10 倍，因此，这对于改善大模型失忆的问题大有裨益。

以下通过一张表清晰的对比为了解决文档识别的应用场景问题，传统的技术方案和DeepSeek-OCR方式的差异：

打开今日头条查看图片详情

一句话总结而言，DeepSeek OCR 让相当多的AI应用开发者在处理文档技术问题的时候，以更低的成本解决内容内别的问题，同时还降低了大模型文本输入的成本，提升响应的效率，以及环节了超长文本下大模型的失忆问题。

2.DeepSeek-OCR的性能和表现数据如何？

1）识别精度表现：10倍压缩的情况下，几乎无损精确识别

除了压缩成本等相关的问题，大家对于DeepSeek-OCR更加高度关注的是其识别精度的问题，目前在大家相对比较认可的Fox 基准测试（一个专门测量在不同压缩率下的精确文本匹配能力的测试）中，测试结果显示：

当使用 100 个视觉 token（作为压缩预算）时：

• 对于包含600-700个文本token的页面，压缩成100个视觉token的时候（约6.7倍压缩），模型精度高达98.5%。
• 对于包含900-1000个文本token的页面（约9.7倍压缩），模型精度依然保持在96.8%。

这说明在 10 倍左右的压缩率下，模型几乎是“无损”的。

当把压缩预算降低到 64 个视觉 token（意味着压缩率更高） 时，模型的表现如下：

• 精度会随着压缩率的增加（即页面上的字数变多）而下降。
• 当压缩率达到19.7倍时（处理1200-1300文本token），精度会降至59.1%。

这符合直觉：给的“信息预算”越少，能承载的原文信息就越有限。

打开今日头条查看图片详情

2）性能表现：达到SOTA，在OmniDocBench上表现优异

在业界公认的权威基准测试 OmniDocBench 上，deepseek-ocr取得了 SOTA（State-of-the-Art，即业界顶尖）的性能。

• 它用最少的toke达到了顶尖的性能，也就是说可以使用最少的算力开销，实现精准的识别效果；
• 仅用100个视觉token/页，就超过了同样优秀的GOT-OCR2.0（使用了256token）。
• 使用了不到800个视觉token，就优于了平均使用近7000token/页的MinerU2.0。

3）生产效率：单A100每天可处理超20万页

这个模型不仅效果好，而且“跑得快”。在生产环境中，单块 A100-40G 的 GPU 每天可以生成（处理）超过 20 万页的训练数据。这意味着它具备了大规模商业化落地的高吞吐量能力。

3.DeepSeek-OCR将影响哪些应用场景的发展？

宽泛一点讲，所有跟文档识别相关的应用场景，都会受益，个人认为，重点受益的场景主要包括如下：

• 办公文档的处理和生成场景：比如AI阅读文档和报告，AI生成文档与报告，DeepResearch等应用领域；
• 纸质档案电子化：政府、银行、医院、图书馆的海量历史档案、病历、卷宗，可以被快速电子化并实现检索。
• 实时证件识别：在机场、酒店、银行柜台，自动识别身份证、护照、银行卡，实现自动填表和身份核验。
• 法律/知识产权检索：快速处理扫描版的判决书、专利说明书，用于法律检索和分析。
• 风控与打假：自动比对合同、发票、仓单上的关键字段，或者识别车牌、集装箱号，用于防伪和风险控制。

4.技术社区和专家观点评价

1）硅谷热议，被誉为“AI的JPEG时刻”

模型一经发布，就因为它 3B（30亿）参数的“小”规模、带来的指数级效能变革以及“大道至简”的设计思想，在硅谷引发了热议。

• 有人认为它甚至开源了谷歌Gemini商业机密的核心思路。
• 特斯拉前AI总监Karpathy（卡帕西）也称赞其“图像比文字更适合LLM输入”。
• 行业内将其称为“AI的JPEG时刻”，意思是它像JPEG压缩图像一样，为AI处理和存储记忆开辟了一条全新的、高效的路径。

2）DeepSeek将模型连同权重开源，实现“把贵的东西做成白菜价”

DeepSeek 团队延续了他们一贯的风格，将这个强大的模型连同权重一起开源了。这相当于“把贵的东西做成白菜价”，让所有开发者都能享受到这项技术红利，这对于整个 AI 领域，特别是文档处理（Document AI）方向，是实用且重要的一步，所以也获得了广大AI应用开发者的好评；

3）争议：10倍压缩97%精度，需在实际工作负载中验证

DeepSeek 宣称的“10 倍压缩 97% 精度”是在特定基准（Fox）上测试的，这个声明是否能在用户实际的、五花八门的工作负载中同样成立，还需要大量的实践来验证。

4）争议：OCR是否已“基本解决”？

社区对于“OCR 是否已经被 LLM 基本解决了”这个问题，存在巨大争议：

正方观点（如 pietz）：认为 OCR 基本解决了。例如 Gemini 2.5 Flash Lite 已经能以极低成本（1000 页/$0.20）处理多种 OCR 任务。

反方观点（如 cahaya, carschno, mormegil）：坚决反驳。

• 复杂表格：LLM在转换包含多层标题、合并单元格、复选框的复杂表格时，仍然会频繁失败。
• 手写体识别（HTR）：HTR仍然非常困难。LLM在处理手写体时，经常会“幻觉”出看似正确但与原文完全无关的内容。而像transkribus.eu这样的专用工具表现好得多。

有开发者（breadislove）认为，端到端的 OCR（即模型一步到位完成所有事）仍然“极其棘手”。在实际工程中，组合式的流水线（先做布局检测 -> 再做阅读顺序判断 -> 最后再做 OCR）效果往往更好。

5）挑战：Karpathy指出的不对称性、成本和生态问题

Karpathy 本人也指出了“以图为入”的几个挑战：

• 不对称性：用户输入可以是图像（压缩），但模型的输出（生成）仍然需要是文本。因为让AI生成一张逼真的、包含特定文字的图像，本身还是一个未解决的难题。
• 计算开销：图像编码（如DeepEncoder）本身的计算开销是不容忽视的。
• 可编辑性：文本一旦被“图像化”，就失去了可编辑性。
• 生态兼容性：现有的AI工具链（如RAG、向量数据库）都是围绕文本token构建的，如何与这种新型的视觉token兼容，是一个巨大的工程问题。

五、DeepSeek OCR将带来的行业思考

1.使用图像作为LLM输入可能比传统文本更高效

特斯拉前AI总监Karpathy评论：使用图像作为LLM输入可能比传统文本更高效，他的观点甚至挑战了“文本 token 是标准输入”这一常规假设，并暗示了“语言模型”（Language Model）未来可能会向更通用的“信息处理模型”（Information Processing Model）进化，而视觉（图像）可能是比文本更通用的信息载体，其中的原因包括：

1）一个图像patch可包含多个字符

• 传统的文本输入，一个token（计算单元）通常只代表“一个词的一部分”。
• 而在图像输入中，一个视觉token（例如一个图像patch）可以代表“一页的一部分”，这个“部分”里可能天然就包含了多个单词或字符。

2）图像天生支持粗体、颜色、布局等视觉元素，纯文本输入会丢失大量信息。例如，“加粗”、“红色”、“标题字体”、“段落布局”，这些信息在纯文本中要么丢失了，要么需要用 HTML 或 Markdown 这样的额外标记（markup）来描述。而图像输入天生就“看”到了这些视觉元素，信息更丰富。

3）图像输入可使用更强的双向注意力

• 文本生成（解码）通常使用“自回归因果注意力”（只能看前面的内容）。
• 而图像编码（理解）可以使用“双向注意力”（可以同时看前后左右的内容），这种机制的理解能力通常更强。

2.突破LLM“内存限制”，使AI能处理数百页超长上下文

这项技术的潜力在于，它有望突破 LLM 的“内存限制”。当 AI 能够以极高压缩率处理信息时，它就有可能用更少的算力去处理以往无法想象的超长上下文，比如几百页的财报或一整本小说。

3.未来构想：AI可将旧记忆存储为图像，实现高效信息归档

一个有趣的未来构想是，AI 可以将“旧的记忆”（即久远的上下文）存储为图像，以此来实现高效的信息归档。

4.“用光学压缩模拟人类遗忘机制”，更好的解决计算资源的问题

这个构想进一步被比作人类的“遗忘曲线”，模拟了自然的记忆和遗忘过程：

• 近期上下文被视为“高保真记忆”，系统会将其保存为高分辨率图像（信息保真度高，压缩率低）。
• 远期上下文被视为“低密度记忆”，系统会将其压缩为更模糊的图像（信息密度低，压缩率高，token消耗少）。

这种“文本遗忘”机制，是平衡无限上下文信息和有限计算资源的一个早期研究方向，未来可能带来巨大突破。

六、企业如何部署和使用？

DeepSeek-OCR 不仅仅是一个研究模型，它提供了清晰的使用和部署路径。

1.DeepEncoder支持多种具有固定token预算的“原生分辨率”模式

模型提供了多种“档位”供开发者选择，让你可以根据需求平衡成本和性能。这些被称为“原生分辨率”模式：

• Tiny(微小档)：512×512分辨率，压缩为64tokens。
• Small(小档)：640×640分辨率，压缩为100tokens。
• Base(基础档)：1024×1024分辨率，压缩为256tokens。
• Large(超大档)：1280×1280分辨率，压缩为400tokens。

2.DeepEncoder还支持“动态分辨率”模式（Gundam）

除了固定档位，它还支持一种更强大的“动态分辨率”模式（Gundam），这种模式会混合平铺的“局域视图”（看清细节）和“全局视图”（看清整体布局）。

• 这种模式会产生更多的token，例如+256tokens（n在2-9之间）。
• 这些模式允许开发者根据页面的复杂度，灵活地平衡token预算（即成本）和性能。

3.官方建议

1.对于典型文档（报告、书籍），建议从Small模式（100 tokens）开始测试

在实际评估时，官方给出了建议：

• 对于绝大多数典型文档（如报告、书籍），建议从Small模式（100tokens）开始测试。这个档位在成本和精度上取得了最好的平衡。
• 模型发布了明确的token预算模式，从64tokens(Tiny)到400tokens(Large)以及复合的Gundam模式，PM可以根据业务场景的复杂度来选型。

2.对于包含密集小字体或极高token数的页面，应使用Gundam模式

如果你的业务场景非常极端，比如页面上塞满了密密麻麻的小字体，或者单页的 token 数极高，那么应该使用Gundam 模式。Gundam 模式结合了全局和局域视野，并提供了明确的 token 预算，专为复杂场景设计。

3.通过二次模型调用（需提示词），模型能对复杂结构的内容进行深度解析和推理

需要注意的是，该模型还可以支持图表、几何图形、化学公式等复杂元素的深度解析和推理，通常需要通过“二次调用”并配合特定的提示词（Prompt）来实现，具体可以后续大家需要的时候详细体验和关注，其中包括：

• Markdown识别：能处理模糊的电子书页面，并将其转换为结构化的Markdown格式。
• 深度解析（DeepParsing）：它能通过自动推理和纠错，来修正初步识别的结果。比如，如果初步识别漏掉了字母，它可以通过上下文推理进行修复。

同时官方也提供了一些提示词示例如下：

• 文档（带布局）：n<|grounding|>Convertthedocumenttomarkdown.
• 无布局OCR：nFreeOCR.
• 图表解析：nParsethefigure.
• 内容定位：nLocate<|ref|>xxxx<|/ref|>

4.模型已开源，Hugging Face和GitHub提供了部署指引

模型的部署门槛相对较低：

• DeepSeek在GitHub上提供了快速部署指引，并在HuggingFace上开源了模型。
• 它提供了一个经过测试的、可立即使用的设置（Python3.12.9，CUDA11.8，PyTorch2.6.0，FlashAttention2.7.3），以及适用于普通GPU的6.67GB分片，这大大降低了工程师的设置成本。
• 安装环境前提为cuda11.8+torch2.6.0，并需要安装vllm-0.8.5和flash-attn==2.7.3。
• 推理支持vLLM（推荐，用于图像、PDF和批量评估）和标准Transformers(HF)两种方式。
• vLLM方式下，直接运行run_dpsk_ocr_image.py或run_dpsk_ocr_pdf.py即可。
• Transformers方式下，使用AutoModel.from_pretrained加载deepseek-ai/DeepSeek-OCR即可。

以上为我站在产品经理角度，对于当下大家热评的DS OCR的一些理解和观点