★ FEATURED ARTICLE 写“context-mode”这个项目得先把它放在一个真实场景里看做大模型应用的人早期通常手里只有一张提示词模板往里面塞一堆数据就开跑能跑通就谢天谢地。等应用真正上线、用户量开始涨问题就来了——同样的入口有的用户输入长文档有的用户聊了一百轮对话还有的用户需要实时查企业知识库你怎么让系统在同一个模型能力下既处理长文本又确保实时信息准确还不把上下文窗口撑爆我的答案是把“上下文”当成一种需要显式管理的模式来处理。这就是“context-mode”项目的由来。它不是一个神奇的模型也不是什么新框架而是一套把上下文从“隐式拼进 prompt 里”升级为“显式按模式组装和调度”的工程落地方案。本文适合正在做大模型应用、被 token 成本、上下文污染、记忆丢失等问题折磨过的开发者参考我会从模式分类、工程实现、边界条件和调优经验几个角度完整拆解。2. 为什么“上下文”需要模式化从隐式拼接到显式调度先说一个我在实际项目里反复踩到的场景。早期版本里我们把用户历史对话、企业知识库检索结果、系统指令全部塞进一个字符串模板然后丢给模型。初期用户少看起来没什么问题。等并发上来prompt 长度开始波动从 2k token 到 20k token 都有随之而来的就是三个问题第一token 成本失控同样的请求有的用户单次调用消耗量是别人的十倍第二模型输出的稳定性变差长 prompt 下模型经常丢失早期指令用户前面要求“用简体中文回答”聊到后面就开始夹杂繁体甚至英文第三上下文里到底哪些信息影响了模型当前决策完全不可控出了问题之后根本没法排查。这个问题本质上不是模型能力的问题而是上下文管理方式的问题。模型就像一个只能同时看一小块舞台的导演你把所有道具、灯光、台词全部堆在他面前他当然会看漏。所以我们需要一种机制让上下文能够被“标记”“分类”“按需加载”“自动淘汰”。这就是 context-mode 的核心思路把上下文从一段平铺的文本改造成带有模式标签的结构化数据流由运行时决定当前请求应当启用哪部分上下文。具体实施之前我给上下文模式做了几个维度上的定义维度可选值说明时间性static / session / realtime静态系统指令、会话内动态内容、实时查询结果聚合粒度global / user / task全局公共知识、用户画像、单次任务上下文来源类型rule / retrieval / generated硬编码规则、检索补充、模型中间生成消耗权重core / assist / discardable不可省略、辅助增强、可随时丢弃有了这几个维度上下文就不再是一团乱麻而是一组可以独立评估、独立处理的模块。这一步是整个项目的底层基础后面所有代码逻辑都是围绕这些维度设计的。3. context-mode 的模式分类与选择策略3.1 四种核心模式static、session、retrieval、computed在设计 context-mode 时我把上下文的加载方式归纳成四种运行模式分别对应真实场景里最常见的四种诉求static 模式是最容易理解的一种它处理的是“无论如何都要带上”的信息。比如系统提示词、功能说明书、惩罚性规则、回答格式要求等等。这类上下文的特点是恒定、无状态、可以被缓存。在实现时我直接把 static 内容预先编码成固定的 token 序列并放进一个独立的缓存层每次请求不再重复构造这样能省下不少 CPU 时间。session 模式处理的是多轮对话中的记忆。这里最核心的问题不是“有哪些历史消息”而是“哪些历史消息值得保留”。我见过太多人把整个聊天记录一股脑塞进 prompt然后祈祷模型能自己找到关键信息结果就是早期对话被遗忘、token 膨胀、模型在冗余信息里绕圈。session 模式的做法是每次对话结束后把这一轮的消息摘要化生成结构化的事件记录用户意图、关键实体、承诺动作只有最近 N 轮的原始消息会保留更早的消息全部替换成摘要只有用户主动追问某个具体细节时才临时把对应原始消息重新拉回来。retrieval 模式是面向知识库、文档库、实时数据这类外部信息的。它的逻辑很简单先从向量库里召回 Top-K 片段然后把召回结果按照与当前问题的相关性重新排序再拼装进上下文。但有个容易忽略的点召回结果不是越多越好。我一开始 K 取 10发现模型在长文档里严重分心经常把第 9 条、第 10 条里不相关的信息当作核心事实来引用。后来把 K 调到 5并加入相关性阈值过滤低于 0.72 的片段直接不进入 context效果立刻好多了。computed 模式是针对那些无法预先生成、需要实时计算的上下文。典型例子包括用户当前时区的问候语、实时库存状态、天气信息、动态计算出的权限范围。这类上下文必须在请求发生时即时生成而且只对当次请求有意义不需要持久化。computed 模式的核心优化点在于“最小化计算范围”比如天气信息只需要城市和日期两个字段没必要把完整的天气 API 响应塞进上下文。3.2 选择策略不是越全越好而是够用就好有了四种模式之后下一个问题就是一次请求到底应该启用哪些模式这里我给一个自用的决策矩阵不复杂但很管用。先从任务类型判断如果任务是单轮问答static retrieval 就够不需要 session如果任务是多轮对话static session retrieval 都要上但要为 session 设置预算上限如果任务是数据抽取或格式化输出computed static 够用retrieval 反而可能引入噪声。其次是预算控制。我给每次请求设了三层预算软预算建议 token 总量、硬预算最大 token 总量、紧急预算只允许 core 类上下文使用。当 session retrieval 的内容接近软预算时触发压缩流程优先折叠最老的 session 摘要到硬预算时直接丢弃 discardable 类内容并响应用户提示“部分历史内容已归档”。这套机制保证了同一个应用在不同输入长度下token 消耗的波动范围能控制在 30% 以内。最后是优先级排序。所有上下文模块都有一个加载序号序号越小越早放进 prompt。static 永远是第 0 位然后根据任务类型决定第 1 位是 retrieval 还是 session。为什么顺序很重要因为模型对 prompt 前部的注意力要显著高于中部和尾部也就是 lost in the middle 现象。越是核心的指令和当前任务最关键的信息越要靠前。4. 工程实现模块结构、缓存机制与调度流程4.1 核心模块划分整个 context-mode 项目我拆成了四个独立模块这样既方便测试也方便单独部署loader 层负责从不同数据源加载原始上下文包括对话存储、向量库、静态配置文件、API 接口。loader 的输出统一为标准化的 context_unit 结构包含 mode 标签、content、created_at、token_size、priority。assembler 层负责把 context_unit 按规则拼装成最终的 prompt。这个模块是策略核心包含了压缩、截断、排序、格式转换等逻辑。cache 层负责上下文的缓存与失效管理。static 内容永不失效session 摘要随对话更新失效retrieval 结果按查询类型设置 TTL。metrics 层负责记录每次请求的上下文构成包括 token 消耗、模式占比、命中情况、压缩率。这些数据是后续调优的依据。下面是我核心 loader 的一个简化实现示例展示了 context_unit 的基本结构from dataclasses import dataclass, field from enum import Enum from typing import Optional class ContextMode(str, Enum): STATIC static SESSION session RETRIEVAL retrieval COMPUTED computed dataclass class ContextUnit: mode: ContextMode content: str priority: int 0 token_size: int 0 metadata: dict field(default_factorydict) ttl: Optional[int] Nonetoken_size 不在加载时计算而是由缓存层在首次写入时通过 tokenizer 计算并保存避免每次请求都重复计算 token 数量。对于长文本这个优化能省下大量延迟。4.2 三级缓存设计缓存在 context-mode 里不是可选项而是必选项。我的设计是三级缓存第一级是进程内缓存用字典存储key 是 context_unit 的唯一 ID适合 static 和 computed 中那些频繁复用的结果。进程内缓存读取最快但不支持多实例共享。第二级是Redis 缓存用于跨实例共享 session 摘要和检索结果。Redis 的 key 设计成context:{mode}:{user_id}:{task_id}值存 JSON 序列化后的 context_unit并带有 TTL。session 摘要的 TTL 我一般设为 30 分钟超过 30 分钟没有活跃对话存储成本和不活跃风险都会上升。第三级是不可变快照用于 static 类上下文。static 内容一般会随产品版本更新而变化但单个版本内保持不变。我把 static 内容打包成带版本号的不可变对象请求时直接从快照读取。发布新版本时重新生成快照即可不需要清缓存。4.3 调度流程的伪代码一次请求进入 context-mode 后流程大致如下1. 接收请求解析出 user_id、task_type、query 2. 从 context registry 拉取该任务类型的策略配置 3. 按策略生成空上下文槽位顺序为 [static, 根据任务决定 retrieval 或 session] 4. 并行加载 - static loader 读快照 - session loader 读最近 N 轮原始消息并对更早消息读取摘要 - retrieval loader 执行向量检索过滤低相关片段 5. 合并所有 context_unit按 priority 排序 6. 计算 token 总量执行预算检查 如果超过软预算对 SESSION 中最旧的摘要进行二次压缩 如果超过硬预算丢弃 discardable 单元 7. 拼装最终 prompt 8. 请求模型 9. 响应后将本轮内容写入 session 存储触发摘要更新这套流程的关键在于第 4 步的并行加载和第 6 步的预算检查。并行很重要因为 retrieval 的向量查询一般有几十毫秒延迟如果和 static 加载串行执行整体延迟会翻倍。预算检查则保证了整个应用的 token 成本可控。5. 实测中的意外情况与排查链路5.1 session 摘要反噬模型把摘要当成原始事实这是我在实测中踩到的第一个坑。最初 session 模式会在第七轮对话后把早期消息替换为摘要结果发现模型会一本正经地引用摘要中的模糊信息比如摘要写“用户提到可能考虑云服务器”模型就回答“根据您之前提到的云服务器需求”但用户实际上说的是“暂时不考虑云服务器”。摘要丢失了否定词导致语义翻转。排查链路是这样的先看 metrics 层里哪一轮回答质量下降发现集中在第七轮之后然后对比同一问题的完整上下文输出与摘要上下文输出定位到摘要生成环节进一步检查摘要 prompt发现问题不在模型能力而在于摘要提示词没有强调“保留否定关系、转折关系、未决内容”。修复方式很直接在摘要生成指令中加入专门针对否定词和转折关系的检查规则并让摘要以结构化三元组输出事实 / 状态 / 时间而不是自然语言描述。5.2 retrieval 高亮片段带来的三重引用问题另一个高发问题来自 retrieval 模式。向量检索回来的片段往往带着原文的高亮标记比如**关键词**或自定义的em标签。这些标签一旦混进 prompt模型会误以为这是某种指令格式轻则输出格式异常重则把高亮标记当作要完成的任务。我一开始没有对检索结果做清洗结果模型在一次输出中居然复制了[摘要]标签用户端看到一堆方括号。修复方法很朴素但在检索管线里容易漏掉在 context_unit 写入前统一用正则剥离所有 Markdown 和 HTML 标记并且额外做一次 SQL 特殊字符转义防止检索内容里的引号破坏 prompt 结构。我建议把这个清洗步骤放在 retrieval loader 的返回值之后、context_unit 构建之前不要放在向量库入库阶段因为入库时清洗会损失原文的可读性影响检索效果。5.3 长会话崩溃预算触发但没有替代方案第三个让我比较头疼的情况是超长会话下 session 压缩失效。当用户连续聊了几十轮历史消息本身已经很长时即使触发压缩压缩后的摘要仍然可能超出预算。最初的实现里一旦超预算就直接丢弃最旧摘要结果用户突然问“我最早说的那件事怎么样了”模型一脸茫然。这让我意识到丢弃不是方案归档才是。后来我在 session 模式中增加了一个归档层压缩时不会直接删除旧摘要而是把旧摘要写入存档存储并在上下文中保留一个极简的“记忆索引行”比如“用户曾在第 1-20 轮讨论过项目 A 上线事宜”。当模型遇到用户询问早期内容时可以通过这个索引行触发检索从存档中精确拉取对应的原始摘要。虽然实现上多了一层存储但用户追问早期记忆的成功率从不到 40% 提升到了 85% 以上。6. 调优经验token 成本、响应质量与延迟的取舍6.1 目标用户画像决定静态上下文的粒度static 模式看似简单但粒度设计直接影响成本。我试过两种方式一种是给所有用户同一份大而全的系统说明另一种是根据用户画像和当前任务类型动态挑选 static 片段。前者的好处是逻辑简单坏处是每个请求都要搬运大量冗余 token。后者虽然灵活性高却需要维护一套规则映射表并且在冷启动阶段会漏掉某些必要的系统指令。我的最终结论是采用“两级 static”。第一级是所有请求都带的核心底座包括输出格式和通用行为规范大约 600 token第二级是任务相关的业务规则根据 task_type 加载大约 200-400 token。两级合起来比原来一刀切的 1500 token 少了一半而且因为指令与任务更匹配模型出错率反而下降了。6.2 延迟优化缓存命中率比模型快慢更重要如果你想降低端到端延迟很多人的第一反应是换更快的模型但在 context-mode 体系里缓存命中率才是延迟的大头。一次请求里如果 static 和 session 都命中缓存只有 retrieval 需要实时查询那整体的预模型时间可以压到 20ms 以内而如果缓存全部穿透光组装上下文可能就要 100ms。我统计过一个典型工作负载的缓存命中分布static 命中率 99%、session 最近五轮命中率 85%、retrieval 短 TTL 命中率约 40%。总延迟中缓存带来的节省占比接近一半。所以我的建议是先看 metrics 里的缓存命中数据再决定是否需要升级推理硬件。很多时候加一层 Redis 缓存比把模型从 7B 换成 70B 的收益更直接。6.3 质量调优为四种模式分别配置不同的生成参数最后一个调优心得是不同 context-mode 应当使用不同的生成参数。static 和 session 拼装出来的上下文是结构化的历史事实适合用较低的温度、较高的 top_p保证摘要和重写的稳定性retrieval 引入的外部知识则需要稍微高一点的温度让模型在综合多片段时更灵活computed 模式中的实时数据我倾向于直接用低温度避免格式漂移。这不是说在同一个请求里调用多次生成而是指在 context-mode 的调度器中为每个 context_unit 携带一套独立的 generation_hint 参数供上层推理服务参考。这样整个流水线既能保持上下文的稳定性又不至于因为统一参数让实时信息部分过于机械。7. context-mode 在不同业务场景下的接入方式7.1 客服机器人的接入实例客服机器人是我最早落地 context-mode 的场景。接入前的问题是用户问题高度相似但知识库条目多、更新快模型经常引用过期政策。接入后我做了三件事第一把客服政策拆成 static 版的“通用回答规范”和 retrieval 版的“具体条款”第二session 模式开启实时摘要用户的诉求变化第三computed 模式用于获取用户会员等级和订单状态这两类数据直接从订单系统同步不进向量库。效果方面token 消耗降低了约 35%因为不再把整个知识库片段全塞进 prompt。用户满意度提升则来自响应速度retrieval 命中高时模型基本不再编造政策细节。不过在接入时也付出了一些代价客服系统中政策文档更新频率高每次更新都要重新生成 static 快照这要求发布流程里加入快照重建的 CI 阶段。7.2 数据分析助手的接入实例数据分析类助手是另一个很有意思的场景。这类任务的上下文往往由表结构、数据样例、SQL 操作说明组成而且每轮对话都可能生成新的中间查询结果。早期没有 context-mode 时模型会在多轮后忘记表结构凭空造出根本不存在的字段名。接入时我先拆出 static 快照包含所有表结构定义retrieval 模式负责从历史查询记录中召回曾经成功过的 SQL 写法session 模式负责承载本轮迭代的进度摘要。computed 模式承担了最关键的任务把实时查询结果整理成紧凑的 markdown 表格放入上下文而不是把完整的数据集塞进去。这样模型既能看到真实样例又不会被几千行的原始数据淹没。7.3 写作辅助工具中的接入方式写作辅助工具相对简单但有个很特殊的点用户的写作目标会随对话推进持续变化。最初我只用 session 模式记忆用户题目和写作偏好但发现模型经常把早期草稿的结论当成用户最终观点。后来调整为先通过 computed 模式在每轮开始时生成一个“当前写作状态”的短句放在 session 摘要之前。这样模型永远先看到最新的写作意图再看到历史素材上下文重心从早期草稿转移到了当前需求。8. 我个人的复盘与再理解做 context-mode 这个项目最大的收获是我重新理解了上下文在 LLM 应用里的角色。以前总把上下文当成“给模型更多的信息”做出来才发现上下文真正要解决的问题是“给模型更少但更关键的信息”。模式化的过程本质上是在做信息熵的筛选决定哪些信息必须出现、哪些信息可以被压缩、哪些信息干脆不出现。如果你刚起步我建议不要一次性实现全部四种模式。先做 static 和 retrieval这两个最成熟、收益最直接跑通之后再加 session但一定要设计好摘要的否定信息保留最后才考虑 computed。工程实现的顺序很重要因为每一层都会暴露新的问题一次全上你会被各种交叉问题淹没。另外一个经验是一定要保留充足的 metrics 数据。我在早期没有记录每次请求的模式占比和 token 构成后来想定位成本问题时发现连基线都没有只好从头补。现在 metrics 里固定记录 mode_ratio、compression_rate、cache_hit_rate、budget_status 四个字段每次发布后的数据对比都能直接指出是哪个模式出了问题。最后想说上下文模式这个思路并不是什么高深理论它更像是对注意力的一种尊重模型的能力是有限的你的上下文越清晰模型的表现就越稳。把这份清晰用代码固化下来就是 context-mode 存在的意义。
阅读完成 · 觉得有帮助？
