一次线上事故让我盯上了上下文工程。当时某个智能客服系统上线没两周用户问“订单超过七天能不能退”模型回答“根据规则可以办理”但实际上运费险条款里明确写着“签收七天后不予受理”。客服主管把对话记录甩过来的时候我第一反应是模型又犯病了——没错大模型幻觉一本正经地胡说八道。后来我在项目里陆续试了提示词加固、检索增强、输出约束、推理引导等一批手段才慢慢摸清一件事幻觉不能靠“换个更强的大模型”根除真正可控的办法是把你给模型的上下文设计好。说得直接一点大模型的输出质量很大程度不取决于模型本身而取决于你喂给它的上下文有多“干净”、多“有结构”、多“能约束它”。这就是上下文工程Context Engineering。这篇文章就把我实际项目里用得最多、见效最快的6大核心技术整理出来从原理到写法、从参数选择到踩坑记录都讲清楚。适合正在调大模型API的开发者、做AI应用落地的产品技术团队以及所有被“AI乱编”折磨过的人。内容全部来自实战验证照着抄能直接用。1. 先搞清楚幻觉是怎么来的才能知道上下文工程该往哪儿使劲1.1 模型的“自信”来自概率不是来自事实大模型的本质是一个超大的概率模型它生成每一个词的时候都在计算“在已有上下文的情况下下一个词最可能是什么”。所以当你问它一个它没记住的知识点它并不会像搜索引擎那样返回“没有结果”而是会根据训练时见过的相似文本模式现场编一段看起来很像样的内容。这个机制决定了幻觉的三个根源知识截止模型的训练数据有截止日期之后发生的事它根本不知道。知识稀疏某些低频知识在训练集里出现次数太少模型没有真正记住只有模糊印象。迎合倾向模型被对齐训练得过猛倾向于“用户问什么就答什么”而不是“我不知道就直说”。我在实际项目里最头疼的就是第三点。用户问“你确定吗”很多模型会为了显得靠谱而坚持错误答案甚至会越编越详细。1.2 幻觉的四种典型形态把症状分清楚才能对症下药。我一般把幻觉分成四类事实性幻觉时间、地点、人名、数据出错。“某产品发布于2023年”实际是2024年这类最常见。逻辑性幻觉步骤之间自相矛盾前后对不上。推理类任务里特别多。指令性幻觉模型没按你的格式要求输出擅自加内容、换结构。引用性幻觉最坑的一种模型会编造参考文献、链接、引文看起来有鼻子有眼实际全是假的。测试下来纯靠模型自我修正几乎压不住这四类问题。必须从上下文层面入手。1.3 为什么上下文工程是“性价比最高”的解法调大模型的传统路子就两条换更大规模的模型或者做微调。前者成本高后者周期长而且微调对“未知知识”的注入效果并不好——模型该不知道的还是不知道。上下文工程不一样。它不改变模型参数只改变模型“看到什么”。你让模型看到的上下文里直接包含正确答案、明确边界和输出要求它就只能在你的框子里作答幻觉空间被物理压缩。打个比方。模型就像一个记性不太好但表现欲很强的实习生。你考他不知道的事他会编但如果你把答案写在纸条上放他桌上再告诉他“只准看纸条没有纸条就说不知道”他就算想编也编不出来了。上下文工程干的就是“写纸条、定规矩”这件事。2. 核心技术一系统提示词给模型划定作答边界2.1 系统提示词为什么是上下文工程的第一道防线系统提示词是所有上下文中最特殊的一部分。它的优先级高于用户输入而且通常情况下模型会把系统提示词当成“自己的行为准则”来执行。很多开发者的误区是系统提示词只写一句“你是一个智能助手请回答用户问题”。这不叫提示词工程这叫啥也没干。一个合格的系统提示词至少要承担三个职责定义身份与职责范围、明确知识与事实边界、规定输出格式与行为约束。2.2 一个可直接复用的系统提示词模板我项目里用下来效果最好的结构是“身份定义 知识约束 行为边界 兜底声明”四段式你是[某电商平台]的售后政策咨询助手。你的唯一职责是解答关于[订单退款、运费险、售后时效]三个范围内的问题。 知识依据 - 仅允许参考下方[知识库片段]中的内容进行回答。 - 如果[知识库片段]中没有相关信息必须明确回答“该问题超出我掌握的知识范围请转人工客服”禁止自行推断。 行为边界 - 禁止编造订单编号、金额、时间等具体数据。 - 禁止对政策条款做延伸解读。 - 回答时先给出结论再给出依据引用条款时说明条款编号。 输出格式 - 结论一句话概括。 - 依据引用具体条款原文。 - 建议基于条款给出的操作建议。 - 若无法回答直接输出“转人工”话术。这个模板第一次上线就把客服场景的事实性幻觉降低了大约五成。关键点在于“禁止自行推断”和“兜底话术”两条模型在没知识时会倾向于触发兜底而不是硬编。2.3 系统提示词的几个实操坑别把系统提示词写太长。超过300字之后收益递减核心规则会被稀释模型反而记不住。真需要长篇背景放在用户内容里给。否定式指令要写得具体。“不要胡说”这种模糊表述等于没说模型不知道啥算“胡说”。要写“不要编造订单编号”具体名词才有约束力。系统提示词也要测回归。改一次提示词别只测两三条用例就上线。我吃过亏某次改完客服问答准确率提了结果转人工率暴涨用户投诉更多了。提示词的修改要当代码需求一样走测试流程。3. 核心技术二少样本示例用标准答案把模型“教会”3.1 少样本示例为什么能压住幻觉系统提示词定规矩少样本示例给答案。模型基于模式匹配生成内容给它几个“问题-标准答案”的配对示例等于直接告诉它同样类型的问题我要的是这种质量的答案。我在总结归纳场景里验证过加上3到5个少样本示例之后回答风格的稳定性提升非常明显而且模型更容易“照葫芦画瓢”。它有示例可抄的时候倾向于模仿示例的结构和严谨度而不是自由发挥。3.2 示例选择的三个原则少样本不是随便丢几个例子进去就完事。我一般按三个原则挑同类型示例必须和用户当前问题属于同一范畴。问的是退货政策示例就不能是发货时间。覆盖边界至少要有一个“无法回答”的示例。这一步很多人漏掉导致模型以为所有问题都必须给出答案反而诱发编造。对比反差如果预算允许给一个“错误示范 正确示范”的对比组合让模型直观看到什么写法是错的。3.3 一个实际的少样本配置示例文本分类场景里我是这样配置的请根据用户描述将售后问题分类为退货退款、换货、物流查询、维修服务、其他。 分类时遵循以下示例 示例1 用户我前天申请退货今天收到短信说拒收了凭什么 分类退货退款 示例2 用户订单显示签收了但我没收到货。 分类物流查询 示例3 用户这台冰箱的门关不严能上门修吗 分类维修服务 示例4 用户我不想聊了叫你们经理来。 分类其他 现在请对以下用户描述进行分类 用户收到货发现颜色不对想换一个。这个例子看着简单实际上手时最大的坑是示例太少不管用示例太多有副作用。少于3个示范效果不稳超过8个一是浪费token二是某些模型会因为示例太杂而“不知所从”。5个左右是甜点区间个别复杂任务可以到7个再多就要考虑规则引擎了。4. 核心技术三RAG检索增强把模型的知识库“搬”到外部4.1 RAG的本质给模型一个可以查询的“外挂记忆”大模型的知识是从训练语料里学到的既可能过时也可能记错。RAGRetrieval-Augmented Generation的思路很简单回答之前先从外部知识库里检索相关片段把检索结果拼进上下文再让模型基于检索内容生成答案。这套路在知识密集场景里效果最明显。我有一个文档问答项目用RAG之前员工手册类问题的正确率只有七成引入RAG之后九成五以上。核心原因就是模型不再依赖它记得多少而是依赖你的知识库里有什么。4.2 一个最小可用的RAG链路实现我用一个极简例子说明整条链路。假设我要做一个“公司报销制度问答”知识库里是几份PDF文档。第一步把文档切成片段。切分直接影响检索质量。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , ., , ] ) chunks text_splitter.split_text(document_text) print(len(chunks))第二步给片段做向量化存入向量数据库。切好的片段要被转成向量之后才能做语义检索。from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import FAISS embeddings OpenAIEmbeddings() vectorstore FAISS.from_texts(chunks, embeddings)第三步查询时检索相关片段和问题一起喂给模型。这就是最核心的“检索-增强-生成”闭环from langchain.chains import RetrievalQA qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrievervectorstore.as_retriever(search_kwargs{k: 3}) ) answer qa_chain.run(报销打车费需要什么材料)4.3 RAG链路里五个关键参数怎么设chunk_size分块大小我一般从500到800字起步。太小则上下文碎片化关键信息被切散太大则检索精度下降还容易塞进无关内容。具体取值要看你文档的语料结构。chunk_overlap重叠长度80到120字比较稳防止关键句正好落在两块的切割缝上。top_k检索条数先设3再根据效果调。多了模型容易被无关片段带跑少了覆盖不住。相似度阈值低于阈值的片段宁可不要。设了阈值之后“查不到”的情况会明显减少。检索后重排简单场景可跳过但文档多、片段杂的时候加一层重排能显著提升喂给模型的上下文质量。4.4 我对RAG的一点批评RAG不是万能药。很多人以为装好向量库就完事结果上线后幻觉照样多。我排查过不少项目发现绝大多数是三个原因分段切得稀碎检索召回的内容不对或者把检索结果一股脑全塞给模型不做筛选。RAG的成败七成在检索阶段生成阶段只是“照着念”。别只盯着向量库选型先把切分和召回调明白效果能翻一倍。5. 核心技术四思维链推理逼模型“先想后答”5.1 为什么让模型多“想”几步能减少幻觉大模型的错误常常出在“跳步”。你让它直接给结论它会跳过推理过程凭直觉蹦出一个听起来合理的答案。思维链Chain-of-Thought的作用就是强制模型把推理过程展开先理解问题再列出已知条件然后逐步推导最后才下结论。过程一旦展开模型的注意力就会被分散到“步骤是否正确”上而不是执着于“结论是否像样”。实测中逻辑推理类的题目加了思维链要求之后正确率能从五成提到八成以上。5.2 触发链式推理的几种写法触发思维链不一定非要写“请一步一步思考”这个说法现在被很多模型的安全对齐拦得很死。我自己试下来有效的写法是“在给出最终结论前先展示你的推理步骤。”“请分步骤分析这个问题。”“把解题过程拆成三步已知条件、分析过程、最终结论。”“先不要回答先告诉我你打算怎么分析这个问题。”以数学题为例用户某商品的进价是120元加价30%后标价然后打8折出售问每件商品的利润率是多少 请按以下步骤作答 1. 写出已知条件。 2. 计算标价。 3. 计算折后价。 4. 计算利润率并保留一位小数。模型按步骤走下来每一步都基于前一步的结果一旦中间出错你也知道错在哪方便定位问题。5.3 思维链不适合用的场景思维链不是什么时候都好用。两类场景别硬套简单事实问答“北京在哪里”这类问题强行拆步骤反而增加错误路径。低延迟场景思维链会显著增加输出token数响应时间可能翻倍。线上高并发服务要慎用。另外思维链输出会暴露模型的“思考过程”在某些对文本有洁癖的场景比如生成正式报告里头你得把推理过程和最终答案在结构上分开只抽出结论部分给用户看。6. 核心技术五输出约束与结构强制让模型“没机会乱编”6.1 结构化输出的核心逻辑大模型乱编很多时候不是它不知道答案而是它“自由发挥”的空间太大。输出约束的思路是用格式和结构把模型的发挥空间框死让它只能在固定的字段里填内容。拿客服工单解析来说。如果你让模型“从对话里提取用户信息和诉求”它可能输出好几种格式有的还夹带私货。但如果用JSON Schema约束它它就只能输出你定好的那几项多一个字段都不行。6.2 一个实际的结构化输出配置在API调用层面直接用JSON Schema做约束{ name: order_refund_info, strict: true, schema: { type: object, properties: { order_id: {type: string}, user_complaint: {type: string}, decision: { type: string, enum: [approve_refund, reject_refund, need_human_review] }, basis: {type: string} }, required: [order_id, user_complaint, decision, basis], additionalProperties: false } }这套配置跑下来的效果是字段永远不会缺、不会多decision只会取枚举值里的三个之一。模型想乱写都没有空间。这就是把上下文工程从“文字层面”推进到“结构层面”的威力。6.3 输出约束的三个坑别把枚举值写太宽。我见过有人把“退款原因”的枚举写了二十多个值模型频繁选错。值越少越准能归为“其他”就归为“其他”。字段描述要详细。JSON Schema里加description字段告诉模型每个字段到底是啥意思准确性明显提升。别让结构化输出吃掉系统提示词。有些模型对JSON模式的约束是硬性的如果和系统提示词里的格式要求冲突会出现互相打架。系统提示词里的格式规范要跟JSON Schema保持一致。7. 核心技术六不确定性声明允许模型“说不知道”7.1 “敢于认怂”的模型更可靠这一条可能是六条里最反直觉的但效果极其明显。很多人把“模型能回答所有问题”当成好事实际上模型在不知道的时候硬答才是产生幻觉的最大来源。在上下文里明确允许甚至强制模型表达不确定性等于给了它一条“合法退路”。它不用为了保住面子而编答案安全的表达方式意味着更低的幻觉率。我在客服问答场景里加了一条“不确定就转人工”转人工率只增加了一点但用户投诉“AI乱说”的比例直接降了一大截。7.2 在提示词里怎么写不确定性声明我用过最有效的一套写法回答规则 1. 如果问题在知识库中有明确答案直接回答并标注依据来源。 2. 如果问题在知识库中没有明确答案或答案可能受时效性影响必须回答“该问题涉及的信息可能已变动建议以官方渠道为准”不得自行推断。 3. 如果问题包含无法核实的具体数据如订单金额、库存数量必须说明“我无法核实该数据”并引导用户提供截图或订单号。7.3 配合置信度阈值让模型自查更进阶的做法是让模型输出一个“置信度”字段然后你在代码层做拦截。请回答用户问题并在JSON中返回结果 - confidence0到1之间的小数表示你对答案的把握程度。 - answer你的回答内容。 当confidence低于0.6时answer字段必须返回“无法确认需要人工介入”。拿到结构化输出后代码里做一个简单的阈值判断低于阈值就走人工兜底流程。这套“模型自查 程序拦截”的双保险是我在金融文档问答项目里压幻觉最有效的手段。8. 六大技术的组合策略与实战选型8.1 不同场景该用哪几招六个技术各有侧重但真正的实战项目从来不是只用一招。我整理了一张技术选型对照表场景特征首选组合推荐说明客服问答知识密集RAG 系统提示词 不确定性声明知识库兜底边界约束答不上来就走人工信息抽取/工单解析输出约束 少样本示例JSON Schema框死结构少样本教会标签映射逻辑推理/数学计算思维链 结构化输出先展开过程再收敛到标准格式低延迟在线服务系统提示词 输出约束避免思维链带来的额外延迟开放域写作低风险少样本示例 系统提示词保证风格稳定不必过度约束8.2 一个完整的多技术组合示例我的实际项目里做得最多的就是把这几个技术叠在一起用效果远胜单发。举个例子一个售后工单自动分类 处理建议的系统完整提示词长这样[系统提示词] 你是售后工单处理助手。仅使用以下知识库内容回答。若知识库无相关内容回复“政策更新中请转人工”。禁止编造。 [知识库片段] 这里塞入RAG检索回来的3条相关政策原文 [少样本示例] 示例1 用户退款怎么还没到账 意图退款进度查询 处理建议查询财务系统退款状态若超过3个工作日需升级处理 示例2 用户我不小心把地址填错了能改吗 意图订单地址变更 处理建议确认订单是否已发货未发货可支持修改 [用户问题] 用户我退货的快递显示签收三天了怎么还不确认收货 [输出要求] 请按以下JSON格式输出 {intent: , policy_basis: , handling_suggestion: , confidence: 0.0} 若confidence小于0.6handling_suggestion必须为“转人工处理”。这个组合里动用了RAG、少样本、系统提示词、结构化输出、置信度兜底五招剩下思维链没有硬套因为工单分类不需要多步推理加了反而拖慢响应。8.3 怎么评估这六招到底有没有用调上下文工程最怕就是“凭感觉说变好了”。我给自己的项目定了三组量化指标每改一次上下文都对这三项跑回归准确率标注一批问答对人工判断回答是否正确。这是最硬的指标。幻觉率统计所有错误回答里“编造事实”的比例。这个指标能直接反映上下文工程的效果。兜底触发率回答“不知道/转人工”的比例。这个值不是越低越好降得太狠通常意味着模型在硬答。我个人实操中的感受是上下文工程做到位以后幻觉率能压到个位数但“零幻觉”是不现实的。评估时要给系统留一个容错空间设定不可答场景的人工兜底链路比追求一个不切实际的指标更有意义。9. 上下文工程的调试心法与实操避坑9.1 我调试上下文的工作流好用的上下文不是一次写出来的是测出来的。我调一个项目时通常分四步走第一步先建评测集。挑至少五十条代表性输入覆盖正常情况、边界情况和完全超出知识库的情况。没有评测集就调上下文等于闭眼开车。第二步单点测试定位问题。逐条看模型输出判断错误类型是“约束不到位”还是“知识缺失”还是“输出格式跑偏”对应去改系统提示词、补RAG片段、加JSON约束。第三步做组合对比。同一个输入分别用“只有系统提示词”“系统提示词RAG”“全套组合”跑一遍看每一层到底贡献了多少提升。第四步灰度回归。上线前用小流量跑一阵重点关注兜底触发率和人工介入率确认没有引入新的体验问题。9.2 高频踩坑清单上下文塞太满。把整本手册都喂进去模型反而抓不住重点。上下文不是越全越好是越精准越好。提示词和知识库打架。系统提示词说“必须引用来源”知识库片段里却没有来源信息模型就会编一个来源。这种冲突是硬编码的幻觉源。少样本示例带错风格。示例的严谨程度决定了输出的严谨程度。示例里如果有玩笑话模型也会学去。全依赖模型自查。模型说“我确定”不代表它真确定。置信度字段要用程序二次校验别把希望全押在模型自己身上。忽略输出解析的失败率。结构化输出偶尔会解析失败触发重试时如果把同样的错误上下文原样发回去错得一模一样。重试时要把上一次的失败反馈也放进上下文。9.3 最后的实战建议我见过太多团队在微调和换模型上砸资源却忽略了最简单的上下文调整。实际上上下文工程是所有大模型落地手段里投入产出比最高的一环。可以先从系统提示词加RAG开始把流程打通再加输出约束最后逐步叠加思维链和置信度兜底。每一层都有可量化的收益每一层也都有对应的调试方法。上下文工程不是一个“配一次就完事”的静态工作。知识库要更新提示词要维护评测集要扩充这是一个需要持续运营的工程体系。但它带来的回报是确定的——你不需要换模型不需要昂贵的微调算力只靠更好地组织上下文就能让大模型从“愛說胡話”变得“言之有据、理之有据”。这可能是目前大模型应用落地里最被低估、也最值得花时间深耕的方向之一。