1. context-mode决定上限大模型效果差的80%出在上下文管理最近好几个人问过我同一个问题为什么我用同一个模型同样的提示词别人跑出来的效果甩我几条街我帮他们检查了system prompt、few-shot示例、temperature参数看起来都没毛病最后定位到根因时发现他们压根没认真处理过上下文更别提设置上下文模式了。context-mode这个词字面意思是“上下文模式”但它背后解决的问题非常实在大模型能同时“看到”多少信息、以什么方式组织这些信息、以及超出窗口后怎么取舍。它直接决定了应用的回答质量、成本和多轮对话的稳定性。我甚至可以说在模型本身够用的前提下你花80%精力打磨的提示词可能都敌不过把context-mode调对来得多。这篇文章我想把context-mode的底层逻辑、参数计算、工程实现和踩坑记录一次讲透。不管你是刚接触大模型开发的新手还是正在优化生产环境的工程师只要能照着把上下文管理这件事做对效果大概率能肉眼可见地提升。1.1 大模型不是全知全能而是输入什么决定输出什么很多人有个误解觉得大模型像个万事通你问什么它就该答什么。但真实情况是模型在生成回答的那一刻只能参考上下文窗口里塞进来的内容。窗口之外的信息它看不见更别提“记住”以前聊过什么。这就像你临时叫住一个专家只给他看一张纸条他就只能根据纸条上的信息给出判断。所以“上下文”在技术上其实是一份按照顺序拼接起来的token序列通常由几个部分组成系统指令、历史对话、检索到的资料、用户当前的问题。而这个序列怎么拼、拼多少、超了怎么办就是context-mode要管的事。我在实际项目里见过太多“效果差”的案例最后发现都是上下文管理出了问题。要么把无关内容全塞进去挤掉了关键指令要么为了省token只保留最近一轮对话导致模型忘了用户前面的需求要么系统指令被超长历史冲淡模型后半程完全跑偏。这些问题不是模型能力不行而是你喂给它的“视野”本身就是混乱的。1.2 三种上下文模式full、retrieval、summary怎么选如果只记一个结论我会这么说上下文模式本质上就是“在有限的窗口里决定带谁上场”的策略。目前主流实现里最常见的有三种模式核心做法适合场景token成本效果风险full全文模式把所有历史、资料全部拼进窗口短对话、单轮知识问答高长上下文下关键信息被淹没retrieval检索模式先从资料库召回相关片段只拼片段知识库问答、RAG应用中召回不准时答非所问summary摘要模式把历史对话压缩成摘要保留最近若干轮原文多轮会话、客服助手、创作工具低摘要丢失细节追问时容易出错我把full当成默认选项也是最容易被新手无脑使用的模式。它在前几轮对话里效果很好因为上下文短、信息全模型能精准参考。但对话一旦拉长到十几轮或者你往Prompt里塞了一堆文档full模式的弊端就非常明显模型处理长序列时注意力会被分散中间部分的历史细节经常被忽略也就是业内常说的“迷失在中间”。retrieval模式适合知识库场景核心思路是不把所有文档塞进去而是先用向量检索找出跟当前问题最相关的3到5个片段再把片段放进上下文。它的关键在召回质量召回错了给再多上下文也没用。summary模式则是一个省token的好工具。它把已经聊过的内容交给模型生成一段摘要之后每次请求都带着这段摘要加最近几轮原文进入模型。这种模式在长会话里效果稳定成本也低代价是摘要可能丢掉具体数字、人名、细节偏好所以需要配合“最近原文保留”的策略使用我的实现里一般会两者结合。1.3 模式选错的典型翻车现场只讲概念可能不够有感觉我举两个真实发生过的翻车案例。第一个案例来自一个客服机器人项目。团队把所有用户历史工单全塞进了system prompt足足有上万字希望模型“记住”所有规则。结果呢模型开头几轮还能遵守后面完全忘了系统指令开始自由发挥甚至把客服该有的口头禅都丢了。这就是full模式被滥用后的典型问题指令被大量无关内容稀释模型越到后面越迷失。第二个案例来自一个RAG知识库问答工具。他们用了retrieval模式但没做重排序只按向量相似度取前3个片段。用户问“报销流程中发票金额超过一万怎么处理”检索回来的全是“差旅报销标准”和“发票粘贴规范”真正的关键条款没召回。结果模型一本正经地答了一堆不相关的内容。问题不在模型而在retrieval上下文本身的质量。我后来总结了一句话模式本身没有好坏只有合不合适。短对话用full最快知识库场景必须走retrieval并配合重排长会话生产环境summary加最近滑动窗口才是稳定方案。2. 把话说到点子上context-mode背后的token经济学与量化思路聊清楚了模式选型接下来要进入工程实操环节。很多人做上下文管理时凭感觉觉得“差不多够了吧”结果上线后token账单一个月比一个月离谱或者模型输出质量忽高忽低。上下文管理这件事第一步不是写代码而是先学会算账。2.1 先算账一次请求到底吃掉多少token要管理上下文你得先清楚每个请求到底消耗了多少token。最常用的方法是直接用tiktoken库按模型做编码但日常开发时可以先靠估算快速判断。我自己的经验公式是这样的中文场景token数 ≈ 中文字符数 × 1.5英文场景token数 ≈ 英文字符数 × 0.25混合场景按字符比例加权比如一段500字的客服历史对话中文大概产生750个token而一段英文文档2000字符大概产生500个token。这两个数字看起来不大但多轮会话累积起来就非常可观了。正式做预算时我一般把一次请求的上下文占用拆成五项system指令占用的tokenfew-shot示例占用的token历史对话占用的token检索返回的参考资料占用的token当前用户问题占用的token外加模型输出预留token模型输出也走同一份上下文窗口不能忽略。举个例子假设你用的是32K窗口的模型系统设定max output tokens为2000那么输入侧最多只能占用30000个token。如果把预算拆成system 500、few-shot 1000、历史10轮共8000、检索文档6000、当前问题200加起来一共15700离30000还有余量看起来健康。但如果你把检索文档换成原样塞入3万字的产品手册输入侧直接飙到25000以上加上历史和系统指令就超出了你说模型还能好好输出吗所以每次调整上下文结构前先在代码里算一次总账这是最基础的自我体检。2.2 长文本的迷失效应为什么塞得越多错得越远你可能会想既然窗口还有空间为什么不全塞进去这里必须提一个我很早就踩过的坑长上下文并不是越多越好模型在长序列里对“信息密度”极高的中间部分注意力会显著下降。我做过一组对比实验用同一份包含30个条款的技术规范文档问模型“第17条说了什么”。把文档放在开头准确率很高把文档放在中间模型经常胡诌出一个不存在的条款。后来我把文档拆成段落用retrieval模式只召回目标条款准确率立刻回到90%以上。这不是模型“不聪明”而是Transformer的注意力机制天然对长序列有压力。信息混杂在大量无关token里信号会被背景下沉。你喂进去的99%的内容如果在当前问题里根本用不上它不但帮不上忙反而会成为噪音。所以“把窗口塞满”从来不是目标。context-mode的本质是控制信息密度保证喂给模型的每一段内容都是当前问题最需要的东西。宁可让窗口空着也别把无关内容塞满。2.3 不同模式在真实场景的取舍矩阵想选对模式我建议按表格里的维度过一遍再决定判断维度full适合的情况retrieval适合的情况summary适合的情况会话轮数1-4轮任意轮数依赖检索10轮以上资料体量小几百字内大几千字以上中历史为主对细节的要求高高中低成本敏感度敏感中很敏感典型应用单轮问答、指令执行知识库、企业内部问答客服、创作助手我个人的默认组合是单轮问答直接full需要查资料时切retrieval长会话场景用summary加最近5轮原文。这是一套很稳的底座后面做任何定制都从它出发。3. 从0到1实现一个支持三种模式切换的ContextManager理论聊够了直接动手。这一节我会带你实现一个小巧但可以上生产环境的ContextManager支持full、retrieval、summary三种模式并自带token预算控制。代码用Python核心思路不依赖特定框架你可以平移到LangChain、LlamaIndex或者其他任何自己的封装里。3.1 模块拆分这玩意儿该怎么设计先想清楚职责边界。一个合格的上下文管理器至少要干四件事维护会话历史保存每条消息的role和content按当前模式把历史、检索片段、系统指令拼成最终Prompt估算token总量超预算时执行压缩策略在模式切换时保证不丢关键信息所以它本质上是一个“状态管理拼装器”。不建议把向量检索、摘要生成的逻辑直接塞进这个类里而是通过接口或回调注入让ContextManager只负责拼装和裁剪。我把整个结构拆成三层数据层历史消息、摘要、最大token限额、策略层不同模式下的拼装规则、调度层对外提供build_prompt接口处理超预算自动降级。下面直接看一下代码怎么落地。3.2 核心代码token计数、历史存取与Prompt拼装先定义基础数据结构和管理器骨架from dataclasses import dataclass, field from typing import List, Optional import tiktoken dataclass class ChatMessage: role: str # system / user / assistant content: str class ContextManager: def __init__( self, max_context_tokens: int 32_000, max_output_tokens: int 2_000, mode: str full, encoder_name: str cl100k_base, ): self.max_context_tokens max_context_tokens self.max_output_tokens max_output_tokens self.mode mode self.encoder tiktoken.get_encoding(encoder_name) self.history: List[ChatMessage] [] self.summary: str def _count(self, text: str) - int: return len(self.encoder.encode(text)) def add_message(self, role: str, content: str) - None: self.history.append(ChatMessage(rolerole, contentcontent)) def set_summary(self, summary: str) - None: self.summary summarytiktoken的编码名称要跟模型匹配cl100k_base可以覆盖GPT-3.5和GPT-4系列但如果你用新模型比如gpt-4o建议确认一下官方tokenizer配置。接下来是模式分流。三种模式都从同一个入口进入但拼装逻辑不同def build_prompt( self, current_query: str, retrieval_docs: Optional[List[str]] None, ) - List[dict]: if self.mode full: return self._build_full_prompt(current_query, retrieval_docs) elif self.mode retrieval: return self._build_retrieval_prompt(current_query, retrieval_docs) elif self.mode summary: return self._build_summary_prompt(current_query) else: raise ValueError(funknown mode: {self.mode})full模式的拼装逻辑最直白系统指令 历史 检索资料 当前问题全都往里放。历史默认取全部但如果预算不够再做尾部裁剪。def _build_full_prompt( self, current_query: str, retrieval_docs: Optional[List[str]] None, ) - List[dict]: prompt: List[dict] [{role: system, content: self._system_prompt()}] for msg in self.history: prompt.append({role: msg.role, content: msg.content}) if retrieval_docs: doc_text \n\n.join(retrieval_docs) prompt.append({role: system, content: f参考资料\n{doc_text}}) prompt.append({role: user, content: current_query}) return prompt这里有一个设计细节检索资料我用system角色传入而不是跟用户问题混在一起。这样模型能区分“这是需要参考的材料”和“这是用户在提问”效果会比拼在一起更好。3.3 关键逻辑超预算时怎么压缩才不丢关键信息拼装简单难点在于“上下文超了怎么办”。很多人直接截断最中间的消息结果把关键信息切掉了。我的做法是四级递进压缩第一级优先裁剪检索文档中得分最低的片段而不是裁剪历史。 第二级裁剪最早的历史消息保留最近的对话因为最近的对话通常和当前问题最相关。 第三级如果历史仍然太多把早期历史替换为一句话摘要。 第四级如果还是超从历史末尾倒着删除较长的assistant消息控制用户消息尽量保留。先把摘要降级逻辑写进一个独立方法def _compact_history(self, max_allowed: int) - None: # 如果历史太大先把最老的一半压成摘要 if not self.summary: return total sum(self._count(msg.content) for msg in self.history) if total max_allowed: return system_cost self._count(self._system_prompt()) query_cost self._count(占位符) # 实际会在调用时扣除 budget_for_history max_allowed - system_cost - 200 - query_cost merged self.summary \n remaining: List[ChatMessage] [] for msg in reversed(self.history): cost self._count(msg.content) need len(merged) cost 200 if need budget_for_history: remaining.insert(0, msg) merged msg.content \n else: break self.history remaining self.summary merged很多简化实现只保留最近的N条完全不保留早期任何信息。但我在实践中发现用户经常会在第8轮时提一句“回到我们最开始说的那个问题”这时候如果没有摘要模型完全不知道前面聊过什么。所以self.summary承担的就是“压缩后的长期记忆”角色。3.4 一个完整的调度示例长对话下的模式自适应光有拼装还不够实际线上环境需要“模式自适应”。我不太建议把模式写死而是设一个简单的自动切换规则历史长度小于5轮且检索文档小于800字时用full一旦对话变长或检索资料变多自动切到retrieval或summary。下面这个示例展示了一次完整的调度过程manager ContextManager(max_context_tokens16_000, modefull) manager.set_summary(用户想开发一个报销审批工具技术栈选型倾向Python。) # 模拟十几轮对话 manager.add_message(user, 报销额度超过5万需要什么流程) manager.add_message(assistant, 超过5万需要部门总监和财务负责人双签。) manager.add_message(user, 那电子发票和纸质发票的处理有区别吗) manager.add_message(assistant, 电子发票需要在系统中上传原件PDF纸质发票需要扫描留存。) # ...继续添加更多历史 # 某一轮用户需要查公司制度文档 retrieval_docs [ 第六章差旅报销额度标准部长级单程上限6000元。, 第六章发票审核要求所有报销必须附带完整发票链。, ] # 根据当前情况切换模式 if len(manager.history) 8: manager.mode summary elif retrieval_docs: manager.mode retrieval prompt manager.build_prompt( 帮我确认部长级差旅报销需要谁审批, retrieval_docsretrieval_docs, ) # 调用模型 import openai resp openai.chat.completions.create( modelgpt-4o, messagesprompt, max_tokens2000, ) print(resp.choices[0].message.content)这段逻辑并不复杂但已经把context-mode的核心全包含了历史管理、模式切换、检索融合、预算控制。你在自己项目里可以直接拿这个类做底座需要接入不同向量库或摘要模型时替换检索来源和摘要生成逻辑就行。4. 实际跑起来的坑context-mode常见问题与排查实录我不打算把这一章写成理论复习直接把这几年实际运行中遇到过的问题摊开来说。很多坑光看文档是发现不了的但一旦踩过印象会非常深。4.1 高频问题速查表症状可能原因处理办法模型输出突然变得很短甚至空白上下文窗口被输入占满输出的token空间被挤掉预留max output tokens启动时检查剩余配额多轮对话中模型“忘掉”用户开头说的需求full模式塞入太多历史早期信息被稀释切到summary模式或定期生成历史摘要同一个问题retrieval模式答得不如full模式检索召回片段无关或top_k太小加粗召回数量配合重排序用rerank模型过滤系统指令到后面失效模型还在自言自语system提示词被长历史冲淡位置靠前注意力低把关键约束在靠近用户问题的位置重复一遍token消耗暴涨账单翻了好几倍摘要模式每次请求都重新生成全量摘要增量更新摘要只在对话轮次间隔时触发摘要模型回答的内容跟检索文档对不上检索片段被截断关键上下文丢失保留片段标题给模型更多“锚点”信息summary模式下用户追问具体细节模型答错摘要丢掉了数字、人名等细节摘要模板里强制要求保留关键实体和数字这张表的每一行都来自真实反馈不是理论推演。如果你的应用出现类似症状优先按表格里的处理办法试比反复调temperature有效得多。4.2 我踩过的几个坑以及现在的固定做法第一个坑是早期做客服机器人时为了“不丢信息”我把所有历史都存成原文每次请求全部塞进上下文。结果跑了一周单次请求token从2K涨到15K模型反馈延迟翻倍回答质量反而下降。后来我才确认那一版根本不该用full模式应该用summary加最近5轮。从那以后我给自己定了一条规矩任何生产环境里的多轮应用默认不走full除非能证明历史真的很短。第二个坑是摘要模式生成频率太高。第一次实现时我每轮对话结束后都让模型重新生成一次全量摘要导致prompt里摘要本身的token就很高成本直接翻倍。后来改成只增量更新summary内容并在对话超过10轮时才触发新一轮摘要生成。成本立刻回到正常水平效果也没有下降。第三个坑是检索模式不加重排序。我在某个知识库项目里测试时选的都是好召回的样例看起来效果很好一上生产就频繁跑偏。排查后才发现向量召回的前3条经常有1条无关内容而这1条内容严重带偏模型回答。后来我在检索结果进入ContextManager之前加了一个rerank步骤用交叉编码器重新打分再取前2条。效果立刻稳定下来。如果你现在要设计一套自己的context-mode策略我个人建议按这个固定组合起步首轮对话full模式不夹带任何冗余资料中间轮次retrieval模式召回加rerank后拼接长会话summary模式摘要加最近5轮原文每次请求前跑一次token预算检查超了自动降级这一套组合在我参与过的项目里表现稳定。它不依赖某个特定模型或框架是纯工程层面的方案换模型换底座都成立。最后再分享一个很多人忽略的小细节在清晰的上下文边界内工作比扩大窗口更有效。我见过太多人为了省事把该检索的资料直接全量塞进上下文结果模型输出质量被一堆无关文本拖垮。真正确认过context-mode这一层之后你会发现很多所谓“模型能力不够”的结论其实都下早了。
1. context-mode决定上限大模型效果差的80%出在上下文管理最近好几个人问过我同一个问题为什么我用同一个模型同样的提示词别人跑出来的效果甩我几条街我帮他们检查了system prompt、few-shot示例、temperature参数看起来都没毛病最后定位到根因时发现他们压根没认真处理过上下文更别提设置上下文模式了。context-mode这个词字面意思是“上下文模式”但它背后解决的问题非常实在大模型能同时“看到”多少信息、以什么方式组织这些信息、以及超出窗口后怎么取舍。它直接决定了应用的回答质量、成本和多轮对话的稳定性。我甚至可以说在模型本身够用的前提下你花80%精力打磨的提示词可能都敌不过把context-mode调对来得多。这篇文章我想把context-mode的底层逻辑、参数计算、工程实现和踩坑记录一次讲透。不管你是刚接触大模型开发的新手还是正在优化生产环境的工程师只要能照着把上下文管理这件事做对效果大概率能肉眼可见地提升。1.1 大模型不是全知全能而是输入什么决定输出什么很多人有个误解觉得大模型像个万事通你问什么它就该答什么。但真实情况是模型在生成回答的那一刻只能参考上下文窗口里塞进来的内容。窗口之外的信息它看不见更别提“记住”以前聊过什么。这就像你临时叫住一个专家只给他看一张纸条他就只能根据纸条上的信息给出判断。所以“上下文”在技术上其实是一份按照顺序拼接起来的token序列通常由几个部分组成系统指令、历史对话、检索到的资料、用户当前的问题。而这个序列怎么拼、拼多少、超了怎么办就是context-mode要管的事。我在实际项目里见过太多“效果差”的案例最后发现都是上下文管理出了问题。要么把无关内容全塞进去挤掉了关键指令要么为了省token只保留最近一轮对话导致模型忘了用户前面的需求要么系统指令被超长历史冲淡模型后半程完全跑偏。这些问题不是模型能力不行而是你喂给它的“视野”本身就是混乱的。1.2 三种上下文模式full、retrieval、summary怎么选如果只记一个结论我会这么说上下文模式本质上就是“在有限的窗口里决定带谁上场”的策略。目前主流实现里最常见的有三种模式核心做法适合场景token成本效果风险full全文模式把所有历史、资料全部拼进窗口短对话、单轮知识问答高长上下文下关键信息被淹没retrieval检索模式先从资料库召回相关片段只拼片段知识库问答、RAG应用中召回不准时答非所问summary摘要模式把历史对话压缩成摘要保留最近若干轮原文多轮会话、客服助手、创作工具低摘要丢失细节追问时容易出错我把full当成默认选项也是最容易被新手无脑使用的模式。它在前几轮对话里效果很好因为上下文短、信息全模型能精准参考。但对话一旦拉长到十几轮或者你往Prompt里塞了一堆文档full模式的弊端就非常明显模型处理长序列时注意力会被分散中间部分的历史细节经常被忽略也就是业内常说的“迷失在中间”。retrieval模式适合知识库场景核心思路是不把所有文档塞进去而是先用向量检索找出跟当前问题最相关的3到5个片段再把片段放进上下文。它的关键在召回质量召回错了给再多上下文也没用。summary模式则是一个省token的好工具。它把已经聊过的内容交给模型生成一段摘要之后每次请求都带着这段摘要加最近几轮原文进入模型。这种模式在长会话里效果稳定成本也低代价是摘要可能丢掉具体数字、人名、细节偏好所以需要配合“最近原文保留”的策略使用我的实现里一般会两者结合。1.3 模式选错的典型翻车现场只讲概念可能不够有感觉我举两个真实发生过的翻车案例。第一个案例来自一个客服机器人项目。团队把所有用户历史工单全塞进了system prompt足足有上万字希望模型“记住”所有规则。结果呢模型开头几轮还能遵守后面完全忘了系统指令开始自由发挥甚至把客服该有的口头禅都丢了。这就是full模式被滥用后的典型问题指令被大量无关内容稀释模型越到后面越迷失。第二个案例来自一个RAG知识库问答工具。他们用了retrieval模式但没做重排序只按向量相似度取前3个片段。用户问“报销流程中发票金额超过一万怎么处理”检索回来的全是“差旅报销标准”和“发票粘贴规范”真正的关键条款没召回。结果模型一本正经地答了一堆不相关的内容。问题不在模型而在retrieval上下文本身的质量。我后来总结了一句话模式本身没有好坏只有合不合适。短对话用full最快知识库场景必须走retrieval并配合重排长会话生产环境summary加最近滑动窗口才是稳定方案。2. 把话说到点子上context-mode背后的token经济学与量化思路聊清楚了模式选型接下来要进入工程实操环节。很多人做上下文管理时凭感觉觉得“差不多够了吧”结果上线后token账单一个月比一个月离谱或者模型输出质量忽高忽低。上下文管理这件事第一步不是写代码而是先学会算账。2.1 先算账一次请求到底吃掉多少token要管理上下文你得先清楚每个请求到底消耗了多少token。最常用的方法是直接用tiktoken库按模型做编码但日常开发时可以先靠估算快速判断。我自己的经验公式是这样的中文场景token数 ≈ 中文字符数 × 1.5英文场景token数 ≈ 英文字符数 × 0.25混合场景按字符比例加权比如一段500字的客服历史对话中文大概产生750个token而一段英文文档2000字符大概产生500个token。这两个数字看起来不大但多轮会话累积起来就非常可观了。正式做预算时我一般把一次请求的上下文占用拆成五项system指令占用的tokenfew-shot示例占用的token历史对话占用的token检索返回的参考资料占用的token当前用户问题占用的token外加模型输出预留token模型输出也走同一份上下文窗口不能忽略。举个例子假设你用的是32K窗口的模型系统设定max output tokens为2000那么输入侧最多只能占用30000个token。如果把预算拆成system 500、few-shot 1000、历史10轮共8000、检索文档6000、当前问题200加起来一共15700离30000还有余量看起来健康。但如果你把检索文档换成原样塞入3万字的产品手册输入侧直接飙到25000以上加上历史和系统指令就超出了你说模型还能好好输出吗所以每次调整上下文结构前先在代码里算一次总账这是最基础的自我体检。2.2 长文本的迷失效应为什么塞得越多错得越远你可能会想既然窗口还有空间为什么不全塞进去这里必须提一个我很早就踩过的坑长上下文并不是越多越好模型在长序列里对“信息密度”极高的中间部分注意力会显著下降。我做过一组对比实验用同一份包含30个条款的技术规范文档问模型“第17条说了什么”。把文档放在开头准确率很高把文档放在中间模型经常胡诌出一个不存在的条款。后来我把文档拆成段落用retrieval模式只召回目标条款准确率立刻回到90%以上。这不是模型“不聪明”而是Transformer的注意力机制天然对长序列有压力。信息混杂在大量无关token里信号会被背景下沉。你喂进去的99%的内容如果在当前问题里根本用不上它不但帮不上忙反而会成为噪音。所以“把窗口塞满”从来不是目标。context-mode的本质是控制信息密度保证喂给模型的每一段内容都是当前问题最需要的东西。宁可让窗口空着也别把无关内容塞满。2.3 不同模式在真实场景的取舍矩阵想选对模式我建议按表格里的维度过一遍再决定判断维度full适合的情况retrieval适合的情况summary适合的情况会话轮数1-4轮任意轮数依赖检索10轮以上资料体量小几百字内大几千字以上中历史为主对细节的要求高高中低成本敏感度敏感中很敏感典型应用单轮问答、指令执行知识库、企业内部问答客服、创作助手我个人的默认组合是单轮问答直接full需要查资料时切retrieval长会话场景用summary加最近5轮原文。这是一套很稳的底座后面做任何定制都从它出发。3. 从0到1实现一个支持三种模式切换的ContextManager理论聊够了直接动手。这一节我会带你实现一个小巧但可以上生产环境的ContextManager支持full、retrieval、summary三种模式并自带token预算控制。代码用Python核心思路不依赖特定框架你可以平移到LangChain、LlamaIndex或者其他任何自己的封装里。3.1 模块拆分这玩意儿该怎么设计先想清楚职责边界。一个合格的上下文管理器至少要干四件事维护会话历史保存每条消息的role和content按当前模式把历史、检索片段、系统指令拼成最终Prompt估算token总量超预算时执行压缩策略在模式切换时保证不丢关键信息所以它本质上是一个“状态管理拼装器”。不建议把向量检索、摘要生成的逻辑直接塞进这个类里而是通过接口或回调注入让ContextManager只负责拼装和裁剪。我把整个结构拆成三层数据层历史消息、摘要、最大token限额、策略层不同模式下的拼装规则、调度层对外提供build_prompt接口处理超预算自动降级。下面直接看一下代码怎么落地。3.2 核心代码token计数、历史存取与Prompt拼装先定义基础数据结构和管理器骨架from dataclasses import dataclass, field from typing import List, Optional import tiktoken dataclass class ChatMessage: role: str # system / user / assistant content: str class ContextManager: def __init__( self, max_context_tokens: int 32_000, max_output_tokens: int 2_000, mode: str full, encoder_name: str cl100k_base, ): self.max_context_tokens max_context_tokens self.max_output_tokens max_output_tokens self.mode mode self.encoder tiktoken.get_encoding(encoder_name) self.history: List[ChatMessage] [] self.summary: str def _count(self, text: str) - int: return len(self.encoder.encode(text)) def add_message(self, role: str, content: str) - None: self.history.append(ChatMessage(rolerole, contentcontent)) def set_summary(self, summary: str) - None: self.summary summarytiktoken的编码名称要跟模型匹配cl100k_base可以覆盖GPT-3.5和GPT-4系列但如果你用新模型比如gpt-4o建议确认一下官方tokenizer配置。接下来是模式分流。三种模式都从同一个入口进入但拼装逻辑不同def build_prompt( self, current_query: str, retrieval_docs: Optional[List[str]] None, ) - List[dict]: if self.mode full: return self._build_full_prompt(current_query, retrieval_docs) elif self.mode retrieval: return self._build_retrieval_prompt(current_query, retrieval_docs) elif self.mode summary: return self._build_summary_prompt(current_query) else: raise ValueError(funknown mode: {self.mode})full模式的拼装逻辑最直白系统指令 历史 检索资料 当前问题全都往里放。历史默认取全部但如果预算不够再做尾部裁剪。def _build_full_prompt( self, current_query: str, retrieval_docs: Optional[List[str]] None, ) - List[dict]: prompt: List[dict] [{role: system, content: self._system_prompt()}] for msg in self.history: prompt.append({role: msg.role, content: msg.content}) if retrieval_docs: doc_text \n\n.join(retrieval_docs) prompt.append({role: system, content: f参考资料\n{doc_text}}) prompt.append({role: user, content: current_query}) return prompt这里有一个设计细节检索资料我用system角色传入而不是跟用户问题混在一起。这样模型能区分“这是需要参考的材料”和“这是用户在提问”效果会比拼在一起更好。3.3 关键逻辑超预算时怎么压缩才不丢关键信息拼装简单难点在于“上下文超了怎么办”。很多人直接截断最中间的消息结果把关键信息切掉了。我的做法是四级递进压缩第一级优先裁剪检索文档中得分最低的片段而不是裁剪历史。 第二级裁剪最早的历史消息保留最近的对话因为最近的对话通常和当前问题最相关。 第三级如果历史仍然太多把早期历史替换为一句话摘要。 第四级如果还是超从历史末尾倒着删除较长的assistant消息控制用户消息尽量保留。先把摘要降级逻辑写进一个独立方法def _compact_history(self, max_allowed: int) - None: # 如果历史太大先把最老的一半压成摘要 if not self.summary: return total sum(self._count(msg.content) for msg in self.history) if total max_allowed: return system_cost self._count(self._system_prompt()) query_cost self._count(占位符) # 实际会在调用时扣除 budget_for_history max_allowed - system_cost - 200 - query_cost merged self.summary \n remaining: List[ChatMessage] [] for msg in reversed(self.history): cost self._count(msg.content) need len(merged) cost 200 if need budget_for_history: remaining.insert(0, msg) merged msg.content \n else: break self.history remaining self.summary merged很多简化实现只保留最近的N条完全不保留早期任何信息。但我在实践中发现用户经常会在第8轮时提一句“回到我们最开始说的那个问题”这时候如果没有摘要模型完全不知道前面聊过什么。所以self.summary承担的就是“压缩后的长期记忆”角色。3.4 一个完整的调度示例长对话下的模式自适应光有拼装还不够实际线上环境需要“模式自适应”。我不太建议把模式写死而是设一个简单的自动切换规则历史长度小于5轮且检索文档小于800字时用full一旦对话变长或检索资料变多自动切到retrieval或summary。下面这个示例展示了一次完整的调度过程manager ContextManager(max_context_tokens16_000, modefull) manager.set_summary(用户想开发一个报销审批工具技术栈选型倾向Python。) # 模拟十几轮对话 manager.add_message(user, 报销额度超过5万需要什么流程) manager.add_message(assistant, 超过5万需要部门总监和财务负责人双签。) manager.add_message(user, 那电子发票和纸质发票的处理有区别吗) manager.add_message(assistant, 电子发票需要在系统中上传原件PDF纸质发票需要扫描留存。) # ...继续添加更多历史 # 某一轮用户需要查公司制度文档 retrieval_docs [ 第六章差旅报销额度标准部长级单程上限6000元。, 第六章发票审核要求所有报销必须附带完整发票链。, ] # 根据当前情况切换模式 if len(manager.history) 8: manager.mode summary elif retrieval_docs: manager.mode retrieval prompt manager.build_prompt( 帮我确认部长级差旅报销需要谁审批, retrieval_docsretrieval_docs, ) # 调用模型 import openai resp openai.chat.completions.create( modelgpt-4o, messagesprompt, max_tokens2000, ) print(resp.choices[0].message.content)这段逻辑并不复杂但已经把context-mode的核心全包含了历史管理、模式切换、检索融合、预算控制。你在自己项目里可以直接拿这个类做底座需要接入不同向量库或摘要模型时替换检索来源和摘要生成逻辑就行。4. 实际跑起来的坑context-mode常见问题与排查实录我不打算把这一章写成理论复习直接把这几年实际运行中遇到过的问题摊开来说。很多坑光看文档是发现不了的但一旦踩过印象会非常深。4.1 高频问题速查表症状可能原因处理办法模型输出突然变得很短甚至空白上下文窗口被输入占满输出的token空间被挤掉预留max output tokens启动时检查剩余配额多轮对话中模型“忘掉”用户开头说的需求full模式塞入太多历史早期信息被稀释切到summary模式或定期生成历史摘要同一个问题retrieval模式答得不如full模式检索召回片段无关或top_k太小加粗召回数量配合重排序用rerank模型过滤系统指令到后面失效模型还在自言自语system提示词被长历史冲淡位置靠前注意力低把关键约束在靠近用户问题的位置重复一遍token消耗暴涨账单翻了好几倍摘要模式每次请求都重新生成全量摘要增量更新摘要只在对话轮次间隔时触发摘要模型回答的内容跟检索文档对不上检索片段被截断关键上下文丢失保留片段标题给模型更多“锚点”信息summary模式下用户追问具体细节模型答错摘要丢掉了数字、人名等细节摘要模板里强制要求保留关键实体和数字这张表的每一行都来自真实反馈不是理论推演。如果你的应用出现类似症状优先按表格里的处理办法试比反复调temperature有效得多。4.2 我踩过的几个坑以及现在的固定做法第一个坑是早期做客服机器人时为了“不丢信息”我把所有历史都存成原文每次请求全部塞进上下文。结果跑了一周单次请求token从2K涨到15K模型反馈延迟翻倍回答质量反而下降。后来我才确认那一版根本不该用full模式应该用summary加最近5轮。从那以后我给自己定了一条规矩任何生产环境里的多轮应用默认不走full除非能证明历史真的很短。第二个坑是摘要模式生成频率太高。第一次实现时我每轮对话结束后都让模型重新生成一次全量摘要导致prompt里摘要本身的token就很高成本直接翻倍。后来改成只增量更新summary内容并在对话超过10轮时才触发新一轮摘要生成。成本立刻回到正常水平效果也没有下降。第三个坑是检索模式不加重排序。我在某个知识库项目里测试时选的都是好召回的样例看起来效果很好一上生产就频繁跑偏。排查后才发现向量召回的前3条经常有1条无关内容而这1条内容严重带偏模型回答。后来我在检索结果进入ContextManager之前加了一个rerank步骤用交叉编码器重新打分再取前2条。效果立刻稳定下来。如果你现在要设计一套自己的context-mode策略我个人建议按这个固定组合起步首轮对话full模式不夹带任何冗余资料中间轮次retrieval模式召回加rerank后拼接长会话summary模式摘要加最近5轮原文每次请求前跑一次token预算检查超了自动降级这一套组合在我参与过的项目里表现稳定。它不依赖某个特定模型或框架是纯工程层面的方案换模型换底座都成立。最后再分享一个很多人忽略的小细节在清晰的上下文边界内工作比扩大窗口更有效。我见过太多人为了省事把该检索的资料直接全量塞进上下文结果模型输出质量被一堆无关文本拖垮。真正确认过context-mode这一层之后你会发现很多所谓“模型能力不够”的结论其实都下早了。
