面经策

什么提示压缩？为什么在 RAG 中需要提示压缩？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

提示压缩（Prompt Compression）指在把长上下文送入大模型前，用算法或小模型把冗余信息浓缩——去重复、删寒暄、压缩历史对话、摘要化检索文档，只保留与当前任务相关的信息密度。

为什么 RAG 需要它：一是成本。检索回来的文档动辄几万 token，而按 token 计费，长提示直接吃掉利润——高频客服场景下，提示压缩能省 30%~60% 的 token 开支；二是效果。塞进过多无关内容会引发"迷失在中间"问题，模型反而答得更差；三是窗口上限。长对话+多文档场景不压缩就会溢出。

落地方式：轻量级用 LLMLingua 这类压缩模型做 token 级裁剪；重量级用 LLM 先对检索文档做"面向问题的摘要"。我的取舍原则：压缩是有损的，会牺牲细节忠实度——法律条款、医疗指南这类"一个字都不能错"的内容我倾向不压缩或只做粗筛，营销知识库这类宽容场景则大胆压。先算清 token 账和错误代价账，再决定压到什么程度。

🏗 系统架构师 ​

提示压缩（Prompt Compression）是在上下文窗口预算内，把长 Prompt/检索内容压到信息密度更高的短文本，通常用小模型做"抽取式删减 + 概括式改写"。

为什么需要：三个硬约束——上下文窗口是付费资源（2026 年长上下文虽便宜了但不是免费）、Attention 有"中间丢失"效应（lost in the middle，塞 100K 只用 5K 时模型反而抓不住重点）、推理延迟随 token 数线性上涨（prefill 时间直接吃 P99）。

工程做法：

  • 检索侧：chunk 打分后只留 Top-3，每条先做要点抽取再进 Prompt；
  • 历史侧：多轮对话旧轮次只保留"决策与事实"，寒暄和过程性内容丢弃（LLMLingua 类工具可做 token 级压缩，压到 1/4~1/2）；
  • 系统侧：System Prompt 里冗长的规则改写成紧凑条目，配合 Prompt Cache 避免重复计费。

权衡：压缩是有损的，过度压缩丢关键约束，会导致幻觉回升。我的纪律：压缩率控制在 30%~50%，且关键指令、数字、实体名白名单保护不压；上线前用回归集对比压缩前后的任务指标，而不是只看省了多少 token。

💻 全栈开发专家 ​

提示压缩是在 token 预算内把进 Prompt 的内容压小但保住关键信息。为什么需要：一是长对话/长文档直接塞会超上下文或成本爆炸；二是无关内容稀释注意力，模型「lost in the middle」反而答得更差。

工程上分两级：

  • 粗粒度（可解释、可控）：历史对话滚动摘要（旧轮次压成一段事实）、工具结果摘要（50KB 搜索结果→要点+引用）、检索上下文只留 rerank 后 top 3。
  • 细粒度（token 级）：LLMLingua 类工具用小模型逐 token 打困惑度，删掉「好猜」的冗余词，能压到 1/4~1/20，任务掉点很小：
python
from llmlingua import PromptCompressor
compressor = PromptCompressor(model_name="microsoft/llmlingua-2-xsmall")
result = compressor.compress_prompt(context, rate=0.5)

我的实践建议：优先用结构化粗压缩（可控、可审计），LLMLingua 用在对成本极度敏感的高 QPS 场景；压缩后要留「不可压缩区」——system prompt、安全约束、最近 2 轮原文永远不压。另外压缩策略要进评测集回归，否则省了钱悄悄掉了准确率都不知道。