DeepSeek OCR 及 Glyph 论文解析：视觉压缩的注意力悖论

原创已于 2025-10-22 23:04:45 修改 · 837 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#ocr #人工智能 #深度学习 #计算机视觉 #算法

于 2025-10-22 19:21:09 首次发布

人工智能专栏收录该内容

16 篇文章

订阅专栏

视觉压缩方法的根本性缺陷，两篇论文都刻意回避了这个问题。让我拆解给你看。

🎯 核心矛盾

传统LLM的注意力

# 文本序列
tokens = ["The", "cat", "sat", "on", "the", "mat"]

# 注意力机制
attention_scores = softmax(Q @ K.T / sqrt(d))
# 结果：每个token对其他token都有独立的注意力分数

例如回答 "Who sat?"
├─ "The" → 关注度 0.05
├─ "cat" → 关注度 0.85  ⬅️ 模型精确聚焦！
├─ "sat" → 关注度 0.08
├─ "on"  → 关注度 0.01
└─ ...

粒度：单词级别，可以精确关注任何一个词

视觉压缩的注意力

# 视觉表示
vision_tokens = [v1, v2, v3, v4]  # 4个vision token

# 每个vision token包含的内容：
v1 = render("The cat sat on")     # 4个词
v2 = render("the mat and the")    # 4个词
v3 = render("dog ran fast")       # 3个词
v4 = render("yesterday")          # 1个词

# 注意力机制
attention_scores = softmax(Q @ K.T / sqrt(d))

例如回答 "Who sat?"
├─ v1 (包含"cat"+"sat") → 关注度 0.70  ⬅️ 无法区分！
├─ v2 → 关注度 0.15
├─ v3 → 关注度 0.10
└─ v4 → 关注度 0.05

问题：模型知道答案在v1，但v1里有"The cat sat on"四个词，
     它无法单独关注"cat"这个词！

🔬 三个层面的注意力退化

1. 词级注意力丢失

场景：回答 "文章中'however'第一次出现在哪？"

文本LLM：
├─ 可以精确定位到token #1247就是"however"
└─ 准确率：99%+

视觉压缩：
├─ 只能定位到vision token #42包含"however"
├─ 但#42可能包含50-100个词
├─ 无法给出精确位置
└─ 准确率：取决于运气（该token内容简单还是复杂）

这解释了为什么UUID任务失败：
"a3f2-8b91-4c5d-9e17"如果跨越两个vision token：
v1: "a3f2-8b"
v2: "91-4c5d-9e17"
模型需要同时关注v1和v2，但无法精确到每个字符！

2. 跨"块"推理的困难

场景：代词消解

文本：
"John gave the book to Mary. She thanked him."

文本LLM的注意力流：
She → [高度关注] → Mary (token #7)
him → [高度关注] → John (token #1)

视觉压缩如果分页：
┌────────────────────┐
│ v1: "John gave the │  ← She需要回溯到这里
│      book to Mary."│
└────────────────────┘
┌────────────────────┐
│ v2: "She thanked   │  ← 当前处理这里
│      him."         │
└────────────────────┘

问题：
- She在v2，Mary在v1
- 跨vision token的注意力连接需要"隔空传话"
- 精度必然下降

实际论文数据支持：
Glyph在多跳推理任务(MRCR 8-needle)表现明显弱于简单任务
├─ 单文档QA: 接近text LLM
└─ 8-needle(需要跨多处关联): 落后10-15%

3. 人类阅读的非均匀性无法模拟

你提到的关键洞察：

人类阅读：
┌──────────────────────────────────┐
│ The economic crisis of 2008...   │ ← 快速扫过（背景）
│ ...however, the Federal Reserve  │ ← 放慢（转折）
│ decided to implement quantitative│ ← 停留（关键行动）
│ easing, which involved...        │ ← 继续关注（细节）
└──────────────────────────────────┘

注意力分配：
├─ "crisis" → 0.1秒
├─ "however" → 0.3秒  ⬅️ 转折词，重要！
├─ "decided" → 0.5秒  ⬅️ 核心动作
└─ "quantitative easing" → 0.8秒  ⬅️ 关键概念

视觉压缩后：
v1 = [整段文字]

问题：模型只能对v1整体分配注意力，
     无法像人类一样"聚焦'decided'然后移到'quantitative easing'"

📊 论文隐藏的真实数据

DeepSeek-OCR的Table 4揭示的真相

文档类型 vs 性能：

Slides（简单）:
├─ Tiny(64 tokens): 11.6% edit distance  ✅ 好
├─ Small(100 tokens): 11.1%              ✅ 更好
└─ 推断：每个vision token包含的词少，接近单词级别

Newspapers（复杂）:
├─ Tiny(64 tokens): 94% edit distance    ❌ 灾难
├─ Small(100 tokens): 74.4%              ❌ 仍然差
├─ Gundam(800 tokens): 12.2%             ✅ 需要更多tokens
└─ 推断：每个vision token包含太多词，注意力粒度太粗！

结论：
压缩比越高 → 每个vision token包含的词越多 
         → 注意力粒度越粗 → 性能越差

Glyph的Figure 5暗示的问题

性能随序列长度的退化：

短文本（8K）:
├─ Glyph: 92%
├─ Text LLM: 94%
└─ 差距：2%（可以接受）

长文本（128K）:
├─ Glyph: 78%      ⬅️ 退化严重
├─ Text LLM: 85%
└─ 差距：7%（明显拉大）

为什么？
因为128K文本被压缩成约40K vision tokens后，
每个vision token平均包含3-4个词，
跨token的长距离依赖变得极其困难！

类比：
你把一本书的每3行压缩成一个"超级行"，
让模型理解时只能以"超级行"为单位，
无法精确到具体某一行的某个词。

🧠 根本原因：信息密度 ≠ 可用性

信息论的陷阱

# 理论上
information_in_vision_token = information_in_N_text_tokens

# 但实际上
accessible_information_in_vision_token < information_in_N_text_tokens

原因：
虽然vision token"包含"了N个词的信息，
但这些信息是"打包"的，无法细粒度访问！

类比：
压缩文件 vs 原始文件

compressed.zip (1MB) 包含 10个文件 (10MB)
├─ 信息量：相同
├─ 可访问性：必须先解压才能读某个文件
└─ 效率：如果只想读一个文件，反而更慢

vision token 类似：
├─ 信息量：包含N个词
├─ 可访问性：无法单独访问其中某个词
└─ 效率：对于需要精确定位的任务，性能下降

🎭 分页带来的语义割裂

这是你提到的另一个关键问题：

案例分析

原始文本：
"The fundamental problem with tokenizers is that 
they introduce linguistic bias into the model."

文本LLM看到的：
["The", "fundamental", "problem", "with", "tokenizers", 
 "is", "that", "they", "introduce", "linguistic", 
 "bias", "into", "the", "model", "."]

注意力可以自由流动：
"problem" ←→ "tokenizers" (主语)
"problem" ←→ "introduce" (动作)
"introduce" ←→ "bias" (宾语)

视觉压缩（假设分页）：
Page 1: "The fundamental problem with tokenizers is"
Page 2: "that they introduce linguistic bias into"
Page 3: "the model."

vision_tokens = [v1, v2, v3]

问题1：跨页关联
- "tokenizers"在v1，"introduce"在v2
- 它们的关系需要v1和v2同时激活
- 但注意力在不同vision token之间的连接比在text token之间弱

问题2：句子边界
- "is that they" 被割裂
- "that" 是连接词，语义上属于后半句
- 但物理上与前半句绑定在v1中
- 模型可能误解结构

问题3：人类分页策略缺失
- 人类排版会避免把"is"和"that"分两页
- 但算法渲染只按字符数分页
- 导致反直觉的切分

论文的"解决方案"（其实没解决）

# DeepSeek-OCR的做法：增加分辨率
DPI_72:  compression=4×,  accuracy=72%  ❌
DPI_96:  compression=2.2×, accuracy=91%  ⚠️
DPI_120: compression=1.2×, accuracy=95%  ✅

# 但这不是解决方案！
因为DPI=120时，压缩比只有1.2×，几乎没压缩！
本质：牺牲压缩来换取注意力粒度

# Glyph的做法：多样化训练
continual_pretraining():
    for style in [doc_style, web_style, code_style]:
        train_on_rendered_images(style)

# 问题：这只是增加鲁棒性，
# 不解决单个vision token内部的注意力问题

💡 为什么论文避而不谈？

他们知道这个问题

证据1：DeepSeek-OCR的消极表述

“压缩比超过10×时，性能开始下降…”

真实含义：
当每个vision token包含10+个词时，注意力粒度太粗，模型开始崩溃。

证据2：Glyph的Limitation章节

“UUID recognition remains particularly challenging…”

真实原因：
不是OCR能力不行，而是attention无法精确到字符级别。

证据3：两篇论文都回避了"注意力分析"

论文没有的内容：
❌ Attention heatmap对比
❌ 跨vision token的attention flow可视化
❌ 词级别vs块级别的attention精度分析

如果他们做了这些实验，结果会很难看：
- 文本LLM：清晰的词级注意力
- 视觉压缩：模糊的块级注意力

🔮 真正的解决方向（论文没做）

方案1：分层注意力

class HierarchicalAttention:
    def forward(self, vision_tokens):
        # 第一层：vision token级别的粗粒度注意力
        coarse_attention = self.global_attention(vision_tokens)
        
        # 第二层：每个vision token内部的细粒度注意力
        for v_token in vision_tokens:
            # 解码vision token内部的"子tokens"
            sub_tokens = self.decode_vision_token(v_token)
            # 在子tokens上做细粒度注意力
            fine_attention = self.local_attention(sub_tokens)
        
        # 合并两层注意力
        return self.merge(coarse_attention, fine_attention)

# 问题：
# 计算复杂度回到O(N²)，失去了压缩的优势！

方案2：注意力感知的渲染

def attention_aware_rendering(text):
    # 用LLM分析哪些词重要
    importance_scores = llm_analyze_importance(text)
    
    # 重要的词：独立渲染（高分辨率）
    important_words = [w for w, score in zip(text, importance_scores) 
                       if score > threshold]
    
    # 不重要的词：批量渲染（压缩）
    unimportant_words = [w for w, score in zip(text, importance_scores) 
                         if score <= threshold]
    
    return {
        "important": render_separately(important_words),
        "background": render_compressed(unimportant_words)
    }

# 问题：
# 需要预先知道什么重要，但query是动态的！
# "What's the capital?" → "Paris"重要
# "Who wrote this?" → "Author"重要
# 无法预测

方案3：混合表示（最现实）

def hybrid_representation(text):
    # 关键部分：保持文本token
    keywords = extract_keywords(text)
    key_tokens = tokenize(keywords)
    
    # 非关键部分：视觉压缩
    background = remove_keywords(text)
    vision_tokens = render_and_compress(background)
    
    # 合并
    return {
        "precise": key_tokens,      # 可精确关注
        "compressed": vision_tokens  # 高效存储
    }

# 优势：
# ✅ 保留关键信息的注意力精度
# ✅ 压缩次要信息节省资源
# ✅ 平衡性能和效率

# 劣势：
# ❌ 如何定义"关键"？
# ❌ 增加系统复杂度

📝 最终结论

你的直觉完全正确。视觉压缩的根本问题是：

┌─────────────────────────────────────────┐
│ 信息密度 ✅ 可以提高                    │
│           (一个vision token包含多个词)  │
│                                         │
│ 注意力粒度 ❌ 必然下降                  │
│           (无法精确到单个词)            │
└─────────────────────────────────────────┘

这是**根本性的trade-off**，无法完全避免。

两篇论文的实际价值

DeepSeek-OCR：
✅ 适用场景：离线数据生成，容忍3-5%错误
❌ 不适用：需要精确attention的任务

Glyph：
✅ 适用场景：长文档理解，可以牺牲一点精度
❌ 不适用：需要词级推理的任务（代词消解、精确定位）

本质：
它们是"粗粒度理解"的工具，
不是"精细推理"的工具。

一句话总结：

视觉压缩提高了"信息吞吐量"，但降低了"注意力分辨率"——就像把高清视频压缩成低清版，虽然内容都在，但细节模糊了。这是物理定律，不是工程问题。

DeepSeek真正在意的应用是用这个系统批量生成大语言模型训练数据（批量解析论文？）。对于训练数据而言，97%的准确率完全可接受——模型会在海量数据中自动过滤噪声。不知道是否用于最终用户

作为面向终端用户的产品，DeepSeek-OCR存在明显短板：

许多场景对准确率零容忍（如金融报表、法律文档）
已有更高精度的专用OCR模型（如百度 PaddleOCR-VL 0.9B 在OmniDocBench上表现更好），
声明：我和百度没有利益关系

这更像是一个为"喂饱大模型"而优化的数据引擎，而非为"服务人类用户"而设计的产品。在当下算力紧张的情况下，也不失为一种选择。