前阵子一个深夜我盯着线上客服机器人的数据面板整个人都不太好同样的提示词、同样的模型这周的回答质量肉眼可见地往下掉。一开始我怀疑是模型侧出了问题后来把一次完整请求的全链路日志翻出来看才发现问题出在我自己的“context-mode”配置上——历史对话塞太多了模型被自己说过的废话带偏了。这个场景我想很多做AI应用开发的人都遇到过。今天想聊的“context-mode”上下文模式就是决定“哪些信息进上下文、以什么形式进、什么时候淘汰”的一整套管理方法。它不是某个单一函数或配置项而是贯穿提示词工程、记忆管理、检索策略和成本控制的一条主线。这篇文章不是教程式罗列而是我踩过不少坑之后沉淀下来的实操笔记。不管你是刚开始接大模型API还是已经在做Agent、客服、知识库这类应用里面关于模式选型、参数调优、避坑经验的内容应该都能直接用。1. 先搞懂三个底层事实再谈上下文模式我在社区里见过不少朋友一上来就问“context-mode到底选哪种好”但其实这个问题本身就问早了。上下文模式是建立在上下文窗口之上的管理策略如果你对上下文窗口的真实行为没有概念选型基本就是拍脑袋。所以这一章先把三个底层事实讲清楚。1.1 标称窗口和有效窗口之间隔着一条“记忆曲线”先看一组主流模型的上下文窗口参数模型标称上下文窗口大致单次请求成本档位GPT-4o / 4o-mini128K tokens中 / 低Claude Sonnet 系列200K tokens中高Gemini 1.5 Pro最高约2M tokens高国内部分长上下文模型普遍128K-1M不等低至中标称128K、200K听着很猛但你要明白一个反直觉的事实模型对长上下文的“记忆”不是均匀分布的。较早前的研究比如经典的“Lost in the Middle”实验已经反复证明在长上下文场景下模型对开头和结尾的内容利用率最高对中间段的注意力明显衰减。我实测下来的体感也差不多——当你把200K窗口用到80%以上时模型经常出现“记得第一页的内容、也记得最后一轮对话但忘了中间某条关键结论”的情况。这意味着标称窗口是一条物理上限而“有效窗口”取决于你的内容排布和上下文总量。物理上限之外你塞不进去物理上限之内你也不该随便塞满。所有好的context-mode配置本质上都在做同一件事让有效窗口尽量接近物理窗口。1.2 上下文模式直接决定你的token账单第二个事实很现实上下文模式的每一个选择都直接反映在账单上。当前主流API都是按token计费的输入和输出单价通常不同输入侧虽然便宜一些但只要量级一大差距就非常可观。我给大家算一笔具体的账。假设一个客服应用每天1000次会话每次会话平均输入30K tokens输出4K tokens。如果输入单价假设为3美元/1M tokens输出单价为15美元/1M tokens那么每天输入成本1000 × 30K ÷ 1M × 3美元 90美元每天输出成本1000 × 4K ÷ 1M × 15美元 60美元每月成本90 60× 30 4500美元如果你换一种更省token的上下文模式比如把平均输入从30K压到18K保留最近3轮原文 更早内容走摘要压缩那么每月输入成本会掉到 1000 × 18K ÷ 1M × 3美元 × 30 1620美元加上输出不变的话月账单从4500美元降到3420美元。同样的业务场景单靠上下文模式的调整就能省下20%到30%的预算。这还没算上“上下文精简后回答质量提升带来的隐性收益”。1.3 context-mode需要回答的三个核心问题说到底上下文模式要干的事情就三件什么信息该进上下文不是所有检索到的、历史记录里的信息都值得塞进去要有选择性。以什么形式进原文直接进、摘要压缩进、还是结构化之后进这决定了token的消耗密度。什么时候淘汰上下文是一个有限的“舞台”新内容进场意味着旧内容得退场。退场是直接删、还是归档到外部存储这三个问题组合一下就演化出了下一章要讲的四种主流模式。没有一种模式是万能的每种模式本质上都是对上面三个问题的不同取舍。2. 四种主流上下文模式原理、取舍与适用场景我见过的生产级context-mode方案抛开各种花哨的名字内核基本就四种全量注入、摘要压缩、检索增强、分层记忆。下面一个个拆开说重点讲清楚它们各自的“为什么”。2.1 全量注入最朴素的模式也是最贵的模式核心思路把需要模型参考的内容原封不动、按原始顺序全部塞进上下文窗口。系统提示词在前历史对话按时间排参考资料按逻辑排完事。生活类比就像把整个图书馆的书全搬进考场允许你随便翻。问题是你得在有限时间里找到答案书多了反而抓瞎。适用场景单次任务、一次性分析、上下文总量远小于窗口上限的场景。比如丢给模型一份30页的PDF让你总结或者一次性分析一段完整的代码文件这种“用完即走”的场合全量注入是最简单也最可靠的选择。我自己的经验是当单次上下文总量不足窗口上限的40%时全量注入通常是性价比最高的因为省掉了所有加工环节的技术复杂度和出错风险。主要缺点第一贵每次请求都在搬运全量数据第二当内容超过窗口一半以上时中间内容容易被“注意力稀释”模型会开始抓不住重点第三如果资料里有矛盾信息比如新旧两版文档混在一起模型容易无所适从。2.2 摘要压缩用“划重点”的方式来省token核心思路在上下文累积到一定程度后不是简单裁剪旧内容而是让模型或单独的摘要模型把旧内容压成一段摘要再把摘要放回上下文里新内容继续完整保留。生活类比就像班上学委的笔记。重点和结论都在但具体推导过程、某句话的语气细节基本丢了。实现要点结论摘要模式的实现最简单的是用LangChain里的ConversationSummaryBufferMemory这类组件。核心参数是max_token_limit当会话token超过阈值时最早的内容会被改写为摘要。核心代码如下from langchain.memory import ConversationSummaryBufferMemory memory ConversationSummaryBufferMemory( llmsummary_llm, max_token_limit12000, return_messagesTrue, )这里的max_token_limit我建议设置成模型窗口的60%左右别等窗口满到85%再触发压缩。因为摘要生成本身要消耗输出token如果上下文已经快满了生成摘要时很容易把窗口挤爆API直接报错或触发自动截断。主要缺点摘要一定会丢细节。你永远不知道下一次用户提问会不会正好命中被压掉的那条细节。所以压缩策略不能粗暴地“一压了之”关键字段、错误日志、用户明确提到的约束条件最好在压缩模板里要求模型保留。这个我在第四章会讲一个真实翻车案例。2.3 检索增强不追求全知只追求精准核心思路上下文里只放“与当前问题最相关的片段”。先通过向量检索或关键词检索从外部知识库里召回几段相关内容再组装进上下文。这就是大家熟悉的RAGRetrieval-Augmented Generation。生活类比带着目录索引和几本精选参考书进考场不背整个图书馆。你需要练的是“判断该翻哪本书”的能力。实现要点这一步的工程质量直接决定最终效果核心三件套是embedding模型、切块策略和召回数量。这块参数细节我下个章节专门讲这里先给一个组装上下文的参考代码docs vectorstore.similarity_search(query, k4) sorted_docs sort_by_time_ranking(docs) # 按时间新鲜度二次排序 context \n\n.join(doc.page_content for doc in sorted_docs) prompt f基于以下资料回答问题\n\n{context}\n\n问题{query}主要缺点检索质量决定了系统的天花板。如果检索召回的内容本身就不准、过时或互相矛盾模型再聪明也无济于事。所以检索增强模式不是“搭完向量库就行”而是需要持续评估召回质量和时效冲突。我这几年做下来最大的感受是RAG系统里检索环节花的时间和工程复杂度至少占整个项目的六成。2.4 分层记忆给上下文装上“快慢存储”核心思路参考人的记忆系统把上下文分成快速层和慢速层。最近几轮交互原文放“工作记忆”稍早的对话放滚动摘要更早但重要的信息用户偏好、长期目标、事实性知识放外部向量存储需要时再检索回来。生活类比人的大脑就是这样运作的——记得住今早同事说了什么也记得住去年项目的大方向但中间那些不重要的日常细节早就被遗忘了。实现要点分层记忆是目前做Agent和长期陪伴式应用的主流方案。它本质上不是一种新技术而是把全量注入、摘要压缩、检索增强按层次组合起来短期不压缩保证交互质量中期走压缩控制token长期走检索保留关键事实。每一层之间有清晰的“转移触发器”比如超过N轮或超过M tokens就向后一层迁移。主要缺点架构复杂度最高每一层的调度逻辑都需要精心调。需要为“什么内容值得长期记忆”定义评分规则——这个规则定不好会出现该记住的忘了、该忘的死死记住的尴尬局面。2.5 四种模式对比与选择框架模式核心思路优点主要缺点典型场景全量注入原始内容直接塞入简单、无损贵、注意力被稀释单次文档分析、短对话摘要压缩旧内容转摘要省token、保留主线丢失细节多轮客服、Agent历史管理检索增强只召回相关片段精准、可扩展检索质量决定上限知识库问答、企业文档分层记忆多级存储组合兼顾质量与成本架构复杂Agent、陪伴式应用选型逻辑我放在第五章展开这里先给一句总结上下文总量小选全量总量大且相关性分散选检索时序性强选压缩既要时序又要长期记忆选分层。3. 把上下文模式调到最佳状态四个关键参数与经验值这一章是纯实操内容。无论你选了哪种模式下面这四个参数都是躲不开的调优点。这些经验值是我在多个项目中反复试出来的不一定放之四海而皆准但至少能让你少走很多弯路。3.1 窗口占用率给输出留出“呼吸空间”第一个参数是窗口占用率也就是“输入 token 数 ÷ 模型最大窗口”。我的红线是85%。为什么不能塞满两个原因一个是模型输出也要占token如果输入已经把窗口占满输出就会被截断回答写到一半戛然而止另一个是前文提到过的注意力稀释问题窗口越接近满中间部分的遗忘就越严重。实际操作中我会在请求前做一次token估算用tiktoken这类库直接数一遍输入tokenimport tiktoken enc tiktoken.encoding_for_model(gpt-4o) input_tokens len(enc.encode(prompt_text)) max_window 128_000 output_budget 4_000 # 给输出预留 if input_tokens output_budget max_window * 0.85: trigger_summary_or_retrieval(input_tokens)这个预检逻辑可以放在请求层一旦超限就触发压缩或检索逻辑而不是靠API的硬性截断来兜底。兜底意味着你已经失去了对上下文的控制权。3.2 系统提示词不要用2000 token去解释一个100 token能说清的事第二个容易忽略的地方是系统提示词的长度。不少团队为了让模型“更听话”把系统提示词越写越长动不动就上千token动辄把角色设定、回复格式、禁止事项、词典定义全塞进去。这里有个问题系统提示词是每轮请求都要计费的而且它占据了上下文窗口中的固定区域。上下文窗口是一个零和博弈系统提示词写得太长留给真正业务内容的token就少了。我的经验建议系统提示词控制在窗口的10%-15%以内。比如128K窗口系统提示词最多留15K左右的预算一般项目其实控制在2K-4K就够用。判断标准很简单如果删掉某段提示词模型的行为没有发生变化那这段提示词就是噪音。另外有个小技巧把静态的规则角色、语气、输出格式和动态的规则本次任务、当前输入、临时指令分开。动态规则放在用户消息前部让模型更容易注意到本次任务的特殊性。3.3 多轮对话裁剪基线最近3到5轮完整保留更早进摘要做多轮对话类场景时上下文里历史消息的裁剪策略可以直接抄我的方案保留最近3到5轮完整原文这部分的交互最接近当下意图细节不能丢。更早的对话进摘要不管中间隔了多少轮只要总token超限超过3到5轮的部分就触发压缩。摘要放到历史消息的最前面作为“背景故事”压缩后的摘要排在原文前面模型先读背景再读近期对话语义连贯性最好。这里“3到5轮”是经验值。To B场景里用户说话比较正式3轮就够To C场景用户经常跑题、反复修改需求建议保留到5轮。你可以做一个简单的A/B实验同一批线上问题分别配置3轮、5轮、8轮保留观察回答质量和token消耗的平衡点在哪里。3.4 检索式上下文的硬参数chunk size、overlap和top-k怎么定如果你用的是检索增强模式下面三个参数是躲不开的chunk size切块大小建议256到512 token。切太大一块里面混合了多个主题检索精度下降切太小语义不完整模型理解困难。256到512是一个兼顾语义完整和检索精度的经验区间。overlap重叠量建议10%到20%。不重叠语义边界处的关键信息容易在切块时被拦腰斩断重叠太多浪费存储和token。top-k召回数量建议3到5个片段。召回过少答案可能缺上下文召回过多噪音增加而且token成本线性上涨。在调参时我习惯先用一个包含50个真实用户问题的评测集跑一遍统计“答案是否被采纳”。评测集跑分比单点调试要靠谱得多因为单点调参很容易被一两个案例带偏。4. 实战复盘三个上下文模式事故的完整排查链路理论讲再多不如看几个真实翻车现场。这三个案例都是我生产环境里实际发生过的问题完整还原当时的现象和排查思路你可以拿着这套方法去复现和验证。4.1 事故一模型“一本正经”地引用了不存在的API现象线上代码辅助应用用户问“如何在项目里调用支付接口”模型给出了一个看着非常合理、但实际上并不存在于项目代码库里的API方法名。用户照着写完编译直接报错。排查过程一开始怀疑模型本身的问题把同样的提示词拿到无上下文环境里测模型回答正确。说明问题出在上下文而不是模型参数。dump出请求日志发现进入上下文的项目文档里同时包含了v1版本和v2版本的接口文档v1已经废弃但没删除。模型在上下文中看到两个版本的调用方式没有足够的信号判断哪个是当前有效版本于是把两套信息“缝合”成了一个不存在的API。根因上下文里存在矛盾信息且没有给模型提供时效判断的信号。全量注入模式下尤其容易出现这个问题。修复方案把参考资料按时效分层处理。当前版本直接放正文历史版本放“参考副档”区域并显式标注“以下为已废弃版本仅供阅读”。同时在检索时优先按时间戳排序把新版本排在前面。4.2 事故二摘要压缩把关键的异常堆栈“压”掉了现象一个Agent应用在执行一个多步骤数据处理任务时频繁失败。日志显示中间某一步抛了一个异常但模型的下一步行动完全没理会这个异常继续往下走最终输出了一个错误结果。排查过程先看最终输出发现模型提到了“步骤二的异常情况”说明它知道有异常但不知道异常的具体内容。追踪上下文发现那轮出错时的完整日志已经被滚动摘要压缩成了一句话“步骤2运行时发生错误。”堆栈详情、错误码、出错字段名全都在摘要里被丢掉了。模型只知道“有错”不知道“错在哪”所以只能瞎猜下一步。根因摘要策略一刀切没有对“敏感信息”做保护。错误日志、关键字段、用户硬性约束都属于压缩后不能丢的信息。修复方案给压缩模块加一个白名单机制。摘要模板里强制要求保留错误码、异常类型、关键字段名这三类信息逻辑上遇到日志型内容直接跳过摘要压缩走“原文保留”或“只截断时间戳、保留正文”的策略。修复后同一场景的准确率从67%提到了92%。4.3 事故三RAG检索出了“看起来很对”的过期文档现象企业知识库问答场景用户问“我们的退款政策是什么”模型回答的是三个月前的老政策。新政策已经上线但向量库里新旧版本并存检索结果把老版本排在了前面。排查过程查看检索返回的chunk内容发现老版本文档和问题的向量相似度非常高排在第1位。新版本文档排在第3位但当时top-k设的是2所以新版本压根没进上下文。模型基于上下文回答自然就给出了过期政策。根因检索只看了语义相似度没有看时效。这是RAG系统里一个非常典型且隐蔽的坑——语义相似度只解决“像不像”不解决“对不对、新不新”。修复方案把时间戳纳入排序权重。检索结果先按语义得分召回再用“发布时间新鲜度”做二次加权排序。如果有metadata字段顺手在上下文里把版本时间和版本号也显示出来给模型一个直接的时效信号。4.4 快速定位“是不是上下文问题”的排查清单遇到AI质量问题时我建议按下面这个顺序排查能省很多时间把同样的提示词和问题在“无上下文”或“最小上下文”环境下测一遍。如果模型回答正常问题基本出在上下文。dump实际进入模型的token序列人工看一下上下文里到底放了什么。这一步能发现80%的问题矛盾信息、垃圾内容、过期文档、重复片段。做A/B测试同一批问题分别用“全量注入”“摘要压缩”“检索增强”三套策略跑一遍对比准确率。看成本曲线如果某天token消耗突然飙升往往意味着上下文里进了大量无效内容。排查工具方面我常用LangSmith或Langfuse这类可观测性平台来追踪每次请求进入模型的完整上下文。注意这类工具本身也会消耗一定的存储和token但在排查阶段的价值远超成本。5. 场景化的模式选型建议与成本测算最后把选型逻辑和成本账放到一起。这一章适合你准备动手搭建新系统时直接照抄。5.1 按场景选模式的决策逻辑我总结了一个简单的四问决策法基本能覆盖绝大多数应用场景上下文总量是多少如果单次任务的全部相关数据小于窗口的40%无脑选全量注入省事且可靠。信息时效性重要吗重要的话无论如何都要在上下文里带上时间戳或版本号并且在检索排序时考虑新鲜度。内容总量远超窗口且查询是“按需获取”的选检索增强。典型场景知识库、企业文档、商品FAQ。你是做Agent或长期对话吗选分层记忆。短期原文、中期摘要、长期向量检索三层各司其职。如果你同时满足“总量大”和“时序性强”比如客服系统那就把摘要压缩和检索增强结合用最近对话走压缩保持主线历史事实性信息走检索按需召回。5.2 三类典型应用的推荐配置应用类型推荐模式关键配置客服机器人分层记忆 摘要压缩保留最近5轮原文更早滚动摘要摘要模板强制保留用户ID、订单号、退款诉求等关键字段企业知识库问答检索增强chunk 512、overlap 20%、top-k 4metadata带文档版本号和发布时间代码仓库分析全量注入 结构化分段按文件维度组织上下文当前文件在前相关依赖文件在后标注版本状态5.3 成本测算实战三种方案月账单对比最后回到最现实的问题这三种方案到底差多少钱。假设一个知识库问答应用每天1000次查询每次查询需要参考约30K token的知识库内容模型输出平均2K token。方案单次输入token单次输入成本月输入成本月总成本含输出全量注入30K0.09美元2700美元约3600美元摘要压缩18K0.054美元1620美元约2520美元检索增强6K0.018美元540美元约1440美元这套账一目了然同样业务逻辑检索增强模式下个月成本可以低到全量注入的四成不到。当然检索增强方案需要额外的向量化和检索服务成本但这部分通常比API调用费用便宜一个数量级整体依然划算。这也印证了我一直以来的观点context-mode不只是技术选型问题它同时是一个成本工程问题。在模型能力接近的今天谁把上下文管理得更精准谁的成本结构就更健康谁的上限就更高。别等预算超了再来优化从架构第一天就重视上下文模式后面会省下非常多的麻烦。写到最后再分享一个我个人的习惯无论用哪种模式我都会在每次请求结束后把实际进模型的token序列dump出来瞟一眼——就一眼。这么干三个月你对“什么上下文值得放、什么纯属凑数”会形成一种非常敏锐的直觉这种东西是任何教程都给不了你的。