1. 从一次"答非所问"说起：context-mode到底是什么
上周我在给内部日志告警工具加一个智能诊断功能，需求很简单：把最近一小时的异常日志喂给大模型，让它输出根因分析和处理建议。结果第一次跑出来的效果让人哭笑不得——模型没有给我任何结论，反而把日志里那几条Error当成了"用户想看的内容"，逐条复述了一遍，甚至还在结尾补了一句"以上是本次遇到的错误列表"。
我盯着输出愣了几秒，第一反应是"模型抽风了"，但第二反应很快纠正过来：问题出在我自己身上。我用了最省事的做法，把一大段日志原文直接拼在对话里，没有告诉模型这段上下文"是什么身份、该怎么对待"。说白了，就是没管好上下文模式的取舍。
很多人把AI答非所问归咎于"模型笨"，其实大多数时候是上下文组织方式不对。context-mode，可以理解为模型的注意力调度规则，也就是一套控制"哪些信息参与决策、以什么权重参与、按什么视角输出"的策略。它不是某个官方API里必备的开关，而是我们在做AI应用时绕不开的一种设计思路：当一段上下文中既有任务指令、又有参考材料、还有历史对话时，模型凭什么知道该听谁的、该忽略谁？
在动手调这个功能的过程中，我逐渐把context-mode拆成了可落地的几个维度。这篇文章就把我这几周的实测记录、踩过的坑和一套自查方法完整写出来，给同样在跟大模型上下文打交道的朋友做个参考。
1.1 翻车现场还原：一段日志引发的"复读机"
先说那个反例的具体配置。我当时的做法是：
系统提示词：你是一个日志诊断助手，请分析用户提供的日志并给出根因。 用户消息：这是最近一小时的全部异常日志，请分析： [粘贴了大概80行日志，包含ERROR、WARN、堆栈片段]看起来没毛病，指令明确、资料也给了。但模型输出的是：逐条翻译日志内容、把每个ERROR的时间点列出来、最后建议"关注数据库超时"。不是说它完全错了，而是这种输出根本没用——我需要的是"哪个服务最先异常、为什么、怎么修"，它给的却是流水账。
问题出在哪？当一条用户消息里同时塞了"命令"和"资料"两种性质的文本，模型倾向于把"最长的文本段"当作主要处理对象。日志占了90%的token，默认权重就被拉高了，指令反而被稀释。我后来把这个场景切换成明确的"先指令、后资料、中间用分隔符隔开、再声明资料仅供引用"的结构，同样的日志，输出质量立刻不一样。这就是第一个context-mode原则：上下文内容必须带"身份标签"，不能一锅炖。
1.2 context-mode的三个控制维度
我用一个表格把这段时间摸索出来的核心维度列一下，后面所有的调优都是围绕这三个维度展开的：
| 控制维度 | 要回答的问题 | 常见误区 |
|---|---|---|
| 内容选择 | 哪些信息该进入上下文？哪些该留在外面？ | 总觉得塞得越多越准，实际是噪声大于信号 |
| 内容编排 | 指令和参考资料按什么顺序、什么结构组织？ | 随机拼接，没有分隔和优先级 |
| 输出口径 | 模型应该以什么身份、什么详细程度来回答？ | 不声明口径，让模型自由发挥 |
接下来说的几种模式，本质就是在这三个维度上做了不同的预设。
2. 三类主流形态：连续对话、单轮补全、检索增强
2.1 连续对话模式（Conversation Mode）：历史的边吃边吐
连续对话模式是最常见的默认方式，ChatGPT网页版、各种聊天机器人基本都是这个思路：把多轮历史消息全部塞进上下文，模型在完整对话脉络里生成下一句。好处是衔接自然，适合追问、澄清、多轮修改。
但它的隐患也很典型：历史消息越堆越长，注意力会被"最近几轮"占据，早期的关键信息会慢慢被挤出去。我自己实测过一个多轮改需求的任务，前五轮用户明确说了"不要用红色主题"，结果到第十轮模型开始推荐红色按钮，因为它已经"忘了"。不是真忘了，是早期那条约束在全部历史里的权重占比太低，被后续大量讨论淹没了。
解决办法不是无限扩大窗口，而是给历史做"裁剪"和"摘要"。实操中我一般给自己维护的用户对话记录设定两个规则：
- 保留最近3-5轮完整消息，更早的压缩成一句摘要，例如"用户已确认：采用蓝色主题、拒绝月度订阅、偏好简洁风格"；
- 每轮新问题出现时，把跟当前问题有关的旧约束提到最前面，而不是依赖模型自己找回。
2.2 单轮补全模式（Completion Mode）：前缀定调，后面跟着写
补全模式跟对话模式的最大区别是：它没有"你来我往"的意识，模型的角色就是把已有的前缀续写下去。代码补全工具（比如各类AI编程插件）就是典型的补全模式——光标前的代码就是上下文，模型的任务是让后面的代码在风格上和逻辑上和前文保持一致。
这种模式在某些场景下比对话模式好用得多。最典型的就是批量生成结构化内容：我写配置文档时，只要在前面给出一个优秀示例，然后让模型"按同样的风格继续写下一段"，效果比对话模式里反复说"请参照上面的风格"更稳定。原因很直接：补全模式天然把前文当作唯一权威，指令不用反复强调。
当然它也有代价：对前文的无条件遵循意味着"前文有错，后面跟着错"。如果你给模型一段有bug的旧代码让它补全新功能，它大概率会用同样的错误写法继续，因为它认为前文就是标准。这种模式适合"前文质量有保障"的场景，不适合"前文只是参考"的场景。
2.3 检索增强模式（RAG Context Mode）：把相关资料"焊"进上下文
检索增强模式是目前企业级AI应用里用得最多的一种。它的核心流程是：用户提问后，先去知识库检索相关片段，把命中片段和问题一起塞给模型，让模型基于这些片段回答。这里面的context-mode问题非常突出：检索回来的片段，是以什么身份进入上下文的？是"必须引用的依据"还是"仅供参考的资料"？
我见过很多RAG应用效果不好，不是因为检索没召回，而是因为上下文里贴了一堆不相关片段之后，模型的注意力被带偏了。比如用户问"报销流程"，系统召回了5个片段，其中有2个是关于差旅标准的，模型就开始讲差旅标准，反而把核心的报销流程讲得含糊。
正确的RAG context-mode应该包含三层设定：
- query改写：把问题改写成更适合检索的形式；
- 片段筛选：控制进入上下文的片段数量和相关性阈值；
- 引用约束：在最终生成前明确告诉模型"只依据当前资料回答，不编造，资料中没有的信息要明说不知道"。
三张模式放在一起，各自的适用场景就很清楚了：
| 模式 | 核心特征 | 最适合的场景 | 最容易翻车的点 |
|---|---|---|---|
| 连续对话 | 多轮历史参与决策 | 客服、助手、多轮修改 | 早期约束被后续对话冲淡 |
| 单轮补全 | 前文即标准、续写下去 | 代码生成、批量结构化文案 | 前文错误被无脑延续 |
| 检索增强 | 外部资料作为事实依据 | 知识库问答、文档解读 | 不相关片段污染答案 |
3. 为什么切换模式后输出判若两"人"：注意力机制那点事
很多人会问：我用的都是同一个模型，API参数也没改，为什么只是换个上下文组织形式，输出质量就天差地别？这就要说到大模型底层的注意力机制了。
3.1 注意力不是均匀分配的
模型的每一步推理，都会对当前上下文里的每个token计算一个注意力权重。权重高（相关性高）的token会强烈影响下一个词的生成，权重低的token基本就是背景板。这个权重计算不是平均分的，而是模型根据"当前任务"动态决定的。
问题在于，模型判断"相关性"的依据很大程度来自文本的位置和结构。放在开头的内容很容易获得高权重，因为大模型天然把开头当作"任务框架"；放在大段资料中间的内容容易被当成"待处理材料"；放在末尾的内容会获得"最近优先"的加成。这就解释了为什么同样一段日志，你把它放在指令前面，模型就会倾向于"处理日志"；放在指令后面并标明"仅作参考"，它才会倾向于"基于日志做分析"。
我用一个日常类比来记这件事：模型就像一个灯光师，上下文是舞台上的演员，注意力是追光灯。灯光师并不知道谁是主角，他主要靠"谁站在最显眼的位置、谁的话最多"来判断该追谁。你要做的就是通过编排，告诉灯光师"那个站在角落、话不多的人才是主角"。
3.2 长尾衰减：中间那段最容易被"忽略"
还有一个更隐蔽的现象：上下文如果很长，中间部分的内容往往会被"两头挤"。开头有框架效应，末尾有近因效应，夹在中间的段落注意力权重最低。我做过一个简单的对照实验：同样一份10000字的技术说明书，如果要求模型严格执行第三章节里的某条规范，把这条规范放在上下文开头，执行准确率接近90%；把它放在中间，准确率降到60%出头；放在末尾，准确率又回升到80%左右。
这个规律在工程上很实用。当你有一份很长的参考材料、但当前步骤只需要其中一小部分时，不要偷懒把整份材料都塞进去，而是应该先取出需要的那段，再放到上下文靠前的位置。RAG系统里常说的"给最相关的段落更高的优先级"，在实现层面往往就体现在这一段该怎么排序。
3.3 模式切换的本质：改变信息优先级
理解了注意力分布，再看context-mode就清楚了：所谓切换模式，就是改变了上下文中各段信息的优先级。
- 对话模式：历史的优先级默认高于新输入（虽然可以通过system prompt干预）；
- 补全模式：前文的优先级无限高，因为它就是"标准答案"；
- 检索增强模式：检索回来的片段优先级较高，但模型并不自动知道它们是不是权威来源，需要显式声明。
加上temperature、top_p这些采样参数，其实是在调整"模型在多大程度上愿意偏离高权重信息"。我个人的习惯是：需要严格基于资料输出时，temperature调到0.2以下；需要发散、头脑风暴时，才放到0.7以上。很多新手在context-mode搭配参数上非常随意，输出了不稳定的结果，还以为是模型问题。
4. 不同任务下context-mode的选型与调参实操
前面讲了原理和分类，这一章直接给"抄作业"级别的配置方案。我按最常见的三类任务分别说。
4.1 代码生成与代码审查：优先补全模式
写代码这个场景，最大的矛盾是：你希望模型遵循现有项目的风格，又希望它别把已有的坑继承过来。我的做法分两步。
第一步，抽取项目的关键上下文：函数签名、依赖版本、代码风格片段（命名规范、错误处理方式），而不是把整个仓库塞进去。第二步，用补全模式生成新代码。比如要生成一个读取配置文件的函数，我会这样组织输入：
# 项目风格约定： # - 函数名使用蛇形命名 # - 错误处理使用 try-except 并返回默认值 # - 日志使用 logging.getLogger(__name__) # - 已有代码示例： # def load_config(): # try: # cfg = read_yaml("./config.yaml") # except FileNotFoundError: # cfg = {} # return cfg # # 现在请按照以上风格实现： # def load_config_with_cache(config_path: str) -> dict:补全模式下，模型会把前面那几行注释当成"既定风格标准"，生成结果高度一致。实测下来，这种写法比对话模式里说"请按照参考代码风格"稳定得多。代码审查场景同理：把要审查的代码放在前文，把审查标准放在代码后面靠近末尾的位置，模型既能看到代码细节，又能记住审查要点。
4.2 对话答疑与多轮修改：对话模式 + 历史裁剪
对话模式的核心是把历史管理好。我给自己定了一个简单的裁剪策略：
- 最近3轮消息完整保留；
- 3轮之前的消息抽取"约束条件"和"关键偏好"合并成一条事实摘要；
- 每轮新请求时，把该摘要在第一轮位置重发一遍，确保它位于上下文的头部。
这个策略在开发一个内部机器人时效果很明显。用户经常在对话中反复修改需求，没有裁剪策略前，模型到了第10轮基本会把第2轮说的"务必保留A功能"忘掉。加了"事实摘要前置"之后，这类问题的复发率大幅下降。
4.3 知识库问答：RAG模式 + 显式引用约束
做RAG问答，我现在的标配流程是：
- 将文档切分成固定大小的chunk。我常用的chunk size是500-800字，带100字左右的overlap，避免关键信息被切断；
- 对用户query做简单改写。比如"报销流程是啥"改写为"公司报销流程的具体步骤和所需材料"；
- 检索top-k个片段。我会把k控制在3-5个，不贪多；
- 在最终上下文里用明确的XML标签包裹每个片段，并加一句引用约束。
示例上下文组织：
<task> 请根据以下资料回答用户问题。严格依据资料内容，不要编造。如果资料中没有相关信息，请明确回答"资料中未提及"。 </task> <context> <doc id="1"> 报销流程第一步：... </doc> <doc id="2"> 差旅标准：... </doc> </context> <task> 用户问题：报销流程是什么？ </task>这里我故意把task标签在开头和结尾各放了一次。开头让模型知道接下来的context是"参考资料"，结尾再次强调当前问题，利用前面说的首因和近因效应，让模型不被中间资料带跑。这个细节是我试了很多次才摸索出来的，效果比只有一个开头指令明显更好。
4.4 各场景推荐配置表
| 任务类型 | 模式选择 | 推荐参数 | 易错点 |
|---|---|---|---|
| 代码生成 | 补全模式 | temperature=0.2，top_p=0.9 | 前文示例必须无bug |
| 代码审查 | 补全模式或对话模式 | temperature=0.1 | 审查标准要放末尾，别混在代码中间 |
| 多轮客服 | 对话模式 + 摘要裁剪 | 保留3轮完整历史 + 摘要前置 | 不裁剪，早期约束丢失 |
| 知识库问答 | 检索增强 | top_k=3~5，temperature=0.1 | 不相关片段必须过滤，别硬塞 |
| 创意写作 | 对话模式 | temperature=0.8 | 上下文里给风格示例但别给死规则 |
5. 我在context-mode上踩过的坑与排查思路
这一章我想完整复盘几个真实翻车案例，重点不是"我最后怎么改好的"，而是"我是怎么一步步定位到问题根源的"。掌握这套排查方法，比记住结论更重要。
5.1 坑一：上下文过载，模型开始复读和混乱
现象：某个QA机器人上线两周后，用户反馈它开始频繁重复之前的回答，甚至把两个不相关的问题混在一起回答。我看日志发现，对话上下文里已经积累了40多轮消息，其中还夹着几段长长的报错信息。
排查过程：我没有直接改代码，而是先在测试环境复现，把40轮历史逐步截断，从保留全部、到保留20轮、10轮、5轮。分别跑同一组问题后，发现15轮以上时开始出现轻微复读，30轮以上时混乱明显。这个对照实验直接锁定了问题是"历史过长导致注意力稀释"。
修复方案：上线了历史摘要前置策略，同时给上下文设置了硬性长度上限。跑了一周之后，复读问题基本消失。
5.2 坑二：补全模式被旧代码带偏
现象：在用补全模式给一个旧项目加新接口时，模型生成的方法体里沿用了项目里一个已被废弃的数据库连接方式。这个连接方式在我的"参考上下文"里确实存在，但它是不该被当作标准的坏例子。
排查过程：我先把参考代码里的废弃连接方式移除，重新生成，问题立刻消失。于是确认不是模型随机行为，而是上下文里的坏例被补全模式当成了"标准答案"。
教训：补全模式的上下文里，绝不能出现"你不想让它学习的负面示例"。如果你需要在补全模式里指出某些写法是错的，必须在上下文里用注释明确标注"该写法已废弃，新代码禁止使用"，否则模型分不清示例的好坏。
5.3 坑三：RAG检索不相关，答案反而变差
现象：知识库问答系统在处理"请假制度"相关问题时，偶尔会引用"绩效考核"文档里的内容，给出的答案牛头不对马嘴。查看检索链路后，发现原因是"请假"和"考勤/考核"在向量空间里距离较近，被误召回。
排查过程：我先调低了top_k值，从8个减少到4个，误召回少了一些但没根除。随后加入了相关度阈值过滤，低于阈值的片段直接丢弃。更进一步，我把最后生成的prompt里对资料来源的引用要求改严了，明确写"只能使用与问题直接相关的资料，无关资料要忽略"。三层一起改之后，整体准确率从85%左右提到了93%。
所以我给RAG项目的建议是：不要只调检索参数，还要在上下文编排层面做过滤和约束。很多团队在检索上花了大力气，却在最后一步"把召回片段拼给模型"时偷懒，丢了效果。
5.4 通用排查方法论：控制变量，逐段验证
最后分享一下现在遇到context相关问题时，我的标准排查流程：
- 固定模型和参数，只改上下文组织形式，对比输出。这一步能确认是不是context-mode的锅；
- 固定组织形式，只改各段的顺序和位置。比如把指令从前面挪到后面，把参考资料分成两组交替测试；
- 固定顺序，只改内容，逐步删减某一段，看哪一段的缺失对输出影响最大；
- 把每一次实验的配置和输出记录下来。我习惯用一个表格记录：模式、上下文顺序、参数、输出摘要、主观评分。
| 实验编号 | 模式 | 上下文顺序 | temperature | 输出质量（1-5） | 备注 |
|---|---|---|---|---|---|
| 1 | 对话 | 指令+日志 | 0.5 | 2 | 复读日志，没分析 |
| 2 | 对话 | 指令+分隔符+日志 | 0.5 | 3 | 开始有结论但浅 |
| 3 | 对话 | 指令+分隔符+日志+末尾重申任务 | 0.5 | 4 | 有根因分析 |
| 4 | 对话 | 同上 | 0.2 | 4 | 更严谨但不够发散 |
这个表不只是给自己看的，跟同事协作、跟供应商反馈问题时，它是最有说服力的依据。
说实话，做了这么多实验之后我最大的体会是：context-mode不是什么神秘的参数开关，它本质上是"你对模型工作方式的尊重程度"。模型不是全知全能的读心者，它只能依据你给它的上下文来做事。你能不能把上下文组织得清晰、有主次、有边界，决定了AI能力的上限。这个道理说起来简单，但每次踩坑时总会发现，自己又不知不觉地选择了"最省事"的偷懒方案。现在我给自己立了一个规矩：任何需要模型高质量输出的场景，上下文组织的时间绝不能省。这份投入，回报是稳定且立竿见影的。
