context-mode这个词最近在我关注的几个 AI 应用开发群里被反复提起。说实话它不是什么高深理论说白了就一句话给 AI 应用按需喂上下文让它在对的时机、用对的语境、做出对的回答。我在给内部一个客服知识库助手加这个功能时才真正意识到所谓的上下文模式不是加一个开关那么简单它背后是一整套采集-存储-检索-注入-回收的管道工程。这篇文章就把我在实战里踩过的坑、验证过的方案原原本本写出来希望能给同样在做 AI 应用、AI 助手、智能问答的人省点时间。这个功能适合谁来参考正在做 AI 客服、AI 文档问答、代码助手或者任何需要让大模型记住业务场景的开发者。不管你是刚接触大模型应用开发还是已经在线上跑了不少对话任务这篇文章里关于架构设计和排障的思路应该都能用得上。1. 先想清楚context-mode 到底解决什么问题1.1 没有上下文模式的 AI蠢在哪儿先聊聊我为什么非要做这个功能。拿我们内部的客服知识库助手举例最初版本的做法很粗暴每次用户提问就把用户最近几轮对话原封不动拼进 prompt再把知识库里所有文档一股脑塞进去。结果呢一是 prompt 动不动就爆掉二是模型回答质量飘忽不定——问退款流程的时候它反而在讲退货地址因为塞进去的无关文档太多了。这就是典型的上下文失控问题。大模型本身就像一个记忆力有限但阅读速度极快的实习生你一次性塞给它太多材料它没法判断哪些是当前任务真正需要的注意力被稀释回答自然跑偏。context-mode 的核心目标就是解决这个失控问题系统主动判断当前这个问题需要哪些上下文只把最相关的那部分交给模型。我打个比方你就理解了。人类开会的时候聪明的主持人不会把公司所有资料都摆在桌上而是根据议题只调出相关的那几份文档。context-mode 就是这个主持人角色。它在用户和模型之间加了一道筛选和编排的工序。1.2 三个设计目标准确、省 token、可解释做这个功能之前我给自己定了三个硬性指标后来的所有设计决策都围绕它们展开。第一个是准确。注入的上下文必须和当前用户意图强相关相关性不行就宁可不注入。我见过太多人因为多塞点多让模型理解的思维结果把 quality 搞砸了。第二个是省 token。大模型 API 是按 token 计费的上下文越长成本越高响应也越慢。context-mode 必须有预算控制像人一样有话则长、无话则短。第三个是可解释。这个很多人会忽略但一旦上线出问题你就知道它多重要了——你要能随时回答刚才那次回答到底用了哪些上下文、每条上下文是从哪来的否则排查问题就像大海捞针。这三个目标其实互相牵制追求准确可能要多检索几条上下文这就增加 token追求省 token 可能砍掉辅助信息准确度又下降。所以 context-mode 本质上是一个带约束的优化问题而不是一个简单的有没有上下文的二值开关。2. 核心设计三层上下文架构2.1 显式、隐式、推导三层在动手写代码之前我先把上下文这个词拆开了。一说到上下文很多人只想到对话历史但实际业务里上下文远不止这些。我把它分成三层每一层的来源、特征、处理方式都不一样。第一层是显式上下文就是用户主动提供的信息。比如在客服场景里用户说我上周买的那个蓝牙耳机坏了上周蓝牙耳机坏了就是显式上下文它们是用户需求最直接的信号优先级最高必须原样保留不能随便压缩改写。第二层是隐式上下文系统被动采集到的环境信息。包括当前时间、用户所在页面、设备类型、用户等级、会员状态等等。比如同样是问退款政策金卡会员和普通用户看到的政策可能不同凌晨 2 点的咨询和白天工作时间的咨询客服的响应口径也可能不同。这类上下文单个看起来不起眼但组合起来往往能大幅提升回答的针对性。第三层是推导上下文需要系统主动算出来的。比如根据用户历史工单推断他最近的关注点根据他当前输入的句子做意图分类根据知识库标签体系判断他可能需要的文档类别。这一层最花功夫但也是 context-mode 真正体现智能的地方。分层的好处是你在设计采集和注入策略时有了明确的处理对象。显式上下文要做的是保真隐式上下文要做的是补全推导上下文要做的是取舍。不同的处理逻辑落到代码里就是不同的数据管道互相之间不会搅在一起。2.2 上下文生命周期管理有了三层分类之后我开始梳理上下文的完整生命周期。这个流程我后来一直在用也推荐你照着画一遍它能帮你看清整个系统该有的模块采集从用户输入、系统日志、业务数据库里拿原始数据。采集的关键是快不能为了拿一条上下文让主流程多等几百毫秒。结构化把杂乱原始数据转成统一格式。比如原始日志是一条 JSON结构化之后变成一条带时间戳、来源、实体标签的上下文记录。这里我强烈建议加一个来源标记字段后面排查问题全靠它。存储上下文不是用完就扔的。短期上下文比如当前会话的对话历史放内存缓存长期上下文比如用户偏好、历史订单放数据库或者向量库。存储策略取决于你的业务类型下面实操部分我再细讲。检索根据当前用户请求从存储里找出最相关的上下文片段。这一步是 context-mode 的心脏检索做不好后面全白搭。注入把检索到的上下文按优先级排序拼装成 prompt。注意不是简单的字符串拼接要有结构化的模板让模型能区分哪段是背景资料、哪段是对话历史、哪段是系统指令。回收一次对话结束后需要把临时上下文清理掉把有价值的长期上下文写回存储。这个环节容易被忽略但内存泄漏、数据膨胀基本都是因为它没做好。这六个环节串起来就是一个完整的闭环。我在做第一版的时候只实现了采集-注入两步结果系统能跑但完全谈不上模式因为没有存储和检索上下文就永远只有当次对话的那一点点。后来补上全生命周期之后整个系统的表现才真正稳定下来。3. 实操从零搭一套 context-mode3.1 上下文数据结构怎么设计动手写代码之前先把数据结构定下来。我踩过的一个坑是一开始用简陋的 key-value 结构存上下文后来需要按时间和相关性做筛选发现根本筛不了只能回炉重写。我最终用的方案是统一的上下文记录结构每条记录包含这几个核心字段字段类型说明ctx_idstring唯一标识方便追踪typeenum显式/隐式/推导sourcestring来源标记如user_input、order_db、page_viewcontenttext上下文内容metadatamap附加信息如时间、置信度、实体标签expire_attimestamp过期时间用于自动回收relevance_scorefloat预计算的相关性分数检索排序用以我们客服助手为例一条显式上下文可能是这样的ctx_id是ctx_20250614120001类型是显式来源是user_input内容是我上周买的蓝牙耳机坏了metadata 里记录着解析出来的实体物品蓝牙耳机、时间上周、问题故障。隐式上下文示例类型隐式来源是session内容用户等级gold当前页面/order/refund设备ios时间2025-06-14 12:00。推导上下文示例类型推导来源是intent_classifier内容是意图售后咨询情感负面置信度 0.92。注意一个细节relevance_score我建议能做预算就预算不要在每次注入时才现算。你可以在写入存储时就根据业务规则算好一个基础分检索时再用具体请求去微调。这个设计在高峰期帮我省了不少计算资源。3.2 检索策略关键词加向量混合上下文检索是重头戏我试过纯关键词方案也试过纯向量方案最后用的是两者的混合。为什么因为这两种方式各自有硬伤。纯关键词检索快、可控但遇到同义词和语义相似就抓瞎。用户问怎么退货知识库里存的是退款流程关键词匹配不上。纯向量检索能解决语义相似的问题但偶尔会把完全不相关的上下文拉进来而且向量检索对冷门词、专业术语的效果不稳定。我的混合方案分三步走。第一步把用户当前输入做意图识别和实体抽取生成几组检索 query第二步关键词检索走倒排索引或数据库 LIKE向量检索用 embedding 余弦相似度两条线并行召回第三步把两条线的结果合并用加权分数排序——关键词命中得分 0.6向量相似度得分 0.4再结合之前预计算的relevance_score做微调。具体的加权公式我调成了这样细节因业务而异仅供参考final_score 0.35 * keyword_score 0.25 * vector_score 0.25 * base_relevance 0.15 * recency_bonus其中recency_bonus用来给新产生的上下文加分毕竟用户刚才提到的信息往往比上周的重要。比如用户这轮说刚才那个耳机那蓝牙耳机这条上下文的时效性加分就会让它排到前面去。检索返回的条数我也做了限制。之前贪多一次给模型塞 15 条上下文结果回答反而变差。现在是按预算动态决定默认取 top 5对话历史复杂时最多取到 8 条超出就丢弃低分项。3.3 token 预算怎么算token 预算这个事看着简单做起来全是门道。我的经验是预算必须在请求发出前就定死不能等拼好 prompt 才发现超了再砍那样很被动。我用的预算公式是这样的total_budget min(max_tokens, model_context_limit - reserved_tokens) reserved_tokens 系统指令占位 用户问题占位 模型回答预留举个例子假设模型上下文上限是 8000 token系统指令约 500用户问题约 300模型回答预留 1000那么可用上下文预算就是 8000 - 1800 6200 token。实际的上下文分配再在这个预算里细分对话历史 40%、检索文档 45%、结构化业务摘要 15%每个部分都设硬上限。如果你用的是 GPT-4 这类多轮对话能力强的模型对话历史可以压缩一些多给检索文档留空间如果用的模型指令遵循能力弱系统指令部分就要多占预算。这里没有标准答案建议按你实际跑的模型做实验。我还写了个小工具在开发环境打印每次请求的 token 分配明细哪部分超了、哪部分浪费了一目了然。没有这个工具之前我只知道prompt 太长完全不知道长在哪里。3.4 核心代码骨架参考下面这段是我简化后的 context-mode 核心调度逻辑去掉了业务细节保留了主干。语言用 Python框架无关你迁移到 Node.js 或者 Go 也容易。def build_contextual_prompt(user_input, session, user_profile, knowledge_db): # 1. 解析用户输入生成检索 query intent, entities parse_intent(user_input) # 2. 采集三层上下文 explicit [ctx for ctx in session.recent_messages if ctx.type explicit] implicit collect_implicit_context(session, user_profile) # 时间/等级/页面 inferred infer_context(intent, entities, user_profile) # 意图/偏好 # 3. 混合检索知识库 keyword_hits keyword_search(knowledge_db, user_input, top_k8) vector_hits vector_search(knowledge_db, user_input, top_k8) fused fuse_results(keyword_hits, vector_hits, session) top_contexts fused[:budget_alloc(documents)] # 按 token 预算取条数 # 4. 计算 token 预算 budget compute_budget( model_limit8000, system_reserved500, user_question_reserved300, answer_reserved1000 ) # 5. 按优先级排列并注入 prompt system_prompt build_system_prompt(inferred) # 推导上下文进系统提示 history_block compress_history(session.recent_messages, max_tokensbudget.history) docs_block format_documents(top_contexts, max_tokensbudget.documents) prompt PromptTemplate().render( systemsystem_prompt, historyhistory_block, docsdocs_block, questionuser_input ) return prompt这段代码看起来很简练但每行背后都有讲究。比如compute_budget这个函数我建议返回一个带各分区上限的预算对象而不是一个总数字这样后续每个模块都能自查是否超预算。再比如compress_history不是简单截断而是按最近的消息保留原文、较早的只保留摘要的策略做有损压缩能省不少 token。实际操作中我会把build_contextual_prompt的返回值同时写一份到日志里包括最终 prompt 全文、每条上下文的ctx_id和source、各个分区的 token 用量。这么做一开始会有点心疼日志存储成本但等第一次线上问题排查时你就会谢我了。4. 踩坑与排查实录4.1 上下文太脏导致答非所问上线第一周我们的 QA 就反馈了一个诡异现象用户明明在问会员积分怎么用模型却开始回答订单配送范围。我把日志拉出来一看发现问题出在推导上下文上——意图识别模块把积分错分到了配送类目推出来的上下文全是物流相关的反而把真实的用户输入挤到了次要位置。这个问题的根源是推导上下文出错时它的推导身份会让系统误以为它比用户原话更可信。后来我在注入逻辑里加了一条硬规则任何推导上下文只要和显式上下文冲突一律以后者为准。同时把推导结果的置信度阈值从 0.7 提到 0.85宁可漏推不可错推。这一改答非所问的概率立刻降了一个量级。4.2 token 溢出还是发生了预算公式算得再好也架不住用户输入超长。有一次用户直接把一整个发票表格粘贴进对话框用户问题就占了 4000 多 token把检索文档的预算全挤没了模型只能裸答质量自然差。我的应对方案是动态降级当用户问题超过预设阈值时先对用户输入做一个最大长度截断同时降低检索条数、跳过对话历史压缩把预算让给最核心的部分。注意截断用户输入会丢失信息所以我只在极端情况下触发并且会明确告诉用户您输入的内容过长已为您精简处理。这么做的思路和高速公路应急车道一样——平时不用但关键时候能保命。4.3 上下文过期导致回答过时第三个大坑是上下文过期。我们的知识库每周更新一次政策文档但向量库里的旧版本 embeddings 还在导致模型经常引用已废除的政策。这个问题的隐蔽性在于你单独看模型回答内容非常自信完全想不到它用的是一份过期文档。解决方法是给每条写入检索库的文档加valid_from和valid_to时间戳检索时过滤掉已过期文档同时写一个定时任务每天扫描一遍失效文档触发向量库的增量更新。另外我又加了一道知识时效性提示——如果检索到的文档距离最后更新时间超过 30 天就在 prompt 里提醒模型以下资料时间较早请谨慎引用。这道提示看起来像废话但它真的能减少模型对旧数据的自信程度。4.4 可观测性没有日志你无从下手前面说了可解释性这儿再展开讲。我做 context-mode 最大的心得就是这个功能必须做成白盒而不是黑盒。每次请求除了返回给用户的回答我还产出一条调试记录包含几个关键字段用户原始输入、意图识别结果、检索到的 top 5 上下文含ctx_id和分数、token 分配明细、最终注入的 prompt 全文。这些调试记录配合一个简单的查询界面让支持人员可以在用户反馈回答不对时直接看到那次回答的前因后果。有一次用户投诉说模型推荐了错误商品我们排查发现是检索时把无线鼠标的向量相似度排到了无线充电器前面原因是我们 embedding 模型对这两个词组的区分度不够。没有这条调试记录这种问题几乎不可能定位。我还建议你给 context-mode 做一个离线回放工具把线上真实请求重新跑一遍修改检索参数对比不同参数下的回答质量。我把这个工具做成了一个小命令行脚本调整一次权重跑一晚上第二天看对比报告。整个调参过程一下子就科学化了。5. 一点个人的体会这套 context-mode 从设计到上线前后改了三版。第一版只做对话历史拼接效果稳定但还是不够智能第二版加了三层上下文采集和混合检索效果上了一个台阶但 token 成本高了不少第三版引入预算管理、动态降级和调试记录最终在效果、成本、可维护性三者之间找到了平衡。我个人最想说的一点是不要把 context-mode 想成给模型加记忆的开关它是一个需要持续调优的编排系统。模型本身的能力固然重要但很多时候回答质量差的根因不在模型而在你喂给它的上下文是脏的、乱的、过期的。把上下文管好往往比换更强的模型性价比高得多。如果你打算在自己项目里做类似的功能我建议你从上手的第一天就把调试日志和离线回放工具做了别等出问题再补。这个教训是我用三个通宵换来的写在这里希望你能绕开。