RAG系统里给大模型加的prompt到底该怎么写才不冲突？

我之前也踩过这个坑，后来发现核心问题往往不在prompt本身，而在检索质量。如果召回的片段本身就不相关或者互相矛盾，你prompt写得再花哨，模型也容易懵。可以先看看你top-k的相似度分数，如果阈值设得太低，一堆垃圾进上下文，它当然会“选择性失明”。至于“只基于文档回答”这个指令，我后来改成“如果文档没有明确提及，请直接说资料不足”，比单纯禁止编造有效得多，因为给了模型一个体面的“退路”。

关于few-shot，我试过加一个正例和一个反例，比如展示“文档说了A，就答A”和“文档没提，就说不知道”，模型稳定性会好不少，但别超过三个，不然会挤占上下文窗口。还有一个细节，把检索内容放在user prompt里而不是system里，并且用更明确的标记，比如“以下是唯一可参考的资料”，比标签管用，因为有些模型对标签的遵循度远不如自然语言指令。最后，如果你发现它总依赖预训练知识，试着在system里加一句“你是一个只能访问本地资料库的助手”，有时候这种身份设定比硬性规则更能抑制幻觉。

试过把放前面再加一句“优先用材料，材料没说就明说”，效果稳不少，你可以试试。

或者别太纠结格式，关键是在user prompt里直接告诉它“这些资料是你唯一的信息来源，别用你自己的知识”。

我最近也在调这玩意儿，咱俩症状几乎一模一样。后来我试了个笨办法，把system prompt里“只基于文档”改成“文档是唯一事实来源，但你可以用常识补充解释，别编造具体数据”，效果反而稳了。感觉大模型对“禁止”类指令特别容易叛逆，你越说“不要瞎编”，它越容易在边界模糊时放飞自我。

另外你那个标签其实没问题，关键是要在user prompt里明确告诉它“如果标签内信息不够，直接说缺什么，别硬答”。我加了一句“回答时先标注哪些来自文档，哪些是推断”，模型就老实多了，至少能看出它的思考路径。

few-shot我觉得得看场景，如果问法很固定可以加，但要是开放式问题，示例反而会带偏它。还有个坑是检索片段太碎时，模型会自己脑补连贯性——我后来把多个片段拼一起时强制用“；”分隔，并在问题里加“按文档顺序回答”，幻觉率降了不少。

不过最玄学的还是温度参数，我调低到0.1之后，它“不知道”的次数变多了，但至少不瞎编了。你试试把“合理推断”的权限写得更具体，比如“只能推断因果关系，不能推断具体数值”，也许能解决打架问题。

我也遇到过，后来把规则塞进system里再给个简短示例，效果稳多了。

我一般会在system里写“优先用回答，不足时明确说不知道”，但别指望模型百分百听话。实测few-shot放一两个“文档没有就承认”的例子，比光讲规则管用。还有个坑是检索质量差的时候，你prompt再漂亮也白搭，先把召回率搞上去。

我一般把规则放system里，检索内容用标签包住放user里，再补一句“没找到就直说”，效果稳不少。

我一般把检索内容放system里，指令放最后，感觉冲突少很多，你可以试试。

我也遇到过类似的问题，后来发现关键是把“忠于检索”的规则拆成两步：先让模型判断检索内容够不够回答，不够就直接说信息不足，别硬编。然后在回答时要求它每句话都标注来自哪段context，这样它就不太敢乱来了。few-shot我试过，加一两个“文档没提但能合理推断”的例子确实有用，但别加多，不然模型会偷懒照抄格式。另外温度调到0.2左右，比死磕prompt措辞管用多了。

我也踩过这个坑，后来发现问题的关键其实不在措辞本身，而是你给的“边界”太硬了。你写“只基于提供的文档回答”，模型听到的是“不许用我自己的知识”，但检索片段又经常缺胳膊少腿，它就只能在“瞎编”和“说不知道”之间反复横跳。我现在的做法是把指令拆成两层：一层是“优先使用里的信息”，另一层是“如果context不足以回答，明确说出来，但可以补充常识性背景”。这样模型有个台阶下，不会硬编。另外few-shot确实有用，但别放那种“标准问答”，放一两个“context不完整时该怎么回应”的示例，效果比强调十遍规则都强。还有个细节是context的摆放位置，我试过放system里和放user里，差别挺大，放user里并且用明确的分隔符隔开，模型对“这是外部资料”的感知会更强。温度也别开太高，RAG场景下0.1到0.3就够了，高了它就开始自由发挥。

我最近也在折腾这个，感觉关键不是把规则堆在system里，而是把检索内容直接放进user消息里，并且用简短指令收尾，比如“若上下文不足就直说”。few-shot可以加，但别放太多，容易占上下文还把模型带偏。另外“忠于检索”和“合理推断”得看场景，事实型问题就卡死，开放型问题允许它补一句“基于常识”。

我之前也踩过这个坑，后来发现关键不是把规则写得多严厉，而是得让模型觉得“用检索内容回答”是件自然的事。我现在的做法是把system prompt拆成两层，一层定角色和边界，比如“你是基于给定资料作答的助手”，另一层专门讲冲突时怎么办，比如“资料没提的就直说没提，别拿常识补”。然后user那边我不光包context，还会在context后面加一句“以上是全部可用资料”，这样模型更容易收住。
few-shot我试过，有用但别放太多，两三个例子就够，重点展示“资料不足时怎么答”和“资料里有答案时怎么引用”。另外温度调低一点也有帮助，0.2左右比默认稳不少。还有个细节是检索片段别塞太满，太多无关内容反而让模型分心，宁可少而准。
至于“忠于检索”和“合理推断”的平衡，我的经验是看场景：事实型问答就死磕检索，推断型任务可以允许模型在资料基础上做有限归纳，但得在prompt里明确说“可以总结，不要引入新事实”。最后建议你把失败案例单独存下来，反推是检索问题还是prompt问题，很多时候锅不在措辞上。

我一般会把system prompt写死成“必须优先依据，信息不足就明确说不知道”，但关键还是别让模型自己发挥。few-shot确实有用，不过别塞太多，挑一两个“引用原文+简短回答”的例子就够了，太多反而挤占上下文。还有个坑是检索片段顺序和相关性，有时候不是prompt的问题，是召回的噪声把模型带偏了。

我也踩过这个坑，后来发现关键不是措辞多强硬，而是把“允许推断”和“不允许编造”分开说清楚。比如我会写：优先用context回答，context不够时可以基于常识补充，但要明确标注哪部分不是文档里的。加一两个few-shot确实有用，尤其示范“信息不全时怎么答”，比单纯说“别瞎编”管用多了。另外温度调低点也有帮助，不然模型容易自由发挥。

可以试试把规则写进system，检索内容放user，再给一两个示例，模型就不容易精神分裂了。

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

这个思路不错，收藏了。

这个思路不错，收藏了。