在RAG（检索增强生成）系统中，提示词工程是确保模型输出准确性和相关性的核心环节。通过精心设计和优化提示词，能够有效引导模型理解用户的意图，从而生成更为精准和相关的回答。提示词不仅仅是输入的简单文本，它们承载着上下文信息和特定的语义指向，能够影响模型的推理过程和生成结果。

其实，已经很多的提示词框架供大家参考和使用，网络上也可以搜索很多，这里不再赘述。这里更多的是说明在RAG场景下的提示词的编写规则。

---

选择合适的模型

prompt工程本质上是LLM不成熟的副产品；合适的模型一定可以带来还不错的结果。这里的合适不是指最新的、最贵的模型，而是结合业务特点来进行。可以通过几点来考虑：

• 上下文长度：结合提示词和领域知识的复杂程度，选择合适的上下文长度，以容纳检索获得的多文档片段。如果场景中更加侧重获得更多的召回，避免信息遗漏，较大的上下文就很必要。
• 推理及响应延迟：在Deepseek R1面世后，可视化的推理过程被人推崇，但其延迟也是明显的；比如在客户解答用户场景过程中，大模型较长的延迟可能带来不好的用户体验。而该过程还仅仅是RAG耗时的其中一环。
• 专业度&领域适配度：在一些特定领域，微调后的模型往往比通用大模型更加专业，比如医疗、法律。例如前司传神提出的素问中医大模型，其对于中医领域肯定更加专业。
• ROI/投入与效果：兼顾价格和效果。至少价格是业务可以承受的，效果是可以进行验证的。这个过程是仁者见仁智者见智的阶段，主观看法很明显。效果的判定也往往需要大量的人为干预，在之前项目中就曾经邀请专业同事进行背对背的打分，这又涉及另外的系统来去考验人性了，很难去确保主观打分的严谨性、一致性。后面有时间，会专题再去讨论该问题。

---

不要迷恋大模型

Douwe Kiela的一场演讲中也提及了该点，大家可以去搜索《RAG之父：部署RAG Agents的10个经验教训》即可查看。

企业AI项目最常见的错误：过度关注语言模型性能。成功的RAG项目都不是因为模型最强，而是因为系统最完整。”更好的大语言模型不是唯一答案，系统级能力优先于模型性能。” Kiela的第一条教训直指痛点。

RAG其实是一整套的解决方案，大模型只是其中一环，工程化也会影响RAG整体的效果。

其实，该观点也适用于其他大模型的产品中，从更高维度看，大模型只是一种技术方案，具有一定的先进性，但是这种先进性并不意味着之前其他的一些传统算法、工程化方法是落伍的、闭塞的。对于产品经理来说，没有最好的解决方案，只有最合适的解决方案；技术不论新旧，能够有效满足场景需求才是重点；所以白猫黑猫理论适用于大模型时代的产品设计。

---

RAG提示词如何写

提示词的要求

其他的一些提示词框架这里不赘述，主要提两点关注：

输出的要求：比如字数要求、输出格式、条理性等，甚至是表格等；也可以让大模型直接返回json格式数据，再通过工程化方法进行二次处理

异常的兜底：当召回为空或相关性较差的时候，需要提供兜底的输出，引导用户换一种Query提问搜索；宁缺毋滥，切勿让大模型随意发挥。

提示词的范例

角色约定部分

你是一名专业的“知识整合专家”，你的核心任务是根据用户提供的检索文档（###中间的文本###）回答问题。  
请严格遵守以下规则：  
1. **精准匹配原则**：答案必须严格基于提供的文本内容生成，禁止引入外部知识或主观推测（[[0]](#__0) [[2]](#__2)）；  
2. **分步验证流程**：  
   - 步骤1：先解析用户问题的关键词和意图，明确需求范围；  
   - 步骤2：从文档中检索与问题直接相关的段落（至少3段），标注原文位置（如段落编号）；  
   - 步骤3：交叉验证检索结果的一致性，剔除矛盾或模糊信息；  
3. **容错与交互机制**：  
   - 若文档信息不足以回答问题，需明确说明缺失的具体内容（例如“文档未提及2023年后数据”），而非简单拒绝（[[1]](#__1)）；  
   - 若问题存在歧义，主动列出可能的解读方向并要求用户澄清。  

输出格式要求

### 回答格式示例 ###  
**[答案摘要]**  
{用1-2句话总结核心结论}  

**[支持证据]**  
1. 段落[编号]：“...” → 解释相关性  
2. 段落[编号]：“...” → 解释相关性  

**[置信度评估]**  
- 高：所有证据一致且无冲突  
- 中：证据有限但逻辑合理  
- 低：信息不足或存在矛盾（需提示风险）