上下文压缩

问题：上下文膨胀会同时压垮预算和质量

当对话轮次变多、RAG 检索结果变大时，原始上下文很容易超出可用 token 预算。若直接截断，关键事实可能被丢掉；若硬塞进 prompt，推理成本和超时风险上升。上下文压缩要解决的是：在预算内保留对当前任务最有用的信息，而不是简单地删掉文本。

技能如何工作

核心流程分六步：

• 测量 token 预算：从模型上下文窗口中扣除系统提示、指令和生成输出，得到可用预算。如果原始上下文已经放得下，就不需要压缩。
• 打分信息密度：按段落、句子或 chunk 计算每 token 携带的任务相关事实量。纯风格、重复、跑题的内容得分低，可用关键词重叠或轻量分类器实现。
• 选择压缩策略：根据压缩比例和内容性质选择：

- 抽取式摘要：逐字保留重要句子，适合法律、医疗、代码等需要精确措辞的场景。
- 生成式摘要：用更少词重写，自然但可能引入偏差，需配合校验。
- 要点提取：只保留实体、事实和数据，压缩率高但丢失叙述细节。
- 选择性剪枝：删除填充句、重复解释和模板内容，风险低。

• 应用压缩：激进压缩（>80%）时可组合策略，如先剪枝再摘要；中等压缩（40–60%）通常抽取式已足够。
• 验证信息保留：检查实体、数字、结论是否仍在压缩结果中。
• 组装最终上下文：将压缩文本替换原始上下文，并提示模型该上下文已摘要，以便校准置信度。

适用边界与注意点

• 上下文在预算内时不要压缩：不必要的压缩一定会丢信息。
• 代码、表格、JSON 等结构化内容不宜用生成式摘要，优先剪枝或只抽取相关字段。
• 数字、名称、日期、代码标识符要重点保留。
• 压缩对话历史时，保留最近 2–3 轮原文，更早内容再摘要。
• 安全警告、法律声明、用药剂量等必须标记为 must-retain，不可压缩。
• 压缩后要验证关键问题的答案仍正确，若任务依赖的事实丢失，说明压缩过头了。