1. 项目概述：从“无限”到“有限”的工程现实
在构建和部署大语言模型应用时，很多开发者，尤其是刚入行的朋友，常常会陷入一个美好的“幻觉”：既然模型宣称支持128K甚至更长的上下文窗口，那是不是意味着我们可以一股脑地把所有相关文档、历史对话、背景信息都塞进去，让模型在一个“全知”的语境下工作？这个想法听起来很诱人，但只要你真正动手去跑一个生产级别的应用，或者处理一批稍具规模的用户请求，现实就会给你当头一棒。你会发现响应速度慢得惊人，账单费用高得吓人，甚至模型的表现也开始变得不稳定。这背后的核心矛盾，就在于我们如何理解和使用“上下文”。
“上下文压缩”不是一个可选项，而是LLM系统设计中一个必须严肃对待的工程基石。它解决的不是“能不能”的问题，而是“好不好”、“贵不贵”、“快不快”的问题。简单来说，上下文压缩的目标，是在不显著损失任务效果的前提下，尽可能减少每次请求中实际输入给模型的令牌数量。这直接关系到系统的成本、延迟、吞吐量以及最终的用户体验。一个不进行上下文压缩的LLM应用，就像一辆没有刹车的跑车，理论上马力十足，但一上路就危机四伏。
2. 为什么必须压缩上下文？成本、性能与效果的三角博弈
要理解压缩的必要性，我们必须跳出单纯的技术视角，从系统工程的全局来审视。这背后是成本、性能和效果三者之间的一场精密博弈。
2.1 成本驱动：令牌消耗是现金消耗
这是最直接、最现实的驱动力。目前主流云服务商对LLM的API调用收费，几乎全部基于输入和输出的令牌数量。以GPT-4 Turbo为例，其128K上下文版本的输入令牌费用大约是每百万令牌10美元。听起来不多？让我们算一笔账：
假设你构建了一个客服机器人，每次用户提问，系统都需要从知识库中检索3篇各2000字（约3000令牌）的相关文档，连同10轮历史对话（约2000令牌）和当前问题（100令牌）一起发送。那么单次请求的输入令牌数就可能接近3000*3 + 2000 + 100 = 11100令牌。
- 不压缩：每次调用成本约为
11100 / 1,000,000 * $10 ≈ $0.111。 - 压缩后（假设压缩至30%）：输入令牌降至
11100 * 0.3 = 3330令牌，成本约为$0.0333。
单次节省7.8美分。对于一个日活一万、人均每日交互5次的应用，仅输入令牌一项，日成本就从5550美元降至1665美元，节省了3885美元，月省超过11万美元。这还没有计算因令牌数减少可能带来的输出令牌减少（模型需要“阅读”的内容变少了，回答也可能更精简）。在商业场景中，成本控制直接决定了项目的可行性与可持续性。
注意：这里的计算还未考虑许多模型对长上下文的处理本身就有溢价。更长的上下文通常意味着更昂贵的模型单价和更复杂的内部计算。
2.2 性能瓶颈：延迟与吞吐量的隐形杀手
成本是账面上的数字，而性能则是用户指尖的体感。LLM的推理时间与输入的令牌数呈超线性增长关系。这主要是因为Transformer架构中注意力机制的计算复杂度。对于标准的注意力，其计算量大致与序列长度的平方成正比（尽管有各种优化技术，但趋势不变）。
- 延迟：用户发送一个问题，如果系统需要将上万令牌的上下文送入模型，生成第一个令牌前的等待时间（Time To First Token, TTFT）可能会从几百毫秒激增至数秒。在交互式应用中，超过2秒的等待就足以让用户感到不耐烦。
- 吞吐量：对于服务端，处理长上下文请求会长时间占用昂贵的GPU计算资源。假设一块GPU每秒能处理10个短请求（如512令牌），面对一个8000令牌的长请求，它可能被独占数秒，导致整体服务吞吐量急剧下降，排队请求增多。
压缩上下文，本质上是缩短了模型需要“消化”的序列长度，是降低延迟、提升吞吐量最有效的工程手段之一。
2.3 效果悖论：更多信息不等于更好答案
这是一个反直觉但至关重要的点。我们本能地认为，给模型的信息越多，它的回答应该越精准。然而，在实际应用中，过长的、未经处理的上下文往往会引入“噪声”，导致模型表现下降。
- 注意力稀释：模型的注意力是有限的资源。当上下文过长时，真正关键的信息可能被淹没在海量文本中。模型可能无法有效地将注意力集中在与当前问题最相关的片段上，反而被一些无关的细节干扰。
- 中间信息丢失：有研究表明，即使在超长上下文窗口中，模型对位于输入序列中间部分的信息的记忆和提取能力也会显著弱于开头和结尾部分（类似于人类的“序列位置效应”）。简单地把所有文档拼接起来，可能意味着中间的重要信息被模型“忽略”了。
- 指令遵循偏差：过长的上下文可能包含与系统指令或用户当前意图相矛盾的历史信息或文档内容，导致模型困惑，不知该遵循哪一部分的指引。
因此，通过压缩策略（如摘要、过滤、精炼）主动地为模型筛选和呈现最相关的信息，往往比提供原始“数据垃圾场”能获得更高质量、更一致的输出。
3. 核心压缩策略全景图：从检索到重写的工程工具箱
理解了“为什么”，接下来就是“怎么做”。上下文压缩不是一个单一的技术，而是一套根据场景组合使用的工程策略工具箱。我们可以将其分为“事前”、“事中”、“事后”三大类。
3.1 事前策略：查询时检索与智能路由
这类策略发生在构造最终提示词之前，目标是尽可能避免不必要的信息进入上下文。
3.1.1 检索增强生成
这是当前最主流、最有效的策略。RAG的核心思想不是把整个知识库都塞给LLM，而是在用户提问时，先用一个轻量级的检索器（如向量数据库）从海量文档中找出最相关的几个片段，只将这些片段作为上下文送入LLM。
- 操作要点：
- 分块策略：文档如何切分直接影响检索质量。简单的按固定长度分块可能割裂语义。更好的做法是按段落、标题或语义边界进行分块，并可考虑使用重叠窗口来保持上下文连贯。
- 检索器选型：稀疏检索（如BM25）速度快、对关键词敏感；稠密检索（向量检索）语义理解能力强。生产环境中常采用混合检索，兼顾两者优势。
- 重排序：初步检索返回Top-K个片段后，可以使用一个更精细但更耗资源的交叉编码器模型对它们进行重排序，选出Top-N最相关的，进一步提升精度。
3.1.2 智能路由与上下文窗口选择
并非所有请求都需要128K的窗口。一个设计良好的系统应该具备路由能力，根据请求的预估复杂度，动态选择不同上下文长度的模型或处理管道。
- 实现思路：
- 可以训练一个简单的分类器，根据用户查询的长度、意图识别结果（例如，是简单QA还是复杂分析）来预测所需上下文大小。
- 例如，简单寒暄或事实查询，路由到低成本、快响应的4K或8K上下文模型；需要进行多文档总结、复杂推理的任务，再路由到长上下文模型。这既能节约成本，也能优化整体系统资源分配。
3.2 事中策略：对已进入上下文的信息进行精炼
当必要的背景信息（如历史对话、检索到的文档）已经进入待处理队列时，我们可以在将它们拼接成最终提示词前，进行一轮“精加工”。
3.2.1 摘要与压缩
这是最直观的压缩方法。用一个更小、更快的模型（或LLM本身）对长文本进行摘要。
- 具体方法：
- 提取式摘要：直接抽取原文中最重要的句子或段落。优点是保真度高，不会产生事实错误。可以通过TextRank等无监督算法或训练一个序列标注模型来实现。
- 抽象式摘要：用LLM重写，生成凝练的概括。例如，将10轮历史对话总结为“用户之前咨询了产品A的价格和保修政策，并比较了产品B”。这种方法压缩比高，但需警惕“幻觉”，即摘要扭曲了原意。
- 渐进式摘要：在长对话场景中，不是每次都从头总结。而是维护一个“对话摘要”状态，每次新增对话时，只将新对话与旧的摘要一起，生成更新的摘要。这类似于LSTM中的状态更新，能极大减少重复计算。
3.2.2 相关性过滤与去重
在检索到的多个文档片段或历史消息中，可能存在信息冗余或低相关度内容。
- 操作技巧：
- 基于嵌入的相似度去重：计算所有片段之间的语义相似度（如余弦相似度），合并或剔除高度相似的片段。
- 基于查询的相关性评分：不仅看片段之间的相似度，更关键的是看每个片段与当前用户问题的相关性。可以训练一个相关性评分模型，或使用LLM直接判断，只保留分数超过阈值的片段。
- 关键信息提取：对于结构化信息，可以先用LLM或规则提取出实体、属性、关键数据点，以结构化形式（如JSON）代替大段文本作为上下文。例如，将一篇产品评测文章压缩为
{"优点": ["续航长", "屏幕好"], "缺点": ["价格高"], "评分": 4.5}。
3.3 事后与架构层策略：模型与系统级优化
这类策略更接近底层，通常需要更深入的工程介入。
3.3.1 提示词工程优化
提示词本身的写法也影响效率。冗长、模糊的提示词会浪费令牌。
- 最佳实践：
- 指令前置，结构清晰：将最重要的系统指令放在最前面。使用清晰的标记（如
## 问题 ##，## 背景 ##）来分隔不同部分，帮助模型快速解析。 - 示例精炼：在少样本提示中，选择最典型、最精炼的示例，避免使用冗长的例子。
- 避免开放式引导：如非必要，不要使用“请根据以上所有信息”这种模糊指令，而是明确指定“请根据文档A的第二段和文档B的结论部分进行分析”。
- 指令前置，结构清晰：将最重要的系统指令放在最前面。使用清晰的标记（如
3.3.2 利用模型自身特性
一些新兴的模型或接口提供了原生支持。
- Claude的“浓缩”指令：如网络热词中提到的，Anthropic的Claude模型支持在对话中通过特定指令（如用户提及“请浓缩之前的对话”）来激活模型的内部摘要功能，将之前的长上下文压缩成一个简短的摘要，用于后续对话。这相当于把摘要任务“外包”给了模型本身，简化了工程实现。
- 系统级缓存：对于频繁出现的、不变的背景信息（如产品手册、公司介绍），可以预先用LLM生成其摘要或关键问答对，并将结果缓存起来。当用户查询涉及这部分内容时，直接使用缓存的结果，避免重复处理和传输原始长文本。
4. 工程落地：设计一个可扩展的上下文压缩管道
理论需要落地。在实际系统中，我们很少只采用单一策略，而是将它们组合成一个可配置、可观测的压缩管道。下面以一个假设的智能客服系统为例，拆解其核心流程。
4.1 管道设计示例
- 接收用户查询：用户提问：“你们最新款手机相比旧款，电池提升了多少？”
- 意图识别与路由：轻量级分类模型识别为“产品特性对比查询”。路由决策：需要检索知识库，但属于中等复杂度，目标压缩比为原始检索内容的40%。
- 检索阶段：
- 从向量知识库中检索出“新款手机技术白皮书”、“旧款手机规格页”和一篇“新旧款对比评测”三个文档片段，总计约6000令牌。
- 压缩与精炼阶段：
- 去重：计算发现“技术白皮书”和“对比评测”中关于电池的部分有重叠，合并后去除冗余约500令牌。
- 相关性过滤：用一个微调的BERT模型对剩余内容进行相关性打分。过滤掉与“电池”无关的屏幕、摄像头描述，再减少1500令牌。
- 提取式摘要：针对保留下来的关于电池的文本（约4000令牌），使用TextRank算法抽取核心句子，压缩至1500令牌。
- 结构化提取：尝试用小型LLM将1500令牌的文本进一步提取为结构化数据：
{"新款电池容量": "5000mAh", "旧款电池容量": "4500mAh", "提升百分比": "约11%"}。如果提取成功且置信度高，则以此作为最终上下文（约50令牌）；如果失败，则回退到上一步的1500令牌摘要。
- 构造提示词：将压缩后的上下文（50或1500令牌）、清晰的指令（“请根据提供的电池数据，直接回答用户的百分比提升问题”）和当前查询，组合成最终提示。
- 调用LLM并返回：将提示发送给LLM API，获得精准、简洁的回答：“您好，最新款手机的电池容量相比旧款提升了约11%。”
4.2 关键工程考量
- 可观测性与评估：必须为压缩管道的关键节点埋点。监控指标应包括：各阶段输入/输出令牌数、压缩比、检索命中率、相关性评分分布、LLM最终回答的质量评分（可通过模型或人工评估）。没有度量，就无法优化。
- 降级与回滚机制：压缩是有损的。必须设计健全的降级策略。例如，当相关性过滤过于激进导致有效信息丢失时，应能自动回退到更宽松的模式，甚至绕过压缩直接使用原始检索结果（同时记录日志供后续分析）。确保系统健壮性优先于极致压缩。
- 异步与缓存：摘要生成、相关性评分等计算密集型步骤，可以考虑异步执行或预计算。对于高频查询或静态文档，压缩结果可以多层缓存（内存、Redis等），极大提升响应速度。
5. 常见陷阱与实战心得
在实际操作中，我们会遇到各种预料之外的问题。以下是一些常见的“坑”和对应的解决思路。
5.1 过度压缩导致信息丢失
这是最核心的风险。压缩算法过于激进，把关键证据给“压”没了。
- 应对策略：
- 设置安全边际：不要追求单一的、极高的压缩比。根据任务类型设定动态阈值。例如，法律合同分析任务，压缩比可以低一些（如70%）；创意头脑风暴任务，压缩比可以高一些（如30%）。
- 保留“原文引用”：在采用抽象式摘要时，可以要求模型在摘要中标记关键信息的来源位置（如“根据文档A第3段”）。或者在系统设计上，当用户追问细节时，有能力快速定位并呈现原文片段。
- A/B测试：上线任何新的压缩策略前，必须进行严格的A/B测试，对比压缩版和完整版上下文下，LLM回答的关键指标（准确性、完整性、用户满意度）是否有统计学上的显著下降。
5.2 压缩引入的延迟抵消了收益
如果压缩过程本身非常耗时（例如调用另一个LLM做摘要），那么节省下来的模型推理时间可能被预处理时间吃掉，整体延迟反而增加。
- 应对策略：
- 成本-延迟权衡分析：明确你的首要优化目标。如果是为了极致降低成本，可以接受预处理有一定延迟（如异步预处理）。如果是为了降低端到端延迟，则应选择极快的压缩方法（如基于嵌入的简单过滤），或增加硬件并行度。
- 分层压缩：设计快慢两条路径。快速路径使用简单规则（如截断前N个令牌）立即响应；同时，慢速路径在后台执行精细压缩，并将结果缓存起来供后续相同或相似查询使用。
- 硬件加速：对于部署在本地的压缩模型（如BERT重排序器），考虑使用GPU或专用AI加速卡进行推理加速。
5.3 动态上下文管理的复杂性
在多轮对话中，上下文是不断增长的。如何维护、更新这个动态上下文是一大挑战。
- 实战心得：
- “摘要+滚动窗口”组合拳：这是最实用的策略。维护一个固定长度的“最近对话滚动窗口”（例如最近5轮），同时维护一个“长程记忆摘要”。每轮对话后，用LLM将“滚动窗口”中的新信息与旧的“长程记忆摘要”融合，生成新的摘要。这样，每次发送给模型的上下文就是“当前问题 + 最近几轮原始对话 + 长程记忆摘要”，长度可控且信息连贯。
- 区分对话状态与知识状态：将与当前对话进程相关的信息（如用户已选择的选项、填写的表单）以结构化的“状态”对象维护，而不必每次都放入文本上下文。只有需要自然语言理解的部分才进入LLM上下文。
5.4 评估体系缺失
无法衡量，就无法改进。很多团队只关注压缩比和成本，忽略了效果评估。
- 必须建立的评估维度：
- 保真度：压缩后的内容是否忠实于原文？可以计算关键实体、事实的保留率。
- 相关性：压缩后的内容对最终任务目标的贡献度如何？可以通过人工标注或训练一个评估模型来打分。
- 端到端任务指标：这是黄金标准。压缩策略最终是否提升了问答的准确率、摘要的ROUGE分数、代码生成的通过率？必须与基线系统进行对比。
上下文压缩不是一项一劳永逸的工作，而是一个需要持续迭代和调优的工程过程。它没有银弹，最佳策略高度依赖于你的具体应用场景、数据特点和业务目标。从最简单的检索开始，逐步引入更精细的压缩模块，并建立强大的监控和评估体系，是稳妥的演进路径。记住，目标不是把上下文压到最短，而是在成本、速度和效果之间找到属于你那个应用的最佳平衡点。
