LLMLingua：用小模型压缩 Prompt，省 95% Token

调研范围：LLMLingua 系列（v1 / LongLLMLingua / LLMLingua-2）项目背景、技术演进、性能数据、横向对比、工程落地
主要文献：arXiv:2310.05736（EMNLP 2023）、arXiv:2310.06839（ACL 2024）、arXiv:2403.12968（ACL Findings 2024）

一、项目背景与核心原理

1.1 动机：Prompt 膨胀是 LLM 落地的成本瓶颈

CoT、ICL、RAG 等技术的普及使 prompt 长度从几百 token 迅速膨胀到数万 token。按 GPT-4 计费标准，一次请求仅 prompt 成本就可能达 $0.3–$1+。企业级应用中，80% 的 token 开销往往集中在冗余的上下文内容里。

三类影响：

• 成本：Token 按量计费，压缩 20× 可节省约 95% 的 input token 费用
• 延迟：prefill 阶段与输入长度正相关，长 prompt 直接拉高首 token 延迟（TTFT）
• 准确率：超长上下文有 “lost-in-the-middle” 问题——LLM 对中间位置的信息关注度显著低于首尾

1.2 核心洞察：用小模型 PPL 代理信息量

LLMLingua 的根本思路是：用廉价的小语言模型（GPT-2/LLaMA-7B）计算 token 的困惑度（Perplexity），以此作为信息重要性的代理。

$$\text{PPL}(x) = \exp\left(-\frac{1}{N}\sum_{i=1}^{N}\log p_\theta(x_i \mid x_{<i})\right)$$

• 低 PPL token：可预测 → 语义冗余 → 可删除
• 高 PPL token：出乎意料 → 信息量大 → 应保留

这一机制的关键优势在于：小模型对 token 重要性的判断与大模型高度相关，且完全不需要访问目标 LLM（黑盒兼容），用 GPT-2（117M）替代 GPT-4 做判断，成本可忽略。

1.3 整体框架：粗粒度 + 细粒度两阶段压缩

原始 Prompt
   │
   ▼
[粗粒度：Budget Controller]
  ─ 粒度：Demo / 文档级
  ─ 目标：给各组件分配 token 预算，高信息量的段落分配更多空间
   │
   ▼
[可选：Distribution Alignment]
  ─ 轻量 LoRA 微调，对齐小模型与目标 LLM 的词汇分布偏差
   │
   ▼
[细粒度：Iterative Token-level Compression]
  ─ 按条件 PPL 迭代过滤 token，每轮删除后重新计算（避免级联误差）
   │
   ▼
压缩后 Prompt → 目标 LLM（GPT-4 等，黑盒兼容）

二、各版本技术演进

LLMLingua 系列三个版本各自针对前一版本的核心瓶颈进行突破，并不是简单的功能叠加。

2.1 演进路线图

LLMLingua v1（EMNLP 2023）
 ├─ 核心贡献：提出「PPL 过滤冗余 token」的黑盒压缩范式
 ├─ 三阶段：Budget Controller → Iterative Token-level → Distribution Alignment
 └─ 瓶颈：无 query 感知；自回归 PPL 是 O(n²)，10k token 需 30-60s；中文差
        │
        ├─── 分支 A（RAG 场景：需要 query 感知 + 位置优化）
        │         ↓
        │    LongLLMLingua（ACL 2024）
        │     ├─ 引入对比困惑度（Contrastive PPL），把 query 信号注入 token 决策
        │     ├─ 文档重排序（缓解 lost-in-middle）
        │     └─ 瓶颈：仍是自回归，速度慢；强依赖 query 可用性
        │
        └─── 分支 B（通用场景：速度 + 泛化）
                  ↓
             LLMLingua-2（ACL Findings 2024）
              ├─ GPT-4 数据蒸馏 + 双向编码器 token 分类，彻底换掉 PPL 机制
              ├─ O(n²) → O(n)，速度快 3-6×；2.1GB 显存；多语言（中文）
              └─ 代价：最高压缩率降至 ~5×（v1 可达 20×）

2.2 LLMLingua v1（EMNLP 2023）

核心机制

Budget Controller（粗粒度）：对每条 Demonstration 整体计算 PPL，按比例动态分配 token 预算，而非粗暴地丢弃整段 Demo：

τ_i = τ · (PPL_i / Σ PPL_j) · N_demo

三段组件的分配逻辑：

• Instruction（系统提示）：低压缩率，全局语义依赖强
• Demonstrations（示例）：按 PPL 比例分配，低信息量示例多压缩
• Question（用户问题）：通常不压缩

Iterative Token-level Compression（细粒度）：逐批删除最低条件 PPL token，每轮删除后必须重新计算剩余 token 的条件概率（因为删除 token 会改变上下文，影响其他 token 的 PPL）。这是 v1 速度慢的根本原因。

Distribution Alignment（可选）：LoRA 微调小模型以对齐领域分布。消融实验显示有 vs 无对齐：GSM8K +4%，BBH +2.5%；工程场景通常可跳过。

v1 的局限

2.3 LongLLMLingua（ACL 2024）

核心洞察：RAG 场景中 LLM 性能取决于关键信息的密度和位置，不只是压掉冗余，还要主动把关键信息放到 LLM 最容易注意到的位置。

四大新组件

① Question-Aware 粗粒度压缩（文档级）

用 query-document 相关性替代文档 PPL 来分配压缩预算：

相关性分数 = PPL(question | d_i) / PPL(question)

分数越低 = 文档越能解释 question = 越重要 = 分配更多 token 预算。

② Contrastive PPL（对比困惑度，Token 级）

LongLLMLingua 最关键的技术贡献，把 query 信号显式注入 token 保留决策：

传统 PPL（v1）：  score = PPL(x_i | 前文)
对比 PPL（Long）：score = PPL(x_i | 前文) − PPL(x_i | 前文 + question)

差值越大 → 加入 question 后该 token 变得更"确定" → 与 query 高度相关 → 优先保留

③ 文档重排序（Reorder Context）

利用粗粒度的相关性分数，把高相关性文档移到首尾位置，利用 LLM 的 position bias 提升答案质量：

原始顺序：[d1(0.3), d2(0.8), d3(0.5), d4(0.9), d5(0.2)]
重排后：  [d4(0.9), d2(0.8), d3(0.5), d1(0.3), d5(0.2)]
          ↑首部最相关                              ↑尾部次要

实验：单独使用重排序（不改变压缩率）即可在多跳 QA 上提升 5-8% 准确率。

④ 后续压缩恢复（Subsequent Recovery）

压缩后对输出做局部恢复——关键实体被截断时从原文恢复其上下文窗口内的相邻 token，是后处理步骤，不影响主流程。

2.4 LLMLingua-2（ACL Findings 2024）

核心洞察：PPL 本质上是任务感知的（task-specific），泛化差；自回归计算是 O(n²)，太慢。 解法是彻底换掉 PPL 机制，改用 GPT-4 数据蒸馏 + 双向编码器。

两阶段：数据蒸馏 + Token 分类

阶段 1：GPT-4 数据蒸馏

输入：MeetingBank 数据集（~200k 条会议记录）

Step 1：提示 GPT-4 对每个 token 标注 [KEEP] 或 [DROP]
        GPT-4 能捕捉跨句依赖、专业术语重要性、语用意图

Step 2：数据质量过滤（验证 KEEP 集合能重建原文语义）

Step 3：构建训练集
        输入：原始 token 序列
        标签：0（DROP）/ 1（KEEP）
        规模：约 200k 训练样本

阶段 2：双向编码器 Token 分类

基础模型：
  XLM-RoBERTa-large（560M）→ 效果更好，~2.1GB 显存
  mBERT-base（110M）        → 更轻更快，~1.5GB 显存，多语言强

损失函数：
  L = -Σ [y_i · log(p_i) + (1-y_i) · log(1-p_i)]

推理执行：
  1. 单次前向传播，并行得到所有 token 的 p_preserve（O(n)）
  2. 按 p_preserve 降序保留前 k 个 token
  3. 恢复原始相对顺序 → 输出压缩文本

为什么双向编码器是关键改变

LLMLingua-2 最高压缩率为何更低

v2 最大实用压缩率约 5×，远低于 v1 的 20×。根本原因是训练目标不同：GPT-4 标注时倾向于保守——删掉 token 就必须不影响重建原文，过度删除的样本在数据过滤时被去掉。这是其"保真承诺"的副产品，而非设计缺陷。

2.5 三版本技术架构对比

三、压缩率、效果指标与适用场景

3.1 LLMLingua v1：极高压缩率下的惊人鲁棒性

GSM8K（数学推理，CoT）

核心结论：20× 极高压缩下 EM 仅降 1.52 个点，说明 LLM 具备很强的"残缺 prompt 理解"能力；而对比方法（Sentence Selection）在同等压缩率下崩溃（-33.1 EM）。

BBH（Big-Bench Hard，多任务推理）

成本节省

• 典型 ICL prompt 2000-5000 token（含 20 个 demonstrations）
• 压缩后 100-300 token，节省 API 成本约 80-95%

3.2 LongLLMLingua：RAG 场景压缩后反超原始

NaturalQuestions（多文档 QA，20 个文档）

MuSiQue（多跳推理）

LongBench 综合

• 4× 压缩 + 重排序：优于 GPT-3.5-Turbo 无压缩基线
• 端到端延迟降低 1.4x–2.6x（2–6× 压缩率）

核心发现：适度压缩（4×）+ 文档重排序 反而比不压缩效果更好。去噪（压缩低相关内容）+ 位置对齐（高相关文档移到首尾）共同消除了 lost-in-the-middle 这个 LLM 的固有缺陷。

3.3 LLMLingua-2：速度与显存的突破

MeetingBank（会议记录 QA）

GSM8K 推理

压缩器开销

3.4 各版本适用场景矩阵

四、与其他方案横向对比

4.1 Prompt Compression 方案全景

当前主流方案可分为两大类型：Hard Prompt（token 级文本过滤/替换，黑盒兼容）和 Soft Prompt（学习连续 embedding，需要白盒访问）。

Prompt Compression
├── Hard Prompt（黑盒兼容）
│   ├── 无监督：Selective Context、LLMLingua 系列
│   └── 有监督：RECOMP（抽取/生成式）
└── Soft Prompt（白盒，需要目标 LLM 权重）
    ├── AutoCompressor
    ├── Gist Token
    └── ICAE

4.2 核心属性对比矩阵

4.3 压缩率 vs 性能损失

4.4 深度对比分析

LLMLingua vs Selective Context

两者都是无需训练的 Hard Prompt 方案，但差距远大于表面：

关键差距：LLMLingua 的迭代 token 级过滤使其压缩率上限从 3× 拉到 20×，差距 6-7 倍。

LLMLingua vs RECOMP

RECOMP 是 LLMLingua 系列最接近的竞争对手，差异在于压缩范式：

• LLMLingua（抽取式）：只能从原文选 token，信息不会被改写，无幻觉风险
• RECOMP 生成式：可以重新组织、跨文档合并信息，在多跳推理（HotpotQA）等需要信息综合的场景有结构性优势——代价是需要训练压缩器且存在幻觉风险

选型建议：多文档查找型问答（RAG）用 LLMLingua；需要跨文档信息整合且有幻觉容忍的场景可考虑 RECOMP 生成式。

Hard Prompt vs Soft Prompt

结论：Soft Prompt 学术指标漂亮，但绑定特定 LLM 版本、不可审计、无法用于任何 SaaS API，目前主要是研究工具。工业场景 90%+ 是黑盒 API，LLMLingua 系列是事实上的主流。

4.5 综合评分

五、工程落地建议

5.1 版本选型决策

你的场景是什么？
│
├── 需要极高压缩率（>10×）？
│   └── ICL/Few-shot 场景 → 选 LLMLingua v1（LLaMA-7B 压缩器）
│
├── RAG 多文档问答，且 query 可提前获得？
│   └── 选 LongLLMLingua + reorder_context="sort"
│
├── 中文 / 多语言场景？
│   └── 必须用 LLMLingua-2（XLM-RoBERTa / mBERT）
│
├── 通用 pipeline，query 不可提前获得？
│   └── 选 LLMLingua-2（任务无关，开箱即用）
│
└── 显存 < 4GB 或纯 CPU 环境？
    ├── LLMLingua-2 mBERT（~1.5GB）→ 最推荐
    └── LLMLingua v1 + GPT-2（~0.5GB）→ 备选

通用首选：绝大多数工程场景首选 LLMLingua-2（xlm-roberta-large）——开箱即用，速度最快，不依赖 query，适配任何 pipeline。

5.2 安装与快速上手

# 基础安装
pip install llmlingua

# 完整安装（含 LangChain / LlamaIndex 集成）
pip install llmlingua openai langchain langchain-community

三种核心用法

from llmlingua import PromptCompressor

# ─── 用法 1：LLMLingua-2（推荐，通用首选）
llm = PromptCompressor(
    "microsoft/llmlingua-2-xlm-roberta-large-meetingbank",
    use_llmlingua2=True   # ⚠️ 必须设置，否则走 v1 逻辑
)
result = llm.compress_prompt(prompt, rate=0.5)
# result 包含 compressed_prompt / origin_tokens / compressed_tokens / ratio / saving

# ─── 用法 2：LongLLMLingua（RAG 多文档场景）
llm = PromptCompressor()
result = llm.compress_prompt(
    [doc1, doc2, doc3, ...],
    question="What are the main findings?",
    rate=0.4,
    reorder_context="sort",               # 文档重排序（强烈推荐）
    dynamic_context_compression_ratio=0.3,# 高相关文档少压缩
    rank_method="longllmlingua",
    condition_compare=True,
)

# ─── 用法 3：精细控制（结构化压缩）
structured = """
<llmlingua, compress=False>Speaker A:</llmlingua>
<llmlingua, rate=0.3>This is a lengthy explanation that can be compressed...</llmlingua>
"""
result = llm.structured_compress_prompt(structured, rate=0.5)

5.3 LangChain 集成（三步完成）

from langchain.retrievers.contextual_compression import ContextualCompressionRetriever
from langchain_community.document_compressors import LLMLinguaCompressor

# Step 1：初始化压缩器（一次，循环外）
compressor = LLMLinguaCompressor(
    model_name="microsoft/llmlingua-2-xlm-roberta-large-meetingbank",
    use_llmlingua2=True,
)

# Step 2：包裹现有 Retriever（不侵入已有代码）
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=your_retriever   # FAISS / Chroma / Pinecone 等均可
)

# Step 3：调用方式与普通 retriever 完全一致
docs = compression_retriever.invoke("Your question here")

5.4 LlamaIndex 集成

from llama_index.postprocessor.longllmlingua import LongLLMLinguaPostprocessor
from llama_index.core.query_engine import RetrieverQueryEngine

node_postprocessor = LongLLMLinguaPostprocessor(
    target_token=300,                     # 直接指定压缩后 token 数
    rank_method="longllmlingua",
    additional_compress_kwargs={
        "condition_compare": True,
        "reorder_context": "sort",
        "dynamic_context_compression_ratio": 0.3,
    },
)

query_engine = RetrieverQueryEngine.from_args(
    retriever=retriever,         # similarity_top_k 建议设 10-20
    node_postprocessors=[node_postprocessor],
)

5.5 压缩率设置建议

5.6 生产环境注意事项

① 模型缓存（必须）

首次运行会从 HuggingFace 下载模型（xlm-roberta-large ~1.1GB），生产环境必须提前缓存：

import os
os.environ["HF_HOME"] = "/path/to/model/cache"   # 指定缓存目录

② 初始化在循环外

# ❌ 错误：每次循环重新加载，极慢
for doc in docs:
    llm = PromptCompressor(...)   # 每次重新加载几 GB 模型

# ✅ 正确：初始化一次复用
llm = PromptCompressor(...)
for doc in docs:
    llm.compress_prompt(doc, rate=0.5)

③ 不适用场景

④ 压缩率 vs target_token 选择

# rate：相对压缩比，适合不确定输入长度时
llm.compress_prompt(prompt, rate=0.5)

# target_token：绝对 token 数，适合有严格上下文窗口限制时
llm.compress_prompt(prompt, target_token=512)

5.7 端到端收益估算

示例：RAG 服务，检索 10 个文档共 8k token，目标 LLM 为 GPT-4o

不压缩：
  [retrieval 1s] + [LLM 推理 8s @ 8k input tokens] = 9s 端到端
  成本：8k × $5/1M = $0.04/次 × 日 10k 请求 = $400/天

压缩（LLMLingua-2，3×）：
  [retrieval 1s] + [压缩 0.5s] + [LLM 推理 3s @ ~2.7k tokens] = 4.5s 端到端
  成本：2.7k × $5/1M = $0.0135/次 × 日 10k 请求 = $135/天

结果：延迟 -50%，成本 -66%（节省 $265/天）
      注意：LLMLingua-2 压缩器本身在自有服务器运行，边际成本接近 0

六、信息来源