Lazy loaded image
人工智能
理解 RAG-3
字数 4500阅读时长 12 分钟
2025-9-9
2025-10-4
type
status
date
slug
summary
tags
category
icon
password
Description

缓解 RAG 中的幻觉

在可能阻碍语言模型性能的各种问题和挑战中,幻觉(hallucinations)经常名列前茅。幻觉是指语言模型生成虚假、误导性或无意义的信息。在检索增强生成(RAG)系统中,语言模型通过检索和整合外部信息来提高事实依据,虽然这个问题得到了缓解,但并未完全消除。
在本期“理解 RAG”系列文章中,我们将探讨幻觉问题,它们在 RAG 系统中与独立语言模型相比是如何表现的,以及最重要的是,如何应对这一挑战。

为什么 RAG 系统中的幻觉仍然存在

正如本系列文章开头所讨论的,RAG 系统相较于传统语言模型的主要优势之一是能够通过检索和整合事实准确的信息来减少幻觉,但幻觉仍可能出于多种原因出现。事实上,它们仍然是 RAG 系统中最严峻的挑战之一,特别是那些检索准确性有限或知识库质量不足的方法。
RAG 系统中仍然可能出现幻觉的一个原因很简单:如果检索到的数据包含错误,生成的响应也可能不正确或具有误导性。在依赖知识库(通常是文档语料库,有时也包括结构化数据库)的 RAG 系统中,数据由人工录入、传感器收集等,其中包含错误或不准确的条目并不少见。当 RAG 的检索器优先处理或误解这些“损坏”的数据条目或文档时,幻觉的风险就会增加。文档或数据库中错误录入的人名,足以触发“幻觉表演”,如果用户向 RAG 系统查询与该人相关的信息……如果用户就是那个人,情况会更糟!
另一个问题出现在检索到的信息缺乏足够细节或关键的上下文细微差别,从而导致无法正确解读。例如,银行聊天机器人 RAG 系统的检索器可能会在响应客户咨询时检索到有关抵押贷款条件的信息。然而,如果客户有残疾或特殊身份,符合享受额外福利的资格,而检索器未能检索到这些特定信息,生成的响应可能会遗漏对客户至关重要的机会。这不仅会导致错误信息,还可能导致糟糕的用户体验,从而可能将客户推向竞争对手。
在这两种情况下,生成器(RAG 系统中的语言模型)都会尝试根据不完整或误导性的数据构建响应,从而导致不可靠或不准确的输出。

缓解 RAG 系统中的幻觉

从广义上讲,我们可以识别和归类三种策略或关注点来缓解 RAG 系统中的幻觉:数据、上下文以及检索器和生成器中的 AI 与推理过程。

与数据相关的缓解策略

减少幻觉的关键在于确保检索器使用的知识库中的数据质量高且经过精心策划。如果检索到的文档包含错误、不精确的条目、过时的信息或偏见,生成器可能会给出误导性或不正确的回答。为了提高可靠性,策略包括严格的数据策划、持续系统地更新知识库、自动事实核查方法以及过滤掉低质量或不相关的来源。

与上下文相关的缓解策略

即使在数据质量和准确性得到提升的情况下,如果模型未能完全捕捉用户的意图或检索到所有相关信息,仍然可能出现幻觉。为了解决这个问题,侧重于改进上下文的策略包括优化检索技术、使用查询扩展进行更精细的搜索、应用重排模型来优先处理与特定场景最相关的文档,以及采用高级提示工程技术。这些策略有助于提高检索信息和上下文的相关性,从而为传递给生成器的最终提示提供坚实的上下文基础。

AI 与推理过程相关的缓解策略

最后,即使拥有结构良好的上下文和高质量的数据,语言模型的推理过程仍可能导致幻觉。为了应对这一最终挑战,常见的策略包括使用指令遵循数据集(旨在帮助语言模型理解和遵循明确指令的训练实例集合)对模型进行微调、融入逻辑推理和常识推理技术、利用事实核查 API 等外部验证工具,以及在 RAG 工作流中集成多步推理框架,以产生更连贯、更精确的响应。
缓解
主要关注点
关键策略与技术
益处/结果
数据
策划和维护高质量数据
严格的数据整理、持续更新、自动化事实核查、过滤低质量来源
减少过时或不准确信息导致的错误;提高事实依据的准确性
上下文
捕获用户意图并增强检索细节
优化检索方法、查询扩展、重排模型、高级提示工程
提高检索信息的相关性和完整性
AI 与推理
优化模型决策与推理
使用指令数据集、逻辑和常识推理、多步框架、外部验证工具进行微调
缓解固有的模型幻觉,产生更连贯的响应
幻觉是当今基于语言模型的 AI 系统中的一个关键问题,尽管 RAG 系统在一定程度上解决了这个问题,但它们也并非例外。本文在 RAG 的背景下讨论了幻觉问题,重点阐述了在检索外部信息后再生成响应的系统中,该问题仍可能发生的原因,并确定了几种可以在 RAG 系统、数据库和知识库中实施以缓解这些问题的实用策略。

为 RAG 微调 LLMs

我们学习了如何管理传递给 LLM 的上下文长度,如何优化检索,以及向量数据库和索引策略如何有效检索知识。
这一次,我们将注意力转移到生成器组件,即 LLM,通过研究如何在 RAG 系统中 微调 LLM(以及何时进行微调),以确保其响应保持连贯、事实准确并与领域特定知识保持一致。
在深入了解作为 RAG 系统一部分的 LLM 微调的细微差别之前,让我们回顾一下“传统”或独立 LLM 的微调概念和过程。

什么是 LLM 微调?

就像新买的手机会通过个性化设置、应用和装饰外壳来适应主人的喜好和个性一样,对现有的(且经过预先训练的)LLM 进行微调,就是使用额外的、专门的训练数据调整其模型参数,以增强其在特定用例或应用领域中的性能。
微调是 LLM 开发、维护和重用的重要组成部分,原因有二:
  • 它允许模型适应更具领域特异性、通常更小的数据集,从而提高其在法律、医疗或技术等专业领域的准确性和相关性。请参阅下图中的示例。
  • 它确保 LLM 能够跟上不断发展的知识和语言模式,避免出现信息过时、幻觉或与当前事实和最佳实践不符等问题。
LLM fine-tuning
LLM 微调
通过定期微调 LLM 的全部或部分参数来保持其更新的缺点是,正如您可能猜到的,成本很高,这既包括获取新训练数据,也包括所需的计算资源。RAG 有助于减少对持续 LLM 微调的需求。然而,在某些情况下,为 RAG 系统微调底层 LLM 仍然是有益的。

RAG 系统中的 LLM 微调:为什么以及如何做?

虽然在某些应用场景中,检索器提取相关、最新的信息以构建准确上下文的工作足以满足需求,无需定期重新训练 LLM,但在更具体的情况下,这并不足够。
一个例子是当你的 RAG 应用需要对 专业术语或领域特定推理 有非常深入和雄心勃勃的理解,而这些内容并未包含在 LLM 的原始训练数据中。这可能是一个医学领域的 RAG 系统,它在检索相关文档方面可能做得很好,但 LLM 在被针对包含有用的信息来吸收这种领域特定推理和语言解释机制的特定数据集进行微调之前,可能难以正确解释输入中的知识片段。
对 RAG 系统的 LLM 进行均衡的微调频率也有助于提高系统效率,例如通过减少过多的 token 消耗,从而避免不必要的检索。
从 RAG 的角度来看,LLM 微调是如何进行的?虽然大多数经典的 LLM 微调方法也可以应用于 RAG 系统,但有些方法在这些系统中特别受欢迎且有效。

领域自适应预训练 (DAP)

尽管其名称如此,DAP 仍可作为 RAG 中通用模型预训练与基础 LLM 特定任务微调之间的中间策略。它通过利用特定领域的语料库,使模型能够更好地理解某个领域,包括行话、写作风格等。与传统的微调不同,它可能仍会使用相对较大的数据集,并且通常在将 LLM 与 RAG 系统的其余部分集成之前完成,之后再对较小的数据集进行更专注、更具体的任务微调。

检索增强微调

这是一种有趣且更具 RAG 特色的微调策略,其中 LLM 会针对结合了检索到的上下文(增强的 LLM 输入)和期望响应的示例进行专门再训练。这使得 LLM 更擅长利用和优化地使用检索到的知识,生成能更好地整合该知识的响应。换句话说,通过这种策略,LLM 能更熟练地正确使用其所依赖的 RAG 架构。

混合 RAG 微调

这种方法也被称为混合指令-检索微调,它将传统的指令微调(通过向 LLM 展示指令-输出对的示例来训练其遵循指令)与检索方法相结合。在这种混合策略使用的数据集中,两种类型的示例并存:有些包含检索到的信息,而另一些包含指令遵循信息。结果呢?一个更灵活的模型,能够更好地利用检索到的信息,并且也能正确地遵循指令。

生产环境中的 RAG 管道

管道在部署软件中起着核心作用,因为它们有助于在生产环境中自动化和协调多项任务,从而保证数据和流程的顺畅。在检索增强生成 (RAG) 应用等高级系统的背景下,生产环境中的管道具有更重要的意义。它们对于在管理复杂工作流程的同时,保持合理的效率、可扩展性、组件之间的一致性和可靠性至关重要。
本部分“理解 RAG 系列”将重点讨论生产环境中 RAG 管道的关键特征,并区分三种类型的管道: 索引管道  检索管道生成管道 。每种管道类型在整个 RAG 架构中都有其作用,了解它们如何交互对于优化性能以及确保系统产生及时、相关且事实准确的结果至关重要。
在下面描述三种 RAG 管道的过程中,我们将探讨此可视化图表中显示的元素:
RAG production pipelines
RAG 生产流水线

索引流水线

RAG 系统中索引流水线的目的是收集、处理和存储文档到向量数据库中,以便高效检索。简单来说,索引流水线负责 RAG 系统的文档数据库。
为此,它依赖于以下组件:
  • 用于收集和加载多种格式(如 PDF、网页等)文档的文档加载器。
  • 文本分块策略,用于确保长文档能够以可管理的大小集成到向量数据库中。这些策略包括重叠设置,以保持同一文档中不同文本块之间的语义关系。
  • 数据预处理工作流,用于对文档相关数据应用清理、过滤和去重等步骤。
  • 嵌入模型,用于将文本转换为数值向量表示或嵌入。
  • 用于存储文档以供将来检索的向量数据库
  • 文档元数据提取方法。
这些组件在前面图示的“索引管道”块中按顺序表示。索引管道如何与 RAG 系统中的其他管道交互?您可能已经猜到,该管道在应用了某些基于相似性的搜索后,会将处理和存储的文档提供给检索管道。管道中的过程必须与检索策略以一致和协调的方式设计:例如,分块方法和设置通常会影响检索质量。索引管道的良好维护策略必须支持增量更新,以便随时提供最新数据。

检索管道

检索管道负责在每次用户提交查询时,从向量数据库中查找并提取最相关的上下文。它直接与其他两个 RAG 管道——索引管道和生成管道——进行通信,其组件包括:
  • 查询理解与预处理:在处理查询之前,可以使用一个更简单的、专注于语言理解任务(如意图识别或命名实体识别(NER))的语言模型,以便在预处理原始查询之前更好地理解它。
  • 查询转换机制,如查询扩展、分解等。
  • 相似性搜索算法是 RAG 系统检索器和该管道的关键部分。通过与向量数据库交互,并与索引管道进行协调,可以使用余弦相似度或欧几里得距离等相似性度量来查找与处理后的查询最相关的已存储文档。此处可以使用缓存层来高效管理频繁查询。
  • 如果我们实现重排策略,重排机制也成为该管道的一部分。
  • 基于元数据的上下文过滤或选择,以从检索到的文档中选择最相关的信息。
通过整合混合搜索功能,如语义搜索和基于关键字的搜索,可以进一步增强此管道。
在交互方面,检索管道消耗来自索引管道的数据,并将其构建的检索到的上下文发送到控制 RAG 系统语言模型的生成管道。它还可以向索引管道提供反馈以优化其操作。

生成管道

该管道的目标是利用语言模型和检索管道构建的检索到的上下文来创建连贯、准确的响应。其关键组件或阶段包括:
  • 提示工程和模板化,以准备上下文作为语言模型的输入。
  • 上下文窗口管理在处理长上下文等场景下是必要的,以确保相关信息能够被纳入语言模型的限制范围内,例如输入令牌长度。
  • LLM 选择和配置在实际的 RAG 应用中至关重要,这些应用通常有几个针对特定任务(如摘要、翻译或情感分析)进行微调的模型。
  • 响应验证程序,用于验证和后处理原始生成的输出。
  • 响应格式化和结构化,以便呈现给最终用户。
生成管道接收来自检索管道的相关上下文,并作为向用户提供响应的最后阶段。它可以包含基于与其他组件交互的反馈循环,以促进持续改进。