拒绝 AI 幻觉：构建一个具备“事实核查”能力的资料检索智能体

如果你希望 AI 在回答资料型问题时少“猜”、多给依据，关键不是把提示词写得更强硬，而是把回答过程改造成一条可检查的检索链路：先明确问题，再查找资料，随后筛选和核对，最后只根据证据生成答案。这个过程就是面向事实核查的检索增强生成（RAG）智能体。

先明确：RAG 不是“把资料塞给模型”

RAG 的基本思路是先检索与问题相关、能够支撑答案的文档，再把这些文档作为上下文交给生成模型。模型不必只依赖训练阶段形成的静态知识，而是可以根据当前检索结果组织回答，并同时给出资料来源。Prompt Engineering Guide 对 RAG 的介绍也强调了“检索文档—生成回答—提供来源”这一基本链路。

但普通 RAG 仍然可能产生问题：检索到的内容不一定真的支持用户的问题，多个来源之间可能互相矛盾，模型也可能把自己的常识混进答案，却只给出一个看似完整的引用。因此，具备事实核查能力的智能体，至少要把流程拆成四个阶段：

1. 理解问题并判断是否需要澄清；




2. 检索、筛选和整理证据；




3. 对关键事实执行验证；




4. 只根据通过验证的证据生成带引用的答案。

这里的重点是“证据先于结论”，而不是让模型在最后补几个来源链接。

第一步：把用户问题拆成可验证的事实

用户的问题往往不是一个简单事实，而是多个隐藏任务的组合。例如，“某个方案是否更适合小团队，成本和风险怎么样”至少包含对象识别、适用场景、成本比较和风险判断。若直接把整句话交给检索模块，返回的资料容易过于宽泛，后续也很难判断每条资料到底支持哪一个结论。

可以先让问题理解模块输出一份内部任务表：

字段	要解决的问题
核心问题	用户最终想知道什么
时间范围	是否只接受某个时间点之后的资料
对象范围	讨论哪个产品、项目、行业或文档
事实清单	最终答案必须核对哪些具体陈述
证据要求	每条陈述需要什么类型的来源
不确定项	哪些信息需要向用户追问

这一步不应急于回答。比如用户没有说明“最新”对应的时间范围，智能体可以先追问；如果问题涉及多个主题，则应拆成多个检索任务。阿里云深度搜索实践资料将查询理解、规划、搜索、澄清、总结和答案校正分别作为不同职责，这种拆分思路适合用来设计事实核查流程。阿里云深度搜索实践教程

第二步：让检索围绕“证据”而不是关键词展开

检索模块的目标不是返回一堆相似文本，而是为每个待核查事实寻找能够直接支撑它的证据。资料库中可以同时存在产品文档、内部资料、网页内容和结构化数据，但不同问题适合的索引并不相同。Microsoft Learn 的高级 RAG 资料提到，可以由路由器为问题选择一个或多个适合的索引；事实型内容和意见、特殊主题内容可能需要不同的索引。Microsoft Learn：构建高级检索扩充生成系统

实际设计时，可以把检索过程分成三层。

第一层是问题改写。将用户的自然语言转成若干个更适合搜索的子问题，同时保留原始问题，避免改写后改变用户意图。比如“哪个方案更稳定”可以拆成“稳定性如何定义”“是否有故障记录”“官方文档说明了哪些限制”“不同方案的适用边界是什么”。

第二层是多路召回。不要只依赖一种检索方式，可以结合关键词、语义相似度、时间条件和资料类型。对于一份长文档，返回结果还应保留文档名称、章节位置、发布时间或其他可定位信息，否则模型即使生成了正确结论，也很难把引用准确地对应回原文。

第三层是证据重排。召回内容需要按“是否直接回答问题、来源是否适配、内容是否完整、时间是否匹配”重新排序。与问题只有概念相似、但没有明确事实支撑的段落，不应因为文字相近就被当作有效证据。

第三步：给每条资料建立可追踪的来源标识

来源引用不能等到生成答案时再临时补充。每条进入上下文的资料，都应在检索阶段绑定一个稳定的来源标识，例如：

[文档01] 文档名称｜章节位置｜来源地址
证据内容：……
适用事实：……
时间信息：……

其中，[文档01] 是回答中使用的引用编号，文档名称、章节位置和来源地址则用于读者回查。编号应在当前回答中保持唯一，不能出现多个不同来源共用同一个编号，也不能让模型自行创造没有进入检索结果的编号。

生成阶段应设置明确约束：

• 每一个可核查的事实后面都必须紧跟对应引用；




• 引用只能使用检索结果中存在的来源标识；




• 如果一条陈述由多个来源共同支撑，应同时列出这些来源；




• 来源只说明“资料在哪里”，不能自动证明资料内容一定正确；




• 检索结果没有覆盖的问题，必须明确说明现有资料不足。

这种约束比“请尽量引用来源”更有效，因为它把引用变成输出格式中的必需部分。阿里云深度搜索资料中的示例也采用了每个事实使用文档编号引用的方式，可作为设计引用格式的参考。

第四步：增加独立的事实验证环节

最容易被忽略的是：检索器找到了资料，不代表生成模型已经正确理解资料。事实核查应当独立于最终回答，至少检查三类问题。

检查事实是否真的被证据支持

验证模块可以逐句读取候选答案，并把每句话拆成最小事实单元。例如：

“方案甲更适合小团队，因为部署简单、维护成本较低。”

这句话实际上包含“适合小团队”“部署简单”“维护成本较低”三个判断。验证时要分别查找证据，而不能因为第一部分有依据，就默认整句话都成立。

如果证据只说明“部署流程较少”，就不能直接扩写成“维护成本较低”；如果资料只描述了产品能力，也不能据此推导出适用于所有小团队。

检查引用是否准确对应

验证模块需要判断引用内容与事实之间的关系：

• 直接支持：原文明确说明了该事实；




• 部分支持：只能支持事实中的一部分；




• 间接相关：主题相关，但不能证明该结论；




• 相互冲突：不同来源给出了不一致的信息；




• 没有支持：检索结果中找不到对应依据。

只有“直接支持”的内容，才适合以确定语气输出。部分支持应缩小表述范围，间接相关和没有支持的内容应删除或改成不确定说明。

检查来源之间是否冲突

多来源检索的价值不只是增加资料数量，也在于发现差异。不同文档可能面向不同版本、地区、用户群或使用条件。遇到冲突时，不要让模型自行投票选出一个答案，而应保留冲突，并进一步查看时间、适用范围和来源层级。

如果无法判断哪条资料更可靠，可以写成：“现有资料存在差异，分别指出了两种情况，暂时不能据此得出唯一结论。”这比强行给出一个确定答案更符合事实核查的目标。

一个实用的智能体流程

可以把整个工作流设计为以下闭环：

用户问题
  ↓
问题理解与澄清
  ↓
拆分为待核查事实
  ↓
选择资料范围与检索路径
  ↓
召回候选文档
  ↓
证据筛选与来源编号
  ↓
生成候选答案
  ↓
逐句核查事实与引用
  ↓
修正、删除或标记不确定内容
  ↓
输出最终答案与来源

这里的“修正”不应只让同一个生成步骤重新润色。更稳妥的做法是让验证模块返回具体问题，例如“第3句缺少直接证据”“第5句引用只能支持时间条件”“文档01与文档03存在范围差异”，再把这些反馈交给答案生成模块处理。

对于复杂问题，还可以增加一个规划模块，决定是否需要继续检索、是否需要换一种查询方式，或者是否应该先向用户澄清条件。阿里云资料将自主规划、搜索和答案校正作为不同的智能体职责，说明复杂检索任务并不适合由一个模型调用一次完成。

不要把“无法回答”当成失败

事实核查型智能体最重要的能力之一，是知道什么时候不能回答。以下情况都应触发保守输出：

• 检索结果没有覆盖用户询问的关键事实；




• 资料只提供背景介绍，没有给出用户要求的结论；




• 不同来源之间存在未解决的冲突；




• 用户问题缺少必要的时间、对象或范围条件；




• 候选答案中的某句话无法绑定有效引用。

可以将回答分为三种状态：证据充分、证据部分充分、证据不足。证据部分充分时，只回答能够被支持的部分；证据不足时，说明缺少什么资料，并给出下一步需要补充的条件。不要用模型的常识填补空白，也不要把“听起来合理”当作事实。

如何判断这套流程是否真的有效

测试智能体时，不要只准备能顺利回答的问题。更有价值的是建立一组专门的反向测试：

1. 资料库中明确存在答案的问题；




2. 资料库中只有部分答案的问题；




3. 资料库完全没有答案的问题；




4. 多份资料说法不一致的问题；




5. 用户问题包含模糊时间或对象的问题；




6. 检索到相关主题但无法直接支撑结论的问题。

检查结果时，重点看四件事：回答是否引用了真实来源，引用是否真的支持对应句子，无法确认时是否主动收缩结论，以及资料冲突时是否保留差异。不要只评价文字是否流畅，因为一篇没有证据链的流畅回答，反而更容易让读者误信。

真正可靠的检索智能体，不是“回答得像专家”，而是能够让读者看清答案从哪里来、哪些内容已经核对、哪些地方仍然不能确定。把问题拆解、证据检索、来源编号、逐句验证和不确定性处理串成闭环，才是比简单提示词更稳妥的防止 AI 幻觉方案。