context-compression

上下文压缩

上下文压缩是指在保留对任务最重要的信息的同时，缩短提供给语言模型的文本上下文。随着对话不断延长、检索到的文档越来越大，压缩对于避免超出令牌限制并控制推理成本至关重要，同时还要确保答案质量不受影响。

工作流

1. 衡量令牌预算：确定模型的总上下文窗口（例如，4K、32K、128K 个令牌），然后减去为系统提示词、指令和模型生成输出预留的令牌数。剩余部分就是可用的上下文预算。如果原始上下文已经符合预算，则可能无需压缩。

2. 评估信息密度：分析原始上下文中的每个段落、句子或文本块，并根据其每个令牌包含的任务相关事实数量，评定信息密度。纯属修饰、重复或偏离主题的句子得分较低。可通过启发式方法（与查询进行关键词重叠比对）或轻量级分类器完成评估。

3. 选择压缩策略：根据所需的压缩率和内容性质，选择最合适的技术：

   • 抽取式摘要 —— 原文摘录最重要的句子。
   • 抽象式摘要 —— 用更少的词语改写内容，同时保留原意。
   • 要点提取 —— 仅提取命名实体、事实和数字。
   • 选择性删减 —— 移除低密度句子、套话和重复信息。

4. 执行压缩：应用选定的策略。对于激进压缩（缩减幅度 >80%），可结合多种技术，例如先删去套话，再对剩余内容进行抽象式摘要。对于中等程度的压缩（40–60%），抽取式筛选通常就足够了，还能避免改写造成的错误。

5. 验证信息保留情况：将压缩后的输出与原文进行比较，确保没有丢失关键信息。快速验证时，可检查原文中的关键实体、数字和结论是否仍出现在压缩版本中。

6. 组装最终上下文：将压缩后的文本插入提示词，替代原始上下文。添加说明，告知模型上下文已经过摘要，以便模型据此调整置信度。

技术

• 抽取式摘要：根据相关性评分，从源文本中选出最重要的前 n 个句子。保留原文措辞，适用于精确性至关重要的场景（法律、医疗、代码）。工具：TextRank、LexRank 或基于 LLM 的提取。
• 抽象式摘要：生成一份更短的新文本，同时保留原文含义。输出更自然、简洁，但存在引入不准确内容的风险。最适合搭配可靠的 LLM 和验证步骤使用。
• 要点提取：将文本精简为结构化的事实、实体和数据点列表。空间利用效率极高（压缩率通常超过 90%），但会失去叙述的连贯性和细微差别。
• 选择性删减：移除填充句、重复说明、问候语和套话，同时保留实质内容。信息丢失风险低，并且易于通过基于规则的启发式方法实现。
• 令牌预算管理：在多个上下文来源之间动态分配令牌预算。例如，在包含 5 个检索文本块的 RAG 流程中，为相关性较高的文本块分配更多令牌，并对相关性较低的文本块进行激进压缩。

用法

提供原始上下文文本和目标令牌预算。该技能会返回符合预算的压缩文本。还可选择指定压缩策略（抽取式、抽象式、要点式或自动），以及必须保留的关键词或实体列表。

示例

示例 1：为问答任务压缩文档

输入（节选，约 800 个 token）：

Acme Corporation 于 1987 年由 Jane Doe 在德克萨斯州奥斯汀创立。它最初是一家专注于环境合规的小型咨询公司。多年来，公司业务拓展至废弃物管理技术领域，并于 1994 年获得首项自动分拣系统专利。到 2005 年，Acme 已发展到在全国 12 个办事处拥有 500 名员工。公司于 2010 年上市，IPO 发行价为每股 18 美元。2018 年，Acme 以 2.4 亿美元收购 GreenTech Solutions，将回收自动化纳入其业务组合。截至 2024 年，Acme 报告的年收入为 12 亿美元，员工人数为 3,400 人。自 2020 年起担任 CEO 的是 Michael Chen，他此前曾任 CTO。Acme 的总部于 2021 年迁至科罗拉多州丹佛市。公司的使命宣言强调可持续工业实践，并计划在 2030 年前实现碳中和运营。

压缩后输出（提取关键要点，约 150 个 token）：

• Acme Corporation：1987 年由 Jane Doe 在德克萨斯州奥斯汀创立；现总部位于科罗拉多州丹佛市（2021 年迁址）
• 业务：环境合规咨询 → 废弃物管理技术 → 回收自动化
• 重要里程碑：1994 年获得首项专利（自动分拣）；2010 年 IPO（每股 18 美元）；2018 年以 2.4 亿美元收购 GreenTech Solutions
• 当前情况：CEO Michael Chen（自 2020 年起），3,400 名员工，年收入 12 亿美元
• 目标：在 2030 年前实现碳中和运营

示例 2：压缩对话历史

输入（长时间运行的聊天，18 条消息共约 3,000 个 token）：

用户询问如何设置 Python 虚拟环境。Agent 说明了如何创建 venv、使用 pip 以及 requirements.txt。接着，用户询问 Docker 容器化。Agent 介绍了 Dockerfile、docker-compose 和卷挂载。用户遇到端口绑定错误。Agent 通过检查是否存在冲突进程来帮助排查问题。用户解决了问题。之后，用户询问如何部署到 AWS ECS。

压缩后输出（抽象式摘要，约 400 个 token）：

**对话摘要：**用户正在设置一个 Python 应用，并使用 Docker 将其部署到 AWS。关键背景：

1. Python 环境已使用 venv 和 requirements.txt 配置（已解决）。
2. Docker 设置使用 Dockerfile 和带卷挂载的 docker-compose（已解决）。
3. 通过终止冲突进程，解决了端口 8080 的绑定冲突。
4. **当前主题：**用户现在询问如何将 Docker 化的 Python 应用部署到 AWS ECS。本地 Docker 设置已可正常运行，需要有关 ECS 任务定义、服务配置和负载均衡的指导。

最佳实践

• 逐步压缩——先进行轻度精简并测量结果，只有仍超出预算时才使用更强的压缩技术。这样可以最大限度地减少不必要的信息损失。
• 保留数字和名称——定量数据、专有名词、日期和代码标识符的重要性远高于一般内容，即使进行大幅压缩，也应予以保留。
• 标记压缩后的上下文——始终告知模型上下文已经压缩，以便在细节可能丢失时适当地保留判断余地。
• 代码优先采用摘录法——抽象式摘要可能会在代码片段中引入细微错误。对于技术内容，应使用摘录选择或选择性精简。
• 保留最近几轮对话——压缩对话历史时，逐字保留最后 2–3 轮，并总结更早的对话。近期内容是判断相关性的重要信号。
• 衡量信息损失——压缩后，检查是否仍能正确回答关于内容的关键问题。如果任务依赖的事实已丢失，说明压缩过度。

边缘情况

• 上下文已在预算范围内：完全跳过压缩——不必要的压缩总会损失一些信息。仅当原始上下文超出可用 Token 数量时才进行压缩。
• 高度技术性或结构化的内容：表格、JSON 和代码块不适合使用抽象式方法压缩。请采用选择性删减，或仅提取相关行/字段，而不要进行概括。
• 上下文包含多种语言：压缩模型在不同语言上的表现可能参差不齐。请分别压缩各语言片段，或使用多语言摘要模型。
• 关键安全信息：切勿压缩掉安全警告、法律免责声明或医疗剂量信息。在应用任何压缩之前，先将这些内容标记为必须保留。
• 上下文接近预算上限：如果上下文仅超出预算 10–15%，与完整摘要相比，简单删减空白、模板化标题和重复句子更安全。