上下文压缩
当上下文过长时，一般是怎么进行压缩的？
当大语言模型（LLM）的上下文过长（超过模型原生上下文窗口，或即使在支持长上下文的模型中也希望降低成本、加速推理、减少KV cache占用）时，目前业界主流的压缩/优化方式可以大致分为以下几类（从最常用到较前沿的排序）：
1. 最常见、最广泛使用的几种方式（工程上最成熟）
| 压缩方式 | 核心思路 | 压缩比（常见） | 适用场景 | 代表工具/方法 | 优缺点简评 |
|---|---|---|---|---|---|
| LLM摘要/提炼式压缩（Abstractive） | 用LLM自己把历史对话/长文档总结成几句话或关键事实 | 3–20× | 长对话、多轮Agent、文档问答 | LangChain Summary、LLMLingua的prompt压缩、Roo Code双重压缩 | 效果最好，但需要额外调用一次LLM，成本稍高 |
| 提取式压缩（Extractive） | 从原文中直接挑出最重要的句子/片段保留下来 | 5–15× | 文档问答、RAG | LLMLingua、Selective Context | 速度快、无幻觉风险，但可能丢失连贯性 |
| 基于困惑度/信息熵的硬删减 | 计算每个token/句子对当前任务的“重要性”（困惑度、自信息量），低于阈值就删 | 2–10× | 几乎所有长上下文场景 | LLMLingua系列、信息熵剪枝 | 非常快，几乎零额外推理成本，但压缩过度容易丢关键信息 |
| 滑动窗口 + 最近优先 | 只保留最近N轮对话 + 少量关键历史摘要 | 固定窗口 | 聊天机器人、客服Agent | 绝大多数开源Agent框架默认策略 | 实现最简单，但老信息容易永久丢失 |
2. 中间层/推理时压缩（越来越流行，2025–2026年主流方向）
软压缩（Soft Prompt Compression）
把长上下文编码成少量“虚拟token”或concept embedding，再喂给主模型。
代表：CompLLM（分段独立压缩、可缓存）、Gist tokens、AutoCompressor
优点：推理速度可提升2–4倍，KV cache减半甚至更多
目前多用于长文档问答（Q&A over book / codebase）KV Cache压缩（不压缩输入prompt，只压缩推理过程中产生的key-value缓存）
- 量化（FP8 → INT4 / NVFP4）
- 注意力相似性聚类 / 共享（相似的token共享KV）
- 重要性驱逐（eviction，根据attention score动态扔掉不重要token的KV）
代表：KVPress (NVIDIA)、H2O、SnapKV、Infini-attention的压缩记忆部分
优点：对用户无感知，端到端提速明显，内存占用可减50%以上
3. 其他高级/特定领域方式
- 代码专用压缩：LongCodeZip（粗粒度函数级 + 细粒度块级，根据指令困惑度排序保留）
- 视觉/多模态压缩：把长文本渲染成图片再OCR（DeepSeek-OCR、Glyph），或直接用视觉token表示（2025年后很火的一条路线）
- 记忆外置 + 按需召回（严格来说不算压缩，但效果类似）
→ 把历史压缩成向量存向量库，需要时RAG拉回来（最常见于生产级Agent系统）
实际产品/框架里最常看到的组合策略（2026年视角）
- 平时用滑动窗口 + 最近K轮兜底
- 当token快满时（比如占窗口90%以上），自动触发LLM摘要压缩或LLMLingua式硬压缩
- 对于特别长的文档/RAG场景，优先用提取式 + 查询感知摘要（query-aware summary）
- 如果部署在GPU上且追求极致性能，再叠加KV cache量化 + 动态驱逐
一句话总结目前工程界的共识：
“能用滑动窗口 + 摘要就先用，能用困惑度硬删就别轻易上LLM摘要，能上软压缩/KV压缩就尽量上，能不让用户感知到压缩最好。”
你现在是在做哪一类场景的长上下文优化？（聊天、RAG、Agent、代码、百万token文档……）可以告诉我更具体的需求，我可以给你更针对性的当前最佳实践。