1. 同样是RAG，为什么你的AI总在"一本正经地胡说八道"
你有没有遇到过这种情况：资料库搭好了，向量检索也通了，模型也换成了能力很强的那一档，可是用户问一句"我们公司的报销流程是什么"，AI回复得头头是道，你翻开制度文件一核对，发现流程完全对不上——它把两年前的旧制度跟今年的新制度缝在一起了。
我见过太多团队在RAG项目上卡在这一步。大家第一反应往往是"检索召回有问题""分块粒度不对""向量模型选错了"，折腾半天，最后发现根子其实非常简单——提示词里只写了一句话："请根据资料回答用户问题。"
这句话本身没有错，但它太模糊了。模型拿到这句话，再收到一堆检索片段，它并不清楚哪些片段能用、哪些不能用、资料不够时能不能直接说不知道、多个说法冲突时该怎么办。于是它只能按照预训练阶段形成的"默认习惯"来操作：把看起来相关的内容组织成一段通顺的话。结果就是——单看句子是通的，对照资料是错的。
这篇文章把RAG提示词这件事拆开讲清楚，并给你5个可以直接复制修改的RAG提示词模板，每个模板对应一类具体的"胡说八道"，后面还有我实际调试时的参数设置和踩坑记录。适合正在做知识库问答的开发者，也适合想搞懂RAG效果为什么忽好忽坏的产品和技术同学。
1.1 先搞清楚：RAG链路里的"幻觉"到底从哪一步来
要理解提示词为什么重要，得先看清RAG的完整链路。大致流程是：
- 文档先被切块、向量化，存进向量库，构成知识库；
- 用户输入问题，系统把问题向量化，从库里召回最相关的几个片段；
- 系统把这些片段连同用户问题拼成一段Prompt，交给大模型；
- 大模型根据Prompt里给的资料，组织成最终回答。
幻觉之所以出现，问题往往出在第2步和第3步之间的缝隙里。检索环节不会保证召回的所有片段都和问题强相关，可能5个片段里只有1条真正有用，其余4条只是"沾边"甚至是完全无关的。这些噪声片段会被原封不动地塞进Prompt，如果提示词没有任何过滤指令，模型就会把噪声也当作有效依据，结果就是回答里混入了大量无关内容。
另一个影响因素是模型自身的预训练知识。大模型在训练时已经见过海量文档，当你给它一小段检索资料时，它脑子里那些"自己知道的"知识会不断冒出来。如果提示词没有明确告诉你"只准用资料里的信息"，它很可能把预训练知识和检索资料混合在一起，输出一个看似合理、实则没有任何一条资料支持的答案。这种混合型幻觉是最隐蔽的，因为单看回答内容往往很自然，用户很难第一时间察觉有问题。
1.2 提示词在RAG里的真实作用：不是客气话，是操作手册
很多人把提示词当成"跟AI礼貌说话的话术"，这其实低估了它的作用。在RAG链路里，提示词是唯一一个能同时控制检索结果如何被看待、生成时有哪些限制、输出格式长什么样的环节。
我见过最典型的反面模板长这样：
你是智能客服，请根据提供的资料回答用户问题。 资料：{context} 用户问题：{question}这个模板翻车是必然的。模型看到这段指令后，完全不知道：资料里没有答案时能不能说不知道？多个片段矛盾时优先信哪个？回答需不需要标注来源编号？需不需要考虑输出格式？
于是模型只能按自己的理解自由发挥。有的模型倾向于"硬答"，资料不足也要给你编一个；有的模型倾向于"漫谈"，把预训练知识混进来；还有的模型会把不相关片段里的一句话当成线索，顺着脑补出一整段。这些问题在检索质量高的时候不明显，可一旦知识库变大、内容变杂、用户问题变复杂，差距立刻被放大。
我在做模拟知识库问答项目时，对同一批检索结果做过对比：同样的向量库、同样的模型，仅把上面那段"裸提示词"换成经过设计的模板，引用覆盖率从不到30%提升到了90%以上。这里没有让检索多做任何一步，纯粹是提示词在起作用。所以我的结论是：RAG调优，先看提示词，再动检索链路，这个顺序千万别反了。
2. 5个提示词模板逐个拆解：一个模板治一种病
下面这5个模板是我在项目里逐步沉淀下来的，按"病"分类。每个模板都会先说明治疗什么症状，然后给出完整可复制的模板结构，再解释为什么这样设计。你可以单独用，也可以组合用，第3部分我会专门讲组合策略。
提示：模板里的
{context}代表检索片段拼接后的文本，{question}代表用户问题。使用前记得把检索片段加上[1] [2] [3]这样的编号前缀，后面所有模板都依赖这个编号体系。
2.1 模板一：护栏式引用模板——不给依据就闭嘴
治疗症状：AI回答读着流畅，但每个关键事实都查无出处，用户追问"你从哪看到的"，它根本答不上来。
[系统指令] 你的任务是根据资料片段回答用户问题。回答必须严格基于资料片段，不得使用资料之外的任何知识。 资料片段（按编号引用）： {context} 回答要求： 1. 每个关键结论后面必须标注来源编号，格式为[编号]。 2. 如果资料片段中没有足够信息回答问题，请直接说"资料中未找到相关信息"，不要推测，不要脑补。 3. 不得把多个片段中没有直接关联的内容强行合并成新结论。 [用户问题] {question}这个模板的三个设计点很关键。
第一条"严格基于"是给模型的第一道约束，把"参考素材"的性质从"可选项"变成了"唯一依据"。第二条是"退路条款"，模型之所以爱编造，很多时候是因为它害怕回答不上来会显得无用，你明确允许它说"没找到"，它反而不会硬编。第三条是防止模型"跨片段缝合"，多个片段各说各的，它却能脑补出一个它们之间本来不存在的逻辑关系，这种缝合式幻觉最难看破。
我在实际项目里跑过效果对比。裸提示词状态下，模型回答中约半数结论没有资料依据；换成这个模板后，绝大多数回答都带上了来源编号，至少从形式上保证"每个结论都能追溯到某条片段"。注意，形式上的引用并不能保证语义一定正确，但至少人工核验的效率高了一个量级，用户能直接查看依据片段。
如果用的是指令跟随能力比较弱的开源小模型，可以在第3条后面追加一句："如果回答内容在资料片段中找不到依据，将被判定为失败。"这种威胁式约束对部分小模型确实管用，但对指令跟随强的模型则没必要，它反而可能过度紧张到不敢回答本可以回答的问题。
2.2 模板二：检索内容自查模板——先筛一遍再回答
治疗症状：召回结果里混着大量无关片段，模型"雨露均沾"全部用上，回答里一半内容在讲隔壁产品、旧版本或者完全不相关的事情。
[系统指令] 你将收到若干资料片段和一个用户问题。在回答之前，请先完成以下步骤： 1. 逐一检查每个片段与用户问题的相关程度，将片段标记为：高相关 / 低相关 / 不相关。 2. 回答时只使用"高相关"和"低相关"的片段，完全排除"不相关"片段。 3. 对于"低相关"片段，只允许使用其中的事实性信息，禁止做延伸解释。 资料片段（按编号引用）： {context} 请先输出每个编号对应的相关程度，再回答用户问题。 [用户问题] {question}这个模板的巧妙之处在于，它让模型先当一次"检索质量检查员"，再当"答题员"。把任务拆成两步之后，模型必须强迫自己逐个审视片段，而不是拿到Prompt后直接顺着第一段就开始答题。这样能显著降低"看到沾边的就强行用上"的概率。
我实测过一次印象很深的场景：知识库里混入了某个历史版本的旧文档，问题问的是现行方案，旧文档里恰好出现了同一个功能名但流程完全不同。裸提示词状态下，模型把这个旧文档当成了重要参考，回答里整个流程都错了。换上自查模板后，模型先根据片段发布时间和上下文的描述，把旧文档对应的编号标记为"不相关"，回答时自动排除了它。这个过程完全不需要额外写时间判断规则，模型自己能读出来语料里隐含的信息。
需要留意的是，这个模板会额外消耗一些token和时间，因为模型要先输出一遍相关程度标注。如果你的RAG应用对首字延迟特别敏感，可以去掉"请先输出每个编号对应的相关程度"这句话，只保留内部筛选的指令，效果会损失一些，但延迟能回来不少。
2.3 模板三：复杂问题拆分模板——把多跳题拆成选择题
治疗症状：用户的问题本身是复合型的，比如"对比A方案和B方案的适用场景，然后给出推荐"，单个检索片段回答不了，需要跨多个片段甚至多次检索才能整合出答案。
[系统指令] 用户提出的问题可能包含多个子问题。请按照下面的流程回答： 1. 先把用户问题拆解为2到5个子问题，并按顺序列出。 2. 根据资料片段，逐个回答每个子问题；每个子问题的回答必须标注引用编号。 3. 如果某个子问题在资料片段中找不到依据，明确标注"该子问题资料中无依据"，不要跳过，不要脑补。 4. 最后基于子问题的答案，汇总成对用户问题的最终回复。 资料片段（按编号引用）： {context} [用户问题] {question}这种模板解决的是"多跳问题"场景。模型面对复杂问题时，如果直接一步到位组织答案，很容易漏跳、跳错。拆解子问题的过程，相当于强制它把"综合题"变成"应用题"，每个子问题都必须在资料片段里有落脚点，最后汇总时才不容易编造。
我在一次测试里问的是"根据资料判断，某功能上线时需要先做哪两项配置，然后评估它对现有数据的影响"。裸提示词状态下，模型只从资料里找到了配置步骤，完全漏掉了新增数据字段对旧数据的兼容性影响。用模板三后，模型把问题拆成三个子问题：功能上线需要哪些配置、配置中涉及哪些数据字段、字段对旧数据是否兼容。第三个子问题迫使它去查找资料里关于"兼容性"的说明，最终回答完整覆盖了原本遗漏的部分。
这里还藏着一个进阶玩法：拆解出来的子问题列表，可以反过来用于二次检索。我的做法是把子问题单独提取出来，生成几个更简洁的检索词，再去向量库查一轮，把新召回的片段并入上下文后再回答。这样多跳问题的完整命中率会比只靠第一次检索明显提升。如果你的RAG架构里没有二次检索的环节，用这个模板+一轮检索也能有不少改善，只是遇到深层多跳问题时仍有概率缺料。
2.4 模板四：结构化输出模板——回答直接变成JSON给程序用
治疗症状：你要把RAG结果接进工单系统、自动报表、审批流程，但模型输出的是自然语言，程序解析全靠正则匹配，每加一个字段就改一次解析逻辑，维护成本越来越高。
[系统指令] 请根据资料片段回答用户问题，并严格输出JSON格式，不要输出JSON以外的任何内容。JSON结构如下： { "answer": "给用户的最终回答正文", "confidence": "HIGH / MEDIUM / LOW", "sources": ["编号1", "编号2"], "missing_info": "资料中未覆盖的信息点；若无则填null" } 字段说明： - answer：基于资料片段的答复，每个结论后标注引用编号。 - confidence：HIGH表示资料足以完整回答问题；MEDIUM表示资料部分覆盖；LOW表示基本无法回答。 - sources：本回答实际引用的资料编号列表。 - missing_info：列出回答中缺失的关键信息点；资料完整时为null。 资料片段（按编号引用）： {context} [用户问题] {question}结构化输出解决的是RAG落地到工程系统时的"最后一公里"问题。自然语言回答适合人看，但不适合程序处理。JSON格式让上层业务可以直接解析字段，不用维护一堆脆弱的正则规则。
字段设计上，confidence是最容易被人忽视但其实最值得用的。当置信度为LOW时，业务层可以自动触发兜底逻辑：转人工、弹追问、或者直接告知用户"当前资料不足以回答这个问题"。这个字段等于给了RAG应用一个"承认自己不知道"的正式入口。missing_info字段同样实用，在交互场景中，它可以直接转换成提示语"我还没找到XX信息，能否补充一下"，引导用户多维提问，降低反复试错成本。
实测中模型输出JSON最常见的毛病是前面多一句废话，比如"好的，以下是你需要的JSON"。遇到这种情况，我的做法是：先在指令里强调"不要输出JSON以外的任何内容"，然后在解析端增加兜底逻辑，如果解析失败就自动重试一次，并把"解析失败"本身当成信号记录下来，用于后续观察模板约束是否失效。多个模型对比下来，指令跟随能力越强的模型，额外废话出现的概率越低，所以不能完全靠解析兜底，模型选型同样重要。
2.5 模板五：冲突消解模板——新旧资料打架时不能和稀泥
治疗症状：知识库里同时存在旧文档和新文档，或者多个来源说法不一致，模型要么摇摆不定，要么强行"仲裁"出一个两边都没提到的第三种说法。
[系统指令] 资料片段中可能存在相互矛盾的信息。当检测到矛盾时，按照下面的优先级规则处理： 1. 先标注矛盾，说明哪几个编号的片段之间存在冲突，具体差异是什么。 2. 优先采信带有"更新时间"或"版本号"标识的片段；都有标识时，采用较新的。 3. 更新程度相同时，采用与多数片段一致的结论。 4. 如果仍然无法判断，在回答中保留两种说法，并标注"资料显示存在不一致，需进一步确认"。 5. 严禁为了消除矛盾而创造资料中不存在的第三种说法。 资料片段（按编号引用）： {context} [用户问题] {question}冲突消解往往是RAG项目做大之后才暴露的问题。知识库只要持续更新，旧资料没有被及时清理或打上过期标记，就一定会出现"一份说流程A、一份说流程B"的情况。模型面对矛盾信息时的默认行为是"调停"，它总想给出一个让所有信息看起来都对得上的回答，这个调停过程恰恰是编造的重灾区。
这个模板的关键在第1条和第5条。第1条要求模型先把矛盾摆到台面上，意味着它不能假装什么问题都没有。第5条明确禁止创造第三种说法，等于把"调停编造"这条路堵死。剩下的就是机械式的优先级判断，规则越机械，模型越不容易自由发挥。
配套建议是：如果知识库支持元数据，把每份文档的上传时间或版本号以字段形式拼进context片段里，比如在每一段前面加上[更新时间：2025-03-01]。没有时间标识时，模型只能靠文本内容猜测哪个是旧的，猜测准确率并不高。我测试过，给片段加上明确时间前缀后，冲突场景的回答准确率提升了约三成，而且回答里那句"需进一步确认"的出现频率也明显下降，因为模型具备了足够信息做判断。
3. 模板落地不算完：编排框架、手写链路与模型适配
很多读者把模板复制走之后发现，直接套用并不一定生效，这正常。RAG提示词的效果和你的整体链路强相关，尤其是向量库、模型类型和检索参数都会影响模板表现。下面说几个实际落地时容易踩坑的地方。
3.1 在RAG编排框架里如何替换默认提示词
现在主流的RAG编排框架都在内部封装了一套默认Prompt，很多团队图快就直接沿用了。替换成自定义模板的方式几乎都差不多：先构建一个消息模板，把{context}和{question}作为变量，再和检索器、模型、输出解析器拼在一起。示意结构如下：
prompt_template = [ {"role": "system", "content": SYSTEM_TEMPLATE}, {"role": "user", "content": "资料片段（按编号引用）：\n{context}\n\n用户问题：{question}"} ] # 推理时 docs = retriever.search(question, top_k=5) context = "\n".join([f"[{i+1}] {doc.content}" for i, doc in enumerate(docs)]) final_prompt = render(prompt_template, context=context, question=question) answer = model.generate(final_prompt)这段伪代码里最重要的三件事：第一，系统提示词里放模板的主要指令，不要放用户消息里，实测大多数模型对系统消息的遵循度更高；第二，检索结果必须带上编号前缀，[1][2]这类格式要和模板里的引用规则完全一致，否则模板要求"标注[编号]"而上下文里根本没有编号，模型就只能自己编编号；第三，输出解析器只处理最终输出，但模板里的"先输出相关程度再回答问题"这种多步输出，就不适合直接接JSON解析器，需要按步骤剥开处理。
3.2 手写RAG链路时，Prompt拼接顺序怎么排
如果你是自己手写的RAG链路，拼接顺序可以直接参考一个原则：系统指令放最前，检索片段放中间，输出要求放靠近问题的位置，最后才是用户问题本身。
这个顺序不是随便定的。模型对越靠前的指令越倾向于当作"元规则"，所以系统指令要放最前面，让模型先把"必须引用"这类规则内化；输出要求放在靠近末尾的位置，是因为模型生成时对最后读到的内容印象更深，对格式类约束更敏感；检索片段放在中间，模型会把它当成"待处理素材"，而不是把它也当成指令的一部分。
一个常用的手写拼接模板：
context = "\n".join([f"[{i+1}] {doc.content}" for i, doc in enumerate(docs)]) prompt = ( SYSTEM_RULES + "\n\n资料片段（按编号引用）：\n" + context + "\n\n输出要求：\n" + OUTPUT_RULES + "\n\n用户问题：\n" + question )注意，SYSTEM_RULES和OUTPUT_RULES不要写成同一段内容，它们在语义上是有分工的。前者管"角色的身份、认知边界、资料的地位"，后者管"格式、语气、必须做的事"。如果全塞在一起，模型对哪条指令属于哪个环节的感知会变弱。
3.3 模型能力强弱不同，模板要裁剪
同样是这一套模板，放到指令跟随能力不同的模型上，表现差异非常大。指令跟随强的商业大模型，你可以直接把模板完整丢给它，它基本能按照要求执行；开源小模型则经常出现"命令太多记不住"的情况，面对5条以上规则会开始选择性失忆。
我的经验是分三档处理：
| 模型能力 | 推荐模板组合 | 注意事项 |
|---|---|---|
| 强（商业大模型接口） | 模板一 + 模板三 + 模板四 | 完整使用，输出质量的提升最明显 |
| 中（一般开源模型） | 模板一 + 模板三 | 模板二可压缩为一句"先排除不相关片段再回答"；模板四慎用，JSON多字段容易崩 |
| 弱 / 轻量模型 | 模板一的简化版 | 只保留"严格基于资料、必须标编号、不够就说不知道"，叠加太多指令反而降低回答质量 |
这里要特别提醒：别以为模板越多越好。指令本身也占用模型的"注意力预算"，规则越多，模型对关键约束的执行强度越可能被稀释。我在测试某个轻量模型时，把5个模板全部叠进去，结果模型连"标注引用编号"都忘了。后来砍到只剩模板一的核心规则，表现反而稳定了。
4. 参数调优与实测记录：哪些调整让效果真正"翻倍"
模板换上了，不等于万事大吉。RAG效果的最终表现还取决于几个关键参数，这些参数和提示词模板是联动关系，单独调任何一边都达不到最优效果。
4.1 top-k的调法要和模板联动
很多教程告诉你top-k设置成3到5，这个建议在"裸提示词"场景下是对的，因为召回多了就等于引入更多噪声。但当你用了模板二（自查模板）之后，情况就变了：模型本来就有一道"过滤不相关片段"的工序，此时top-k稍微调大，比如7到10，反而能提高召回率，因为噪声片段会被模型自己排除掉，而多召回的那部分可能在边缘情况下带回关键信息。
我在模拟项目里的对比非常直观：同样的模板一（引用护栏），top-k=3时答案准确但覆盖不全，遇到多跳问题经常缺信息；top-k=7时噪声多了，但模型在引用约束下仍然只引用相关片段，答案的完整性明显更好。前提是模板一和模板二至少要有一个在生效，否则调大top-k就是自找麻烦。
4.2 temperature必须归零，不要妥协
RAG场景里模型的核心任务是"忠实转述+组织语言"，不是文学创作，因此采样随机性收益极低、风险极高。我在项目里跑过一组对比：同样22个测试问题，temperature=0.7时出现了3处引用编号错位、2处事实轻微改写；temperature=0时编号错位为0，事实改动为0。
temperature=0不代表输出绝对确定，但对忠实度的影响是质变。如果你发现某个RAG应用还保留着默认的0.7或1.0，这基本等于放弃了最廉价的一层幻觉防护。先把temperature设为0，再来看提示词的效果，否则模板设计得再好，随机性也会给结果注入不稳定因素。
4.3 我实际踩过的引用失效翻车现场
分享三个真实遇到的坑，都是提示词与链路其他环节不配套导致的。
第一个坑是检索片段没有编号，模板却要求标注编号。结果模型自己编了个编号出来，用户点开引用一看，编号对应的根本不是那句话。这个问题的解决办法很简单：在拼接context时用代码强制给每段加上[i+1]前缀，而不是靠模板或模型自觉。
第二个坑是编号格式不一致。我给检索片段加的是[1][2]，但向量库返回的另一路片段默认带了[doc1][doc2]前缀，模型识别起来很不稳定。统一格式之后，引用准确率立刻稳定下来。
第三个坑是System和User消息里的指令互相打架。System里写"只基于资料回答"，User里又写"根据你的常识补充一些建议"，模型会倾向于服从User消息里更具体的指令，结果就是回答里混进了大量资料外内容。解决方法是：所有约束类指令只保留在System里，User消息里只放资料和问题，不做任何补充性引导。
4.4 建立你自己的回归测试集，比调什么都管用
RAG提示词调试最忌讳"凭感觉"。感觉这次效果好，感觉这次回复变差了，没有量化数据支撑，很难判断改动到底起了什么作用。我的做法是，从真实历史问题中挑20到30个，覆盖四类场景：简单事实题、复杂对比题、资料缺失题、资料矛盾题，组成一个固定测试集。每次修改提示词、参数、甚至更换模型后，全量跑一遍，记录三个指标：引用准确率、幻觉数量、人工纠错次数。
维护测试集本身不需要花太多时间，但对迭代效率的提升非常明显。特别是当你想尝试一个新模板时，测试集会直接告诉你它到底比之前好还是差，而不是等着线上用户替你做实验。我现在的习惯是：任何提示词上的改动，先过一遍测试集，再决定要不要上线。
最后分享一个小技巧。如果你换了新的模型底座，不要直接拿旧模板上线。不同模型的"脾气"差异很大，同一个模板在A模型上效果很好，换到B模型上可能约束完全失效。这时候跑一遍测试集，你就能快速发现哪些约束失效了，然后针对性地把模板里对应的规则改得更死板或更宽松。RAG提示词的优化没有一步到位的方案，本质上是一个持续迭代的过程。
