别再瞎猜了,开始规划吧: 蓝图如何解决 LLM 幻觉问题
我们都见过这种情况。你让大型语言模型 (LLM) 写一篇关于小众作家的传记,或者总结最近的新闻事件。输出看起来很完美——语法无懈可击,语气权威,结构逻辑严密。但仔细一看,你就会发现模型编造了一个作者从未获得的大学学位,或者引用了一个不存在的奖项。
这种现象被称为幻觉 (Hallucination) 。 它的出现是因为 LLM 是概率引擎,而不是数据库。当它们触及内部 (参数化) 记忆的极限时——通常是因为话题冷门或事件太新——它们会用统计上看似合理但实际上错误的信息来填补空白。
在谷歌和马萨诸塞大学阿默斯特分校的研究人员最近发表的一篇题为 “Analysis of Plan-based Retrieval for Grounded Text Generation” (基于规划的检索用于有据可查的文本生成分析) 的论文中,提出了一个令人信服的解决方案。他们认为,修复幻觉的关键不仅仅是让模型访问谷歌搜索,而是教模型在写下一个字之前先规划其研究过程。
在这篇文章中,我们将解构他们的方法,探讨为什么“规划”是检索增强生成 (RAG) 中缺失的一环,并分析实证证据,看看这种方法如何带来更值得信赖的 AI。
问题: 自信陷阱
为了理解问题的严重性,我们来看看论文开头的例子。当 Falcon 180B 模型被要求为作家 Lorrie Moore 写传记时,它生成了一段令人信服的段落。它列出了她的出生年份、教育背景和奖项。
问题出在哪?几乎所有的具体细节都是错的。它声称她出生在肯塔基州的格拉斯哥 (她出生在纽约) ,并在威斯康星大学获得艺术硕士学位 (她去的是康奈尔大学) 。
这就是“自信陷阱”。模型生成的文本看起来是对的,因为它模仿了传记的风格,但它未能将文本建立在现实基础之上。
标准检索的局限性
对此的标准修复方法是检索增强生成 (Retrieval Augmented Generation, RAG) 。 在典型的 RAG 设置中,系统接收用户的提示 (例如,“为 Lorrie Moore 写传记”) ,运行网络搜索,将排名靠前的搜索结果粘贴到模型的上下文窗口中,并指示说: “使用这些结果来回答用户。”
虽然这有所帮助,但研究人员发现这对于长篇写作来说是不够的。一次通用的搜索往往无法捕捉到全面传记所需的细粒度细节。它可能会找到一个概括性的维基百科摘要,但会遗漏关于早年生活、特定文学主题或完整奖项列表的具体细节。
解决方案: 基于规划的检索
这项研究的核心贡献是一种模仿人类研究员工作流程的方法。如果你要写一篇传记,你不会只在搜索引擎中输入一个名字然后复制第一个结果。你会:
- 列大纲 : 确定你要写的部分 (早年生活、职业生涯、奖项) 。
- 提出具体问题 : 针对每个部分提出问题。
- 研究 : 针对这些具体问题进行搜索。
- 撰写 : 根据找到的答案编写内容。
研究人员在 LLM 中实现了这个确切的工作流程。
架构
如下图所示,该方法将生成过程分解为不同的步骤。

让我们分解 图 1 中显示的流程:
- 初始提示与搜索 : 用户要求写传记。系统进行快速、高层次的搜索以获取基本上下文。
- QA 规划生成 : 提示模型创建一个“蓝图”。例如,它决定第 1 段应涵盖早年生活,第 2 段涵盖写作风格,第 3 段涵盖奖项。
- 问题生成 : 对于计划中的每一段,模型生成具体的搜索查询 (例如,“Lorrie Moore 出生在哪里?”,“Lorrie Moore 获得了什么奖项?”) 。
- 细粒度检索 : 系统针对这些具体问题执行搜索,收集有针对性的证据。
- 有据生成 : 最终答案是利用蓝图和找到的具体答案生成的。
这种方法将 LLM 从被动的文本预测器转变为主动的研究者。
处理“无法回答”的问题
这种方法最巧妙的地方之一是它处理缺失信息的方式。在问答 (QA) 阶段,如果检索系统无法为生成的问题找到确信的答案 (例如,“Lorrie Moore 最喜欢的颜色是什么?”) ,系统将其标记为无法回答 。
在最终提示中,模型被明确告知不要通过编造来回答缺乏证据的问题。这个简单的步骤——承认无知——大大降低了模型胡编乱造的频率。
实验设置
为了测试这一假设,作者在四个不同的数据集上将他们的“基于规划的检索”与标准方法进行了比较:
- Wiki-Ent (头部) : 拥有维基百科页面的热门实体。
- Wiki-Event (头部) : 著名的历史事件。
- Researcher (长尾) : 一个包含 106 名研究人员的挑战性数据集,这些研究人员虽然知名但没有维基百科页面。这测试了模型处理“长尾”知识的能力。
- News Events (时效性) : 发生在模型训练截止日期之后的突发新闻事件。
他们使用 AIS (Attributable to Identified Sources,可归因于已识别来源) 来评估模型。该指标会检查模型生成的每一个句子,并验证其是否得到检索文档的支持。
关键结果
结果是决定性的: 规划显著优于标准检索。
1. 卓越的归因能力
下表显示了使用 text-unicorn 模型 (一种大型、能力强的 PaLM-2 变体) 的性能。

观察 表 2 , 请注意“AIS Strict”一列 (这要求输出中的每一个句子都有证据支持) :
- No Retrieval (无检索) : 得分接近 0.00 。 没有外部数据,模型几乎总是会产生至少一个细节上的幻觉。
- One-Retrieval (标准 RAG) : 得分在 60-68% 左右。好了一些,但仍然容易出错。
- Plan-based Retrieval (基于规划的检索,变体 A & B) : 跃升至 80-88% 。
这是一个巨大的进步。仅仅通过结构化检索过程,研究人员就大大降低了幻觉率。即使他们将标准 RAG 方法的搜索片段数量增加一倍 (“2x snippets”) ,它仍然无法击败基于规划的方法。这证明了如何搜索比搜索多少更重要。
2. “思维链”大纲的力量
大纲真的有必要吗?我们能不能直接让模型生成问题?
研究人员进行了一项消融研究来找出答案。他们将完整方法与跳过“段落大纲”步骤、直接生成搜索问题的版本进行了比较。

如 表 5 所示,“w/o plan” (无计划) 版本的严格归因分数显著下降 (从 87.18 降至 68.59 )。
这支持了“思维链” (Chain of Thought) 理论: 强迫模型首先阐明一个高层次的计划 (蓝图) ,有助于它在随后生成更好、更相关的问题。规划步骤充当了认知支架,确保搜索查询全面且逻辑有序。
3. 质量提升
除了数字之外,基于规划的方法还能产生更好的内容。它避免了标准 RAG 中经常出现的“重复拼接”,即模型只是将搜索片段拼凑在一起。

图 2 以“2023 年约翰内斯堡建筑火灾”为例说明了这一点。
- One-Retrieval (标准) : 模型产生幻觉,称火灾始于“二楼”。
- Plan-based Retrieval (基于规划) : 模型在规划阶段明确询问了“起火原因是什么?”和“起火点在哪里?”。检索结果显示起火原因未知。因此,基于规划的生成正确地指出原因正在调查中,避免了幻觉。
4. 人类偏好
这种严格的事实核查会让文本变得枯燥或机械吗?令人惊讶的是,并没有。

在一次正面对决的人类评估中( 表 9 ),标注者发现基于规划的生成在约 55% 的时间里信息量更大 , 同时保持了同等的流畅性。因为模型规划了其内容,所以比起简单总结排名靠前的搜索结果的模型,它涵盖的范围更广,提供的细节更丰富。
泛化能力: 在开源模型上也有效
对此类论文的一个常见批评是,它们只适用于像 Google PaLM 或 OpenAI GPT-4 这样的专有巨型模型。为了解决这个问题,作者在流行的开放权重模型 Mistral-7B-Instruct 上测试了他们的方法。

表 7 显示,即使对于较小的开放模型,这些优势依然存在。基于规划的检索 (变体 B) 获得了 25.0 的严格 AIS 分数,显著高于标准单次检索的 11.7 分。对于希望实现有据生成系统而不想完全依赖大型 API 模型的学生和开发者来说,这是令人鼓舞的。
为什么第二次搜索很重要?
你可能会问: 系统真的需要搜索两次网络吗? (一次用于初始上下文,另一次用于具体问题) 。
数据显示是的。

表 3 将完整方法与规划了问题但仅尝试使用初始搜索结果来回答这些问题的版本 (“w/o 2nd search”) 进行了比较。当移除第二次搜索时,归因分数下降了。
这证实了“规划”步骤不仅仅是为了整理思路;它是关于信息发现的。初始的广泛搜索根本不包含回答具体问题 (如“受试者哪一年毕业?”或“事件的原因是什么?”) 所需的具体细节。该计划指导检索器找到原本会被遗漏的信息。
结论与启示
论文《基于规划的检索用于有据可查的文本生成分析》为可靠 AI 写作的未来提供了清晰的路线图。对于任何构建 RAG 系统的人来说,这些要点都很重要:
- 不要只检索,要规划 : 对于复杂的主题,简单的“搜索 \(\rightarrow\) 生成”循环是不够的。添加“规划 \(\rightarrow\) 提问 \(\rightarrow\) 搜索”循环可以显著提高可靠性。
- 明确处理未知 : 设计能够识别并标记“无法回答”问题的系统是抵御幻觉的有力防线。
- 结构胜于数量 : 更好的提示和结构化的工作流程往往比简单地增加检索文档的数量能产生更好的结果。
随着我们迈向能够进行研究和撰写报告的 AI 代理,像基于规划的检索这样的方法让我们远离“随机鹦鹉” (stochastic parrots) ,转向能够推理、研究并真正权威地引用其来源的系统。
](https://deep-paper.org/en/paper/2408.10490/images/cover.png)