你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
注释
此功能目前处于公开预览状态。 此预览版在提供时未附带服务级别协议，建议不要用于生产工作负载。 某些功能可能不受支持或者受限。 有关详细信息，请参阅 Microsoft Azure 预览版补充使用条款。
在 Azure AI 搜索中， 代理检索 是一个新的查询管道，专为聊天和 copilot 应用中的用户或代理提出的复杂问题而设计。 它使用大型语言模型（LLM）将问题分解为较小的子查询，通常使用聊天历史记录作为上下文。 这些子查询并行运行，每个子查询都在索引中搜索最相关的内容。 结果按语义相关性排序并组合，然后返回到您的 LLM，以使用专有内容生成准确的答案。
对代理式检索的支持是以编程方式通过 2025-05-01-preview 数据平面 REST API 和提供该功能的 Azure SDK 预发行包中的新知识代理对象来实现的。 知识代理的检索响应旨在供其他代理和聊天应用下游使用。
为何使用代理检索
如果要为代理和应用提供最相关的内容来回答更难的问题，利用聊天上下文和专有内容，则应使用代理检索。
代理方面是查询规划处理中的一个推理步骤，由你提供的受支持大型语言模型 (LLM) 执行。 LLM 分析整个聊天线程，以确定所需的基础信息。 模型根据用户问题、聊天历史记录和请求参数，将复合问题分解为多个专注的子查询，而不是单个通用查询。 子查询以 Azure AI 搜索中的索引文档（纯文本和向量）为目标。这种混合方法可确保同时显示关键字匹配项和语义相似性，从而显著提高召回率。
检索组件能够同时运行子查询、合并结果、对结果进行语义排序，并返回包含三个部分的响应：其中包括下一个会话轮次的基础数据、引用数据以便检查源内容，以及显示查询执行步骤的操作计划。
查询扩展和并行执行以及检索响应是代理检索的关键功能，使其成为生成式 AI （RAG） 应用程序的最佳选择。
代理检索增加了查询处理的延迟，但它通过添加这些功能来弥补它：
- 读入历史聊天记录作为检索管道的输入。
- 将原始查询通过同义词映射（可选）和 LLM 生成的释义重写为多个子查询。
- 更正拼写错误。
- 将包含多个“请求”的复杂查询分解为组件部分。 例如：“帮我在海滩附近找一个提供机场接送服务且步行可达素食餐厅的酒店。”
- 同时执行所有子查询。
- 将统一结果输出为单个字符串。 或者，您可以提取响应中的部分以用于您的解决方案。 有关查询执行和引用数据的元数据包含在响应中。
代理检索为每个查询请求多次调用整个查询处理管道，但它并行执行，从而保持合理的用户体验所需的效率和性能。
注释
在查询规划中包含 LLM 会增加查询管道的延迟。 可以通过使用更快的模型（如 gpt-4o-mini）和汇总消息线程来缓解效果。 尽管如此，此管道的查询时间预期会更长。
代理检索体系结构
代理检索旨在提供包含 LLM 的对话式搜索体验。 代理检索的一个重要部分是 LLM 如何将初始查询分解为子查询，这些查询在查找索引中的最佳匹配项更有效。
代理检索包含以下组件：
| 组件 | 资源 | 用法 |
|---|---|---|
| LLM（gpt-4o 和 gpt-4.1 系列） | Azure OpenAI | 这个LLM具有两个功能。 首先，它为查询计划制定子查询，并将其发送回知识代理。 其次，执行查询后，LLM 从查询响应接收基础数据，并将其用于答案的生成。 |
| 搜索索引 | Azure AI 搜索 | 包含纯文本和矢量内容、语义配置和其他元素（根据需要）。 |
| 知识代理 | Azure AI 搜索 | 连接到 LLM，并提供参数和输入以生成查询计划。 |
| 检索引擎 | Azure AI 搜索 | 在 LLM 生成的查询计划和其他参数上执行，返回包含内容和查询计划元数据的丰富响应。 查询是关键字、矢量和混合查询。 结果进行合并并排名。 |
| 语义排序器 | Azure AI 搜索 | 提供 L2 重新排序，优先显示最相关的匹配项。 语义排名器是代理性检索所必需的。 |
解决方案应包含驱动管道的工具或应用。 代理检索管道以提供有据性数据的响应对象结束。 解决方案应该从那里开始，通过将响应传递给 LLM 来处理响应以生成答案，然后在用户对话中以内联方式呈现该答案。 有关此步骤的详细信息，请参阅 生成代理到代理检索解决方案。
代理检索具有以下过程：
- 在 Azure AI 搜索上，通过调用知识代理来发起代理检索请求。
- 知识代理将连接到 LLM 并提供对话历史记录作为输入。 你提供的消息数量决定了可配置的历史记录量。
- LLM 查看对话并确定是否将其分解为子查询。 子查询的数量取决于 LLM 决定的内容，以及参数
maxDocsForReranker是否高于 50。 为发送到语义排序器的包含 50 个文档的每一批定义一个新的子查询。 - 子查询在 Azure AI 搜索上同时执行，并生成结构化结果和提取的引用。
- 对结果进行排序和合并。
- 知识代理响应是作为由统一结果（长字符串）、引用数组和枚举所有作的活动数组组成的三部分响应进行制定和返回的。
你的搜索索引决定了查询执行以及在查询执行过程中可能发生的任何优化。 这包括语义配置，以及可选的计分配置文件、同义词映射、分析器和规范化器（如果添加筛选器）。
可用性和定价
代理检索在所有提供 语义排名器的所有区域中都可用，但免费层除外。
代理检索计费分为两部分：
Azure OpenAI 上的查询规划计费采用即用即付模式。 它是基于输入和输出标记的标记。 分配给知识代理的模型将根据令牌使用情况收费。 例如，如果使用 gpt-4o，令牌费用将显示在 gpt-4o 的帐单中。
在查询执行期间进行的语义排名将计费。 在初始发布阶段暂停计费，但随后通过语义排序器在 Azure AI 搜索端过渡到即用即付模式。 语义排名器是高级计费功能，是代理检索不可或缺的一部分。 在 Azure AI 搜索端，你需要为语义排名模型的标记输入付费。
对计划中的每个子查询执行语义排名。 语义排名费基于每个子查询返回的标记数。
| 方面 | 经典单查询管道 | 代理检索多查询管道 |
|---|---|---|
| 单位 | 基于（每个货币单位 1,000 个查询） | 基于标记（每个单位货币 100 万个标记） |
| 单位成本 | 每个查询的统一成本 | 每个令牌的统一成本 |
| 成本估计 | 估算查询次数 | 估计令牌使用情况 |
| 免费层 | 1,000 个免费查询 | 5000 万个免费令牌 |
注释
如果在代理检索之外使用它，则现有的语义排名器计费保持不变。 有关没有代理检索的定价，请参阅 Azure AI 搜索定价页。
示例：估算成本
代理检索有两种计费模式：来自 Azure OpenAI 的计费（查询规划）和来自 Azure AI 搜索的语义排名计费（查询执行）。
本文中所示的价格是虚构的。 它们用于说明估算过程。 你的成本可能更低。 有关交易的实际价格，请参阅 Azure OpenAI 定价。 对于查询执行，在初始公共预览版中，代理检索的语义排名是免费的。
查询规划的预估计费成本
若要在 Azure OpenAI 中估算查询计划成本（即用即付），我们假设 gpt-4o-mini：
- 15 美分用于 100 万个输入令牌。
- 对于 100 万个输出标记为 60 美分。
- 对于平均聊天对话大小为 2,000 个输入标记。
- 对于平均输出计划大小为 350 个标记。
查询执行的预估计费成本
若要估算与代理检索相关的语义排名成本，请从索引中平均文档的外观开始。 例如，可以使用以下似近值：
- 10,000 个区块，其中每个区块是 PDF 的一到两个段落。
- 每个区块为 500 个标记。
- 每个子查询最多重新排序 50 个块。
- 每个查询计划平均有三个子查询。
计算交易执行价格
假设我们每个计划执行 2,000 次代理检索，并且每个检索包含三个子查询。 因此，我们总共大约有 6,000 个查询。
每个子查询重新排序 50 个区块，总共 300,000 个区块。
平均块大小为 500 个令牌，因此用于重新排序的令牌总数为 1.5 亿。
假设每令牌价格为 0.022 美元，3.30 美元是重新计价的总成本。
继续查询计划成本：2,000 个输入令牌乘以 2,000 次代理检索，等于 400 万个输入令牌，总成本为 60 美分。
根据平均 350 个令牌估算输出成本。 如果我们将 350 乘以 2,000 次代理检索，则会得到总共 700,000 个输出标记，总成本为 42 美分。
将所有内容组合在一起，你将在 Azure AI 搜索中为语义排名支付约 3.30 美元，在 Azure OpenAI 中为输入令牌支付 60 美分，为输出令牌支付 42 美分，总计为查询计划支付 1.02 美元。 完整执行的总成本为 4.32 美元。
如何入门
必须使用预览版 REST API 或提供该功能的预发行版 Azure SDK 包。 目前，没有 Azure 门户或 Azure AI Foundry 门户支持。
为下一步选择其中任一选项。
快速入门文章：在 Azure AI 搜索中运行代理检索。 使用示例数据和准备好的索引和查询了解基本工作流。
示例代码：
聚焦开发任务的操作指南：
Azure OpenAI 演示，已更新为使用代理检索。