大模型长对话上下文压缩：摘要与检索混合方案实战

1. 项目概述：为什么我们需要“对话压缩”？

如果你最近在折腾大模型应用，尤其是想搞个能记住上下文的聊天机器人，那你肯定遇到过这个头疼的问题：聊得越久，模型记性越差。这可不是模型“笨”，而是技术上的一个硬限制。几乎所有主流大模型，无论是 OpenAI 的 GPT 系列，还是开源的 Llama、Qwen，都有一个“上下文窗口”的概念，比如 4K、8K、16K、32K 甚至 128K tokens。这个窗口就像模型的工作记忆区，你塞进去的对话历史、系统指令、用户问题全在这里面。一旦对话轮次多了，总长度超过这个窗口，模型要么直接报错，要么开始“胡言乱语”——它把最早的那部分对话给“忘”了。

“大模型多轮对话自动上下文压缩”要解决的，就是这个“遗忘”痛点。它的核心目标不是无脑地把所有历史对话都扔给模型，而是像一位经验丰富的秘书，在每次需要模型回答前，主动帮你整理“会议纪要”。它会智能地分析冗长的对话历史，提炼出对当前问题真正有用的核心信息，剔除冗余、无关的细节，然后将这份精炼后的“摘要”连同当前问题一起交给模型。这样，我们既保留了对话的连贯性，又始终让模型在有限的上下文窗口内，处理最相关、最精华的信息。

我最初意识到这个问题的重要性，是在开发一个客服助手原型时。当用户和机器人就一个复杂的产品故障来回沟通了十几轮后，机器人突然开始重复询问用户的基本信息，完全忘记了之前讨论的技术细节。那一刻我明白，单纯靠增大上下文窗口（成本高昂且技术实现复杂）不是根本解法，我们必须教会应用如何“主动管理记忆”。这就是“自动上下文压缩”的价值所在：它让大模型应用在长对话中也能保持稳定、精准的“记忆力”，是构建实用级AI对话系统的关键技术组件。

2. 核心思路拆解：从“全量记录”到“智能摘要”

实现自动上下文压缩，绝不是简单粗暴地截断或者随机丢弃历史消息。那会直接破坏对话的逻辑连贯性。我们需要的是一个有“理解”能力的压缩策略。目前，业界和社区的主流思路可以归纳为以下几种，每种都有其适用的场景和权衡。

2.1 思路一：基于摘要的压缩（Summarization-Based）

这是最直观、逻辑最清晰的方法。其核心流程是：维护一个独立的“摘要存储器”。每当新增一轮对话（用户提问+助手回答），系统并不直接将这轮对话原文追加到历史记录中，而是触发一个“摘要更新”过程。

1. 输入：当前的“历史摘要” + “最新一轮对话原文”。
2. 处理：调用一个大模型（可以是与主模型相同的模型，也可以是一个更轻量、更便宜的专用摘要模型），给出一个指令，例如：“请基于已有的对话摘要和最新一轮的对话，更新摘要，确保涵盖所有尚未解决的关键问题、用户的核心意图以及已达成共识的事实。”
3. 输出：一个新的、更精炼的摘要文本。
4. 使用：当用户提出下一个问题时，我们不再将原始的、可能很长的对话历史扔给模型，而是将“最新的摘要” + “当前问题”作为上下文输入。

优点：

• 高度压缩：能将数十轮对话压缩成一段固定长度的文本，极大地节省了上下文窗口。
• 保留核心信息：通过模型的概括能力，理论上能保留对话的“主旨”和“关键事实”。

挑战与注意事项：

• 信息损耗风险：摘要模型可能会遗漏一些看似次要、但对后续对话至关重要的细节（例如，一个特定的数字、一个精确的时间点）。这被称为“信息蒸馏中的衰减”。
• 累积误差：摘要是一轮一轮迭代更新的，任何一轮摘要产生的小偏差，都可能随着迭代被放大，导致后续摘要偏离原始对话的轨道。
• 成本与延迟：每一轮对话都需要额外调用一次摘要模型，增加了API调用成本和响应延迟。

实操心得：摘要法非常适合任务导向型对话，比如客服场景，核心是跟踪“问题状态”（待解决、已解决）和“关键参数”（订单号、故障代码）。为摘要模型设计一个结构化的提示词模板，要求它按“待办事项”、“已确认信息”、“用户偏好”等字段输出，能显著提升信息保留的准确性。

2.2 思路二：基于向量检索的压缩（Retrieval-Based）

这种方法借鉴了检索增强生成（RAG）的思想。它不再维护一个连贯的摘要，而是将每一轮对话（或更细粒度的对话片段）都转换为向量，存入一个向量数据库中。

1. 存储：对话进行中，将每一轮的用户消息和助手回答（或合并为一个片段）通过嵌入模型（Embedding Model）转化为向量，并存入向量库，同时保留原文。
2. 检索：当用户提出新问题时，将当前问题也转化为向量，然后在向量库中进行相似度检索。
3. 压缩：取出与当前问题最相关的 K 条历史对话片段（例如，相似度最高的前3-5条）。
4. 使用：将这 K 条检索到的历史片段（原文）与当前问题拼接，作为上下文输入给大模型。

优点：

• 按需取用：极度灵活，模型每次看到的都是与当前问题最直接相关的历史片段，无关内容被彻底过滤。
• 保留原文：提供的是原始对话文本，避免了摘要可能带来的信息扭曲。
• 可解释性强：你可以清楚地知道模型做出回答是基于哪几条历史记录。

挑战与注意事项：

• 丢失全局连贯性：模型可能看不到对话的完整演进过程。例如，用户在第一轮说“我喜欢蓝色”，在第五轮说“不过那个蓝色的不好”，如果第五轮的问题检索不到第一轮，模型就无法理解这个转折。
• 检索可能失败：如果当前问题的表述方式与历史片段差异很大，或者涉及需要多轮推理才能关联的信息，简单的向量检索可能会漏掉关键上下文。
• 上下文组装：检索出的多条片段如何排序、如何拼接成一个连贯的上下文，需要精心设计（如按时间顺序）。

实操心得：对于开放域、话题跳跃的聊天场景，检索法比摘要法更合适。关键点在于嵌入模型的选择和检索策略的优化。除了单纯的向量相似度，可以结合一些元数据（如对话轮次的时间戳）进行加权。对于重要但可能检索不到的信息（如用户设定的系统角色），可以采用“固定前缀”的方式强制保留在上下文中。

2.3 思路三：混合策略与启发式规则

在实际项目中，纯用一种策略往往不够，需要混合使用，并辅以一些启发式规则。

• 摘要 + 检索：维护一个全局摘要来保持主线连贯，同时用检索来获取当前问题所需的细节。例如，上下文由[系统指令] + [全局摘要] + [检索到的相关历史片段] + [当前问题]组成。
• 关键信息提取：在对话过程中，主动识别并结构化地提取关键实体（人名、地点、产品名、数字、日期等）和用户意图（查询、比较、投诉、预订），将这些结构化信息作为“记忆核心”保留，比纯文本摘要更可靠。
• 最近优先（Last-N）与令牌滑动窗口（Token Sliding Window）：这是两种简单但有效的基线方法。
  • 最近优先：无条件保留最近 N 轮对话的完整原文。这假设了“最近的对话最重要”。实现简单，在对话话题集中时效果不错。
  • 令牌滑动窗口：保证上下文总令牌数不超过 M。当新增对话导致超限时，从最旧的历史开始逐轮或逐片段删除，直到满足要求。这保证了上下文的“新鲜度”，但可能突然删掉一个很久以前提出但尚未解决的核心问题。

方案选型背后的考量： 选择哪种或哪几种策略组合，取决于你的应用场景：

• 成本敏感型：可能优先考虑启发式规则（如Last-N），虽然粗糙但零额外成本。
• 任务关键型（如法律、医疗咨询）：需要极高的事实准确性，混合策略（摘要+关键信息提取+检索）是更稳妥的选择，尽管实现复杂。
• 体验优先型（如开放域聊天）：检索法或混合策略能提供更灵活、更相关的响应。
• 技术栈限制：如果没有可用的嵌入模型或向量数据库，摘要法或规则法可能是唯一切实可行的起点。

3. 核心实现：一个基于摘要与检索的混合方案实战

下面，我将以一个虚拟的“智能旅行规划助手”为例，拆解一个中等复杂度的混合压缩方案实现。我们假设主模型使用 GPT-4，上下文窗口为 8K tokens。

3.1 系统架构设计

我们的系统将包含以下核心模块：

1. 对话记忆管理器：负责维护三种记忆：系统指令（固定）、全局摘要（可更新）、向量记忆库（存储所有轮次）。
2. 摘要生成器：一个专用的、轻量化的模型（例如 GPT-3.5-Turbo），用于迭代更新全局摘要。
3. 检索器：使用嵌入模型（如text-embedding-3-small）和向量数据库（如ChromaDB或Pinecone）。
4. 上下文组装器：根据策略，从各个记忆模块中抽取内容，组装成最终发送给主模型的提示词。

数据流：

用户输入 -> 记忆管理器 -> 检索器（从向量库找相关历史） -> 上下文组装器（组合：系统指令 + 全局摘要 + 检索结果 + 当前输入） -> 主模型 -> 助手回复 -> 摘要生成器（更新全局摘要） -> 记忆管理器（将本轮对话存入向量库）

3.2 关键模块实现细节

3.2.1 摘要生成器的提示词工程

这是摘要法的灵魂。一个糟糕的提示词会导致摘要信息量不足或跑偏。

基础版提示词：

你是一个对话摘要助手。请根据之前的对话摘要和最新一轮对话，生成一个更新的对话摘要。 之前的摘要： {previous_summary} 最新一轮对话： 用户：{latest_user_input} 助手：{latest_assistant_response} 更新摘要要求： 1. 浓缩对话的核心主题和目标。 2. 保留关于人物、地点、时间、偏好、约束条件等所有关键事实和细节。 3. 如果最新对话澄清或改变了之前的信息，以最新信息为准。 4. 如果有关键待决事项或未回答问题，请明确指出。 5. 摘要语言应简洁、客观，使用第三人称。 请直接输出更新后的摘要，不要添加任何解释。

进阶优化：为了让摘要更结构化、便于后续利用，我们可以要求模型输出 JSON 格式。

...（同上）... 请以JSON格式输出更新后的摘要，包含以下字段： { “core_topic”: “对话的核心主题”， “confirmed_facts”: [“事实1”, “事实2”, ...], // 已确认的信息列表 “user_preferences”: [“偏好1”, “偏好2”, ...], // 用户表达的偏好 “open_issues”: [“待解决问题1”, “待解决问题2”, ...], // 未决事项 “action_items”: [“需执行的动作1”, ...] // 下一步行动 }

结构化摘要使得“检索”和“信息提取”变得更加容易和精确。

3.2.2 检索器的实现与优化

单纯的向量相似度检索在对话场景下可能不够。

1. 分块策略：不要简单地将一整轮对话作为一个向量。可以将一轮对话拆分为“用户消息”和“助手消息”两个独立的片段进行存储。这样，当用户问一个关于之前助手回答的细节问题时，更容易被检索到。
2. 元数据增强：为每个向量片段附加元数据，如round_number（轮次）、speaker（说话者）、timestamp。在检索时，可以给较新的轮次更高的权重。
3. 查询重写：直接使用用户的当前问题作为查询，可能无法有效召回历史片段。可以对当前问题进行“重写”，使其更适用于检索。例如，利用大模型将“它怎么样？”在上下文中重写为“你之前推荐的‘东京皇家花园酒店’怎么样？”
4. 混合搜索：结合向量相似度搜索和基于元数据的关键词过滤（如过滤出所有包含“预算”关键词的历史片段）。

# 伪代码示例：一个增强的检索函数 def retrieve_relevant_history(current_query, vector_store, conversation_context): # 1. 查询重写（可选） rewritten_query = llm_rewrite_query(current_query, conversation_context) # 2. 执行向量搜索 vector_results = vector_store.similarity_search(rewritten_query, k=5) # 3. 基于元数据过滤和重排序（例如，优先显示“助手”提供的、且较新的信息） filtered_results = [] for doc in vector_results: metadata = doc.metadata # 计算一个综合分数：相似度分 + 新鲜度分 + 说话者分 score = doc.score # 向量相似度得分 score += (metadata['round_number'] / 100.0) # 简单的新鲜度加分，轮次越大越新 if metadata['speaker'] == 'assistant': score += 0.1 # 助手提供的信息可能更结构化，给予轻微加分 filtered_results.append((score, doc)) # 按综合分数排序 filtered_results.sort(key=lambda x: x[0], reverse=True) # 返回top-k的原文内容 return [doc.page_content for _, doc in filtered_results[:3]]

3.2.3 上下文组装与令牌预算管理

这是最后也是最关键的一步。我们需要将来自不同来源的内容，拼装进有限的上下文窗口。

1. 设定预算：假设主模型上下文窗口为 8000 tokens。我们需要预留一部分给模型的输出（如 1500 tokens），那么输入上下文的最大令牌数约为 6500。
2. 分配预算：
   • 系统指令：固定，约 200 tokens。
   • 全局摘要：动态，但我们会限制其最大长度（如 500 tokens）。如果摘要过长，则进行截断。
   • 当前用户问题：动态，假设平均 100 tokens。
   • 检索到的历史片段：这是最大的变数。我们需要一个动态装配算法。

动态装配算法（贪心法）：

def assemble_context(system_prompt, global_summary, current_query, retrieved_snippets, max_input_tokens=6500): context_parts = [] current_token_count = 0 # 1. 加入系统指令（必须） system_tokens = count_tokens(system_prompt) context_parts.append(("system", system_prompt)) current_token_count += system_tokens # 2. 加入全局摘要 summary_tokens = count_tokens(global_summary) if current_token_count + summary_tokens <= max_input_tokens: context_parts.append(("summary", global_summary)) current_token_count += summary_tokens else: # 摘要都放不下，说明预算极紧，只能截断摘要 truncated_summary = truncate_tokens(global_summary, max_input_tokens - current_token_count) context_parts.append(("summary(truncated)", truncated_summary)) return format_context(context_parts) # 直接返回，没有空间给历史了 # 3. 按相关性顺序，尝试加入检索到的历史片段 for snippet in retrieved_snippets: snippet_tokens = count_tokens(snippet) if current_token_count + snippet_tokens <= max_input_tokens: context_parts.append(("history", snippet)) current_token_count += snippet_tokens else: break # 空间不足，停止添加 # 4. 最后加入当前问题 query_tokens = count_tokens(current_query) # 理论上，当前问题必须能放下，否则应报错。这里我们做强制保证。 if current_token_count + query_tokens > max_input_tokens: # 极端情况：移除一部分已加入的历史片段，直到能放下当前问题 while context_parts and context_parts[-1][0] == "history" and (current_token_count + query_tokens > max_input_tokens): removed_part = context_parts.pop() current_token_count -= count_tokens(removed_part[1]) context_parts.append(("query", current_query)) # 5. 将所有部分格式化成模型接受的提示词格式（例如，ChatML格式） return format_to_chatml(context_parts)

这个算法确保了最重要的信息（系统指令、当前问题）被优先保留，其次是全局摘要，最后是检索到的细节历史。它动态地利用了可用的令牌空间。

4. 实操陷阱与性能调优指南

在实际部署中，你会遇到许多在纸面上看不到的问题。以下是我踩过坑后总结出的关键点。

4.1 摘要质量的评估与迭代

你怎么知道生成的摘要是好的？这是一个主观且困难的问题。

• 人工评估黄金标准：初期，必须人工抽查。设计一个检查清单：
  • 是否遗漏了关键事实（如预算从5000改成了7000）？
  • 是否错误地合并或扭曲了信息？
  • 待办事项列表是否准确？
  • 摘要的流畅度和连贯性如何？
• 自动评估指标（代理指标）：虽然不完美，但可以辅助监控。
  • 关键实体召回率：从原始对话中提取一套关键实体（如地点、日期、产品名），看它们在摘要中出现的比例。
  • 与后续回答的相关性：用一个轻量模型判断，基于摘要生成的回答，与基于完整历史生成的回答，在语义上是否相似。
• A/B测试：在真实用户流中，对比使用压缩上下文和完整上下文（在窗口允许的情况下）的对话质量指标，如任务完成率、用户满意度评分。

4.2 检索失败的处理

检索不是万能的，必须设计降级方案。

1. 设置相关性阈值：如果检索到的所有片段，其相似度分数都低于某个阈值（如0.7），则认为本次检索“未找到强相关历史”。此时，可以回退到仅使用“全局摘要”，或者使用“最近N轮”作为保底。
2. 缓存机制：对于高频或关键话题，可以将其摘要或关键信息加入一个“长期记忆”或“缓存”区域，这个区域的信息在检索时拥有更高的优先级或权重。
3. 用户显式引用：鼓励用户在提问时进行显式引用，如“关于你刚才说的酒店…”。系统可以识别这种模式（通过正则或简单模型），直接去查找最近几轮中助手提及“酒店”的片段。

4.3 成本与延迟的平衡

压缩本身是为了节省成本（更短的上下文），但压缩过程（摘要、检索）又引入了新的成本。

• 异步与批处理：摘要生成和向量存储不必在响应用户的同步路径中进行。可以在收到助手回复后，异步触发这些后台任务。这样不影响本次响应速度，只为下一次对话做准备。
• 模型选型：摘要模型不必与主模型一样强大。对于许多场景，GPT-3.5-Turbo甚至更小的开源模型（如Mistral-7B）在指令遵循下都能生成合格的摘要，成本大幅降低。
• 冷启动与预热：在对话刚开始的几轮，历史很短，直接使用完整历史即可，无需启动压缩流程。可以设定一个触发阈值（如历史令牌数 > 2000 或对话轮次 > 3）再开启压缩。
• 监控与告警：密切监控摘要API和嵌入API的调用量、延迟和错误率。设置告警，当压缩模块出现异常时，能自动降级到简单的“最近N轮”模式，保证服务可用性。

4.4 一致性与幻觉问题

这是最棘手的问题之一。压缩可能导致模型“看到”的信息不一致，从而引发幻觉。

• 场景：历史中用户说“我对花生过敏”。在摘要中，这句话被简化为“用户有食物过敏”。后续用户问“这个蛋糕我能吃吗？”，检索没有找到原始对话。模型可能基于“食物过敏”这个模糊信息，错误地推断出“用户可能对奶制品过敏”，从而给出错误警告。
• 缓解策略：
  1. 关键信息锁定：对于识别出的绝对关键信息（如过敏史、重要日期、合同条款），不进入摘要压缩流程，而是将其放入一个“受保护事实列表”，这个列表每次都必须包含在上下文中。
  2. 提供引用来源：在组装上下文时，对于检索到的片段，可以标注其来源，如[来自第3轮用户消息]。并指示模型：“对于事实性信息，请优先依据提供的原文片段。”这能在一定程度上约束模型。
  3. 模型自检：在最终输出前，可以增加一个步骤，让模型对自己回答中涉及的关键事实，检查是否与提供的上下文有明确依据。但这会进一步增加复杂度和成本。

5. 进阶思考：超越技术，关注体验

实现一个能运行的上下文压缩模块只是第一步。要让它在产品中真正创造价值，我们必须从用户体验的角度来审视它。

压缩应该是隐形的。用户不应该感知到“压缩”过程的存在。他们只会觉得这个AI助手记忆力很好，始终能抓住重点。如果你的压缩策略导致助手突然“忘记”了十分钟前自己说过的话，或者反复确认已经确定的信息，体验就会非常糟糕。因此，压缩算法的稳定性和可靠性，比压缩率本身更重要。

允许用户干预。提供一种方式，让用户可以手动“钉住”某条信息，告诉助手“这个很重要，请记住”。这相当于用户直接参与了记忆管理，能极大提升在复杂对话中的掌控感和最终结果的准确性。例如，一个“标记重要信息”的按钮，被标记的内容将免于被压缩或删除。

为失败设计。再好的算法也有出错的可能。当系统检测到可能因压缩导致信息矛盾或丢失时（例如，用户说“你刚才不是这么说的”），应该有一个优雅的回退或澄清机制。比如，助手可以回答：“我可能遗漏了一些细节。您指的是我们之前讨论的关于XX的那部分吗？我们可以再确认一下。” 这比硬着头皮给出一个错误的答案要好得多。

持续迭代的依据是用户反馈。不要只依赖技术指标。建立反馈渠道，收集用户对于助手“记忆力”的直接评价。哪些对话场景下用户觉得助手“健忘”？哪些场景下又觉得它“啰嗦”或“抓不住重点”？这些真实的反馈是优化你的压缩策略、调整摘要提示词、改进检索算法的最宝贵输入。

最终，大模型多轮对话自动上下文压缩，不是一个一劳永逸的工程组件，而是一个需要与你的产品、你的用户、以及大模型本身的能力共同演进的核心系统。它没有标准答案，只有最适合你当前场景的权衡与选择。从简单的“最近N轮”开始，逐步引入更智能的机制，持续观察、测量、调整，你就能搭建出一个在长对话中依然可靠、智能的AI交互体验。