跳转至

三十六：长上下文提示压缩

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484450&idx=1&sn=669b9171a8d8d7ee316303d93f9054ee&chksm=f01eb75bc7693e4d6d2fcb30f4b784e5b86777b170c1f2169957b7cf82fd9e5356c1d9475248#rd

1. 学习范围

本日主题是提示压缩，重点是 LongLLMLingua。前几天讨论了扩大上下文窗口和分割上下文窗口；今天讨论另一条更工程化的路线：在送入大模型之前，先压缩 prompt，减少 token 数、降低成本、缓解 lost-in-the-middle，并尽量保留回答问题所需的信息。 需要掌握： - 提示压缩解决什么问题。

  • Selective Context、LLMLingua、LongLLMLingua 的区别。

  • 信息量、困惑度、条件困惑度和 token importance 的直觉。

  • 粗粒度到细粒度压缩流程。

  • question-aware compression 为什么重要。

  • LongLLMLingua 如何缓解长上下文中的信息稀释。

  • 压缩比、答案质量、忠实性和延迟的评估方法。

2. 参考资料

  • 提示词压缩技术综述：https://blog.csdn.net/Baihai_IDP/article/details/140060389

  • Selective Context 论文：https://arxiv.org/abs/2310.06201

  • LLMLingua 论文：https://arxiv.org/abs/2310.05736

  • LongLLMLingua 论文：https://arxiv.org/abs/2310.06839

  • LLMLingua 项目：https://github.com/microsoft/LLMLingua

3. 提示压缩的问题定义

长上下文不只是“模型能收多少 token”的问题。即使模型支持 32k、128k，上下文过长仍会带来： - 推理成本高。

  • 延迟高。

  • 无关信息干扰。

  • lost-in-the-middle。

  • prompt 中关键约束被稀释。

  • RAG 检索片段过多导致证据噪声。

提示压缩的目标：

输入原 prompt P 和 token budget B
输出压缩 prompt P'
使 len(P') <= B
同时尽量保留任务答案所需信息
它不是简单摘要。摘要会改写内容，而压缩可以保留原文 token 或短片段，减少模型误解和事实漂移。

4. 提示压缩和摘要、RAG 的区别

技术 核心操作 优点 风险 RAG（检索增强生成） 向量库检索相关文档片段，拼接至 Prompt 再生成 过滤海量无关素材，降低长文本噪声，可控外部知识 检索召回偏差会丢失关键信息；检索粒度差易上下文断裂 文本摘要 大模型对原始长文浓缩改写输出精简内容 输出逻辑通顺、可读性强，大幅缩减输入长度 易产生事实幻觉；压缩过程丢失小众关键细节、数据 提示词压缩 规则 / 模型筛选删除低价值句子、冗余 Token，原文语句保留 完全依托原文证据无改写失真，显著节约上下文窗口 算法误判易删减核心约束、限定条件、关键论据 原生长上下文大模型 不做预处理，完整输入全部原始文本直接推理 流程最简，无中间步骤信息损耗，无需额外检索 / 压缩模块 推理算力、Token 成本高昂；全文冗余噪声干扰模型判断 提示压缩常和 RAG 组合：

query -> retrieve top-n -> rerank -> compress contexts -> LLM answer

5. Selective Context

Selective Context 的核心思想是：上下文中不同 token 或句子的“信息量”不同，可以删除低信息量内容，保留高信息量内容。 常见直觉： - 功能词、套话、冗余表达信息量低。

  • 实体、数字、关系、条件、结论信息量高。

  • 对语言模型来说越不可预测的 token，通常越有信息。

它使用语言模型估计 token 的自信息或困惑度相关指标：

self_information(token) = -log P(token | prefix)
信息量低的内容可以优先删除，从而压缩上下文。 Selective Context 的优点： - 思路简单。

  • 不需要目标大模型参与。

  • 适合做内容级筛选。

局限： - 不一定 question-aware。

  • 高自信息不一定等于对当前问题有用。

  • 可能保留罕见但无关内容，删除常见但关键的否定词或约束。

6. LLMLingua

LLMLingua 的目标是用小语言模型压缩 prompt，让大模型以更少 token 完成任务。它强调“用小模型做 compressor，用大模型做 target LLM”。 核心模块：

prompt
  -> budget controller（设定 Token 压缩上限）
  -> coarse-grained compression（段落 / 句子级筛选）
  -> token-level iterative compression（逐 Token 评估权重删减）
  -> compressed prompt
  -> target LLM
关键思想： - 使用小模型估计 token 或片段的重要性。

  • 根据预算控制压缩比例。

  • 逐步删除低重要性 token。

  • 尽量保持压缩 prompt 对目标大模型仍可理解。

LLMLingua 的价值： - 降低 target LLM 输入 token。

  • 减少推理延迟和成本。

  • 对长 prompt、few-shot 示例和 RAG 上下文都有应用空间。

LLMLingua 的风险： - 小模型和目标大模型的偏好不完全一致。

  • 过度压缩会破坏语法和任务指令。

  • 对表格、代码、数学、法律条款要非常谨慎。

7. LongLLMLingua

LongLLMLingua 面向长上下文场景，重点不只是压缩 token，而是提升长上下文信息利用效率。它关注一个实际问题：

长上下文中，关键证据可能被大量无关内容淹没。
即使放进 prompt，模型也可能因为 lost-in-the-middle 或注意力稀释而用不好。
LongLLMLingua 的核心是 question-aware compression： - 当前问题是什么？

  • 哪些文档、句子、token 对回答这个问题最有用？

  • 哪些内容虽然信息量高，但和当前问题无关？

高层流程：

question + long context
  -> coarse document / sentence filtering
  -> question-aware importance estimation
  -> token-level compression
  -> optional reorder / highlight important context
  -> compressed prompt
  -> target LLM
与 LLMLingua 相比： - LLMLingua 更通用，主要关注 prompt 压缩。

  • LongLLMLingua 更关注长上下文问答和关键证据保留。

  • LongLLMLingua 更强调 query/question 与 context 的关系。

8. Coarse-to-Fine 压缩

长上下文太长时，不适合一上来对所有 token 做精细评分。更高效的做法是 coarse-to-fine：

文档级:
  判断哪些文档最相关。

段落/句子级:
  判断哪些段落或句子可能包含答案。

token 级:
  删除低价值 token，保留实体、数字、关系、否定和条件。
这种方法降低计算量，也减少重要 token 被早期误删的风险。 RAG 场景中常见：

retrieved docs top-20
  -> rerank top-10
  -> LongLLMLingua compress to budget
  -> final prompt

9. Question-Aware Importance

通用文本信息量衡量方式（如基于词频、稀有度、全局熵）仅评估 Token 在全文内部的固有稀缺程度，只判断一段文字本身信息多不多，完全忽略用户当前查询意图。 例如问题：

问：合同的终止日期是什么？
上下文中：

公司名称、合同编号、金额、终止日期、付款方式
金额可能很显眼，但对“终止日期”不一定有用。Question-aware compression 会把问题作为条件，优先保留和问题相关的片段。 直觉形式：

importance(token) = usefulness(token | question, context)
工程上可用小模型困惑度、条件困惑度、相关性打分、reranker 分数或启发式规则组合估计: - 条件困惑度（Conditional Perplexity）固定 Question，移除某段 Token 后计算模型困惑度涨幅；困惑度上升越多，代表该 Token 对回答问题越关键。

  • 轻量小模型困惑度打分用小型 LM 快速评估：带该 Token 和去掉该 Token，回答问题的生成难度差异，低成本衡量 Token 价值。

  • 交叉重排模型（Reranker）相关分数将 query + 句子送入 Cross-Encoder，输出相关性得分，作为句子、Token 层重要度依据。

  • 启发式规则补充匹配问题实体、数字、时间、否定、条件连词、关键词同义项，强制提升对应 Token 权重。

10. 压缩比与预算控制

压缩比：

compression_ratio = original_tokens / compressed_tokens
也可用保留率：

keep_rate = compressed_tokens / original_tokens
预算控制需要考虑： - 系统提示和安全约束不能被删。

  • 用户问题必须完整保留。

  • 输出格式要求必须完整保留。

  • 证据引用 ID、标题、页码等元数据最好保留。

  • RAG 片段之间的分隔符要保留，避免上下文混淆。

常见策略：

固定预算:
  最终 prompt 不超过 8k tokens。

动态预算:
  根据 query 难度、检索数量、模型窗口和成本自动分配。

分区预算:
  instruction 0 压缩，question 0 压缩，evidence 高压缩，examples 中压缩。

11. 提示压缩的常见失败模式

删除否定词：

不允许、不得、没有、除非
这类词短但关键。 删除实体或数字： 压缩后答案可能引用错误对象或错误数值。 破坏表格结构： 列名和单元格错位，模型无法理解。 破坏代码： 删除括号、缩进、变量名会使代码语义改变。 删除约束和输出格式： 模型可能答非所问或不按格式输出。 小模型错估重要性： compressor 认为不重要的内容，target LLM 实际需要。 过度压缩导致语法碎片化： 模型能省 token，但上下文变得难读，答案质量下降。

12. 评估方法

提示压缩要同时看： - 压缩比。

  • 输入 token 节省。

  • 端到端延迟。

  • 成本下降。

  • QA exact match / F1。

  • 答案忠实性。

  • 引用正确率。

  • 关键信息保留率。

  • 过度压缩失败率。

推荐实验：

baseline:
  原始 long prompt -> target LLM

variant A:
  Selective Context -> target LLM

variant B:
  LLMLingua -> target LLM

variant C:
  LongLLMLingua question-aware compression -> target LLM

比较:
  token reduction
  latency / cost
  answer quality
  citation accuracy
  failure cases

13. 实战建议

优先不压缩： - system prompt。

  • 安全规则。

  • 用户问题。

  • 输出格式。

  • 工具调用 schema。

谨慎压缩： - 法律条款。

  • 医疗说明。

  • 数字密集文本。

  • 表格。

  • 代码。

  • 数学推导。

适合压缩： - RAG 返回的冗余上下文。

  • 长对话历史中的寒暄和重复内容。

  • 多篇文档中的背景说明。

  • few-shot 示例中非关键解释。

推荐 pipeline：

query
  -> retrieve top-n
  -> rerank top-k
  -> preserve metadata and citation ids
  -> LongLLMLingua question-aware compression
  -> final answer with citations

14. 面试表达模板

可以这样回答 LongLLMLingua：

LongLLMLingua 是面向长上下文场景的提示压缩方法。普通长上下文直接喂给 LLM 会带来高成本、信息稀释和 lost-in-the-middle。LLMLingua 用小模型估计 token 重要性并按预算压缩 prompt；LongLLMLingua 在此基础上更强调 question-aware，也就是根据当前问题判断哪些文档、句子和 token 真正有助于回答。它通常采用 coarse-to-fine 流程：先粗粒度筛文档或句子，再做 token 级压缩，并尽量保留问题、指令、实体、数字、否定、引用 ID 和关键证据。

它的价值是减少 token、降低延迟成本，并提升模型在长上下文中的信息利用效率。风险是过度压缩会删掉关键约束或破坏表格、代码、数字，因此必须用答案质量、忠实性和引用正确率一起评估。

15. 紧凑总结

  • 提示压缩通过删除低价值内容降低 token 成本和上下文噪声。

  • Selective Context 依据信息量筛选上下文。

  • LLMLingua 用小模型作为 compressor，做预算控制和 token 级压缩。

  • LongLLMLingua 强调 question-aware compression，适合长上下文 QA。

  • 压缩不是摘要，最好保留关键原文证据和引用元数据。

  • 评估要同时看压缩率、答案质量、忠实性、引用正确率和延迟成本。

            预览时标签不可点

    <div class="