一个基于 WhatsApp 的新型 RAG（检索增强生成）助手通过要求每个答案都必须有 JSON 编码的引用，从而解决了幻觉问题。当模型无法指向特定的数据块（chunk）时，它会返回“我没有足够的信息来回答这个问题”，将一个自信的“骗子”变成了一个值得信赖的“我不知道”系统。

为什么信任在 RAG 中至关重要

大多数关于 RAG 的教程都过度关注检索——选择嵌入（embeddings）、将文档切分为数据块（chunks）、对结果进行重排序（re-ranking）。它们忽略了找到相关文本之后发生的事情。当助手给出一个检索到的上下文实际上并不支持的确定性答案时，用户就会失去信心。

置信度差距

在一个使用 PostgreSQL 和 pgvector 扩展构建的原型中，检索流水线非常直接。真正的挑战出现在生产环境中：即使检索到的片段缺乏所需信息，语言模型听起来也很有把握。演示（demo）可能会掩盖问题，但真实用户暴露了“听起来很自信”与“事实正确”之间的差距。

通过 JSON 强制执行引用

作者没有使用像“只有在你有上下文的情况下才回答”这样的提示词来诱导模型，而是改变了输出格式。系统现在要求一个 JSON 对象，其中每个主张都包含对其支持的精确数据块的引用。如果模型无法附加引用，响应将被拒绝，用户会看到清晰的“我不知道”消息。

强制执行从自然语言指令转向了模式验证（schema validation）。模型仍然生成文本，但周围的代码会在文本到达用户之前检查 JSON 是否符合要求的结构。

发生了哪些变化

  • 分块策略变得更加保守。 模糊或过于宽泛的数据块现在会生成没有引用的主张，从而触发“我不知道”的兜底机制。
  • 系统提示词（system prompt）缩减了。 试图监管模型行为的繁琐提示词被简短的指令集所取代，让模式（schema）承担了主要工作。
  • 失败变得可见。 当检索返回无关材料时，助手不再用自信但错误的答案来掩盖错误；它会公开承认不确定性。

核心启示： 对于 RAG 助手而言，确保每个主张都能追溯到检索到的来源，比单纯优化检索步骤更能可靠地建立用户信任。通过将缺失的引用转化为可见的“我不知道”，开发者让系统承认其局限性，而不是编造答案。