context-mode：大模型上下文管理与模式切换实战

做内部文档问答系统那阵子，我差点被一份三万字的采购合同整到怀疑人生。用户输入“违约金条款怎么约定的”，系统把整份合同一股脑塞进上下文，结果窗口一满，恰好把最关键的违约条款截掉了，模型一本正经地编了一个答案。后来我把这套上下文处理逻辑单独拆出来，起名叫 context-mode——它本质上是一套“按需装载上下文”的路由模式，核心是替你判断当前这一次请求到底适合用哪种方式去喂给模型。这篇文章就来聊聊我为什么做它、怎么设计、以及落地中踩过哪些坑。如果你正在做 RAG 应用、智能客服或者 Agent 工具链，应该能从里面找到一些可以直接抄作业的思路。

1. 为什么要做 context-mode：一次长文档问答的翻车现场

1.1 翻车现场还原

那天用户问的是：“甲方逾期交货，乙方能主张哪些违约责任？”这句话本身没什么问题，问题出在链路实现上。我们把采购合同转成纯文本后没做任何切分，直接拼进 prompt，满心想着“窗口够大，模型肯定能看完”。结果上下文窗口 8K token，合同全文转出来有 11K token，尾部直接被硬截断。更要命的是，违约条款正好落在 9K token 以后的位置——也就是说，模型收到的内容里压根没有完整的违约约定。

模型的表现非常典型：它引用了一个看起来合理的条款编号，还引用了几句模棱两可的“通用违约责任”句式，但核心的赔偿比例、逾期天数、解除权条件全都不对。用户拿这个答案去走合同评审流程，差点出事。我后来复盘发现，这类问题在大模型应用里太常见了：不是模型不聪明，是喂给它的材料本身就是残缺的。

这个案例让我下决心把“上下文”这件事从被动塞满改成主动规划。所谓 context-mode，不是某个具体算法，而是我沉淀出来的一套上下文管理模式：在每次请求进入模型之前，先回答三个问题——这次任务应不应该加载长上下文；如果需要加载，加载哪些内容；加载之后用多少窗口留给模型发挥。只要把这三个问题想清楚，截断问题至少能消除大半。

1.2 上下文管理的三个经典难题

如果你也做过这类应用，大概率遇到过下面三个问题，它们彼此纠缠，很难单独解决。

长度限制导致的截断。所有模型都有上下文窗口，就算窗口涨到 200K，你依然会遇到超长文档。更反直觉的是，哪怕没有真正截断，把超长内容强行塞进去也会让模型的注意力被稀释，关键信息反而变得更不可靠。所以“窗口够大”从来不是正确答案，“怎么规划”才是。

相关性噪声带来的幻觉。有一类幻觉不是模型瞎编，而是上下文里装了太多无关信息。比如用户问的是“违约责任”，你把整份合同塞进去，模型在 11K token 里看到大量“保密条款”“知识产权”“争议解决”的内容，这些相关性噪声会把注意力从真正的违约条款上拉走。不少团队的 RAG 应用召回率做得还行，但最终效果差，问题就出在“召回了一堆相关片段，但没做好片段的取舍和排序”。

成本和延迟的失控。每次请求的 token 量直接决定费用和响应速度。我见过最极端的方案是把所有历史聊天记录、全部文档分片、外加一堆工具调用结果全塞进 prompt，一次请求烧掉几万 token。这在演示环境没什么，一上生产，账单和延迟立刻教做人。

这三个难题是 context-mode 的出发点。它不是要替代 RAG，也不是让你手工给每段文本打标签，而是提供一种“分模式装载”的思路：不同任务走不同的上下文组装管线，让有限的窗口发挥最大价值。

2. context-mode 的核心设计：三种上下文装载模式的选型逻辑

2.1 速读模式（Quick Mode）：小上下文快响应

速读模式是我最先定下来的。它适用于事实类问答，比如“这份合同是哪天签的”“这个接口的超时时间是多少”，这类问题通常只需要一个明确答案，不需要跨章节推理。

实现上，速读模式只做两件事：从知识库里检索出与 query 最相关的 1 到 3 个文本片段，然后拼上一个精简的系统提示词，直接交给模型。整个 prompt 控制在 500 到 1500 token 左右，响应速度通常在 1 秒以内，单次成本极低。

你可以把它理解成去餐厅点菜：你问服务员“今天例汤是什么”，他不需要把后厨整个食材仓库都搬到你面前，只需要走进后厨看一眼菜单板。很多团队做 AI 应用时有一种“不安全感”，总觉得给模型的材料越全越好，但模型不是越大锅越能做好菜，适量的精准材料反而输出更稳。

2.2 精读模式（Deep Mode）：大上下文全视角

与速读模式相对的，是精读模式。它适合全局性问题，比如“总结这份合同的主要风险点”“对比 A 方案和 B 方案的优劣”“分析这份财报的现金流趋势”。这些问题有一个共同特点：答案散布在全文多个位置，单纯靠 topK 召回很容易漏。

精读模式的装载策略是：对全文做一次预处理切分，然后把所有分片按文档顺序拼回一个超长上下文，一次性交给模型。这里有个容易忽略的步骤——长文本会被截断，所以不能“裸拼”，要有自己的分片、压缩、优先级排序流程。例如，先让一个小模型跑一遍全文，提取每个分片的摘要和关键数字，再把摘要和原文按重要度排序压入上下文。这种做法能让相同窗口下塞进去的信息密度高很多。

还是用餐厅类比：精读模式像做法庭案卷的完整阅卷，律师必须翻完所有卷宗才能给出综合判断。它慢、贵，但结论的全局一致性最好，适合低频但重要的请求。

2.3 动态检索模式（RAG Mode）：按需拼接

动态检索模式是我日常最常用的模式，也是大多数团队一上来就在做的方案。它介于速读和精读之间：通过 embedding 把 query 向量化，在向量库里召回 topK 个相关片段，经过重排后拼装成一个“临时上下文”。

RAG 模式的特点是灵活、生态成熟，几乎所有 RAG 框架都在做这件事。但我在实际使用中发现一个容易被忽视的问题：召回质量高不代表组装质量高。同样的 topK 片段，不同的拼接顺序、不同的去重策略，最后模型输出质量天差地别。我后面会专门讲这个坑。

这个模式适合“跨章节、跨文档”的问题，比如用户问“和 A 公司的合同里，付款条件对比 B 公司有什么不同”，你需要从两份合同里各召回几个片段再拼接。单个文档内部可以很快定位答案，但多文档场景必须靠检索串联。

2.4 三种模式的适用场景对比

为了自己方便，我做了一张对比表，现在贴出来供参考，你可以按业务特点调整：

2.5 为什么不能只选一种模式走天下

你可能想问：既然 RAG 模式已经这么成熟，为什么不用它处理所有请求？我最初也这么想，但实测下来发现三条硬伤。

第一，RAG 模式对全局性问题天然拉胯。让模型“总结全文风险点”时，检索出的 topK 片段往往是零散的，模型只能从片段里挤出结论，根本没有“全局视角”。第二，速读模式快，但碰到“请比较这两个条款的差异”就会力不从心，模型没有足够的上下文支撑推理。第三，精读模式准确但贵，如果每个请求都走它，成本直接翻几倍。

context-mode 的思路不是用某个单一模式解决所有问题，而是让系统先判断“这次请求更像哪种类型”，再分配合适的装载策略。相当于给系统建了一个智囊团：有专门跑腿的，有专门坐下来通读卷宗的，还有专门跑图书馆查资料的，每次派谁去由总调度决定。这个“总调度”就是 context-mode 的切换引擎，也是整篇文章最核心的部分。

3. context-mode 切换引擎的实现细节

3.1 整体架构与数据流

我的实现分四层：Query 解析器、模式判定器、上下文装配器、以及最底层的模型调用层。数据流是这样的：用户 query 先进解析器，提取出问题类型、涉及文档、目标章节等特征；接着模式判定器根据这些特征输出一个模式标签；然后上下文装配器按标签执行不同装载策略；最后才调用模型。

这里有一个总原则：模式判定尽量前置，最好在发请求之前就完成。我见过有些团队把模式切换做成“模型自己判断”，也就是让大模型决定自己需要多少上下文，这个方案听起来智能，实际上又贵又慢——你连上下文都没拼好呢，凭什么让模型判断自己缺什么？所以我的做法是用轻量规则加一个小分类器完成判定，整个过程在毫秒级。

为了控制复杂度，我还加了一个名为 ModeStore 的存储层，专门缓存已经装配好的上下文。同样的 query 再次出现时，不需要重新检索、重排、拼接，直接读缓存返回。

3.2 核心代码：模式定义与路由判定

下面这段代码是我的最小实现骨架，去掉了业务细节，保留核心逻辑。用 Python 写，定义枚举、特征提取和模式判定三块。

from enum import Enum from dataclasses import dataclass from typing import List class ContextMode(Enum): QUICK = "quick" DEEP = "deep" RAG = "rag" @dataclass class QueryFeatures: question: str doc_count: int # 涉及文档数量 query_len: int # query 字符长度 has_global_keywords: bool # 是否含“总结/分析/对比/概览/全部”等全局词 has_doc_refs: bool # 是否显式引用某个文档或章节 def extract_features(question: str, related_docs: List[str]) -> QueryFeatures: global_words = ["总结", "概括", "分析", "对比", "差异", "全部", "整体", "风险点", "主要", "发展趋势"] qlen = len(question) flag = any(w in question for w in global_words) return QueryFeatures( question=question, doc_count=len(related_docs), query_len=qlen, has_global_keywords=flag, has_doc_refs=("第" in question and "条" in question) or any(d in question for d in related_docs) ) def decide_mode(f: QueryFeatures, doc_total_len: int) -> ContextMode: # 单文档、短问题、无全局词 -> 速读 if f.doc_count == 1 and f.query_len <= 30 and not f.has_global_keywords: return ContextMode.QUICK # 多文档或显式引用不确定章节 -> RAG 召回 if f.doc_count > 1 or f.has_doc_refs: return ContextMode.RAG # 长文档 + 明确要求全局理解 -> 精读 if f.has_global_keywords and doc_total_len > 5000: return ContextMode.DEEP # 剩余情况默认走 RAG，安全兜底 return ContextMode.RAG

为什么这么设计？这里的关键不是“规则多精确”，而是“失败模式可接受”。QUICK 判错最多答不全，但成本低、可重试；DEEP 判错的代价高，所以只有在同时满足“全局词 + 长文档”时才触发；RAG 是兜底，因为它对各类问题的适应面最广，即使判错也不会太离谱。

3.3 上下文缓存与失效机制

context-mode 切换引擎里最容易被人忽略但又最值钱的部分，是上下文缓存。我的做法是按「文档 ID + 版本号 + 模式标签」做 key，把已经装配好的上下文块存进 ModeStore。比如精读模式处理完一份合同后，装配结果可以缓存半小时，同一份合同的再次“总结”请求直接命中缓存，省掉一次全文切分和压缩。

但缓存有个大坑：文档更新后，旧装配的上下文还在缓存里，模型会拿着旧条款回答新问题。我一开始没做版本管理，上线第二天就遇到生产故障：法务更新了合同版本，系统还在按旧版条款回答，用户差点按错误条款执行。后来我给每份文档引入 version 字段，文档上传或变更时自增，缓存 key 里带上 version，这样文档一更新，旧的上下文块自动失效，系统会重新装配。

顺带说一句，缓存失效不只是“过期时间”的问题，而是“业务版本”的问题。不要简单设一个 timeout，一定要从业务源头跟踪变更，否则再长再短的缓存都可能给你埋雷。

3.4 切换时机：阈值判断与置信度回退

模式判定器输出结果后，不代表万事大吉。我在实际使用中加了一个“置信度回退”机制：判定器除了输出模式，还会输出一个置信度分数。如果置信度低于阈值，就降到安全模式兜底。

举个例子：用户的问题是“合同提到专利费了吗”，query 很短、没有全局词，判定器倾向于输出 QUICK。但这个词“专利费”在知识库里对应了 17 篇文档，实际上是一个跨文档检索问题。这种情况我的判定器会检测到检索命中文档数过多，把置信度下调，自动回退到 RAG 模式，确保不会漏信息。

置信度回退是 context-mode 能在生产环境稳定运行的关键。我的经验是：宁可多花一点 token 切到更高一级的模式，也不要因为省 token 而漏答案。所以在阈值设定上，我倾向于“宽进严出”，让系统的默认行为更保守。

4. 实测结果与调优：省了多少 token、涨了多少准确率

4.1 评测数据集的构造

光有架构还不够，我得说服自己这套模式真的有效。我建了一个专门的小评测集，从业务知识库里挑出 20 篇文档，包括合同、产品说明书、内部制度，然后设计了 3 类 query 各 50 条：事实类（如“这个产品的保修期是多久”）、全局类（如“总结这份制度的审批流程”）、跨文档类（如“对比这两份合同的付款方式”）。

评测指标有两个维度：答案准确率（由业务专家人工打分，按 0-1 给分）和平均单次请求 token 消耗。延迟我也记录了，主要用来观察上下文装载对响应速度的影响。这套评测集在很大程度上改变了我的判断，因为数字比直觉可靠得多。

4.2 三种策略的实测指标对比

我分别跑了三个版本：全 DEEP、全 RAG、以及 context-mode 自动切换。结果是这样的：

仔细看就会发现，context-mode 的 token 消耗比全 RAG 多了 600 token，但准确率从 84% 涨到 89%，同时延迟还略有下降。原因很简单：全局类问题从 RAG 改走 DEEP 后准确率大幅提升，而事实类问题走 QUICK 后不仅省了 token，还因为上下文干净而减少了幻觉。多出来的 600 token 主要用在有回报的地方，非常值。

还有一个意外收获：全 DEEP 方案的准确率居然只有 78%，比全 RAG 还低。这就是我前面说的“注意力稀释”——全文塞进去之后，模型在超长上下文里迷失了重点。这进一步证明，上下文不是装得越多越好。

4.3 踩坑记录：上下文拼接顺序与污染

这块我要重点说，因为文档里基本不会写。第一个坑是拼接顺序。同样 5 个召回片段，按相关性从高到低排，和按文档原始顺序排，模型答案的准确率能差 10 个百分点。我测试发现，把最相关片段放在上下文最前面（紧跟系统提示词）效果最好，其次是放在最后面，最差的是把无关片段夹在中间。

原因其实也简单：模型对 prompt 开头和结尾的内容注意力更强，中间部分容易“被遗忘”。这有点像一个注意力曲线的天然倾向，所以装配上下文时必须把最重要的信息放到首尾。我现在写装配器时，默认把高置信度片段插到开头，低置信度片段按需放到末尾。

第二个坑是上下文污染。召回片段之间经常有语义重叠，比如两个片段都描述了同一条付款条款，放到一起后模型会误以为是两条，进而输出自相矛盾的答案。我加入了一个轻量去重：对候选片段做向量相似度计算，超过阈值就只保留其中一个。这个操作简单，但对答案稳定性的提升非常明显。

4.4 参数调优心得

几个关键参数值得细调。第一个是文本切分的重叠度。我最初用无重叠切分，段落边界正好把关键句子拦腰截断，召回质量很差。后来设置 10% 到 20% 的重叠，让每个 chunk 首尾能衔接上，召回效果立竿见影。但重叠也不是越大越好，重叠太多会导致召回结果里出现大量相似片段，反而增加去重压力和 token 消耗。

第二个是 RAG 模式的召回数量 topK。我试过 3、5、8、12 四档，最终发现 5 到 8 之间效果最好。低于 5 容易漏关键信息，高于 8 噪声开始明显增加，准确率不升反降。这个值需要结合你的知识库内容密度来定，文档越杂，topK 越要保守。

第三个是模式切换的阈值。我刚才提到判定器有置信度，实战中我会用一小批历史 query 做灰度验证，把那些“明明该走 RAG 却被判为 QUICK”的样本捞出来，调高相关特征权重。这个过程不需要复杂模型，每天看日志就能持续优化。

5. 落地时的工程化建议与后续扩展

5.1 路由可观测性：别让模式切换变成黑盒

很多人把 context-mode 做好路由后就不管了，这是大忌。我的习惯是给每次路由打一条结构化日志，记录 query、判定出的模式、置信度、缓存是否命中、token 消耗、延迟。这些数据攒起来之后，价值非常大。

比如我发现某天“DEEP 模式占比突然上升”，赶紧查日志，发现是某位同事新上传了一批超长合同，每条 query 都触发了全局词。但其中很多请求根本不需要全量阅读，只是用户习惯性说“帮我看看这份合同怎么样”。于是我调整了判定规则，让“怎么样”这种模糊表达默认走 RAG 而不是 DEEP，DEEP 占比立刻降了下来，整体成本下降 30%。

可观测性还有一个用途：人工复盘。每周抽几个判定错模式的样本，看是哪里判错了，是特征权重不对，还是缺了新特征。这种迭代方式比调模型参数更直接，反馈周期也短。我建议你上线第一周就把日志体系搭起来，不要等到出问题再补。

5.2 从文本扩展到代码结果与多模态

context-mode 这套“分模式装载”的思路不只适用于文本，我后来把它用到了代码和图像上。比如让 AI 分析一段代码时，Fast 模式只加载函数签名和调用关系，Deep 模式则加载整个文件以及相关依赖的接口定义。图像场景里，Fast 模式只读取 OCR 文本和低分辨率缩略图，Deep 模式才加载原图并做精细分析。模式切换逻辑几乎是通用的，只是每层的装配器不同。

如果你做了 Agent 系统，context-mode 还能和工具调用结果结合。每轮工具调用返回的内容都是“一段上下文片段”，你可以用模式判定来决定哪些片段保留、哪些丢弃。比如只读操作的工具结果走快缓存，写操作的结果则强制进入 Deep 装载，避免 Agent 基于残缺状态做决策。

5.3 与 Agent 系统的协同：让上下文成为可控资源

最后聊一点 Agent 方向上的想法。现在很多 Agent 框架会把所有中间推理步骤、工具调用结果、历史对话全部塞进上下文，导致窗口很快耗完。用 context-mode 的思路，可以给 Agent 的上下文设置“预算”：每条消息分配一个 token 配额，超配内容按重要度淘汰，而不是全量保留。这样 Agent 不会因为一个超长工具结果而丢失重要的用户意图。

我之前在做一个多步骤分析 Agent 时，就是把每步的中间结果按下发模式装入 ModeStore，Agent 需要时再按需取回。实践下来不仅 token 消耗减少了一半，任务完成率反而提升了——因为模型在每一步看到的上下文更聚焦，不会在无关的中间结果里打转。

我个人在这套系统上线后的体会是：context-mode 最大的价值并不只是省 token 或者提准确率，而是逼着你换一种思考方式——把上下文当成一种需要调度、预算、审计的资源，而不是一个无限大的垃圾桶。如果只能带走一个技巧，我会建议你先收集 30 条真实 query，人工标注每一条期望的模式，再拿这些标注去校准你的判定器。这 30 条样本比任何花哨的算法都更能让你的 context-mode 贴近业务，也是我在后续所有场景里始终依赖的第一步。