什么是 上下文压缩（Context Compression）？
上下文压缩（Context Compression）是一种有损转换：它减少提供给 LLM 的上下文，同时保留特定下游任务所需的证据、约束与状态。
快速了解
| 全称 | 上下文压缩（Context Compression）/ 提示压缩（Prompt Compression）/ 上下文紧缩（Context Compaction） |
|---|---|
| 规范文档 | 官方规范 |
工作原理
上下文压缩会缩小原本要进入模型请求的信息表示。Prompt Compression 通常指输入级压缩，Context Compaction 常指缩减累积的对话或 Agent 历史。它不是普通文件压缩，因为原始措辞未必可以恢复；也不等同于扩大 Context Window、检索、Prompt Caching 或推理时 KV Cache 压缩，后者分别改变容量、内容选择、重复计算或运行状态，不一定产生更短的请求制品。
不同方法保留的信息和执行位置不同。硬压缩输出目标模型可直接读取的文本，包括选择文档或片段、去重、Token 剪枝、抽取式摘要与生成式摘要。软压缩把来源编码成学习得到的连续表示或 Memory Slot，因此依赖兼容的 Encoder 和目标模型。两类方法都可以是 Query-aware 或 Task-agnostic。检索和重排可以发生在压缩之前，但相关性排序本身不能证明最终任务所需的每项事实都被保留。
生产压缩器需要显式 Loss Budget，而不只是目标 Token 数或压缩率。缩减前先分类信息：System 与安全策略、授权范围、用户承诺、未决决策、否定词、数字与单位、标识符、代码或 Schema 语法、成对的 Tool Call 与 Result、来源、时间顺序及冲突证据，可能需要原文或结构化保留；低优先级叙述和重复材料才适合摘要或删除。如果受保护内容无法装入预算，应显式溢出、重新检索或进入人工复核，而不是静默丢弃。
每个压缩结果都应被视为 Derived Artifact。它要绑定 Source ID 与不可变 Revision、可用时的 Source Span、Task 或 Query Identity、Compressor 与 Prompt Revision、目标 Model 与 Tokenizer、Policy Revision、Tenant、Method、输入输出 Token 数、Protected-field Policy 及 Omitted-span Record。压缩前先完成来源授权，保持 Tenant 与 Data Class 边界，不能跨 Principal 合并摘要。压缩不是 Sanitizer：它可能保留或放大 Prompt Injection、抹去 Trust Label，或把不可信指令改写成看似权威的陈述。
压缩有自己的生命周期。Source、Permission、Task、Policy、Compressor、Target Model 或 Serialization 改变时，应使制品失效或重新生成。权威原文必须保留，供用户与评测器回查证据。反复对上一次摘要继续摘要会累积遗漏与语义漂移；长期运行系统应定期从 Source Record 或已验证 Checkpoint 重建，而不能把最新摘要当成事实来源。
评测时应在代表性与对抗性工作负载上和未压缩对照组比较。Token Reduction 是效率指标，不是质量证明。至少测量 Downstream Task Success、Critical-evidence Recall、Policy-constraint Recall、实体和数字保留、矛盾与 Unsupported-claim Rate、Citation Entailment、Abstention、包含 Compressor 成本的端到端延迟，以及每个成功任务的成本。测试精确引文、表格、代码、多语言、多跳证据、冲突来源、Prompt Injection、过期 Revision，以及不存在安全压缩方案的样本。
只发布可观测、可回退的版本化策略。在相同 Source Set、Target Model、Token Budget 与 Evaluation Suite 下比较抽取式、生成式、Token-pruning，以及适用时的软压缩方法。记录每次请求为何使用原文或压缩上下文。当 Confidence 或 Protected-information Recall 未达到门禁时，应改用原始上下文、检索更窄的来源、拆分任务、请求澄清或拒绝请求；压缩只有改善经测量的质量与成本前沿时才有价值。
主要特点
- 有损且受任务约束：只有必要证据、约束与状态仍然存活，更短的制品才有意义
- 多种表示路线：硬文本压缩与模型专属的软压缩或潜在压缩具有不同的可移植性和可审计性
- 显式损失预算：关键事实、否定、数字、权限、来源及原子 Tool 交互需要保留规则
- 版本化血缘：Source Revision、Compressor Identity、Task、Target Model、Tokenizer、Tenant 与省略片段共同定义制品
- 可测量的质量成本权衡：Token Reduction 必须与 Grounding、信息保留、任务成功、延迟及总成本联合评估
- 安全降级：低置信度或超预算时回退到来源检索、任务拆分、原始上下文、复核或拒绝
常见用途
- 压缩长对话或 Agent 历史，同时保留决策、约束、Tool 结果与未完成工作
- 把 RAG 检索文档缩减为面向当前 Query 且可回查来源的证据片段
- 删除重复样板内容，同时保留冲突证据与 Provenance
- 从 Log、Ticket 或 Workflow 构建结构化状态，并保留授权与时间语义
- 在工作负载专属质量门禁下减少重复输入成本与 Prefill 延迟
示例
Loading code...常见问题
Context Compression、Prompt Compression 与 Context Compaction 相同吗？
三者有重叠，但不是统一 API 中的同义词。Prompt Compression 通常缩短一次模型输入，Context Compaction 常用于缩减累积对话或 Agent 历史，Context Compression 则是更宽泛的工程操作。具体系统仍需声明它采用文本选择、摘要、Token 剪枝、结构化状态，还是模型专属的潜在表示。
硬上下文压缩与软上下文压缩有什么区别？
硬压缩通过抽取、过滤、Token 剪枝或摘要输出更短文本，因此可人工检查，也较容易迁移到其他文本模型。软压缩把内容编码成学习得到的向量或 Memory Slot，可能实现更强压缩，但依赖兼容的 Encoder 与目标模型，也更难由人直接检查、引用和调试。
为什么流畅的摘要不能证明压缩安全？
流畅度无法证明否定、例外、数字、权限、冲突证据、代码语法或早期决策仍被保留。摘要还可能新增无依据结论，或把不可信指令改写成权威陈述。系统必须保留来源血缘，并相对原文检查关键证据、策略约束、实体、数字、引用、矛盾与任务结果。
如何评估上下文压缩？
在相同 Source Set、Query、Target Model、Tokenizer 与输出策略下比较压缩和未压缩对照组。测量 Token Reduction、任务成功、Grounding、关键证据召回、引用蕴含、Unsupported Claim、Abstention、包含 Compressor 成本的端到端延迟，以及每个成功任务的成本，并覆盖正常与对抗性切片。
什么时候应避免压缩或执行回退？
当精确措辞、法律或安全策略、代码、Schema、数字或未决冲突无法安全转换时，应避免有损压缩。如果受保护内容装不下或保真门禁失败，应检索更窄的来源、拆分任务、改用原始上下文、请求澄清或人工复核，或直接拒绝请求，不能静默删除信息。