context-mode这个词我关注它挺久了。最近在做一个 AI 对话类应用的时候被这个功能折腾得够呛一开始以为不就是把聊天记录多传几轮嘛真正做进去才发现这里面的坑比想象中多得多。如果你也在做聊天机器人、AI 助手或者任何需要记住上下文的产品这篇东西应该能帮你少走不少弯路。我尽量把从设计思路到代码实现再到线上踩坑的完整过程都写清楚照着做不敢说一步到位但至少能让你避开我趟过的那些雷。1. 为什么需要 context-mode先搞清楚你在解决什么问题1.1 AI 应用的失忆症到底从哪来市面上大多数大语言模型LLM本身就是无状态的。什么意思就是你每次调用 API模型都是从头开始理解你的问题它不知道你五分钟前问过什么也不知道你在这个对话框里已经输入过三页纸的背景信息。这不是模型笨而是它的设计机制决定的——模型的注意力机制只在单次请求内生效请求结束这次对话的所有中间状态就清零了。但是用户在真实使用场景里几乎不会只用一句话跟 AI 交流。比如你在用 AI 写一份市场分析报告第一轮你说帮我梳理一下行业背景第二轮你说再结合刚才的行业背景整理竞争格局第三轮你说把前面两部分整合成 PPT 大纲。如果 AI 没有记忆第二轮它就只能看到一句孤零零的再结合刚才的行业背景它怎么知道你刚才说的是什么结果就是你得把第一轮的内容重新复述一遍甚至复述得不够准确AI 给出的回答就会跑偏。这就是失忆症的根源模型无状态但用户的工作流是有状态的。context-mode 要解决的说白了就是把这个状态从用户脑子里搬到程序里替用户记住该记住的东西。我最初做这个功能的动机特别朴素——用户在我的应用里反馈最多的就是怎么越聊越傻我刚才不是说了吗你怎么又忘了这类反馈本质上都是上下文丢失导致的。1.2 context-mode 与普通对话模式的本质区别很多人以为 context-mode 就是把聊天记录全部塞给模型这其实是最大的误解。普通对话模式下应用只是简单地把用户最后一句话发给模型模型基于这句话单独生成回复。而 context-mode 下应用做的是上下文组装——把系统预设、历史对话、检索到的相关资料、用户当前问题按照一定的策略和优先级组装成一个完整的请求再发给模型。两者的差别打个比方就很好理解普通模式像一个新来的实习生你每次交代任务都只给一句话他做完就忘下一次你再交代他还得从头问起context-mode 像一个带笔记本的老员工你跟他聊过什么他都记着你一个继续说他就知道接着哪个话题往下说你问刚才那个方案还有没有别的问题他能立刻定位到你指的是哪个方案。所以 context-mode 的本质不是多传几轮历史记录这个简单动作而是一整套关于信息的筛选、组织、压缩和更新机制。我做完这个功能之后回头总结它其实包含三个核心环节记忆的采集怎么记录、记忆的筛选哪些该进上下文、记忆的更新进不了上下文的怎么处理。这三个环节任何一个做不好context-mode 都会变成鸡肋甚至拖后腿的功能。2. context-mode 的整体设计思路2.1 上下文到底该由哪些部分构成在设计 context-mode 之前我先把上下文这个概念拆解了一遍。所谓上下文并不只是聊天记录。在实际的 AI 应用里一份完整的上下文至少包含四层信息第一层是系统预设也叫 System Prompt。这一层是给模型定调的规定了它的角色、语气、能力边界、输出格式要求。这层信息跟具体对话无关是常量但也是上下文的基础底座。第二层是历史对话记录。这是大多数人理解中的上下文即用户和 AI 之前的每一轮问答。历史对话决定了模型能否理解当前问题的来龙去脉。第三层是检索增强信息。这一层是可选的如果应用接入了知识库或者 RAG检索增强生成那么跟当前问题相关的文档片段、数据库查询结果也应该被组装进上下文。这层信息能帮模型回答那些不在它训练数据里的问题。第四层是用户当前输入。也就是用户在最新一轮里说的一句话或一段话这是模型的直接指令优先级应该最高。四层信息的组装顺序和权重直接决定了模型输出的质量。我的经验是系统预设放在最前面紧接着是检索到的相关资料然后是压缩后的历史对话最后才是用户当前输入。这样模型在生成回复时能先理解自己的角色和背景资料再结合对话脉络最后聚焦在用户当前问题上。顺着这个顺序模型输出的连贯性是最稳的。2.2 选择什么样的上下文策略把上下文的结构想清楚之后第二个问题是要选择具体的上下文管理策略。我在调研和实测中整理出三种比较主流的方案它们各有利弊适用于不同的场景。第一种是滑动窗口策略。这是最简单直接的方案就是把最近的 N 轮对话塞进上下文更早的一律丢弃。N 的取值取决于你用的模型上下文长度和单轮对话的平均 token 消耗。比如你的模型上下文上限是 8K token平均每轮对话消耗 1K token那 N 取 5 左右比较稳妥。这种策略的好处是实现简单、响应快、成本可控坏处是记忆只有短期用户聊得稍微久一点早期信息还是会丢。第二种是摘要压缩策略。当历史对话超过窗口上限时先把早期对话交给模型做一轮摘要用一个简短的记忆摘要替代原始对话继续留在上下文里。这种策略能保留长期记忆但实现复杂度高而且每次摘要本身也要消耗模型调用和 token延迟和成本都有所上升。第三种是检索增强策略。把所有历史对话向量化存入向量数据库每次用户提问时根据问题的相关性检索出最相关的几段历史对话动态组装进上下文。这种策略最聪明能保留几乎无限期的记忆而且不浪费上下文空间但工程复杂度最高需要维护向量索引和检索服务。我的建议是如果你的应用刚起步、用户单次会话时间普遍不长先用滑动窗口方案它足以覆盖 80% 的场景。如果用户会话深度明显超出窗口范围再叠加摘要压缩。检索增强适合知识库类产品或者需要跨会话记忆的产品不建议一上来就上。2.3 上下文管理的核心指标做 context-mode 不能凭感觉你得有数据来验证效果。我整理了四个核心指标每次调整上下文策略之后都会盯着这几个数据看第一个是单次请求的平均 token 消耗。这个直接关联成本。上下文塞得越多token 消耗越大账单越难看。第二个是平均响应延迟。上下文越长模型处理时间越久。第三个是上下文命中率也就是模型在回答中正确引用历史信息的次数占比这个可以抽样对话记录人工评估也可以让模型自己打分。第四个是用户会话深度看用户平均在一轮会话里能聊多少轮不放弃这是 context-mode 价值的直接体现。上线 context-mode 之后我观察到的数据变化很有意思用户平均会话轮数从原来的 4 轮左右提升到了 9 轮以上听起来很好但同时 token 消耗涨了将近一倍延迟也多了几百毫秒。这就是 context-mode 的甜蜜与代价——它确实提升了用户体验但你不能无视它的成本。后面我在做优化时所有决策几乎都是围绕这四个指标做权衡哪里该省 token哪里该保效果心里有数改动起来就不慌。3. 核心实现细节与实操要点3.1 上下文构建的完整管线理论设计得再好落地才是关键。我实际搭建的 context-mode 上下文构建管线大致分五个步骤每一步都有需要注意的细节。第一步是消息归一化。不管用户的输入来自网页、App 还是 API统一转换成内部的消息结构。我用的结构类似于 OpenAI 的 messages 格式每个消息包含 rolesystem、user、assistant和 content 两个字段。这一步看似简单但很容易踩坑——比如用户上传了图片或者文件你需要先预处理好转成模型支持的格式否则后面组装时会报错。第二步是窗口裁剪。按照设定的滑动窗口大小从历史对话中截取最近 N 轮消息。这里有一个细节裁剪的时候最好保证窗口内最后一条消息是 user 角色这样整个上下文的结尾是落在用户问题上模型生成时能自然衔接。我一开始没注意这个裁剪后的窗口刚好以 assistant 消息结尾结果模型经常在用户还没提问的时候就先回答了一通非常尴尬。第三步是摘要合并。如果窗口裁剪之后还有更早的有价值信息就把它们交给模型生成摘要摘要插入到窗口之前。这一步我单独维护了一个memory字段不跟原始历史消息混在一起方便后续更新。第四步是检索注入。如果启用了 RAG根据用户当前问题去向量库检索相关片段按相似度排序后插入到系统预设和历史对话之间。注入的数量要控制我一般控制在 3 到 5 段太多了会挤占其他信息的空间太少了检索意义不大。第五步是组装请求。把系统预设、检索片段、记忆摘要、裁剪后的历史对话、用户当前输入按顺序拼接加上 max_tokens、temperature 等推理参数形成最终的 API 请求。这五步每一步都不复杂但串起来之后整体逻辑就会清晰很多。我把这套管线封装成了一个独立的模块上层业务只需要调用一个 build_context(user_input, session_id) 函数传两个参数进去就能拿到组装好的请求体。3.2 token 预算与窗口管理Token 预算管理是整个 context-mode 里最容易出问题的地方。模型上下文窗口是硬上限超了直接报错但就算不超窗口被塞得太满模型的处理质量和速度都会明显下降。我采用的 token 预算分配方案是这样的假设模型上下文上限是 8K token我会设置一个 80% 的安全线也就是实际使用不超过 6.4K token留出 20% 给模型生成回复的空间。在 6.4K 的有效预算里系统预设固定占用约 500 token检索片段最多占用 1.5K token记忆摘要占用约 500 token剩余 3.9K 左右全部留给历史对话和用户输入。这里的核心问题是怎么预判一截文本的 token 数量。不同模型的分词方式不一样一个英文单词可能拆成 0.6 到 1.3 个 token一个中文字符大约是 0.6 到 1 个 token 的消耗。最稳妥的做法是直接调用对应模型的 tokenizer 来计算而不是用字符数除以 4之类的粗略估算。我一开始就是偷懒用字符数估算结果组装出来的请求时不时触发超限报错后来老老实实换成模型官方 tokenizer 才稳定下来。窗口管理还有一个要点当历史对话超出窗口时不能简单地从最前面删掉因为最前面的消息往往包含了用户在会话早期交代的重要背景。我的做法是渐进式遗忘——把最早的消息先交给摘要模型生成一段凝练的记忆摘要如果摘要也塞不下了再考虑是否丢弃。这样既控制了 token 占用又尽可能保留了核心信息。3.3 记忆压缩与摘要策略摘要压缩是 context-mode 里最有技术含量的一环。你让模型总结一下之前的对话听着简单做起来全是细节。第一个细节是摘要的粒度。我见过有人只生成一段全局摘要对话内容长了之后这段摘要会变得非常笼统丢失大量细节。我的做法是分层摘要每小时左右生成一个阶段摘要一天左右生成一个天级摘要天级摘要由阶段摘要再压缩而成。需要用到早期记忆时优先取天级摘要如果模型觉得信息不够再往下翻阶段摘要。这种分层结构兼顾了 token 效率和信息密度。第二个细节是摘要的更新策略。用户跟 AI 聊到一半对话又增加了几轮这时候全局摘要不能重新生成——每次都重新生成成本太高。我的做法是采用增量摘要读取已有的记忆摘要结合新增的对话内容让模型生成一份新摘要。这样每次摘要的输入只有新旧两份内容token 开销小得多而且摘要质量比从头生成更稳定。第三个细节是摘要的触发时机。我建议不要每轮都做摘要那样太频繁了。我实测下来的经验是当历史对话超过窗口上限的 60% 时触发一次摘要之后每增加 20% 再触发一次。这个频率既能保证记忆不丢又不会频繁打断主流程。做摘要还有一个隐含的收益它相当于主动帮用户划重点。我发现同样的信息放进摘要里的关键信息比堆在原始历史里的信息在后续问答中对模型的影响权重更高。后来我干脆在摘要指令里加了一句保留与用户目标相关的关键事实和数据效果立竿见影模型对早期关键信息的回忆准确率提升了不少。4. 实操过程与关键环节实现4.1 实现一个最小可用的 context-mode纸上谈兵这么久来点实在的。我分享一套最小可用的实现代码基于 OpenAI 接口但思路是通用的换成其他模型也只需要改调用方式。首先定义消息结构和会话存储。我用 Redis 存历史消息key 是 session_idvalue 是消息列表的 JSON。import json import redis import tiktoken r redis.Redis(hostlocalhost, port6379, db0) def append_message(session_id: str, role: str, content: str): key fsession:{session_id} msg {role: role, content: content} r.rpush(key, json.dumps(msg, ensure_asciiFalse))接下来是核心的上下文构建函数。这里我把 token 计算、窗口裁剪、摘要检查都放进去了逻辑比较完整可以直接抄走改改用。def build_context(session_id: str, user_input: str, system_prompt: str, max_context_tokens: int 5000): enc tiktoken.encoding_for_model(gpt-4) key fsession:{session_id} raw_messages [json.loads(m) for m in r.lrange(key, 0, -1)] # 添加用户当前输入 raw_messages.append({role: user, content: user_input}) # 从后往前裁剪保证上下文不超预算 selected [] total_tokens len(enc.encode(system_prompt)) len(enc.encode(user_input)) for msg in reversed(raw_messages[:-1]): # 排除当前输入先处理历史 msg_tokens len(enc.encode(msg[content])) if total_tokens msg_tokens max_context_tokens: break selected.append(msg) total_tokens msg_tokens selected.reverse() # 恢复正确的时序 messages [{role: system, content: system_prompt}] selected [{role: user, content: user_input}] return messages这段代码的核心思路是从最近的对话往前扫描塞得下就保留塞不下就停止。这样实现的好处是永远不超 token 上限坏处是会丢早期信息。所以紧接着补上摘要逻辑如果发现 raw_messages 里存在被裁剪掉的消息就调用摘要模型把它们压缩进 memory。def summarize_old_messages(old_messages, existing_summary): if not old_messages: return existing_summary content existing_summary \n json.dumps(old_messages, ensure_asciiFalse) prompt f请将以下对话内容压缩为简洁的中文摘要保留与用户目标相关的关键事实和数据\n{content} # 调用模型生成摘要这里省略具体 API 调用代码 return call_llm(prompt, max_tokens500)上面这套实现里最有用的一个设计是system prompt 和 user_input 的 token 是优先保证的无论历史对话怎么裁这两部分永远不被挤掉。因为系统预设决定了模型的能力范围用户当前输入决定了本轮的任务目标这两个是刚需历史对话才是可压缩的内容。4.2 接入 RAG 扩展长期记忆如果你的 context-mode 需要跨会话记忆或者需要结合企业知识库回答问题纯靠摘要是不够的得接 RAG。RAG 的核心是向量检索把文档和对话拆分、向量化、存入向量库查询时用用户问题做语义搜索找到最相关的片段注入上下文。我用的是 OpenAI 的 embedding 接口配合 Chroma 向量库代码量不大import chromadb from openai import OpenAI client OpenAI() collection chromadb.Client().get_or_create_collection(memory_store) def add_to_memory(session_id, text): vec client.embeddings.create(modeltext-embedding-3-small, inputtext).data[0].embedding collection.add( documents[text], embeddings[vec], metadatas[{session_id: session_id}], ids[f{session_id}-{len(collection.get()[ids])}] ) def search_memory(query, session_id, top_k3): vec client.embeddings.create(modeltext-embedding-3-small, inputquery).data[0].embedding results collection.query( query_embeddings[vec], n_resultstop_k, where{session_id: session_id} ) return results[documents][0]接入 RAG 之后context-mode 的构建管线就多了一步先拿用户当前输入去检索相关记忆把检索结果插到系统预设和历史对话之间。这一步的顺序非常关键——检索结果必须放在历史对话前面让模型先看到背景资料再看到对话过程最后看当前问题这样信息层次最清晰。不过 RAG 也不是万能的。我踩过的一个坑是向量检索的结果和当前问题表面相关、实质无关比如用户问报告里的预算部分怎么改检索出来的却是另一份完全无关报告里的预算表。解决的办法是加一层 rerank 重排用模型对检索结果做一次相关性打分过滤掉低质量片段。这个操作会增加一次模型调用但会明显提升注入片段的质量。4.3 实测效果对比代码写完理论说了一大堆最终还是得看实测数据。我整理了一份 context-mode 开启前后的对比数据用的是同一个测试集包含 50 组多轮对话场景。从结果看context-mode 开启后模型的上下文连贯性打分从 3.2 提升到了 4.6满分 5 分历史信息准确引用率从 41% 提升到了 78%。最明显的变化是回答中我不知道你之前说了什么这类问题的大幅减少以及在涉及前文信息的追问中模型给出的回复不再自相矛盾。同时我也记录了代价单轮请求平均 token 消耗从 600 涨到了 2100延迟从 1.2 秒涨到了 2.1 秒。这个增幅在我的场景里是可以接受的但如果你的应用对延迟特别敏感或者模型调用量大就要在上下文长度和成本之间做更精细的平衡可以考虑用更小规模的历史窗口或者对部分请求关闭 RAG 检索。我还做了一组有趣的对比同一段多轮对话分别测试了完整历史注入摘要注入和滑动窗口丢弃早期信息三种策略。完整历史注入的效果最好但 token 消耗最高摘要注入的效果接近完整历史token 消耗降低约 60%性价比最高滑动窗口丢弃早期信息在对话超过 6 轮之后效果明显下滑。所以如果你的模型上下文窗口够大优先用完整历史窗口紧张用摘要注入实在没有摘要能力才退而求其次用滑动窗口。5. 常见问题与排查技巧实录5.1 上下文越界与截断问题我上线 context-mode 后遇到的第一个线上事故就是用户聊到第 20 轮时请求直接抛出了 context length exceeded 的错误。排查过程很有意思因为我明明写了 token 预算控制理论上不该超问题出在哪里后来发现问题出在 max_tokens 的预留上。我的预算算法只算了输入侧的总 token没算输出侧。当用户的单轮输入非常长、或者我用模型生成摘要时消耗了较多输出 token整体就超出了模型硬上限。解决办法是双保险一方面在 build_context 里把系统提示和用户输入也计入预算另一方面在请求层做一次最终校验如果总 token 超过模型上限的 85%就对历史对话做进一步裁剪。另一个容易忽略的细节是不同模型的 tokenizer 不同。我用 gpt-4 的 tiktoken 来估算其他模型的 token结果某些模型实际 token 数比估算高 20% 以上导致隐性越界。后来统一改成用各模型官方 tokenizer 计算再没出过这个问题。5.2 上下文污染与相关性下降上下文越界是明枪上下文污染是暗箭。污染指的是上下文里塞入了太多跟当前问题无关的信息模型反而被这些信息带偏。最典型的一个案例某用户在一轮会话中先聊了旅游攻略又聊了股票投资再问你觉得哪个更值得做。由于 context-mode 把前面所有对话都注入了上下文模型搞不清哪个指的是旅游项目还是股票回答起来左右摇摆。这就是没有做好相关性过滤导致的上下文污染。我的解决方案是给历史对话做相关性标注。在组装上下文时先用轻量级模型对每段历史消息进行相关性分类与当前问题高度相关的保留完整内容中度相关的压缩成一句话不相关的直接丢弃。这样虽然多一步处理但显著提升了模型的回答精准度。实测下来相关性标注能让模型在复杂话题切换场景下的表现提升约 30%。还有一个污染源是系统预设里的冗余信息。有些团队习惯把大段的产品说明、公司介绍塞进 system prompt数量一多就会挤占历史对话的空间。建议定期审查系统预设凡是跟当前任务无关的内容一律移除保持精简。5.3 成本失控与延迟飙升context-mode 是一把双刃剑用好了提升体验用不好钱包流血。我的应用接入 context-mode 的头一周模型调用成本直接翻了一倍多排查下来发现三个原因。第一个原因是摘要触发的频率过高。我最初的设计是每轮对话后都检查是否需要摘要结果在长对话里摘要模型的调用次数比主模型还多。后来改成历史对话超过窗口的 60% 才触发摘要调用量立刻降下来了。第二个原因是检索注入的片段太多。每次检索默认返回 5 个片段但大部分场景下 2 到 3 个片段就够用了。减少注入数量后token 消耗下降明显回答质量几乎没受影响。第三个原因是调试期的日志记录。为了排查问题我把每次请求的完整上下文都打日志了这本身不影响模型成本但日志量巨大间接拖慢了系统。建议日志只记录 token 数量和消息元信息不记录完整内容。延迟方面最有效的优化是预热对高频用户提前构建好上下文并缓存用户发消息时直接取缓存结果省去重复构建的时间。实测能降低 30% 到 50% 的端到端延迟。5.4 排查工具箱做 context-mode 的调试没有趁手的工具真的会崩溃。我推荐几个常用的排查手段都是我在实践中验证过的。第一是上下文可视化工具。把每次请求的上下文导出来逐条查看消息的角色、内容、token 数、来源标记。我写了一个简单的 Python 脚本能统计上下文中每部分系统、检索、历史、当前的占比画成柱状图。一图胜千言很多问题一眼就能定位。第二是 A/B 测试框架。context-mode 的每一项调整都不要直接全量上线。我习惯把用户分成 A/B 两组一组用旧策略一组用新策略观察两组的会话深度、满意度评分、token 消耗变化。用数据说话才能避免上了线又不确定改动是好是坏。第三是黄金对话集。准备 30 到 50 组覆盖典型场景的多轮对话每次改动后跑一遍对比输出质量。这个对话集是人工标注过标准答案的能把感觉变好了变成覆盖率从 72% 提升到了 81%。第四是熔断机制。如果 context-mode 模块出现异常比如异步摘要任务超时、向量库不可用要能自动降级为普通对话模式保证用户体验不中断。我在系统里加了一个开关RAG 服务连续三次超时就自动关闭检索注入只保留历史对话和摘要等服务恢复后再自动开启。这些工具搭起来成本不高但能在关键时刻救你一命。尤其是黄金对话集它帮我在一次代码重构后立刻发现了上下文组装顺序的回归问题如果没有它这个问题可能要线上跑一周才能被用户反馈出来。做 context-mode 这件事我最大的体会是它不是一个一锤子买卖的功能而是一个需要持续调优的系统。别指望上线了就完事用户的对话场景千奇百怪今天你觉得窗口 5 轮够了明天就有个用户在第 8 轮时告诉你你怎么忘了我说过我喜欢简约风格。多留几手后路把摘要、检索、降级机制都准备好遇到问题才有得打。最后再分享一个小技巧context-mode 的调优不要只盯着模型效果也要看用户的行为数据。如果用户在使用 context-mode 后主动说你记得真清楚这类话的频率提升了说明你方向对了反过来如果用户开始大量复制粘贴前文内容说明你的上下文机制还没真正帮到用户。用这些信号来校准你的优化方向比任何指标都真实。
AI应用上下文管理实战：从失忆到记住一切的context-mode
context-mode这个词我关注它挺久了。最近在做一个 AI 对话类应用的时候被这个功能折腾得够呛一开始以为不就是把聊天记录多传几轮嘛真正做进去才发现这里面的坑比想象中多得多。如果你也在做聊天机器人、AI 助手或者任何需要记住上下文的产品这篇东西应该能帮你少走不少弯路。我尽量把从设计思路到代码实现再到线上踩坑的完整过程都写清楚照着做不敢说一步到位但至少能让你避开我趟过的那些雷。1. 为什么需要 context-mode先搞清楚你在解决什么问题1.1 AI 应用的失忆症到底从哪来市面上大多数大语言模型LLM本身就是无状态的。什么意思就是你每次调用 API模型都是从头开始理解你的问题它不知道你五分钟前问过什么也不知道你在这个对话框里已经输入过三页纸的背景信息。这不是模型笨而是它的设计机制决定的——模型的注意力机制只在单次请求内生效请求结束这次对话的所有中间状态就清零了。但是用户在真实使用场景里几乎不会只用一句话跟 AI 交流。比如你在用 AI 写一份市场分析报告第一轮你说帮我梳理一下行业背景第二轮你说再结合刚才的行业背景整理竞争格局第三轮你说把前面两部分整合成 PPT 大纲。如果 AI 没有记忆第二轮它就只能看到一句孤零零的再结合刚才的行业背景它怎么知道你刚才说的是什么结果就是你得把第一轮的内容重新复述一遍甚至复述得不够准确AI 给出的回答就会跑偏。这就是失忆症的根源模型无状态但用户的工作流是有状态的。context-mode 要解决的说白了就是把这个状态从用户脑子里搬到程序里替用户记住该记住的东西。我最初做这个功能的动机特别朴素——用户在我的应用里反馈最多的就是怎么越聊越傻我刚才不是说了吗你怎么又忘了这类反馈本质上都是上下文丢失导致的。1.2 context-mode 与普通对话模式的本质区别很多人以为 context-mode 就是把聊天记录全部塞给模型这其实是最大的误解。普通对话模式下应用只是简单地把用户最后一句话发给模型模型基于这句话单独生成回复。而 context-mode 下应用做的是上下文组装——把系统预设、历史对话、检索到的相关资料、用户当前问题按照一定的策略和优先级组装成一个完整的请求再发给模型。两者的差别打个比方就很好理解普通模式像一个新来的实习生你每次交代任务都只给一句话他做完就忘下一次你再交代他还得从头问起context-mode 像一个带笔记本的老员工你跟他聊过什么他都记着你一个继续说他就知道接着哪个话题往下说你问刚才那个方案还有没有别的问题他能立刻定位到你指的是哪个方案。所以 context-mode 的本质不是多传几轮历史记录这个简单动作而是一整套关于信息的筛选、组织、压缩和更新机制。我做完这个功能之后回头总结它其实包含三个核心环节记忆的采集怎么记录、记忆的筛选哪些该进上下文、记忆的更新进不了上下文的怎么处理。这三个环节任何一个做不好context-mode 都会变成鸡肋甚至拖后腿的功能。2. context-mode 的整体设计思路2.1 上下文到底该由哪些部分构成在设计 context-mode 之前我先把上下文这个概念拆解了一遍。所谓上下文并不只是聊天记录。在实际的 AI 应用里一份完整的上下文至少包含四层信息第一层是系统预设也叫 System Prompt。这一层是给模型定调的规定了它的角色、语气、能力边界、输出格式要求。这层信息跟具体对话无关是常量但也是上下文的基础底座。第二层是历史对话记录。这是大多数人理解中的上下文即用户和 AI 之前的每一轮问答。历史对话决定了模型能否理解当前问题的来龙去脉。第三层是检索增强信息。这一层是可选的如果应用接入了知识库或者 RAG检索增强生成那么跟当前问题相关的文档片段、数据库查询结果也应该被组装进上下文。这层信息能帮模型回答那些不在它训练数据里的问题。第四层是用户当前输入。也就是用户在最新一轮里说的一句话或一段话这是模型的直接指令优先级应该最高。四层信息的组装顺序和权重直接决定了模型输出的质量。我的经验是系统预设放在最前面紧接着是检索到的相关资料然后是压缩后的历史对话最后才是用户当前输入。这样模型在生成回复时能先理解自己的角色和背景资料再结合对话脉络最后聚焦在用户当前问题上。顺着这个顺序模型输出的连贯性是最稳的。2.2 选择什么样的上下文策略把上下文的结构想清楚之后第二个问题是要选择具体的上下文管理策略。我在调研和实测中整理出三种比较主流的方案它们各有利弊适用于不同的场景。第一种是滑动窗口策略。这是最简单直接的方案就是把最近的 N 轮对话塞进上下文更早的一律丢弃。N 的取值取决于你用的模型上下文长度和单轮对话的平均 token 消耗。比如你的模型上下文上限是 8K token平均每轮对话消耗 1K token那 N 取 5 左右比较稳妥。这种策略的好处是实现简单、响应快、成本可控坏处是记忆只有短期用户聊得稍微久一点早期信息还是会丢。第二种是摘要压缩策略。当历史对话超过窗口上限时先把早期对话交给模型做一轮摘要用一个简短的记忆摘要替代原始对话继续留在上下文里。这种策略能保留长期记忆但实现复杂度高而且每次摘要本身也要消耗模型调用和 token延迟和成本都有所上升。第三种是检索增强策略。把所有历史对话向量化存入向量数据库每次用户提问时根据问题的相关性检索出最相关的几段历史对话动态组装进上下文。这种策略最聪明能保留几乎无限期的记忆而且不浪费上下文空间但工程复杂度最高需要维护向量索引和检索服务。我的建议是如果你的应用刚起步、用户单次会话时间普遍不长先用滑动窗口方案它足以覆盖 80% 的场景。如果用户会话深度明显超出窗口范围再叠加摘要压缩。检索增强适合知识库类产品或者需要跨会话记忆的产品不建议一上来就上。2.3 上下文管理的核心指标做 context-mode 不能凭感觉你得有数据来验证效果。我整理了四个核心指标每次调整上下文策略之后都会盯着这几个数据看第一个是单次请求的平均 token 消耗。这个直接关联成本。上下文塞得越多token 消耗越大账单越难看。第二个是平均响应延迟。上下文越长模型处理时间越久。第三个是上下文命中率也就是模型在回答中正确引用历史信息的次数占比这个可以抽样对话记录人工评估也可以让模型自己打分。第四个是用户会话深度看用户平均在一轮会话里能聊多少轮不放弃这是 context-mode 价值的直接体现。上线 context-mode 之后我观察到的数据变化很有意思用户平均会话轮数从原来的 4 轮左右提升到了 9 轮以上听起来很好但同时 token 消耗涨了将近一倍延迟也多了几百毫秒。这就是 context-mode 的甜蜜与代价——它确实提升了用户体验但你不能无视它的成本。后面我在做优化时所有决策几乎都是围绕这四个指标做权衡哪里该省 token哪里该保效果心里有数改动起来就不慌。3. 核心实现细节与实操要点3.1 上下文构建的完整管线理论设计得再好落地才是关键。我实际搭建的 context-mode 上下文构建管线大致分五个步骤每一步都有需要注意的细节。第一步是消息归一化。不管用户的输入来自网页、App 还是 API统一转换成内部的消息结构。我用的结构类似于 OpenAI 的 messages 格式每个消息包含 rolesystem、user、assistant和 content 两个字段。这一步看似简单但很容易踩坑——比如用户上传了图片或者文件你需要先预处理好转成模型支持的格式否则后面组装时会报错。第二步是窗口裁剪。按照设定的滑动窗口大小从历史对话中截取最近 N 轮消息。这里有一个细节裁剪的时候最好保证窗口内最后一条消息是 user 角色这样整个上下文的结尾是落在用户问题上模型生成时能自然衔接。我一开始没注意这个裁剪后的窗口刚好以 assistant 消息结尾结果模型经常在用户还没提问的时候就先回答了一通非常尴尬。第三步是摘要合并。如果窗口裁剪之后还有更早的有价值信息就把它们交给模型生成摘要摘要插入到窗口之前。这一步我单独维护了一个memory字段不跟原始历史消息混在一起方便后续更新。第四步是检索注入。如果启用了 RAG根据用户当前问题去向量库检索相关片段按相似度排序后插入到系统预设和历史对话之间。注入的数量要控制我一般控制在 3 到 5 段太多了会挤占其他信息的空间太少了检索意义不大。第五步是组装请求。把系统预设、检索片段、记忆摘要、裁剪后的历史对话、用户当前输入按顺序拼接加上 max_tokens、temperature 等推理参数形成最终的 API 请求。这五步每一步都不复杂但串起来之后整体逻辑就会清晰很多。我把这套管线封装成了一个独立的模块上层业务只需要调用一个 build_context(user_input, session_id) 函数传两个参数进去就能拿到组装好的请求体。3.2 token 预算与窗口管理Token 预算管理是整个 context-mode 里最容易出问题的地方。模型上下文窗口是硬上限超了直接报错但就算不超窗口被塞得太满模型的处理质量和速度都会明显下降。我采用的 token 预算分配方案是这样的假设模型上下文上限是 8K token我会设置一个 80% 的安全线也就是实际使用不超过 6.4K token留出 20% 给模型生成回复的空间。在 6.4K 的有效预算里系统预设固定占用约 500 token检索片段最多占用 1.5K token记忆摘要占用约 500 token剩余 3.9K 左右全部留给历史对话和用户输入。这里的核心问题是怎么预判一截文本的 token 数量。不同模型的分词方式不一样一个英文单词可能拆成 0.6 到 1.3 个 token一个中文字符大约是 0.6 到 1 个 token 的消耗。最稳妥的做法是直接调用对应模型的 tokenizer 来计算而不是用字符数除以 4之类的粗略估算。我一开始就是偷懒用字符数估算结果组装出来的请求时不时触发超限报错后来老老实实换成模型官方 tokenizer 才稳定下来。窗口管理还有一个要点当历史对话超出窗口时不能简单地从最前面删掉因为最前面的消息往往包含了用户在会话早期交代的重要背景。我的做法是渐进式遗忘——把最早的消息先交给摘要模型生成一段凝练的记忆摘要如果摘要也塞不下了再考虑是否丢弃。这样既控制了 token 占用又尽可能保留了核心信息。3.3 记忆压缩与摘要策略摘要压缩是 context-mode 里最有技术含量的一环。你让模型总结一下之前的对话听着简单做起来全是细节。第一个细节是摘要的粒度。我见过有人只生成一段全局摘要对话内容长了之后这段摘要会变得非常笼统丢失大量细节。我的做法是分层摘要每小时左右生成一个阶段摘要一天左右生成一个天级摘要天级摘要由阶段摘要再压缩而成。需要用到早期记忆时优先取天级摘要如果模型觉得信息不够再往下翻阶段摘要。这种分层结构兼顾了 token 效率和信息密度。第二个细节是摘要的更新策略。用户跟 AI 聊到一半对话又增加了几轮这时候全局摘要不能重新生成——每次都重新生成成本太高。我的做法是采用增量摘要读取已有的记忆摘要结合新增的对话内容让模型生成一份新摘要。这样每次摘要的输入只有新旧两份内容token 开销小得多而且摘要质量比从头生成更稳定。第三个细节是摘要的触发时机。我建议不要每轮都做摘要那样太频繁了。我实测下来的经验是当历史对话超过窗口上限的 60% 时触发一次摘要之后每增加 20% 再触发一次。这个频率既能保证记忆不丢又不会频繁打断主流程。做摘要还有一个隐含的收益它相当于主动帮用户划重点。我发现同样的信息放进摘要里的关键信息比堆在原始历史里的信息在后续问答中对模型的影响权重更高。后来我干脆在摘要指令里加了一句保留与用户目标相关的关键事实和数据效果立竿见影模型对早期关键信息的回忆准确率提升了不少。4. 实操过程与关键环节实现4.1 实现一个最小可用的 context-mode纸上谈兵这么久来点实在的。我分享一套最小可用的实现代码基于 OpenAI 接口但思路是通用的换成其他模型也只需要改调用方式。首先定义消息结构和会话存储。我用 Redis 存历史消息key 是 session_idvalue 是消息列表的 JSON。import json import redis import tiktoken r redis.Redis(hostlocalhost, port6379, db0) def append_message(session_id: str, role: str, content: str): key fsession:{session_id} msg {role: role, content: content} r.rpush(key, json.dumps(msg, ensure_asciiFalse))接下来是核心的上下文构建函数。这里我把 token 计算、窗口裁剪、摘要检查都放进去了逻辑比较完整可以直接抄走改改用。def build_context(session_id: str, user_input: str, system_prompt: str, max_context_tokens: int 5000): enc tiktoken.encoding_for_model(gpt-4) key fsession:{session_id} raw_messages [json.loads(m) for m in r.lrange(key, 0, -1)] # 添加用户当前输入 raw_messages.append({role: user, content: user_input}) # 从后往前裁剪保证上下文不超预算 selected [] total_tokens len(enc.encode(system_prompt)) len(enc.encode(user_input)) for msg in reversed(raw_messages[:-1]): # 排除当前输入先处理历史 msg_tokens len(enc.encode(msg[content])) if total_tokens msg_tokens max_context_tokens: break selected.append(msg) total_tokens msg_tokens selected.reverse() # 恢复正确的时序 messages [{role: system, content: system_prompt}] selected [{role: user, content: user_input}] return messages这段代码的核心思路是从最近的对话往前扫描塞得下就保留塞不下就停止。这样实现的好处是永远不超 token 上限坏处是会丢早期信息。所以紧接着补上摘要逻辑如果发现 raw_messages 里存在被裁剪掉的消息就调用摘要模型把它们压缩进 memory。def summarize_old_messages(old_messages, existing_summary): if not old_messages: return existing_summary content existing_summary \n json.dumps(old_messages, ensure_asciiFalse) prompt f请将以下对话内容压缩为简洁的中文摘要保留与用户目标相关的关键事实和数据\n{content} # 调用模型生成摘要这里省略具体 API 调用代码 return call_llm(prompt, max_tokens500)上面这套实现里最有用的一个设计是system prompt 和 user_input 的 token 是优先保证的无论历史对话怎么裁这两部分永远不被挤掉。因为系统预设决定了模型的能力范围用户当前输入决定了本轮的任务目标这两个是刚需历史对话才是可压缩的内容。4.2 接入 RAG 扩展长期记忆如果你的 context-mode 需要跨会话记忆或者需要结合企业知识库回答问题纯靠摘要是不够的得接 RAG。RAG 的核心是向量检索把文档和对话拆分、向量化、存入向量库查询时用用户问题做语义搜索找到最相关的片段注入上下文。我用的是 OpenAI 的 embedding 接口配合 Chroma 向量库代码量不大import chromadb from openai import OpenAI client OpenAI() collection chromadb.Client().get_or_create_collection(memory_store) def add_to_memory(session_id, text): vec client.embeddings.create(modeltext-embedding-3-small, inputtext).data[0].embedding collection.add( documents[text], embeddings[vec], metadatas[{session_id: session_id}], ids[f{session_id}-{len(collection.get()[ids])}] ) def search_memory(query, session_id, top_k3): vec client.embeddings.create(modeltext-embedding-3-small, inputquery).data[0].embedding results collection.query( query_embeddings[vec], n_resultstop_k, where{session_id: session_id} ) return results[documents][0]接入 RAG 之后context-mode 的构建管线就多了一步先拿用户当前输入去检索相关记忆把检索结果插到系统预设和历史对话之间。这一步的顺序非常关键——检索结果必须放在历史对话前面让模型先看到背景资料再看到对话过程最后看当前问题这样信息层次最清晰。不过 RAG 也不是万能的。我踩过的一个坑是向量检索的结果和当前问题表面相关、实质无关比如用户问报告里的预算部分怎么改检索出来的却是另一份完全无关报告里的预算表。解决的办法是加一层 rerank 重排用模型对检索结果做一次相关性打分过滤掉低质量片段。这个操作会增加一次模型调用但会明显提升注入片段的质量。4.3 实测效果对比代码写完理论说了一大堆最终还是得看实测数据。我整理了一份 context-mode 开启前后的对比数据用的是同一个测试集包含 50 组多轮对话场景。从结果看context-mode 开启后模型的上下文连贯性打分从 3.2 提升到了 4.6满分 5 分历史信息准确引用率从 41% 提升到了 78%。最明显的变化是回答中我不知道你之前说了什么这类问题的大幅减少以及在涉及前文信息的追问中模型给出的回复不再自相矛盾。同时我也记录了代价单轮请求平均 token 消耗从 600 涨到了 2100延迟从 1.2 秒涨到了 2.1 秒。这个增幅在我的场景里是可以接受的但如果你的应用对延迟特别敏感或者模型调用量大就要在上下文长度和成本之间做更精细的平衡可以考虑用更小规模的历史窗口或者对部分请求关闭 RAG 检索。我还做了一组有趣的对比同一段多轮对话分别测试了完整历史注入摘要注入和滑动窗口丢弃早期信息三种策略。完整历史注入的效果最好但 token 消耗最高摘要注入的效果接近完整历史token 消耗降低约 60%性价比最高滑动窗口丢弃早期信息在对话超过 6 轮之后效果明显下滑。所以如果你的模型上下文窗口够大优先用完整历史窗口紧张用摘要注入实在没有摘要能力才退而求其次用滑动窗口。5. 常见问题与排查技巧实录5.1 上下文越界与截断问题我上线 context-mode 后遇到的第一个线上事故就是用户聊到第 20 轮时请求直接抛出了 context length exceeded 的错误。排查过程很有意思因为我明明写了 token 预算控制理论上不该超问题出在哪里后来发现问题出在 max_tokens 的预留上。我的预算算法只算了输入侧的总 token没算输出侧。当用户的单轮输入非常长、或者我用模型生成摘要时消耗了较多输出 token整体就超出了模型硬上限。解决办法是双保险一方面在 build_context 里把系统提示和用户输入也计入预算另一方面在请求层做一次最终校验如果总 token 超过模型上限的 85%就对历史对话做进一步裁剪。另一个容易忽略的细节是不同模型的 tokenizer 不同。我用 gpt-4 的 tiktoken 来估算其他模型的 token结果某些模型实际 token 数比估算高 20% 以上导致隐性越界。后来统一改成用各模型官方 tokenizer 计算再没出过这个问题。5.2 上下文污染与相关性下降上下文越界是明枪上下文污染是暗箭。污染指的是上下文里塞入了太多跟当前问题无关的信息模型反而被这些信息带偏。最典型的一个案例某用户在一轮会话中先聊了旅游攻略又聊了股票投资再问你觉得哪个更值得做。由于 context-mode 把前面所有对话都注入了上下文模型搞不清哪个指的是旅游项目还是股票回答起来左右摇摆。这就是没有做好相关性过滤导致的上下文污染。我的解决方案是给历史对话做相关性标注。在组装上下文时先用轻量级模型对每段历史消息进行相关性分类与当前问题高度相关的保留完整内容中度相关的压缩成一句话不相关的直接丢弃。这样虽然多一步处理但显著提升了模型的回答精准度。实测下来相关性标注能让模型在复杂话题切换场景下的表现提升约 30%。还有一个污染源是系统预设里的冗余信息。有些团队习惯把大段的产品说明、公司介绍塞进 system prompt数量一多就会挤占历史对话的空间。建议定期审查系统预设凡是跟当前任务无关的内容一律移除保持精简。5.3 成本失控与延迟飙升context-mode 是一把双刃剑用好了提升体验用不好钱包流血。我的应用接入 context-mode 的头一周模型调用成本直接翻了一倍多排查下来发现三个原因。第一个原因是摘要触发的频率过高。我最初的设计是每轮对话后都检查是否需要摘要结果在长对话里摘要模型的调用次数比主模型还多。后来改成历史对话超过窗口的 60% 才触发摘要调用量立刻降下来了。第二个原因是检索注入的片段太多。每次检索默认返回 5 个片段但大部分场景下 2 到 3 个片段就够用了。减少注入数量后token 消耗下降明显回答质量几乎没受影响。第三个原因是调试期的日志记录。为了排查问题我把每次请求的完整上下文都打日志了这本身不影响模型成本但日志量巨大间接拖慢了系统。建议日志只记录 token 数量和消息元信息不记录完整内容。延迟方面最有效的优化是预热对高频用户提前构建好上下文并缓存用户发消息时直接取缓存结果省去重复构建的时间。实测能降低 30% 到 50% 的端到端延迟。5.4 排查工具箱做 context-mode 的调试没有趁手的工具真的会崩溃。我推荐几个常用的排查手段都是我在实践中验证过的。第一是上下文可视化工具。把每次请求的上下文导出来逐条查看消息的角色、内容、token 数、来源标记。我写了一个简单的 Python 脚本能统计上下文中每部分系统、检索、历史、当前的占比画成柱状图。一图胜千言很多问题一眼就能定位。第二是 A/B 测试框架。context-mode 的每一项调整都不要直接全量上线。我习惯把用户分成 A/B 两组一组用旧策略一组用新策略观察两组的会话深度、满意度评分、token 消耗变化。用数据说话才能避免上了线又不确定改动是好是坏。第三是黄金对话集。准备 30 到 50 组覆盖典型场景的多轮对话每次改动后跑一遍对比输出质量。这个对话集是人工标注过标准答案的能把感觉变好了变成覆盖率从 72% 提升到了 81%。第四是熔断机制。如果 context-mode 模块出现异常比如异步摘要任务超时、向量库不可用要能自动降级为普通对话模式保证用户体验不中断。我在系统里加了一个开关RAG 服务连续三次超时就自动关闭检索注入只保留历史对话和摘要等服务恢复后再自动开启。这些工具搭起来成本不高但能在关键时刻救你一命。尤其是黄金对话集它帮我在一次代码重构后立刻发现了上下文组装顺序的回归问题如果没有它这个问题可能要线上跑一周才能被用户反馈出来。做 context-mode 这件事我最大的体会是它不是一个一锤子买卖的功能而是一个需要持续调优的系统。别指望上线了就完事用户的对话场景千奇百怪今天你觉得窗口 5 轮够了明天就有个用户在第 8 轮时告诉你你怎么忘了我说过我喜欢简约风格。多留几手后路把摘要、检索、降级机制都准备好遇到问题才有得打。最后再分享一个小技巧context-mode 的调优不要只盯着模型效果也要看用户的行为数据。如果用户在使用 context-mode 后主动说你记得真清楚这类话的频率提升了说明你方向对了反过来如果用户开始大量复制粘贴前文内容说明你的上下文机制还没真正帮到用户。用这些信号来校准你的优化方向比任何指标都真实。
