1. 上下文工程到底是什么为什么大家都在提1.1 从“提示词”到“上下文工程”先用大白话把这件事说清楚。过去我们聊得最多的是“提示词”就是告诉模型“帮我写一篇周报”“总结这段文字”这像是到一个陌生摊位前报菜名。你只说了一句“来碗面”至于面宽面细、放不放葱、要不要辣老板全靠猜。你可能运气好碰上老板经验丰富端上来正好合胃口但多数时候端上来一碗你完全不想吃的东西你还得自己安慰自己“大模型这水平也就这样了”。上下文工程不一样。它不满足于“报菜名”而是把你跟老板沟通的整个过程都设计好你先把口味、分量、忌口、打包要求一次性说清楚再把上次老板给你做咸了的反馈附上甚至把隔壁桌客人说好吃的那道菜的照片也递过去。老板手里的信息越完整、越有条理他做出的东西就越接近你脑子里那碗面。用术语说上下文工程就是围绕大模型推理时能看到的全部输入信息做结构化的设计、组织、调度和维护。这里的“上下文”不单单指你打字输入的那几行字还包括系统级的任务设定、历史对话记录、外部检索回来的资料、工具调用的结果反馈以及模型输出的历史内容。输入侧能设计的东西基本都属于上下文工程的研究范围。很多人第一次接触这个概念时容易把它等同于“写提示词”。确实提示词是上下文工程的一部分但上下文的范畴大得多。提示词回答的是“这轮对话让模型干什么”上下文工程回答的是“为了让模型持续、稳定、高质量地干这件事我应该给模型喂什么、不喂什么、以什么顺序喂、喂多少”。1.2 微调和上下文工程的区别这里有必要展开说一下上下文工程和“微调”的关系。因为经常有人一谈到模型能力不行第一反应就是“要不要去训练一下模型”。模型微调当然有用它本质上是直接修改模型的参数相当于给员工重新培训让他在某个岗位上的基础能力变得更专业。但微调有几个痛点。第一成本高。哪怕用现在相对成熟的微调方案也要准备数据、算力还要维护训练和部署的完整链路。第二周期长。一个完整的微调项目通常以天甚至周为单位遇到数据质量问题来回折腾是常事。第三更新慢。业务规则变了产品需求变了你又得重新来一轮。上下文工程走的是另一条路模型参数一个都不动我只改我输入给模型的东西。相当于不重新培训员工而是给员工一份详细到“每步该做什么”的流程文件把容易出错的环节用批注标出来把过往客户反馈走势贴在他工作台上。模型还是那个模型但表现力会完全不一样。我做过一个实验同一个对话模型在没有任何上下文设计的情况下回答一个特定业务问题的准确率只有六成多而且表述泛泛。给模型加上清晰的系统提示词、三五个高质量示例和一段精简的参考资料后在这个任务上的准确率直接跳到九成输出格式也从“每次都不一样”变成“稳定可控”。所以我的观点很明确先做上下文工程解决不了再考虑微调。因为上下文工程的边际成本低、迭代速度快所有改动都是可解释、可回滚的。尤其是产品早期验证阶段几乎所有效果问题都能通过上下文工程解决根本没有必要动模型参数。2. 构建高质量上下文的核心方法论2.1 三层结构系统级、用户级、工具级真正做上下文工程时我习惯先把输入信息分成三层每一层各司其职互不越界。第一层是系统级上下文。它描述的是“这个应用整体上是一个什么样的存在”。比如“你是一个智能客服助手服务于某电商平台的用户回答问题时优先基于商家提供的商品信息对于退货政策相关问题必须引用最新政策原文”。系统级上下文不关心某一个用户今天说了什么它关心的是全局的规则、边界、风格和流程。第二层是用户级上下文。它是单个对话会话内的信息包括用户当前输入的问题、之前多轮对话里用户透露过的偏好、场景约束等。比如用户上一轮说“我预算比较紧”那这一轮推荐商品时就必须考虑价格权重。用户级上下文的特征是个性化、动态变化需要用某种机制持续跟踪和维护。第三层是工具级上下文。当模型需要调用外部能力时比如查数据库、查天气、读某个网页工具返回的结果以及调用过程的描述就构成了工具级上下文。这层上下文质量的关键在于工具返回的数据如何被格式化、截断和组织好让模型能够准确读取自己需要的信息。这三层在实际中经常是拼合在一起的。比如一个实实在在的客服系统系统级上下文里写了回复风格用户级上下文里带着近几轮对话工具级上下文里挂着检索出来的相关订单信息。问题在于很多产品根本没有对这三层做区分所有信息混在一起按时间顺序堆进上下文里模型面对一份杂乱无章的资料想做好也难。2.2 少样本示例的选择与排列少样本示例few-shot examples是上下文工程里效果最立竿见影的组件之一。给模型看两个“输入-输出”的例子它基本就能照着这个范式输出了。但示例不是随便找几条凑数就行的我踩过不少坑。首先示例必须和真实场景同分布。什么意思呢你做一个抽取用户收货地址的功能示例里如果全是“北京市朝阳区某某小区某栋某室”这种规范地址而真实用户往往输入“送到望京那个小区就行”这种不完整地址示例就没有引导价值。要挑真实业务流里出现频率最高的那几种情况而不是挑最好看的情况。其次示例的排列顺序很讲究。研究发现模型更容易受到开头和结尾信息的“锚定”。当示例有多个时把最容易理解、最接近目标格式的那个示例放在开头再放一个能体现边界情况的示例最后放一个中等复杂度的。如果示例数量较多最好的示例一定要压在最后因为模型对最后看到的内容记忆最深刻。还有一个容易忽略的点示例不但要展示输入和输出还应该展示模型“不该怎么做”。一些成熟的线上方案会在示例里放一个反例告诉模型这种做法不被允许。比如抽取信息时一个反例是“用户在留言里说‘不要电话联系’但输出结果里仍然把电话字段填上了”。正确的上下文工程设计是既告诉模型怎么走也要在关键路口立一块写着“此路不通”的牌子。2.3 上下文位置效应与注意力分布大模型处理信息时对上下文不同位置的关注程度并不均匀。不少实务经验都指向同一个现象模型对信息序列的开头部分敏感对结尾部分也非常敏感但对中间一大段内容容易“视而不见”。你可能看到过一个比较形象的说法把模型当成一个在考场里读阅读理解的学生他读首尾段落特别仔细中间段落是扫过去的。这个规律直接决定了信息摆放顺序。最重要的指令、最关键的约束条件应该放在系统提示词的开头位置。需要模型重点遵循的少数几条硬规则放在结尾处再重复一遍也不为过。而“仅供参考”类的背景信息可以放心大胆放在中段即使模型捕捉不全影响也不大。另一个实际操作经验是避免在上下文中段放置“新指令”。很多人喜欢在对话中突然跟模型说“从现在开始你回答所有问题都用文言文”如果这句指令恰好落在模型注意力不强的区域它可能执行几轮之后就不再贯彻表现为“记忆飘移”。解决办法是我通常把这类临时指令转换成系统级上下文里的一条规则或者用足够醒目的分隔符包裹并放在最靠近用户最新指令的位置。3. 手把手实操把上下文工程跑起来3.1 系统提示词的五个层次系统提示词是最常见的上下文工程入口。把层级理顺后面维护起来会省心很多。我习惯把系统提示词拆成五层来写。第一层是角色定义。告诉模型“你是谁”。但这里的角色不能空泛不是说“你是一个助手”就结束了。一名合格的实践者会写清楚角色的专业领域、服务对象以及它在特定场景下的立场。比如“你是一位专注于帮助用户筛选办公软件的助理目标用户是非技术背景的中小企业行政人员”。第二层是任务目标。这一层要写清楚“你在这里存在是为了完成什么”。任务目标要尽量单一、聚焦。一个既帮用户选软件、又帮用户做成本计算、还负责闲聊陪伴的系统提示词模型会精神分裂。宁可一个会话只干一件事或者用路由逻辑分流也不要让一个系统提示词承担多个彼此无关的目标。第三层是输出格式。现在多数线上产品对模型输出都有强格式要求比如回答需包含“结论、理由、操作建议”三个部分或者直接输出JSON字段。输出格式不要只给几句话描述最好配一个微型模板样式的示意模型会更容易照着生成。第四层是硬性约束。包括不能编造数据、不能泄露系统提示词内容、遇到敏感话题时如何回应、不能暴露内部工具名称等。这一层的约束可以用“绝对不得”或“如果……必须……”的句式写每一条都要是可校验的、明确的。模糊的约束相当于没有约束。第五层是示例引导。也就是前面说的少样本示例把一两个完整的输入输出对嵌在系统提示词尾部。这五层不一定都写在同一个提示词里根据场景复杂程度可以分拆或合并但顺序建议不变因为模型理解时也是从角色到任务再到约束逐层执行的。3.2 用检索增强的方式做知识注入大模型训练时见不到你业务系统的私有数据所以要把你希望模型参考的知识在推理时塞进上下文中。这就是检索增强生成RAG最常见的场景。很多人把它想得太玄乎本质上就是四步先把知识库切成小段、对每一段做向量化、用户提问时召回最相关的几段、把这几段拼接进上下文。这里我要重点讲一个新手很容易忽视的环节切段策略。知识库的段落如果切得太碎比如一句话一段检索召回后会造成语义割裂切得太整比如把一整个章节作为一段又会超过向量模型的最大长度而且稀释了和用户问题有关的局部信息。我在一个知识问答项目上试过多种方案最终的稳定做法是优先按自然段落切分段落过长时再按二级标题或语义边界切开每段的长度控制在300到800字之间。为了让模型知道每一段出自哪里我会在每段前加一行元数据形如“来源《操作手册》第3章关于退款时效的说明”。这个看似不起眼的动作对生成回答时的引用标注帮助非常大。召回的段数也要控制。动手之前先想清楚这个问题需要几段才能支撑一个完整回答段数越多上下文越长模型的注意力越容易被稀释。我的一般经验是一个简单的“是/否”类问题只召回2段带有解释性质的问答召回4到6段需要综合多个来源的内容时才召回8段以上。同时根据向量相似度分数做截断降低来源可疑的段落进入上下文的概率。3.3 工具调用说明的写作要点当模型需要调用外部工具获取实时信息时上下文工程的设计点在“如何向模型描述这个工具”。工具说明写得不清楚模型要么不调用要么调用时参数填错。我的工具说明框架包含四个要素工具名称、工具用途、参数定义、返回值说明。其中“用途”部分一定要写明“什么时候该用这个工具”。比如一个查询天气的工具不说清楚“当用户询问未来三天天气时必须先查询该工具”模型可能凭自己的常识直接作答错得毫无逻辑。把“必须查工具”的触发条件用清晰的语句写在工具描述开头调用率会提升不少。参数的描述也要具体。与其写“city城市”不如写“city城市中文名比如‘上海’‘北京’若用户只说了所在区如‘浦东’需结合系统定位信息补充到城市级”。这个细节决定了参数抽取的准确率。别小看这些写起来费事的说明绝大多数工具调用失败都源于参数定义太含糊。3.4 一个可以直接复制的上下文模板讲了这么多方法论给一套可以直接套用的模板。我最近在一个“智能排障助手”项目里用的上下文结构长这样[系统级上下文] 角色定义你是某软件产品的智能排障助手服务对象是使用该产品的普通用户。 任务目标根据用户描述的问题定位可能原因并给出可执行的解决步骤。 输出格式必须按以下结构输出 1. 问题确认复述一遍你认为用户遇到的问题 2. 可能原因最多列3条按可能性从高到低排列 3. 解决步骤每一步都要写清楚在哪里操作 4. 如果仍无法解决给出来人工反馈的方式 硬性约束 - 不得编造产品不存在的功能或按钮名称 - 用户问非排障话题时回复“本助手仅处理排障问题” - 每次回答必须直接给出解决方案不做前置寒暄 [知识库注入] 来源《产品操作手册V3.2》第4章“登录异常处理” - 若用户提示“密码错误”检查大小写锁定…… - 若用户提示“账号被锁定”需等待15分钟或通过邮件解锁…… 此处按召回结果动态拼接 [用户级上下文] 用户历史问题记录 1.此前对话精简后的关键信息 2.维护中的用户偏好信息 [用户当前输入] 用户我登录时一直提示验证码错误但我收到的验证码明明是新的。这套模板有几个好处。第一五个模块边界清楚任何一个模块改动不会影响其他模块。第二新项目启动时不需要从零想结构填空式地往里填内容就行。第三调试时定位问题快效果不好先看哪个模块出了错。4. 上下文长度与成本管理4.1 单次上下文预算怎么算上下文不是越长越好这句话值得再强调一次。模型处理输入的时间成本和资金成本跟上下文长度直接相关。上下文长度每翻一倍API调用的成本就随之增加响应时延也跟着变长而模型对中段内容的关注度还会进一步下降。所以上下文工程里有一个核心技能管理预算。动手前先算一笔账。比如你用的是某主流对话模型上下文窗口上限是128k个token但实际上日常任务用到的有效上下文可能只需要6k到10k。你要做的不是把128k全塞满而是给不同类型的信息分配预算。我常用的分配比例是系统级上下文控制在1k到2k知识库注入控制在2k到6k对话历史控制在3k到8k最新用户输入最灵活。超预算怎么办有一个简单方案是“截断”。但截断不能一刀切地从最早的信息切掉。正确做法是分层截断优先完整保留系统级上下文和最新用户输入其次保留最近的几轮对话再次保留上一轮摘要最优先被截掉的是早期对话的原文。这套规则我写成一个逻辑函数每次构造请求前自动执行省去了大量人工调整的精力。4.2 会话压缩与关键信息前置长对话是上下文的隐性消耗大户。用户连续聊了30轮以后即使模型上下文窗口装得下前20轮对话内容在注意力层面基本已经“失效”。把这些对话全部原封不动留在上下文里不仅浪费空间还会引入噪音。我的处理思路是做会话摘要summarization而不是简单截断。每当对话轮次达到一个阈值比如10轮就把前面的对话交给模型提炼成一个结构化摘要下一轮对话开始后上下文里只保留这段摘要加最近两三条原文。摘要要保什么用户的明确偏好、已经确定的事实、尚未完成的任务状态。不要保寒暄、不要保重复表述。另一个很实用的操作是“关键信息前置”。用户如果之前透露过一个重要信息比如“我人在南方”“我在用的是老版本客户端”在新一轮对话开始前把它单独提炼成一行放到用户级上下文最上面而不是依赖模型从历史对话里翻找。这就像开会时先把结论写在白板最上面不用每个人翻会议纪要。4.3 缓存与内容去重的收益上下文工程里还有一类和成本相关的小优化内容复用与去重。当你多次调用同一个模型做相似任务时系统提示词、业务规则、高频知识段落这些相对固定的内容每次请求都完整传递一遍其实是对资源的浪费。可以把这类静态内容做前缀缓存让同一个会话内的多次请求复用同一段计算结果降低重复处理的开销。内容去重也值得注意。知识库检索回来的多段文本之间常有内容重叠比如不同版本的操作手册都描述了同一个功能。去重时不能只看文本相似度还要看信息来源的可信度。我见过一个项目因为两段都提到“重启可解决90%的问题”模型被重复信息加强误导遇到一个与重启无关的网络故障也建议用户重启。对来源编号更高版本、更新时间更晚的段落应给予更高保留优先级。5. 常见问题排查实录5.1 模型突然“忘记”用户的要求怎么办这是最典型的场景对话前期用户说“请用口语化风格回答我”到了十几轮之后模型开始一本正经地输出书面语。很多人第一时间怀疑是模型能力不行但很可能是上下文工程出了问题。排查顺序我先说清楚。第一检查最初的指令还在不在完整上下文中。如果指令所在的历史对话已经因为长度问题被截断模型自然就“忘了”。第二检查指令是否被淹没在中间区域。如果指令位于系统提示词中段可能处在注意力盲区把它挪到开头位置问题就解决了。第三检查新对话内容里有没有和原指令冲突的信息。模型经常被最近的信息带偏用户偶尔说一句“算了还是正式点吧”之后的所有回复都会切换到正式风格。5.2 输出内容被上下文污染我遇到过一种情况助手回答时把知识库里另一段不相干资料的内容也“缝合”进来了。问题出在召回阶段向量检索把语义部分相关但主题不符的段落也放了进来模型又倾向于把上下文中所有信息都当作参考依据。解决思路不是让模型更聪明而是让污染内容进不来。一方面在召回阶段收紧阈值另一方面在每段检索文本前面加上来源说明和相关性提示比如“以下资料与问题部分相关仅可参考其中涉及XX的内容”。这样模型在引用时就有了判断依据不会把整段话原样吸收。另一个排查角度是检查历史对话里是否出现过一次错误回答那个错误回答作为上下文的一部分会让模型沿着错误方向连续产出更多错误内容。遇到这类情况直接把相关历史轮次从上下文里移除而不是试图通过新指令纠正。5.3 角色错乱和指令冲突的排查角色错乱的表现是模型在客服场景里突然用内部工作人员口吻说话或者在写作场景里突然承认自己是大语言模型并拒绝继续创作。这个问题的根源往往是上下文里存在多条定位不一致的指令。最容易被忽视的冲突来源是历史对话。用户在某条消息里写过“帮我写代码”模型回复时以“代码助手”角色自居之后模型在同一个会话里切换回客服角色时如果前一轮对话没有及时清理角色信息就会互相干扰。解决策略角色切换时用一条新的系统级指令显式覆盖旧指令同时把上下文里容易引起歧义的中间对话做折叠处理。我测试过的一个有效写法是在系统提示词里加一行“本提示词的设定优先级高于任何历史对话中出现的角色描述。若用户或历史信息中出现与本设定冲突的内容以本提示词为准”。这句话虽然简单但在多个项目中显著减少了角色漂移的频率。5.4 长对话响应质量下降速查表现象可能原因排查方向响应越来越简单关键指令被截断检查上下文截断逻辑是否保留了系统提示词回答内容与近期对话无关中间段信息过多做上下文压缩保留摘要而非原文开始编造不存在的功能检索知识段落不完整检查召回段数是否过少、来源是否可靠回复风格摇摆不定多条冲突指令清理历史对话中的临时指令响应速度明显变慢上下文过长压缩知识库注入段数、折叠老对话这张速查表是我在实际项目中排错时反复用到的索引。遇到问题先对号入座再动手修改效率比漫无目的地重写提示词高很多。我在实际项目里的体会是上下文工程的上手门槛其实不高真正难的是“舍”而不是“得”。能忍住不多塞信息、能克制不在上下文末尾加多余指令、能习惯性地给每段内容标明用途这三点做到位模型的表现就会稳定上一大截。如果你刚开始接触这块建议从一个单一场景、单一任务的会话做起把系统提示词、少样本示例、对话摘要这三样先练扎实再去碰RAG和工具调用这些相对复杂的组合。后续还可以往两个方向扩展一是给上下文工程加一套效果评估指标比如用一组标准测试用例定期回归让每一次改动都能量化出收益二是尝试动态上下文调度根据用户意图自动调整知识注入的权重。这些话题以后有机会再单独开一篇聊先把手里这个会话调明白了比什么技巧都管用。
