上下文管理实战：窗口预算、历史裁剪与长文档压缩的工程取舍

1. 上下文管理不是记性好而是知道什么时候该忘很多人第一次听到上下文管理这个词脑子里浮现的是让模型记住更多东西。这个理解不能说错但只对了一半。真正在一线做过多轮对话系统、Agent 工作流或者长文档处理的人会告诉你上下文管理的核心矛盾从来不是记住多少而是在有限的窗口里放什么、丢什么、怎么压缩。我见过太多项目前期 demo 跑得飞起一上真实场景就崩。用户聊到第八轮模型开始答非所问文档超过两万字关键信息被淹没在一堆无关段落里Agent 执行到第五步忘了第一步设定的约束条件。这些问题表面上看是模型不够聪明实际上八成是上下文管理没做好。这篇文章面向的是正在做对话系统、智能助手、文档问答、Agent 编排的开发者也适合对提示工程有一定了解、想深入理解上下文机制的产品和运营同学。我会从实际项目出发把上下文管理拆成几个可操作的层面窗口预算怎么分配、历史消息怎么裁剪、长文档怎么压缩、多轮状态怎么维护、以及那些文档里不会写的踩坑经验。先给一个我自己的判断标准一个好的上下文管理方案应该让模型在任意一轮对话中都能拿到刚好够用的信息而不是尽可能多的信息。多给的信息不是免费的它会稀释注意力、增加延迟、抬高成本甚至引入矛盾。2. 窗口预算把 token 当成钱来花2.1 为什么必须做预算而不是塞满就行大模型的上下文窗口从早期的 4K 一路涨到 128K 甚至更大很多人就觉得窗口这么大随便塞。我实测下来的结论是窗口越大越需要做预算。原因有三个。第一注意力稀释。Transformer 的注意力机制在长上下文里并不是均匀分配的中间部分的信息容易被忽略这就是业内常说的lost in the middle现象。你把关键约束放在第三千字模型可能压根没看进去。第二成本线性增长。输入 token 是要计费的每轮对话都把全部历史塞进去成本会随轮次平方级增长。一个聊了五十轮的用户如果每轮都带全量历史费用会非常难看。第三延迟。输入越长首 token 延迟越高。对话场景里用户对延迟的容忍度很低超过两三秒就开始烦躁。所以预算的本质是在有限的 token 额度里按重要性分配空间。2.2 一个可落地的预算分配模板我在项目里常用的分配比例是这样的你可以根据场景调整模块建议占比说明系统提示词10%~15%角色设定、输出格式、硬约束优先级最高长期记忆/用户画像5%~10%跨会话的稳定信息如偏好、身份检索到的外部知识30%~40%RAG 召回的文档片段按相关度排序近期对话历史25%~35%最近 N 轮原文保证连贯性当前用户输入5%~10%本轮问题必须完整保留预留缓冲5%防止 tokenizer 估算误差导致超限这个表不是拍脑袋来的。系统提示词占比高是因为它承载了不可违背的约束检索知识占比最大是因为它通常是回答质量的决定因素近期历史保留原文是因为改写会丢语气和指代关系。注意不同 tokenizer 对中文的切分差异很大同样一段中文有的按字切有的按词切估算误差可能到 20%。所以永远留缓冲别卡着上限用。2.3 token 估算的实操细节很多人直接用字符数除以 2来估算中文 token这个在多数模型上偏乐观。我的做法是先用目标模型的 tokenizer 跑一批真实样本统计出字符数 : token 数的实际比例再写进代码里做动态估算。# 以某类中文场景为例实测比例约为 1 字符 ≈ 0.7~0.9 token def estimate_tokens(text: str, ratio: float 0.8) - int: return int(len(text) * ratio) def fit_budget(segments: dict, max_tokens: int) - dict: 按优先级裁剪各段直到总 token 不超预算 priority [system, user_input, recent_history, retrieval, memory] result {} used 0 for key in priority: seg segments.get(key, ) cost estimate_tokens(seg) if used cost max_tokens: result[key] seg used cost else: remain max_tokens - used if remain 50: # 留一点空间做截断 result[key] seg[: int(remain / 0.8)] used max_tokens break return result这段代码的关键在于优先级顺序。系统提示和当前输入永远优先历史可以砍检索可以减。实际项目里我会把最近一轮的助手回复也提到高优先级因为它往往包含用户接下来要指代的内容。3. 历史消息裁剪滑动窗口只是最笨的办法3.1 滑动窗口为什么经常不够用最简单的历史管理就是只保留最近 K 轮。这个方案在闲聊场景够用但在任务型对话里会出大问题。举个我踩过的坑用户第一轮说帮我订下周三去某地的票预算不超过八百聊到第十轮确认细节时滑动窗口早把预算八百挤出去了模型就开始推荐超预算的选项。滑动窗口的根本缺陷是它假设越近的信息越重要但真实对话里早期设定的约束往往贯穿全程。3.2 分层记忆把历史拆成原文层和摘要层我现在的做法是分层。最近 3~5 轮保留原文保证指代和语气连贯更早的历史压缩成结构化摘要只保留事实性信息。摘要不是随便让模型总结一下而是按固定字段抽取{ user_goal: 预订下周三的出行票, constraints: [预算不超过800, 下周三出发, 目的地已确认], confirmed_facts: [出发城市已定, 同行人数2人], open_questions: [返程时间未定], tone: 偏正式 }这样做的价值在于摘要层是稳定的、可校验的不会像自由文本摘要那样越滚越模糊。每轮对话结束后用一次轻量调用更新这个结构成本可控。3.3 摘要更新的触发时机不是每轮都更新摘要那样太浪费。我的触发条件是对话轮次达到阈值比如每 5 轮检测到新的硬约束出现预算必须不能这类词历史 token 占用超过预算的 80%这三个条件满足任意一个就触发更新。实测下来一个五十轮的长对话摘要更新大概只发生十次左右成本可以接受。3.4 裁剪时的指代消解裁剪历史有个隐蔽的坑指代丢失。用户说就按刚才那个方案来你把刚才那个方案裁掉了模型就懵了。我的处理方式是在裁剪前做一次指代消解把代词替换成实体。比如把那个方案替换成预算800、下周三出发的方案。这一步可以用规则加小模型结合规则处理常见代词小模型处理复杂指代。实操心得指代消解不要追求 100% 准确覆盖 80% 的常见情况就能显著降低答非所问的概率。剩下的靠摘要层的约束兜底。4. 长文档压缩不是摘要是按需提取4.1 长文档场景的特殊性对话历史的压缩逻辑是时间衰减但长文档不一样。一份两万字的合同关键条款可能在第 300 字也可能在第 18000 字位置和重要性没有必然关系。所以长文档的上下文管理核心是检索加精排而不是简单截断。4.2 分块策略按语义切不按字数切最常见的错误是按固定字数切块比如每 500 字一块。这样切出来的块经常在句子中间断开语义不完整。我的做法是按语义边界切优先在段落、标题、列表项处断开其次在句号、分号处断开实在没有再按字数硬切。切块时保留 10%~15% 的重叠防止关键信息正好落在边界上被割裂。import re def semantic_chunk(text: str, max_len: int 500, overlap: int 60): # 优先按段落切 paras re.split(r\n\s*\n, text) chunks, buf [], for p in paras: if len(buf) len(p) max_len: buf p \n else: if buf: chunks.append(buf.strip()) # 超长段落再按句号切 if len(p) max_len: sents re.split(r(?[。]), p) tmp for s in sents: if len(tmp) len(s) max_len: tmp s else: chunks.append(tmp.strip()) tmp s buf tmp else: buf p \n if buf: chunks.append(buf.strip()) # 加重叠 final [] for i, c in enumerate(chunks): if i 0: c chunks[i-1][-overlap:] c final.append(c) return final4.3 检索后的精排与去重召回阶段通常用向量相似度但向量相似不等于真正相关。我一般会做两件事一是关键词加权重排。把用户问题里的实体、数字、专有名词抽出来在召回结果里做二次打分包含这些词的块往前排。二是去重。重叠切块会导致相邻块内容高度相似如果都塞进上下文等于浪费预算。用简单的文本相似度比如 Jaccard过滤掉重复度超过阈值的块。处理阶段目标常用手段召回尽量不漏向量检索 关键词检索双路精排把最相关的排前面关键词加权、交叉编码器去重不浪费预算相似度过滤截断不超窗口按精排顺序取前 N 块4.4 引用标注让模型知道这话从哪来长文档场景里我强烈建议在每块前面加来源标注比如[文档A-第3节]。这样模型在回答时能引用出处用户也能核对。更重要的是当多块内容冲突时模型能意识到这是两个不同来源而不是把矛盾信息混在一起。踩坑记录早期我没加来源标注结果模型把两份不同文档里的数字混着用生成了一个看似合理但完全错误的结论。加了标注后这类问题基本消失。5. 多轮状态维护把对话当成状态机5.1 为什么纯靠上下文不够对话系统做复杂了你会发现光靠把历史塞进 prompt根本管不住状态。用户可能中途改主意、可能同时进行多个任务、可能一句话里包含多个意图。这些情况靠模型自己从历史里推断稳定性很差。我的经验是把关键状态显式抽出来用结构化数据维护而不是指望模型记住。5.2 状态槽位的设计以任务型对话为例我会定义一组槽位{ task_type: 预订, slots: { destination: {value: 某地, confidence: 0.95, source: turn_1}, date: {value: 下周三, confidence: 0.9, source: turn_1}, budget: {value: 800, confidence: 0.85, source: turn_1}, return_date: {value: null, confidence: 0, source: null} }, status: collecting }每轮对话后更新槽位confidence低或value为空的槽位就是下一步要追问的。这样上下文里只需要放当前槽位状态 最近几轮原文token 占用大幅下降而且状态可追溯、可调试。5.3 状态冲突的处理用户改主意是常态。第一轮说预算 800第五轮说其实可以到一千。这时候不能简单覆盖要记录变更历史并在上下文里明确告诉模型预算已从 800 调整为 1000。我的做法是给每个槽位加一个history字段记录变更轨迹。当模型需要做决策时把变更说明放进上下文避免它用旧值。5.4 多任务并行的隔离一个用户可能同时聊两件事。如果所有状态混在一起模型会串台。解决办法是给每个任务分配独立的task_id上下文里按任务分组呈现模型回复时也明确当前在处理哪个任务。这个设计在客服、助手类产品里特别重要。我见过因为没做任务隔离用户问A 订单的物流结果模型回答了B 订单的退款的事故。6. 那些文档不会告诉你的踩坑经验6.1 系统提示词的位置很关键很多人把系统提示词放在最前面就完事了。但在长上下文里最前面的内容反而容易被忽略。我的做法是首尾都放关键约束开头放完整系统提示结尾再放一句精简版的核心约束比如记住预算不超过 800下周三出发。这样模型在生成时最近的注意力落在约束上遵守率明显提升。6.2 别让摘要自我繁殖摘要层如果每轮都基于上一版摘要再摘要几轮之后就会失真信息一层层丢失。正确做法是摘要始终基于原文生成而不是基于旧摘要。原文可以归档到外部存储需要时重新抽取。6.3 温度参数和上下文长度要联动上下文越长模型越容易发散。我在长上下文场景里会把温度调低一些比如从 0.7 降到 0.3~0.5让输出更聚焦。这个不是绝对的但实测在文档问答和任务型对话里降低温度能明显减少胡编。6.4 监控上下文命中率上线后一定要埋点监控每轮对话里模型实际用到的上下文片段占多少比例。如果长期低于 30%说明你塞了大量无用信息该优化检索和裁剪了。如果高于 90%说明预算太紧可能在丢关键信息。这个指标我称之为上下文命中率是我判断一个上下文管理方案是否健康的核心依据。6.5 边界情况要专门测常规对话测不出问题真正暴露 bug 的是这些场景用户连续快速发多条短消息用户中途切换语言用户引用很早之前说过的内容检索结果为空检索结果之间互相矛盾单轮输入就接近窗口上限我一般会针对这六种情况各写一组测试用例每次改动上下文逻辑都跑一遍。这套用例帮我拦下过好几次线上事故。7. 一套可复用的上下文管理流水线把上面的东西串起来我现在的标准流程是这样的接收输入拿到用户本轮消息做基础清洗和意图识别。更新状态抽取槽位更新任务状态检测约束变更。检索知识如果是知识型问题走召回加精排拿到 top-N 块并去重。组装上下文按预算模板分配空间系统提示首尾各放一份历史分层原文加摘要检索结果带来源标注。裁剪校验估算 token超限则按优先级裁剪裁剪前做指代消解。调用模型带上组装好的上下文和调优后的参数。后处理解析输出更新摘要和状态记录命中率指标。这套流程听起来步骤多但每一步都很轻。真正重的只有检索和模型调用其余都是毫秒级的字符串处理。def build_context(user_input, state, history, retrieval, budget): segments { system: SYSTEM_PROMPT, memory: render_memory(state), retrieval: render_retrieval(retrieval), recent_history: render_recent(history, n4), summary: render_summary(history), user_input: user_input, } packed fit_budget(segments, budget) # 首尾各放一份核心约束 packed[tail_constraint] CORE_CONSTRAINTS return assemble(packed)这段伪代码的重点不在实现而在结构所有上下文来源都是独立的、可单独裁剪的模块而不是一坨拼好的字符串。这样你才能按预算灵活取舍也才能做命中率监控。8. 关于成本、延迟和效果的三方平衡最后聊一个绕不开的话题上下文管理本质上是在成本、延迟、效果之间找平衡点。三者不可能同时最优。我的取舍原则是效果优先的场景如合同审查、医疗问答预算给足检索做深宁可慢一点贵一点。延迟优先的场景如实时客服、语音助手历史只留最近两轮检索只取 top-3摘要用缓存。成本优先的场景如批量处理、内部工具用更小的模型做摘要和精排主模型只负责最终生成。这个平衡点没有标准答案只能靠监控数据不断调。我自己的习惯是每周看一次命中率、平均 token 消耗和用户反馈三者一起看哪边异常就调哪边。上下文管理这件事说到底是个取舍的艺术。你不可能把所有信息都塞进去也不应该指望模型自己搞定一切。把该显式维护的状态维护好把该压缩的历史压缩好把该检索的知识检索准剩下的交给模型它才能发挥出真正的水平。我在多个项目里反复验证过上下文管理做扎实了同样的模型效果能差出一大截。这不是玄学是工程。