1. 上下文窗口告急一个被低估的生产事故源头做过大模型应用的人大概率都遇到过这个场景用户跟机器人聊了四五十轮突然某一次请求直接返回一个 400 错误日志里赫然写着context_length_exceeded或者maximum context length is 128000 tokens。前端弹出一句“服务异常请稍后重试”用户一脸懵你也一脸懵——明明前面几十轮都好好的怎么突然就崩了这个问题的本质是大模型的上下文窗口是有限的而对话历史是无限增长的。不管你用的是 8K、32K 还是 128K 的模型只要对话足够长、检索内容足够多、工具调用返回足够大迟早会撞上这堵墙。撞上之后最粗暴的做法就是直接报错把问题甩给用户。但生产环境里这种做法基本等于自杀——用户不会理解什么叫 token 超限他们只会觉得你的产品不好用。所以真正要解决的问题不是“怎么把窗口做大”而是“窗口满了之后怎么办”。这就是 Context Eviction上下文淘汰要干的事在上下文即将或已经超出模型承载能力时按照某种策略主动丢弃一部分历史内容腾出空间给新的输入让对话能够继续下去。我前后在三个不同规模的项目里落地过上下文淘汰机制从最早的“超了就截断”这种土办法到后来按重要性打分、按语义聚类、按时间衰减的多种策略组合踩过的坑不算少。这篇文章就把我实际用过、对比过的 5 种淘汰策略摊开来聊包括它们各自的实现思路、适用场景、参数怎么调、生产环境下的真实表现以及那些文档里不会写的坑。如果你正在做对话系统、RAG 应用、Agent 工具链或者任何需要维护长上下文的应用这些内容应该能帮你少走不少弯路。2. 为什么不能直接报错上下文淘汰的工程价值2.1 直接报错到底伤害了谁先算一笔账。假设你做一个客服机器人平均每轮对话消耗 800 tokens用户输入 模型回复 系统提示模型窗口 32K。理论上能撑 40 轮左右。但实际场景里用户可能上传一份产品手册让机器人参考这一下就吃掉 10K tokens再加上系统提示词、工具定义、few-shot 示例真正留给对话历史的空间可能只有 15K。也就是说用户聊到第 18 轮左右就会撞墙。如果这时候直接报错用户体验是这样的前 17 轮聊得好好的第 18 轮突然说“系统繁忙”。用户会怎么想他不会觉得是技术限制他会觉得你的产品不稳定、不可靠。更糟糕的是如果这是一个付费产品用户很可能直接流失。从工程角度看直接报错还意味着你放弃了所有已经积累的上下文价值。前面 17 轮对话里包含的用户偏好、问题背景、已确认的信息全部作废。用户不得不重新描述一遍需求这种体验是灾难性的。2.2 淘汰不等于丢失保留核心信息的艺术上下文淘汰的核心思路不是“随便扔掉一些东西”而是“在有限空间里保留最有价值的信息”。这跟人类开会很像一个两小时的会议你不可能记住每一句话但你会记住关键决策、待办事项、重要数据。上下文淘汰要做的就是类似的事——从对话历史中识别出哪些是“关键决策”哪些是“闲聊废话”然后优先保留前者。这里有个关键认知不是所有 token 的价值都一样。系统提示词里的角色定义价值极高绝对不能丢用户第一轮说的核心需求价值很高应该尽量保留中间那些“好的”“明白了”“嗯嗯”的确认性回复价值极低可以优先淘汰。淘汰策略的好坏本质上就是价值判断的准确度。2.3 五种策略的全景对比在展开细节之前先用一张表把五种策略的核心特征拉齐方便你建立整体认知。后面每个策略我都会单独展开讲实现和调参。策略名称核心思路实现复杂度信息保留质量计算开销适用场景滑动窗口只保留最近 N 轮极低低极低短对话、闲聊首尾保留保留开头系统提示 最近 N 轮低中极低通用对话重要性打分按规则给每轮打分淘汰低分中中高低客服、任务型对话语义聚类按语义相似度合并冗余内容高高中高RAG、知识密集型摘要压缩把旧内容摘要成短文本高高高长程 Agent、复杂任务这张表不是让你选一个用而是让你理解不同场景需要不同策略甚至需要组合使用。我后面会讲怎么组合。3. 策略一滑动窗口——最简单也最容易翻车的方案3.1 实现逻辑与代码骨架滑动窗口是所有淘汰策略里最直观的维护一个固定大小的队列新消息进来就把最老的消息挤出去。用 Python 写大概长这样class SlidingWindowContext: def __init__(self, max_turns20): self.max_turns max_turns self.history [] def add_message(self, role, content): self.history.append({role: role, content: content}) # 超出窗口就淘汰最老的 while len(self.history) self.max_turns * 2: # 一问一答算两轮 self.history.pop(0) def get_context(self): return self.history看起来很简单对吧但这里有个致命问题系统提示词也在 history 里会被一起挤掉。我最早做的一个项目就犯了这个错聊到第 25 轮的时候模型突然开始用完全不同的语气回复因为它的角色设定被淘汰了。用户直接投诉“机器人变了一个人”。修正方案是把系统提示词单独存每次请求时拼在最前面def get_context(self): return [self.system_prompt] self.history3.2 参数怎么定max_turns 的计算方法max_turns不能拍脑袋定得算。公式是可用 token 数 模型窗口 - 系统提示词 - 工具定义 - 预留输出空间 max_turns 可用 token 数 / 平均每轮 token 数 / 2举个例子模型窗口 32K系统提示词 500 tokens工具定义 2000 tokens预留输出 2000 tokens那么可用空间是 27500 tokens。如果平均每轮对话用户 助手消耗 600 tokens那么max_turns 27500 / 600 ≈ 45。但这是理论上限实际要留 20% 余量应对突发长输入所以设成 35 左右比较稳。注意平均每轮 token 数一定要用真实数据统计不要凭感觉估。我见过有人按 200 tokens 估结果实际平均 800窗口设大了直接报错。3.3 什么时候能用什么时候绝对不能用滑动窗口适合短对话、闲聊、单轮问答这类场景。比如一个天气查询机器人用户问“明天天气怎么样”机器人答完就结束了根本不需要记住历史。这种场景用滑动窗口完全够用而且开销极低。但以下场景绝对不能用任务型对话用户第一轮说“我要订一张去北京的机票”第 30 轮说“改成后天”如果第一轮被淘汰了机器人根本不知道“改成后天”改的是哪张票。RAG 应用检索到的文档片段如果被淘汰后续追问就失去了依据。Agent 工具链工具调用的返回结果如果被淘汰Agent 会重复调用同一个工具浪费资源。我踩过最惨的一次坑是在一个合同审核 Agent 里用了滑动窗口结果 Agent 把前面已经审核过的条款又审了一遍因为历史被淘汰了。后来换成重要性打分才解决。4. 策略二首尾保留——性价比最高的通用方案4.1 为什么首尾信息价值最高首尾保留策略的核心洞察是对话的开头和结尾信息密度最高。开头通常包含系统提示、用户核心需求、任务定义结尾包含最近的交互直接决定当前回复的上下文。中间部分往往是确认、追问、闲聊信息密度低。这个规律在心理学上叫“系列位置效应”——人对一段序列的开头和结尾记忆最深刻。大模型的注意力机制也有类似特性中间部分的内容容易被“遗忘”lost in the middle 现象。所以首尾保留不仅符合工程直觉也符合模型的实际行为特征。4.2 实现细节首尾各留多少实现上首尾保留是滑动窗口的升级版class HeadTailContext: def __init__(self, head_turns3, tail_turns15): self.head_turns head_turns self.tail_turns tail_turns self.history [] def get_context(self): if len(self.history) self.head_turns self.tail_turns: return [self.system_prompt] self.history head self.history[:self.head_turns * 2] tail self.history[-self.tail_turns * 2:] return [self.system_prompt] head tailhead_turns一般设 2-3 轮够覆盖用户初始需求就行。tail_turns根据可用空间算通常占 70%-80% 的预算。中间被丢弃的部分可以在拼接时加一个标记比如[中间省略 N 轮对话]让模型知道这里有过内容。4.3 一个真实项目的参数调优记录我在一个法律咨询机器人项目里用过首尾保留。初始参数是 head2、tail10结果发现用户经常在前 5 轮里补充关键信息比如“我是在上海签的合同”head2 不够。后来调到 head4问题解决。tail 的调整更有意思。一开始设 tail10但法律咨询的回复通常很长10 轮 tail 就吃掉了 8000 tokens。后来改成按 token 数动态计算 tail而不是按轮数def get_tail_by_tokens(self, budget): tail [] used 0 for msg in reversed(self.history): msg_tokens count_tokens(msg[content]) if used msg_tokens budget: break tail.insert(0, msg) used msg_tokens return tail这样不管每轮长短都能把预算用满。实测下来动态 tail 比固定轮数的信息保留质量高不少。实操心得首尾保留的中间省略标记很重要。不加标记的话模型可能会把 head 的最后一句和 tail 的第一句当成连续对话产生逻辑错乱。加了[中间省略]之后模型能正确理解这是两段不连续的内容。5. 策略三重要性打分——让淘汰有据可依5.1 打分维度设计哪些信号值得关注重要性打分的思路是给每条消息算一个分数淘汰时从低分开始扔。难点在于怎么定义“重要”。我总结了一套在实际项目里验证过的打分维度维度权重说明角色0.2系统提示 用户 助手 工具返回位置0.15越靠近开头和结尾分越高关键词命中0.25包含“必须”“记住”“重要”“不要”等词加分实体密度0.2包含人名、数字、日期、专有名词加分被引用次数0.2后续消息引用了这条内容则加分权重不是固定的要根据业务调。比如客服场景里“实体密度”权重可以调高因为订单号、金额这些实体很关键创作场景里“关键词命中”权重可以调高因为用户明确说的“要幽默”“要正式”这类指令很重要。5.2 打分函数的实现与调参def score_message(msg, index, total, history): score 0.0 # 角色分 role_weights {system: 1.0, user: 0.8, assistant: 0.5, tool: 0.4} score role_weights.get(msg[role], 0.5) * 0.2 # 位置分首尾高中间低 position_ratio min(index, total - index) / (total / 2) score (1 - position_ratio) * 0.15 # 关键词分 keywords [必须, 记住, 重要, 不要, 关键, 核心] if any(kw in msg[content] for kw in keywords): score 0.25 # 实体密度分 entities extract_entities(msg[content]) # 自定义实体抽取 entity_density min(len(entities) / 10, 1.0) score entity_density * 0.2 # 被引用分 if is_referenced(msg, history[index1:]): score 0.2 return score调参的时候有个技巧先跑离线评估再上线。拿一批真实对话数据用不同权重组合跑一遍看淘汰后模型回复的质量。我一般用“关键信息保留率”作为指标——把人工标注的关键信息作为 ground truth看淘汰后还剩多少。5.3 生产环境下的效果与开销重要性打分的计算开销主要在实体抽取和引用检测上。实体抽取可以用轻量级的 NER 模型单条消息 5-10ms引用检测可以用简单的字符串匹配或 embedding 相似度单条 2-5ms。整体下来一次淘汰决策大概 50-100ms对于大多数应用可以接受。效果方面我在一个电商客服项目里对比过滑动窗口的关键信息保留率约 45%首尾保留约 65%重要性打分能到 82%。提升很明显尤其是订单号、金额、用户明确说的偏好这些信息基本不会丢。注意打分函数不要设计得太复杂。我见过有人用了 15 个维度结果调参调到崩溃而且过拟合严重。5-6 个维度足够了关键是权重要贴合业务。6. 策略四语义聚类——RAG 场景的利器6.1 冗余检测哪些内容在重复RAG 应用有个特点检索回来的文档片段经常高度冗余。比如用户问“这个产品的保修政策”检索回来 5 个片段其中 3 个都在说“保修期一年”。如果全塞进上下文既浪费空间又干扰模型。语义聚类的思路是把语义相似的内容合并或去重。具体做法是对每条消息或每个文档片段算 embedding然后做聚类同一簇里只保留信息量最大的那条。from sklearn.cluster import AgglomerativeClustering import numpy as np def deduplicate_by_semantic(messages, threshold0.85): embeddings [get_embedding(m[content]) for m in messages] embeddings np.array(embeddings) clustering AgglomerativeClustering( n_clustersNone, distance_threshold1 - threshold, metriccosine, linkageaverage ) labels clustering.fit_predict(embeddings) # 每个簇保留最长的那条信息量最大 kept [] for label in set(labels): cluster_msgs [m for m, l in zip(messages, labels) if l label] kept.append(max(cluster_msgs, keylambda m: len(m[content]))) return keptthreshold是关键参数。设太高如 0.95去重不彻底设太低如 0.7会误删不同信息。我实测下来 0.82-0.88 比较合适具体要看 embedding 模型。6.2 聚类粒度与合并策略聚类粒度有两个选择按消息聚类和按句子聚类。按消息聚类实现简单但粒度粗可能把一条长消息里的不同信息当成一个整体。按句子聚类粒度细但计算量大而且可能破坏消息的完整性。我的做法是混合先按消息聚类去重再对保留的长消息做句子级去重。这样兼顾效率和效果。合并策略也有讲究。同一簇里保留哪条我试过三种保留最长的信息量最大但可能啰嗦保留最居中的语义最典型但可能丢细节保留最新的时效性最好但可能不完整实测下来“保留最长”效果最稳因为 RAG 场景里信息完整性比简洁性更重要。6.3 计算成本与延迟权衡语义聚类的主要开销在 embedding 计算。如果每次淘汰都重新算所有消息的 embedding延迟会很高。优化方案是缓存 embedding消息进来时就算好存起来淘汰时直接读缓存。即使这样聚类本身也有开销。100 条消息的层次聚类大概 200-500ms。如果对话很长这个延迟不可忽略。我的做法是异步淘汰在后台线程做聚类主线程先用滑动窗口应急等聚类结果出来再替换。这样用户感知不到延迟。实操心得语义聚类不要每轮都做可以每 5 轮做一次或者当上下文使用率超过 80% 时才触发。频繁聚类既浪费算力又可能导致上下文频繁变动影响模型回复的连贯性。7. 策略五摘要压缩——长程 Agent 的终极方案7.1 摘要的时机与触发条件摘要压缩是把旧对话用模型总结成一段短文本用摘要替代原文。这是信息密度最高的方案但也是开销最大的。触发时机有三种阈值触发上下文使用率超过 80% 时触发轮数触发每 N 轮触发一次混合触发阈值 轮数先到先触发我推荐混合触发。纯阈值触发的问题是可能在关键对话中途触发打断思路纯轮数触发的问题是可能在不该压缩的时候压缩。混合触发能兼顾。7.2 摘要 prompt 的设计要点摘要 prompt 的质量直接决定摘要质量。我踩过的坑包括摘要太笼统“用户咨询了产品问题”、丢失关键实体订单号、金额、改变原意。好的摘要 prompt 应该包含请将以下对话历史压缩成一段简洁的摘要要求 1. 保留所有具体的数字、日期、订单号、金额 2. 保留用户的明确需求和偏好 3. 保留已达成的结论和待办事项 4. 保留未解决的问题 5. 用第三人称陈述不要用“用户说”“助手说” 6. 控制在 200 字以内 对话历史 {history} 摘要关键是明确列出要保留的信息类型。泛泛地说“保留重要信息”模型不知道什么算重要。列出来之后摘要质量明显提升。7.3 摘要质量评估与迭代摘要质量怎么评估我用了三个指标实体保留率原文里的实体有多少出现在摘要里意图保留率人工标注的用户意图有多少被摘要覆盖下游任务准确率用摘要替代原文后模型回复质量下降多少前两个可以自动化第三个需要人工评估或 LLM 评估。我一般每周抽 50 条做人工评估持续迭代 prompt。有个反直觉的发现摘要不是越短越好。我试过把摘要压到 100 字结果下游任务准确率掉了 15%。后来放宽到 300 字准确率只掉 3%。所以摘要长度要跟任务复杂度匹配复杂任务需要更长的摘要。8. 五种策略的生产对比数据说话8.1 对比实验设计为了公平对比我设计了一个统一的测试集100 条真实对话平均长度 45 轮涵盖客服、咨询、任务执行三类场景。每条对话人工标注了 5-10 个关键信息点。评估指标关键信息保留率淘汰后关键信息还剩多少下游任务准确率用淘汰后的上下文让模型完成任务看准确率平均延迟淘汰决策的耗时token 节省率淘汰后节省了多少 token8.2 关键指标对比表策略关键信息保留率下游准确率平均延迟token 节省率滑动窗口45%62%1ms60%首尾保留65%74%2ms55%重要性打分82%85%80ms50%语义聚类78%83%350ms65%摘要压缩88%88%1200ms75%数据很说明问题摘要压缩效果最好但最慢滑动窗口最快但效果最差。重要性打分是性价比最高的延迟可接受效果也不错。8.3 组合策略112 的实践实际生产里我很少只用一种策略而是组合使用。我目前最常用的组合是首尾保留 重要性打分 摘要压缩具体流程先用首尾保留快速裁剪把中间部分拿出来对中间部分做重要性打分保留高分内容如果还是超限对低分内容做摘要压缩这样兼顾了速度和效果。实测下来关键信息保留率能到 90%延迟控制在 200ms 以内。def hybrid_eviction(history, budget): # 第一步首尾保留 head, middle, tail split_head_tail(history) # 第二步中间部分打分 scored [(score_message(m), m) for m in middle] scored.sort(reverseTrue) # 第三步按预算填充 result head.copy() used count_tokens(head) count_tokens(tail) for score, msg in scored: msg_tokens count_tokens(msg[content]) if used msg_tokens budget * 0.7: result.append(msg) used msg_tokens # 第四步剩余空间用摘要填充 remaining [m for _, m in scored if m not in result] if remaining: summary summarize(remaining) result.append({role: system, content: f[历史摘要] {summary}}) result.extend(tail) return result9. 常见问题与排查技巧实录9.1 淘汰后模型“失忆”怎么办这是最常见的问题。表现是模型突然问“你刚才说的什么”或者重复之前已经确认过的信息。原因通常是关键信息被淘汰了。排查思路先看淘汰日志确认哪些消息被扔了检查打分函数看关键信息是不是被打低分了检查摘要质量看摘要有没有覆盖关键信息解决方法调高关键信息的权重或者在淘汰前做一次“关键信息提取”把提取出的信息作为 system 消息强制保留。9.2 摘要越摘越离谱的修复摘要压缩用多了会出现“摘要的摘要”信息层层丢失最后变得面目全非。我遇到过最离谱的一次摘要里出现了原文根本没有的信息模型“幻觉”了。修复方法限制摘要层级最多做两级摘要不要无限套娃保留原始关键信息摘要时把实体、数字单独提取出来不参与压缩定期重置每 50 轮做一次全量摘要用原始对话重新生成而不是基于旧摘要9.3 淘汰引发的上下文不一致有时候淘汰后模型会“精神分裂”前面说 A后面说 B。原因是淘汰把有逻辑关联的消息拆散了。比如用户说“我要退款”助手问“哪个订单”用户答“12345”如果“我要退款”被淘汰了“12345”就失去了上下文。解决方法按对话轮次淘汰而不是按单条消息淘汰。一问一答作为一个整体要么都保留要么都淘汰。这样能保持逻辑完整性。9.4 常见问题速查表问题现象可能原因排查方法解决方案模型失忆关键信息被淘汰查淘汰日志调高权重或强制保留摘要失真摘要层级过深查摘要历史限制层级定期重置上下文不一致关联消息被拆散查淘汰粒度按轮次淘汰延迟过高淘汰计算太重查耗时分布异步淘汰或降频token 仍超限预算计算错误查 token 统计重新计算预算避坑技巧上线前一定要做压力测试。用超长对话100 轮以上跑一遍看淘汰机制是否稳定。我见过太多项目在短对话下没问题一上长对话就崩。10. 落地建议从哪开始怎么迭代如果你现在正准备给自己的应用加上下文淘汰我的建议是不要一上来就搞最复杂的方案。先从首尾保留开始它能解决 80% 的问题实现成本极低。上线后观察一段时间收集真实数据看看哪些信息经常被误删再针对性地引入重要性打分。迭代节奏我一般这么走第一周首尾保留上线观察基本效果第二到四周收集数据标注关键信息训练打分函数第五周重要性打分上线对比效果第六周起根据场景引入语义聚类或摘要压缩监控指标要盯紧三个上下文使用率看淘汰触发频率、关键信息保留率看淘汰质量、下游任务准确率看最终效果。这三个指标任何一个异常都要及时排查。最后分享一个我用了很久的小技巧给淘汰机制加一个“逃生舱”。当所有策略都失效、上下文还是超限时不要报错而是把最老的内容替换成一句[早期对话已省略]保证请求能发出去。虽然信息丢了但至少服务不中断。这个兜底机制帮我避免了好几次线上事故。上下文淘汰这件事本质上是在信息完整性和系统可用性之间找平衡。没有完美的策略只有适合当前场景的策略。多试、多测、多调慢慢就能找到那个平衡点。