Prompt 压缩有哪些方法？

简化版

Prompt 压缩应先删除重复模板和无关证据，再对历史对话与文档做结构化摘要，必要时用查询感知抽取或 learned soft prompt。压缩目标不是 Token 最少，而是在质量约束下减少输入成本；系统规则、权限边界、关键数字、引用位置和输出契约属于不可损压缩区。

详细版

方法从低风险到高风险包括：模板去冗余、字段化表达、检索只取相关片段、对话状态摘要、句子/Token 重要度抽取、较小模型生成摘要，以及提示蒸馏/soft prompt。抽取保留原文但可能断上下文，生成摘要更紧凑却可能改写事实，soft prompt 高效但不透明且绑定模型。

设计时把内容分成 must-keep、可压缩和可丢弃三层，为数字、否定条件和证据 ID 做校验；压缩后测任务正确率、事实保真、指令遵循、输入 Token、P95 和压缩耗时。节省的 LLM prefill 必须大于压缩器成本，并为高风险请求保留原文回退。

原始上下文 -> 规则去重 -> 查询相关筛选 -> 摘要/抽取 -> 关键字段校验 -> 模型
                  保真高 ----------------------> 压缩强、风险高

完整版教学

一、为什么要压缩 Prompt

长 Prompt 增加首 Token 延迟、调用费用和注意力干扰，还会挤占输出空间。即使模型支持超长窗口，也不代表每个 Token 都有价值；重复日志和无关文档会造成 lost-in-the-middle。压缩本质是在有限预算下提高有效信息密度。

但“更短”不是独立目标。如果删掉退款条件中的“不”字，Token 省得再多也失败。应先定义允许的质量退化和必须保留的信息，再谈压缩率。

二、先做无损与规则压缩

最低风险操作包括删除重复系统段、合并相同规则、去无意义空白、把冗长 JSON key 映射为短但明确的 schema，以及不重复发送模型已缓存的固定前缀。模板层优化可人工审查，且容易定位问题。

例如 2000 Token 的工具说明中，五个工具重复相同错误格式 300 Token，可把公共规则提到一次。若每请求省 1200 Token、日调用 100 万次，就是 12 亿输入 Token；这种收益不需要让另一个模型改写事实。

记忆钩子：先清理“重复和无关”，再压缩“有用信息”；顺序反过来会花成本概括本来就该删除的内容。

三、检索与查询感知筛选

对文档库而言，最有效的压缩往往是不把无关内容召回。按用户问题检索 Top-k，再用 reranker 过滤，可把几十页降到几个片段。查询感知抽取还会在片段内保留与问题相关句子，同时附页码和段落 ID。

方法	保真性	额外成本	主要风险
规则去重	高	低	规则写错
检索筛选	原文保留	中	漏召回
抽取式压缩	较高	中	上下文断裂
生成式摘要	中	中高	幻觉与数字改写
Soft Prompt	难解释	训练成本	模型绑定

筛选要保留邻接窗口，避免只留下结论而丢条件。

四、对话摘要怎么避免状态漂移

多轮对话可把历史转成结构化状态，如用户目标、已确认事实、未决问题和工具结果，而不是一段自由摘要。每次更新只修改对应字段，并保留最近若干轮原文。用户纠正旧信息时，要覆盖旧值而非把矛盾同时保留。

goal: 预订上海酒店
constraints: [2026-10-01入住, 预算<=800]
confirmed: [双床]
pending: [区域]
evidence: [tool_call_17]

关键交易参数应从结构化源读取，不能依赖摘要模型回忆。定期从原始事件重建状态，可检测累计漂移。

五、生成摘要有哪些校验

生成式压缩能融合重复表述，但会遗漏限定词、修改数字或添加推断。可以要求输出固定 schema，逐项附证据 ID，再用程序检查金额、日期、实体和否定词是否来自原文。高风险字段直接复制，不允许自由改写。

若 10K Token 合同压到 1K，压缩率 10:1，但问答准确率从 90% 降到 70%，没有工程价值。可以采用分层摘要：先按章节生成带引用摘要，问题到来时回源拉取相关原文，而非只保留最终摘要。

六、Learned Compression 适合什么场景

Prompt tuning、prefix tuning 或蒸馏可把固定任务说明压成一组连续向量，减少文本 Token 并提高特定模型表现。它适合高频稳定任务，不适合频繁变规则或要求审计的政策文本。换模型或版本后，soft prompt 往往需要重新训练。

还有 Token 级重要度模型，通过删除对输出影响小的 Token 达到强压缩。它可能破坏语法或忽略全局依赖，应在真实任务上测，不可仅用语言模型困惑度判断。生产中通常把它放在低风险可回退场景。

七、怎样算压缩是否划算

定义压缩率 r = compressed_tokens / original_tokens，同时计算质量变化和端到端成本。若原输入 8000 Token，压到 3000，压缩器耗时 150ms、目标模型 prefill 节省 400ms，则净省 250ms；若短请求只省 50ms，压缩器反而拖慢。

评测集应包含数字、否定、长距离条件、引用和注入文本，比较无压缩基线。记录压缩器版本与输出，使错误可复现。根据请求长度和风险动态路由，低于阈值不压，高风险附原文，高重复长文本才启用强压缩。

八、常见误区与追问

• 误区：上下文窗口够大就不需要压缩。 成本、延迟和无关信息干扰仍然存在。
• 误区：摘要语句通顺就代表保真。 数字、否定和条件可能已被悄悄改写。
• 误区：压缩率越高方案越好。 应在质量约束下看净延迟与净成本。
• 追问：哪些内容绝不能自由摘要？ 系统权限、安全边界、关键数字、法律原文和输出契约。
• 追问：抽取式和生成式如何选？ 要求可追溯优先抽取，需要融合冗余且可校验时才用生成摘要。
• 追问：如何防摘要累积漂移？ 保留事件日志和近期原文，定期从源重建，并校验结构化状态。

九、加强记忆

Prompt 压缩可记成“删、检、抽、摘、验、算”：先删重复，检索相关内容，抽取原文关键句，必要时再生成摘要；关键字段和引用必须校验，最后算目标模型节省减去压缩器开销。把信息分级并保留回源能力，才能让压缩省 Token 而不偷走正确性。