上下文衰减：LLM的"老年痴呆"是怎么回事？大厂们都在怎么治？

引言

你有没有过这种经历：

跟AI聊了半小时，前面说得好好的，到后面它突然"失忆"了——你十分钟前告诉它的需求，它转头就忘；你上传了一份50页的文档让它总结，它只记住了最后5页；你让它参考前面的代码风格写新代码，它写出来的东西跟前面完全是两个画风。

别急着骂AI笨，这不是它的错，这是上下文衰减（Context Decay）——LLM界的"老年痴呆"。

今天这篇文章，我们就来扒一扒这个让所有大厂都头疼的问题：它到底是怎么回事？为什么会发生？大厂们都在怎么治？我们普通开发者又能怎么应对？

全程人话，偶尔幽默，该严肃时严肃。

---

一、什么是上下文衰减？先看现象

1.1 "Lost in the Middle"——中间的信息最容易丢

2023年，斯坦福和伯克利的研究者联合发表了一篇论文，标题就叫《Lost in the Middle》（迷失在中间）。他们做了个实验：

把关键信息放在上下文的不同位置，然后问模型问题。结果发现：

信息召回率
  ▲
100%│●●                                    ●●
    │  ●●                                ●●
 80%│    ●●                            ●●
    │      ●●                        ●●
 60%│        ●●                    ●●
    │          ●●                ●●
 40%│            ●●            ●●
    │              ●●        ●●
 20%│                ●●●●●●
    │
  0%└──────────────────────────────────────► 位置
     开头                              结尾
          中间区域召回率最低

翻译成人话：模型对开头和结尾的信息记得最牢，中间的信息最容易忘。

这就像你听一场两小时的讲座，开头和结尾印象深刻，中间讲了啥？不好意思，睡着了。

1.2 标称128K，实际可能只有32K

各大厂发布模型时，都喜欢吹上下文窗口："我们支持128K！""我们支持200K！""我们支持1M！"

但实测下来，有效上下文长度往往只有标称值的1/4到1/2。

模型	标称上下文	实测有效上下文	缩水比例
GPT-4 (早期)	8K	~6K	25%
GPT-4 Turbo	128K	~60-80K	35-50%
Claude 2	100K	~70-80K	20-30%
Claude 3	200K	~100-150K	25-50%
Gemini 1.5 Pro	1M	~500-800K	20-50%

（注：数据为多方实测的大致范围，不同任务类型表现不同）

这就像餐厅菜单上写着"超大份200g"，端上来一看，连盒子带饭才150g——标称值是理想状态，实际打骨折。

1.3 真实案例：大厂也踩坑

OpenAI的尴尬：GPT-4刚发布128K版本时，很多开发者兴冲冲地把整个代码库塞进去，结果发现模型对中间文件的引用经常出错。OpenAI后来不得不承认："长上下文在需要精确召回的任务上表现会下降。"

Anthropic的诚实：Claude 2发布100K上下文时，Anthropic在文档里明确写了："在长上下文中，模型对中间信息的召回率会降低，建议将重要信息放在开头或结尾。"——人家至少诚实，不藏着掖着。

字节的实战：豆包团队在做长文档问答时发现，超过50K后，答案的准确率开始明显下降。他们的解决方案是——不是硬塞，而是先做摘要，再做检索。

---

二、上下文衰减的原理：为什么会"失忆"？

知道了现象，我们来挖根源。上下文衰减不是单一原因造成的，而是多个因素叠加的结果。

2.1 注意力机制的"注意力分散"

Transformer的核心是自注意力机制（Self-Attention）。简单说，模型在处理每个词时，会"看"上下文中的所有其他词，然后给每个词分配一个"注意力权重"。

问题来了：当上下文只有100个词时，每个词能分到的注意力还挺多；但当上下文有10万个词时，每个词分到的注意力就被稀释了——就像一个老师带10个学生能照顾过来，带1000个学生就只能顾全大局了。

短上下文（100词）：
  每个词的平均注意力权重 = 1/100 = 1%
  → 每个词都能被"看到"

长上下文（100000词）：
  每个词的平均注意力权重 = 1/100000 = 0.001%
  → 大部分词被"忽略"

更关键的是，注意力权重不是均匀分配的。模型倾向于关注：

• 与当前词语义相关的词
• 位置靠近的词
• 开头和结尾的词（位置编码的影响）

中间那些"不相关、位置远、不出彩"的词，就被自然忽略了。

2.2 位置编码的"远程衰减"

位置编码（Positional Encoding）是给每个词打上"位置标签"，让模型知道词的顺序。

主流的位置编码方案（如RoPE、ALiBi）都有一个特点：距离越远，位置信号越弱。

以RoPE（旋转位置编码，GPT-4、Llama都在用）为例：

位置编码的衰减效应：

词A（位置1）和词B（位置100）：
  相对距离 = 99
  位置信号强度 = 较强

词A（位置1）和词C（位置10000）：
  相对距离 = 9999
  位置信号强度 = 很弱
  → 模型很难感知到它们的位置关系

这就像你在人群中找熟人：站在你旁边的人你一眼就能认出，站在100米外的人你就得眯着眼看，站在1公里外的人——你根本看不见。

2.3 信息密度的"信噪比下降"

上下文越长，里面的"噪音"就越多。

一份50页的文档，可能只有5页是关键信息，其他45页都是铺垫、重复、无关内容。模型要在50页里找到那5页，就像在干草堆里找针——不是找不到，是容易找错。

更严重的是，无关信息会干扰相关信息。研究表明，上下文中的干扰信息会显著降低模型对关键信息的召回率。这就是所谓的"噪音遮蔽效应"。

信噪比公式（简化版）：

有效信息召回率 ∝ 关键信息量 / (关键信息量 + 噪音量)

上下文10页：关键5页 + 噪音5页 → 信噪比1:1 → 召回率高
上下文50页：关键5页 + 噪音45页 → 信噪比1:9 → 召回率低

2.4 KV Cache的"内存墙"

这是工程层面的原因。模型推理时，会把每个词的Key和Value缓存起来（KV Cache），避免重复计算。

上下文越长，KV Cache越大，占用的显存越多。当显存不够时，就需要：

• 换出到CPU内存（速度慢10-100倍）
• 或者截断/压缩（信息丢失）

大厂的真实数据：

• GPT-4级别的模型，128K上下文的KV Cache约占80-120GB显存
• 这就是为什么长上下文API贵——因为显存成本高
• 为了控制成本，很多服务实际上会对长上下文做"隐式截断"

2.5 小结：上下文衰减的四大元凶

┌─────────────────────────────────────────────┐
│           上下文衰减的四大元凶                │
├──────────────┬──────────────────────────────┤
│  注意力分散   │  上下文太长，注意力被稀释      │
│  位置衰减     │  距离越远，位置信号越弱        │
│  信噪比下降   │  噪音信息干扰关键信息          │
│  内存墙       │  KV Cache太大，成本高          │
└──────────────┴──────────────────────────────┘

---

三、大厂们都在怎么治？

知道了病因，我们来看看大厂们开的药方。每家的思路都不一样，有的治标，有的治本，有的干脆绕着走。

3.1 OpenAI：RAG + 函数调用，"绕着走"流派

OpenAI的策略很务实：不硬刚长上下文，而是用工具绕过它。

核心思路：

• 不把所有信息都塞进上下文
• 而是用RAG（检索增强生成）按需检索
• 用函数调用（Function Calling）让模型自己决定查什么

具体做法：

1. 把文档切成小块（chunk），存入向量数据库
2. 用户提问时，检索最相关的3-5个块
3. 只把这3-5个块塞进上下文
4. 模型根据检索到的信息回答

OpenAI的官方建议：

"对于超过模型上下文窗口的文档，我们建议使用检索增强生成（RAG），而不是试图将所有内容放入上下文。"

优点：成本低、速度快、准确率高
缺点：需要额外搭建检索系统，检索质量决定回答质量

真实案例：OpenAI的ChatGPT知识库功能，就是典型的RAG方案。你上传100个文件，它不会全塞进上下文，而是每次检索相关片段。

3.2 Anthropic：优化注意力，"硬刚"流派

Anthropic走的是另一条路：硬刚长上下文，从模型架构层面优化。

Claude的长上下文优化：

1. 改进位置编码：使用更适合长距离的位置编码方案
2. 注意力稀疏化：不是每个词都看所有词，而是只看相关的词
3. 训练数据优化：在长文本上做针对性训练，让模型学会"记住中间"
4. 提示词工程：在系统提示中引导模型关注全文

Anthropic的实测数据：

• Claude 3 Opus在200K上下文中，关键信息召回率达到约90%
• 这在业界属于第一梯队
• 但即使是90%，也意味着10%的信息会丢

Anthropic的诚实建议：

"即使有200K上下文，我们仍然建议将最重要的信息放在开头或结尾。对于需要精确召回的任务，考虑使用RAG。"

3.3 Google：百万级上下文，"堆料"流派

Google走的是第三条路：堆硬件、堆算法，把上下文做到极致。

Gemini 1.5 Pro的1M上下文：

• 支持100万token的上下文（约75万个英文单词）
• 可以一次性处理10小时的视频、11小时的音频、3万行代码
• Google在论文中声称，在1M上下文中的召回率达到约99%

怎么做到的？

1. MoE架构：混合专家模型，不是所有参数都参与计算
2. 多模态注意力优化：针对不同模态（文本、图像、音频）做专门优化
3. TPU硬件加速：Google自家的TPU，专门为大模型推理优化
4. 训练技巧：在长序列上做大量预训练

但问题来了：

• 1M上下文的推理成本极高，一次推理可能要几十美元
• 实际使用中，大部分场景不需要1M
• Google自己也建议："对于大多数任务，使用更短的上下文更经济高效"

3.4 字节跳动：工程优化，"实用主义"流派

字节的策略最接地气：不追求极限上下文，而是在工程层面把现有能力用到极致。

豆包团队的长上下文优化：

1. 分层检索：先粗筛，再精排，最后只把最相关的内容塞进上下文
2. 动态摘要：长对话自动生成摘要，用摘要代替原始对话
3. 滑动窗口：只保留最近N轮对话，更早的对话做摘要归档
4. 重要性评分：给每条信息打重要性分，重要的保留，不重要的丢弃

字节的实战经验：

"在实际产品中，90%的用户对话不超过20轮。我们不需要无限上下文，我们需要的是在有限上下文里把重要信息留住。"

3.5 Meta：开源方案，"大家一起治"流派

Meta作为开源扛把子，把长上下文优化的方法都开源了。

Llama系列的长上下文优化：

1. RoPE缩放：通过位置编码的缩放，把4K上下文扩展到128K
2. Grouped Query Attention (GQA)：减少KV Cache的大小，降低内存占用
3. Flash Attention：优化注意力计算，速度提升2-4倍
4. 社区微调：全球开发者一起在长文本上微调

Meta的哲学：我们不做最好的，我们做最开放的。大家一起优化，总比一家闭门造车强。

3.6 大厂方案对比

公司	流派	核心方案	优点	缺点
OpenAI	绕着走	RAG + 函数调用	成本低、准确率高	需要额外系统
Anthropic	硬刚	注意力优化 + 长文本训练	召回率高	成本仍高
Google	堆料	1M上下文 + TPU加速	上下文最长	成本极高
字节	实用主义	分层检索 + 动态摘要	性价比高	有信息损失
Meta	开源	RoPE缩放 + GQA	开放可定制	需要自己调

---

四、我们能怎么解决？实战方案

大厂的方案虽然好，但很多是我们用不起的（比如TPU集群）。不过别担心，普通开发者也有很多实用的方法。

4.1 方案一：RAG（检索增强生成）——最推荐

原理：不把所有信息塞进上下文，而是按需检索。

用户提问
    │
    ▼
┌─────────────┐
│  向量检索    │  从知识库中找到最相关的3-5个片段
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  上下文组装  │  系统提示 + 检索结果 + 用户问题
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  LLM生成    │  基于检索到的信息回答
└─────────────┘

关键参数：

• Chunk大小：一般200-500个token，太小没上下文，太大有噪音
• 检索数量：一般3-5个，太多会稀释注意力
• 重叠度：相邻chunk之间保留10-20%的重叠，避免信息被切断

适用场景：文档问答、知识库、客服系统
不适用：需要全局理解的任务（比如整本书的主题分析）

4.2 方案二：记忆压缩/摘要——对话场景必备

原理：长对话不保留全部，而是定期生成摘要，用摘要代替原文。

对话历史（100轮）
    │
    ▼
┌─────────────┐
│  摘要生成    │  "用户之前问了A、B、C，我们讨论了D、E"
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  上下文组装  │  摘要 + 最近5轮对话 + 当前问题
└─────────────┘

两种摘要策略：

策略	做法	优点	缺点
滚动摘要	每N轮生成一次摘要，覆盖之前的	实现简单	细节可能丢失
分层摘要	短期摘要+长期摘要，重要信息进长期	信息保留好	实现复杂

适用场景：长对话、客服系统、个人助手
不适用：需要精确引用原文的场景

4.3 方案三：滑动窗口——最简单粗暴

原理：只保留最近N轮对话，更早的直接丢弃。

上下文窗口（固定大小）
┌──────────────────────────────┐
│  [最近5轮对话]  [当前问题]    │
│  更早的对话被丢弃              │
└──────────────────────────────┘

优点：实现最简单，零额外成本
缺点：早期信息完全丢失，用户可能会说"我刚才不是说过了吗"

适用场景：简单闲聊、不需要长期记忆的场景
不适用：需要参考历史信息的复杂任务

4.4 方案四：分层记忆——高级玩法

原理：把记忆分成多层，不同层有不同的保留策略。

┌─────────────────────────────────────────┐
│  瞬时记忆（当前对话）                     │
│  保留：最近10轮                          │
│  用途：当前任务的上下文                   │
├─────────────────────────────────────────┤
│  短期记忆（本次会话）                     │
│  保留：本次会话的摘要                     │
│  用途：跨轮次的信息参考                   │
├─────────────────────────────────────────┤
│  长期记忆（用户画像）                     │
│  保留：用户偏好、历史决策、重要事实        │
│  用途：个性化、跨会话的一致性             │
└─────────────────────────────────────────┘

实现要点：

• 瞬时记忆：直接放在上下文里
• 短期记忆：每次会话结束时生成摘要，存入数据库
• 长期记忆：用结构化存储（如用户画像表），需要时检索注入

适用场景：个人助手、长期陪伴型Agent
不适用：一次性任务（用完就走的那种）

4.5 方案五：提示词工程——零成本优化

原理：通过提示词引导模型更好地利用上下文。

技巧1：重要信息放开头或结尾

❌ 错误做法：
[系统提示] [大量文档] [用户问题]
  ↑ 系统提示被淹没

✅ 正确做法：
[系统提示] [用户问题] [相关文档] [再次强调系统提示]
  ↑ 开头结尾都有强调

技巧2：明确要求模型参考全文

请仔细阅读以上所有内容，特别是中间部分的信息。
回答时，请确保引用了文档中的相关内容，不要只看开头和结尾。

技巧3：让模型先复述再回答

在回答之前，请先用一句话总结你从上下文中获取的关键信息，然后再回答问题。

这个技巧看似简单，但能显著提升模型对上下文的利用率——因为它被迫"回顾"了一遍。

4.6 方案选择指南

你的场景是什么？
    │
    ├─ 文档问答/知识库 ──► RAG（方案一）
    │
    ├─ 长对话/客服 ──► 记忆压缩（方案二）
    │
    ├─ 简单闲聊 ──► 滑动窗口（方案三）
    │
    ├─ 个人助手/长期陪伴 ──► 分层记忆（方案四）
    │
    └─ 所有场景 ──► 提示词工程（方案五，必加）

---

五、怎么应用？在Agent开发中的实战

最后，我们来看看在Agent开发中，怎么把这些方案用起来。

5.1 Agent的记忆系统设计

一个生产级的Agent，记忆系统应该是这样的：

用户输入
    │
    ▼
┌─────────────────────────────────────┐
│  记忆检索层                          │
│  - 从长期记忆中检索相关用户偏好       │
│  - 从短期记忆中检索本次会话摘要       │
│  - 从知识库中检索相关文档             │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│  上下文组装层                        │
│  [系统提示]                          │
│  [用户偏好（长期记忆）]              │
│  [本次会话摘要（短期记忆）]          │
│  [检索到的相关文档]                  │
│  [最近5轮对话]                       │
│  [当前用户输入]                      │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│  LLM推理 + 工具调用                  │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│  记忆更新层                          │
│  - 更新短期记忆（本次对话摘要）       │
│  - 重要信息写入长期记忆              │
│  - 过期信息清理                      │
└─────────────────────────────────────┘

5.2 字节的Agent记忆实践

字节跳动在做AI Agent时，总结了一套记忆管理的最佳实践：

1. 重要性评分：每条对话都打一个重要性分（1-5分），3分以上的才保留
2. 时效性衰减：记忆的权重随时间衰减，越久的记忆权重越低
3. 关联检索：不是按时间检索，而是按语义相关性检索
4. 用户可控：用户可以查看、编辑、删除Agent的记忆

用字节工程师的话说："Agent的记忆不是越多越好，而是越准越好。就像人的记忆，记住所有事情的人反而会疯掉——选择性遗忘才是智慧。"

5.3 常见坑与避坑指南

坑	表现	解决方案
上下文塞满了无关信息	回答跑偏	做信息筛选，只放相关的
重要信息放在中间	模型忽略了	重要信息放开头或结尾
只存不清理	记忆越来越乱	定期清理过期记忆
摘要太粗略	丢失关键细节	摘要保留关键事实和数字
RAG检索不准	回答文不对题	优化chunk大小和检索算法

---

结语

上下文衰减是LLM的"老年痴呆"，但它不是不治之症。

从原理上看，它是注意力分散、位置衰减、信噪比下降、内存墙四大因素叠加的结果。从方案上看，大厂们各显神通：OpenAI绕着走（RAG）、Anthropic硬刚（注意力优化）、Google堆料（1M上下文）、字节实用主义（工程优化）、Meta开源（大家一起治）。

对我们普通开发者来说，不需要追求极限上下文，而是要根据场景选择合适的方案：

• 文档问答用RAG
• 长对话用记忆压缩
• 简单场景用滑动窗口
• 高级玩法用分层记忆
• 所有场景都加上提示词优化

最后说一句：上下文不是越长越好，而是越准越好。就像人的记忆力，不是记住所有事情的人最聪明，而是知道该记住什么、该忘记什么的人最聪明。

参考来源：Stanford & Berkeley《Lost in the Middle》论文、OpenAI官方文档、Anthropic技术博客、Google Gemini技术报告、字节跳动技术分享、Meta Llama技术文档。