DeepSeek-OCR：从“识字”到“理解文档”，重新认识 OCR 2.0 与上下文光学压缩

传统 OCR 解决的是“图片里写了什么”，而现代文档智能系统真正需要解决的问题已经变成了：这段文字在文档中扮演什么角色，它和表格、公式、图片、图表之间是什么关系，以及如何把整份 PDF 还原成机器可以继续理解、检索和推理的结构化知识。

DeepSeek-OCR 可以放在这个变化中理解。它不是单纯把字符识别得更准，而是把 OCR、版面理解、视觉语言建模和结构化生成放到统一的多模态框架中，并进一步提出 Contexts Optical Compression（上下文光学压缩）：尝试用更少的视觉 Token 表示大量文本信息，再由语言模型完成“解压”和重建。

这篇文章结合实践资料，重点梳理 DeepSeek-OCR 的技术定位、核心架构、DeepEncoder、上下文光学压缩、本地部署、 Transformers/vLLM 调用，以及它在多模态 RAG 中真正有价值的工程位置。

一、OCR 的问题已经不只是“识字”

最早的 OCR（Optical Character Recognition，光学字符识别）主要完成两个任务：

Text Detection：先找到图像中的文字区域；
Text Recognition：再把区域中的像素识别成字符。

典型系统通常采用 CNN、LSTM、CRNN、CTC 等技术路线。它们非常适合身份证、票据、扫描件、发票等场景，但它们的目标本质上仍然是：

把像素变成字符。

对于普通文本，这已经足够。但一旦面对论文、财务报表、专利、技术手册、CAD 图、双栏 PDF、复杂表格和数学公式，问题就出现了。

例如下面这些信息，仅有文字识别远远不够：

某句话到底是一级标题、图注还是正文；
一组数字属于哪一列、哪一个表头；
一个公式的上下标、分式、矩阵关系应该如何恢复；
多栏排版应该按照什么顺序阅读；
图片和正文之间是否存在“图 1 展示了……”这样的语义关系；
流程图中的节点和箭头应该如何解释。

所以，文档智能的发展逐渐从“识别字符”走向了“理解文档”。

OCR 1.0 与 OCR 2.0 的区别

能力	OCR 1.0	OCR 2.0 / VLM OCR
文字识别	强	强
版面结构	通常依赖独立布局模型	可直接建模
表格	多阶段解析	可生成 Markdown/HTML
公式	需要专用模型	可生成 LaTeX
图像语义	基本没有	可描述、理解
输出	纯文本、坐标	Markdown、HTML、JSON、自然语言
适用场景	文档数字化	文档理解、多模态 RAG、知识抽取

OCR 2.0 的核心，不是简单把 OCR 模型“做大”，而是把 OCR 纳入 Vision-Language Model（VLM） 的统一语义框架中。

二、VLM 为什么能够把 OCR 从“识字”升级为“读文档”

现代 VLM 的基本思想是：将视觉信息和语言信息映射到可以共同建模的表示空间中，让视觉 Token 能够进入语言模型的上下文。

一条典型链路可以抽象为：

Image / PDF
    ↓
Vision Encoder
    ↓
Visual Tokens
    ↓
Projector / Alignment
    ↓
LLM Embedding Space
    ↓
Language Decoder
    ↓
Markdown / LaTeX / JSON / Natural Language

视觉编码器首先把图像切成 Patch，并编码为高维表示：

$$
I = {v_1, v_2, \ldots, v_n}, \quad v_i \in \mathbb{R}^d
$$

文本则被编码为语言 Token：

$$
T = {t_1, t_2, \ldots, t_m}, \quad t_i \in \mathbb{R}^d
$$

关键问题是：视觉表示如何进入语言模型能够理解的空间。

常见路线包括：

方法	典型思路	特点
Contrastive Learning	让图像和文本向量在语义空间中靠近	更偏语义对齐
Projection Head	用 Linear/MLP 把视觉特征映射到 LLM Embedding Space	结构简单
Cross-Attention	视觉 Token 与语言 Token 动态交互	更适合生成和推理

从工程视角看，可以把演进理解为：

CLIP：图文对齐
   ↓
BLIP / BLIP-2：图文交互
   ↓
LLaVA 类模型：视觉信息进入 LLM
   ↓
DeepSeek-OCR：面向文档理解和结构生成进行专门优化

因此，DeepSeek-OCR 的目标并不是成为“通用聊天 VLM”，而是把多模态能力集中投入到文档解析这个高价值场景。

三、DeepSeek-OCR 到底是什么

从功能上看，DeepSeek-OCR 可以理解为一个面向 OCR 2.0 的文档 VLM。

它可以承担的任务包括：

图片自由 OCR；
保留版面结构的文字提取；
PDF 转 Markdown；
表格解析；
数学公式识别并生成 LaTeX；
图表和复杂图片描述；
Grounding，定位指定元素；
Object Detection；
文档结构化输出。

传统 OCR 的输出可能只是：

DeepSeek OCR
Context Optical Compression
4096 token
256 token

而文档 VLM 更希望输出：

## DeepEncoder

DeepEncoder 在高分辨率图像编码之后执行 Token 压缩：

- 输入视觉 Token：4096
- 压缩倍率：16×
- 输出视觉 Token：256

该设计用于降低全局注意力阶段的计算和显存开销。

区别就在于：后者已经开始恢复结构和语义关系。

DeepSeek-OCR 模型示意

四、DeepSeek-OCR 的核心架构

DeepSeek-OCR 的整体思路仍然可以抽象为三段：

视觉编码器
    ↓
投影 / 对齐
    ↓
语言解码器

但它真正有意思的地方不只是“VLM + OCR 微调”，而是进一步思考了一个更底层的问题：

如果一页包含大量文本的文档，本来就可以在二维图像中非常紧凑地表示，那么是否可以直接利用视觉模态压缩长文本上下文？

这就是 Contexts Optical Compression。

五、核心创新：Contexts Optical Compression

1. 为什么视觉有可能成为文本压缩介质

假设一页 PDF 中包含几千甚至上万个文本 Token。

如果把它直接送入 LLM，Transformer 的计算和显存成本会随着序列长度快速增长。而同样的信息如果先被排版成一张图像，二维空间天然具有极强的信息密度。

所以 DeepSeek-OCR 探索了一条反过来的路线：

大量文本
   ↓ 渲染/视觉表示
二维图像
   ↓ Vision Encoder
少量视觉 Token
   ↓ LLM Decoder
恢复文本和结构

它把 OCR 看成一个天然的“压缩—解压”实验：

图像编码器负责压缩；
视觉 Token 是压缩后的中间表示；
语言解码器负责把这些表示恢复成文本。

因此，OCR 不再只是终点任务，也变成了验证“视觉能否压缩上下文”的实验平台。

Contexts Optical Compression 示意

2. 原资料中的压缩实验结果

资料给出的 Fox Benchmark 实验结果中：

当文本 Token / 视觉 Token 的压缩比低于约 10× 时，解码准确率可达到 96% 以上；
当压缩比提升到约 20× 时，OCR 准确率仍可维持在约 60%。

这组数字最值得关注的不是“OCR 排名”，而是它验证了一件事：

一个相对紧凑的语言解码器，确实可以从高度压缩的视觉表示中恢复相当多的文本信息。

视觉 Token 压缩实验

这为两个方向提供了启发：

VLM 的 Token Budget 可以重新设计；
超长上下文不一定只能依靠不断增加文本 Context Window。

3. 一个更容易理解的类比

假设有一页密密麻麻的技术文档。

如果按文本送给模型，可能需要几千个 Token；但人类看这页纸时，并不是先把所有字符逐个转换成脑内 Token 再理解，而是会利用：

空间布局；
标题层级；
表格结构；
视觉聚类；
字体和位置；
上下文关系。

DeepSeek-OCR 的思路，某种程度上就是尝试让模型也使用这种高密度二维表达。

六、DeepEncoder：真正执行视觉 Token 压缩的关键

仅仅提出“视觉压缩文本”还不够，真正困难的问题是：

高分辨率文档图像本身也会产生海量视觉 Token，怎么避免视觉编码器先被自己撑爆？

DeepSeek-OCR 为此设计了 DeepEncoder。

资料中给出的 DeepEncoder 可以概括为三段：

高分辨率图像
    ↓
Window Attention
    ↓
16× Token Compressor
    ↓
Global Attention

核心组件包括：

视觉感知特征提取组件：以窗口注意力为主，资料中描述为基于 SAM-base，约 80M 参数；
16× Token Compressor：通过两层卷积进行 Token 下采样；
视觉知识特征提取组件：执行密集全局注意力，资料中描述为基于 CLIP-large，约 300M 参数。

4096 → 256

资料给出的典型示例是一个 1024 × 1024 输入：

初始视觉 Token：4096
        ↓
窗口注意力处理
        ↓
16× Token 压缩
        ↓
视觉 Token：256
        ↓
全局注意力

这一步很关键。

如果一开始就让 4096 个视觉 Token 全部进入高成本全局注意力，显存和计算开销会非常大。而 DeepEncoder 先利用窗口注意力提取局部视觉信息，再把 Token 数量压到 256，最后才进行全局建模。

DeepEncoder 架构

从架构设计角度看，它在做一件非常经典但非常重要的事情：

把昂贵操作放到降采样之后。

这也是 DeepSeek-OCR 能够讨论“高压缩 + 高分辨率”时真正的工程基础。

七、它对超长上下文还有什么启发

原资料进一步讨论了一个很有想象力的方向：记忆压缩与渐进式遗忘。

例如，可以把历史文本渲染成图像，再通过不同分辨率进行分层压缩：

近期上下文
高分辨率、高保真

较早上下文
中等分辨率、中等 Token

很久以前的上下文
低分辨率、更高压缩比

这会形成一种类似“遗忘曲线”的信息保存方式：越近的信息越清晰，越远的信息越模糊，但不会立刻完全丢失。

这个想法目前更适合作为架构启发，而不是直接等同于已经解决“无限上下文”。但它确实提出了一个值得关注的问题：

LLM 的长期记忆是否一定只能以文本 Token 的形式存在？

多级视觉压缩与记忆示意

八、DeepSeek-OCR 的任务与 Prompt

DeepSeek-OCR 的一个实用特点是可以通过 Prompt 切换不同任务。

1. Free OCR

适合快速抽取图片中的文字：

1 2	`<image> Free OCR.`

关注点是“把内容读出来”。

2. 纯文字 OCR

1 2	`<image> OCR this image.`

更适合只需要文本、不关心复杂结构的场景。

3. 图像详细描述

1 2	`<image> Describe this image in detail.`

这已经更接近通用 VLM 任务，适合 CAD、产品图、科研图片、装饰图等。

4. 图表解析

1 2	`<image> Parse the figure.`

适合尝试恢复图表或结构信息。

5. 文档转 Markdown

1 2	`<image> <\|grounding\|>Convert the document to markdown.`

这是知识库预处理最重要的使用方式之一。

6. Grounding

Grounding 的目标不是只回答“有没有某个元素”，而是进一步定位目标位置，例如签名、表格、指定文本区域等。

从应用角度看，可以把任务划成四层：

L1 文字层：OCR
L2 结构层：Markdown / Layout / Table
L3 语义层：Image Description / Figure Understanding
L4 定位层：Grounding / Object Detection

九、本地部署：先理解两条推理路径

资料中的实践方案主要有两条：

Transformers

适合：

本地验证；
单机实验；
调试 Prompt；
研究模型行为；
快速接入 Python Pipeline。

优点是依赖关系直接、控制粒度高。

vLLM

适合：

批量 PDF；
高并发；
在线服务；
推理服务化；
企业知识库文档解析平台。

如果只是测试一张图片，Transformers 已经够用；如果要让几十个业务同时上传 PDF，vLLM 才更接近生产形态。

版本提示： 原资料中的 Python、PyTorch、CUDA、vLLM、Flash Attention 和显卡兼容性属于当时的实践环境，版本依赖很强。真正部署时应该优先以当前 DeepSeek-OCR 项目的 requirements.txt、README、PyTorch/CUDA Compatibility Matrix 和 vLLM 支持情况为准，不建议机械复制历史版本组合。

十、权重和项目获取

资料给出的主要入口包括：

GitHub:
https://github.com/deepseek-ai/DeepSeek-OCR

Hugging Face:
https://huggingface.co/deepseek-ai/DeepSeek-OCR

ModelScope:
https://www.modelscope.cn/models/deepseek-ai/DeepSeek-OCR/summary

例如通过 ModelScope 下载：

pip install modelscope
mkdir ./deepseek-ocr
modelscope download \
  --model deepseek-ai/DeepSeek-OCR \
  --local_dir ./deepseek-ocr

十一、Transformers 推理示例

原资料给出的核心调用方式如下：

from transformers import AutoModel, AutoTokenizer
import torch
import os

os.environ["CUDA_VISIBLE_DEVICES"] = "0"

model_name = "deepseek-ai/DeepSeek-OCR"

tokenizer = AutoTokenizer.from_pretrained(
    model_name,
    trust_remote_code=True,
)

model = AutoModel.from_pretrained(
    model_name,
    _attn_implementation="flash_attention_2",
    trust_remote_code=True,
    use_safetensors=True,
)

model = model.eval().cuda().to(torch.bfloat16)

prompt = "<image>\nDescribe this image in detail."
image_file = "/data/input/example.png"
output_path = "/data/output"

res = model.infer(
    tokenizer,
    prompt=prompt,
    image_file=image_file,
    output_path=output_path,
    base_size=1024,
    image_size=640,
    crop_mode=True,
    save_results=True,
    test_compress=True,
)

这里真正需要理解的是几个参数。

`trust_remote_code=True`

DeepSeek-OCR 使用自定义模型架构，因此 Transformers 需要加载项目提供的 Python 实现。

这也意味着生产环境中不能把它当成普通配置项看待。对于企业内部环境，应该：

固定模型版本；
固定 Commit / Revision；
审核 Remote Code；
固定依赖；
禁止运行时自动漂移到未知版本。

`_attn_implementation="flash_attention_2"`

用于启用 Flash Attention 2，降低 Attention 计算的时间和显存成本。

`bfloat16`

在支持 BF16 的 GPU 上可以降低推理显存并提升吞吐。

`crop_mode=True`

面对高分辨率或大尺寸文档时，通过裁剪/分块处理降低一次性显存压力。

`test_compress=True`

资料中的调用将其用于启用/测试上下文光学压缩相关流程。

十二、输出结果不应该只看一段字符串

文档模型真正有价值的地方，是输出可以继续进入工程系统。

资料中的推理结果通常会形成一组 Result Bundle，例如：

output/
├── images/
├── result_ori.mmd
├── result_with_boxes.jpg
└── result.mmd

`images/`

保存 PDF 页面切图、解析过程中生成的图像、Grounding 或检测结果等。

`result_ori.mmd`

更接近模型原始输出，适合调试、评估和错误分析。

`result_with_boxes.jpg`

把识别框、区域、类别等叠加在原图上，适合人工复核和前端展示。

`result.mmd`

经过结构处理后的最终多模态 Markdown，更适合进入知识库、搜索系统或下游 LLM。

这说明一个成熟的 OCR 系统最好保留两套结果：

1 2	`机器消费结果：Markdown / JSON / structured data 人工审计结果：boxes / rendered image / raw output`

否则一旦模型识别错误，很难追溯“究竟是图片本身的问题、版面问题还是生成阶段的问题”。

十三、vLLM：从模型 Demo 走向批量文档处理

原资料中的 vLLM 工程包含类似下面的脚本：

文件	用途
`config.py`	模型、尺寸、路径和推理参数
`deepseek_ocr.py`	核心推理逻辑
`run_dpsk_ocr_eval_batch.py`	批量评测
`run_dpsk_ocr_image.py`	单图片推理
`run_dpsk_ocr_pdf.py`	多页 PDF 推理

典型执行方式：

1 2	`cd DeepSeek-OCR-vllm python run_dpsk_ocr_image.py`

或者：

1	`python run_dpsk_ocr_pdf.py`

实际生产中，建议进一步在这个脚本层之上包装服务，而不是让业务系统直接调用脚本。

例如：

Upload API
   ↓
Object Storage
   ↓
Document Task Queue
   ↓
DeepSeek-OCR Inference Service
   ↓
Post Processor
   ↓
Markdown / JSON / Images
   ↓
Knowledge Ingestion Pipeline

这样才能解决：

大文件上传；
多页 PDF 分片；
GPU 并发；
超时；
任务重试；
幂等；
结果缓存；
失败页重跑；
人工复核。

十四、DeepSeek-OCR 在多模态 RAG 中应该放在哪里

很多 RAG 项目最大的问题，是直接把 PDF 当成“文本文件”处理。

经典流程往往是：

PDF
 ↓
Text Extractor
 ↓
Chunk
 ↓
Embedding
 ↓
Vector DB

这个流程一旦遇到扫描件、双栏、表格和图片，就很容易把知识破坏掉。

更合理的多模态文档 RAG 可以写成：

PDF / Image
     ↓
DeepSeek-OCR
     ↓
Document Structure
├── Markdown
├── Table
├── Formula
├── Figure
├── Layout
└── Grounding
     ↓
Normalization
     ↓
Semantic Chunking
     ↓
Embedding / Multimodal Embedding
     ↓
Vector DB + Metadata Store
     ↓
Retriever
     ↓
LLM / VLM

OCR 是 RAG 的“视觉入口”

如果 OCR 阶段把一张表格识别成几十段互不相关的文本，那么后面的 Embedding 再强也没有办法恢复原始行列关系。

因此，RAG 的效果上限往往早在“入库”之前就已经决定了。

可以用一句话概括：

Garbage In, Garbage Retrieved.

对于企业文档系统，OCR 的评估甚至应该放在 Embedding 和 LLM 评估之前。

十五、一个更实用的 PDF 入库 Pipeline

如果要真正把 DeepSeek-OCR 用在知识库中，我更推荐把整个流程拆成以下阶段：

Stage 1：文件预处理

PDF validation
→ page split
→ image rendering
→ DPI normalization
→ orientation correction

Stage 2：文档解析

使用 DeepSeek-OCR 获取：

raw output
structured markdown
layout boxes
images
formula/table blocks

Stage 3：后处理

不要把模型输出直接入库，至少进行：

Markdown 语法修复；
空标题过滤；
表格完整性检查；
重复页眉页脚删除；
页码标准化；
断行合并；
图片引用校验；
特殊字符清洗。

Stage 4：Chunk

不要简单每 500 Token 一刀切。

应该优先按照：

Document
 ├── H1
 │    ├── H2
 │    │    ├── Paragraph
 │    │    ├── Table
 │    │    └── Figure

进行语义分块。

Stage 5：索引

至少保存：

{
  "document_id": "doc-001",
  "page": 12,
  "section_path": ["Architecture", "DeepEncoder"],
  "content_type": "paragraph",
  "text": "...",
  "image_ref": null,
  "bbox": null
}

对于表格、图片、公式，建议保存 content_type 和原页面位置，而不是把一切都降级成普通字符串。

十六、图片不能只保留一个 Markdown 占位符

PDF 转 Markdown 之后常见一个问题：

1	`![figure](images/figure_001.png)`

对人来说没有问题，但对纯文本 RAG 来说，这张图几乎等于消失了。

所以应该继续调用视觉模型为图片生成结构化语义：

1
2
3

ALT
CAPTION
CONTENT_MD

例如：

![model architecture](images/figure_001.png)

*DeepEncoder 通过窗口注意力和 Token 压缩连接全局视觉编码阶段。*

<details><summary>图片解析</summary>

- 输入为高分辨率图像；
- 首先执行局部窗口注意力；
- 中间执行 16× Token 压缩；
- 最后使用全局注意力提取视觉知识。

</details>

这样图片才真正进入了可检索知识空间。

十七、工程落地时最容易踩的坑

1. 把“能 OCR”当成“能正确理解”

生成式 OCR 具备更强语义能力，但也意味着输出不再是纯粹的确定性字符识别。

对于合同金额、发票金额、编号、证件号等高风险字段，应该保留：

OCR result
+ bounding box
+ source image
+ confidence / validation
+ business rule verification

不能只相信一段自然语言生成结果。

2. 把所有任务都使用同一个 Prompt

“识别文字”“还原 Markdown”“描述图片”“定位签名”本来就是不同任务。

应该按任务路由：

Document OCR      → Convert to markdown
Text extraction   → Free OCR
Figure parsing    → Parse the figure
Image semantics   → Describe this image in detail
Grounding         → grounding prompt

3. 只测试一两页 PDF

生产文档经常会出现：

300 页手册；
某几页异常大图；
混合横竖屏；
扫描页与文本页混排；
少数页损坏；
某一页生成异常长输出。

所以必须做 Page-level Isolation，让单页失败不会让整份文档重新执行。

4. 没有原始结果和后处理结果分层

建议保存：

1
2
3

raw
normalized
indexed

三套数据。

否则后处理算法升级后，只能重新跑 GPU 推理。

5. 忽略版本锁定

trust_remote_code=True、Flash Attention、PyTorch、CUDA、vLLM 都是高度版本敏感组件。

推荐至少固定：

model revision
transformers version
pytorch version
cuda version
flash-attn version
vllm version
container image digest

十八、DeepSeek-OCR 和通用 VLM 应该怎么选

DeepSeek-OCR 并不是要替代所有 VLM。

更合理的架构是分层使用。

文档解析层

适合使用 DeepSeek-OCR 一类专业 OCR 2.0 模型：

PDF → Markdown
Table → structured data
Formula → LaTeX
Layout → blocks

高阶语义层

再把解析好的结构交给通用 LLM/VLM：

总结
问答
跨页推理
对比分析
Agent 任务
知识抽取

也就是说：

1 2	`DeepSeek-OCR = 文档视觉入口 + 结构化解析器 LLM/VLM = 高阶推理和业务决策层`

这是比“让一个超大 VLM 从头做到尾”更容易控制成本和质量的工程路线。

十九、如何评价一个 OCR 2.0 模型

不要只看“文字识别准确率”。

一个真正面向 RAG 的评估体系至少应该包括：

字符级

Character Error Rate；
Word Error Rate；
数字、日期、金额准确率。

结构级

Heading hierarchy accuracy；
Reading order；
Table structure；
Formula reconstruction；
Image-caption association。

语义级

图表信息是否被正确描述；
关键事实是否被保留；
是否出现 hallucination。

RAG 级

最终还应该测：

OCR
 ↓
Chunk
 ↓
Retrieval
 ↓
Answer

整条链路的 Retrieval Recall 和 Answer Accuracy。

因为 OCR 本身“看起来不错”，并不代表知识库一定检索得好。

二十、总结

DeepSeek-OCR 真正值得关注的地方，并不是它又做了一个“更强 OCR”。

它体现了三个很重要的趋势。

第一，OCR 正在从字符识别系统变成文档理解系统。

现代 OCR 不仅需要知道文字是什么，还需要恢复标题、段落、表格、公式、图片和空间关系，从而生成 Markdown、HTML、JSON 等机器可继续消费的结构。

第二，视觉 Token 不只是输入成本，也可能成为压缩媒介。

Contexts Optical Compression 把视觉编码重新解释为一种文本上下文压缩手段。DeepEncoder 则通过“局部视觉建模 → Token 压缩 → 全局建模”的方式，把这个理论变成可以运行的模型结构。

第三，在多模态 RAG 中，文档解析质量决定了知识库的上限。

真正可用的企业级 Pipeline 不应该只是：

1	`PDF → OCR → Text → Vector DB`

而应该是：

PDF
 ↓
DeepSeek-OCR
 ↓
结构化文档
 ↓
后处理与语义分块
 ↓
多类型索引
 ↓
Retriever
 ↓
LLM / Agent

从这个角度看，DeepSeek-OCR 更像是多模态知识系统中的一个 Document Compiler：输入是视觉文档，输出是 LLM、RAG 和 Agent 能真正消费的结构化知识。

而“上下文光学压缩”带来的更深层问题则是：未来模型的上下文，也许并不一定全部以文本 Token 存在。

这可能才是 DeepSeek-OCR 最值得继续观察的地方。

参考项目

DeepSeek-OCR GitHub：https://github.com/deepseek-ai/DeepSeek-OCR
DeepSeek-OCR Hugging Face：https://huggingface.co/deepseek-ai/DeepSeek-OCR
DeepSeek-OCR ModelScope：https://www.modelscope.cn/models/deepseek-ai/DeepSeek-OCR/summary

本文依据提供的 DeepSeek-OCR 实战资料进行知识抽取、去重和重新组织。涉及具体依赖版本、显卡兼容性、模型性能数字及工具链配置的内容具有明显的版本时效性，实际部署时应以当前项目官方说明和本地环境测试结果为准。

AI > 多模态 > OCR

#Markdown #DeepSeek-OCR #OCR 2.0 #VLM #DeepEncoder #Contexts Optical Compression #多模态 RAG #vLLM #Transformers #PDF

DeepSeek-OCR：从“识字”到“理解文档”，重新认识 OCR 2.0 与上下文光学压缩

https://allendericdalexander.github.io/2026/08/13/ai/ml/vlm/deepseek-ocr-from-ocr-to-document-understanding/

作者

AtLuoFu

发布于

2026年8月13日

许可协议

VMware vCenter Server Appliance 8.0 安装部署教程：从 ESXi 到 VCSA 上一篇

RFC 3 带读：Documentation Conventions——互联网最早的协作规则，为什么反而鼓励“不成熟” 下一篇