RAG客服系统：多轮对话上下文管理

可视化演示

观察多轮对话历史的存储结构、上下文窗口的token预算管理，以及超限时的摘要压缩策略，理解RAG客服系统保持对话连贯性的机制，可切换三种模式。

上下文管理基础

想象张姐在餐厅门口迎接李小姐。李小姐第一句是“来一份宫保鸡丁，少油少盐”，张姐在记事本写下“宫保：少油少盐”。十分钟后李小姐又说“花生换腰果”，张姐如果忘了前面的“少油少盐”，这道菜就毁了。多轮对话客服机器人面对的就是这个场景：用户前前后后说过的话，构成了回答当前问题的决定性地基。没有这些“前情”，机器人就像一个每隔五分钟失忆一次的服务员，每句话都像第一次见面。

在RAG客服系统中，这个“前情”有正式名称——上下文。它的本质是按时间顺序累积的全部对话消息。多轮对话之所以难，是因为每轮发言都在修改整个对话的状态：用户可能在第二句话里否定了第一句话里的需求，也可能用“它”“这个”来指代前面提到的物品。只有把每轮消息都当作记忆单元保存下来，后续的推理和检索才有依据。这就是为什么上下文管理不是可选项，而是多轮客服系统的地基。

从技术实现看，系统用一个按时间排列的消息集合表示当前对话的全部状态。这个集合会被送入大语言模型，用来生成符合语境的回话；也会被用来改写检索查询，让RAG能从知识库中找到更准确的材料。但集合不能无限膨胀——模型的上下文窗口（最大能同时处理的token数量）就是记事本的页数上限。理解这个约束，是掌握后续所有管理策略的前提。

张姐的记事本虽然写满了密密麻麻的字，但每一笔都是顾客真实的需求。上下文管理的起点，就是意识到这些记忆单元值得被认真记录——只有理解了“要记什么”，后面才能谈“怎么存、怎么压缩”。

上下文存储机制

张姐一晚上要服务十几桌客人，如果所有订单都写在同一页上，必然乱成一锅粥。她的做法是：给每桌发一个桌号，A1桌的宫保鸡丁写在A1的卡片上，B2桌的麻辣香锅写在B2的卡片上，互不干扰。客服系统里的“桌号”就是会话ID——一个唯一标识，把不同用户的对话隔离开，防止张姐把李小姐的少油少盐记到隔壁王先生头上。

有了会话ID，接下来就是怎么组织消息。最直白的方式是消息列表：每当用户或客服说一句话，就按照时间顺序追加到该会话的列表末尾。这就像张姐在每张卡片上按顺序记下“顾客说→我说→顾客又说”。但问题来了：一桌客人聊上两小时，卡片写满了怎么办？于是有了滑动窗口算法——只保留最近L条消息，更早的要么丢弃、要么压缩。这相当于张姐每隔一段时间就把卡片最上面几行旧笔记撕掉，只留下最近几轮的关键内容。

在实际工程中，这些状态还需要持久化存储。用户可能在半夜两点问了问题，第二天早上又回来继续说，系统必须能从数据库重新载入那桌的“卡片”。常见方案是把会话ID、消息列表和摘要一起存入Redis或数据库中，用会话ID作为主键。这样即使服务器重启，张姐换了个新人班，也能照着旧卡片继续接待顾客。

张姐的卡片系统看似简单，却解决了“桌桌隔离”和“本子有限”两大难题。但光会存还不够，顾客有时会用“它”来指代前文，这时张姐就得翻旧账才能搞明白——这正是下一节要讲的上下文与RAG检索的配合。

上下文增强RAG

李小姐盯着菜单又问：“那它和昨天那道香辣虾比，哪个更适合老人？”这里的“它”显然指宫保鸡丁。如果张姐不翻前面的记事本，后厨根本不知道要对比什么。RAG客服系统同样会遇到这句话，它需要把“它”改写成“宫保鸡丁”，再补上“少油少盐、腰果替换花生”这些背景，生成一个全新的查询去检索知识库。这个动作就是查询改写。

查询改写只是第一步。客服系统还可以把整个上下文历史向量化——把每条消息转换成一组数字向量，存进向量数据库。当用户问新问题时，系统既能用关键词去匹配知识库，也能用语义相似度去匹配历史消息，再把两类结果合并。这种混合检索策略，就像张姐既翻自己的记事本，又去问后厨师傅，两边的信息都拿到手才敢下单。

检索回来的结果还需要重排序。张姐从记事本和后厨收集到一堆信息，比如“宫保鸡丁的辣度分级”“腰果过敏注意事项”“老人饮食推荐”，她会按与当前问题的相关程度排个序，把最相关的放在最前面。RAG系统同样用重排序模型给检索结果打分，只把排名靠前的内容拼进给大模型的提示词中。这样一来，多轮对话的上下文就真正“喂”给了检索和生成两个环节。

张姐的绝活在于“结合上下文去查证”——既记得每桌客人的偏好，又懂菜品的知识。RAG客服系统具备同样的能力后，用户的每一句“它”“那个”都不再是谜语，而成了可追踪、可检索的具体线索。

上下文压缩策略

周末晚上餐厅爆满，张姐的记事本快不够用了。她灵机一动，把“宫保鸡丁，少油少盐，花生换腰果，加一碗米饭”简化成“宫保：少油低盐，腰果替花生”。这样一来，四个记忆单元合并成一句话，本子空出一大片。这种把多条历史消息提炼成精练摘要的操作，正是上下文压缩策略的核心。

压缩不能蛮干。假如张姐把所有细节都丢掉，只写“顾客点了菜”，那等于没记。工程上常用的策略有三种：摘要压缩（用大模型把长对话总结成几句话）、关键信息提取（只抽取实体和意图，如菜品名、忌口、数量）、智能截断（优先保留最近几轮和带明确需求的对话）。更进一步，还可以引入遗忘机制，给每条消息算一个“重要度分数”，分数低的自动降权或移出窗口。

设计评分函数时，系统通常综合三个因素：与当前话题的相关性、是否带来新信息、消息的长度。相关性高的消息要保留，重复寒暄可以丢；提出新需求的要留，只是附和“嗯嗯”的可删；太长的消息可能被摘要替代。这就像张姐记笔记时，重点记顾客的偏好变化，而不是顾客说的每一句客套话。

张姐的记事本越用越薄，但含金量越来越高。压缩不是简单的删除，而是把信息“提纯”。经过压缩的上下文，既保住了顾客的忌口，又为后面的检索腾出了空间，让客服机器人在长对话中依然保持高准确度。

上下文管理挑战

最让张姐头疼的客人是那种边打电话边说菜、边刷手机边改需求的话痨型顾客，聊上半小时，记事本换了三页。多轮对话发展成超长对话后，第一个挑战就是上下文窗口溢出：模型的窗口是固定的，消息却越来越多，就像记事本永远不够用。如果窗口装不下，系统就得在“丢掉旧信息”和“拒绝新问题”之间做两难取舍。

第二个挑战是信息丢失的连锁反应。压缩时手一抖，把“不要香菜”扔进了垃圾桶，结果上菜时顾客脸都绿了。在RAG客服系统中，信息丢失不只是体验问题，还可能造成严重业务后果：金融客服忘了用户已经确认的风险等级、医疗导诊忘了患者的过敏史，都可能导致错误引导。压缩永远在“节省空间”和“保留关键事实”之间走钢丝。

第三个挑战是延迟与成本。如果每次用户提问都把全部历史消息送给大模型重新处理，一来模型输入暴涨，响应变慢；二来费用直线上升。好比张姐每次接单都把整本记事本从头读一遍，客人早就等得不耐烦了。此外还有状态一致性问题：当多个服务器并发处理同一段对话时，A服务更新了窗口，B服务还在用旧状态，就会像两个服务员同时对一桌客人记了两本不一样的账。

面对这些挑战，张姐没有选择辞职，而是总结出一套服务高手的打法：提前预判、勤做标记、多桌并发管理。RAG客服系统也一样，接下来我们看看性能优化如何把这四个难题逐个击破。

性能优化实践

张姐服务十桌客人依然游刃有余，靠的不只是记忆好，更有一套省力的工作流。她会把“宫保鸡丁的通用做法”这种反复用到的信息记在活页夹里，而不是每次客人点菜都重新去后厨问一遍。客服系统里的活页夹就是缓存机制——把高频检索结果、常用回复模板和用户画像提前缓存，命中时直接取用，省去重复计算。

第二招是索引优化。张姐给每桌卡片贴上标签，绿色代表“有忌口”，红色代表“催得急”，找的时候一眼定位。对应到RAG客服系统，就是为向量库建立高效的近似最近邻索引（如HNSW），为消息列表建立时间戳索引，让“找某段历史”从翻遍全本变成翻目录瞬间定位。第三招是并发控制。客流高峰期，张姐会先把点菜单按桌号排好队，一件件处理；系统同样用队列和分布式锁来协调同一会话的读写，避免两个请求同时修改窗口导致状态错乱。

最后，张姐每天打烊后都会复盘：哪桌的记忆断了导致上错菜？哪类记录其实根本用不上？客服系统也需要监控评估——记录上下文压缩后的信息保留率、缓存命中率、平均响应延迟，以及用户“重复提问率”（用户因为机器人忘了前情而重新解释同一需求的比例）。这些指标就是系统健康的体温计。

打烊之后，张姐整理好记事本，把新学到的菜品知识和客人偏好归档。RAG客服系统同样在优化中不断成长：缓存让响应变快，索引让检索变准，并发控制让高峰不乱，监控让问题无处遁形。做好这四件事，一个“记得住、答得快、忘不丢”的智能客服才算真正合格。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""RAG客服系统多轮对话上下文管理器"""from collections import deque  class ContextManager:    """管理多轮对话的滑动窗口与摘要压缩"""     def __init__(self, max_window=3, summary_len=2):        # 使用 _map 后缀避免与 get_or_create 方法冲突        self.session_map = {}        self.max_window = max_window        self.summary_len = summary_len     def get_or_create(self, session_id):        if session_id not in self.session_map:            self.session_map[session_id] = {                "history": deque(maxlen=self.max_window),                "summary": "",                "turn_count": 0            }        return self.session_map[session_id]     def add_message(self, session_id, role, content):        ctx = self.get_or_create(session_id)        ctx["turn_count"] += 1        ctx["history"].append({"role": role, "content": content})        if len(ctx["history"]) == self.max_window:            self._compress(ctx)     def _compress(self, ctx):        old_lines = []        for msg in ctx["history"]:            prefix = "用户" if msg["role"] == "user" else "助手"            old_lines.append(prefix + ":" + msg["content"][:15])        ctx["summary"] = "；".join(old_lines[:self.summary_len]) + "。"        ctx["history"].clear()     def build_prompt(self, session_id, query):        ctx = self.get_or_create(session_id)        parts = []        if ctx["summary"]:            parts.append("历史摘要：" + ctx["summary"])        for msg in ctx["history"]:            name = "用户" if msg["role"] == "user" else "助手"            parts.append(name + "：" + msg["content"])        parts.append("用户：" + query)        return "\n".join(parts)  if __name__ == "__main__":    cm = ContextManager(max_window=3)    cm.add_message("A100", "user", "我想买一台办公笔记本")    cm.add_message("A100", "assistant", "请问预算大概多少？")    cm.add_message("A100", "user", "5000左右，要轻薄")    cm.add_message("A100", "assistant", "推荐联想小新Pro 14")    cm.add_message("A100", "user", "那它续航怎么样？")    prompt = cm.build_prompt("A100", "有货吗？")    print(prompt)

1. self.session_map = {}用字典保存所有会话状态，会话ID就是“桌号”，避免不同用户互相干扰。
2. deque(maxlen=self.max_window)双向队列自动滑动窗口，超出的旧消息被挤出，就像张姐撕掉过时的笔记。
3. ctx["history"].append(...)每条新消息追加到当前会话末尾，保持严格的时间顺序。
4. len(ctx["history"]) == self.max_window当窗口填满时触发压缩，防止无限膨胀。
5. ctx["summary"] = "；".join(...)把旧消息拼成一句摘要，实现“丢细节、留重点”的压缩策略。
6. ctx["history"].clear()清空已压缩的旧消息，为后续对话腾出窗口空间。
7. build_prompt把摘要、历史消息和当前问题拼接成最终提示词，供大模型和RAG系统使用。
8. "历史摘要：" + ctx["summary"]摘要放在最前面，让模型第一时间获得对话背景。

常见误区

面试题