做AI应用做得久了你会发现一件特别有意思的事同一个模型同一个提示词模板别人跑出来的效果像定制了专属助手你跑出来的却像在跟一个记忆力只有三秒的客服对话。差别大多不在模型本身而在 context-mode——上下文模式。这里的 context-mode不是一个具体产品而是你组织、管理和利用模型能看见的信息范围的方式。它直接决定了模型在手头有多少依据、这些依据按什么顺序排列、关键信息会不会被淹没。说实话我见过太多这个模型不行的结论最后排查下来八成是上下文没用好是方案设计的问题。这篇文章我会结合自己在真实项目里的实操经验把 context-mode 涉及的窗口选型、内容组装、动态压缩、检索增强、常见坑位一次讲透。无论你是刚接触大模型应用开发还是已经在做 RAG、Agent 类的工程落地这篇文章应该都能给你一些可以直接抄作业的内容。1. context-mode 到底在控制什么1.1 大模型的桌面工作机制先讲认知。大模型本身没有记忆模型权重里面存的是训练时学到的知识但模型权重不会因为你和它聊了几句就改变。每次调用模型看到的输入就只是你的 prompt输出完之后这次会话的信息并不会自动留在模型里。想要模型记住任何事情都得通过上下文来完成。我特别喜欢用一个类比把模型当成一个特别聪明但记性极差的临时助手。你给它布置任务的时候必须把所有资料都打印出来放在桌上——客户背景、历史对话、产品说明、注意事项一样都不能少。它干活的时候只看得到桌上的这些纸桌上的纸越多、越乱它就越容易找错重点。context-mode 就是这个桌面的布置策略。所以你会明白为什么同样是那个模型有人用来做客服机器人效果好有人做出来却老是答非所问。很多时候不是模型笨而是你没有往桌上放对纸。1.2 上下文模式的三种形态我平时会把 context-mode 拆成三个维度来看避免一上来就陷进细节。第一种是上下文窗口Context Window也就是模型的桌面容量一次最多能放多少 token。这是硬指标直接决定你能不能把一段长文档完整放进去。第二种是上下文学习In-Context Learning指的是模型从上下文里的示例中提炼规律、完成任务的能力。你不用微调模型只要在 prompt 里塞两三个例子模型就能照着干这就是 ICL 的威力。第三种是我自己最看重的上下文管理Context Engineering也就是怎么去构建、排序、压缩、检索这些上下文。它属于工程实践比前两个维度更考验设计功夫也是我们大多数应用开发者真正能发力的地方。维度核心问题谁来关心典型参数/手段上下文窗口能放多少 token模型选型阶段8K / 32K / 128K上下文学习模型能否从示例学会任务prompt 设计few-shot 示例数量上下文管理如何让有用信息不被忽略系统架构检索、压缩、重排2. 上下文窗口的真相参数表上的数字别全信2.1 名义窗口和有效记忆的差距第1节讲了三种形态现在先从窗口这个硬指标说起。很多人选模型的时候只看参数表看到128K就觉得很安心。但到了实际项目里你会发现128K窗口不代表模型能有效利用128K。这里有个在业内已经被反复验证的现象当上下文很长时模型对最开头和最结尾的内容利用得最好对中间部分的内容记忆最差。我自己做一个长文档问答项目的时候把一份30万字的技术手册整体塞进去问它中间章节的一个参数它愣是答串到了另一章节而且发生得相当稳定。后来查了不少研究资料发现这个中间丢失现象不是偶发问题而是 Transformer 结构下的普遍倾向。为什么会出现这种情况往浅了说注意力机制计算的是每个 token 和其他所有 token 之间的关联权重上下文越长注意力权重被摊得越薄中段内容的信号就被周围环境稀释了。加上很多模型用的位置编码带有距离衰减特性相对较远的 token 之间相关性会被进一步削弱。所以中间内容天然就不占优势。再加上一个更现实的问题很多支持所谓长窗口的模型是通过位置编码插值比如把训练时的4096窗口外推到128K来实现的。这种外推不是没有代价位置信息相对模糊有效记忆长度会打折扣。参数表上的128K和它真正能保证质量的有效上下文完全是两个概念。2.2 长窗口不是万能的上面讲的还是记忆能力的问题接下来要说的这个坑更隐蔽即便模型真的记住了所有细节给了它太多不相关的内容它也容易被噪声带偏。我还是拿客服知识库项目举例。第一版图省事把500多页的产品手册全量塞进上下文让模型自己找答案。结果它经常把两种不同型号的参数混在一起说还会从手册的偏僻角落挖出一句过时的话当作标准答案。后来改成只从手册里检索出和用户问题最相关的3到5个片段再塞进上下文准确率直接上了一个大台阶。这说明什么长窗口是被动容量不是主动智能。你不能指望塞进去的垃圾会被模型自动滤掉。所以在方案设计上我的原则是不要为了用长窗口而用长窗口。RAG、上下文压缩这些手段本质上是在帮你往桌上放更有用的纸而不是把整间仓库都搬上桌。2.3 窗口选型的实操建议根据场景选择窗口长度我一般按下面的思路来应用场景推荐窗口选型理由日常对话、意图识别8K ~ 32K对话轮次有限历史信息少通用知识问答32K兼顾成本和上下文余量文档问答RAG32K ~ 128K检索片段 历史会话 指令留余量代码仓库分析128K一个项目可能有多个文件同时需要上下文长文档全文摘要128K需要在同一窗口内覆盖全文这里有一个细节选择窗口时不要只看够不够放资料要给输出留空间还要给对话历史留余量。比如你算出来参考资料2000 token随着对话进行历史记录还会增长那就得按照一个更宽裕的量级来选型而不是刚好卡在某个临界值。在长对话过程中上下文会动态膨胀窗口吃满之后就必须触发压缩或者裁剪处理不当会严重影响体验。3. 上下文内容组装策略比模型更决定效果3.1 把重要的信息放到开头和结尾窗口理解了接下来才是最体现功力的一块上下文内容怎么排。咱们前面说了中间丢失这个现象那策略就很明确了把最需要模型严格遵循的内容放在开头把当前要处理的目标问题放在结尾参考资料和对话历史放在中间。为什么这么放因为模型在生成的时候注意力天然更偏向开头设定角色与任务基调和结尾最近的指令信号。很多 prompt 工程师总结过一个通用布局第一层系统提示词定义角色、任务范围、输出格式、禁止事项第二层few-shot 示例让模型理解这个任务要这么干第三层参考资料检索到的文档片段或知识库内容第四层当前用户输入以及附带的相关约束拿客服机器人来举例。系统提示词里写你是某产品的客服助手只能基于提供的产品资料回答不要编造价格用户提问放在最后面中间是检索到的产品片段。这就是最基础但很稳妥的上下文布局。有个小技巧是对特别关键的限制比如如果资料里没有答案就明确说不知道可以在开头和结尾各写一遍。模型对重复出现的指令会更敏感这样能有效降低幻觉概率。我自己实测过双写关键约束比只写在系统提示词里幻觉率能低一半左右。3.2 few-shot 示例的设计要点前面提到上下文学习ICL这块实操起来有个容易犯的错示例贪多、贪全。不少人觉得例子越多越好于是把每个类别都写一个示例结果示例本身占了大量 token挤占了真正需要的参考资料空间效果还未必提升。我的经验是few-shot 示例不必多2到5个高质量示例通常就够。关键是示例要贴近真实查询分布。比如做意图分类先看看用户最常问的是哪些类型把高频类型的正反例做出来而不是平均分配十几个类型。正反例配合效果最好——一个正确的示例一个看似相近但实际是另一种意图的反例模型能更快理解边界。还有一个细节示例的格式要和最终任务一致。如果你希望模型输出 JSON那示例里就必须有 JSON 输出如果你希望模型在不确定时说不知道示例里也要出现这种输出。模型会模仿示例的格式和风格这是一个常常被忽略但影响很大的点。3.3 上下文压缩窗口快满时的保命手段长对话中上下文迟早会膨胀到窗口上限。这时候就得动刀了压缩策略我常用以下几种对话历史摘要。把早期对话压缩成一句到两句摘要只保留关键信息比如用户之前询问过某产品的退货政策已告知需要15天审核期。关键信息抽取。从历史中提取结构化标签比如用户ID、产品型号、订单状态用结构化的方式存到上下文里。滑动窗口裁剪。只保留最近 N 轮对话。对大多数对话型应用用户的当前意图和最近几轮强相关更早的内容大概率已经不影响最终回答。检索排序。在长文档场景先做一次检索只把得分最高的片段放进上下文。这里要注意一个权衡摘要压缩会丢失细节滑动窗口会丢失早期信息。什么时候用哪种我的经验是如果历史中涉及事实型信息订单号、地址、合同条款必须用关键信息抽取而不是只靠摘要——摘要一模糊后续所有回答都会跟着模糊。如果只是普通闲聊滑动窗口就够了简单高效。3.4 别忘了提示词缓存最后提一个工程上直接省钱省时间的手段提示词缓存。现在不少模型服务都支持对输入前缀做缓存重复的前缀 token 不会再走一遍完整计算延迟和成本都能明显下降。使用上有两个要点。第一把上下文里固定不变的部分系统提示词、工具定义、few-shot 示例放在最前面动态部分用户问题、检索结果放在后面。因为缓存通常按前缀匹配只有前缀一致才命中。第二尽量保持前缀内容稳定哪怕系统提示词里加一个空格前缀变了缓存就废了。我有一次在调试时给系统提示词加了一句日志说明结果整天的调用都打不中缓存成本直接翻了几倍这个教训印象很深。4. 实战一个 RAG 问答系统的 context-mode 设计4.1 场景与第一版问题前面理论说了一大堆现在看一个真实案例把上下文管理的思路串一遍。需求很简单做一个企业内部文档问答机器人知识库大概2000份技术文档用户会问某产品支持单点登录吗某接口的限流参数是什么这类问题。第一版我们图省事把所有文档全量塞进上下文让模型自己找。结果回答经常张冠李戴A产品的功能安到B产品上长文档被截断后半部分内容永远看不到单次调用耗时很长成本也很高后来改成 RAG 增强加精细化上下文组装问题基本都解决了。4.2 整体流程与上下文模板改造后的流程分离线在线两条线。离线阶段把文档按照一定策略切块我习惯按章节和语义切每块大约300到500 token然后做向量化存进向量数据库。在线阶段用户问题进来之后先用向量检索找出和问题最相关的 TopK 块然后组装上下文最后调用模型生成答案。组装上下文的伪代码大概长这样用 Python 示意def build_context(query, retrieved_chunks): system_prompt 你是一名企业内部技术文档助手请基于提供的资料准确回答用户问题。如果资料中没有相关信息请明确说明资料中未找到不要编造。 # 固定部分放前面便于命中提示词缓存 context system_prompt # 中间放检索片段 context \n\n【参考资料】\n for i, chunk in enumerate(retrieved_chunks, 1): context f[片段{i}]\n{chunk}\n # 用户问题放最后 context f\n【用户问题】\n{query}\n return context注意这里的顺序系统提示词在最前参考资料在中间用户问题在最后。这就是利用了开头结尾注意力更强的规律。系统提示词负责定基调和约束用户问题作为最后的强指令检索片段作为支持材料放在中间。4.3 参数选择与计算过程接下来是参数设计。我按下面的思路估算上下文大小假设每块文档平均长度400 token检索 TopK 取5那么参考资料大约2000 token。系统提示词约300 token用户问题平均约100 token。单轮完整上下文约2400 token选 32K 窗口完全够用还能给对话历史留出很大余量。那 TopK 为什么不取10或者更大呢一开始我也试过 TopK10结果准确率没有明显提升反而出现了一些无关片段混进来干扰模型判断。后来做了个简单实验在验证集上分别测 TopK3、5、10 的效果TopK5 性价比最高3 略信息不足10 噪声偏多。这个结果在不同知识库上可能不一样但方法是一样的先小样本测再定参不要拍脑袋。4.4 检索质量对上下文效果的放大效应这里要特别强调一点上下文组装得再好如果检索出来的片段本身不对结果照样拉胯。RAG 里检索和生成是一荣俱荣一损俱损的关系。我记得有一次线上反馈某个内网工具不会用用户问怎么导出报表检索出来的片段却是报表导入一字之差答案完全跑偏。后来在检索环节加了查询改写先让模型判断用户问题的关键实体和意图再拿改写后的查询去检索。比如怎么导出报表改写为报表导出 操作步骤命中率明显提升。这就是上下文工程里常说的好的输入才有好的输出。另外文档切块策略也直接影响检索质量。切得太碎片段缺乏上下文模型看不懂切得太大片段里混着大量无关内容检索精度下降。我一般按文档结构章节、标题来切而不是死板地按字数切这样每个片段在语义上更完整。5. 常见问题与排查技巧实录5.1 答非所问先查上下文是不是被截断了很多团队把模型回答不对归结为模型能力问题我建议先排查上下文。最常见的坑就是上下文超出窗口被服务端静默截断。截断之后用户的问题可能在最末尾被砍掉模型根本不知道用户问了什么只能根据中间残留的内容猜当然答非所问。排查方法很简单把发送给模型的输入打印出来检查最后的内容是不是完整的。如果被截断了要么缩短参考资料长度要么调整压缩策略要么换更大的窗口而不是去改提示词。5.2 指令被淹没了怎么办另一个高频问题模型突然不遵守系统提示词里的约束比如让它不要编造它还是编造。这种情况通常是因为上下文过长约束指令被其他内容稀释了。解决思路有三条。第一关键约束在开头和结尾各写一遍前面提过这个技巧实测有效。第二减少上下文里无关 token 的数量给指令腾出注意力空间。第三如果约束特别重要可以把它拆成独立判断步骤先让模型判断资料中有没有答案再让模型生成回答而不是一口气让它既要又要。5.3 上下文越长模型越笨还有一个反直觉的现象上下文越多模型反而表现得越差。这其实是信息噪声带来的干扰。很多人迷信信息越全越好实际上模型并不是一个完美的信息筛选器塞进去的无关信息越多它被带偏的概率越大。我的处理原则是最小化上下文只给模型完成任务必要的信息多一句废话都不放。这句话说起来简单做起来需要你在每次构建上下文时都问自己一句——这段内容真的需要放进去吗如果拿不准就先不放跑一遍看看效果再说。5.4 速查表整理一份排查速查表方便遇到问题时快速定位现象可能原因解决方案答非所问上下文被截断、问题在末尾被裁掉检查输入长度缩短内容或换大窗口张冠李戴检索片段不相关或 TopK 过大增加查询改写调小 TopK优化切块不遵守约束指令被长上下文稀释首尾双写关键约束减少无关 token越给资料越错噪声干扰、信息冗余最小化上下文只保留必要片段回答风格不一致示例格式与目标不一致调整 few-shot 示例确保格式统一我个人在实际操作中的体会是玩好 context-mode 最大的门槛不是理解上下文窗口这个概念而是养成一个习惯每次往 prompt 里塞内容之前都先问自己这段对模型完成任务到底是加分的还是减分的。多数时候你会惊讶地发现长长的 prompt 里有一半内容是可以删掉的。最后再分享一个小技巧准备一个覆盖常见场景的测试集日常跑着每次改动上下文结构不靠感觉判断效果而是用测试集量化对比。我在项目里就是用三十条覆盖常见场景的测试问题做回归任何上下文策略的调整都能立刻看出有没有收益。上下文这个东西看起来玄学其实你把变量控制住了它就会变得很可控。