做了一段时间大模型应用我发现一个特别容易被忽略、但又直接影响产出质量的问题很多人把上下文Context当成一个简单的拼字符串过程顶多注意一下别超长度却很少去思考这段上下文到底以什么模式在参与生成。打个比方你把一堆材料塞给模型表面上它都看到了但怎么排布、怎么取舍、哪些该保留哪些该压缩直接决定了模型是在认真回答你的问题还是在一堆信息里瞎蒙。我这次想聊聊context-mode这个概念——也就是上下文在应用中的组织模式和控制方式。它不是某个具体模型的参数而是一整套关于如何管理上下文、以什么形态喂给模型、什么时候该切换策略的工程思路。无论你是在做聊天机器人、文档问答、代码辅助工具还是搞 Agent 编排都绕不开这一层。下面我会从一次真实故障说起逐步拆解底层的机制、常见的模式分类以及一套可以直接抄走的工程实现。1. 一次典型的上下文失效故障问题现象与初步定位1.1 症状连续对话后模型失忆和风格漂移先说个我遇到过的真实案例。当时我们在做一个面向内部员工的知识库问答机器人核心场景是让员工针对几十页的规章制度连续提问。比如先问年假怎么计算接着问那病假呢再追问如果入职不满一年怎么办。测试初期一切正常但连续聊到六到八轮之后模型开始出现两个明显的异常第一指令失忆。用户在第一轮就明确说了请基于公司制度回答不要猜到第七轮之后模型开始频繁忽略这个约束给出一些看似合理但完全不在制度文本里的答案。第二风格漂移。最初几轮回答都会引用制度原文的条款编号越往后越倾向于自由发挥口语化严重甚至开始编条款。我们把日志拉出来一看发现输入给模型的内容早就超过了配置的上下文上限于是底层的处理逻辑直接把最前面的历史消息整体丢弃了。也就是说用户最先说的基于制度回答这条最重要的指令连同最初的几轮问答一起被挤出了窗口。这是最粗暴的上下文模式——先入先出导致的典型问题。1.2 排查链路从日志到上下文的实际构成遇到这种问题别急着怀疑模型本身能力不行。我们第一步是把每次请求的输入组装逻辑单独抽出来打印确认发送给模型的 messages 数组里到底有哪几类内容系统提示词、历史对话、检索回来的知识片段、当前问题。打印出来的结果通常是这样的前几轮系统提示词 第一轮的问题和回答 检索到的知识块 当前问题第六轮之后系统提示词 最近三到四轮对话 当前问题最初的系统约束部分被完整保留但第一轮交互和对应的检索知识已经没了表面看系统提示词还在所以模型应该还知道要基于制度回答。但实际缺的是第一轮交互中隐含的示范——模型最初回答时附带的条款引用格式、推理语气这些上下文特征在后续生成中承担着锚点的作用。锚点一旦丢失模型的输出分布就会漂移这不是模型变笨了而是上下文模式设计不当。1.3 根因判断不是长度问题是模式问题继续深挖后我们确认问题不在模型本身也不在单纯的长度不够而在于我们被动地使用了最简单的截断策略。模型处理长上下文的能力是有限的但更重要的是不同位置的上下文内容对当前输出的价值密度完全不同。由此我想提出一个核心观点上下文管理的本质不是装得下而是放得对。所谓 context-mode就是一套显式控制上下文如何组织、如何取舍、如何更新的规则。这个思路贯穿后面所有的优化方案。2. 上下文窗口的内部机制为什么越聊越笨2.1 Token 与注意力机制上下文如何参与推理要真正理解 context-mode绕不开模型本身的工作机制。现代大模型在处理一段文本时会把文本切分成 token词元然后通过自注意力机制让每个 token 都能看到序列中的其他 token。上下文越长模型在每一步生成时需要考虑的信息就越多。这里有个必须知道的量化概念上下文上限通常以 token 数量衡量不同的模型有不同的窗口尺寸例如 8K、16K、32K、128K 甚至更大。但有窗口不等于每个位置的信息都能被充分利用。我在实测中发现当序列长度超过某个阈值后模型对中间部分内容的注意力会明显下降这种现象在业内通常被称为lost in the middle——信息放在开头和结尾容易被注意到放在中段就像被遗忘了一样。生活化类比上下文就像你在一张长桌上摆了一堆文件。桌子足够大文件都能放上去但你的注意力有限只能聚焦桌子两头附近的东西中间区域扫一眼就略过了。模型的注意力也是类似的不是均匀分布的。2.2 信息熵与注意力稀释每轮对话都在往上下文里增加内容随之而来的是注意力稀释。我用一个通俗的公式来理解每个 token 的平均注意力权重 总注意力资源 / 序列长度当历史消息越来越长当前问题所对应的关键信息比如制度原文、用户最初的明确约束在整个输入序列中的占比越来越小模型分配给关键信息的相对权重就被稀释了。哪怕关键信息没有被物理删除它在生成时的指挥作用也会减弱。这就解释了为什么很多人感觉模型聊久了会越来越笨——不是模型退化而是上下文里无效信息太多有效信息被淹没。我在一个测试集上对比过相同问题当上下文从 2K token 扩展到 8K token 时回答与标准答案的一致性下降了接近 20 个百分点。可见塞得越多并不等于记得越牢。2.3 上下文模式切换的临界点不同任务对上下文的敏感性差异极大。我整理过一张大概的映射表不一定精确但可以帮你做初步判断任务类型上下文敏感度说明单轮事实问答低主要依赖检索到的知识块历史对话几乎不参与多轮任务型对话中需要记住用户的目标和关键约束但不需要记住逐字逐句的历史代码生成与修改高依赖前置代码结构、变量命名、依赖关系截断影响非常大长文档分析高需要全局结构感知中间信息的丢失会直接导致结论错误Agent 多步规划高每一步决策依赖前几步的结果上下文断裂会导致规划重启看到这个敏感性差异你就会明白单一的上下文处理策略不可能适配所有场景。所谓 context-mode就是针对不同任务特性选择不同的上下文组织方式。必须承认模式这个词本身就暗示了一件事——它应该是可配置、可切换的而不是写死的。3. 上下文模式的分类与选型五种常见模式3.1 完整保留模式最直观但最浪费完整保留模式是指把从系统提示词到最新消息的全部内容原样送入模型不做任何裁剪。这是最简单、最容易实现的模式适合对话轮次少、交互简短、token 预算宽裕的场景。优点很直接信息无损实现成本低只需要拼接字符串。缺点也明显成本高响应速度慢而且会踩中前面说的注意力稀释问题。我在早期版本中就是用这种模式遇到的最大麻烦不是超长而是虽未超长但已变笨。即使上下文没有突破窗口上限只要长度增长到一定程度回答质量也会肉眼可见地下降。所以我不建议在任何需要连续多轮交互的产品里长期使用完整保留模式。3.2 滑动窗口模式解决超长问题但引入新问题滑动窗口模式是一种最朴素的上下文剪裁策略保持一个固定大小的窗口每当新消息到来就把最早的消息移出窗口。这也是很多框架的默认行为。好处是 token 数量可控、实现简单、内存占用稳定。坏处非常明显它完全不考虑消息的重要性。窗口内的内容只取决于什么时候说过而不取决于这个信息是否关键。我用上面的例子已经证明了最早的用户指令很可能被无情挤出窗口导致模型指令失忆。适合场景简单闲聊机器人、不需要严格长期约束的任务。不适合需要依赖初始指令或长期目标的任务型对话、Agent 应用。3.3 摘要压缩模式用记忆代替原文摘要压缩模式的核心思路是保留系统提示词和最近的少量原文把更早的历史对话通过模型生成摘要以摘要文本替代原文参与后续生成。这种模式模拟了人类的记忆机制——我们不会记得每句话但会记住聊过什么、结论是什么。实测效果在六轮以上的对话中摘要压缩模式在回答一致性和指令遵循性上都明显优于滑动窗口模式。不过代价是每次压缩都需要调用一次模型做摘要生成增加了延迟和成本。而且摘要本身有信息损失如果摘要质量问题没做好模型可能在错误的记忆上展开推理。我一般建议在连续对话超过五轮后再触发摘要太早压缩反而丢失早期有用细节。有一个控制参数值得关注摘要粒度即压缩时保留的是结论还是过程结论。对于需要复盘的场景建议保留过程。3.4 语义检索模式上下文里的精准召回语义检索模式借鉴了 RAG检索增强生成的思路。上下文不再简单地按时间顺序堆叠而是维护一个历史消息库每次请求前只把与当前问题最相关的历史片段召回拼进上下文里。这个模式非常契合多轮对话 知识库问答的场景。比如员工先问了年假制度又问了病假制度中间可能聊了很多无关闲话。等到他追问那入职不满一年呢真正需要的上下文其实是上一轮关于年假的对话而不是中间那些寒暄。优点上下文短而精注意力集中在关键信息上回答质量高、token 开销小。缺点需要额外的检索组件向量数据库或关键词索引召回质量直接决定上下文质量召回错误会导致回答偏离。3.5 混合模式工程上最推荐的落地形态成熟的 context-mode 通常不是单一策略而是多种策略的组合。我现在的做法是给上下文划分不同的优先级区固定区系统提示词、用户长期目标、不可变约束永远保留工作区最近两到三轮的原始对话完整保留记忆区更早的历史通过摘要压缩成记忆块按主题组织检索区从外部知识库或历史库中召回的片段与当前问题相关这个分层结构天然适合用混合模式实现。它兼顾了即时交互的完整性工作区和长期记忆的稳定性记忆区又通过检索区解决了外部知识的注入问题。下面我会用一个具体工程案例来演示这套混合模式怎么落地。4. 实战改造一套多轮问答系统的 context-mode 落地4.1 系统现状与边界条件假设我们要改造一个制度问答机器人。需求如下支持员工针对制度连续提问要求回答始终基于提供的制度文本对话轮次可能很长需要保持指令一致性延迟不能太高每次请求需要在 2 秒内返回允许适度调用摘要模型但不可每次都触发基于这些条件我决定采用工作区 记忆区的二层结构暂不引入复杂的向量检索因为制度的规模不大约 5 万字可以直接把制度全文放在固定区。真正需要优化的是历史对话的管理方式。4.2 核心代码用上下文管理器实现分层策略我用一段简化但结构完整的 Python 代码来演示这套逻辑。以下代码基于主流模型 API 的 messages 格式不绑定具体厂家。from typing import List, Dict import json class ContextManager: 分层上下文管理器 def __init__(self, system_prompt: str, max_work_tokens: int 3000): self.system_prompt system_prompt self.max_work_tokens max_work_tokens self.work_history: List[Dict] [] # 工作区最近几轮原文 self.memory_blocks: List[Dict] [] # 记忆区摘要后的历史 def estimate_tokens(self, messages: List[Dict]) - int: 粗略估算 token 数生产环境建议用分词器精确计算 total 0 for msg in messages: total int(len(msg.get(content, )) * 0.8) # 中文约 0.8 token/字 return total def add_message(self, role: str, content: str): 新增一轮对话 self.work_history.append({role: role, content: content}) if self.estimate_tokens([{content: c[content]} for c in self.work_history]) self.max_work_tokens: self._compress_history() def _compress_history(self): 把最早的一批对话压缩进记忆区 # 取前两轮作为压缩对象 to_compress self.work_history[:4] self.work_history self.work_history[4:] summary_prompt ( 请把以下对话压缩成一段简洁的摘要 保留用户的核心诉求、已确认的结论、引用的制度条款编号。 压缩后的文本应适合作为后续对话的背景信息\n\n json.dumps(to_compress, ensure_asciiFalse) ) # 这里的 summarize 函数需要接入实际的模型调用 summary summarize(summary_prompt) self.memory_blocks.append({role: system, content: f[历史摘要] {summary}}) def build_messages(self, user_question: str) - List[Dict]: 组装最终发送给模型的 messages messages [ {role: system, content: self.system_prompt} ] # 记忆区在前提供长期背景 messages.extend(self.memory_blocks) # 工作区在后提供近期上下文 messages.extend(self.work_history) # 当前问题 messages.append({role: user, content: user_question}) return messages这段代码的核心是build_messages方法的组装顺序系统提示词在最前记忆区摘要紧随其后相当于长期背景工作区原文放在靠后位置相当于近期记忆最后是当前问题。在实际推理中这个顺序能让模型在建立任务基线时看到长期约束在回答具体问题时看到最近的即时信息贴近人类对话的认知顺序。4.3 评测方法用一致性指标替代主观感受改完之后我们不能只说感觉好多了得做量化评测。我给这类场景设计了一套简单可复用的指标指令遵循率每轮答案是否仍然引用了制度条款编号设定为必须动作回答一致性同一问题在对话尾声重复提问与首轮回答的核心结论是否一致事实偏差率人工抽检回答中是否存在制度文本之外的自创条款我用了一组 30 条问题的测试集做了对比。滑动窗口模式下到第八轮指令遵循率会跌到 40% 左右切换到混合模式后同一测试集下指令遵循率稳定在 90% 以上事实偏差率从 35% 降到 8%。注意这 8% 的残留偏差主要来自摘要压缩时丢掉的细节而不是模型自身的幻觉。这个结果印证了前面的判断大部分多轮场景的质量问题不是模型能力不够而是上下文组织方式没有把关键信息放在合适的位置。混合模式的价值不是玄学是通过结构设计保证关键信息始终在注意力最优的区间内。5. 调优路上的几个坑与对应解法5.1 摘要压缩引入的幻觉放大摘要压缩模式看起来很合理但它有一个隐蔽的问题摘要模型可能把用户没说过的话补全出来。比如原始对话里只有员工问了年假怎么算摘要却生成了员工确认年假按 15 天计算而这个结论实际上并未在对话中出现过。这就是摘要幻觉。对应用法摘要 prompt 里必须明确加上只允许重述原文中出现过的信息禁止推断和补充并且压缩阈值不能设置得过低。我试过用足够低温度尽量接近 0来做摘要生成幻觉概率显著下降。核心原则是摘要的职责是删减不是创作。5.2 检索召回粒度太粗和太细都没用如果使用语义检索模式粒度控制是重中之重。粒度太粗召回的是一个完整章节里面大量无关内容会稀释注意力粒度太细召回的是碎片化句子丢失了上下文之间的逻辑关系。我的经验是先按语义段落切分每条知识块控制在 200 到 500 字之间检索时召回 2 到 4 条。召回数量切忌贪多真实场景里我见过有人一次召回 10 条以上的知识块结果模型被各种相似但不完全一致的内容搞晕回答反而更差。检索上下文时质量大于数量。5.3 不设上限的系统提示词膨胀固定区内容会随时间膨胀。制度全文、用户画像、业务规则等全都塞进系统提示词看起来全部重要结果就是所有内容一起被稀释。我在实践中发现系统提示词一旦超过 1500 字模型对其核心指令的遵循度就会明显下降。对应用法把系统提示词里背景性描述压缩掉只保留不可妥协的硬约束。比如你是公司制度问答助手这句可有可无但回答必须引用制度原文条款编号这句必须保留。能用一行说清楚的绝不用三行。另外固定区也不是无限增长的如果制度全文太长建议走检索路线而不是全文塞入。5.4 不同模型对上下文位置的敏感度差异最后提醒一点不同模型对上下文排布方式的敏感度是不一样的不能拿来主义。某些模型对记忆区在前、工作区在后的排布非常适用另一些可能反过来更好。我在切换基础模型后重新评测过一次结果最佳排布方式发生了改变。因此在做 context-mode 调优时务必以评测指标为准不要凭直觉。每一次改动结构调整、顺序调整、摘要粒度调整都跑一遍同一套测试集把变化记录下来。上下文工程本质上是一个系统的实验过程不是一次性写死配置就算完事。6. 基于实测的几点个人体会大概经历了三轮迭代我们才把这套 context-mode 真正稳定下来。第一轮用完整保留模式问题出在长对话说服力下降第二轮改成简单滑动窗口指令跟随性崩了第三轮引入分层结构和摘要压缩才达到可接受的水平。整个过程的收获是上下文的管理策略应当是显式设计的一部分而不是被动的拼字符串。如果你只想记一件事那我会建议任何多轮应用上线前至少跑一个 20 轮以上的压力测试观察输出质量是否随着轮次增加而稳定。如果质量一路下滑第一时间检查上下文模式的配置而不是去调模型温度或换更大窗口的模型。顺带分享一个小技巧在开发调试阶段可以给每次请求的组装逻辑加一行日志输出最终发送给模型的 messages 长度和各分区占比。这个看似不起眼的输出会在排查问题时帮你省下大量时间。看到记忆区占比过大、工作区被挤掉、系统提示词膨胀等异常时你就能第一时间定位到问题而不是对着模型输出发呆。