Appearance
10.3.4 上下文太长时，有哪些常见压缩方法？
先给结论：上下文太长时，不是把模型上下文窗口开大就万事大吉。更稳的做法通常是先减少重复、保留关键证据、压缩冗余说明，再决定到底要不要继续扩上下文。
很多人一看到答案不完整，就会自然想到：
- 那就多塞一点上下文
这个方向有时有效，但一旦过头，就很容易带来：
- 成本上升
- 延迟增加
- 长上下文排序问题更明显
- 模型对关键证据的利用反而变差
所以“上下文压缩”的目标不是为了省几个 token，而是为了让：
- 真正关键的证据更容易被模型稳定使用
为什么上下文过长会伤害效果
最常见的原因有三个：
- 重复内容太多，稀释了关键信息
- 无关或边缘相关材料占位，挤掉真正重要的证据
- 关键信息虽然在上下文里，但位置和组织方式不利于模型使用
这说明问题很多时候不是：
- 信息不够
而是：
- 信息太杂
第一类常见压缩方法：去重和去相似
这是最基础、也最常见的一类。
常见适用场景：
- 相邻块 overlap 较大
- 多路召回后结果高度重复
- 不同文档里存在大量模板化相似说明
核心作用是：
- 先把重复证据清掉
这样能让有限上下文预算留给真正新增的信息。
第二类常见压缩方法：块级筛选和保留关键句
有些块本身很长，但真正有价值的可能只有几句。
常见适用场景：
- 召回块偏大
- 规则文档中关键条件集中在少数句子
- 表格说明文档中只有部分字段和当前问题强相关
这类方法的核心是：
- 不一定保留整块
- 而是保留最关键的子内容
但这里要注意，压缩过度也可能把上下文关系切坏。
第三类常见压缩方法：文档级聚合和摘要
当候选结果来自多个相似块时，有时更合适的做法是：
- 先按文档或主题聚合
- 再提炼出最 relevant 的部分
常见适用场景：
- 多个 chunk 来自同一文档
- 多文档答案需要归纳，但不能把所有段落原样塞进去
这类方法适合：
- 先做结构整理
- 再进入最终生成
第四类常见压缩方法：按任务类型做上下文模板化
不同任务未必需要同一种上下文组织方式。
例如：
- FAQ 问答可以更直接
- 规则问答要优先保留条件和例外
- 多文档综合题要保留来源边界
这意味着压缩有时候不只是“删减”，而是：
- 重新组织
这种方式常常比单纯截短更有效。
第五类常见压缩方法：分阶段生成
对于特别长、特别复杂的问题，有时不要试图一步把所有证据都直接喂给模型。更稳的方式可能是：
- 先局部归纳
- 再整体合成
这类方式更适合：
- 长文档
- 多文档综合
- 跨文档比对
它本质上不是简单压缩，而是：
- 把一次超长生成拆成多次较短处理
什么时候应该优先做压缩，而不是继续扩上下文
如果你发现：
- 上下文已经很长
- 延迟和成本持续上升
- 生成层开始漏关键条件
- 候选中重复和噪声明显很多
这时通常更应该先做压缩，而不是继续塞更多内容。
什么时候压缩反而可能伤害效果
也要注意一个边界：不是所有情况下都该 aggressively 压缩。
如果当前问题更像：
- 关键证据本来就不完整
- 检索层仍在漏召回
- 多文档关系需要完整保留
这时压缩过头，可能会进一步损伤证据完整性。
一个最小压缩思路示意
python
compression_plan = {
"remove_duplicates_first": True,
"keep_key_constraints": True,
"group_by_document_or_topic": True,
"avoid_over_compressing_evidence": True
}这个示意想强调的是：
- 压缩的第一目标是提纯
- 不是机械删字
一句话总结
上下文太长时，常见压缩方法包括去重、筛选关键句、文档级聚合、任务化重组和分阶段生成。压缩的核心不是让上下文更短，而是让关键证据更集中、更可用。