授权与合规声明
本文为技术实操分享,所有示例均在自建隔离环境中验证或为可复现的演示代码;文中版本、命令与数据均标注来源,无法核验的已标「待验证」,不含任何攻击步骤、利用载荷与绕过手法。转载请注明出处。
一、上下文不是越长越好
做 RAG、做多轮对话、做 Agent,上下文都会越长。直觉是「多塞点信息模型更懂」,但现实是:token 成本线性上涨,长上下文下模型反而更容易被无关信息带偏,关键指令被「稀释」。
1.1 三个真实代价
- 钱:每次请求都重发长上下文,输入 token 直接乘上调用频次。
- 慢:上下文越长,首字延迟与吞吐都受影响。
- 糊:无关内容越多,模型对核心指令的遵从度越差。
1.2 压缩不是删信息,是删噪声
上下文压缩的目标,是在尽量不损失决策所需信息的前提下,减少送入模型的 token 量。它是「信息保真度」与「token 预算」之间的工程权衡,不是无脑截断。
二、三级压缩策略
2.1 第一级:检索层瘦身(不进模型就砍掉)
最省的是「根本别送进去」。RAG 检索召回的冗余段落、对话里早就过期的寒暄,在检索/拼接阶段就该过滤。判据:只保留与当前问题相关性高于阈值的片段。
2.2 第二级:关键句抽取(进模型前再压)
对不得不送的长文档,先用一个小模型做「关键句/关键片段抽取」,只把抽取结果作为上下文。这比整段塞进去便宜得多,且抽取模型可以用更小、更便宜的档位。
2.3 第三级:摘要式压缩(历史太长就归纳)
多轮对话或长程 Agent 轨迹,把早期历史换成「摘要 + 最近若干轮原文」。越久远越该被归纳,越近期越该保留原貌。
三、一个抽取压缩的示意实现
下面用「关键句抽取」演示压缩流程,核心是「先用小模型挑句子,再拼给大模型」。
⚠️ 代码待验证
defcompress_context(documents,query,extract_call,top_k=5):"""对检索到的文档做关键句抽取,返回压缩后的上下文。"""scored=[]fordocindocuments:forsentindoc.split("。"):sent=sent.strip()ifnotsent:continue# 用小模型给「句子与问题相关性」打分score=float(extract_call(f"只输出 0-1 的相关性分数:问题={query}句子={sent}"))scored.append((score,sent))scored.sort(reverse=True)kept=[sfor_,sinscored[:top_k]]return"。".join(kept)+"。"3.1 抽什么、留什么
抽取阶段要保留「带数字、带结论、带实体」的句子,砍掉过渡句和重复句。阈值和top_k是必须可调的超参,不是写死的。
3.2 小模型做抽取的理由
抽取是重复性高、对「理解深度」要求低的工作,用便宜的小模型即可,省下的钱直接抵消压缩本身的调用开销,整体仍净赚。
四、压缩质量的判据
4.1 别只看成本
压缩效果的判据不能只是「少了多少 token」,更要看下游任务指标有没有掉。建议用固定的评测集,对比「原始上下文」与「压缩后上下文」在相同任务上的得分差。
4.2 保真度红线
设一条「保真度红线」:压缩后的任务得分跌幅不能超过某个阈值,否则自动回退到未压缩版本。这是线上兜底的关键。
五、生产落地的三个注意点
5.1 缓存压缩结果
同一份文档被多个请求复用,压缩结果要缓存,避免每次都重新抽取。缓存键可以是文档指纹。
5.2 压缩本身也要可观测
记录每次压缩「压缩比」「抽取耗时」「是否触发回退」。压缩链路一旦出问题,表现为「成本降了但效果崩了」,没有指标你发现不了。
5.3 分级压缩
按请求重要度分级:重要的请求少压、保真优先;海量的低优请求多压、成本优先。一刀切反而两头不讨好。
配套资料:这一章讲的缓存与分级压缩配置,仓库里有一份可直接抄的参数模板,扫码即可获取:
六、常见坑
6.1 过度压缩
为了省钱把top_k调得极小,结果关键句被砍光,模型开始「编」。压缩比和保真度要一起看。
6.2 压缩链路引入新延迟
抽取模型串行调用会加延迟。要么批量、要么异步、要么缓存,别让压缩比原始还慢。
6.3 忽视回退
没有保真度红线和回退,压缩一旦失手就是静默崩坏。回退不是可选项。
七、什么时候上压缩
7.1 判据清单
- 单次请求输入 token 长期偏高;
- 同一份长文档被反复送入;
- 多轮/长程任务历史越积越长。
7.2 上线检查单
- 是否有固定评测集对比压缩前后得分?
- 是否设了保真度红线与自动回退?
- 压缩结果是否缓存?
- 压缩链路延迟是否可接受?
配套资料:文末资料包里有一份「上下文压缩参数对照表」,把上面五级策略的每一项都拆成了可调参数,扫码即可获取:
附表 A:本文引用事实与出处对照表
| 事实/结论 | 出处 | 本文位置 |
|---|---|---|
| 上下文越长,输入 token 成本与延迟同步上升 | 通用工程经验(待验证具体基准数据) | 第一章 |
| 长上下文下无关信息会稀释核心指令遵从度 | 通用工程经验归纳 | 第一章 |
| 压缩效果需用固定评测集对比下游任务得分 | 本文提出的判据方法 | 第四章 |
| 抽取类任务可用更小更便宜的模型档位 | 通用工程实践 | 第二章、第三章 |
附表 B:术语速查表
| 术语 | 含义 |
|---|---|
| 上下文压缩 | 减少送入模型的 token 而不显著损失信息 |
| 保真度红线 | 压缩后任务得分允许的最大跌幅阈值 |
| 关键句抽取 | 用小模型挑出文档中相关句子再送入 |
| 分级压缩 | 按请求重要度采用不同压缩强度 |
写在最后:这篇用到的资料
写这篇文章时,我把上下文压缩的五级策略和参数模板整理成了对照表,顺手也整理了几份配套的东西:
- 压缩参数对照表:五级策略逐项可调参数
- 保真度评测脚本示例:固定评测集对比压缩前后
- 缓存键设计示例:文档指纹缓存压缩结果
资料是我自己整理的,放在下面这个码上,扫码即可获取:
资料较多,建议先看「全套 AGI 大模型学习路线」,再挑一个实战项目跟练。