彻底消除 RAG 幻觉：从提示词工程转向架构级约束

如果你曾经发布过检索增强生成（RAG）助手，你很可能在系统提示词（System Prompt）中写过类似这样的话：“如果答案不在提供的上下文中，请回答你不知道。不要编造任何信息。”然而，你可能也目睹了模型在压力之下是如何轻而易举地忽略这条指令的。无论是 GPT-4 还是像 Claude 3.5 Sonnet 这样先进的模型，当用户提出一个听起来很专业的问题时，检索系统返回了一些擦边的内容，模型就会开始“发挥”，缝合出一个听起来逻辑通顺、表达流利但完全错误的答案。

告诉大语言模型（LLM）不要产生幻觉，本质上只是一种“建议”。在模型的行为优先级中，建议往往会输给模型那种“过度乐于助人”的本能。当你通过 n1n.ai 这样高性能的 LLM API 聚合平台调用顶级模型时，虽然你获得了强大的推理能力，但如果输入的数据本身存在歧义，模型依然会倾向于迎合用户的期望，而不是果断拒绝。

为什么提示词工程无法根治幻觉？

提示词工程在防止幻觉方面已经遇到了瓶颈。原因很简单：LLM 的训练目标是预测下一个 token。在它们的内部权重中，完成对话的动机非常强烈。当检索到的上下文（Context）质量不高或不相关时，模型会利用其预训练的知识库来填补空白。这种“知识补全”往往会导致幻觉，甚至编造出与参考文档完全背道而驰的事实。

与其通过越来越复杂的提示词来和模型“斗智斗勇”，不如换一种思路。在开发 MCP（Model Context Protocol）SDK 文档助手时，我意识到处理“拒绝回答”的最佳方式不是要求模型拒绝，而是从根本上剥离它编造事实的能力。核心逻辑很简单：模型只有在你有素材喂给它时才能产生幻觉。如果你不给它素材，它就无从编造。

架构级门控：将拒绝逻辑下放到工具层

在传统的 RAG 管道中，检索工具负责抓取数据，然后无论匹配度如何都直接丢给 LLM。这种设计寄希望于 LLM 能够自行判断相关性。而在一个健壮的架构中，拒绝决策应该发生在检索工具内部，在大模型看到数据之前就完成。如果没有任何搜索结果能超过设定的置信度阈值，工具将直接返回一个空集。此时，模型面前没有任何参考文本，它唯一的选择就是诚实地回答“文档中没有相关记录”。

在实际代码中，这种“置信度门控”的实现逻辑如下：

const candidates = await hybridSearch(query, \{ version, limit: 12 \});

// 如果最佳匹配的余弦相似度低于阈值（例如 0.45），则直接拦截
if (!hasConfidentMatch(candidates)) {
  // 这里的 gate 逻辑是关键：不给模型任何发挥空间
  return { relevant: false, results: [] };
}

// 只有通过门控的数据才会进入重排序（Rerank）阶段
const results = await rerank(query, candidates, 6);
return { relevant: true, results };

通过这种方式，拒绝回答不再是你期望模型具备的一种“性格特质”，而成了系统架构的一种“物理属性”。这种方法在配合使用 n1n.ai 提供的 DeepSeek-V3 或 OpenAI o3 模型时效果尤为显著，因为这些模型对工具调用（Tool Calling）的返回结果有着极高的服从度。

高级检索技术：混合搜索与 RRF 融合

要让这个“拒绝门控”真正起作用，检索的精度必须极高。如果检索系统太弱，就会导致过多的“误报”（明明文档里有，却因为没搜到而拒绝回答）。为了解决这个问题，我们需要构建一个多维度的检索管道：

1. 语义搜索：利用 Postgres 的 pgvector 扩展进行向量余弦相似度计算，捕捉用户的意图。
2. 全文检索：利用 Postgres 的 Full-Text Search 进行关键词匹配。这对于技术文档至关重要，因为函数名（如 sendRequest）的精确匹配往往比语义相似性更重要。
3. 倒排排名融合 (RRF)：这是一种将不同搜索算法的结果进行融合的算法。它不需要对分数进行归一化，就能有效地平衡语义和文本的权重。如果一个结果在两种搜索方式中都排名靠前，它将获得极高的优先级。

应对版本迭代：处理 SDK 的重大更新

对于像 MCP TypeScript SDK 这样迭代迅速的项目，版本控制是 RAG 系统的一大痛点。v1 和 v2 之间可能存在破坏性的 API 变更。普通的文档机器人经常会把两个版本的代码片段混在一起，导致用户复制的代码根本无法运行。

我们的解决方案是将“版本”作为检索的首要维度。在数据入库（Ingestion）阶段，每一段文本都会被标记上对应的版本号。检索时，根据用户所处的环境自动过滤版本。结合前文提到的拒绝门控，这确保了助手能够做到三点：版本正确、引用精准、无据可查时果断拒绝。

构建评估体系：Golden Set 的重要性

你如何量化你的 RAG 系统是否变得更好了？不能靠感觉。你需要建立一个“黄金测试集”（Golden Set）。在我的实践中，我编写了一个包含 18 个典型案例的测试集，专门评估以下三个核心指标：

• 拒绝准确率：当问题超出范围时，系统是否真的拒绝了？
• 引用完整性：每一句回答是否都附带了正确的原始文档链接？
• 版本正确性：是否根据请求提供了对应版本的代码？

在早期测试中，我发现即使检索系统返回了相似度高达 0.70 的结果，模型有时仍会因为过度解读而选择拒绝。修复方法是在系统提示词中明确告知模型：只要工具返回了结果，这些结果就是绝对相关的。这种检索工具与模型推理之间的协同，是提升系统表现的关键。对于开发者来说，通过 n1n.ai 接入多种模型进行对比测试，是优化这类评估指标的高效途径。

总结：约束优于建议

如果你正在构建 RAG 系统，最重要的经验分享就是：你真正关心的行为——无论是拒绝、引用还是版本控制——通过代码强制执行比通过提示词请求要可靠得多。提示词是一种希望，而检索工具中的门控是一种约束。在面对刁钻的对抗性问题时，约束的稳定性远超礼貌的指令。

通过将逻辑从“软性”的提示词层移动到“硬性”的架构门控层，你可以创造出一个不仅聪明，而且真正值得信赖的 AI 助手。

Get a free API key at n1n.ai