1. 上下文管理不是记性好而是知道什么时候该忘很多人第一次接触上下文管理这个词是在做对话系统或者长文档处理的时候。一开始大家的直觉都是上下文嘛不就是把之前说过的话都带上让模型记住于是拼命往窗口里塞历史记录结果发现效果反而越来越差——答非所问、前后矛盾、关键信息被淹没。这时候才意识到上下文管理的核心根本不是记住更多而是在正确的时机保留正确的信息把不重要的果断丢掉。我做了几年对话系统和长文本处理相关的项目踩过的坑基本都集中在这一点上。上下文管理本质上是一套信息调度机制它要解决三个问题哪些信息该进上下文、这些信息以什么形式排列、什么时候该把旧信息清理出去。这三个问题听起来简单但每一个都直接决定了系统的响应质量和运行成本。这篇文章适合两类人看一类是正在做对话系统、智能助手、长文档问答的开发者另一类是想搞清楚为什么我的模型总是答偏的产品和运营同学。我会从实际项目出发把上下文管理的分层结构、裁剪策略、压缩方法、排序技巧和常见坑一个个拆开讲尽量做到看完就能上手改自己的系统。全文不会堆砌概念重点放在为什么这么设计和实测怎么调上。2. 上下文的分层结构别把所有信息当成一回事2.1 系统指令、会话历史、当前输入的三层划分刚开始做对话系统的时候我习惯把所有内容拼成一个大字符串丢给模型。后来发现这种做法在短对话里勉强能用一旦轮次超过十轮就开始出问题。原因很简单不同信息的保质期和优先级完全不一样混在一起就没法精细控制。比较稳妥的做法是把上下文分成三层。最上层是系统指令层包括角色设定、输出格式要求、安全边界这些它的特点是几乎不变而且优先级最高任何时候都不能被挤掉。中间层是会话历史层记录用户和系统之前的交互它的特点是会不断增长需要定期裁剪。最下层是当前输入层也就是用户这一轮说的话以及系统检索到的相关素材它的特点是时效性最强必须完整保留。这三层的优先级顺序是系统指令 当前输入 会话历史。为什么当前输入比历史更重要因为用户这一轮问的问题才是他要解决的核心历史只是辅助理解。我见过不少系统把历史记录放在最前面结果模型被前面的内容带偏忽略了用户当前的真实意图。2.2 为什么优先级顺序不能随便调有人可能会问把历史放前面不是更符合时间顺序吗从阅读习惯上确实如此但从模型注意力机制的角度看放在开头和结尾的内容通常获得更高的关注度中间部分容易被稀释。这就是所谓的中间遗忘现象。所以一个实用的排列策略是系统指令放最前面当前输入和检索素材放最后面会话历史夹在中间。这样模型在生成回复时既能看到明确的角色约束又能抓住用户当前的问题历史作为背景补充。我实测下来同样的内容用这个顺序排列回答的准确率比历史在前的顺序高出不少尤其是在多轮任务型对话里。提示如果你的系统指令很长可以考虑把它拆成固定部分和可变部分固定部分永远保留可变部分根据当前任务动态拼接避免每次都占用大量窗口。2.3 分层之后要解决的第一个问题预算怎么分分层只是第一步真正难的是给每一层分配多少窗口预算。假设你的模型上下文窗口是 8000 token系统指令占了 500当前输入和检索素材占了 2000那留给历史的就只有 5500。这 5500 怎么用直接决定了多轮对话的连贯性。我的经验是给历史层设一个软上限比如不超过总窗口的 50%。一旦历史超过这个比例就触发裁剪。为什么要留余量因为模型生成回复本身也要消耗 token如果输入把窗口占满输出空间就被压缩了容易出现回答被截断的情况。这个软上限不是固定的任务越复杂、需要的历史背景越多可以适当调高但一般不建议超过 60%。3. 裁剪策略滑动窗口只是最粗糙的一种3.1 滑动窗口的适用边界与失效场景说到裁剪大多数人第一反应是滑动窗口——保留最近 N 轮对话更早的丢掉。这个方法实现简单在闲聊类场景里够用但它的缺陷也很明显它假设越近的信息越重要可现实往往不是这样。举个典型场景用户在第一轮说我要订一张去某地的票时间是下周三然后中间聊了七八轮关于座位、餐食的细节最后说就按刚才说的办。这时候如果滑动窗口把第一轮丢掉了系统就不知道刚才说的到底指什么。关键信息往往出现在对话早期而滑动窗口恰恰会把它裁掉。所以滑动窗口只适合那些每轮相对独立、不需要长期记忆的场景。一旦涉及任务型对话、多轮信息收集就必须换更聪明的策略。3.2 基于重要性的保留给每条消息打分更靠谱的做法是给每条历史消息打一个重要性分数裁剪时优先保留高分消息。分数怎么来可以从几个维度综合维度说明权重建议信息密度是否包含实体、数字、时间等关键信息高任务相关性是否与当前任务目标直接相关高时效性距离当前轮次的远近中用户强调用户是否用了记住重要等词中冗余度是否与其他消息重复低用于扣分这个打分不需要很精确用简单的规则引擎就能实现。比如检测到消息里包含日期、金额、人名这类实体就加高分检测到和前面消息高度重复就扣分。我实测下来规则打分虽然粗糙但比纯滑动窗口的效果好一大截尤其是在信息收集类任务里。3.3 摘要压缩把多轮对话压成一段话当历史实在太长光靠裁剪还是放不下时就需要做摘要压缩。思路是把较早的若干轮对话交给模型让它生成一段简短的摘要然后用这段摘要替代原始对话。这里有个关键细节摘要不能只保留发生了什么还要保留结论是什么。比如用户比较了三个方案最后选了第二个摘要里必须写清楚用户最终选择了方案二而不是只写用户比较了三个方案。前者是决策结果后者只是过程过程可以丢结果不能丢。摘要压缩的另一个坑是摘要的摘要。如果你对已经压缩过的摘要再做一次压缩信息会快速衰减几轮之后就面目全非了。我的做法是设置一个压缩层级上限最多压两层再往前的就直接丢弃同时确保关键结论被提升到更高层级保存。3.4 裁剪触发时机别等到爆了才动手很多人是等到上下文快满了才开始裁剪这时候往往已经很被动。更好的做法是设置一个预警阈值比如窗口使用率达到 70% 就触发一次轻度裁剪达到 85% 触发重度裁剪。这样系统始终运行在一个相对宽松的状态不会因为突然的超长输入而崩溃。裁剪的粒度也要注意。按轮裁剪比按条裁剪更合理因为一轮对话里的用户消息和系统回复是有关联的拆开裁剪容易造成语义断裂。如果一轮对话本身就很长可以在轮内做摘要但尽量不要把一轮拆成两半。4. 上下文压缩在有限窗口里塞进更多有效信息4.1 冗余信息的识别与去除上下文里最占地方又最没用的是冗余信息。常见的冗余有几类重复的问候语、反复确认的客套话、系统生成的格式化提示、以及用户重复表达同一意思的不同说法。这些东西在人类看来是礼貌在模型看来就是噪声。识别冗余可以用简单的相似度计算。把每条消息转成向量计算两两之间的余弦相似度超过阈值的就认为是重复保留信息量更大的那条。这个操作在预处理阶段做一次能省下不少窗口空间。我做过一个统计在客服类对话里去掉冗余后上下文长度平均能压缩 20% 到 30%而关键信息几乎没损失。4.2 结构化改写把自然语言变成紧凑格式自然语言很啰嗦同样的信息用结构化格式表达能省很多 token。比如一段对话用户我想订下周三下午的票从A地到B地两个人。 系统好的下周三下午从A地到B地的票两张对吗 用户对。压缩成结构化格式就是订单意图订票时间下周三下午出发地A目的地B人数2状态已确认。信息一点没少token 却少了一大半。这种改写适合任务型对话因为任务型对话的信息本身就是结构化的只是用自然语言包装了一层。改写的时候要注意保留用户的原始措辞中可能存在的歧义比如下午到底是几点如果用户没说清楚就不要擅自补全而是标记为待确认。4.3 关键实体抽取让重要信息浮出来除了压缩还要让关键信息更容易被模型注意到。做法是把对话中的关键实体抽取出来单独放在一个要点区附在上下文末尾。这样即使原始对话被裁剪了要点区里的实体还在。抽取哪些实体取决于任务类型。订票任务抽时间、地点、人数技术支持任务抽产品型号、错误码、操作步骤咨询任务抽用户诉求、约束条件。抽取可以用规则加模型结合的方式规则保证召回模型保证准确。注意要点区不是越大越好。如果什么都往里塞它就变成了第二个上下文失去了提纯的意义。我的经验是控制在 5 到 10 条以内每条不超过 20 个字。4.4 压缩与保真的平衡点在哪压缩最大的风险是丢信息。压得太狠模型就失去了必要的背景回答会变得空洞或者错误。压得太松又起不到节省窗口的作用。这个平衡点怎么找我的方法是做 A/B 测试。准备一批典型的对话样本用不同的压缩强度跑一遍对比回答质量。具体看两个指标一是关键信息保留率二是回答准确率。当压缩强度增加到某个点回答准确率开始明显下降时就说明压过头了往回退一档。一般来说把上下文压缩到原始长度的 40% 到 60% 是一个比较安全的区间。低于 40% 就要非常小心除非任务本身对背景要求很低。5. 排序与位置同样的内容放错地方就白搭5.1 首尾优先利用模型的注意力分布前面提到过模型对开头和结尾更敏感这个特性在上下文管理里要充分利用。最重要的信息——系统指令、当前问题、关键结论——应该放在首尾两端。中间部分放次要的、辅助性的内容。具体操作上我习惯这样排系统指令在最前紧接着是当前任务要点从历史里提炼出来的关键结论然后是压缩后的历史对话最后是用户当前输入和检索到的素材。这样模型一上来就看到约束和要点生成时又能看到最新输入中间的历史作为背景。5.2 相关素材的插入位置越靠近问题越好如果你用了检索增强检索到的素材放哪里很关键。放在最前面模型可能看完就忘了放在最后面紧挨着用户问题模型在生成时能直接参考。所以检索素材应该放在用户当前输入的前面或者后面越近越好。但要注意如果检索素材很多全堆在末尾会挤占输出空间也会让模型分心。这时候要做二次筛选只保留和当前问题最相关的几条其余的要么丢弃要么压缩成一句话摘要。5.3 时间顺序 vs 重要性顺序的取舍历史对话是按时间顺序排还是按重要性排这两种排法各有道理。时间顺序符合叙事逻辑模型容易理解因果关系重要性顺序能让关键信息更突出但可能打乱因果链。我的折中方案是主体按时间顺序排但在开头加一个要点回顾区把最重要的几条按重要性列出来。这样既保留了叙事逻辑又突出了重点。如果对话本身逻辑性不强比如用户东一句西一句那就干脆按重要性排别硬凑时间线。5.4 分隔符与标记让模型分得清边界上下文里混着系统指令、历史、素材、当前输入如果不加标记模型很容易搞混。所以要用清晰的分隔符和标签把它们区分开。比如用[系统指令]、[历史对话]、[参考资料]、[当前问题]这样的标签。标签要统一不能这次用方括号下次用尖括号。标签本身也要简洁别用一长串说明文字那反而占地方。我见过有人用[以下是系统指令请严格遵守不得违反]这种纯属浪费 token一个[系统]就够了。6. 多轮对话里的状态跟踪别让上下文断片6.1 槽位填充与状态机任务型多轮对话的核心是状态跟踪。用户不会一次性把所有信息给全而是分多轮慢慢补充。系统需要维护一个槽位表记录哪些信息已经收集到哪些还缺。比如订票任务槽位包括出发地、目的地、时间、人数。第一轮用户说了出发地和目的地槽位表就填上这两项其余标记为待填。下一轮用户补充了时间就更新槽位表。每一轮生成回复前先看槽位表还缺什么缺什么就问什么。这个槽位表本身就是一种上下文压缩——它把多轮对话的精华浓缩成了几个字段。即使原始对话被裁剪了只要槽位表还在系统就不会断片。6.2 指代消解搞清楚它那个指什么多轮对话里充满了指代。就按刚才说的办那个方案再改改它什么时候能到这些刚才那个它如果消解不了系统就没法正确响应。指代消解要在上下文管理阶段做而不是等模型去猜。做法是维护一个最近提及实体列表按时间倒序排列。遇到指代词时从列表里找最近的、语义匹配的实体来替换。比如它前面最近提到的名词是订单那就把它替换成订单。这个替换要在送入模型之前完成让模型看到的是消解后的明确表述。实测下来做了指代消解的对话系统在多轮场景里的准确率提升非常明显。6.3 话题切换的检测与处理用户聊着聊着突然换话题这也是常见情况。如果不做处理旧话题的上下文会干扰新话题的回答。所以需要检测话题切换一旦检测到就把旧话题的上下文压缩或者隔离。检测方法可以用关键词匹配加语义相似度。如果当前输入和最近几轮对话的相似度突然下降就可能是话题切换。这时候可以把旧话题的历史折叠成一句摘要标记为之前的话题然后为新话题腾出空间。6.4 状态回滚用户改主意了怎么办用户改主意是高频操作。算了还是改成两个人吧时间改到周四。这时候槽位表要能回滚和更新不能只是追加。如果只是追加槽位表里就会出现矛盾信息模型不知道该信哪个。做法是给每个槽位维护一个版本用户修改时更新版本号只保留最新版本。同时在上下文里明确标注用户已将人数从 1 改为 2让模型知道这是修改而不是新增。这样既保留了修改历史又不会造成歧义。7. 实测中的坑那些文档不会告诉你的细节7.1 上下文不是越长越好这是我最想强调的一点。很多人有个误区觉得窗口大就使劲塞塞得越满模型知道得越多。实际上上下文越长噪声越多模型抓重点的难度越大。我做过对比测试同样的问题给 2000 token 的精准上下文和给 8000 token 的冗余上下文前者的回答质量反而更高。所以别迷信大窗口要把精力放在提纯上。宁可少给不可乱给。7.2 系统指令被稀释的问题系统指令放在最前面按理说应该最受重视。但如果后面跟了很长的历史对话系统指令的影响力会被稀释。模型生成到后面可能就忘了最初的约束。解决办法有两个一是在上下文末尾再重复一遍关键约束形成首尾呼应二是把系统指令拆成多条穿插在上下文里。我一般用第一种简单有效。比如在末尾加一句再次提醒回答必须用中文且不超过三句话。7.3 裁剪导致的记忆断层裁剪最怕的是把有因果关系的内容裁掉一半。比如用户说因为预算有限所以选经济舱如果只保留了选经济舱而裁掉了预算有限模型可能会追问为什么选经济舱显得很蠢。避免方法是按语义单元裁剪而不是按消息条数裁剪。一个语义单元可能包含好几轮对话裁剪时要整块保留或整块丢弃。判断语义单元可以用话题分割算法也可以用简单的规则比如遇到明显的转折词就切一刀。7.4 压缩后的信息失真摘要压缩难免失真。我遇到过最离谱的一次用户说不要红色的摘要写成了用户提到了红色意思完全反了。这种否定词丢失是摘要的常见问题。所以摘要生成后要做校验重点检查否定词、数量词、时间词有没有丢。可以用规则做一遍检查比如原文有不别勿这类词摘要里必须有对应的否定表达。校验不通过就重新生成或者干脆保留原文不压缩。7.5 多语言混用的处理用户中英文混着说的情况很常见。帮我 book 一个 meeting room这个 API 的 response 太慢了。如果上下文管理没处理好模型可能会只回应中文部分或只回应英文部分。处理方法是统一语言标记把混用内容归一化。可以在预处理阶段把英文术语翻译成中文或者反过来保持上下文语言一致。如果术语翻译会失真就保留原文但加注中文说明。关键是让模型看到的是语言统一的上下文减少它的理解负担。8. 一套可落地的上下文管理流程把前面讲的串起来我给出一套实际项目里用过的流程你可以直接参考。第一步接收输入。拿到用户当前输入后先做预处理去除多余空格、统一标点、检测语言、识别指代词。第二步更新状态。把当前输入里的信息抽取出来更新槽位表和实体列表。如果有指代词用实体列表做消解。第三步判断话题。计算当前输入和最近对话的相似度判断是否话题切换。如果是折叠旧话题如果不是继续当前话题。第四步组装上下文。按系统指令 要点回顾 压缩历史 参考资料 当前输入的顺序拼接。拼接时检查各部分的 token 占用确保总长度在预算内。第五步裁剪与压缩。如果超出预算先裁剪低分历史再对较早的历史做摘要压缩。压缩后做否定词校验。第六步生成回复。把组装好的上下文送入模型生成回复。生成时监控输出长度避免被截断。第七步回写历史。把本轮的用户输入和系统回复写入历史更新重要性分数为下一轮做准备。这套流程看起来步骤多但每一步都不复杂用几百行代码就能实现。关键是每一步都要有明确的触发条件和退出条件不能含糊。步骤核心动作关键检查点接收输入预处理、语言检测指代词是否识别更新状态槽位更新、实体抽取是否有矛盾信息判断话题相似度计算阈值是否合理组装上下文按优先级拼接token 预算是否超裁剪压缩打分裁剪、摘要否定词是否保留生成回复调用模型输出是否截断回写历史更新分数分数是否合理9. 几个容易被忽略的工程细节9.1 token 计数要准别用估算上下文管理里 token 计数是基础。如果计数不准预算就会失控。不同模型的 tokenizer 不一样同一个字符串在不同模型下的 token 数可能差很多。所以要用目标模型对应的 tokenizer 来计数别用字符数除以某个系数来估算那个误差太大。我吃过这个亏。早期用字符数估算结果中文和英文混排时误差能到 30%导致有时候超窗有时候浪费。后来换成精确计数问题就没了。9.2 缓存常用片段减少重复计算系统指令、固定的参考资料这些内容每次都要重新计算 token 和拼接很浪费。可以把它们缓存起来只在变化时更新。这样每轮对话的处理时间能省不少。缓存要注意失效策略。系统指令一般不变可以长期缓存参考资料如果来自检索每次都可能不同就不适合缓存。分清楚哪些是静态的、哪些是动态的分别处理。9.3 日志要记全方便复盘上下文管理出问题时最难的是定位。所以日志要记全每轮输入了什么、裁剪了什么、压缩成什么、最终送给模型的是什么。这样出问题才能回溯。日志不用记全部内容记关键信息就行token 数、裁剪了哪几条、摘要内容、最终上下文的哈希值。哈希值可以用来快速判断两次请求的上下文是否相同排查缓存问题很有用。9.4 灰度发布别一次全量上下文管理策略的调整对效果影响很大别一次全量上线。先在小流量上跑对比关键指标确认没问题再逐步放量。指标至少要看两个回答准确率和平均 token 消耗。有时候准确率上去了但 token 消耗暴涨这种也要权衡。我在实际项目里养成的习惯是任何涉及上下文策略的改动都先跑一周的灰度观察指标稳定后再全量。这个习惯帮我避免了好几次线上事故。10. 我在实际项目里踩过的三个印象最深的坑第一个坑是过度依赖摘要。有段时间我为了省 token把所有超过三轮的历史都做摘要结果发现模型经常失忆用户前面明确说过的约束后面就不认了。后来改成只对超过五轮的历史做摘要而且摘要必须保留所有否定词和数字问题才解决。教训是摘要能省空间但省不出准确性该保留的原文还得保留。第二个坑是忽略了输出 token 的预算。有次上下文组装得很完美输入刚好卡在窗口上限结果模型生成到一半被截断回复不完整。后来我在预算里强制留出 20% 给输出再也没出现过截断。这个细节文档里很少提但实际很致命。第三个坑是指代消解做过头。有次我把所有代词都替换成实体结果一些本来指代明确的句子被改得啰嗦又别扭模型反而理解错了。后来改成只对模糊指代做消解明确的指代保留原样。教训是消解是为了消除歧义不是为了消灭代词别做无用功。这三个坑的共同点是都是用力过猛。上下文管理的很多问题不是做得不够而是做得太多。知道什么时候该停手比知道怎么操作更重要。