大模型记忆增强实战：context-mode上下文管理设计与落地

那次演示翻车之后我才认真去思考记忆这件事。当时我给内部团队搭了一个AI助手原型演示环节有人连续追问了三个问题结果助手把前一轮的结论完全抛在脑后回答得牛头不对马嘴。场面一度很尴尬。问题根子不在模型本身而在于我压根没做上下文管理。大模型接口天生无状态每次调用都是一张白纸你传什么它看什么。想让助手记得用户刚才说了什么、正在看什么、手头有什么资料必须自己造一套记忆系统。这个需求后来被我做成了项目代号为context-mode的功能模块简单说就是让AI助手具备一种上下文模式能感知当前对话所处的场景把相关的历史信息、环境信息和用户意图一起送进模型再输出回答。这篇文章不是讲理论是把我从设计到落地、再到上线后被真实用户按在地上摩擦的完整过程记录下来。内容包括上下文窗口怎么分配、记忆怎么分层、检索怎么避坑、延迟怎么压下来以及最后我怎么搭了一套评测机制。适合正在做AI助手、智能客服、Copilot类应用被模型记不住事折磨过的开发者参考。项目代号X也行、context-mode也好思路是通用的。1. 从一问三忘到context-mode先搞清楚要治什么病1.1 无状态AI的尴尬现场先说个最典型的翻车场景。用户问帮我看看这个模块的代码感觉性能有问题。助手回答了一大段优化建议。用户接着问那第二点提到的方案如果数据量翻一倍还能撑住吗——如果助手没有上下文它根本不知道第二点是哪一点。这类问题在纯问答场景里还能用把整个对话历史拼进Prompt来凑合。但如果对话很长或者用户中途切换了话题你塞进去的历史越多模型越容易串味。更麻烦的是真实产品里用户往往不只有对话他可能正打开某个文件、正在调试某个报错、昨天刚配置过某个环境——这些环境上下文如果也能被助手感知回答质量会提升一个量级。context-mode要治的就是这个病让AI助手在生成回答时不仅仅依赖当前这一句话还要参考用户此刻在什么场景里、之前说过什么、手头有什么材料。1.2 上下文模式的本质给AI装一个工作记忆人跟人聊天时彼此默认共享大量背景信息。你在帮同事看代码对方递过来一行报错你立刻知道这是哪个项目的哪段逻辑。AI助手要复现这种体验需要三样东西会话上下文本轮对话之前聊了什么用户已经提供过的信息。环境上下文用户当前的操作场景比如打开了哪个文件、正在执行什么命令、浏览的是哪个页面。知识上下文产品内置的资料库、历史工单、团队文档回答问题时需要的参考资料。context-mode做的就是把这三种上下文按需抓取、按优先级组装成一份工作记忆在每次调用模型时注入。它跟对话历史硬拼最大的区别是有选择、有结构、有优先级而不是一股脑全塞进去。1.3 适合做context-mode的场景清单不是所有产品都需要这套东西但下面几类场景做了之后收益非常直接场景上下文来源典型收益代码助手当前打开的文件、光标所在函数、最近改动补全和建议更贴合手头代码智能客服用户历史工单、会员等级、最近浏览商品回答更个性化、减少重复询问文档问答企业知识库、问答历史、用户身份权限答案准确率明显提升运维助手当前告警、最近发布记录、系统指标排查建议更聚焦、少废话教育辅导学生过往错题、当前章节、学习进度讲解更有针对性我自己最先落地的是代码助手场景后面又把同一套context-mode抽象出来接到了客服问答上。核心逻辑完全复用差别只在上下文来源的采集方式。2. 上下文来源、窗口分配与记忆衰减设计阶段的三个关键抉择设计阶段我纠结最久的是三个问题上下文从哪来、塞多少进去、以及哪些记忆该被保留。这三个问题如果没想清楚代码写得再漂亮也是白搭。2.1 显式上下文与隐式上下文的取舍上下文来源可以分成两类显式上下文用户主动提供的信息比如指定只看这个目录下的代码参考这份文档。这类上下文可靠性高因为用户明确授权了。隐式上下文系统从用户行为里自动推断的比如检测到用户当前打开的文件、最近的键盘输入、正在浏览的页面。这类上下文不用用户额外操作体验好但容易抓错。我的建议是隐式上下文必须配合显式确认机制。比如代码助手检测到用户打开了A文件但用户提的问题是关于B项目的这时不能默认把A文件的内容塞进去应该允许用户用文件路径或关注范围xxx的方式手动指定。当时我踩过一个典型坑助手检测到用户在看测试文件自动把测试代码当作上下文注入结果用户问的是生产环境的性能问题回答里全是测试数据反而误导了用户。后来我加了一条规则——隐式上下文只作为候选必须经过相关性打分超过阈值才允许注入否则宁可不注入。2.2 窗口分配策略不是越多越好大模型输入端有个上下文窗口上限即使窗口很大也不代表塞满就好。原因有两个注意力稀释上下文过长时模型对关键信息的权重会下降海量无关内容会干扰回答。成本与延迟处理的token越多响应越慢、费用越高。我当时用了一个非常朴素的分配策略效果却很稳定上下文类别预算占比说明系统指令与角色设定5%固定不变不参与动态分配当前用户问题10%原样保留不加改动会话上下文25%最近的对话历史超出部分做摘要环境上下文30%当前文件、当前页面等场景信息知识上下文30%检索来的参考资料按相关度排序这个分配不是拍脑袋而是从一次内部评测得出的经验当知识上下文的占比超过40%时回答会开始偏离用户的问题夹杂太多资料里的话术当会话上下文超过30%时模型会在历史里打转。30%左右是一个比较平衡的点。2.3 记忆的优先级与衰减模型不是所有历史对话都值得记住。用户昨天问过的问题、上周看过的文档对今天的回答可能毫无帮助甚至起反作用。我给每条记忆设计了一个新鲜度-重要性二维打分公式大概是记忆分 0.6 * 新鲜度分 0.4 * 重要性分 新鲜度分 1 / (1 距离当前时间的小时数) 重要性分 由事件类型决定用户明确标记1.0问题被追问0.8普通问答0.5闲聊0.2只要记忆分高于0.4的才进入候选用途低于这个阈值直接丢弃。这个模型简单到有点粗暴但它让我避开了什么都想留、什么都往Prompt里塞的陷阱。上线第一个月因为记忆衰减过滤掉的无效上下文占了总候选量的60%以上回答准确率反而提升了。3. 记忆分层与上下文组装让AI拥有工作记忆的骨架3.1 短期记忆与长期记忆的分层context-mode的记忆系统我分成了两层短期记忆当前会话内的对话记录、临时状态存内存数据库TTL设为2小时。会话结束后可以清理或者把有价值的摘要沉淀到长期记忆。长期记忆跨会话的信息包括用户偏好、历史问题模式、业务知识片段存向量数据库按用户ID和业务场景维度做索引。分层的核心原因是访问频率和生命周期完全不同。短期记忆读写频繁要求低延迟长期记忆查询频率低但需要支持语义检索。混在一个存储里两头都做不好。3.2 上下文状态的流转逻辑我设计了一个简单的状态机来管理上下文的切换CONTEXT_NEW新会话没有历史上下文无需加载。CONTEXT_ACTIVE当前会话正在进行加载短期记忆和当前环境上下文。CONTEXT_SWITCHING检测到话题切换旧上下文归档新上下文初始化。CONTEXT_CLOSED会话结束短期记忆做摘要后写入长期记忆。话题切换检测是这里最容易出问题的地方。我的做法是每轮对话结束后用当前问题与上一轮问题的向量相似度做判断。相似度低于0.4就认为发生了话题切换在0.4到0.7之间时保留上一轮的摘要但降低它的权重高于0.7则完全是延续原样保留。3.3 上下文组装管线组装过程我拆成了四个步骤每一步都有明确产出采集从短期记忆、环境监控模块、知识库检索接口分别拉取原始数据。过滤用前面提到的记忆分和相关度阈值砍掉低价值内容。压缩对超过预算的长文本做摘要。会话历史太长时我采用最近N条完整保留 更早部分分段摘要的策略而不是一刀切。拼接按照固定模板把系统指令、用户问题、三类上下文拼成最终的Prompt。这套管线最大的好处是每一层都可以单独调试。比如发现回答质量下降可以先看是采集不到数据、过滤砍太狠还是摘要压坏了关键信息。比起在最终Prompt里调来调去定位问题快得多。4. 动手实现一个能跑的context-mode最小闭环4.1 整体架构与模块划分整个模块我拆成了五个部分彼此尽量解耦模块职责对外接口ContextCollector采集各类上下文来源返回原始上下文列表ContextFilter打分、过滤、排序返回精选上下文列表ContextCompressor对超长内容做摘要返回压缩后的文本ContextAssembler拼接最终Prompt返回组装结果MemoryStore短期/长期记忆存取提供读写与检索能力数据流大概是用户发起请求 → ContextCollector并行拉取会话、环境、知识三类数据 → ContextFilter打分过滤 → ContextCompressor对超预算内容压缩 → ContextAssembler按模板拼接 → 调用大模型API。整个过程在服务端完成对用户无感。4.2 核心代码骨架核心的ContextAssembler我写得比较朴素但够用class ContextAssembler: def __init__(self, budget_alloc): # budget_alloc: {system: 0.05, query: 0.10, # session: 0.25, env: 0.30, knowledge: 0.30} self.budget_alloc budget_alloc def assemble(self, user_query, session_ctx, env_ctx, knowledge_ctx, token_fn): total_budget token_fn(user_query) / self.budget_alloc[query] sessions self._fit(session_ctx, total_budget * self.budget_alloc[session]) envs self._fit(env_ctx, total_budget * self.budget_alloc[env]) knows self._fit(knowledge_ctx, total_budget * self.budget_alloc[knowledge]) return self._render_prompt(user_query, sessions, envs, knows)_fit方法做的事情是先按相关度排序然后从高到低往里塞塞到预算上限为止。超预算的部分直接丢弃不再额外处理因为前面的过滤和压缩已经把质量把控住了组装层只负责装得下。这里有个细节容易忽略token_fn不能简单用len(text)估算中文字符和英文token的比例差异很大。我用的方案是按字符数估算再乘以1.5的安全系数宁少勿多防止组装完发现超了窗口又得回来砍。4.3 接入大模型API的请求组装最终发送给模型的Prompt长这样[系统指令] 你是一个具备上下文感知能力的助手。以下内容是按优先级排列的参考上下文。 [知识上下文] 检索到的资料按相关度从高到低排列 [环境上下文] 用户当前正在处理的文件/页面信息 [会话上下文] 最近对话记录最旧的在最上面 [用户问题] 当前这一轮的完整问题顺序不是随意的。知识上下文放在最前面是因为它的信息量大、需要模型花更多注意力处理会话上下文放在最后是为了跟紧挨着的用户问题形成连贯环境上下文居中起到场景锚点的作用。这是我做了几轮对照实验得出的顺序把知识上下文和会话上下文对调之后测试集的回答准确率掉了大约7个百分点。4.4 性能与成本控制context-mode最大的开销不在逻辑本身而在上下文采集和检索。如果每次请求都实时去拉数据、做向量检索、做摘要延迟和成本都压不住。我用三板斧解决采集并行化会话、环境、知识三路采集同时发起等最慢的那路返回再继续。原本串行耗时350毫秒并行后压到120毫秒。短期记忆走缓存最近半小时内的会话上下文直接读内存缓存不查数据库。这一项把会话上下文的平均采集时间从80毫秒降到15毫秒。摘要结果做二级缓存同一用户、同一话题的摘要缓存10分钟避免每轮对话都重复压缩同样的长历史。成本方面加了context-mode之后单次请求的token消耗大约涨了40%但这是值得的——因为回答准确率上去了用户不再反复追问同一个问题总请求量反而降了。实际算下来单位有效回答的成本是下降的。5. 上线后踩坑实录上下文污染、检索偏差与延迟黑洞功能上线前我信心满满觉得设计已经很完善了。结果第一个月就被真实流量教育了三次每次都是课堂上不会教的坑。5.1 上下文污染旧记忆干扰新任务第一个坑是上线第三天发现的。用户在聊天里聊了几轮A项目的数据库优化然后突然转去问B项目的接口设计。我的话题切换检测当时设的是相似度低于0.4就切换但A项目聊得很深积累了不少短期记忆这些记忆即使权重降了仍然被塞进了新话题的Prompt里。结果助手回答B项目接口设计时时不时冒出一句这个表结构可以参考之前A项目的分库方案。用户看得很懵。修复方案分两步一是话题切换时旧会话的原始记录直接归档只保留一条不超过200字的摘要作为跨话题参考原始内容不再参与新话题的组装二是给每条记忆打上话题标签组装时优先匹配与当前问题话题标签一致的记忆。5.2 检索偏差相关知识检索不到的尴尬第二个坑出在知识上下文检索上。我最初用的纯向量检索按语义相似度召回。某些专业名词、简称、代码标识符向量检索的效果很差——明明知识库里有答案召回结果里却没有。比如知识库里存了一条SRE-告警-磁盘使用率超过80%时执行清理脚本用户问的是磁盘快满了怎么办向量相似度居然不到0.3这条资料压根没被召回来助手只能空泛回答建议检查磁盘空间清理不必要文件。后来我把召回策略改成混合式先做关键词召回再做向量召回两条路的结果合并后统一重排。关键词召回能抓住代码标识符、专业名词这种精确匹配向量召回擅长处理口语化表达。两者合并后知识上下文命中的准确率从62%提到89%。这中间花了两天时间调召回数量最后定为每条路径各取Top 20合并后按综合分取Top 10。5.3 延迟黑洞检索太慢拖垮整个响应第三个坑是延迟。context-mode上线后P95响应时间从原来的1.2秒涨到2.8秒用户体感明显变差。排查下来罪魁祸首是知识上下文的向量检索每次请求实时查询向量库查询本身只要30毫秒但前面的文本向量化编码耗时400多毫秒。关键是这400多毫秒里很多是重复劳动——用户问的问题跟上一轮语义接近向量化结果几乎一样。我的优化方案是对用户问题的向量化结果做缓存key是用户ID 问题前32个字符命中率大约三成。把知识检索改为异步预取用户输入停顿超过1.5秒时后台先按当前输入做一次粗检索等用户真正发送时结果已经在缓存里了。给向量检索加了超时熔断超过200毫秒没返回就直接走关键词召回结果不阻塞主流程。这三招叠加之后P95响应时间回落到1.5秒知识上下文的摄取对用户基本无感。5.4 没有评测就谈不上优化踩完这些坑之后我意识到一件重要的事context-mode这种模块每个人改一个参数都可能影响最终效果但没有评测机制的话你根本不知道改好还是改坏了。我搭了一套轻量评测系统核心是一个包含300条真实问题的测试集每条问题都标了正确答案和期望引用的上下文。每次改动后跑一遍记录三个指标回答准确率输出与标准答案的语义相似度用模型打分。上下文命中率期望引用的上下文是否真的出现在最终Prompt里。响应延迟P50和P95两条线都要记录。没有这套评测我后来做的几轮参数调优根本不敢动。有了它每次改动到底有效还是负优化跑一次就知道。6. 实测数据与总结思考context-mode到底值不值6.1 上线三个月的实测数据项目上线三个月我对接了代码助手和智能客服两个场景数据上有一些值得分享的变化指标未开context-mode开启后变化回答准确率内部测试集71%86%15%用户追问次数平均2.3次/题平均1.4次/题-39%P95响应时间1.2s1.5s0.3s单次请求平均token消耗1x1.4x40%错误归因用户投诉基线下降52%明显改善准确率提升在意料之中但用户追问次数下降39%这个数据最让我意外。追问减少意味着用户对第一轮回答的满意度提升了这是比准确率更能反映真实体验的指标。代价是响应时间涨了0.3秒token消耗涨了40%但换来的是有效回答率的大幅提升总体算下来是划算的。6.2 context-mode在什么情况下可能不是好方案我也要泼一盆冷水。如果你的产品满足下面任一条件context-mode短期内不必上单轮问答为主用户每次提问都是独立的、不含前后依赖比如计算器、翻译工具。这种场景硬加上下文只会增加延迟和成本。领域极窄且封闭助手只处理固定格式的请求比如表单校验、格式化输出上下文图形同虚设。上下文来源无法可靠获取没有埋点、没有日志、拿不到用户当前环境的任何信号。这种情况下硬凑出来的上下文基本靠猜还不如不做。6.3 关于这件事我的几点体会最后聊几句实践中积累的体会。第一context-mode的收益上限由上下文采集质量决定。模型能力再强你喂给它的上下文是脏的、偏的、不新鲜的它也只能在错误的信息上做推理。所以我把最多的精力花在采集和过滤上组装反而最简单。第二别迷信复杂的记忆模型。我在设计时一度想把记忆做得非常精细比如情感权重、话题图谱、时间衰减曲线。后来发现对大多数场景来说新鲜度加重要性这两维就够用了。复杂度上去了调试成本也跟着上去了收益却很不明显。第三评测先行这句话在context-mode这个项目上真的救了命。没有那300道题的测试集我后续的每次调优都相当于盲人摸象。你如果也要做类似功能我强烈建议先花时间建评测集再动手调参。第四我想特别提醒一点context-mode不改变模型本身的推理能力它只是在恰当的时候把恰当的信息送到模型面前。设计时可以追求让AI看起来记得住但别指望它能自主判断哪些信息重要、哪些不重要——那是你的工作。把上下文捡好、筛好、摆放好剩下的交给模型。如果你正在做类似的AI应用我建议从最小闭环开始先接一种上下文来源跑通后再逐步加。别一上来就搞全套否则你会同时面临采集不准、过滤误杀、组装超预算三个问题根本分不清是哪个环节出了问题。