大模型上下文管理实战：context-mode 四种模式与工程落地

去年我接了一个知识库问答项目前两周效果还不错第三周开始用户陆续反馈“机器人变笨了”——同一个问题前几天还能答出明确出处后面就开始一本正经地胡说八道。排查了一圈模型没换、知识库没坏、API预算反而涨了最后才定位到根因多轮对话里历史消息越堆越长真正有用的知识被挤到注意力边缘模型被长下文“撑”傻了。这个问题的本质是上下文组织方式不对。你以什么结构、什么顺序、什么长度把历史消息、外部知识和系统指令拼给模型直接决定了输出质量。我后来把整套上下文组织逻辑整理成一套可以复用和演进的实现取了个朴素的名字叫“context-mode”上下文模式。这套思路帮我解决了不少类似的对话类项目问题也让我从“每次都在prompt里瞎调”的状态里彻底跳了出来。这篇内容就把这套东西完整拆开讲一遍包括模式设计、核心代码、token预算计算、以及我在实际项目中踩过的坑。适合正在做AI应用开发、尤其是对话机器人和知识库问答的工程师参考。1. 为什么要单独把“context-mode”拎出来讲1.1 大多数人处理上下文的方式都是先拼字符串再说我见过很多团队写大模型应用第一步都是把messages数组直接塞进API。代码很简单刚开始效果也还行因为对话轮数少模型上下文窗口足够容纳所有内容。但一旦会话变长问题就像滚雪球一样出现。有一个很典型的例子一个客服机器人用户和它聊了30轮前面问过退货政策中间聊了订单状态最后问“那我应该怎么操作”。如果没有合理的上下文管理模型可能会把“操作”理解成退货流程但用户实际想问的是订单催进度。历史消息一股脑全给模型反而不知道哪一段才是当前问题的核心。更麻烦的是token成本。多轮对话里很多内容是重复的、寒暄的、或者已经被纠正过的。全量拼接意味着每次请求都在为无关内容买单。我统计过一个项目平均每轮对话入参token从3000涨到8000只用了不到一周费用翻了一倍多效果却在持续下降。这种时候你再回头去调prompt已经没用了问题出在上下文本身。1.2 context-mode不是框架是一套组织上下文的决策逻辑我第一次想给这套逻辑起名的时候查了一下社区里的叫法有叫“上下文工程”的有叫“memory management”的也有叫“上下文压缩策略”的。叫法很多但核心其实就一件事在每一轮请求发出之前你都要回答几个问题——哪些消息必须保留哪些可以丢哪些需要先压缩再保留以什么顺序排列以及总长度控制在多少。context-mode就是把这些问题变成了一套显式的、可枚举的、可切换的方案。就像数据库有“读模式”“写模式”一样对话系统在不同的场景下也应该有不同的上下文处理模式。你在做闲聊机器人、客服系统、代码生成助手、或者复杂数据分析Agent的时候需要的上下文组织方式完全是两码事统一用一种策略一定出事。把context-mode当作独立的模块来设计而不是散落在prompt拼接代码里的if-else最大的好处是你可以单独测试它、单独调优、单独统计它对token消耗和回答质量的影响。我后面会把具体实现讲清楚先说我总结出来的四种模式因为它们是我所有代码的基础。1.3 什么信号说明你该引入context-mode了如果你在维护一个已经上线的大模型应用下面几个信号中招两条以上就说明你需要一套正式的上下文管理方案了对话轮数超过10轮之后回答质量肉眼可见地下降经常出现“答非所问”用户问的是后面聊的内容模型却在引用前面几轮的旧信息token消耗持续增长费用涨幅远超用户增长每次优化prompt只能好一两天随后又被打回原形你不敢升级模型版本因为每换一次模型同样的上下文策略表现都不一样。这些现象的共同根源是模型输入侧的组装逻辑是拍脑袋写的没有经过设计和度量。引入context-mode之后你能把“上下文怎么组织”变成可配置的、可测试的工程模块而不是每个版本上线前临场发挥。2. 四种上下文模式的拆解与选型2.1 单轮完整注入模式Full-Context简单但有天花板这是最朴素的模式把系统指令、全部对话历史、当前用户输入一股脑拼进去。优点是代码最简单、信息无损适合对话轮数极少、每次交互相对独立的场景比如一次性问答工具、表单填写辅助。但它的天花板非常明显。一方面模型对超长上下文的注意力会稀释——我实测过一个128k窗口的模型当输入超过30k token之后它对中段信息的召回准确率明显下降具体表现就是“记得开头和结尾忘了中间”。另一方面成本线性增长完全不可持续。这个模式适合做成context-mode的兜底选项也就是其他模式都没命中的时候走这里。但如果你打算长期用它撑所有场景迟早会被账单和用户投诉一起找上门。2.2 滑动窗口模式Sliding Window多轮对话的入门解法滑动窗口的核心思路很直接只保留最近N轮对话更早的全部丢弃。N可以是固定轮数也可以按token数动态调整。这个模式在OpenAI早期ChatGPT的简易实现里非常常见因为它基本上解决了“历史无限膨胀”的问题代码复杂度也不高。但它的缺陷很多人没意识到**滑动窗口没有“长期记忆”的概念。**一旦重要信息被滑出窗口就永久消失了。还是拿客服场景举例用户在第3轮说过“我是会员”第20轮问“我这个订单能打折吗”如果窗口只保留最近10轮模型根本不知道他是会员自然算不出折扣。所以滑动窗口适合那些话题连贯、单轮信息量不大、并且早期信息可以被安全遗忘的场景。比如闲聊型机器人、短会话工具。如果你要做需要记忆用户属性的业务系统单靠滑动窗口一定不够。2.3 摘要压缩模式Summarization把历史“榨成汁”摘要压缩模式是目前解决长期对话问题最实用的方案之一。思路是当对话历史超过一定长度时先让模型把前面的内容总结成一段结构化摘要之后每轮请求都带着摘要最近几轮完整消息一起发给模型。这样模型既知道“之前聊过什么”又不至于被全部历史淹没。这个模式的工程细节比较考验人。摘要什么时候生成摘要里该保留什么、该丢什么摘要本身如果累积太长了怎么办我见过不少项目在摘要模式上翻车就是因为只做了“定期总结”但没有管住摘要本身的质量和长度结果摘要变成了一坨新的垃圾信息模型照样被污染。不过只要设计得当摘要压缩模式的效果非常稳定。我自己的项目里把30轮的客服对话压成200~400 token的摘要之后回答准确率反而比全量输入提升了大概11个百分点。原因很简单模型不需要处理大量冗余信息注意力更集中了。2.4 检索增强模式RAG不靠记忆靠外部知识检索增强模式跟前三种完全不是一个维度。它的核心逻辑是不依赖对话历史去“记住”知识而是每一轮都从外部知识库检索相关的片段拼接到上下文里。对话历史只用来理解当前问题答案的主要依据来自检索结果。这种模式非常适合知识库问答、企业文档助手、法律/医疗辅助等场景。它最大的好处是知识来源可控、可更新、可追溯模型不会凭空编造太多的内容。但注意RAG模式不等于不需要上下文管理——恰恰相反它更需要精细控制检索回来的片段怎么排序、怎么截断、和对话历史的占比怎么分配这些都是context-mode要管的事。2.5 模式对比没有银弹只有适配模式适合场景优势劣势典型上下文占比单轮完整注入一次性问答、极少轮对话零丢失、实现简单token暴涨、注意力稀释历史几乎占满滑动窗口闲聊、短会话控制长度、成本可控无长期记忆最近N轮摘要压缩多轮客服、业务助手兼顾记忆与长度摘要可能丢失细节摘要最近几轮检索增强知识库、文档问答知识可控、可溯源依赖检索质量检索片段为主我一般会按“会话长度记忆需求知识来源”三个维度来选型。如果是一个内部业务系统优先上摘要压缩如果知识量很大且更新频繁上检索增强如果只是工具型应用滑动窗口就够用了。千万别一上来就什么都要先选一个主模式跑出数据再迭代。3. 从零实现一个context-mode管理器3.1 管理器到底要管哪些事看了很多上下文管理的代码我发现容易走两个极端一种是过度设计搞了一大堆抽象类和接口实际用起来维护成本很高另一种是压根没设计散落着一堆拼接字符串的函数。我最终沉淀下来的方案介于两者之间一个ContextManager类集中管理三件事消息的存储、消息的组装、预算的控制。存储解决的是“历史往哪放”组装解决的是“每一轮按什么顺序拼成messages”预算控制解决的是“超长时怎么截断和压缩”。这三件事分开想清楚代码结构就自然清晰了。另外管理器还需要记录每一次请求的“上下文快照”——比如本轮用了哪种模式、历史保留了多少条、摘要是什么、最终拼出来的token数是多少。这些快照是后面做效果评估和问题排查的关键素材没有它们你只能靠肉眼猜。3.2 核心数据结构和代码骨架我用Python实现了一个精简版核心数据结构就是dataclass加上一个Manager类。这里不依赖任何重框架只用到最基础的Python库你可以直接移植到自己的FastAPI或异步服务里。from enum import Enum from dataclasses import dataclass, field from typing import List, Dict, Optional import tiktoken class ContextMode(str, Enum): FULL full SLIDING sliding SUMMARIZATION summarization RAG rag dataclass class Turn: role: str # user / assistant content: str tokens: int 0 dataclass class ContextConfig: mode: ContextMode ContextMode.SUMMARIZATION max_input_tokens: int 7000 sliding_window_turns: int 10 summary_interval: int 8 # 每8轮重新生成摘要 summary_max_tokens: int 500 system_prompt: str You are a helpful assistant. encoder_name: str cl100k_base class ContextManager: def __init__(self, config: ContextConfig): self.config config self.turns: List[Turn] [] self.summary: str self.encoder tiktoken.get_encoding(config.encoder_name) # 记录最近一次组装的结构方便排查 self.last_build {} def add_turn(self, role: str, content: str) - None: tokens len(self.encoder.encode(content)) self.turns.append(Turn(rolerole, contentcontent, tokenstokens)) def _count_tokens(self, text: str) - int: return len(self.encoder.encode(text)) def _build_full(self, user_input: str) - List[Dict[str, str]]: messages [{role: system, content: self.config.system_prompt}] for turn in self.turns: messages.append({role: turn.role, content: turn.content}) messages.append({role: user, content: user_input}) return messages def _build_sliding(self, user_input: str) - List[Dict[str, str]]: messages [{role: system, content: self.config.system_prompt}] recent self.turns[-self.config.sliding_window_turns:] for turn in recent: messages.append({role: turn.role, content: turn.content}) messages.append({role: user, content: user_input}) return messages def _build_summarization(self, user_input: str) - List[Dict[str, str]]: # 如果达到了重新摘要的间隔先用模型把历史压缩成摘要 if len(self.turns) % self.config.summary_interval 0: self._refresh_summary() messages [{role: system, content: self.config.system_prompt}] if self.summary: messages.append({role: system, content: f对话摘要{self.summary}}) recent self.turns[-self.config.sliding_window_turns:] for turn in recent: messages.append({role: turn.role, content: turn.content}) messages.append({role: user, content: user_input}) return messages def build_messages(self, user_input: str) - List[Dict[str, str]]: if self.config.mode ContextMode.FULL: messages self._build_full(user_input) elif self.config.mode ContextMode.SLIDING: messages self._build_sliding(user_input) else: messages self._build_summarization(user_input) # 做个硬性保护如果总量超过预算退化成滑动窗口 total sum(self._count_tokens(m[content]) for m in messages) if total self.config.max_input_tokens: messages self._build_sliding(user_input) self.last_build { mode: self.config.mode, total_tokens: total, turn_count: len(self.turns), summary: self.summary, } return messages这段代码已经能支撑一个基本的多轮对话服务了。比较关键的设计是最后一道硬性保护不管什么模式如果组装出来的messages总token数超过了预算就降级成滑动窗口。这相当于给系统上了保险丝不至于因为一条超长输入把整个请求打爆。3.3 token预算怎么分先算账再动手很多人在设置max_input_tokens的时候是瞎填的填个4096、8192然后就不管了。但预算分配其实应该是一个计算题。假设你的模型上下文窗口是32k你希望给模型留出至少2048 token做输出那输入侧最多就是32k减2048大约30k左右。但实际业务中我们通常不会把输入预算用满因为太长的输入会显著增加首字延迟。以我常用的配置为例系统指令固定占用约300 token摘要部分预算控制在500 token以内最近N轮完整消息预算约4000~6000 token当前用户输入预算约1000 token。加起来大概6000~8000 token。所以max_input_tokens我通常会设在7000附近留出余量。如果某条用户输入特别长硬性保护会自动把历史窗口压短优先保证当前问题能够进入上下文。还有一个容易被忽略的点**预算分配要有优先级。**系统指令永远是最高优先级其次是当前用户输入然后是摘要最后才是历史对话。因为从效果上说模型最需要的是理解“你现在要它做什么”而不是“你们过去聊了什么”。很多人排序排反了把历史放在前面当前问题反而被截断自然答不好。3.4 摘要生成不要偷懒单独走一次模型调用摘要压缩模式里最容易踩的坑是“顺手在回答请求里夹带摘要”。也就是说你让模型在正常回答的同时顺便输出一个摘要下轮再用。这听起来省了一次调用但实际效果很差模型在回答任务和生成摘要之间会互相干扰摘要质量不稳定一旦回答里混入摘要片段还会污染用户端展示。我推荐的正确姿势是摘要生成走独立的模型调用。在_refresh_summary里单独构造一个精简的prompt让模型只做压缩任务然后把摘要存起来。摘要生成调用建议用温度低一点的参数比如temperature0.2保证输出的稳定性和可复现性。摘要本身也需要控制长度不能让它无限膨胀。我一般会在摘要prompt里明确要求“不超过X字保留用户身份信息、关键业务规则、未完成事项”。实测下来三个必留项特别好用**用户的身份属性、业务约束条件、还没解决的诉求。**这三类信息漏掉了后续对话基本会崩。4. 工程化落地缓存、评测和监控一个都不能少4.1 前缀缓存省成本的关键手段context-mode组装出来的messages往往带有较长且固定的系统指令和摘要。如果每次都原样发给模型接口这些重复内容的embedding计算会反复消耗算力。很多主流模型服务商都提供了前缀缓存机制也就是对相同前缀的输入做缓存复用。我在项目中启用前缀缓存之后成本大概下降了40%左右。做法很简单在组装messages时把system指令和摘要放在最前面确保这两块内容在连续多轮请求中保持不变。然后调用模型接口时开启对应的缓存参数或者在服务商支持的场景下它会有cache_control之类的标记位。等模型侧缓存命中了费用和响应时间都会明显下降。但注意前缀缓存有命中和未命中的区别未命中时可能还要额外收取写入费用。所以不要盲目开启要先估算连续请求之间前缀的相似度。我一般建议摘要压缩模式下前缀缓存收益最大因为摘要固定且出现在前面滑动窗口模式收益次之因为窗口内容一直在变但系统指令是固定的多少能省一点。4.2 离线评测不评测就去调上下文就是耍流氓很多人优化上下文靠“感觉”。试几轮对话觉得模型好像聪明了就上线了。但对话场景里的感知极不稳定同一个回复上午觉得好下午觉得差。更麻烦的是你改了上下文策略到底是因为策略变好了还是因为模型随机性在起作用完全说不清。我现在的做法是在动手改context-mode之前先准备一组固定的评测样本。每个样本包含一段多轮对话历史和一个新问题以及标注好的期望答案要点。然后跑一个离线脚本把不同的模式配置跑一遍计算答案与期望要点的命中率。这组样本不需要很多50条左右就够了关键是覆盖典型场景——有需要长期记忆的、有需要实时检索的、有容易混淆主题的。有了评测集你才能回答“摘要该压到什么程度”“窗口该保留几轮”这样的问题。我在实际项目中通过评测集发现对于我的客服场景摘要保留400 token左右效果最好超过600 token反而因为包含过多噪声导致准确率下降。这种结论靠肉眼是试不出来的只能靠数据。4.3 线上监控记录快照让问题可回溯线上监控往往是被忽视的一环。很多项目只监控API报错率和Token消耗完全没有记录“每一轮请求的上下文是怎么组织的”。结果一旦用户反馈回答质量有问题你只能从聊天记录里手动猜效率极低。我建议每一轮请求都要把ContextManager.last_build这个结构体连同请求ID、模型回答、用户反馈一起写入日志或数据库。字段包括模式、总token数、历史轮数、摘要内容摘要模式才有、被截断的消息条数。这样当用户投诉时你只需要根据请求ID查一条记录立刻就能判断是上下文模式用错了、摘要丢信息了还是模型本身的问题。更进阶一点可以做一个简单的看板按模式、按时间段统计平均token数和平均首字延迟。比如我后来发现某个入口的对话平均token数突然从5000涨到9000一查发现是有用户在短时间内连续聊了20多轮触发了摘要刷新机制但摘要刷新后token没降下来说明摘要压缩比例没达到预期。这类问题只有监控了才能被发现。5. 常见问题与排查技巧实录5.1 上下文漂移用户突然换了话题模型还在“回味”上一段这是我在实际项目中遇到最多的一个问题。用户聊了半天A话题突然切到B话题模型如果仍带着A话题的历史回答很容易产生混淆。尤其当A话题里包含强业务专有词时模型会把B话题强行往A上靠。解法我总结了两个第一种是轻量方案在组装messages时给历史消息加上时间衰减标记只保留最近几轮完整消息更早的压缩成摘要。第二种是重量方案对每一轮用户输入做“话题切换检测”当话题发生显著变化时直接把完整历史全部清空只保留用户身份等全局信息。我建议先用轻量方案大多数场景够用如果话题切换特别频繁再上检测。5.2 摘要把关键信息弄丢了摘要压缩模式一个极常见的坑是摘要里什么都提了一点但用户最关心的关键信息被“平均”掉了。比如一个客服对话里用户在第5轮明确说了“我只有周五下午有空”但摘要生成时这句话被淹没在大量无关讨论中最后模型约了个周四的维修时间。后来我在摘要prompt里写了强制要求“必须原样保留以下类型信息日期时间、地点、数字、用户ID、订单号、地址。禁止改写或概括这些字段。”这招非常管用准确率一下子拉上来了。如果你发现自己的摘要模式下模型经常遗忘细节优先检查摘要prompt里有没有对关键字段做这样显式的保护。5.3 输入太长首字延迟变得不可接受有用户反馈机器人“越来越慢”你查监控发现首字延迟从500ms涨到了2s。原因大概率是上下文塞得太满。大模型处理输入的时间基本随输入长度线性增长超过一定阈值后增长还会加剧。所以控制延迟本质就是控制输入token数。遇到这种情况我会先把max_input_tokens往下调同时缩短滑动窗口轮数。很多业务其实根本不需要保留那么多历史——用户当前的意图加上最近两三轮的澄清就已经足够回答了。你把窗口从10轮砍到4轮延迟能降一半效果可能反而更好。5.4 上下文模式换了版本效果波动明显换了模型版本之后同样的context-mode配置表现居然出现了明显下降。这种现象我遇到过两次原因多半是不同模型对长文本的注意力分布不一样对摘要的理解能力也不一样。新版模型可能更擅长直接理解完整对话旧版模型反而更依赖清晰摘要。所以上下文策略不是一劳永逸的。每次升级模型我建议把离线评测集重跑一遍重点关注摘要压缩模式下的准确率变化。如果下降了不要急着骂模型可以先试试把摘要重新写详细一些、或者增加保留轮数往往就能找回来。5.5 问题排查速查表症状可能原因首选排查手段答非所问上下文漂移查看最近请求的mode快照确认历史是否过长记住细节但答错摘要丢失关键字段检查摘要文本确认日期/数字是否被概括响应越来越慢输入token超预算看监控中平均入参token压缩窗口轮数模型变笨但无明显规律上游模型版本更新重跑离线评测集对比历史准确率费用突然暴涨前缀缓存未命中检查前缀是否在连续请求间产生了变化新功能上了没效果上下文拼装顺序不对确认系统指令在最前、当前问题没有被截断末尾再分享一个思路我自己在实际操作里最大的体会是context-mode不是一个“做完就丢掉”的功能模块它更像是对话系统的体检报告。你每观察一次它的行为和日志就能更清楚地看到模型在哪里变笨、为什么变笨。一开始我写这套管理器只是为了少挨老板骂后来它反而成了我排查所有对话问题的第一站。如果你正准备给自己的项目加上下文管理我的建议是从摘要压缩模式起步配合离线评测集和请求快照日志。这套组合拳打下来不敢说能解决所有问题但至少能让你从“一直在调一直调不好”的泥潭里走出来。后续可以扩展的方向还有很多动态模式切换、多级摘要树、基于用户反馈的自动调参每一步都是在上面的骨架上做加法不会推翻重来。