三十七：更多提示压缩方法¶

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484469&idx=1&sn=37a44af4088c060d90ec7fc92bca9e32&chksm=f01eb74cc7693e5a36fa54bcedf473610eac35114cf4eb515bb293eeb1bdaf0de1a2673c6273#rd

1. 学习范围¶

本日主题是长上下文中的提示压缩，重点任选理解 AutoCompressor、LLMLingua-2、RECOMP 中的一类方法，但学习文档会把三者放在同一张方法地图里比较。第 36 天已经覆盖 Selective Context、LLMLingua、LongLLMLingua 等基础提示压缩，本日更关注不同压缩范式的设计差异：软提示压缩、抽取式压缩、生成式压缩、检索上下文压缩，以及这些方法在 RAG 和长上下文系统里的选型。本日覆盖： - 提示压缩的目标、输入输出和约束。

AutoCompressor 的 summary vectors / soft prompt 思路。
LLMLingua-2 的数据蒸馏式 token 级压缩思路。
RECOMP 的 extractive compressor 与 abstractive compressor。
压缩方法和 RAG、long-context、contextual compression 的关系。
压缩比、忠实性、可解释性、延迟、成本和兼容性权衡。
面试中如何比较不同提示压缩方法。

2. 提示压缩的问题定义¶

提示压缩的输入通常是长上下文：

X = instruction + context + query

目标是在保持任务关键信息的前提下，把上下文压缩成更短表示：

C = Compress(X, query, budget)
Y = LLM(instruction + C + query)

压缩的收益： - 降低 token 成本。

降低推理延迟。
缓解上下文窗口限制。
减少无关内容干扰。
在 RAG 中提高上下文密度。

压缩的风险： - 删除关键证据。

改写引入幻觉。
丢失数字、否定、条件和引用。
压缩器与下游 LLM 不匹配。
压缩开销超过节省收益。

3. 提示压缩的方法谱系¶

提示压缩方法可以按输出形式划分：

1. 抽取式压缩：保留原文 token、句子、span、chunk
2. 生成式压缩：生成摘要或重写后的短文本
3. 软提示压缩：把长文本压缩成连续向量或 summary vectors
4. 混合式压缩：抽取后摘要、检索后压缩、粗到细筛选

也可以按是否依赖 query 划分： - Query-agnostic：压缩不看具体问题，适合离线缓存。

Query-aware：根据用户问题保留相关信息，效果更强但在线成本更高。

按部署位置划分： - LLM 输入前的 prompt 压缩。

RAG 检索结果的 contextual compression。
长文档记忆或会话历史压缩。
agent 工具结果压缩。

4. AutoCompressor 的核心思想¶

AutoCompressor 关注把长上下文压缩到一组 summary vectors 中。这些 summary vectors 是连续向量表示，不一定对应可读文本。它的直觉是：与其把所有历史 token 都放进上下文，不如让模型学习把前文信息压缩成少量可被后续模型利用的软提示。

高层结构：

segment_1 -&gt; model -&gt; summary vectors_1
segment_2 + summary vectors_1 -&gt; model -&gt; summary vectors_2
...
summary vectors + query -&gt; answer

这种方法类似可学习的记忆压缩。它把长文本的信息压缩进连续向量，减少后续需要显式输入的 token 数。

5. AutoCompressor 的 Summary Vectors¶

summary vectors 可以理解为模型内部可读取的压缩记忆。它们不同于自然语言摘要： - 不一定能被人直接阅读。

可以携带比短文本摘要更适合模型使用的隐式信息。
需要模型训练或适配才能正确使用。
跨模型迁移能力通常弱于文本压缩。

其关键问题是：summary vectors 是否保留了回答任务所需的信息，以及下游模型能否稳定读取这些信息。

6. AutoCompressor 的优点与限制¶

优点： - 压缩率可以很高。

避免自然语言摘要的信息瓶颈。
适合递归压缩长上下文或历史。
能减少显式 token 输入。

限制： - 需要特定模型训练或适配。

可解释性弱，难以人工检查压缩内容。
不适合需要引用原文的场景。
与 API 黑盒模型兼容性较差。
出错时难以定位是压缩丢失还是生成失败。

因此 AutoCompressor 更偏模型架构/训练侧方法，而不是普通应用层 prompt 模板技巧。训练时，AutoCompressor 本质是基于原生预训练大模型做无监督微调，让模型学会把分段文本压缩为固定长度 summary vectors（软提示向量），全程只用自回归语言建模损失，不需要人工标注摘要数据。

7. LLMLingua-2 的核心思想¶

LLMLingua-2 关注任务无关的高效提示压缩，核心是把压缩建模为 token 级保留/删除问题。它通过数据蒸馏从强 LLM 获取压缩数据，再训练较小的压缩模型判断哪些 token 应该保留。

高层流程：

Teacher LLM / data distillation -&gt; token labels
Train compressor -&gt; predict token importance
Input prompt -&gt; keep important tokens -&gt; compressed prompt
Downstream LLM -&gt; answer

与依赖困惑度或下游 LLM 打分的方法相比，LLMLingua-2 更强调泛化、效率和任务无关压缩。

8. LLMLingua-2 的 Token Classification 视角¶

LLMLingua-2 可以理解为对每个 token 做二分类：

label(token_i) = keep or drop

保留 token 需要满足： - 对语义结构重要。

对任务回答可能有用。
对句子关系、实体、数字、条件、否定重要。
删除后不破坏整体可理解性。

压缩后输出仍然是文本 token，因此比 soft vectors 更可解释、更容易接入任意 LLM API。

9. LLMLingua-2 的优点与限制¶

优点： - 输出是文本，兼容黑盒 LLM。

压缩速度较快，适合在线系统。
可解释性比 soft prompt 强。
可用于通用长 prompt 压缩。

限制： - token 删除可能破坏语法和局部连贯性。

对需要完整引用的任务要谨慎。
如果 token importance 估计错误，关键证据会丢失。
高压缩比下数字、否定、条件容易受损。
不一定针对具体 query 最优。

10. RECOMP 的核心思想¶

RECOMP 面向 retrieval-augmented language modeling 中的检索上下文压缩。它不是压缩任意 prompt，而是压缩检索到的文档，使生成模型获得更短、更相关的上下文。

RECOMP 包含两类 compressor： - Extractive compressor：从检索文档中抽取相关句子或片段。

Abstractive compressor：生成压缩摘要，保留回答所需信息。

高层流程：

query -&gt; retrieve documents
documents -&gt; compressor -&gt; compressed context
query + compressed context -&gt; generator

11. Extractive Compressor¶

只从检索文档里直接截取原有句子 / 段落，不造新文字、不改写、不合并改写。优点： - 忠实性较好。

便于引用原文。
幻觉风险低于摘要式压缩。
适合事实问答、法律、技术文档。

缺点： - 压缩率受原文冗余程度限制。

片段之间可能不连贯。
如果答案需要综合多个句子，简单抽取可能不完整。

12. Abstractive Compressor¶

读取全部检索文档，模型自主理解信息后重写全新简短文本，融合多段内容产出连贯摘要。优点： - 压缩率高。

可以整合多文档信息。
输出更流畅。
对长检索结果更节省上下文。

缺点： - 可能引入幻觉。

可能丢失数字、限定条件和引用。
需要额外评估摘要是否忠实。
高风险场景要保留原文证据。

13. 三类方法对比¶

AutoCompressor: 软提示/summary vectors，压缩率高，但可解释性弱、需模型适配。
LLMLingua-2: token 级抽取式文本压缩，兼容性强、速度快，但高压缩比可能丢细节。
RECOMP: 面向 RAG 的检索上下文压缩，有抽取式和生成式两种，适合检索后压缩。

从可解释性看：

抽取式 RECOMP &gt; LLMLingua-2 &gt; 生成式 RECOMP &gt; AutoCompressor

从压缩潜力看：

AutoCompressor / 生成式压缩 &gt; token 删除 &gt; 句子抽取

从 API 兼容性看：

文本压缩方法 &gt; soft prompt 方法

14. Query-Aware 压缩¶

Query-aware 压缩根据用户问题决定保留什么。例如：

问题：合同的退款条件是什么？
保留：退款条款、时间限制、例外情况、金额条件
删除：公司背景、无关服务介绍

它通常比 query-agnostic 压缩更适合问答，但在线成本更高，也更依赖 query rewrite 的正确性。 RAG 中常用 query-aware compression，因为检索结果里只有部分内容与问题直接相关。

15. 压缩比与预算控制¶

压缩比定义：

compression_ratio = compressed_tokens / original_tokens

或：

compression_rate = original_tokens / compressed_tokens

实际要明确使用哪个定义。预算控制方式： - 目标 token 数。

保留比例。
按重要性排序后截断。
分层压缩：先 chunk 级，再句子级，再 token 级。
高风险字段强制保留。

压缩比越高，信息损失风险越大。

16. 忠实性与引用¶

压缩后的上下文必须仍能支持答案。尤其在 RAG 中，需要关注： - 原文证据是否仍保留。

引用 ID 是否保留。
数字、日期、否定、条件是否保留。
多文档冲突是否被压缩掉。
摘要是否引入新事实。

对需要引用的场景，抽取式压缩通常更稳。生成式压缩可以配合原文引用或 claim verification。

17. 评估方法¶

提示压缩评估包括： - 压缩率。

下游任务准确率。
Faithfulness。
Answer correctness。
Citation accuracy。
Token cost。
Latency。
压缩器开销。
关键信息保留率。

常见实验设计：

原始上下文 baseline
固定截断 baseline
摘要 baseline
压缩方法 A/B/C

必须比较压缩后端到端效果，而不只是看文本是否变短。

18. 常见失败模式¶

常见失败模式： - 删除关键实体。

删除否定词。
删除条件和例外。
删除数字、日期、单位。
删除引用 ID。
摘要引入未出现事实。
软提示不可解释，无法调试。
压缩器偏向句子流畅性而非答案支持。
压缩开销大于节省的推理开销。

高风险任务中应设置不可删字段和压缩后验证。

19. 生产选型建议¶

普通应用层 RAG： - 优先使用抽取式/contextual compression。

保留 doc_id 和引用。
需要更高压缩时再用摘要式压缩。

黑盒 LLM API： - 优先使用文本压缩，如 LLMLingua-2 或抽取式方法。

不适合依赖 summary vectors 的方法。

自研模型或可训练模型： - 可以研究 AutoCompressor 类软提示压缩。

法律、金融、医疗、合规： - 优先抽取式。

保留原文证据。
强制引用和人工审核。

长会话记忆： - 可以使用递归摘要、软记忆或分层压缩。

20. 面试表达要点¶

面试中可以这样组织：

提示压缩的目标是在尽量保留任务关键信息的前提下降低上下文 token。
AutoCompressor 把长上下文压缩成 summary vectors，压缩率高但需要模型适配、可解释性弱。
LLMLingua-2 把压缩看成 token 级保留/删除，通过蒸馏训练压缩器，输出仍是文本，兼容性强。
RECOMP 面向 RAG 检索上下文压缩，包含抽取式和生成式 compressor，分别在忠实性和压缩率之间权衡。
选型时要看任务风险、是否需要引用、是否使用黑盒 API、压缩比、延迟和端到端准确率。

21. 参考资料¶

提示词压缩技术综述: https://blog.csdn.net/Baihai_IDP/article/details/140060389
AutoCompressor paper: https://arxiv.org/pdf/2305.14788
LLMLingua-2 paper: https://arxiv.org/pdf/2403.12968
RECOMP paper: https://arxiv.org/pdf/2310.04408
LLMLingua project: https://github.com/microsoft/LLMLingua
LongLLMLingua paper: https://arxiv.org/abs/2310.06839
```
        预览时标签不可点

修改于
```
<div class="