1. 项目缘起当AI对话开始“失忆”最近在折腾一个AI智能客服的Demo想把用户和客服的历史对话记录喂给大模型让它能基于上下文给出更连贯的回复。一开始我直接把最近10轮对话的原始文本拼接起来一股脑塞给了模型。头几次效果还不错但随着对话轮次增加问题来了要么是提示词超长了API直接报错要么是模型开始“胡言乱语”把前面用户提的需求A和后面客服的回复B给张冠李戴了。这其实就是典型的“上下文窗口”限制问题。你可以把大模型的上下文窗口想象成一个固定大小的“工作记忆白板”。无论是GPT-4、Claude还是国内的一些主流模型这个白板的大小都是有限的比如常见的4K、8K、16K、32K tokens。当你把超长的对话记录、文档内容直接塞进去不仅会挤占掉真正用于思考和生成答案的空间更严重的是模型在处理超长文本时对中间部分信息的理解和记忆能力会显著下降这种现象有时被称为“中间迷失”。所以直接堆砌原始消息是不可行的。我们需要一种方法既能保留对话的核心信息和关键细节又能大幅缩减其占用的token数量。这就是“上下文摘要”技术登场的时刻。它不是一个简单的“删除不重要句子”的操作而是一个由AI驱动的、理解性的信息压缩过程。本次分享的就是我在这个Demo项目中如何一步步实现并优化这个“AI摘要压缩”功能的全过程。2. 核心思路从“存档记录”到“动态摘要”在动手写代码之前我们先要理清思路。上下文摘要的目标不是生成一份供人类阅读的会议纪要而是为后续的AI对话生成一份高质量的“记忆提纲”。这份提纲需要满足几个核心要求保真性不能歪曲原意。用户说“我要退上个月买的蓝色衬衫因为它尺码不对”摘要里必须保留“退货”、“蓝色衬衫”、“上个月”、“尺码问题”这些关键实体和意图。信息密度要用最精炼的语言概括。将“用户表达了不满认为商品质量与描述不符希望全额退款并补偿运费”这样的描述压缩为“用户因商品与描述不符要求退款并索赔运费”。结构清晰对于多轮对话最好能体现出对话的演进脉络。例如区分“用户初始需求”、“客服已提供的信息”、“待解决的问题”。面向模型友好摘要的最终消费者是另一个AI。因此语言应保持客观、简洁避免过多情感修饰词并可以适当结构化如使用关键词、列表。基于这些要求我放弃了简单的规则匹配如提取实体词或传统文本摘要模型决定直接使用大模型自身的能力来完成这项任务。这形成了一个有趣的递归用AI来为AI的对话生成摘要。具体流程设计如下触发机制不是每轮对话都摘要那样开销太大。我设置了两个触发条件一是当累积的对话token数接近上下文窗口限制的某个比例如70%时二是当对话自然告一段落例如一个用户问题被解决开启新话题时。摘要对象将到目前为止的所有历史对话或自上一次摘要以来的所有新对话作为输入。摘要指令设计一个特定的“系统提示词”System Prompt明确告诉模型摘要的目的、格式和要求。更新上下文用生成的新摘要替换掉被摘要的那部分原始对话历史。这样上下文中就保留了从对话开始到现在的“压缩版记忆”再加上最新的几轮原始对话继续后续的交互。这个思路将静态的、不断膨胀的聊天记录变成了一个动态的、持续演进的“摘要流”从而在有限的上下文窗口内实现了对长程对话信息的有效管理。3. 实战步骤构建摘要生成管道接下来我们进入实操环节。我将以 OpenAI API (GPT-3.5-Turbo/GPT-4) 为例展示如何搭建这个管道。其他平台的模型如 Claude、文心一言、通义千问等在接口调用上大同小异核心在于提示词的设计。3.1 环境准备与消息结构定义首先确保你已安装必要的库并设置好API密钥。pip install openai在代码中我们需要规范对话消息的结构。通常与Chat Completion API交互的消息是一个字典列表每个字典包含role(系统、用户、助手) 和content。import openai import tiktoken # 用于计算token非常重要 import json # 设置你的API密钥 openai.api_key your-api-key-here # 初始化一个全局的对话历史列表 conversation_history [ {role: system, content: 你是一个有帮助的客服助手。} ]tiktoken库是OpenAI官方提供的token计算工具准确计算文本占用的token数是控制成本、判断何时触发摘要的关键。3.2 设计摘要生成的系统提示词这是整个功能的核心灵魂。一个糟糕的提示词会导致摘要失真或信息丢失。经过多次调试我最终使用的提示词框架如下SUMMARY_SYSTEM_PROMPT 你是一个专业的对话摘要AI。你的任务是将一段用户与AI助手的多轮对话历史压缩成一个简洁、准确、信息密度高的摘要。 请遵循以下规则生成摘要 1. **绝对忠实**摘要必须完全基于提供的对话内容不得添加任何未提及的信息不得曲解任何一方的意图。 2. **提取核心**聚焦于用户的核心需求、问题、关键事实如订单号、产品名、时间、数字、以及AI助手给出的关键答复或已采取的行动。 3. **忽略琐碎**省略问候语如“你好”、“谢谢”、重复的表述、以及未产生实质进展的来回确认。 4. **结构化组织**如果对话涉及多个主题或问题请在摘要中清晰区分。使用“用户需求”、“已解决事项”、“待办事项”等小标题如需要。 5. **使用中性语言**摘要语言应客观、简洁使用第三人称。例如“用户反馈商品存在划痕要求换货。客服已核实情况并提供了换货流程链接。” 6. **保留关键引用**对于重要的决定、承诺或特定信息如“客服承诺24小时内回复”应在摘要中明确保留。 7. **输出格式**直接输出摘要文本不要添加“摘要”这样的前缀。 本次需要摘要的对话历史如下 这个提示词明确了角色、任务、具体规则和输出格式。其中“结构化组织”和“保留关键引用”是针对后续AI消费而特别设计的能让新的模型快速抓住重点。3.3 实现摘要生成函数现在我们创建一个函数它接收一段对话历史调用API并返回生成的摘要。def generate_summary(dialogues_to_summarize, modelgpt-3.5-turbo): 生成对话历史的摘要。 :param dialogues_to_summarize: 需要摘要的对话消息列表 :param model: 使用的模型gpt-3.5-turbo性价比高gpt-4摘要质量更稳 :return: 摘要字符串 # 构建本次摘要请求的完整消息 messages_for_summary [ {role: system, content: SUMMARY_SYSTEM_PROMPT}, {role: user, content: json.dumps(dialogues_to_summarize, ensure_asciiFalse)} ] try: response openai.ChatCompletion.create( modelmodel, messagesmessages_for_summary, temperature0.1, # 温度设低确保摘要稳定、可重复 max_tokens500 # 控制摘要长度根据实际情况调整 ) summary response.choices[0].message.content.strip() return summary except Exception as e: print(f生成摘要时出错: {e}) # 降级策略如果摘要失败返回一个最基础的拼接版本 fallback .join([f[{msg[role]}]: {msg[content][:50]}... for msg in dialogues_to_summarize[-3:]]) return f摘要生成失败保留最近三条记录: {fallback}这里有几个关键点temperature0.1摘要任务要求高度一致性和准确性低温度值能减少模型的随机性使输出更稳定。max_tokens500限制摘要的长度防止模型生成过于冗长的内容违背了压缩的初衷。异常处理与降级策略网络或API可能不稳定必须有备选方案。这里简单截取最近三条记录保证服务不中断。3.4 实现对话管理与摘要触发逻辑这是最复杂的部分需要管理整个对话状态并在合适的时机调用摘要函数。class AIConversationManager: def __init__(self, context_window_size4000, summary_trigger_ratio0.7): self.context_window context_window_size self.summary_trigger_ratio summary_trigger_ratio # 达到窗口容量的70%时触发 self.history [] # 存储完整的原始历史用于追溯 self.compacted_history [] # 存储用于上下文的“压缩后历史” self.encoder tiktoken.encoding_for_model(gpt-3.5-turbo) # 选择编码器 def _count_tokens(self, messages): 计算一组消息占用的token数 total 0 for msg in messages: total len(self.encoder.encode(msg[content])) total 4 # 每个消息的role和content等元数据大约占用4个token total 2 # 每次请求的开销 return total def _needs_summary(self, new_messages): 判断是否需要触发摘要 # 模拟将新消息加入当前上下文后的总token数 current_context self.compacted_history new_messages estimated_tokens self._count_tokens(current_context) return estimated_tokens (self.context_window * self.summary_trigger_ratio) def add_interaction(self, user_input, ai_response): 添加一轮新的用户-AI交互 user_msg {role: user, content: user_input} assistant_msg {role: assistant, content: ai_response} new_pair [user_msg, assistant_msg] self.history.extend(new_pair) # 完整历史永远保留 # 检查是否需要摘要 if self._needs_summary(new_pair): print(上下文即将满载触发摘要生成...) # 选择需要被摘要的旧对话部分通常是compacted_history中除最近一两轮外的所有内容 to_summarize self.compacted_history[:-2] if len(self.compacted_history) 2 else self.compacted_history if to_summarize: summary generate_summary(to_summarize) # 用摘要替换旧对话 summary_msg {role: system, content: f【历史对话摘要】{summary}} self.compacted_history [summary_msg] self.compacted_history[-2:] new_pair else: # 如果没有旧对话可摘要直接添加新对话 self.compacted_history.extend(new_pair) else: # 不需要摘要直接添加到压缩历史 self.compacted_history.extend(new_pair) print(f当前压缩历史长度消息数: {len(self.compacted_history)}) print(f估计Token占用: {self._count_tokens(self.compacted_history)}) def get_context_for_next_round(self): 获取用于下一轮对话生成的完整上下文 return self.compacted_history这个管理器的核心逻辑在于add_interaction方法永远保存完整的self.history供追溯。在添加新对话前检查当前压缩历史加上新对话后是否触及触发阈值。如果触发则选取compacted_history中“较老”的部分除了最近一两轮因为最近的最重要需要保持原貌进行摘要。用生成的摘要包装成一个system消息替换掉那些被摘要的旧消息并与最新的原始对话拼接形成新的compacted_history。这样上下文始终由“一份不断更新的摘要” “最近的原始对话”构成总长度被有效控制。3.5 集成与测试最后我们将这个管理器集成到主对话循环中。def main_conversation_loop(): manager AIConversationManager(context_window_size4000) # 初始系统提示词 system_prompt {role: system, content: 你是一个有帮助的客服助手请根据对话历史回应用户。} manager.compacted_history.append(system_prompt) print(客服AI已就绪。输入‘退出’结束对话。) while True: user_input input(\n用户: ) if user_input.lower() 退出: break # 1. 准备上下文 context_messages manager.get_context_for_next_round() # 2. 调用AI生成回复这里模拟一个简单的回复 # 实际应调用 openai.ChatCompletion.create ai_response simulate_ai_response(context_messages, user_input) print(fAI助手: {ai_response}) # 3. 将本轮交互添加到管理器 manager.add_interaction(user_input, ai_response) def simulate_ai_response(context, user_input): 模拟AI生成回复实际项目中替换为真实的API调用 # 这里只是简单模拟实际需要调用模型 return f我已理解您的意思‘{user_input}’。当前对话历史中有 {len(context)} 条消息。 if __name__ __main__: main_conversation_loop()通过这个循环一个具备自动上下文摘要能力的对话系统就搭建起来了。随着对话进行管理器会自动在后台进行摘要压缩确保上下文长度可控。4. 避坑指南与优化策略在实际测试中我遇到了不少坑也总结出一些优化方向。4.1 摘要的“信息损耗”与关键细节保留最大的挑战是如何在压缩中不丢失关键细节。最初我的提示词比较笼统导致模型有时会省略掉具体的数字如订单号、金额、时间承诺“24小时内”或特定的用户选择“要蓝色而不是黑色”。解决方案在提示词中明确强调。我在SUMMARY_SYSTEM_PROMPT的规则2和6中特别加入了“关键事实如订单号、产品名、时间、数字”和“保留关键引用”。更进一步可以在提示词中举例说明“例如如果用户说‘我的订单号是123456昨天收到的’摘要中必须包含‘订单号123456’和‘昨天收到’。”4.2 摘要的“主观性”与客观性保障即使温度设为0.1模型在概括时仍可能带入轻微的主观解读或语气变化。例如用户说“这产品不太好用”模型可能摘要成“用户对产品表示失望”。虽然意思接近但“失望”是模型推断的情绪并非用户原话。解决方案在提示词规则1中强调“绝对忠实”和“不得添加任何未提及的信息”。同时可以在生成摘要后设计一个简单的“事实核对”步骤例如从摘要中提取实体产品名、编号等反向检查是否在原文中出现过。对于高要求场景可以使用更小的、专门训练过的摘要模型或在生成后加入人工审核环节对于关键业务。4.3 触发策略的权衡频率与成本摘要本身也需要消耗API调用和token。如果触发太频繁比如每轮对话后成本会急剧上升且可能打断对话流畅性。如果触发太晚可能已经遭遇了上下文窗口溢出或模型性能下降。我的经验阈值法如代码所示设置一个token占用率阈值如70%是平衡成本和效果的好方法。话题切换检测可以加入简单的语义分析当检测到用户开启一个全新话题例如从“退货咨询”突然跳到“新品推荐”时主动触发对前一话题的摘要。这可以通过计算用户输入与历史对话的向量相似度来实现相似度低则可能意味着话题切换。混合策略结合阈值法和固定轮次法例如每10轮对话强制摘要一次作为兜底策略。4.4 摘要的“可逆性”与历史追溯用摘要替换原始消息后原始信息就“丢失”了。如果后续对话需要引用非常早的、已被摘要的某个细节可能会出现问题。解决方案永久存储如代码中的self.history永远在后台保存完整的原始对话记录。这主要用于审计和追溯。摘要链每次摘要时不仅生成当前段的摘要还可以选择性地将前一次的摘要也作为输入的一部分生成一个能串联起更长时间线的“超级摘要”。但这会增大提示词复杂度。按需检索当AI在回答过程中如果需要更早的细节可以设计一个机制从永久存储中检索相关片段临时插入上下文。这涉及到检索增强生成RAG的技术是更高级的解决方案。4.5 模型选择与成本考量GPT-3.5-Turbo vs GPT-4GPT-3.5-Turbo摘要速度更快、成本更低在大多数情况下足够可靠。GPT-4的摘要质量更高、更稳定尤其擅长处理复杂逻辑和长文档但成本也高得多。建议从GPT-3.5-Turbo开始在关键业务或对摘要质量要求极高的场景再考虑GPT-4。专用摘要模型市面上有一些开源的、参数更小的文本摘要模型如BART、PEGASUS。如果对话内容非常领域化如法律、医疗且对可控性和成本有极高要求可以尝试微调这些专用模型。但这就需要准备训练数据、拥有GPU资源入门门槛较高。5. 效果评估与扩展思考实现这个功能后最直观的感受是对话的“续航能力”大大增强。在客服Demo中模拟长达50轮的复杂咨询AI助手依然能准确记得用户在最初几轮提供的订单信息和核心诉求而不会出现“失忆”或混淆。评估摘要效果我主要看三点压缩比摘要后的文本token数通常是原始对话的10%-30%效果显著。信息保真度随机抽查摘要让另一个AI或人工判断摘要是否准确反映了原始对话的核心事实和意图。下游任务性能这是终极测试。用摘要后的上下文继续对话看AI的回复质量是否与使用原始完整上下文时无明显下降甚至因为去除了噪音而有所提升。这个“AI摘要上下文”的模式其应用远不止于智能客服。它可以被用于长文档问答将超长PDF或报告分段摘要再将摘要串联起来供模型理解全文脉络。会议记录助手实时摘要多方会议讨论形成动态的会议纪要。代码审查对话在漫长的代码讨论中持续摘要已发现的问题和达成的共识帮助新加入的评审者快速跟上。个人记忆外脑持续摘要你与AI的日常对话形成一份不断增长的、高度浓缩的个人知识库。本质上这是一种让大模型突破其固有上下文窗口限制的“外挂”记忆管理策略。它承认了模型的局限性并巧妙地利用模型自身的能力来克服它。在构建需要长期记忆或处理长文本的AI应用时这几乎是一个必备的组件。