LLMPrompt CompressionToken Cost上下文工程成本优化
Prompt 压缩技术：语义保持与信息损失之间，如何做工程权衡
Prompt 压缩看似只是“少放点 token”，实际上是在做信息论取舍：保留哪些语义、丢弃哪些细节、如何评估压缩后是否还能支持稳定推理。本文系统梳理摘要压缩、规则抽取、片段裁剪与结构化压缩四类方法，并给出保真评估、自动化流程与回退策略。
2026年3月7日
Synthly 团队
预计阅读 15 分钟
📷 Photo by Leeloo The First via Pexels
一、压缩不是节流小技巧，而是信息选择机制
很多团队做 Prompt 压缩时只盯着一个指标：
- token 变少了
但真正重要的是：
- 模型还能不能维持原有判断质量
压缩的本质不是把文本变短，而是把“未来仍有价值的信息”保留下来，把“不会影响答案的噪声”移除。这本身就是一个预测问题。
二、四类常见压缩方法
1）摘要压缩
把多轮历史或长文压缩成更短摘要。
优点：实现快、对自然语言友好。
缺点：最容易发生语义漂移。
2）规则抽取
把不可丢的约束、偏好、边界条件提取成结构化清单。
优点：稳定、便于复用。
缺点：对复杂上下文中的隐含语义抽取能力有限。
3）片段裁剪
基于重要性或相似性选择最相关的若干片段。
优点：保留原文粒度，失真较低。
缺点：容易漏掉跨片段依赖。
4）结构化压缩
把上下文转成字段化表示，例如任务状态、角色、约束、依赖等。
优点：最利于后续系统处理。
缺点：设计成本高，对任务建模能力要求高。
三、保真评估：判断“压缩后还能不能用”的关键
Prompt 压缩不能只看 token 降幅，至少要补三类评估：
- 语义保真：关键约束是否仍在
- 任务保真：任务通过率是否稳定
- 错误迁移：失败是否更多集中在遗漏/误解
一个很实用的评估方法是“关键事实对照表”：
- 原始上下文有哪些不可丢事实
- 压缩版本是否完整保留
如果压缩后连关键事实清单都保不住，再便宜也没有意义。
四、自动化流程：压缩、评估、回退三件套
建议将压缩流程设计成：
- 预处理：识别约束、事实、状态、噪声
- 压缩：选择具体压缩策略
- 校验：检查关键字段与约束是否仍存在
- 评估：小样本快速判定质量
- 回退：若风险过高，回退原文或改走 RAG
这意味着压缩不是单点函数，而是一条可失败、可回退的链路。
五、什么时候压缩最有效
压缩最有效的场景通常具备三个特征：
- 信息有大量重复
- 关键信号可结构化提取
- 当前任务不需要完整原文逐字引用
例如：
- 多轮聊天历史
- 项目状态同步
- 长任务阶段总结
而对法律条文比对、逐句校验这类任务，压缩往往风险更高。
六、与 RAG 的关系：压缩解决“保留”，RAG 解决“取回”
压缩和 RAG 常被拿来对比，但二者更像互补关系：
- 压缩：处理当前上下文与历史状态
- RAG：处理大规模外部知识
一个稳定系统通常会同时使用：
- 近期上下文压缩
- 外部知识检索
- 必要时原文回退
这比只押一边更稳。
七、结论：优秀的压缩方案，不是“压得最狠”，而是“压后仍然可靠”
Prompt 压缩的 KPI 不该只是 token 下降，而应是：
- 成本下降
- 质量稳定
- 失败可解释
只有同时满足这三点，压缩才是系统优化，而不是质量赌博。