在 RAG 流水线中，检索环节召回的原始文本片段往往包含大量对回答无用的信息——重复的背景描述、与当前问题无关的段落、格式标记等。这些冗余内容不仅浪费 LLM 宝贵的上下文窗口，还可能稀释真正有用的信息，导致回答走偏或遗漏重点。上下文压缩正是在检索之后、生成之前，对输入信息进行精炼的一道关键工序。
1. 为什么需要压缩
直接喂给模型的文本越“干净”，生成质量越稳定。冗余信息会带来几个实际问题：
- 挤占上下文窗口：LLM 一次能处理的 token 数量有限，废话多了，关键信息就少了，尤其是需要多片段融合回答时。
- 干扰模型注意力：模型在长文本中抓重点的能力有限，若检索片段夹杂大量无关句子，模型可能抓住次要内容生成偏题答案。
- 增加延迟与成本：无用 token 同样消耗算力和 API 费用，压缩后体积更小、处理更快。
因此，在检索结果进入提示词之前进行压缩，相当于先做一轮“提纯”，让模型只看到高度相关的核心信息。
2. 压缩的两类常用方法
实践中，上下文压缩主要走两条路线：基于规则/模型的轻量级方法，以及基于 LLM 自身的摘要能力。两者可以组合使用，根据场景灵活选择。
（1）冗余信息剔除
这类方法侧重删除不增加信息量的内容，保留原文结构，适用于结构规整、噪音明显的检索结果。
- 去重：当多个检索片段包含相同或高度相似的句子（例如同一段政策被不同 chunk 重复覆盖），只保留最长或最完整的一个版本，删除其他副本。
- 移除格式噪音：剥离 HTML 标签、Markdown 标记、页眉页脚、文档编号等对回答无意义的纯格式符号。
- 过滤低相关度内容：有些检索结果整体相关度尚可，但内部混有完全不相关的句子。可以使用滑动窗口结合句子级相似度计算，将与问题向量距离过远的句子直接删除。
- 丢弃伪影片段：去除仅有标题、目录条目、表格空壳的无意义 chunk，这些片段在 chunking 时容易产生但毫无帮助。
例子：检索到一段“3.1 概述……3.2 请假流程……3.3 年假计算（此处略，详见附表）……”如果用户只问年假天数，“3.1”和“3.2”完全可以剔除，只保留含“年假计算”的句子。
（2）关键信息提取
当检索片段较长或语体松散（如会议记录、邮件）时，直接删除部分句子可能仍不够精炼。这时需要进一步提取核心要点，重组成紧凑的上下文。
- 小模型摘要：使用专门的、轻量的摘要模型（如 BART、T5 等）对每个片段生成一句或两句话的概括，只保留摘要送入 LLM。这类模型小、推理快，适合作为前置过滤器。
- LLM 自摘要：在提示词中要求 LLM 先压缩，再回答。例如：“请先提取以下材料的要点，然后基于要点回答问题。”这是最灵活的方式，但会增加一次 LLM 调用，需权衡成本。
- 关键句打分抽取：基于问题与片段内每个句子的相似度打分，直接提取 top‑k 个最相关句子拼接，抛弃其余部分。这种方法可解释性强，处理速度快。
例子：原始检索结果是一长段产品功能介绍：“本产品采用全新一代处理器，主频高达 3.2GHz，支持多任务并行。外观方面提供三种颜色可选，电池容量为 5000mAh，支持快充……”若用户只问“支持快充吗？”，关键信息抽取可只保留“电池容量为 5000mAh，支持快充”这一句，其余全部忽略。
3. 实际落地建议
- 先剔除、后提取：通常先做规则化的去重、去格式、低相关度片段过滤，再对有需要的长片段进行语义级压缩，形成漏斗式处理。
- 保留出处元数据：压缩过程中必须保留片段来源标识，确保最终回答依然可以溯源。
- 别过度压缩：过度精炼可能丢掉必要的上下文或限定条件，导致模型回答片面。建议对压缩后内容进行简单校验，比如检查 token 长度占原始比例是否过低。
- 成本考量：轻量规则和评分过滤几乎零成本，应优先应用；调用摘要模型或 LLM 会引入额外开销，适合对答案质量要求极高的场景。
上下文压缩用最小的代价换取了更干净的输入，是提升 RAG 系统整体效果的高性价比手段。它让后续的生成模型能把算力真正用在理解与推理上，而不是浪费在“读懂垃圾信息”上。