我最近在做一个 AI 文档问答工具遇到了一个很不起眼但决定体验上限的设计问题context-mode中文叫上下文模式。说白了它就是控制“模型在这一轮回答里到底能看到哪些上下文”的开关。听起来很简单实际做起来却很绕同样一个知识库、同一个模型、同一份 Prompt只要上下文模式没设计好回答质量能差出一个数量级。这篇文章我想把 context-mode 背后的东西完整拆一遍为什么需要它、怎么划分模式、怎么做最小实现、落地时会踩哪些坑。无论你是在做 AI 应用、RAG 工具、Agent 编排还是单纯想把 ChatGPT 类产品用得更好都应该能从这里找到能直接上手的思路。1. 为什么 context-mode 值得认真设计1.1 一个让 AI“忽好忽坏”的隐形变量很多人有个错觉模型能力越强给它的信息越多回答就越好。实际并非如此。以文档问答为例用户打开一篇 8000 字的方案文档问“第三节提到的上线时间是什么时候”如果我把整篇文档一股脑塞给模型结果往往是模型被前面的背景、定义、名词解释带跑甚至把历史版本里的旧时间当成答案。这不是模型笨而是它不知道你希望它把注意力放在哪里。context-mode 就是在做这样一件事由产品或用户显式地告诉模型“你这次该看哪些材料”。它位于应用的输入组装层而不是模型内部。你可以把它理解成一个“信息闸门”在用户问题和模型之间控制信息暴露范围。这个环节一旦缺失模型就只能靠猜猜对了就是运气猜错了就是日常。我早期踩过这个坑为了省事把所有检索结果全部塞进 prompt结果单轮问答的准确率只有 60% 出头。后来把上下文按模式切分同样场景准确率到了 85% 以上。差别不在模型而在信息的组织方式。1.2 需求决定模式不同任务需要不同粒度的上下文设计 context-mode 之前先要理解一个事实不存在一个“万能上下文”能覆盖所有任务。代码修复和架构评审需要的上下文粒度完全不同客服知识库问答和多轮闲聊对历史的依赖也完全不同。如果没有模式概念产品就只能选择“最全”的那一档结果就是成本高、噪声大、响应慢。我在自己的工具里按任务类型区分了四种典型场景代码定位与修复需要当前文件里函数、类、依赖的局部上下文不需要整个仓库。文档内容问答需要当前文档的标题结构、章节正文、关键表格不需要无关目录。知识库检索问答需要检索出的相关片段以及片段的来源和置信度。全局架构理解需要项目摘要、模块地图、全局检索结果而不只是某一个文件。如果产品面向通用问答那 context-mode 至少要在“局部”和“全局”之间做切换。局部模式优先保证与当前内容的相关性全局模式优先保证信息覆盖度。两者无法互相替代因为它们本质上是两种不同的信息暴露策略。局部模式更贴近人类的“阅读习惯”切换到某个文件或某段内容时模型能基于附近的文本回答细节准确率很高但它看不到上下文之外的信息容易“一叶障目”。全局模式则相反它能覆盖更广的范围但信息密度被稀释模型容易给出看似周到却很空洞的答案。所以 context-mode 的核心问题是在正确的时间把正确的信息粒度暴露给模型。它不是简单的“加还是不加”而是“加多少、从哪里加、优先级怎么排”。2. 上下文模式的核心设计从模式划分到预算分配2.1 四种常见模式你至少要有这几种我在实践中总结了一套相对稳定的模式划分不复杂但很实用。每个模式本质上是一套“上下文装配规则”决定检索范围、历史长度、系统指令和过滤策略。为方便理解我把四种模式整理成一个对照表模式名称上下文来源典型场景主要风险对话模式当前消息 最近 N 轮历史闲聊、头脑风暴、轻量问答历史太长导致主题漂移文档模式当前文档全文或选区切片读代码、改文档、分析图表局部信息不足或过长截断知识库模式检索命中的 top-k 片段RAG 问答、客服支持、政策查询检索噪声导致幻觉全局模式项目摘要 全局检索结果架构评审、跨文件分析上下文稀释、回答泛化对话模式是最容易实现的但要小心“记忆幻觉”。很多人以为把最近 20 轮历史全部带上就行结果模型把 10 轮前的一个旧结论当成用户最新意图回答自然出问题。我自己的做法是只保留最近 5 轮原始消息更早的历史压缩成一段 200 字以内的“会话摘要”放在系统指令里。文档模式是代码助手和写作助手最常用的场景。它要解决的是“当前打开的文件太大塞不进窗口”的问题。我的方案是把文档按标题和段落切成带层级路径的块然后以当前光标位置或用户划线内容为中心取前后若干块组成局部上下文。这个模式特别适合“帮我看看这个函数为什么不 work”这类问题模型能看到函数定义、周边调用和注释但不会被仓库里其他文件干扰。知识库模式是 RAG 类产品的核心。这里的上下文来源不是用户当前文档而是检索系统返回的片段集合。关键点在于检索片段必须保留“可溯源性”比如原文路径、章节编号、片段得分这样模型在后续回答时能引用来源用户也更容易信服。全局模式看起来最“厉害”实际上最难用好。它需要把项目或知识库的全貌压缩成摘要再配合全局检索结果一起使用。我的经验是全局模式不要直接上“全文索引”而是先喂一个结构化概览比如目录树、模块清单、关键指标再把检索结果作为证据补充。否则模型很快就会被不相干的信息淹没。2.2 Token 预算别把窗口塞满设计 context-mode 最容易忽略的是 token 预算。模型窗口是有限的比如 128k 听起来很大但真正留给上下文的空间远没有想象中那么多。我一般按这个公式做初步规划可用上下文长度 模型窗口 - 系统指令 - 预留输出 - 用户问题 - 历史消息假设模型窗口是 128k系统指令占用 2k用户问题平均 0.5k历史消息 2k再预留 30% 给模型输出实际能塞给检索结果和文档切片的额度大约在 80k 左右。听起来还是很大但一个长文档分块后很容易超过这个量再加上检索结果经常返回 10 个片段每个片段 500 token很快就捉襟见肘。我在实际项目中会根据模式设置不同的预算上限对话模式总上下文不超过 4k token。文档模式切片上下文不超过 16k token。知识库模式检索片段不超过 24k token单个片段控制在 500 token 以内。全局模式摘要 检索结果不超过 32k token。这些数字不是拍脑袋定的而是根据用户反馈和失败样本调出来的。核心原则是优先保证“最关键的信息”完整进入上下文而不是试图把所有信息都塞进去。模型不擅长在大量低信号信息里找高信号点所以应用层应该先把高信号信息挑出来而不是把挑的任务交给模型。2.3 切换策略手动、自动与意图路由模式设计好之后还要考虑用户如何切换。最粗暴的做法是做一个手动下拉框让用户自己选。这个方案适合工具类和开发者产品因为用户清楚自己是在看单个文件还是全局检索。手动模式的好处是可控、可预期、易调试坏处是大部分人根本不会去切换默认模式如果不对体验就直接崩掉。因此更现实的做法是“自动检测 显式覆盖”。自动检测可以用一组轻量规则实现比如用户消息里提到了当前文件名就走文档模式消息里出现“项目有哪些模块”这类汇总性问题就走全局模式其余情况走知识库模式。规则不适合的场景可以再用分类模型判断但我不建议一开始就上模型路由因为训练数据和评估体系没建立之前自动路由的误判率会很高。更进阶的切换策略是“意图路由”也就是把 context-mode 选择当成一个独立任务由大模型或小模型在调用主模型之前先做一次分类。比如用户说“帮我概览一下平台的整体架构”意图分类器会输出“global”用户说“把这段代码改成异步实现”会输出“document”。意图路由的好处是不需要用户主动操作坏处是多一次模型调用成本和延迟都会增加。我的建议是分三步走先做手动切换保证功能可用然后用规则做自动检测并在 UI 上明确显示当前模式给用户修改入口最后等积累了足够日志再训练一个轻量分类器做意图路由。直接跳到第三步很容易出现“模式选得不对、用户又不知道怎么改”的尴尬局面。3. 从 0 到 1 实现一个可用的 context-mode3.1 最小可运行结构枚举、装配器、策略很多教程上来就讲 RAG、向量数据库、rerank但 context-mode 的最小实现其实不需要这些东西。你可以用不到 200 行代码先跑通一个包含模式枚举、上下文装配器和检索策略的版本。下面是我经过几轮迭代后比较稳定的一种结构用 Python 写出来大概是这样from dataclasses import dataclass, field from enum import Enum from typing import Optional class ContextMode(str, Enum): CHAT chat DOCUMENT document KNOWLEDGE knowledge GLOBAL global dataclass class ContextRequest: mode: ContextMode user_query: str current_doc: Optional[str] None history: Optional[list] None extra_kwargs: dict field(default_factorydict) dataclass class ContextBlock: tag: str # 来源标记system/doc/knowledge/conversation content: str score: float 1.0 metadata: dict field(default_factorydict)这里的核心不是数据结构而是“ContextBlock”这个概念。它把上下文拆成多个带标签的块而不是一锅乱炖。tag 决定了提示词里怎么描述它score 决定了预算紧张时它会被优先保留还是优先丢弃metadata 则记录文件路径、页码、时间戳等信息方便排查问题。接着需要一个装配器把 ContextBlock 列表按模式组织成最终 prompt。伪代码如下def assemble_prompt(req: ContextRequest, budget: int) - str: blocks [] if req.mode ContextMode.DOCUMENT and req.current_doc: blocks.append(make_doc_blocks(req.current_doc, budget)) elif req.mode ContextMode.KNOWLEDGE: blocks.append(make_knowledge_blocks(req.extra_kwargs[retrieved], budget)) elif req.mode ContextMode.GLOBAL: blocks.append(make_global_summary(req.extra_kwargs[summary], budget)) blocks.append(make_knowledge_blocks(req.extra_kwargs[retrieved], budget)) if req.history: blocks.append(make_history_block(req.history, budget // 4)) blocks trim_blocks(blocks, budget) return render_prompt(req.mode, req.user_query, blocks)你注意看doc 模式只处理当前文档不会去碰知识库knowledge 模式只看检索片段不看当前文档global 模式则是“摘要 检索结果”的组合。这种“各干各的”设计能避免模式之间互相污染。很多失败的 context-mode 实现问题就出在模棱两可既放了文档又放了检索结果结果模型不知道该信谁。3.2 检索与重排决定哪些片段能进入上下文知识库模式和全局模式都离不开检索。如果检索拿回来的片段质量不好context-mode 做得再精细也没用。我最早只用一个向量召回器用的是 OpenAI 的 embedding 接口效果在大多数场景还过得去但遇到术语稠密的文档就容易翻车。原因很简单向量检索擅长捕捉语义相似却不擅长精确匹配比如“context-mode”这个复合词如果被拆成 “context” 和 “mode” 两个子词去匹配很容易召回一堆不相干的内容。后来我采用了一个简单的 hybrid 方案同时用 BM25 做关键词召回和向量模型做语义召回再用一个加权公式把两路分数合并。合并公式不要搞太复杂我用的就是最基础的final_score 0.4 * bm25_score 0.6 * vector_score权重可以根据业务微调但核心思路是让“精确匹配”和“语义理解”都能影响最终结果。召回之后还需要对候选片段做重排。重排器我一般用 cross-encoder 模型它的特点是把“查询 片段”拼在一起计算相关性比单纯把查询和片段分别向量化再算相似度的双塔模型更准但也更慢。所以重排只作用于召回的前 50 个候选不会作用于全库。在文档模式里检索不是唯一的信息来源。更常见的是“滑动窗口切片”把当前打开的文件按 500 token 切成带重叠的窗口以光标所在位置或用户选中文本附近的窗口为中心向前取两片、向后取两片组成局部上下文。这样做的好处是模型能连续看到前后文不会因为硬切而丢失函数定义或段落结构。切片时我会保留原始行号和代码块边界方便后续转成提示词里的“片段[3]”引用。3.3 提示词组织让模型正确使用“模式”有了上下文内容还要把它们组织成模型能理解的提示词。这里有个容易犯的错误把参考片段直接堆在问题后面不做区分。模型很可能分不清“这是参考材料”还是“这是用户消息的一部分”从而把参考材料里的错误信息当作事实。我的提示词模板大致如下你现在处于 {mode_name} 模式。 以下是与你任务相关的参考信息如果其中包含答案请优先参考如果信息不足请明确说“根据现有信息无法确定”。 参考片段 [1] file: docs/context-mode.md, line 24-45 ...片段内容... 历史会话摘要 ...不超过200字... 用户问题 {user_query}注意我特意写了“如果信息不足请明确说无法确定”而不是“必须严格根据参考信息回答”。原因是后者会抑制模型利用自身常识的能力遇到检索不完整时反而答得越坚决越错。更好的做法是给模型一个“优先级”参考信息 历史摘要 自身常识。另外每个参考片段前面要带上来源标记。这个标记对最终用户可能无感但对调试非常关键。当模型出现幻觉时你能直接看出它到底引用了哪一个片段当检索结果本身有误时你也能快速定位是哪一路召回或重排引入的问题。4. 落地中的常见问题与排查技巧4.1 上下文过长关键信息总被截断这是最让人头疼的问题。我一开始以为把检索结果按得分从高到低排好就行但实际发现得分最高的片段往往不是模型最需要的。比如用户问“项目什么时候上线”得分最高的片段可能是一个含“上线”关键词的测试用例而真正讲上线时间的里程碑文档排在第二位结果预算不够被截断了。解决思路不是“截断”而是“分级”。我会先把所有待入上下文的块按来源、得分、信息量做一次排序再按预算从优先级最高的块开始塞。对文档和知识库两种模式还要额外做“去重”同一个语义内容在多个片段里重复出现时只保留包含信息最丰富的那个。常用做法是用 MinHash 或简单的高频词重叠率去重效果虽不完美但足够实用。另一个技巧是在代码块实现里做“渐进式截断”如果预算还剩 10k先把每个片段的开篇和结尾保留中间用一句“此处省略 N 字”代替。很多重要结论往往在段落开头这样能在有限预算内保留最多信号。当然这个策略只适合提示词场景不适合给用户展示原文。4.2 模式选错AI 像“失忆”自动切换模式后最常见的失败是用户明明在问当前文档里的某段代码系统却因为消息里一些宽泛的词误判成了知识库模式。结果模型完全无视用户正盯着的那份文件去知识库里找了一段类似但错误的内容回答自然牛头不对马嘴。排查这个问题我建议给每次请求都记录一个“模式日志”包括判定模式、判定依据、实际使用的上下文块列表、模型最终输出。然后定期抽样错误案例你会发现 80% 的问题都出在“规则优先级”上。比如用户选中文本后提问应该强制优先走文档模式而不是先走意图分类。这个“显式信号优先于隐式信号”的原则可以事先写进规则里。另外在 UI 上一定要露出“当前模式”提示。用户发现自己问错了范围时第一时间能手动切到正确的模式比任何自动纠错都有效。我见过很多产品把这个细节藏得很深导致用户根本不知道有模式切换这是非常可惜的。4.3 检索噪声引发的幻觉知识库模式还有一个经典坑检索结果看似相关实际上引入了一堆互相矛盾的片段。举个例子同一套系统里有两个文档一个说“默认超时时间为 3 秒”另一个说“重构后默认超时时间为 5 秒”如果检索结果同时命中这两段模型就会无所适从可能给出一个四舍五入的“4 秒”纯属幻觉。我后来定了几条规则第一检索片段数量不要贪多top 5 就够留更多空间给每个片段的完整内容第二重排后如果两个片段语义重复度超过阈值只保留得分更高的那一个第三在提示词里明确要求“当参考信息存在矛盾时指出矛盾并说明不要强行调和”。第二条和第三条结合能让模型的幻觉率下降很多。但最根本的解法还是提高检索质量。我在项目中会对索引切分做“段落感知”不在固定的 500 token 处硬切而是以标题、列表、代码块等完整语义单元为边界进行切分。这样检索出来的片段才更像一个完整论点而不是从句子中间断开的文字碎片。4.4 成本与延迟优化context-mode 会让每次请求多出“检索、重排、上下文装配、模式判定”等多个步骤如果不加控制延迟和成本都会翻倍。我的优化经验主要有三点缓存检索结果同一份文档、同一类查询在 30 分钟内复用检索结果能省掉大量 embedding 调用。分段延迟加载对话模式不需要走检索那就不要为它初始化知识库索引按需加载能明显降低首响时间。重排放到异步链路对延迟敏感的场景可以先返回 BM25 向量召回的 top 5 结果重排只在得分接近时触发避免每次都跑 cross-encoder。成本方面我会在日志里记录每次请求的输入 token 数和检索调用次数按模式统计。如果你发现某个模式的平均输入 token 比预算高出 20%那一定是装配器里的裁剪逻辑出了问题需要回去看是不是某个片段超了。4.5 问题速查表现象可能原因快速排查方向模型回答内容正确但信息太旧缓存了旧版本的文档或检索结果检查缓存 key 是否包含文档版本号问当前文档却答了别名系统内容模式误判为知识库模式优先走“当前文档 用户选中区域”信号上下文长度超出模型限制没有按 token 预算裁剪查看日志里实际 token 数调整 trim 策略回答出现两段内容互相矛盾检索到多个冲突片段增加去重规则和“冲突声明”提示模型回答太笼统、缺少细节全局模式信息密度不足增加项目摘要中的结构信息减少泛泛描述多轮对话里丢失最新信息历史截断过早保留最近 2-3 轮原文再压缩更早历史5. 从 context-mode 到更大的记忆系统5.1 让模式感知状态从开关到路由当我跑通了最基础的 context-mode 之后发现它真正的前景不在“手动切换”而在于“状态感知”。用户不会一直用同一个模式他们在同一个会话里可能先问文档细节再问整体架构过一会儿又回到具体代码。模式在这里变成了一个动态变量应该随用户意图和对话状态变化。于是我开始把 context-mode 往两个方向扩展一是把模式判定交给一个更小的专用模型输入用户当前消息、历史摘要、当前打开文件元数据输出一个模式标签。这样既保留可解释性又比大模型意图分类快得多。二是把“模式”这个概念抽象成“上下文策略”不只是单选而是一个带权重的组合。比如在全局模式下如果用户又选中了一段代码那就应该让全局检索和局部代码块的权重同时存在而不是二选一。更进一步context-mode 还可以和 Agent 工具结合。当一个 Agent 决定调用某个工具时它自己也知道应该切换上下文模式比如调起文件读取工具时自动进入文档模式调起搜索工具时自动进入知识库模式。模式不再是用户界面上的一个控件而是 Agent 执行链条中的一个状态。这是我在后续版本里最想完善的方向。5.2 我的几点实操心得第一从手动模式开始别一上来就做全自动。原因很简单自动模式需要评估数据而评估数据在手动模式下才能积累起来。先让用户明确选择记录他们的选择结果和后续反馈再据此训练自动切换模型这比拍脑袋设计规则可靠得多。第二把 context-mode 做成“白盒”。每次请求都输出一张上下文卡片显示当前模式、预算、用了哪些块、每个块的来源和得分。我在排障时无数次靠这张卡片救场它比任何日志分析都直观。你甚至可以把这个卡片做成前端可展开的调试面板对用户透明度极高也能减少“AI 胡说”的投诉。第三不要用“更全的上下文”掩盖糟糕的检索。如果检索就返回了错误片段那么无论 context-mode 怎么设计模型都会被带偏。先把检索、重排、去重做好再谈上下文模式优先级不能反。第四评估指标不要只看“回答正确率”还要看“信息误用率”。也就是模型有多少次回答引用了错误文件或过期信息。这个指标比准确率更敏感能直接反映 context-mode 的信息隔离是否有效。我常用的人工抽样方式是每个模式抽 50 条线上日志检查模型回答里的引用是否真实存在于上下文块中。最后再分享一个小技巧在提示词末尾增加一行“当前模式: {}参考信息来源: {}”让模型在必要的时候能主动解释自己为什么根据某段信息做出回答。这行看似多余但能让模型在信息不全时更倾向于承认不确定性而不是强行编造。context-mode 的本质不是限制模型而是替用户把世界整理好让模型在正确的舞台上演戏。