你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
检索增强生成 (RAG) 是一种设计模式，通过添加信息检索步骤来增强 ChatGPT 等聊天补全模型的能力，整合专属企业内容来生成答案。 对于企业解决方案，可以将生成式 AI 完全限制在企业内容范围内。
决定使用哪种信息检索系统至关重要，因为它将决定对 LLM 的输入。 信息检索系统应提供：
按所需频率为所有内容进行大规模加载和刷新的索引策略。
查询功能和相关性优化。 系统应以满足大型语言模型（LLM）输入的令牌长度要求所需的短格式返回 相关 结果。 查询处理时间应尽量缩短。
数据和操作的安全性、全球影响力和可靠性。
与用于索引编制的嵌入模型以及用于检索的聊天模型或语言理解模型集成。
Azure AI 搜索是 RAG 体系结构中一种可靠的信息检索解决方案。 它提供索引和查询功能，并且具有 Azure 云的基础设施和安全性。 通过代码和其他组件，你可以设计一项全面的 RAG 解决方案，其中包括基于专有内容的生成式 AI 的所有元素。
可以在 RAG 工作负载的两种方法之间进行选择：代理检索，或经典 RAG 的原始查询体系结构。
Note
不熟悉 Copilot 和 RAG 概念？ 观看生成式 AI 应用的矢量搜索和先进检索。
具有代理检索的新式 RAG
Azure AI 搜索现在提供 代理检索，这是专为 RAG 模式设计的专用管道。 此方法使用大型语言模型将复杂的用户查询智能分解为重点子查询，并行执行它们，并返回针对聊天完成模型优化的结构化响应。
代理检索表示从传统的单查询 RAG 模式到多查询智能检索的演变，提供：
- 使用对话历史记录进行上下文感知查询规划
- 并行执行多个重点子查询
- 具有依据数据、引文和执行元数据的结构化响应
- 内置语义排名以实现最佳相关性
- 可选答案合成，该合成在查询响应中使用由 LLM 构建的答案。
需要为此管道增加新的对象：一个或多个知识来源、一个知识代理，以及需要从应用程序代码中调用的检索操作，例如一个能够与您的代理配合使用的工具。
对于新的 RAG 实现，建议从 代理检索开始。 对于现有解决方案，请考虑迁移以利用改进的准确性和上下文理解。
Azure AI 搜索的经典 RAG 模式
可以使用原始查询执行体系结构在 Azure AI 搜索上实现 RAG 解决方案。 使用此方法，应用程序会将单个查询请求发送到 Azure AI 搜索，搜索引擎处理请求，并将搜索结果返回到调用方。 没有对 LLM 进行查询规划或答案表述的侧游。 响应中没有查询执行详细信息，仅当索引中有提供父文档名称或页面的字段时，才会将引文内置到响应中。 这种方法更快、更简单，组件更少。 根据应用程序要求，这可能是最佳选择。
基于 Azure AI 搜索构建的经典 RAG 模式的高级摘要如下所示：
- 从用户问题或请求（提示）开始。
- 将其作为查询请求发送到 Azure AI 搜索以查找相关信息。
- 将排名靠前的搜索结果返回到 LLM。
- 使用 LLM 的自然语言理解和推理功能生成对初始提示的响应。
Azure AI 搜索提供 LLM 提示符的输入，但不训练模型。 在传统的 RAG 模式中，没有额外的训练。 LLM 是使用公共数据预训练的，其生成的响应由检索器的信息（在本例中为 Azure AI 搜索）补充。
包含 Azure AI 搜索的 RAG 模式具有下图所示的元素。
- 提供用户体验的应用 UX（Web 应用）
- 应用服务器或协调器（集成和协调层）
- Azure AI 搜索（信息检索系统）
- Azure OpenAI（适用于生成式 AI 和 LLM）
Web 应用提供用户体验，其中提供演示文稿、上下文和用户交互。 用户的问题或提示从此处开始。 输入通过集成层，首先转到信息检索以获取搜索结果，还会转到 LLM 以设置上下文和意向。
应用服务器或业务流程协调程序是协调信息检索和 LLM 之间交接的集成代码。 常见解决方案包括用于协调工作流的 Azure 语义内核 或 LangChain 。 LangChain 与 Azure AI 搜索集成，以便更轻松地将 Azure AI 搜索作为 检索器 包含在工作流中。 其他选项包括 LlamaIndex 和语义内核。
信息检索系统提供可搜索索引、查询逻辑和有效负载（查询响应）。 搜索索引可以包含矢量或非矢量内容。 尽管大多数示例和演示都包含向量字段，但这不是必要的。 查询使用 Azure AI 搜索中的现有搜索引擎执行，该搜索引擎可以处理关键字（或术语）和矢量查询。 该索引根据你定义的架构预先创建，并使用从文件、数据库或存储中获取的内容加载。
LLM 收到原始提示以及 Azure AI 搜索的结果。 LLM 分析结果并制定响应。 如果 LLM 为 ChatGPT，则用户交互可能包含多个会话轮次。 Azure 解决方案最有可能使用 Azure OpenAI，但对此特定服务没有硬性依赖。
Azure AI 搜索中的可搜索内容
在 Azure AI 搜索中，所有可搜索内容都存储在托管于搜索服务上的搜索索引中。 搜索索引专为具有毫秒级响应时间的快速查询而设计，因此其内部数据结构旨在支持该目标。 为此，搜索索引将存储索引内容，而不是整个内容文件（如整个 PDF 或图像）。 在内部，数据结构包括 标记化文本的倒排索引、嵌入的向量索引，以及在需要逐字匹配的情况下使用的未修改纯文本（例如，在筛选器、模糊搜索、正则表达式查询中）。
为 RAG 解决方案设置数据时，可以使用在 Azure AI 搜索中创建和加载索引的功能。 索引包括复制或表示源内容的字段。 索引字段可能是简单的转移（源文档中的标题或描述成为搜索索引中的标题或描述），或者字段可能包含外部过程的输出，例如生成图像的表示形式或文本描述的矢量化处理或技术处理。
你可能知道你想要搜索哪种类型的内容，因此请考虑使用适合每种内容类型的索引功能：
| 内容类型 | 已编制索引为 | Features |
|---|---|---|
| 文本消息 | 令牌，未更改的文本 | 索引器可以从其他 Azure 资源（如 Azure 存储和 Cosmos DB）中拉取纯文本。 你还可以向索引推送任何 JSON 内容。 若要在使用中修改文本，请使用分析器和规范化器在建立索引期间添加词法处理。 如果源文档是可能在查询中使用的丢失的术语，则同义词映射会非常有用。 |
| 文本消息 | 矢量 1 | 可以在索引器管道中对文本执行分块和矢量化处理，或者在外部处理，然后在你的索引中将其作为矢量字段编制索引。 |
| 图像 | 令牌，未更改的文本 2 | OCR 和图像分析的技能可以处理图像以实现文本识别或图像特征。 技能具有索引器要求。 |
| 图像 | 矢量 1 | 可以在索引器管道中对图像进行矢量化处理，或者在外部处理以获得图像内容的数学表示形式，然后在你的索引中将其作为矢量字段编制索引。 可以使用 Azure AI 视觉多模式或 OpenAI CLIP 等开源模型在同一嵌入空间中对文本和图像进行矢量化。 |
1 Azure AI 搜索提供集成的数据分块和矢量化，但必须依赖索引器和技能组。 如果无法使用索引器，Microsoft 的语义内核或其他社区产品/服务可以为你提供全栈解决方案。 有关显示这两种方法的代码示例，请参阅 azure-search-vectors-sample 存储库。
2 图像说明将转换为可搜索文本并添加到索引中。 图像本身不存储在索引中。 技能 是 应用 AI 的内置支持。 对于图像描述和语言化，索引管道对 Azure OpenAI 或 Azure AI 视觉发起内部调用。 这些技能会传递提取的图像传递进行处理，并以文本形式接收由 Azure AI 搜索编制索引的输出。 技能还用于集成数据分块和嵌入。
矢量提供了对不同内容（多个文件格式和语言）的最佳适应性，因为内容以数学表示形式通用表达。 矢量还支持相似性搜索：在与矢量查询最相似的坐标上匹配。 与在标记化术语上匹配的关键字搜索（或术语搜索）相比，相似性搜索更加细致。 如果内容或查询中存在歧义或解释要求，这是更好的选择。
Azure AI 搜索中的内容检索
数据进入搜索索引后，就可以使用 Azure AI 搜索的查询功能来检索内容。
在非 RAG 模式中，查询从搜索客户端进行往返。 提交查询、在搜索引擎上执行查询，然后向客户端应用程序返回响应。 响应或搜索结果仅包含索引中找到的逐字匹配内容。
在经典 RAG 模式中，搜索引擎和 LLM 之间协调查询和响应。 用户的问题或查询会作为提示转发给搜索引擎和 LLM。 搜索结果从搜索引擎返回，然后重定向到 LLM。 返回给用户的响应是生成式 AI，即 LLM 的求和或答案。
在现代代理检索 RAG 模式中，查询和响应与 LLM 集成，以帮助进行查询规划和可选的答案表述。 查询输入可以更加丰富，包括聊天历史记录和用户的问题。 LLM 会确定如何设置子查询，以对索引内容建立最佳覆盖范围。 响应不仅包括搜索结果，还包括查询执行详细信息和源文档。 可选择性地包含答案构建，这在其他模式中通常发生在查询管道之外。
以下是 Azure AI 搜索中用于构建查询的功能：
| 查询功能 | Purpose | 使用原因 |
|---|---|---|
| 代理搜索（预览版） | 多个子查询的并行查询执行管道，返回专为 RAG 工作负荷和代理使用者设计的响应。 查询可以是矢量或关键字搜索。 语义排名可确保子查询的最佳结果包含在最终响应结构中。 这是基于 Azure AI 搜索的 RAG 模式的建议方法。 | |
| 关键字搜索 | 对文本和非矢量数值内容的查询执行 | 全文搜索最适合精确匹配项，而不是相似匹配项。 全文搜索查询使用 BM25 算法排名，并支持通过计分概要文件进行相关性优化。 它还支持筛选器和 facet。 |
| 矢量搜索 | 对矢量字段执行查询以实现相似性搜索，其中查询字符串是一个或多个矢量。 | 矢量可以用任何语言表示所有类型的内容。 |
| 混合搜索 | 合并了以上任意或所有查询技术。 矢量查询和非矢量查询并行执行，并在统一的结果集中返回。 | 在精确度和召回率方面取得的最显著的增益是通过混合查询实现的。 |
| 筛选器和 facet | 仅适用于文本或数字（非矢量）字段。 根据包含或排除条件减少搜索外围应用。 | 提高查询的精准率。 |
构建查询响应
查询的响应向 LLM 提供输入，因此搜索结果的质量是决定成功与否的关键因素。 结果为表格行集。 结果的构成或结构取决于：
- 用于确定响应中包含索引部分的字段。
- 表示索引匹配项的行。
当属性“可检索”时，字段将显示在搜索结果中。 索引架构中的字段定义具有属性，这些属性确定字段是否在响应中使用。 仅在全文或矢量查询结果中返回“可检索”字段。 默认情况下，将返回所有“可检索”字段，但可以使用“选择”指定子集。 除了“可检索”之外，该字段没有限制。 字段可以是任意长度或类型。 对于长度，Azure AI 搜索中没有最大字段长度限制，但 API 请求的大小有限制。
行与查询匹配，按相关性、相似性或两者设置排名。 默认情况下，全文搜索的结果限制为前 50 个匹配项，矢量搜索限制为前 50 个 k 最近邻匹配项。 可以更改默认值，以增加或减少最多 1,000 个文档的限制。 还可以使用top 和skip 分页参数将结果检索为一系列分页结果。
最大化相关性和召回率
处理复杂流程、大量数据和预期的毫秒级响应时，每个步骤都必须增加价值并提高最终结果的质量，这一点至关重要。 在信息检索方面，相关性优化活动可以提高发送给 LLM 的结果的质量。 结果中应尽包含最相关或最相似的匹配文档。
下面是最大化相关性和召回率的一些提示：
结合关键字（非矢量）搜索和矢量搜索的混合查询可以在输入相同时提供最大的召回率。 在混合查询中，如果对相同的输入加倍，则文本字符串及其向量等效项将生成关键字和相似性搜索的并行查询，并在统一的结果集中返回每种查询类型最相关的匹配项。
此外，还可以扩展混合查询。 可以在同一请求中对详细分块内容进行相似性搜索，对名称进行关键字搜索。
支持相关性调优的方式如下：
计分概要文件，如果在特定搜索字段或其他条件中找到匹配项，可提高搜索分数。
对初始结果集重新排名的语义排序器，使用来自必应的语义模型对结果重新排序，以获得适合原始查询的更好语义。
用于微调的查询参数。 可以 提升矢量查询的重要性 ，或调整混合查询响应中 BM25 排名的结果量 。 还可以设置最低阈值以从向量查询中排除低得分结果。
在比较和基准测试中，包含文本和矢量字段的混合查询（与语义排名相补充）会产生最相关的结果。
集成代码和 LLM
包含 Azure AI 搜索的 RAG 解决方案可以利用内置的数据分块和矢量化功能，或者你也可以使用语义内核、LangChain 或 LlamaIndex 等平台构建自己的解决方案。
对于使用 Azure OpenAI 和 Azure AI 搜索的完整堆栈 RAG 聊天应用示例，建议使用 Azure OpenAI 演示 。
如何入门
有许多方法可以开始，包括代码优先解决方案和演示。
如需帮助来在智能体检索与经典 RAG 之间做出选择，请使用你自己的数据尝试几个快速入门项目，了解开发工作并比较结果。
尝试此自主检索快速入门 以便了解 RAG 的新推荐方法。
尝试本经典 RAG 快速入门 ，以演示通过搜索索引与聊天模型进行查询集成。
查看索引概念和策略以确定引入和刷新数据的方式。 决定是使用矢量搜索、关键字搜索，还是混合搜索。 需要搜索的内容类型以及要运行的查询类型将决定索引设计。
查看如何创建查询，以详细了解搜索请求语法和要求。
Note
某些 Azure AI 搜索功能适用于人机交互，在 RAG 模式中不起作用。 具体而言，可以跳过自动完成和建议之类的功能。 其他功能（如 facet 和 orderby）可能很有用，但在 RAG 方案中并不常见。