最近调试AI应用的时候我翻了不少项目的源码和配置文档发现context-mode这个字段出现的频率越来越高。不少朋友在群里问这到底是干嘛的是必开项吗怎么配置才能让效果最好说实话这个功能在不同工具里的叫法和表现都不太一样但核心逻辑只有一个——让处理模型在正确的时机只看到该看的上下文屏蔽掉无关信息。听起来简单真正落地的时候牵扯到上下文结构、窗口裁剪、任务分类和容错设计踩过的坑比想象中多。这篇文章不聊虚的直接把我对context-mode的理解、自己在项目里的实现方法和排障经验拆开讲清楚。不管你是AI应用开发者、RAG系统研究者还是重度使用AI工具的产品经理这篇文章都能给你一些能直接抄作业的参考。1. context-mode不是玄学是工程问题1.1 从模式到上下文边界——这个词到底在说什么context-mode直译过来是上下文模式。我第一次看到这个词是在一个开源翻译插件里它的意思是根据光标所在的场景决定把哪个段落当作参考上下文。后来在IDE的代码补全工具里又见到含义变成了代码片段关联性识别——你在函数A里写代码时它不会把整个项目的源码都塞给模型而是精挑细选出和函数A相关的部分。到了大模型应用时代这个词的含义收敛到了一个更精确的方向上下文窗口内的信息选择策略。你可以把模型的上下文窗口想象成一张有限大小的白板白板上写什么、写多少、保留哪个部分决定了模型看着什么来回答。context-mode就是管理这块白板的规则集合。生活里其实有非常贴近的类比。你上班时脑子里装的是项目进度、周报要点、会议纪要回到家之后如果还一直想着工作细节整个人会很累。人脑会自动切换工作模式和生活模式切换的实质是注意力范围的收放。context-mode做的事情完全一样——只不过对象换成了模型它不会自己判断什么该看什么不该看需要你通过显式的配置去约束。1.2 没有上下文模式AI应用会出哪些乱子很多人刚开始接大模型API的时候都是把所有内容一股脑塞进prompt里多给点信息总没错。这个思路在demo阶段勉强能用到了生产环境就处处拉胯。无关联噪声污染你问模型帮我总结这段客服会话结果prompt里塞了50页产品文档模型会被无关信息带偏总结出的内容混杂着文档里的营销话术可用性极低。上下文窗口溢出多轮对话场景下历史消息每轮累加很快就把窗口撑爆。系统不得不粗暴地把最早的消息丢掉结果用户三句话前提过的需求被遗忘了。成本失控现在主流模型的token计费都是输入输出双向收费。你不做上下文管理每一轮都把全部历史重发费用呈线性甚至超线性增长跑一个月账单会非常难看。响应延迟飙升喂给模型的token越多首字延迟越明显。实测同样一段任务2k上下文和32k上下文响应速度可能差出一倍以上。这些问题的根源都指向同一个点模型的上下文空间是稀缺资源而你在不加管理地挥霍它。context-mode就是在这种背景下被推到台前的——它的本质不是某个API参数而是一整套围绕上下文窗口的管理策略。2. context-mode的核心构成三层结构、权重关系和边界判断2.1 把上下文拆开看指令、历史、事实三层想要设计好context-mode第一步得把上下文这个黑盒拆开。我习惯把它分成三个逻辑层每一层的来源、作用和对最终结果的影响权重都不同。层级内容来源核心作用常见问题指令层系统提示词system prompt、任务描述定义角色、能力边界、输出格式写得太长会挤占其他层空间历史层多轮对话记录、用户行为轨迹保持对话连贯性、捕获隐含意图无限累积导致窗口溢出事实层知识库检索结果、工具返回数据、文档片段提供具体依据、减少幻觉与问题相关性不足时反而干扰判断这三层之间不是均等关系。大部分场景下指令层优先级最高因为它是模型行为的宪法事实层优先级次之决定了回答有没有依据历史层优先级相对灵活距离当前时间越近的消息越重要越久远的越可以裁剪。有一个很典型的反面教材我见过有人把整个公司规章制度放进system prompt洋洋洒洒三千字结果真实的任务指令和知识片段挤在剩余空间里模型回答出来的东西又长又空。这就好比白板三分之二都画了装饰性的花边真正要计算的公式反而没地方写了。2.2 context-mode的决策规则什么时候全量保留什么时候果断清空设计context-mode最关键的不是怎么存上下文而是**什么时候用哪一层、什么时候丢掉哪一层**。我根据任务的延续性把场景分成三类每类的处理策略完全不同延续型任务例如多轮客服对话、代码重构会话、长文写作。特征是下一轮的输出依赖上一轮的结果。这种场景历史层必须保留但需要做窗口滑动——只保留最近N轮早于N轮的内容转成摘要。独立型任务例如单次翻译、单次分类、单次绘图。特征是任务之间互不依赖。这种场景历史层可以直接清空只保留指令层和当前输入省token又提升响应速度。检索型任务例如知识库问答、文档分析。特征是需要外部事实支撑。这种场景事实层是主角历史层甚至可以完全不上——用户问一句话系统检索出相关片段拼上指令算完收工不需要知道用户昨天问了什么。每次调用模型之前先问自己这个请求属于哪一类然后再决定组装什么上下文。我见过很多失败的context-mode配置问题都出在一刀切上——不管什么请求都携带全部历史结果检索型任务被历史干扰独立型任务白白烧钱。3. 从零实现一个轻量context-mode代码、参数和裁剪算法3.1 数据结构和上下文构建器怎么写理论说了一堆真正动手的时候你会发现问题全在细节里。我写了一个非常精简的Python实现用来管理发送给模型的上下文消息列表。核心数据结构就两个消息体、构建器。from dataclasses import dataclass, field from typing import Dict, List, Optional, Callable dataclass class ContextMessage: role: str # 枚举值system / user / assistant / tool content: str meta: Dict field(default_factorydict) # 扩展字段记录时间戳、来源等 class ContextBuilder: def __init__(self, max_tokens: int 6000): self.max_tokens max_tokens self.messages: List[ContextMessage] [] self.system_prompt: Optional[str] None def set_system_prompt(self, prompt: str) - None: self.system_prompt prompt def add_message(self, role: str, content: str, **meta) - None: self.messages.append(ContextMessage(rolerole, contentcontent, metameta)) def build(self) - List[Dict[str, str]]: 组装最终发送给模型的上下文消息数组 result [] if self.system_prompt: result.append({role: system, content: self.system_prompt}) # 对历史层做窗口裁剪只保留最近窗口的消息具体裁剪在下一节实现 trimmed self._trim_by_window(self.messages) for msg in trimmed: result.append({role: msg.role, content: msg.content}) return result这段代码本身没什么高深的但它框定了context-mode的边界上下文不是裸字符串而是一组带元信息的消息。meta字段很重要项目跑起来之后你会发现单单一条这条消息是什么时候产生的就能帮你解决很多定位问题。3.2 token预算和窗口滑动裁剪算法任何context-mode都绕不开token预算。不同模型的计费规则不一样你需要知道当前使用的模型多久吃光一个窗口。最简单的token估算方式是用tiktokenimport tiktoken def estimate_tokens(text: str, model: str gpt-4) - int: try: enc tiktoken.encoding_for_model(model) except KeyError: enc tiktoken.get_encoding(cl100k_base) return len(enc.encode(text))有了token估算器裁剪算法就顺理成章了。我实践下来最稳定的是层级预算分配 尾部保留策略为系统提示词划出固定预算推荐800~1200 token足够写清角色和规则又不造成浪费。为事实层划出动态预算根据任务的检索结果量上下浮动。历史层用滑动窗口从最近的消息往前扫描塞得下就保留塞不下就停。滑动窗口的具体代码class WindowSlidingContextBuilder(ContextBuilder): def __init__(self, max_tokens: int 6000, keep_recent: int 10): super().__init__(max_tokens) self.keep_recent keep_recent def _trim_by_window(self, messages: List[ContextMessage]) - List[ContextMessage]: # 策略一简单尾部截断保留最近N条 if len(messages) self.keep_recent: return messages return messages[-self.keep_recent:] def build(self) - List[Dict[str, str]]: result [] budget self.max_tokens if self.system_prompt: result.append({role: system, content: self.system_prompt}) budget - estimate_tokens(self.system_prompt) # 从尾部往前扫描尽量保留更接近当前问题的消息 kept [] for msg in reversed(self.messages[-self.keep_recent:]): msg_tokens estimate_tokens(msg.content) if budget - msg_tokens 400: # 预留安全值防止算满 kept.append(msg) budget - msg_tokens else: break return result [{role: m.role, content: m.content} for m in reversed(kept)]这里有几个细节容易栽跟头务必注意keep_recent不是越大越好。我试过设置成50窗口照样爆因为多轮长消息的token累积远超预期。要根据业务单轮消息的平均长度去反推轮数。预算要预留安全边界不要让消息精确填满窗口。模型输出也要占token把窗口用到100%会导致请求直接报错。尾部的用户最新问题一定要保留这是不可裁剪的硬性上下文。裁剪掉用户当前问题会让模型失去任务锚点。3.3 多模式如何共存短对话、长文档、多轮工具调用一个生产级的应用往往不止一种场景。我维护过一个客服机器人同时承载三种context-mode闲聊模式、工单分析模式、知识库问答模式。它们的差异很大闲聊模式历史层保留最近6轮不需要事实层指令层非常简短。预算分配大约是 system 500 历史 1200 输入 300。工单分析模式事实层是核心需要从工单系统拉取字段、附件摘要、历史处理记录。历史层几乎不保留。预算分配大约是 system 800 事实 3500 输入 500。知识库问答模式事实层来自检索系统topK片段需要做相关性过滤——检索返回的前三条不一定都相关这里我给每段检索结果打一个相关性分低于阈值的直接丢弃。预算分配大约是 system 600 事实 2500 历史 800 输入 300。三种模式共存在一个服务里不可能用同一套context-mode配置。所以实际架构中我抽出基类每个模式继承后重写_trim_by_window和build方法。有朋友问过能不能用一个大而全的配置覆盖所有场景答案是能跑但效果会大打折扣——就像你不可能用同一套穿衣策略同时应对办公、爬山和参加婚礼模式切换的本质就是给不同任务做不同的资源倾斜。4. 四套经过实战检验的上下文策略4.1 窗口滑动策略实时对话场景的保底方案适用场景在线客服、聊天机器人、语音助手。策略核心是保近丢远实现成本最低效果最容易预期。我自己的配置经验keep_recent设在6~12之间token预算不超过总窗口的50%。在gpt-4o这类模型上6000 token预算下历史层最多占3000剩下的留给当前输入和事实层。这个策略最大的弱点是久远但重要的信息会被丢干净——用户10分钟前提过一个关键约束比如预算不能超过2000元窗口滑动后这条约束没了模型瞬间失忆。针对这个问题有两个兜底方案一是把对话关键节点用户约束、决策结论手动提升为永久消息不参与裁剪二是配合下面的摘要压缩策略把被踢出窗口的消息浓缩成一句话摘要继续保留。4.2 摘要压缩策略长文档分析的必由之路适用场景论文分析、长合同审核、竞品调研。策略核心是先压缩再使用。具体操作流程分三步第一步把源文档按章节或固定长度切片每片独立调用模型生成一段摘要控制摘要长度在原文的10%左右。这个步骤可以离线批量处理做成缓存避免重复消耗。第二步把生成的摘要列表作为事实层上下文让模型基于摘要进行推理。需要引用原文细节时再根据相似度检索原文片段补充。第三步每次新对话只携带摘要列表和高亮片段历史层几乎不参与。实测下来一份5万字的研报压缩成3000字摘要后模型依然能回答第二章主要讲了什么竞品定价策略对比这类需要跨章节理解的问题。这个策略对压缩质量非常敏感。我踩过的坑是摘要压缩太狠导致关键数据丢失模型在没看到具体数字的情况下一本正经地编输出和原文矛盾。后来我在摘要指令里明确写保留所有数字、专有名词、百分比并用规则检查压缩文本中的数字是否包含于原文不包含就强制重新摘要问题才算解决。4.3 检索增强策略知识库问答的正确姿势适用场景企业知识库、产品文档助手、法律条款检索。策略核心是让模型只看相关的那几块拼图。RAG链路中context-mode的威力集中体现在检索后的取舍上。很多项目天然流程是用户提问 → embedding检索 → topK片段直接拼接 → 发送模型。问题在于topK片段来自不同文档相关性参差不齐噪声片段会让模型回答偏离用户问题。我的做法是在检索后加一道相关性重排def rerank_fragments(query: str, fragments: List[str], threshold: float 0.45) - List[str]: 简易重排对每个片段与query做相似度打分过滤低于阈值的片段 vectordb get_vectordb() # 假设有一个embedding向量库实例 query_emb vectordb.embed(query) scored [] for frag in fragments: frag_emb vectordb.embed(frag) score cosine_similarity(query_emb, frag_emb) scored.append((score, frag)) scored.sort(reverseTrue) return [frag for score, frag in scored if score threshold]阈值需要根据自己的检索质量标定。检索质量高比如ES的BM25和embedding双路召回阈值可以调到0.5检索质量一般就调到0.35宁可多留一个片段也不能把关键信息漏掉。事实层固定住了模型回答的准确率会有一个肉眼可见的提升。4.4 结构化指令策略代码生成和工具调用的关键适用场景代码补全、SQL生成、Function Call。策略核心是用固定结构和格式约束模型行为。这个策略和其他三个不太一样它的重点在指令层的结构设计。在context-mode里我把生成SQL的指令设计成固定模板你是一个SQL生成器。任务背景 {tables_and_columns} 用户需求 {user_input} 输出格式 只输出SQL语句不输出任何解释。 约束条件 1. 只允许读取表 {allowed_tables} 2. 禁止使用DROP/UPDATE/DELETE 3. 如果需求不明确输出一个包含#说明的占位SQL。模板的好处是让模型在有限上下文里快速进入稳定状态。如果每次的指令措辞都不一样模型会花token去理解你到底要怎么输出输出格式也容易漂移。结构化之后输出稳定性和可解析率大幅提升下游程序可以安全地直接执行。5. 实战中四个高频坑附排查建议速查表5.1 坑一上下文塞满导致模型假装权威这是所有坑里最隐蔽的一个。模型在上下文信息不足时很少直接说我不知道而是顺着你的话头往下编。症状是回答流畅无比但细节错误尤其在长文档分析场景最常见。我排查的思路是先在构建器中加一段日志记录每次请求的最终消息数组和token分布然后在线上错误反馈中抽查了十几条发现凡是回答出错的请求事实层token普遍低于会话层token。说明事实层信息不够模型在靠历史对话硬撑。解决办法很简单调高事实层预算调低历史层预算让模型有据可查而不是凭感觉接话。5.2 坑二裁剪后对话上下文不连贯用窗口滑动策略一段时间后会发现某些轮次模型突然失忆——明明几分钟前交代过的事它像没听到一样。查日志发现问题出在裁剪边界恰好把关键约束消息切掉了。这个坑的修复不在算法里而在消息标记上。我给消息的meta加了一个pinned字段用户明确表达的需求、系统输出过的关键结果、业务规则变更通知都标记为pinned。裁剪时普通消息照常滑动pinned消息坚决保留上下文连贯性问题从此大幅减少。5.3 坑三system prompt位置被覆盖在某些模型API的调用方式中如果用户消息里也带了一段你是...之类的角色设定新指令可能覆盖掉system prompt的早期设定。表现是模型角色漂移一会儿是客服一会儿是翻译助手。规范做法是把system prompt作为只读配置任何业务方都不允许往system prompt里写东西。如果某个业务确实需要临时修改角色正确方式是为它独立创建一套system prompt而不是在用户消息里对抗。另外把system prompt移到构建器的最后一步拼接确保它在发送时始终位于消息数组首位。5.4 坑四无脑拉长上下文窗口大模型厂商都在卷上下文长度128K、200K甚至1M但这不等于你要用满。我用16K窗口和128K窗口跑过相同的检索型任务在token成本上差出8倍而准确率几乎没有提升——事实层该给的片段就那几个窗口再大塞进的也大多是无关噪声。正确思路是以任务最小必要上下文为基准配置窗口。日常问答4K够用长文档分析用16K只有需要整本书级别的上下文才上128K。省下来的成本和延迟比堆窗口性价比高得多。5.5 排查建议速查表症状优先检查项修复方向回答不准确但流畅事实层token占比是否过低提升事实层预算压缩历史层多轮对话失忆裁剪边界是否切掉关键约束引入pinned消息机制角色漂移system prompt是否被覆盖设置只读系统提示词请求报context过长消息数组总token是否接近窗口上限收紧滑动窗口或换大窗口响应速度突然变慢是否存在token重复发送缓存相同system prompt、做消息去重成本飙升是否每次全量重发开启prompt caching或做增量拼接写在最后的实践体会做了这么多context-mode的探索和排坑我的体会是它不是一个开箱即用的开关而是一个需要持续调优的工程系统。与其追求完美的上下文配置不如先搭一套能观测、能调整的最小框架把请求日志、token统计、错误反馈跑起来再根据线上数据去迭代。如果你手头正好在做一个依赖大模型的应用我的建议很简单从今天开始给每次模型调用都加一行token日志记录你实际喂了什么、花掉了多少。连续观察一周你大概率会对上下文到底该怎么管这件事有全新的认知。这个习惯的成本极低带来的收益却可能远超你预期。
最近调试AI应用的时候我翻了不少项目的源码和配置文档发现context-mode这个字段出现的频率越来越高。不少朋友在群里问这到底是干嘛的是必开项吗怎么配置才能让效果最好说实话这个功能在不同工具里的叫法和表现都不太一样但核心逻辑只有一个——让处理模型在正确的时机只看到该看的上下文屏蔽掉无关信息。听起来简单真正落地的时候牵扯到上下文结构、窗口裁剪、任务分类和容错设计踩过的坑比想象中多。这篇文章不聊虚的直接把我对context-mode的理解、自己在项目里的实现方法和排障经验拆开讲清楚。不管你是AI应用开发者、RAG系统研究者还是重度使用AI工具的产品经理这篇文章都能给你一些能直接抄作业的参考。1. context-mode不是玄学是工程问题1.1 从模式到上下文边界——这个词到底在说什么context-mode直译过来是上下文模式。我第一次看到这个词是在一个开源翻译插件里它的意思是根据光标所在的场景决定把哪个段落当作参考上下文。后来在IDE的代码补全工具里又见到含义变成了代码片段关联性识别——你在函数A里写代码时它不会把整个项目的源码都塞给模型而是精挑细选出和函数A相关的部分。到了大模型应用时代这个词的含义收敛到了一个更精确的方向上下文窗口内的信息选择策略。你可以把模型的上下文窗口想象成一张有限大小的白板白板上写什么、写多少、保留哪个部分决定了模型看着什么来回答。context-mode就是管理这块白板的规则集合。生活里其实有非常贴近的类比。你上班时脑子里装的是项目进度、周报要点、会议纪要回到家之后如果还一直想着工作细节整个人会很累。人脑会自动切换工作模式和生活模式切换的实质是注意力范围的收放。context-mode做的事情完全一样——只不过对象换成了模型它不会自己判断什么该看什么不该看需要你通过显式的配置去约束。1.2 没有上下文模式AI应用会出哪些乱子很多人刚开始接大模型API的时候都是把所有内容一股脑塞进prompt里多给点信息总没错。这个思路在demo阶段勉强能用到了生产环境就处处拉胯。无关联噪声污染你问模型帮我总结这段客服会话结果prompt里塞了50页产品文档模型会被无关信息带偏总结出的内容混杂着文档里的营销话术可用性极低。上下文窗口溢出多轮对话场景下历史消息每轮累加很快就把窗口撑爆。系统不得不粗暴地把最早的消息丢掉结果用户三句话前提过的需求被遗忘了。成本失控现在主流模型的token计费都是输入输出双向收费。你不做上下文管理每一轮都把全部历史重发费用呈线性甚至超线性增长跑一个月账单会非常难看。响应延迟飙升喂给模型的token越多首字延迟越明显。实测同样一段任务2k上下文和32k上下文响应速度可能差出一倍以上。这些问题的根源都指向同一个点模型的上下文空间是稀缺资源而你在不加管理地挥霍它。context-mode就是在这种背景下被推到台前的——它的本质不是某个API参数而是一整套围绕上下文窗口的管理策略。2. context-mode的核心构成三层结构、权重关系和边界判断2.1 把上下文拆开看指令、历史、事实三层想要设计好context-mode第一步得把上下文这个黑盒拆开。我习惯把它分成三个逻辑层每一层的来源、作用和对最终结果的影响权重都不同。层级内容来源核心作用常见问题指令层系统提示词system prompt、任务描述定义角色、能力边界、输出格式写得太长会挤占其他层空间历史层多轮对话记录、用户行为轨迹保持对话连贯性、捕获隐含意图无限累积导致窗口溢出事实层知识库检索结果、工具返回数据、文档片段提供具体依据、减少幻觉与问题相关性不足时反而干扰判断这三层之间不是均等关系。大部分场景下指令层优先级最高因为它是模型行为的宪法事实层优先级次之决定了回答有没有依据历史层优先级相对灵活距离当前时间越近的消息越重要越久远的越可以裁剪。有一个很典型的反面教材我见过有人把整个公司规章制度放进system prompt洋洋洒洒三千字结果真实的任务指令和知识片段挤在剩余空间里模型回答出来的东西又长又空。这就好比白板三分之二都画了装饰性的花边真正要计算的公式反而没地方写了。2.2 context-mode的决策规则什么时候全量保留什么时候果断清空设计context-mode最关键的不是怎么存上下文而是**什么时候用哪一层、什么时候丢掉哪一层**。我根据任务的延续性把场景分成三类每类的处理策略完全不同延续型任务例如多轮客服对话、代码重构会话、长文写作。特征是下一轮的输出依赖上一轮的结果。这种场景历史层必须保留但需要做窗口滑动——只保留最近N轮早于N轮的内容转成摘要。独立型任务例如单次翻译、单次分类、单次绘图。特征是任务之间互不依赖。这种场景历史层可以直接清空只保留指令层和当前输入省token又提升响应速度。检索型任务例如知识库问答、文档分析。特征是需要外部事实支撑。这种场景事实层是主角历史层甚至可以完全不上——用户问一句话系统检索出相关片段拼上指令算完收工不需要知道用户昨天问了什么。每次调用模型之前先问自己这个请求属于哪一类然后再决定组装什么上下文。我见过很多失败的context-mode配置问题都出在一刀切上——不管什么请求都携带全部历史结果检索型任务被历史干扰独立型任务白白烧钱。3. 从零实现一个轻量context-mode代码、参数和裁剪算法3.1 数据结构和上下文构建器怎么写理论说了一堆真正动手的时候你会发现问题全在细节里。我写了一个非常精简的Python实现用来管理发送给模型的上下文消息列表。核心数据结构就两个消息体、构建器。from dataclasses import dataclass, field from typing import Dict, List, Optional, Callable dataclass class ContextMessage: role: str # 枚举值system / user / assistant / tool content: str meta: Dict field(default_factorydict) # 扩展字段记录时间戳、来源等 class ContextBuilder: def __init__(self, max_tokens: int 6000): self.max_tokens max_tokens self.messages: List[ContextMessage] [] self.system_prompt: Optional[str] None def set_system_prompt(self, prompt: str) - None: self.system_prompt prompt def add_message(self, role: str, content: str, **meta) - None: self.messages.append(ContextMessage(rolerole, contentcontent, metameta)) def build(self) - List[Dict[str, str]]: 组装最终发送给模型的上下文消息数组 result [] if self.system_prompt: result.append({role: system, content: self.system_prompt}) # 对历史层做窗口裁剪只保留最近窗口的消息具体裁剪在下一节实现 trimmed self._trim_by_window(self.messages) for msg in trimmed: result.append({role: msg.role, content: msg.content}) return result这段代码本身没什么高深的但它框定了context-mode的边界上下文不是裸字符串而是一组带元信息的消息。meta字段很重要项目跑起来之后你会发现单单一条这条消息是什么时候产生的就能帮你解决很多定位问题。3.2 token预算和窗口滑动裁剪算法任何context-mode都绕不开token预算。不同模型的计费规则不一样你需要知道当前使用的模型多久吃光一个窗口。最简单的token估算方式是用tiktokenimport tiktoken def estimate_tokens(text: str, model: str gpt-4) - int: try: enc tiktoken.encoding_for_model(model) except KeyError: enc tiktoken.get_encoding(cl100k_base) return len(enc.encode(text))有了token估算器裁剪算法就顺理成章了。我实践下来最稳定的是层级预算分配 尾部保留策略为系统提示词划出固定预算推荐800~1200 token足够写清角色和规则又不造成浪费。为事实层划出动态预算根据任务的检索结果量上下浮动。历史层用滑动窗口从最近的消息往前扫描塞得下就保留塞不下就停。滑动窗口的具体代码class WindowSlidingContextBuilder(ContextBuilder): def __init__(self, max_tokens: int 6000, keep_recent: int 10): super().__init__(max_tokens) self.keep_recent keep_recent def _trim_by_window(self, messages: List[ContextMessage]) - List[ContextMessage]: # 策略一简单尾部截断保留最近N条 if len(messages) self.keep_recent: return messages return messages[-self.keep_recent:] def build(self) - List[Dict[str, str]]: result [] budget self.max_tokens if self.system_prompt: result.append({role: system, content: self.system_prompt}) budget - estimate_tokens(self.system_prompt) # 从尾部往前扫描尽量保留更接近当前问题的消息 kept [] for msg in reversed(self.messages[-self.keep_recent:]): msg_tokens estimate_tokens(msg.content) if budget - msg_tokens 400: # 预留安全值防止算满 kept.append(msg) budget - msg_tokens else: break return result [{role: m.role, content: m.content} for m in reversed(kept)]这里有几个细节容易栽跟头务必注意keep_recent不是越大越好。我试过设置成50窗口照样爆因为多轮长消息的token累积远超预期。要根据业务单轮消息的平均长度去反推轮数。预算要预留安全边界不要让消息精确填满窗口。模型输出也要占token把窗口用到100%会导致请求直接报错。尾部的用户最新问题一定要保留这是不可裁剪的硬性上下文。裁剪掉用户当前问题会让模型失去任务锚点。3.3 多模式如何共存短对话、长文档、多轮工具调用一个生产级的应用往往不止一种场景。我维护过一个客服机器人同时承载三种context-mode闲聊模式、工单分析模式、知识库问答模式。它们的差异很大闲聊模式历史层保留最近6轮不需要事实层指令层非常简短。预算分配大约是 system 500 历史 1200 输入 300。工单分析模式事实层是核心需要从工单系统拉取字段、附件摘要、历史处理记录。历史层几乎不保留。预算分配大约是 system 800 事实 3500 输入 500。知识库问答模式事实层来自检索系统topK片段需要做相关性过滤——检索返回的前三条不一定都相关这里我给每段检索结果打一个相关性分低于阈值的直接丢弃。预算分配大约是 system 600 事实 2500 历史 800 输入 300。三种模式共存在一个服务里不可能用同一套context-mode配置。所以实际架构中我抽出基类每个模式继承后重写_trim_by_window和build方法。有朋友问过能不能用一个大而全的配置覆盖所有场景答案是能跑但效果会大打折扣——就像你不可能用同一套穿衣策略同时应对办公、爬山和参加婚礼模式切换的本质就是给不同任务做不同的资源倾斜。4. 四套经过实战检验的上下文策略4.1 窗口滑动策略实时对话场景的保底方案适用场景在线客服、聊天机器人、语音助手。策略核心是保近丢远实现成本最低效果最容易预期。我自己的配置经验keep_recent设在6~12之间token预算不超过总窗口的50%。在gpt-4o这类模型上6000 token预算下历史层最多占3000剩下的留给当前输入和事实层。这个策略最大的弱点是久远但重要的信息会被丢干净——用户10分钟前提过一个关键约束比如预算不能超过2000元窗口滑动后这条约束没了模型瞬间失忆。针对这个问题有两个兜底方案一是把对话关键节点用户约束、决策结论手动提升为永久消息不参与裁剪二是配合下面的摘要压缩策略把被踢出窗口的消息浓缩成一句话摘要继续保留。4.2 摘要压缩策略长文档分析的必由之路适用场景论文分析、长合同审核、竞品调研。策略核心是先压缩再使用。具体操作流程分三步第一步把源文档按章节或固定长度切片每片独立调用模型生成一段摘要控制摘要长度在原文的10%左右。这个步骤可以离线批量处理做成缓存避免重复消耗。第二步把生成的摘要列表作为事实层上下文让模型基于摘要进行推理。需要引用原文细节时再根据相似度检索原文片段补充。第三步每次新对话只携带摘要列表和高亮片段历史层几乎不参与。实测下来一份5万字的研报压缩成3000字摘要后模型依然能回答第二章主要讲了什么竞品定价策略对比这类需要跨章节理解的问题。这个策略对压缩质量非常敏感。我踩过的坑是摘要压缩太狠导致关键数据丢失模型在没看到具体数字的情况下一本正经地编输出和原文矛盾。后来我在摘要指令里明确写保留所有数字、专有名词、百分比并用规则检查压缩文本中的数字是否包含于原文不包含就强制重新摘要问题才算解决。4.3 检索增强策略知识库问答的正确姿势适用场景企业知识库、产品文档助手、法律条款检索。策略核心是让模型只看相关的那几块拼图。RAG链路中context-mode的威力集中体现在检索后的取舍上。很多项目天然流程是用户提问 → embedding检索 → topK片段直接拼接 → 发送模型。问题在于topK片段来自不同文档相关性参差不齐噪声片段会让模型回答偏离用户问题。我的做法是在检索后加一道相关性重排def rerank_fragments(query: str, fragments: List[str], threshold: float 0.45) - List[str]: 简易重排对每个片段与query做相似度打分过滤低于阈值的片段 vectordb get_vectordb() # 假设有一个embedding向量库实例 query_emb vectordb.embed(query) scored [] for frag in fragments: frag_emb vectordb.embed(frag) score cosine_similarity(query_emb, frag_emb) scored.append((score, frag)) scored.sort(reverseTrue) return [frag for score, frag in scored if score threshold]阈值需要根据自己的检索质量标定。检索质量高比如ES的BM25和embedding双路召回阈值可以调到0.5检索质量一般就调到0.35宁可多留一个片段也不能把关键信息漏掉。事实层固定住了模型回答的准确率会有一个肉眼可见的提升。4.4 结构化指令策略代码生成和工具调用的关键适用场景代码补全、SQL生成、Function Call。策略核心是用固定结构和格式约束模型行为。这个策略和其他三个不太一样它的重点在指令层的结构设计。在context-mode里我把生成SQL的指令设计成固定模板你是一个SQL生成器。任务背景 {tables_and_columns} 用户需求 {user_input} 输出格式 只输出SQL语句不输出任何解释。 约束条件 1. 只允许读取表 {allowed_tables} 2. 禁止使用DROP/UPDATE/DELETE 3. 如果需求不明确输出一个包含#说明的占位SQL。模板的好处是让模型在有限上下文里快速进入稳定状态。如果每次的指令措辞都不一样模型会花token去理解你到底要怎么输出输出格式也容易漂移。结构化之后输出稳定性和可解析率大幅提升下游程序可以安全地直接执行。5. 实战中四个高频坑附排查建议速查表5.1 坑一上下文塞满导致模型假装权威这是所有坑里最隐蔽的一个。模型在上下文信息不足时很少直接说我不知道而是顺着你的话头往下编。症状是回答流畅无比但细节错误尤其在长文档分析场景最常见。我排查的思路是先在构建器中加一段日志记录每次请求的最终消息数组和token分布然后在线上错误反馈中抽查了十几条发现凡是回答出错的请求事实层token普遍低于会话层token。说明事实层信息不够模型在靠历史对话硬撑。解决办法很简单调高事实层预算调低历史层预算让模型有据可查而不是凭感觉接话。5.2 坑二裁剪后对话上下文不连贯用窗口滑动策略一段时间后会发现某些轮次模型突然失忆——明明几分钟前交代过的事它像没听到一样。查日志发现问题出在裁剪边界恰好把关键约束消息切掉了。这个坑的修复不在算法里而在消息标记上。我给消息的meta加了一个pinned字段用户明确表达的需求、系统输出过的关键结果、业务规则变更通知都标记为pinned。裁剪时普通消息照常滑动pinned消息坚决保留上下文连贯性问题从此大幅减少。5.3 坑三system prompt位置被覆盖在某些模型API的调用方式中如果用户消息里也带了一段你是...之类的角色设定新指令可能覆盖掉system prompt的早期设定。表现是模型角色漂移一会儿是客服一会儿是翻译助手。规范做法是把system prompt作为只读配置任何业务方都不允许往system prompt里写东西。如果某个业务确实需要临时修改角色正确方式是为它独立创建一套system prompt而不是在用户消息里对抗。另外把system prompt移到构建器的最后一步拼接确保它在发送时始终位于消息数组首位。5.4 坑四无脑拉长上下文窗口大模型厂商都在卷上下文长度128K、200K甚至1M但这不等于你要用满。我用16K窗口和128K窗口跑过相同的检索型任务在token成本上差出8倍而准确率几乎没有提升——事实层该给的片段就那几个窗口再大塞进的也大多是无关噪声。正确思路是以任务最小必要上下文为基准配置窗口。日常问答4K够用长文档分析用16K只有需要整本书级别的上下文才上128K。省下来的成本和延迟比堆窗口性价比高得多。5.5 排查建议速查表症状优先检查项修复方向回答不准确但流畅事实层token占比是否过低提升事实层预算压缩历史层多轮对话失忆裁剪边界是否切掉关键约束引入pinned消息机制角色漂移system prompt是否被覆盖设置只读系统提示词请求报context过长消息数组总token是否接近窗口上限收紧滑动窗口或换大窗口响应速度突然变慢是否存在token重复发送缓存相同system prompt、做消息去重成本飙升是否每次全量重发开启prompt caching或做增量拼接写在最后的实践体会做了这么多context-mode的探索和排坑我的体会是它不是一个开箱即用的开关而是一个需要持续调优的工程系统。与其追求完美的上下文配置不如先搭一套能观测、能调整的最小框架把请求日志、token统计、错误反馈跑起来再根据线上数据去迭代。如果你手头正好在做一个依赖大模型的应用我的建议很简单从今天开始给每次模型调用都加一行token日志记录你实际喂了什么、花掉了多少。连续观察一周你大概率会对上下文到底该怎么管这件事有全新的认知。这个习惯的成本极低带来的收益却可能远超你预期。
