🚀 本文收录于Github：AI-From-Zero 项目 —— 一个从零开始系统学习 AI 的知识库。如果觉得有帮助，欢迎 ⭐ Star 支持！

什么是上下文压缩？如何减少Token消耗？

by @Laizhuocheng

---

一、简介

想象这样一个场景：你的客服机器人正在和用户对话，用户问了一个问题：“这款手机的电池续航怎么样？”

你的系统从知识库里检索到了10篇相关文档，每篇平均2000字。如果把这2万字全部塞给大模型，会发生什么？

答案：你要为这2万token付费，而且用户还要等好几秒才能看到回复。

更糟糕的是，这2万字里可能只有2000字是真正相关的，其他都是噪音信息——产品外观描述、拍照功能介绍、购买指南等等。大模型要在海量信息里找出关键内容，不仅浪费计算资源，还可能导致答案质量下降。

这就是上下文压缩要解决的核心问题：在保留关键信息的前提下，把输入token从几万降到几千，甚至几百。

Token消耗的现实压力：

• 成本压力：GPT-4按0.03美元/1000 token计费，一次2万token的调用就要0.6美元
• 延迟压力：大模型处理长上下文需要更长时间，用户体验差
• 上下文窗口限制：大多数模型的上下文窗口有限（4K-32K），超长文档无法处理

举个生动的对比：

• 没有压缩：给医生一份100页的病历，让他找出关键诊断信息
• 有压缩：给医生一份2页的摘要，包含所有关键检查结果和病史

你会选择哪种方式？

---

二、什么是上下文压缩？

上下文压缩（Context Compression）是指在保证回答质量的前提下，减少输入上下文的token数量的技术。

核心思想：提高每个token的信息密度，删除冗余信息，保留关键内容。

三大技术方向：

技术方向	核心思想	压缩率	信息保留率
过滤型	直接删除不相关的内容	50-70%	70-85%
压缩型	用摘要提取把长文本变短	60-80%	60-80%
截断型	保留最重要的部分	30-50%	90%+

上下文压缩与普通摘要的区别：

• 普通摘要：把长文本压缩成短文本，目的是给人阅读
• 上下文压缩：把上下文压缩成更适合大模型推理的形式，目的是提高推理效率和质量

---

三、上下文压缩如何工作

过滤型技术

过滤型技术的核心是相似度计算，把不相关的内容直接删掉。

基于Embedding的过滤

工作原理：

1. 编码查询问题和所有文档
2. 计算查询与文档的相似度
3. 过滤低于阈值的文档
4. 按相似度排序，优先选择最相关的

优势：

• 速度快：只需要计算embedding，延迟在50ms以内
• 成本低：不需要额外调用大模型
• 效果好：对于明确的查询问题，过滤效果显著

劣势：

• 精度有限：基于语义相似度，可能漏掉一些间接相关的内容
• 无法理解复杂逻辑：比如"除了A之外的所有功能"

基于LLM的内容提取

工作原理：

1. 先用Embedding过滤得到候选文档
2. 让LLM提取每个文档中与查询直接相关的内容
3. 删除无关信息，只保留关键事实和数据

优势：

• 精度高：大模型能理解复杂语义和逻辑关系
• 灵活性强：可以处理否定、排除、对比等复杂查询
• 信息保留率高：通常能保留85-90%的关键信息

劣势：

• 成本高：需要额外调用大模型
• 延迟高：每次压缩需要200-500ms
• 可能过度压缩：大模型可能删掉一些看似冗余但实际重要的信息

压缩型技术

压缩型技术的核心是摘要提取，把长文本压缩成关键句子或要点。

递归摘要

工作原理：

1. 把超长文档分块（如每块2000字）
2. 对每个块做摘要
3. 合并摘要，如果还是太长，再次分块摘要
4. 形成金字塔结构，逐层压缩

应用场景：

• 技术文档处理：10万token的技术文档 → 1万token → 1000token
• 法律合同分析：上百页的合同 → 关键条款摘要
• 学术论文总结：长篇论文 → 核心贡献和结论

优势：

• 压缩比高：能达到90%以上的压缩率
• 适合超长文档：能处理远超模型上下文窗口的文档

劣势：

• 信息损失累积：每次摘要都会有信息损失，多次递归后可能降到60%以下
• 延迟高：需要多次调用大模型
• 上下文连贯性差：分块处理可能破坏原文的逻辑结构

Map-Reduce压缩

工作原理：

1. 把长文本分块
2. 并行压缩每个块（Map阶段）
3. 合并压缩结果（Reduce阶段）
4. 对合并结果再做一次压缩（可选）

优势：

• 速度快：并行处理，延迟显著降低
• 适合大规模文本：可以分布式处理超长文档
• 可控性强：可以灵活调整分块大小和并行度

劣势：

• 需要额外基础设施：并行处理需要多线程或多进程支持
• 块间连贯性问题：相邻块可能有信息重复或断裂

截断型技术

截断型技术的核心是设定优先级规则，保留最重要的部分。

滑动窗口机制

工作原理：

1. 始终保留系统提示（如角色定义）
2. 保留最近N轮对话的详细内容
3. 早期对话压缩成摘要
4. 添加当前查询

应用场景：

• 多轮对话系统：客服机器人、心理咨询师等
• 会议记录摘要：保留最近讨论的重点

优势：

• 可预测性强：token消耗不会随着对话轮次线性增长
• 实现简单：不需要复杂的算法或模型
• 适合对话场景：保留最近的上下文，符合人类对话习惯

劣势：

• 可能丢失重要历史信息：早期的重要信息可能被摘要过度简化
• 不适用于文档问答：对话场景专用

基于重要性的截断

工作原理：

1. 对文本中的句子计算重要性得分
2. 按重要性排序
3. 累计选择句子，直到达到token上限

重要性评分规则：

• 必须保留：价格、型号、规格、参数、保修、退货等关键信息 +10分
• 高优先级：功能、特点、优势 +5分
• 可删除：非常、很、特别、超级、极其等冗余修饰词 -1分
• 句子长度：过长的句子可能包含冗余信息 -2分

---

四、上下文压缩的优缺点

优势	劣势
显著降低成本：token消耗减少50-90%，直接节省API费用	可能丢失信息：过度压缩会导致关键信息丢失
提升响应速度：减少大模型处理时间，用户体验更好	增加复杂度：需要设计和维护压缩流程
突破上下文限制：能处理超长文档	压缩延迟：压缩环节本身也需要时间和计算资源
提高答案质量：减少噪音干扰，让大模型更专注关键信息	难以平衡：压缩率、准确率、延迟三者很难兼得
灵活性高：可以根据场景选择不同的压缩策略	调试困难：压缩后的结果可能难以追溯问题根源
工程成熟：有LangChain等框架提供开箱即用的压缩工具	维护成本：需要持续监控和优化压缩效果

---

五、上下文压缩的实际应用与发展趋势

实际应用场景

1. 智能客服系统

场景：电商客服机器人处理用户咨询。

应用流程：

1. 用户问：“这款手机的退货政策是什么？”
2. 系统检索到10篇相关文档（产品说明、售后政策、FAQ等）
3. 用Embedding过滤，只保留3篇最相关的
4. 用LLM提取，把每篇文档压缩到关键句子
5. 总token从5000降到1500，压缩率70%
6. 大模型生成答案，响应时间从3秒降到1秒

效果：

• 成本降低：每次调用成本从0.15美元降到0.045美元
• 响应时间：从3秒降到1秒
• 答案质量：准确率保持90%以上

2. 法律文档问答系统

场景：法律咨询系统处理超长法律文档。

应用流程：

1. 用户问：“这份合同的违约责任条款是什么？”
2. 系统加载100页的合同文档
3. 用递归摘要：先分块摘要，再整体摘要
4. 用滑动窗口：只保留最近查询相关的部分
5. 总token从50000降到2000，压缩率96%
6. 大模型生成答案，准确率保持85%以上

效果：

• 处理能力：能处理100页以上的超长文档
• 准确率：关键条款识别准确率85%+
• 响应时间：2-3秒（递归摘要需要时间）

3. 心理咨询聊天机器人

场景：多轮对话系统。

应用流程：

1. 用户和机器人对话10轮
2. 用滑动窗口：保留最近5轮对话详情
3. 早期5轮对话压缩成摘要：“用户咨询了工作压力问题”
4. 总token稳定在1600左右，不会随对话轮次增长
5. 机器人能保持对话连贯性，理解用户需求

效果：

• 上下文稳定性：token数稳定在1600，不会溢出
• 对话质量：用户满意度评分4.5/5
• 成本控制：每次对话成本降低40%

4. 产品描述自动生成

场景：内容生成系统。

应用流程：

1. 输入原始产品信息（5000字的技术规格）
2. 用LLMLingua压缩到1500字，保留关键参数
3. 用上下文改写生成更流畅的描述
4. 总token减少70%，生成质量保持90%以上

当前局限性

过度压缩问题：

压缩率设到80%后，发现系统经常答非所问。排查发现是压缩算法把一些关键的数字和专有名词删掉了。

解决方案：

• 添加保护规则：某些实体（如数字、专有名词）不可删除
• 设置重要性阈值：低于某个分数的句子才考虑删除
• 人工审核：对关键业务场景，压缩后做人工抽检

压缩延迟问题：

如果压缩环节本身要花500ms，而省下来的token只能让LLM推理加快200ms，那反而得不偿失。

解决方案：

• 根据上下文长度和延迟预算选择压缩策略
• 短文本（<2000字）：不用压缩
• 中等长度：用Embedding过滤
• 超长文本：用递归摘要
• 延迟敏感：用快速过滤，牺牲一些准确率

上下文碎片化问题：

检索出来的5个文档片段，压缩后可能每个都只剩一两句话，拼在一起读起来很跳跃。

解决方案：

• 添加过渡语句，提高可读性
• 保留文档之间的逻辑关系
• 在压缩前先做文档聚类，把相似内容合并

发展与演进

优化策略：

成本优化的实际数据：

class CostAnalyzer:
    def calculate_savings(self, daily_queries: int, avg_tokens_before: int,
                         avg_tokens_after: int, price_per_1k: float):
        """计算节省的成本"""
        daily_cost_before = daily_queries * avg_tokens_before * price_per_1k / 1000
        daily_cost_after = daily_queries * avg_tokens_after * price_per_1k / 1000
        daily_savings = daily_cost_before - daily_cost_after
        monthly_savings = daily_savings * 30

        return {
            'daily_cost_before': daily_cost_before,
            'daily_cost_after': daily_cost_after,
            'daily_savings': daily_savings,
            'monthly_savings': monthly_savings,
            'compression_ratio': avg_tokens_after / avg_tokens_before
        }

# 示例：日均10万次调用的系统
analyzer = CostAnalyzer()
savings = analyzer.calculate_savings(
    daily_queries=100000,
    avg_tokens_before=6000,
    avg_tokens_after=1800,
    price_per_1k=0.03
)

print(f"每月节省: ${savings['monthly_savings']:,.0f}")
# 输出：每月节省: $378,000

监控和评估：

建立完整的监控体系，追踪压缩率、答案准确率、延迟等关键指标，及时发现和解决问题。

未来展望：

自适应压缩：

未来可能会出现能够根据查询复杂度自动调整压缩策略的系统。简单查询用快速过滤，复杂查询用LLM提取。

大模型原生压缩：

未来的大模型可能会内置压缩机制，在推理过程中自动识别和忽略冗余信息，不需要额外的压缩步骤。

多模态压缩：

不仅压缩文本，还要压缩图像、音频等多模态内容。比如从一张产品图片中提取关键视觉特征，而不是把整张图片的像素数据都传给模型。

实时压缩优化：

基于实时反馈动态调整压缩策略。比如发现某个查询的压缩率过高导致答案质量下降，系统自动降低该类型查询的压缩率。

---

六、总结与思考

上下文压缩的本质是在保留关键信息的前提下减少token消耗，通过过滤、压缩、截断等技术手段，在成本、延迟和准确率之间找到最佳平衡点。实际应用中没有一种技术是万能的，需要根据业务场景选择合适的组合：对话类应用用滑动窗口，文档问答系统用检索+重排序+LLM提取，内容生成用语义压缩+上下文改写，实时性要求高的场景用Embedding过滤。

总结：上下文压缩不是简单的技术选择，而是一种工程思维的体现——在保证系统稳定性的前提下，用最小的代价实现最大的价值。真正的工程智慧不在于追求技术的极致，而在于在复杂的约束条件下找到最优解，让资源投入产生最大的业务回报。

思考：技术的真正价值不在于它有多先进，而在于它能否解决实际问题。上下文压缩的技术演进，从简单的截断到智能的语义压缩，本质上反映了我们对"信息价值"理解的深化。当机器学会区分信息的主次轻重，不仅能节省计算资源，更重要的是学会了人类的注意力机制——在海量信息中快速识别关键内容。这种从"全量处理"到"选择性关注"的转变，正是智能从低级走向高级的重要标志。