多轮对话上下文管理实战：从预算分配到记忆策略的完整优化指南

年初我们把基于大模型的 Chatbot 接进客服入口本以为能直接兑现“智能对话”的承诺结果用户第一波反馈就给了我们当头一棒上午刚确认过“订单号 88012”下午回来再问进度机器人像失忆了一样反问“您还没有提供订单号”用户上一轮刚说过“不要香菜”下一轮推荐套餐里又出现了香菜。这类“断片”现象非常多原因不在模型智商而在多轮对话系统的上下文处理做得不够扎实。大模型没有天然的“记忆”每一次生成都基于当前请求上下文一旦组织不当Chatbot 的体验会立刻崩。这篇复盘想完整讲清楚我们团队在 20.4 版本里的做法从上下文窗口的预算计算、历史记忆管理到服务化部署时的前缀缓存和回归评测所有方案都是被生产环境验证过的。适合正在做智能客服、Chabot 或大模型 Agent 的开发者参考尤其是那种已经跑通了单轮问答、却在多轮场景里反复翻车的团队。1. 先回到起点Chatbot 忘了“订单号”之后我们决定重写上下文模块1.1 三个典型的“断片”现场多轮对话做不好用户端看到的问题五花八门但归纳起来无非三类。第一类是完全失忆。用户之前已经提供过关键信息比如订单号、地址、出生日期模型在后面几轮又重复询问。这类问题最伤体验因为用户会觉得“你根本没有在听我说话”。第二类是前后矛盾。用户明确说“我不吃辣”模型后面推荐菜色时却推荐了一道川菜用户说“我今天没有时间打电话”模型却反复建议电话沟通。第三类是时间漂移。用户隔了半小时甚至一天后再回来模型已经分不清哪些是旧信息、哪些是当前意图甚至把旧需求和新需求混在一起生成回答。站在大模型的视角看这些问题其实都不神秘。模型服务端的 API 是无状态的每次请求都只看到当前传过去的 prompt它不知道十分钟前发生过什么。即便你用的是同一个模型、同一个账号只要不把历史消息重新拼进 prompt模型的“记忆”就是零。换句话说多轮对话能力的核心不是模型本身多聪明而是应用层能不能把“历史”以合理的方式重新呈现给模型。1.2 问题收敛不是模型不行而是上下文工程不到位我们一开始走了不少弯路总以为是模型选型不对从 7B 模型换到 14B再换到更强的闭源模型结果长对话场景依然崩。后来把线上 badcase 逐条拉出来看才发现八成问题都出在 prompt 组装上——要么历史消息塞得太满模型分不清主次要么关键信息被截断要么系统提示词和用户消息混杂在一起模型不知道该遵循哪条指令。所以 20.4 版本在需求层面就定了基调把“上下文管理”当成一个独立模块来设计而不是让业务代码临时拼字符串。这个模块要回答三个问题哪些信息必须永远保留哪些信息可以丢弃历史太长时如何压缩以及内存中的会话状态如何与外部存储同步。这个模块也成了后续所有优化工作的地基后面聊的滑动窗口、摘要记忆、语义召回都是在这套设计上长出来的。1.3 20.4 版本的目标边界版本迭代最容易犯的毛病是“什么都想做”。20.4 的需求评审会上产品和算法团队提了一堆想法包括情绪识别、多意图分发、语音合成、知识图谱问答。最后我们砍到只剩一个核心目标在不超过上下文预算的前提下把多轮会话的“连续性”和“一致性”拉到一个可量化的水位上。边界定清楚之后做决策就容易了。哪些功能进 20.4能直接提升用户“记得住”体验的进。哪些不进与上下文无关的锦上添花功能全部排到下个版本。这个克制很关键因为上下文优化的效果需要靠评测数据验证一锅炖的版本根本说不清是哪个改动带来了提升。2. 给上下文做预算Token 计算、窗口分配和“超限降级”策略2.1 先把上下文窗口当成一张资产负债表很多团队接手多轮对话时第一个疑问是“历史消息最多存多少轮”。这个问题问错了方向正确的问法是“每次请求的上下文预算有多少”。大模型 API 会限制上下文窗口比如 8k、32k、128k但这不意味着你可以把整个窗口全部用来装历史消息。窗口内部还包含系统提示、工具定义、检索结果、当前用户输入以及模型输出预留空间。我习惯把上下文窗口看成一张资产负债表总窗口大小是总资产输出长度是刚性负债系统提示和工具定义是固定资产历史消息才是可变库存。如果一段对话历史有 6000 token系统提示 800 token工具定义 1200 token当前用户输入 300 token模型输出你至少要留 1000 token那 8k 的窗口就已经用了 9300直接超额。此时无论模型多聪明都只能靠截断救命而截断往往会牺牲关键信息。实际操作中每个会话请求都应该先做一次 token 预算检查。我们封装了一个独立的上下文构造函数输入是 session_id输出是“可以发给模型的 message 数组”和“预计消耗的 token 数”。构造完成后如果预算超限就触发降级逻辑而不是直接把超长数组发给模型等接口报错再补救。2.2 系统提示、历史消息、工具结果如何分账不同业务对上下文的占用结构完全不一样但有一个分配比例可以参考上下文组成部分预算占比说明系统提示词10%-15%角色设定、固定规则尽量精炼历史消息40%-60%多轮对话记忆的主要载体工具/检索结果10%-20%如果接入了 RAG 或函数调用当前用户输入5%-10%本轮用户意图模型输出预留20%-30%防止回答被 max_tokens 截断这套比例是经验值但它背后有两个原则值得讲清楚。第一系统提示词要精炼不要把所有业务规则都堆进去很多规则可以下放到“最近一轮用户输入”或“工具结果”里动态注入。第二模型输出预留不能低于 20%否则用户会频繁看到“回答到一半戛然而止”这种体验比模型不回答更糟糕。还有一点很多人忽略token 计数不能用len(text)必须用模型自己的 tokenizer。中文场景下一个汉字大约占 0.6 到 1 个 token英文一个单词约 1 到 1.5 个 token不同模型的切分规则差异很大。我们最初用字符数估算结果离线算得挺好上线后频繁超限最后统一换了官方 tokenizer 做硬校验。2.3 超限之后不是报错而是降级不遵守预算的结果就是上下文超过限制后模型服务直接抛错或者被框架强行截断导致回答质量崩坏。在 20.4 里我们把“超限降级”做成了一条完整链路处理顺序是先丢旧消息再做摘要最后丢弃非核心工具日志。具体来说当 token 预算超限时第一步是移除最早的非关键消息保留最近 N 轮和所有“关键信息槽位”。第二步如果还超则把更早的历史通过摘要压缩成一段文本。第三步如果仍然超则删除工具日志、中间步骤等次优先级字段。这套降级不是等到超限才临时想而是在上下文构造函数里内置了“预检”机制超限前就按优先级调整。这里必须强调一个反直觉的结论大模型上下文窗口越大不代表你可以用得越满。很多模型在省电目的下训练了长上下文但接近窗口上限时注意力分布会明显退化幻觉概率上升回答开始答非所问。所以我们内部约定实际使用量不超过窗口上限的 80%剩余 20% 作为安全冗余既防超限也保质量。你可以在压测时试着把历史塞到 90%、95%大概率会看到模型开始“胡言乱语”那个临界点就是你要避开的雷区。3. 攻克上下文短板的三种记忆方案滑动窗口、摘要压缩和语义召回3.1 方案 A滑动窗口加“关键信息固定”最朴素的上下文管理方案是滑动窗口系统提示固定在开头后面跟最近 N 条历史消息。但 N 不能按“条数”算要按 token 算。我们封装了一个函数从最新消息往前累加 token加到预算上限就停止然后把剩下的历史全部丢掉。这个方案适合短对话一旦对话轮次变多纯窗口截断很容易把重要信息切走。解决办法是引入“关键信息固定”在做上下文构造之前先对整段对话做一次槽位抽取把订单号、用户姓名、偏好、地址、售后进度等关键字段提取出来以结构化形式放在历史窗口最前面。槽位抽取可以用规则也可以用模型。20.4 项目里我们参考了 OneKE 这类知识抽取框架用抽取模型做实体抽取和关系抽取把用户意图和关键实体从冗长对话中分离出来。这样做的价值在于用户说“我的订单号是 88012帮我查一下物流”历史里可能有两百字废话但槽位只记“order_id: 88012”模型不需要在整段历史里找信息上下文效率高得多。3.2 方案 B会话摘要把长历史“折叠”成一段话光靠滑动窗口解决不了很长的会话。这时可以用摘要方案当历史消息超过阈值调用模型把已有历史压缩成一段 200 字左右的摘要新消息到来时把摘要加在最近几轮历史前面而不是完整历史。摘要位置很讲究一般放在 system prompt 之后、最近对话之前让它充当“长期记忆”的角色。每触发一次摘要就意味着消耗一次额外推理所以不能让摘要太频繁。我们设置的触发条件是“历史消息 token 数超过总预算的 30%”触发后把旧消息折叠成摘要保留最近几轮完整消息。这里有一个实操教训摘要模型不要用太小的模型如果压缩质量差订单号、日期这类关键信息非常容易丢。我们内部规定摘要必须保留五类信息用户身份、时间节点、关键数值、明确偏好、未完成事项。即便摘要机读不出太长上下文也要保证这五类不丢。摘要方案并不是万能的。角色扮演类对话、情感支持类对话用户往往希望模型记住细节摘要后细节就没了。这种情况只能用检索方案补救也就是下一种方案。3.3 方案 C基于检索的历史召回让无关内容不进上下文语义召回的思路很简单既然全量历史塞不下那就只把与当前问题最相关的历史片段召回出来。我们把用户会话按“消息对”切分每条切片做 embedding 向量化入库新用户问题到来时用问题向量去召回 Top K 相关片段再把片段注入上下文。这个方案在处理话题跳跃时特别好用。用户聊到第 30 轮突然问“我前面说的发票抬头是怎么回事”滑动窗口早就把第 5 轮的发票信息丢了摘要里也没有这么细的内容但检索模块能直接命中那一段模型就能给出正确回答。检索方案工程上要注意三点。第一切片别太小单条消息召回往往缺乏上下文最好按两轮到三轮合并成一个切片。第二向量库选型上单机场景用轻量级方案生产环境需要支撑高并发读取的组件。第三召回结果要带时间顺序拼进 prompt 前先按会话时间排序不要让模型读到乱序历史。20.4 里的数据流是这样的原始消息写入会话数据库异步任务生成向量并写入向量库请求到达后先用向量库召回相关片段再与滑动窗口合并成最终 prompt。3.4 多策略串联的工程实现以 LangGraph 内存机制为例三种方案不是互斥的20.4 最终采用的是“槽位抽取 摘要压缩 语义召回 滑动窗口”的四层结构槽位永远保留摘要作为长期记忆召回补充细节滑动窗口承接最近话题。在工程实现上我们当时用了 LangGraph 作为对话状态编排框架。LangGraph 自带 Checkpointer 机制可以保存整个对话状态。调试阶段用InMemorySaver很方便数据只保存在内存里适合写 Demo但它不是给生产环境设计的进程一重启状态就没了。生产环境我们换成了 Redis 或 Postgres 的持久化 saver让多实例服务共享同一份会话状态。从InMemorySaver取历史时一个常被问到的点是“历史怎么传给大模型”。其实只要从 checkpointer 的 state 里取出messages再交给上下文构造函数做预算控制不能让全量消息直接进入模型。很多人出错就是因为把state[messages]原封不动传给 LLM结果长对话必然超限制。记住一点LangGraph 管的是对话状态流转不是上下文裁剪裁剪是你的业务逻辑。4. 用户交互体验的隐性瓶颈流式输出、系统指令和错误恢复4.1 流式输出是“时间体验”的刚需多轮对话不只是内容要准响应速度的体感也非常重要。同样一段回答如果用户等 10 秒才有反应即便内容再正确体验也是不及格的。这就是流式输出的价值。我们用 SSE 做流式响应后端通过FastAPI的StreamingResponse持续返回 token 片段前端逐字展示。流式方案有几个细节要注意第一流式生成过程中不要把中间结果写入历史库等完整消息生成后再写入否则存储里全是半截话第二如果用户中途中断请求后端要捕获断开事件把已经生成的部分做一次“截断清理”避免把未完成内容当作最终消息第三首字延迟比整体延迟更影响体感如果模型迟迟不吐第一个 token前端要展示“正在思考中”的状态提示。4.2 把系统提示词当成“常驻角色设定”系统提示词是影响多轮一致性的关键。20.4 项目里我们做了一个很严格的约定所有固定角色、固定规则、业务边界都放系统提示词所有动态信息都放在历史消息或最新用户输入里。这条约定表面上是个规范化动作实际上它对后面的前缀缓存优化也至关重要后面会讲。很多团队习惯把当前用户问题也拼到系统提示词里比如“用户说我要退款”。这会让系统提示词每轮都变化破坏前缀稳定性。正确的做法是系统提示词只做“角色规则输出约束”比如“你是某电商平台的客服助手回答需要礼貌不要编造订单状态”。用户当前的问题正常放在最后一条 user 消息里。系统提示词还应该包含一个“自我纠错指令”。我们会加一句“如果你不确定用户历史信息请直接向用户确认不要猜测”。这句话能显著降低模型乱编历史的概率尤其当历史确实被截断时模型会更倾向于发起澄清提问而不是瞎编。4.3 输入纠偏与“我不懂”兜底在多轮对话系统里用户的输入往往不像评测集那么规范。有人会连续点击“重试”有人会在一句话里塞多个问题也有人会用否定句修正之前的回答。这些输入如果不做预处理模型很容易在错误方向上狂奔。20.4 版本把“否定修正”单独拎出来处理。识别到用户消息里出现“不对”“不是这样”“改成”“重新说”等否定词时我们先把否定意图更新到用户偏好槽位比如“不吃辣true”而不是让模型自己从历史里猜。这个过程本质上是把一部分语义理解下沉到前置模块虽然会增加一次轻量模型调用但多轮对话的稳定性提升非常明显。另外我们在后端捕获了三种异常模型超时、模型返回空内容、模型生成重复片段。针对超时我们做了一层带指数的退避重试重试时给 prompt 增加一句“你上一次没有回答完整请继续”避免模型从零开始针对重复片段后处理会检测连续 3 个相同 n-gram 并从那里截断。5. 部署与性能调优从本地版到服务化的上下文缓存实践5.1 用 vLLM 前缀缓存提高上下文重复命中率多轮对话的请求天然存在大量重复前缀同样一段 system prompt同样的历史消息会在每一轮新请求里重复出现。如果我们能把重复前缀的计算结果缓存下来服务端就能大幅降低首 token 延迟。vLLM 提供了 prefix caching 功能默认会缓存 KV 状态。开启后当一个新请求包含与之前请求相同的前缀时vLLM 可以跳过前缀部分的 prefill 阶段直接复用缓存结果把 TTFT首 token 时间降下来。我们在 20.4 项目里的实测数据是开启前缀缓存后长对话场景的首 token 时间从 1.8 秒左右降到 0.3 到 0.5 秒体感提升非常大。但前缀缓存要生效有个前提prompt 前缀必须稳定。这也是前面反复强调“系统提示词不要每轮变化”的原因。如果系统提示词里拼接了当前时间、随机 code、用户输入前缀缓存会频繁失效命中率掉得很惨。我们内部用固定三段式 promptsystem prompt 长期记忆块 最近对话块除了最后一段前面两段尽量保持稳定缓存命中率能维持在 90% 以上。5.2 并发、超时和指数退避别让上下文管理拖垮服务多轮对话服务化之后问题往往会从模型能力转移到工程层面。单轮请求处理时间本来就长多轮对话又频繁触发摘要、检索等额外调用后端很容易出现线程池被占满、数据库连接被耗尽的情况。20.4 项目里我们做了三个硬性约束。第一所有外部调用大模型、向量库、知识库都要显式设置超时大模型推理最长 30 秒检索最长 500 毫秒任何一环超时都不阻塞主流程。第二并发数要做信号量限制否则 20 个用户同时发起长对话GPU 直接打满后面的请求全部排队体验彻底崩坏。第三重试逻辑统一用指数退避第一次等 1 秒第二次 2 秒第三次 4 秒最多重试 3 次避免瞬时洪峰把下游打挂。关于服务端上下文这里容易踩一个坑在 FastAPI 里用全局变量保存会话上下文。多用户并发时全局变量一定会串话。正确做法是把上下文按 session_id 存储或使用请求级的依赖注入。contextvars可以用来传递 request_id 和用户身份但要注意后台任务在请求结束后再访问 contextvars很可能拿不到值因为上下文已经释放了。5.3 本地模型部署的选型参考Ollama / vLLM / 千问系列20.4 的服务化后端最终接了两套推理方案一套是开发调试用的本地 Ollama一套是生产环境用的 vLLM。两者定位完全不同。Ollama 胜在简单一条命令就能拉起模型支持 Modelfile 自定义系统提示、温度等参数。它适合团队早期验证、并发量很小的场景也适合单机 Demo。但 Ollama 默认的并行能力较弱高并发下吞吐很容易触顶所以不建议直接暴露到生产环境除非你的业务量很小。vLLM 是我们在生产环境的选择核心优势是 PagedAttention 和 Continuous Batching能显著提高 GPU 利用率加上前缀缓存能力与多轮对话场景非常匹配。模型方面我们主要用千问系列做本地部署中文理解和生成质量稳定社区资料多调参踩坑时能找到不少参考。选型不是越贵越好。如果业务只需要几十个并发一张消费级显卡加 Ollama 完全够如果用户量超过几百还是老老实实上 vLLM 做服务化再配合负载均衡和自动扩缩容。用一张表总结我个人的选型建议场景推荐方案原因本地实验、单机 DemoOllama 量化模型上手快资源占用低百级以下并发生产vLLM 单卡/双卡PagedAttention 提升吞吐百级以上并发、多轮长会话vLLM 集群 前缀缓存缓存收益明显可横向扩展6. 升级有没有用要用数据说话多轮对话回归评测6.1 构造多轮评测集把回话场景写出来没有评测集就做优化等于闭着眼睛开车。20.4 项目开工第一天评测团队就在写多轮对话剧本总共构造了 15 个典型场景每个场景包含 6 到 20 轮不等。这些场景不是凭空捏造的全部来自客服历史工单。举几个例子。剧本 A用户先咨询订单状态中间吐槽物流慢最后问退款政策模型需要在最后回复里引用之前的订单号。剧本 B用户明确说“不吃辣”中间咨询了三个菜最后问“你刚才推荐了哪个菜”模型要能追忆。剧本 C用户纠正了模型之前给出的错误答案模型道歉并给出新答案。评测集的意义不只是量化优化效果它还能逼着团队把“连续性”“一致性”这些模糊概念变成可判定的问题。每个剧本都附带了评分标准比如“模型是否正确复述订单号”“模型推荐菜色是否包含辣椒”评分人哪怕是刚入职的实习生也能按标准打分。6.2 抓三个维度连续性、一致性、任务完成率回测时我们主要看三个指标。第一个是连续性指模型是否正确引用了历史信息。我们会统计剧本中关键信息被再次提问时的准确回忆率。第二个是一致性指模型回答是否与历史中的偏好、约束自洽。第三个是任务完成率指用户最终目标是否被满足比如“用户是否得到了退款政策答案”。除了主指标我们也会记录上下文 token 中位数、平均每次请求的检索延迟、前缀缓存命中率。之前一直强调“上下文越短越稳定”在 20.4 回归测试里也有数据支撑通过槽位固定和摘要压缩上下文中位数从 8.6k token 降到 3.2k token连续性评分却从 76 提高到 88。这说明压缩并不是牺牲质量换成本反而因为去掉了噪声模型更聚焦了。评测链路中我们也尝试用大模型当裁判给剧本自动打分。大模型裁判可以节省大量人工时间但它偶尔会和人类标准不一致所以我们的底线是每次发布前核心剧本必须人工评审大模型裁判结果只做辅助参考。6.3 上线后的真实反馈和迭代节奏20.4 版本上线后我们又在生产环境加了几个监控指标平均每会话的请求轮数、用户发消息后放弃率、差评率。这里有一个很典型的迭代过程上线第一周流失率确实降了但新增的 badcase 集中在“模型突然改口”比如用户说“不对我上次说的是明天”模型不仅没理解还坚持己见。这类问题的根源是模型把“用户的否定”当成普通聊天而不是必须执行的修正指令。我们随后在关键信息槽位里增加了“否定标记”字段凡是被用户否定过的历史信息后续组装上下文时直接标记为无效不让模型继续参考。这一改一致性指标又往上拉了 5 个点。迭代节奏上我们固定每周跑一次回归每两周出一次版本。每次做上下文策略调整都要求记录上下文构造前后 diff方便回滚和复盘。多轮对话优化的特点就是这样单个改动看起来都很小但叠加起来体验差异非常大。回看 20.4 整个过程我个人最深的体会是多轮对话系统不是一个“加个记忆功能”就能解决的问题它是一个系统性工程。上下文预算、历史压缩、语义召回、缓存优化、评测回放每一个环节都互相咬合。如果你也想优化自家的 Chatbot我建议从“上下文预算表”开始做起先搞清楚每一次请求到底有多少 token 花在了哪里再谈后面那些花里胡哨的策略。把这个基础打牢后续每一步优化才会走得稳。