上下文压缩完整解析｜RAG 知识库、长文档问答生产实战指南

数智星河

导语

      现在大模型上下文窗口越来越大，128K、1M token 的模型比比皆是，但窗口大不等于可以无限制把海量原文全部丢进提示词。把几十万字合同、手册、历史对话直接送入模型，会带来调用成本暴涨、推理延迟升高，还会出现 “Lost in the Middle（中间信息遗忘）” 现象，大量无关噪音诱发幻觉。上下文压缩（Context Compression）就是在保留关键有效信息的前提下，降低输入 token 数量，平衡成本、延迟与回答质量，是 RAG、长文档问答、多轮对话系统必不可少的工程手段。本文拆解主流四类压缩方案，对比各自优缺点，讲解工程组合流水线，梳理业务取舍与踩坑点，给生产环境选型参考。

一、什么是上下文压缩

通俗类比：拿到一本厚厚的参考书籍，不需要把整本书全部摊在桌面上阅读。只筛选摘抄和当前问题强相关的重点内容，去掉废话、重复描述，只把提炼后的材料交给模型阅读。这个筛选、提纯、精简文本的整套过程就是上下文压缩。

上下文压缩：不改变原始文档，对输入文本做筛选、裁剪、提纯，保留回答问题必须的关键信息，减少送入大模型的 token 总量。
核心解决三大现实痛点：

• 控制调用成本：大模型 API 按 token 计费，长文档原始文本会产生巨额账单；
• 降低推理延迟：输入 token 越少，TTFT 首 token 延迟越低，流式对话体验更好；
• 减少幻觉干扰：过滤无关噪音，缓解 Lost‑in‑the‑Middle 中间信息遗忘问题，提升答案准确度。
  

⚠️重要认知：压缩不等于无损，所有压缩手段都存在信息丢失风险，需要在信息保真、成本、延迟三者之间做权衡。

二、四大主流上下文压缩技术方案

1、摘要式压缩（生成式 Abstractive 压缩）

使用轻量小模型对长文本做总结提炼，输出一份精简摘要，把摘要交给主模型完成后续问答。

• 原理：对完整长文档做概括总结，提取核心结论、关键数字、重要观点；
• ✅优点：实现简单，大幅降低 token；适合会议纪要、客服对话记录；
• ❌缺点：属于有损压缩，会丢失细节、原始条款；如果后续问题刚好问到摘要没覆盖的细节，模型会答非所问；额外调用一次模型会增加延迟与少量开销。
  

适用场景：不需要精确原文引用，只需要宏观结论的业务；法律、财报、医疗严谨场景慎用。

2、检索增强式压缩（抽取式 Extractive，RAG 检索过滤）

不会改写原文，不生成新文本；根据用户提问，从海量文档库中检索召回与 Query 最相关的原文片段，只把匹配的片段送入上下文，原始文档保留在向量数据库。

• ✅优点：片段为原始原文，关键事实、数字、条款完整保留；可按需召回，不需要一次性全部加载全部文档；是 RAG 系统最核心手段；
• ❌缺点：高度依赖检索、重排序质量，如果召回不精准，会漏掉关键片段，直接导致答案错误。
  

通俗比喻：不去背诵整座图书馆，根据问题翻阅目录，只取出少数几页参考资料放到桌面。

3、上下文剪枝（Token‑level Pruning，规则 / 模型剪枝）

对已经拿到的文档片段做细粒度裁剪：删除重复语句、客套礼貌用语、空行、无效格式；也可以使用 LLMLingua 这类工具，基于困惑度评估，剔除低信息量句子与 token，保留高价值句子，不改写语义，只做删除。

• ✅优点：保留原文语句，没有生成改写带来的事实错误；速度快；
• ❌缺点：只能剔除冗余内容，无法对高度浓缩文本进一步压缩。
  

典型场景：客服聊天记录，把大量 “您好”“请问还有什么可以帮您” 这类客套语句剔除，保留真实业务对话。

4、提示压缩（Prompt Compression，前沿隐式向量压缩）

训练专用模型，把长文本压缩成人不可读的低维隐式软提示向量，直接喂给大模型，不再保留人类可读文字。代表工作 LLMLingua 系列。

• ✅优点：压缩倍率极高，可以做到几倍到二十倍压缩；
• ❌缺点：属于前沿研究技术，工程部署门槛高，开源工具生态还不成熟；商业生产项目落地较少。
  

压缩方案	信息保真	额外开销	工程复杂度	适用业务
摘要式压缩	中等	较高，需要调用小模型	低	会话总结、会议纪要、非严谨问答
检索增强 RAG 抽取	高	中等（向量检索）	中等	知识库 RAG，绝大多数企业生产业务
上下文剪枝	较高	低	低	对原文有引用需求，清理文本冗余噪音
隐式提示压缩	较高	高推理开销	高	科研实验，尚未大规模商用

三、生产环境标准组合流水线（RAG 系统常用）

真实线上 RAG、长文档问答很少单独使用某一种压缩技术，一般采用多阶段串联流水线：

• 向量检索召回：根据用户 Query，从知识库召回 Top‑N 原始文档片段；
• 重排序 Reranker：对召回结果做二次打分，过滤低相关文档；
• 上下文剪枝：删除片段中空行、重复、客套冗余语句；
• token 预算控制：整体上下文总 token 做上限管控，避免超出模型窗口；
• 将经过压缩提纯的片段，连同系统提示词，一起送入大模型生成回答。
  

举例：原始知识库十几万 token，经过整套流水线之后，最终送入模型的上下文控制在 2000‑4000token 区间，成本大幅下降，同时保留回答所需要的原始事实。

四、上下文压缩带来的风险与业务取舍

• 信息丢失风险摘要改写、剪枝都有可能删掉关键数字、否定描述、法律条款。法律合同、医疗报告等强合规业务，需要降低压缩强度，保留更多原文片段。
• 检索召回失败风险检索增强压缩依赖召回质量，如果相关片段没有被检索出来，模型完全无法获取对应信息。需要搭配重排序、调整 top‑k 数量做权衡。
• Lost‑in‑the‑Middle 现象即便送入上下文，大模型更容易记住开头与结尾的内容，放在中间的片段容易被忽略；压缩之后的文档片段，建议把高相关性的内容尽量放置在提示词靠前或者靠后位置。
• 压缩不等于可以无限塞入更多资料并不是压缩倍率越高效果越好；过度压缩会破坏语义，引发更多幻觉，压缩强度要结合业务做测试调参。
  

五、新手高频认知误区澄清

误区 1：模型上下文窗口足够大，就不需要做上下文压缩

纠正：1M 窗口只是硬件上限，大量无关噪音文本塞进上下文，会增加成本、延迟，还会诱发幻觉、中间遗忘问题。窗口大不代表可以放弃上下文管理。
误区 2：摘要压缩可以用于法律合同、医疗报告等严谨业务

纠正：摘要属于生成改写，存在篡改细节风险；严谨业务优先使用检索抽取 + 剪枝，尽量保留原始原文。
误区 3：RAG 检索召回文档越多，回答效果越好

纠正：过多低相关片段变成噪音，反而会稀释有效信息，幻觉上升，也就是 “上下文诅咒”，不是召回越多越好。
误区 4：上下文压缩可以彻底解决幻觉

纠正：压缩主要是减少噪音；幻觉来源很多，压缩只能缓解，不能彻底根除幻觉。
误区 5：提示向量压缩已经成熟，可以直接用于线上业务

纠正：还处在前沿研究阶段，工程化门槛高，普通企业项目优先用检索 + 剪枝 + 摘要这套成熟组合。

六、本期全文总结

1 上下文压缩核心目标：在保留关键信息前提下降低输入 token，降低成本、减少延迟，缓解长上下文幻觉与 Lost‑in‑the‑Middle 问题。2 四大主流方案：摘要式生成压缩、检索增强抽取压缩、上下文剪枝、隐式提示向量压缩。生产 RAG 业务优先检索增强 + 重排序 + 剪枝的组合流水线。3 不同业务要做取舍：普通业务可以用摘要；法律、医疗等高严谨度业务，尽量保留原始原文片段，降低压缩强度。4 大模型窗口大不等于可以无脑灌入海量文档；过多无关内容会形成噪音，伤害回答质量。5 压缩存在信息丢失风险，上线前要针对自己业务做效果评估，不要直接照搬网上固定压缩参数。