压缩上下文技术:让大语言模型突破上下文窗口限制的新方法

举报
搞点薯条 发表于 2026/09/03 08:29:09 2026/09/03
【摘要】 随着大语言模型(Large Language Model,LLM)的快速发展,GPT、Claude、Gemini 等模型已经能够处理越来越长的文本输入。从几十万个 token 到百万 token 级别的上下文窗口,模型的“记忆容量”不断提升。然而,上下文窗口(Context Window)并不是无限的。无论模型支持多长输入,都面临几个现实问题:计算成本高Transformer 架构中的注意力...

随着大语言模型(Large Language Model,LLM)的快速发展,GPT、Claude、Gemini 等模型已经能够处理越来越长的文本输入。从几十万个 token 到百万 token 级别的上下文窗口,模型的“记忆容量”不断提升。

然而,上下文窗口(Context Window)并不是无限的。无论模型支持多长输入,都面临几个现实问题:

  1. 计算成本高

    Transformer 架构中的注意力机制(Attention)需要计算输入 token 之间的关系。当上下文长度增加时,计算量和显存消耗显著增长。

  2. 有效信息密度下降

    用户输入的历史对话、文档、代码等内容中,并非所有信息都同等重要。大量重复内容、背景信息和过时信息会占据上下文空间,降低模型关注关键内容的能力。

  3. 长期任务难以维持

    在 AI Agent、代码助手、知识管理等场景中,模型需要持续运行数小时甚至数天。如果不断累积完整历史记录,很快就会超过上下文限制。

因此,一个核心问题出现:

如何让模型在有限上下文空间中保留最有价值的信息?

这就是上下文压缩(Context Compression)技术要解决的问题。


一、什么是上下文压缩?

上下文压缩指的是:

通过算法或模型处理,将长上下文中的关键信息提取出来,并以更短、更高密度的形式表示,从而减少输入 token 数量,同时尽可能保持模型任务能力。

简单来说:

原始上下文:

用户历史聊天:
100,000 tokens

经过压缩:

重要信息摘要:
5,000 tokens

模型最终读取压缩后的内容,而不是完整历史。

目标不是简单删除文字,而是:

用更少的信息表示更多有价值的知识。


二、上下文压缩与传统文本摘要的区别

很多人会认为上下文压缩就是“自动总结”。

实际上,两者存在明显区别。

1. 文本摘要(Summarization)

目标:

生成一篇人类可读的摘要。

例如:

原文:

2024 年 1 月,公司开始开发新的推荐系统,使用 Transformer 模型优化用户兴趣预测。经过三个月测试,点击率提升 18%。

摘要:

公司使用 Transformer 优化推荐系统,使点击率提升 18%。

重点是:

  • 语言自然

  • 面向人类阅读

  • 保留主要事实


2. 上下文压缩(Context Compression)

目标:

为模型推理保留最有用的信息。

压缩结果可能类似:

项目:推荐系统
技术:Transformer
结果:CTR +18%
状态:已完成测试

它更关注:

  • 模型是否需要这个信息

  • 信息是否影响未来推理

  • token 使用效率

因此,上下文压缩更接近一种面向模型的信息编码技术。


三、上下文压缩的主要技术路线

目前上下文压缩技术主要包括以下几类。


1. 基于摘要的压缩(Summarization-based Compression)

这是最直观的方法。

流程:

长上下文
    ↓
LLM 总结
    ↓
短摘要
    ↓
继续推理

例如,一个 AI Agent 工作了 10 轮:

原始:

用户需求
历史讨论
代码修改记录
错误日志
测试结果

压缩:

用户目标:
开发支付接口

当前状态:
API 已完成
数据库迁移完成
剩余:
修复异常处理

优点

  • 实现简单

  • 通用性强

  • 人类容易理解

缺点

  • 可能丢失细节

  • 多次压缩可能产生信息漂移

例如:

第一次:

用户喜欢 Python。

第二次:

用户喜欢编程。

第三次:

用户对技术感兴趣。

信息逐渐丢失。

这种现象称为:

Semantic Drift(语义漂移)


2. Token 丢弃与选择(Token Pruning)

另一种方法不是总结,而是直接删除低价值 token。

核心思想:

并不是所有 token 都值得进入注意力计算。

例如:

原始:

用户:
你好,我想咨询一下。
今天北京天气很好。
我正在开发一个支付系统,需要设计数据库。

模型可能判断:

你好 → 低重要性

天气 → 当前任务无关

支付系统设计 → 高重要性

于是:

保留:

开发支付系统,需要设计数据库

删除:

聊天寒暄
无关背景

常见方法

Attention-based pruning

利用模型 attention 权重:

如果某些 token 很少被关注:

attention score < threshold

则删除。


Importance scoring

为每个 token 或句子计算重要性:

例如:

Importance =
任务相关度
+
信息唯一性
+
未来引用概率

然后排序保留。


3. 结构化上下文压缩(Structured Compression)

相比生成自然语言摘要,结构化压缩更适合 Agent 系统。

例如:

原始对话:

用户:
我希望开发一个电商网站。

助手:
推荐 React + Node.js。

用户:
数据库使用 PostgreSQL。

助手:
好的。

转换:

{
 "project": "电商网站",
 "frontend": "React",
 "backend": "Node.js",
 "database": "PostgreSQL"
}

优势:

  • token 少

  • 信息明确

  • 易检索

  • 易更新

因此很多 AI Agent 会维护:

  • 用户画像

  • 任务状态

  • 环境变量

  • 长期记忆

而不是保存全部聊天。


4. 向量化压缩(Embedding-based Compression)

另一种思路:

不直接保存文本,而保存向量表示。

流程:

文本
 ↓
Embedding模型
 ↓
向量空间
 ↓
相似检索

例如:

用户过去说:

我喜欢使用 Python 做机器学习项目。

转换:

[0.23, -0.51, 0.77 ...]

未来用户询问:

推荐机器学习工具

系统检索相关向量:

找到:

Python + ML 偏好

然后重新注入上下文。

这种方式实际上把:

“全部记忆”

变成:

“按需加载”。


5. KV Cache 压缩

这是大模型推理优化中的重要方向。

Transformer 推理时,会缓存历史 token 的 Key 和 Value:

Token1 → K1,V1
Token2 → K2,V2
Token3 → K3,V3

生成新 token 时直接复用。

但是:

上下文越长:

KV Cache 越大。

因此出现:

KV Cache Compression

方法包括:

量化(Quantization)

例如:

FP16:

16 bit

降低到:

8 bit

甚至:

4 bit

减少显存。


Token 合并(Token Merging)

类似图片压缩:

相似 token 合并:

token1
token2
token3

↓

compressed token

KV Cache Eviction

删除不重要历史:

类似操作系统缓存:

最近不用的数据 → 淘汰

四、上下文压缩在 AI Agent 中的重要作用

随着 AI Agent 兴起,上下文压缩变得越来越重要。

一个 Agent 通常需要:

  • 规划任务

  • 调用工具

  • 读取文件

  • 执行代码

  • 保存经验

如果每一步都保存:

完整历史
+
工具输出
+
日志
+
代码

上下文会快速膨胀。

因此 Agent 通常采用:

短期记忆
+
长期记忆
+
任务状态
+
压缩历史

架构:

              用户
               |
               ↓
          Agent系统
               |
    --------------------
    |                  |
短期上下文          长期记忆
(Current Context)    (Memory)
    |                  |
最近任务             向量数据库
    |
上下文压缩

五、上下文压缩面临的挑战

1. 信息损失问题

最大的挑战:

如何确定什么信息可以删除?

例如:

代码任务中:

删除:

变量命名规则

可能没有影响。

但删除:

数据库字段约束

可能导致严重错误。


2. 压缩成本问题

压缩本身需要模型调用。

如果:

压缩一次:

消耗 5000 token

节省:

3000 token

反而不划算。

因此需要动态策略。


3. 压缩后的可解释性

某些压缩方法直接操作:

  • hidden states

  • KV cache

  • latent representation

虽然效率高,但人类无法理解。

这带来:

  • 调试困难

  • 安全风险

  • 错误定位困难


六、未来发展方向

未来上下文压缩可能朝几个方向发展:

1. 自适应压缩

模型自动决定:

  • 哪些内容保留

  • 压缩多少

  • 什么时候恢复原文

类似人类记忆:

重要事情长期记忆,琐事快速遗忘。


2. 神经压缩表示

未来可能不再保存:

文本 → 摘要

而是:

文本 → 神经记忆表示

模型直接读取压缩后的 latent memory。


3. 无限上下文模型

最终目标:

让模型拥有近似无限上下文能力。

可能结合:

  • 上下文压缩

  • 外部记忆

  • 检索增强生成(RAG)

  • 长上下文 Transformer

形成新的认知架构。


结语

上下文压缩技术是大语言模型走向长期运行和智能 Agent 的关键基础设施。

它解决的不只是“输入太长”的问题,更深层的是:

如何让 AI 像人类一样管理信息,只记住重要内容,并在需要时调用过去经验。

未来的大模型竞争,不仅取决于参数规模和训练数据,也取决于模型如何管理自己的“记忆”。

上下文压缩,正是连接短期推理能力与长期智能的重要技术方向。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。