通过

Azure AI 搜索中的检索增强生成 (RAG)

检索增强生成（RAG）是一种通过基于专有内容生成的响应来扩展 LLM 功能的模式。 虽然从概念上讲很简单，但 RAG 实现面临重大挑战。

RAG 的挑战

挑战 Description
查询理解 现代用户在假定上下文的基础下，询问复杂、对话式或模糊的问题。 当查询与文档术语不匹配时，传统关键字搜索将失败。 对于 RAG，信息检索系统必须理解意向，而不仅仅是匹配字词。
多源数据访问 企业内容跨越 SharePoint、数据库、Blob 存储和其他平台。 在不中断数据作的情况下创建统一的搜索库至关重要。
令牌约束 LLM 接受有限的令牌输入。 检索系统必须返回高度相关且只是简洁的结果，而不是海量文档。
响应时间预期 用户需要 AI 支持的答案（以秒为单位，而不是分钟）。 检索系统必须在彻底性与速度之间做出平衡。
安全性和治理 向 LLM 打开专用内容需要精细的访问控制。 用户和代理只能检索授权的内容。

Azure AI 搜索如何应对 RAG 挑战

Azure AI 搜索提供了两种专为这些 RAG 挑战而设计的方法：

  • 代理检索 （预览版）：一个完整的 RAG 管道，其中包含 LLM 辅助查询规划、多源访问和针对代理消耗优化的结构化响应。

  • 经典 RAG 模式：采用混合搜索和语义排名的成熟方法，最适合较简单的需求或需要普遍可用（GA）功能的情况。

以下各节介绍了每个方法如何解决特定的 RAG 挑战。

解决查询理解难题

问题： 用户询问“2023年后雇用的远程工人的带薪休假政策是什么？”，但文件中称“休假”、“远程工作”和“最近入职的员工”。

代理检索解决方案：

  • LLM 分析问题并生成多个目标子查询
  • 将复杂问题分解为重点搜索
  • 使用对话历史记录来了解上下文
  • 跨知识源并行执行

经典 RAG 解决方案：

  • 混合查询结合了关键字和矢量搜索，以提高检索效果
  • 语义排名基于含义重新评分结果，而不仅仅是关键字
  • 矢量相似性搜索匹配概念，而不是确切的术语

详细了解查询规划。

解决多源数据难题

问题：在 SharePoint 中的人力资源政策、数据库中的福利、网页上的公司新闻——创建副本会中断治理和日常数据操作。

代理检索解决方案：

  • 知识库统一多个知识库
  • 针对远程 SharePoint 和必应（无需索引）进行直接查询以补充索引内容
  • 检索说明将 LLM 引导到适当的数据源
  • 生成适用于 Azure Blob、OneLake、已引入的 SharePoint 内容和其他外部内容的自动索引管道
  • 跨所有源的单一查询接口和查询计划

经典 RAG 解决方案：

  • 索引器从 10 多个 Azure 数据源拉取
  • 用于分块、矢量化、图像语言化和分析的技能管道
  • 增量索引使内容保持最新
  • 你可以控制被索引的内容和方式

详细了解知识源。

解决令牌约束挑战

问题： GPT-4 接受约 128k 个令牌，但有 10,000 页的文档。 发送所有内容会浪费令牌并降低质量。

代理检索解决方案：

  • 返回仅包含最相关的区块的结构化响应
  • 内置引文跟踪显示来源
  • 查询活动日志说明搜索的内容
  • 可选答案合成进一步减少令牌使用

经典 RAG 解决方案：

  • 语义排名标识最相关的前 50 个结果
  • 可配置的结果限制（矢量的前k项、文本的前n项）及最小阈值
  • 评分配置可提升重要内容
  • Select 语句控制返回哪些字段

详细了解相关性优化。

解决响应时间挑战

问题： 用户需要 3-5 秒的答案，但你正在查询具有复杂处理的多个源。

代理检索解决方案：

  • 并行子查询执行（非顺序）
  • 可调整推理工作量（最小/低/中）
  • 预建语义排序（无额外编排）

经典 RAG 解决方案：

  • 毫秒查询响应时间
  • 单次查询可降低复杂性
  • 您控制超时和重试逻辑
  • 具有较少故障点的更简单的体系结构

解决安全挑战

问题： 财务数据只能供财务团队访问，即使高管要求聊天机器人也是如此。

代理检索解决方案：

  • 知识源级访问控制
  • 继承针对远程 SharePoint 的查询的 SharePoint 权限
  • 从 Azure 存储中为已索引内容继承 Microsoft Entra ID 权限元数据
  • 在查询其他数据源时的基于过滤器的安全性
  • 通过专用终结点进行网络隔离

经典 RAG 解决方案：

  • 文档级安全修整
  • 从 Azure 存储中为已索引内容继承 Microsoft Entra ID 权限元数据
  • 在查询其他数据源时的基于过滤器的安全性
  • 通过专用终结点进行网络隔离

详细了解安全性。

现代 RAG，具有自主检索功能

Azure AI 搜索是 适用于 RAG 工作负载的经过验证的解决方案。 现在，它提供 自主检索，这是专为 RAG 模式设计的专用管道。 此方法使用 LLM 将复杂的用户查询智能分解为重点子查询，并行执行这些查询，并返回针对聊天完成模型优化的结构化响应。

代理检索表示从传统的单查询 RAG 模式到多查询智能检索的演变，提供：

  • 使用对话历史记录进行上下文感知查询规划
  • 并行执行多个重点子查询
  • 具有基于数据、引文和执行元数据的结构化响应
  • 内置语义排名以实现最佳相关性
  • 可选答案合成，该合成在查询响应中使用 LLM 表述的答案。

需要为此管道配置新对象：一个或多个知识源、知识库，以及在应用程序代码中调用的检索操作，例如与 AI 代理配合使用的工具。

对于新的 RAG 实现，建议从 代理检索开始。 对于现有解决方案，请考虑迁移以利用改进的准确性和上下文理解。

经典 RAG 使用 原始查询执行体系结构 ，应用程序将单个查询发送到 Azure AI 搜索，并单独安排向 LLM 移交。 部署的 LLM 使用查询中的扁平化结果集来生成答案。 这种方法更简单，组件更少，而且速度更快，因为没有 LLM 参与查询规划。

有关实现经典 RAG 的详细信息，请参阅 azure-search-classic-rag 存储库。

RAG 内容的准备

RAG 质量取决于您如何准备内容以进行检索。 Azure AI 搜索支持：

内容挑战 Azure AI 搜索的帮助方式
大型文档 自动分块（内置或通过技能）
多种语言 适用于文本、多语言矢量的 50 多种语言分析器
图像和 PDF OCR， 图像分析， 图像语言化， 文档提取技能
需要相似性搜索 集成矢量化（Azure OpenAI、Azure AI 视觉、自定义）
术语不匹配 同义词映射，语义排名

对于代理检索： 使用自动生成分块和矢量化管道 的知识源 。

对于经典 RAG： 使用 索引器和技能集 生成自定义管道，或通过 推送 API 推送预处理的内容。

最大化相关性和召回率

如何为 LLM 答案表述提供最佳基础数据？ 它是具有适当的内容、智能查询和查询逻辑的组合，可以识别用于回答问题的最佳区块。

在编制索引期间，使用分块对大型文档进行细分，以便可以独立匹配部分。 包括一个向量化步骤，以创建用于矢量查询的嵌入。

在查询方面，为确保您的 RAG 实现获取最相关的结果：

  • 使用混合查询，结合关键字（非向量）和向量搜索，以实现最大召回率。 在混合查询中，如果对相同的输入加倍，则文本字符串及其矢量等效项将生成关键字和相似性搜索的并行查询，并在统一的结果集中返回每种查询类型最相关的匹配项。

  • 语义排名内置于代理检索中，对于经典的 RAG 是可选的。

  • 应用计分配置文件以提升特定数据字段或标准。

  • 使用矢量查询参数微调 矢量权重 和 最小阈值。

详细了解 混合搜索 和 语义排名。

在代理检索和经典 RAG 之间进行选择

在以下情况下使用代理检索：

  • 客户端是代理或聊天机器人
  • 需要尽可能高的相关性和准确性
  • 您的查询是复杂或对话型的
  • 需要包含引文和查询详细信息的结构化响应
  • 你正在构建新的 RAG 实现

在以下情况下使用经典 RAG：

  • 仅需要通用发布版 (GA) 功能
  • 简单性和速度优先于高级相关性
  • 你有要保留的现有编排代码
  • 需要对查询管道进行精细控制

包含代理和 Azure AI 搜索的 RAG 解决方案可以从 Foundry IQ 中受益，作为代理的单一终结点到提供基础数据的知识层。 Foundry IQ 使用代理检索。

详细了解 经典搜索、 代理检索及其 比较方式。

如何开始使用

有许多方法可以开始，包括代码优先解决方案和演示。

  • Last updated on