透明度说明：Azure AI 搜索

AI 扩充是将 Foundry Tools 中的机器学习模型应用于原始形式不易搜索的内容。 通过扩充、分析和推理，用于创建以前不存在的可搜索内容和结构。

AI 扩充是 Azure AI 搜索 搜索索引器管道的可选扩展，它连接到客户的搜索服务所在的同一区域中的 Foundry Tools。 扩充管道的核心组件与典型的索引器（索引器、数据源、索引）以及指定原子扩充步骤的技能集相同。 可以使用基于 Foundry 工具 API 的内置技能（例如 视觉 和 语言）或运行你提供的外部代码的 自定义技能 来组合技能集。

矢量搜索是一种信息检索方法，其中文档和查询在索引中表示为向量而不是纯文本。 在矢量搜索中，从Azure AI 搜索外部托管的机器学习模型生成源输入的矢量表示形式，可以是文本、图像、音频或视频内容。 这种内容（称为矢量嵌入）的数学和规范化表示形式为搜索方案提供了一个常见基础。

当所有内容都被看作向量时，查询可以在向量空间中找到匹配项，即使相关的原始内容属于不同的媒体类型，如图像与文本或使用不同语言。 搜索引擎会扫描索引，查找最相似的矢量内容，即最接近查询中的向量。 例如，在数学向量表示形式上匹配（而不是关键字）可以更可能查找共享语义含义但文本上不同的匹配项，例如“car”和“auto”。 这更详细地介绍了矢量嵌入以及相似性算法的工作原理。

关键术语

语义排名器使用查询的上下文或语义含义来计算新的相关性分数，从而将语义上与原始查询最接近的结果提升至最前。 初始结果集可能来自具有 BM25 排名、 矢量 搜索或包含两者的 混合搜索 的关键字搜索。 它还通过提取结果中找到的逐字内容和“突出显示”来创建并返回“标题”，以引起人们对结果中重要内容的注意。 如果查询具有问题（“什么是水冰点”）的特征，并且结果包含具有答案特征的文本（“水冻结在 0°C 或 32°F”）时，也可以返回“答案”。

关键术语

查询重写会生成合成查询，这些查询是从实际客户输入中人工创建或生成的，以提高BM25 排名、矢量搜索或混合搜索的召回率（即从可用文档总数中检索到的相关文档占比）。 原始查询与合成查询结合，以从搜索引擎提供最佳召回率。

GenAI 提示技能是Azure AI 搜索技能目录的一部分，使客户能够基于其数据使用 AI 生成的内容增强搜索索引。 通过使用客户的组织自己的数据和首选项，此技能有助于生成符合特定需求的定制摘要、答案或见解。

这意味着当最终用户通过 AI 搜索搜索客户的内容时，AI 生成的内容可以提供更丰富的上下文感知结果，从而使用户更容易找到他们查找的信息。

关键术语

代理检索是一种并行查询处理体系结构，它使用对话式大型语言模型（LLM）作为“查询规划器”。LLM 根据需要将用户的聊天历史记录转换为一个或多个重点子查询。 这些子查询在Azure AI 搜索索引上同时运行，服务合并顶级结果，返回：

• 包含最相关的段落（基于数据）的单个内容字符串。
• 公开完整源文档或区块的引用数组（可选）。
• 一个活动数组，列出每个操作、令牌计数和延迟，以帮助成本跟踪和调试。

关键术语

系统行为

Azure AI 搜索中用于 AI 丰富的多个内置技能利用了 Foundry 工具。 有关选择使用技能时的注意事项，请参阅下面链接的每个内置技能的透明度说明：

• 关键短语提取技能： 语言 - 关键短语提取
• 语言检测技能： 语言 - 语言检测
• 实体链接技能： 语言 - 实体链接
• 实体识别技能： 语言 - 命名实体识别（NER）
• PII 检测技能：语言 - PII 检测
• 情绪技能： 语言 - 情绪分析
• 图像分析技能： 视觉 - 图像分析
• OCR 技能：视觉 - 光学字符识别 (OCR)
• 文档布局技能： 文档智能

请参阅每个技能的文档，详细了解其各自的功能、限制、性能、评估和集成和负责任的使用方法。 请注意，结合使用这些技能可能会导致叠加效应（例如，使用 OCR 时引入的错误在使用关键短语提取时会继续影响结果）。

用例

示例用例

由于Azure AI 搜索是全文搜索解决方案，因此 AI 扩充的目的是改进非结构化内容的搜索实用工具。 下面是内置技能支持的内容扩充方案的一些示例：

• 翻译 和 语言检测 支持多语言搜索。
• 实体识别从大量文本中提取人员、地点和其他实体。
• 关键短语提取 标识并输出重要术语。
• OCR 识别二进制文件中的打印文本和手写文本。
• 图像分析 描述图像内容，并将说明输出为可搜索文本字段。
• Integrated vectorization是一项预览功能，它调用 Azure OpenAI 嵌入模型来向量化数据并将嵌入存储在Azure AI 搜索中，以便进行相似性搜索。

系统行为

在矢量搜索中，搜索引擎在索引中查找嵌入空间中的矢量，以查找靠近查询矢量的矢量。 此方法称为 最近的邻居搜索。 这也有助于量化项之间的相似度或距离。 高度矢量相似性表示原始数据也相似。 Azure AI 搜索支持的两种矢量搜索算法对此问题有不同的方法，可以权衡不同的特征，例如延迟、吞吐量、召回和内存。

查找最接近邻域的真正“k”集需要将输入向量与数据集中的所有向量进行比较。 虽然每个向量相似性计算相对较快，但针对大型数据集执行这些详尽的比较成本高昂且速度缓慢，因为所需的比较数量较多。 此外，每个向量维度越高，每个向量上的计算就越复杂、越慢。

为了应对这一挑战，使用了近似最近邻 (ANN) 搜索方法来权衡召回率与速度。 这些方法可以有效地找到一组最有可能类似于查询向量的候选向量，从而减少矢量比较的总数。 Azure AI 搜索使用分层导航小型世界（HNSW）算法，将高维数据点组织成概率分层图结构，从而实现快速相似性搜索，同时允许在搜索准确性和计算成本之间进行可调的权衡。

Azure AI 搜索还支持多种相似性度量方法，用来确定每个向量结果的最邻近的向量及其分数，其中包括余弦、欧几里得（也称为“l2范数”）和点积。余弦通过计算两个向量之间的角度来判断相似性。 欧几里得计算两个向量之间的欧几里得距离，即两个向量之差的 l2 范数。 点积受矢量的量级和两者之间的角度影响。 对于规范化的嵌入空间，点积相当于余弦相似性，但效率更高。

用例

示例用例

在很多情况下，矢量搜索非常有用，它们仅受用于生成矢量嵌入的模型的功能的限制。 下面是可以使用矢量搜索的一些常规用例：

• Semantic search：使用模型从文本中提取语义理解，例如使用模型（如 Azure OpenAI 服务 嵌入模型）。
• 跨不同数据类型（多模式）进行搜索：对来自图像、文本、音频和视频或混合的内容进行编码，并对所有数据类型执行单个搜索。
• 多语言搜索：使用多语言嵌入模型以多种语言表示文档，以支持的语言查找结果。
• 混合搜索：矢量搜索在字段级别实现，这意味着你可以生成包含矢量字段和可搜索文本字段的查询。 查询并行运行，结果合并为单个响应。 已显示具有语义排名的混合搜索结果，以提供最佳的定性结果。
• 筛选的矢量搜索：查询可以包括矢量查询和筛选表达式。 应用于其他数据类型的筛选器可用于根据其他条件包括或排除文档。
• 矢量数据库：此纯矢量存储用于长期内存或大型语言模型的外部知识库（LLM）。 例如，在检索扩充生成（RAG）应用程序的Azure 机器学习提示流中使用Azure AI 搜索作为向量索引。

选择用例时的注意事项

可能存在与你选择生成矢量嵌入的特定模型相关的注意事项和问题。 每个模型都有其自己的偏见和公平性问题，应在应用程序中使用之前对其进行评估。 Azure AI 搜索不提供任何模型来将内容作为服务的一部分进行矢量化。 有关这些注意事项的示例，请参阅 Azure OpenAI 服务 透明度说明。 其他第三方或 OSS 模型有自己的注意事项需要审查。

系统行为

对第一层检索步骤的结果进行排名是一个高度资源密集型的过程。 若要在查询操作的预期延迟内完成排名器处理，仅检索引擎的前 50 个结果作为输入发送到语义排名器。 如果时间过长，则首先将 50 个结果发送到摘要步骤，该步骤先从每个结果中提取最相关的内容，然后再运行语义排名器。

在摘要步骤中，检索的文档首先通过一个准备过程，将不同的文档输入连接成单个长字符串。 如果字符串太长，则进行剪裁练习，特别强调保留添加到 语义配置的字段中的内容。 准备好字符串后，它们将通过计算机读取理解和语言表示模型传递，以确定哪些句子和短语提供相对于查询的最佳摘要。 此阶段从将转发到语义排名阶段的字符串中提取内容，并选择性地输出 语义标题 或 语义答案。

最后一步语义排名确定在上一步中提取的内容与用户的查询的相关性，并输出语义排名分数，范围从 4（高度相关）到 0（无关）。 此步骤基于查询文本和汇总文本，涉及比检索层更复杂的计算。

用例

示例用例

语义排名器可用于多个方案。 系统的预期用例包括：

• 检索增强生成 (RAG)：语义排名器使你能够将生成式 AI 应用程序的响应基于相关搜索结果，这些结果满足你定义的相关性分数阈值。 例如，基于您的数据的 Azure OpenAI 服务使用 Azure AI 搜索来增强结合您数据的 Azure OpenAI 模型。 可以使用此服务中的语义排名器来提高提供给 Azure OpenAI 模型的信息的相关性。
• 内容搜索：语义排名器允许通过分析文本和元数据来搜索数据中的相关内容。 例如，在learn.microsoft.com网站上进行搜索时，使用语义排名器来提升搜索Microsoft技术文档的软件开发人员的搜索相关性。
• 电子商务搜索：语义排名器使电子商务企业能够通过基于语义相关性提供相关的产品结果来增强其搜索体验。 例如，在线零售商使用语义排名器为在线购物者提供相关的搜索结果来优化其电子商务体验。
• QnA：Azure AI 搜索使组织能够根据数据库中提供的信息回答问题，为用户提供对话体验。 例如，制造商可以使用语义排名器来增强聊天机器人可用的信息。 工程师可以使用此聊天机器人来提问，并检索与查询高度相关的内部文档，还能够从这些检索到的文档中即时获取答案。

选择用例时的注意事项

我们鼓励客户在其创新解决方案或应用程序中使用语义排名器。 但是，在选择用例时，下面是一些注意事项：

• 敏感信息 ：用于启用语义排名器的机器学习模型处理搜索查询中检索到的数据，包括个人信息和财务信息等敏感信息。 在实现此类用例的语义排名器之前，请考虑任何隐私和安全影响。
• 偏差和公平性 ：语义排名器由深度学习模型提供支持。 这些深度学习模型是使用公共内容训练的。 客户数据由语义排名器模型评分。 在选择用例时评估语义排名器的输出，特别是对于具有公平和公平影响的用例，例如招聘。
• 法规符合性：某些行业（如医疗保健和金融）受到高度监管，可能限制 AI 和机器学习的使用。 在此类行业使用语义排名器之前，请确保解决方案符合相关法规和准则。

系统行为

原始查询将发送到由 Azure AI 搜索 托管的 优化的小语言模型 （SLM）。 此模型是使用公共内容训练的。 SLM 将原始查询转换为一组综合查询。 这些综合查询在语义上接近原始查询的意图，但包含一组不同的术语，以改进搜索引擎的召回率。

然后，综合查询与原始查询相结合，并发送到搜索引擎。 当它执行 BM25 排名时，综合查询的关键术语将与原始查询组合在一起。 当它执行 矢量搜索时，原始查询与合成查询连接在 矢量嵌入 步骤之前。

用例

示例用例

查询重写可以在多个场景中使用。 查询重写需要使用 语义排名器。

• 与数据的聊天交互：查询重写使你能够将生成式 AI 应用程序的响应基于相关搜索结果，这些结果满足你定义的相关性分数阈值。 例如，Azure OpenAI 服务 On Your Data 使用 Azure AI 搜索用你的数据增强 Azure OpenAI 模型。 可以使用此服务中的查询重写来提高提供给 Azure OpenAI 模型的信息结果的相关性。
• 对话问答（QnA）：Azure AI 搜索 使组织能够根据数据库中提供的信息回答问题，为用户提供对话式体验。 例如，制造商可以使用语义排名器来增强聊天机器人可用的信息。 工程师可以使用此聊天机器人来提问，并检索与查询高度相关的内部文档，还能够从这些检索到的文档中即时获取答案。

选择用例时的注意事项

我们鼓励客户在其创新解决方案或应用程序中使用查询重写。 但是，在选择用例时，下面是一些注意事项：

• 敏感信息和 PII：经过微调的 SLM（实现查询重写功能）会处理可能包含敏感信息的搜索查询。 在实现此类用例的查询重写之前，请考虑任何隐私和安全影响。
• 修订个人信息以减少无意识偏见。 例如，在公司的简历评审过程中，他们可能想要阻止候选人的姓名、地址或电话号码，以帮助减少搜索期间的无意识性别或其他偏见。
• 法律和法规注意事项。 组织在使用任何 AI 搜索时需要评估潜在的特定法律和法规义务，这些义务可能不适合在每个行业或方案中使用。 限制可能因区域或地方法规要求而异。 此外，AI 搜索不是针对的，不得以适用的服务条款和相关行为准则禁止的方式使用。

GenAI 提示技能允许客户将文档内容、数据源中的现有内容以及自定义提示传递给托管在 Microsoft Foundry 上的语言模型。 语言模型处理输入并返回扩充的内容，然后将内容与原始文档内容一起引入搜索索引。 此过程允许根据客户定义的条件，使用 AI 生成的摘要、图像标题和实体提取等功能增强搜索索引。

以下示例演示 GenAI 提示技能的工作原理。

零样本工单摘要

目标：允许支持代理在几秒钟内浏览多页电子邮件线程。

工作原理：

• 在编制索引期间，每个长票证会话划分为逻辑段（初始请求、跟进问题、诊断日志等）。
• 对于每个段，语言模型将指示“用三个清脆的句子总结此部分”。
• 生成的抽象在检索过程中替换原始文本，因此代理和下游 RAG 管道只能看到提取的精髓。

原因如下：简洁、段级摘要可减少提示大小、加速响应生成，并帮助代理专注于客户的核心问题。

少样本实体提取

目标：支持诸如“显示所有产品 X 因错误 500 崩溃的工单”的查询。

工作原理

• 完整工单文本与一个示例一起发送给技能，该示例显示所需输出格式（关键实体列表，如产品名称、错误代码、操作系统和严重性）。
• 模型提取每个出现的〈产品、error_code、平台、严重性〉。
• 此结构化列表随文档存储，使得可以即时筛选，例如显示 iOS 上所有高严重性崩溃。

为什么它有所帮助：预计算实体将任意格式的客户消息转换为可筛选的数据，使支持人员能够发现模式并优先考虑修复，而无需手动分析。

单样本工单路由分类

目标：自动将每个票证路由到正确的队列。

工作原理：

• 每个票证都通过一个提示进行分析，其中列出了五个支持类别：计费、技术问题、帐户访问、功能请求和常规反馈，以及一个参考示例（“示例票证→计费”）。
• 该模型根据上面的五个支持类别，向输入 AI 搜索系统的每个票证分配一个标签。
• 帮助台系统使用标签将账单查询发送给财务专家，技术崩溃发送给工程师等。

为什么它有帮助：快速、一致的标签可减少错误路由的票证、缩短解决时间并提高客户满意度。

思考链解决方案建议

目标：为支持代理提供解决该问题的最佳下一步。

工作原理

• 整个票证（或其最新的客户消息）将传递给语言模型。
• 用户消息在系统提示后指示模型：“在内部进行分步思考，但只输出建议的下一个操作。
• 返回的指南可能是：“要求客户清除缓存并重新安装版本 3.2.1。
• 代理可以在响应之前直接复制建议或对其进行优化。

为什么它有帮助：代理在没有模型的私人推理链的情况下收到可操作的建议，同时节省时间，同时保持故障排除步骤简洁且相关。 在某些情况下，支持代理不会被不必要的信息充斥。

用例

示例用例

GenAI 提示技能可增强Azure AI 搜索中的数据扩充，帮助响应相关性与用户意向和期望保持一致。 通过将 AI 生成的内容集成到搜索索引中，此技能可实现更准确且上下文适当的搜索结果。 关键应用程序包括：

• 生成冗长文档的简明摘要，以便更快地检索信息：一家律师事务所处理大量合同，并使用 GenAI 提示技能创建突出显示关键条款的简短摘要，使律师无需阅读整个文档即可更轻松地查看基本信息。
• 为图像创建文本说明以提高可搜索性和可访问性：媒体公司管理大量图像库。 通过应用 GenAI 提示技能，他们为每个图像生成描述性字幕，从而在其数字资产管理系统中实现高效的搜索和组织。
• 根据自定义标准从文档中识别和提取特定实体或事实：研究机构分析科学论文，以提取对化合物及其属性的提及。 GenAI 提示技能自动执行此提取，为研究人员填充结构化数据库以快速访问相关数据。
• 将文档分类为定义的类别，以便更好地组织和检索：保险公司每天收到各种类型的文档。 使用 GenAI 提示技能，它们会自动将这些文档分类为声明、策略更新和客户反馈等类别。 这样可简化其文档管理过程，并在需要时更轻松地查找特定文档。

虽然这些是常见的应用程序，但技能很灵活，使客户能够定义根据其独特要求定制的提示。

选择用例时的注意事项

请务必注意，内容、提示和语言模型部署是完全客户管理的资源。 Foundry 支持模型部署的内容安全筛选器，客户负责根据需要配置这些筛选器。 除了 Foundry 中可用的配置之外，Azure AI 搜索不会在 GenAI 提示技能中应用其他内容安全筛选器。

实现 GenAI 提示技能时，请考虑以下事项：

• 实现人工评审 AI 生成内容的过程，尤其是在应用可能影响信息可靠性的提示转换时。 利用 Azure AI 搜索 的 debug 会话工具在全面部署之前测试示例文档的提示。
• 避免使用或滥用系统可能导致对个人造成重大身体或心理伤害的情况。 例如，诊断患者或开处方药物的方案可能会造成重大伤害。 将有意义的人工审查和监督纳入方案有助于降低有害结果的风险。
• 仔细考虑所有生成用例。 内容生成方案可能更可能生成意外输出，这些方案需要仔细考虑和缓解。
• 法律和法规注意事项。 组织在使用任何 AI 搜索时需要评估潜在的特定法律和法规义务，这些义务可能不适合在每个行业或方案中使用。 限制可能因区域或地方法规要求而异。 此外，AI 搜索不是针对的，不得以适用的服务条款和相关行为准则禁止的方式使用。

系统行为

原始对话或搜索查询将发送到客户拥有的 Azure OpenAI 模型以执行查询规划步骤。 查询规划将会话分解为一系列经过优化的子查询，这些子查询反映用户的基础意向，其中包含更正的拼写和扩展的同义词。 Azure AI 搜索 在完整的搜索检索系统中一次性处理所有子查询。 子查询首先由关键字搜索和矢量搜索的 混合组合 进行处理。 关键字搜索 使用与子查询类似的关键字在搜索索引中查找文档。 矢量搜索 能在搜索索引中找到可能具有不同关键字但与查询语义类似的文档。 然后，此混合搜索的结果由 语义排名器 重新排名，以查找与子查询意向匹配的文档。 然后，该服务合并并删除排名结果中的重复项，应用响应限制，例如发送回最终响应之前的最大输出长度。

用例

示例用例

• 为自定义聊天机器人准备基础数据。 将聊天机器人链接到公司的官方人力资源政策和员工手册，这样当有人问：“我得到多少个假期？聊天机器人直接从这些文档中提取答案，而不是猜测。
• 配置企业知识助手，使其能够尊重用户上下文、筛选器和聊天历史记录。 例如，当员工询问特定时间段的目标时，助理会使用其角色、当前筛选器（例如区域：美国）和正在进行的对话（例如，最后一个主题是“Q2 管道”）来生成个性化响应。
• 处理低召回率的复杂信息搜寻任务，这些任务使用单一关键字查询。 此类任务可能包括故障排除指南、医学文献研究或产品比较。 例如，如果技术人员只是搜索“设备错误”并收到一般结果，代理检索器可以考虑整个对话历史记录，其中包括设备模型、软件版本、维护历史记录和网络状态，以显示精确的相关文章。
• 确保对检索的内容、原因和成本完全透明。 例如，在汇总监管文档和过去的审核结果时，必须知道确切来源（例如，“2023 年第 2 季度的 SEC 申请”），选择理由（例如“匹配关键字：风险披露、衍生产品”）和相关成本（例如令牌使用情况）。

选择用例时的注意事项

• 延迟：为查询规划添加第二个 LLM 调用不可避免地会延长请求的往返时间。 即使使用快速模型，也应该对高峰流量下的额外延迟进行基准测试，并验证总体体验是否对用户来说是可以接受的。 如果延迟至关重要，请考虑缓存频繁的查询或使用更小、更快的规划模型。
• 成本：费用会在两个维度上累积，即 OpenAI 模型令牌和搜索排名令牌。 查询规划调用由 Azure OpenAI 按输入和输出令牌计费，而每个子查询由 Azure AI 搜索按其必须排序的令牌计费。 排名令牌在公共预览版的初始阶段是免费的。 提前对工作负载的模型和排名令牌数量进行估算。
• 敏感输入：整个对话历史记录将被转发到规划器模型，这意味着任何个人身份信息或业务敏感数据都会超出您直接的信任边界。 在调用 LLM 之前去除、屏蔽或编辑此类数据，并在数据保护状况中记录缓解措施。
• 区域和预览版限制：代理检索仅适用于语义排名器可用的区域。 单个代理只能指向一个搜索索引。 如果需要跨多个索引或地理位置，请确认托管数据和模型的区域支持代理检索，并计划单独的代理。
• 符合性：确认使用 LLM 驱动的查询规划器符合行业特定或区域要求（例如医疗保健或财务中的数据驻留、隐私或自动决策规则）。 确保足够的人工监督和控制。 请考虑包括控件，以帮助开发人员及时验证、审阅和/或批准操作，这可能包括查看计划的任务或对外部数据源的调用。
• 法律和法规注意事项：用户在使用任何 Foundry 工具和解决方案时需要评估潜在的特定法律和监管义务，这可能不适合在每个行业或方案中使用。 此外，Foundry 工具或解决方案并非设计用于适用服务条款和相关行为准则所禁止的用途。

Azure AI 搜索中的 AI 扩充使用服务的索引器和数据源功能调用 Foundry 工具来执行内容扩充。 此过程中使用的索引器和数据源的限制将适用。 有关这些相关限制的详细信息，请查看 索引器和数据源文档 。 AI 丰富管道在 Azure AI 搜索中使用的每个 Foundry 工具的限制也将适用。 有关这些限制的详细信息，请参阅 每个服务的透明度说明 。

技术限制、操作因素和范围

上传到Azure AI 搜索的所有向量都必须使用所选的模型从服务外部生成。 你有责任考虑每个模型的技术限制和操作因素，以及它创建的嵌入是经过优化还是甚至适合你的用例。 这包括从内容中提取的含义推理，以及矢量嵌入空间的维度。

矢量化模型创建一个嵌入空间，用于定义应用程序的最终用户搜索体验。 如果模型与所需的用例不一致，或者生成的嵌入内容优化不佳，则模型可能会对功能和性能产生负面影响。

虽然矢量搜索的许多限制源于用于生成嵌入的模型，但查询时应考虑一些其他选项。 可以选择两种算法来确定矢量搜索结果的相关性：详尽的 k 近邻（KNN）或分层可导航小世界。 穷举 k 近邻 (KNN) 会对整个向量空间进行暴力搜索，通过计算所有数据点对之间的距离并找到查询点的确切 k 个最近邻居，找到与查询最相似的匹配项。 虽然更精确，但此算法可能很慢。 如果低延迟是主要目标，请考虑使用分层导航小型世界 （HNSW） 算法。 HNSW 在高维嵌入空间中执行高效近似近邻 （ANN） 搜索。 有关这些选项的详细信息，请参阅 矢量搜索文档 。

改进系统性能的最佳做法

• 请务必要花时间使用A/B测试对应用程序支持的不同内容和查询类型进行测试。 确定哪种查询体验最适合你的需求。
• 请花时间使用各种输入内容测试模型，以了解它在很多情况下的行为方式。 此内容可能包括潜在的敏感输入，以了解模型中是否存在任何偏见。 Azure OpenAI 负责任的 AI概述提供了有关如何负责任地使用 AI 的指导。
• 请考虑将 Azure AI 内容安全 添加到应用程序体系结构。 它包括一个 API，用于检测应用程序和服务中有害的用户生成和 AI 生成的文本或图像。

评估和集成供你使用的矢量搜索

为了确保最佳性能，请对计划使用矢量搜索实现的解决方案进行自己的评估。 遵循评估过程：（1）使用一些内部利益干系人来评估结果，（2）使用 A/B 试验向用户推出矢量搜索，（3）在首次在体验中部署服务时纳入关键绩效指标（KPI）和指标监视，并且（4）测试和调整语义排名器配置和/或索引定义， 包括用户界面放置或业务流程等周边体验。

Microsoft通过使用不同的数据集来测量返回结果的速度、可伸缩性和准确性，从而严格评估矢量搜索在延迟、查全率和相关性方面的表现。 评估工作的主要重点是为特定用例选择适当的模型，了解模型的局限性和偏见，并严格测试端到端矢量搜索体验。

技术限制、操作因素和范围

在某些情况下，语义结果、标题和答案可能看起来不正确。 语义排名器使用的模型根据各种数据源（包括开放源代码和Microsoft 必应语料库的选择）进行训练。 语义排名器支持 广泛的语言 ，并尝试将用户查询与搜索结果中的内容匹配。 语义排名器也是一项需额外付费的高级功能，在评估您的端到端解决方案的总体成本时，应考虑这个功能。

语义排名器最有可能提高与语义丰富的内容（如文章和说明）的相关性。 它查找字词之间的上下文和相关性，提升对查询更有意义的匹配项。 语言理解“查找”内容中的摘要或标题和答案，但与生成模型（如Azure OpenAI 服务模型 GPT-3.5 或 GPT-4）不同，它不会创建它们。 响应中仅包含来自源文档的逐字文本，然后可在搜索结果页面上呈现，以便获得更高效的搜索体验。

最先进的预先训练的模型用于汇总和排名。 为了维持用户对搜索所期望的快速性能，仅将语义总结和排序应用于由默认评分算法评分的前 50 个结果。 输入派生自搜索结果中的内容。 它无法访问搜索索引以访问在查询响应中未返回的搜索文档中的其他字段。 输入的令牌长度上限为 8,960。 这些限制是维护毫秒响应时间所必需的。

默认评分算法来自必应和Microsoft Research，并作为附加功能集成到Azure AI 搜索基础结构中。 模型在内部使用，不会向开发人员公开，并且不可配置。 有关支持语义排名器的研究和 AI 投资的详细信息，请参阅必应的 AI 如何为 Azure AI 搜索提供动力（Microsoft 研究博客）。

语义排名器还在响应中提供答案、标题及高亮显示。 例如，如果模型将查询分类为问题，并且对答案有 70 个% 自信，则模型将返回语义答案。 此外，语义标题在结果中提供最相关的内容，并提供一个简短的代码片段，其中突出显示了该代码片段中最相关的字词或短语。

语义排名器结果基于基础搜索索引中的数据，模型基于从索引中检索的信息提供相关性排名、答案和标题。 在生产环境中使用语义排名器之前，请务必进行进一步测试，并确保数据集准确且适合预期用例。 有关如何评估语义排名器的详细信息和示例，请参阅 此处的内容和附录。

系统性能

在许多 AI 系统中，通常定义与准确性相关的性能，即 AI 系统提供正确预测或输出的频率。 使用大规模自然语言模型，两个不同的用户可能会查看相同的输出，并对其有用性或相关性有不同的看法，这意味着必须更灵活地定义这些系统的表现。 在这里，我们广泛考虑性能，这意味着应用程序在你和用户期望时执行，包括不生成有害输出。

语义排名器针对公共内容进行了训练。 因此，语义相关性因索引中的文档及其发出的查询而异。 当你将此内容用于决策时，请务必使用自己的判断和研究。

改进系统性能的最佳做法

• 请花时间使用不同的查询类型（例如关键字与混合和语义排名器）测试应用程序。 确定哪种查询体验最适合你的需求。
• 请根据 功能文档合理地设置语义配置。
• 如果对搜索索引中信息的准确性不有信心，请不要信任语义答案。
• 不要总是信任语义标题，因为它们是通过一系列模型从客户内容中提取的，这些模型可预测简短代码片段中最相关的答案。

语义排名器评估

评估方法

语义排名器通过内部测试进行评估，包括对多个数据集的自动和人工判断，以及来自内部客户的反馈。 测试包括对文档进行排名，具体方法是将它们评分为相关或不相关，并根据相关性的优先级顺序对文档进行排序。 同样，字幕和答案功能也通过内部测试进行排名。

评估结果

我们努力交付所有模型更新无回归（即更新的模型只应改进当前的生产模型）。 每个候选对象通过适合评估功能的指标直接与当前生产模型进行比较（例如，排名的归一化折扣累积增益和答案的精确率/召回率）。 语义排名器模型通过使用多样化的训练数据来进行训练、优化和评估。这些训练数据代表不同属性（语言、长度、格式、样式和色调）的文档，以支持最广泛范围的搜索场景。 我们的训练和测试数据来自：

文档源：

• 学术和行业基准
• 客户数据（仅测试，使用客户权限执行）
• 综合数据

查询源：

• 基准查询组
• 客户提供的查询集（仅测试，使用客户权限执行）
• 合成查询集
• 人工生成的查询集

用于评分查询和文档对的标签来源：

• 学术和行业基准标签
• 客户标签（仅测试，使用客户权限执行）
• 综合数据标签
• 人工评分标签

评估并集成语义排名器到你的用例

语义排名器的性能因实际用途和人们使用它的条件而异。 深度学习模型为语义排序功能提供的相关性质量与搜索索引的数据质量直接相关。 例如，模型当前具有令牌限制，仅考虑语义答案的前 8,960 个标记。 因此，如果在长文档末尾找到搜索查询的语义答案（超过 8,960 个令牌限制），则不会提供答案。 同一规则适用于字幕。 此外，语义配置按优先级顺序列出相关的搜索字段。 可以重新排序此列表中的字段，以帮助定制相关性，以更好地满足你的需求。

为了确保其方案中的最佳性能，客户应使用语义排名器对其实现的解决方案进行自己的评估。 客户通常应遵循评估过程：（1）使用一些内部利益干系人来评估结果，（2）使用 A/B 试验向用户推出语义排名器，（3）在首次在体验中部署服务时合并 KPI 和指标监视，并且（4）测试和调整语义排名器配置和/或索引定义， 包括用户界面放置或业务流程等周边体验。

如果要在高风险领域或行业（如医疗保健、人力资源、教育或法律领域）开发应用程序，请评估应用程序在你的方案中的工作方式，实施强有力的人工监督，评估用户如何了解应用程序的限制，并遵守所有相关法律。 根据方案考虑其他缓解措施。

技术限制、操作因素和范围

在某些情况下，综合查询不正确、限制过多或成本过高。 查询重写支持 广泛的语言 ，并尝试重写用户查询以最大化召回率，因此需要将查询语言指定为输入。 查询重写是语义排名器（Azure AI 搜索功能以提高搜索相关性）的一部分，这是一项具有额外成本的高级功能。 在评估端到端解决方案的总体费用时，应考虑这一点。 仅当启用了语义排名器时，才能使用查询重写。

在生产环境中（应用程序的实时版本）中使用查询重写之前，请务必执行进一步测试并确保合成查询适合预期用例。 有关如何评估查询重写的详细信息和示例，请参阅 此处的内容和附录。

系统性能

使用大规模自然语言模型，两个不同的用户可能会查看相同的输出，并对其有用性或相关性有不同的看法，这意味着必须更灵活地定义这些系统的表现。 在这里，我们广泛考虑性能，这意味着应用程序在你和用户期望时执行，包括不生成有害输出。

查询重写的性能因实际用途和人们使用它的条件而异。 查询重写模型提供的合成查询的质量与原始搜索查询直接相关。

为了确保其方案中的最佳性能，客户应使用查询重写对其实现的解决方案进行自己的评估。 客户通常应遵循以下评估过程：

1. 使用一些内部利益干系人来评估结果，
2. 使用 A/B 实验向用户推出查询重写，并且
3. 在服务首次部署到体验中时合并 KPI 和指标监控

改进系统性能的最佳做法

• 使用不同查询类型（全文、矢量、混合或其他类型的查询）为应用程序完成 A/B 测试。 确定哪种查询体验最适合你的需求。
• 不要总是假定由查询重写生成的每个综合查询都将反映原始查询的确切意图。 合成查询由微调的 SLM 生成，它以语义方式生成与原始查询的意向类似的查询，但可能与确切的意向不匹配。

查询重写评估

评估方法

查询重写是通过内部测试进行评估的，包括对多个数据集的自动化和人工判断，以及来自内部客户的反馈。 测试包括评估语义排名与查询重写结合的结果相关性与仅语义排名的结果相关性。

评估结果

每个候选模型都通过使用适合要评估的功能的指标直接与当前部署的模型进行比较。 查询重写模型使用各种公共数据进行优化和评估，这些数据代表具有不同属性（语言、长度、格式、样式和色调）的查询，以支持最广泛的搜索方案数组。 我们的训练和测试数据来自：

文档源：

• 学术和行业基准
• 客户数据（仅测试，使用客户权限执行）

查询源：

• 基准查询组
• 客户提供的查询集（仅测试，使用客户权限执行）
• 合成查询集
• 人工生成的查询集

用于评分查询和文档对的标签来源：

• 学术和行业基准标签
• 客户标签（仅测试，使用客户权限执行）
• 综合数据标签
• 人工评分标签

评估并集成查询重写到你的用例

由于查询重写是在公共内容上训练的，合成查询将根据向其发出的查询而变化。 因此，在将此内容用于决策时，请务必使用自己的判断和研究。

技术限制、操作因素和范围

虽然 GenAI 提示技能提供强大的功能，但必须识别某些限制：

• 技能依赖于 Foundry 中客户配置的内容筛选器。 Azure AI 搜索不提供此技能的其他内容安全机制。
• AI 生成的内容的质量取决于提示和基础语言模型的有效性。 必须进行彻底的测试，以确保输出符合所需的标准。
• 使用复杂提示处理大量数据可能需要大量的计算资源，并可能导致延迟。 明智地规划和分配资源，不仅要保持性能和成本效益，还能防止数据处理的可能延迟。

系统性能

改进系统性能的最佳做法

优化 GenAI 提示功能的性能：

• 利用 Azure AI 搜索 的 debug 会话工具测试示例文档的提示，确保 AI 生成的内容与完整部署前的预期保持一致。
• 创建清晰详细的提示，以有效指导语言模型，从而减少不相关或不准确的输出的可能性。
• 根据需要监视系统性能和缩放资源，以处理 AI 处理的计算需求。
• 鼓励在发布或传播之前对输出进行人工监督。 使用生成 AI 时，可能会生成可能令人反感或与手头任务无关的内容。

生成式AI提示能力评估

评估并集成 GenAI 提示技能到你的用例

若要最大程度地提高特定上下文中 GenAI 提示技能的优势，请考虑以下步骤：

• 确定特定的扩充目标，例如生成简洁摘要、提取关键实体或创建描述性元数据，以便使技能的应用程序与业务需求保持一致。
• 首先，从一部分数据开始，以评估技能的性能并做出必要的调整。 此方法允许在全面部署之前进行受控试验和优化。
• 建立机制来监视 AI 生成的内容的质量和影响。 征求最终用户的反馈，以确定改进领域，并确保扩充的数据符合用户的期望。

技术限制、操作因素和范围

在某些情况下，LLM生成的子查询可能不相关、过于限制或导致令牌成本上升。 代理检索支持 GPT-4o 系列处理的所有语言，但生成的查询计划的质量仍取决于用户输入的清晰度。 由于代理检索依赖于每个子查询的语义排名器，因此必须在索引上启用语义排名器。 语义排名器是基于令牌的高级功能;虽然在公共预览版的初始阶段将免除排名费用，但稍后将适用，并应纳入总拥有成本。

在将代理检索移动到生产环境之前，请进行额外的测试，以确认子查询和返回的段落适用于预期用例，延迟和成本满足服务级别目标，并且基础数据不会公开敏感内容或不符合内容。

系统性能

与任何大规模语言模型系统一样，不同的用户可以对返回的段落的有用性或相关性做出不同的判断，因此必须灵活定义性能。 对于代理检索，我们认为性能良好，这意味着端到端应用程序可提供用户期望的内容，而不会带来不可接受的延迟、成本或有害输出。

代理检索的有效性取决于许多实际因素：

• 提示/聊天历史记录长度
• LLM 生成的子查询数
• 索引大小和架构（关键字、矢量、混合）
• 规划模型选择（GPT-4o 与 GPT-4o-mini）
• 语义搜索配置和评分阈值

改进系统性能的最佳做法

• 汇总或剪裁较旧的聊天轮次，以保持令牌使用率低。
• 优化排名器阈值，以便仅返回高度相关的段落
• 尽可能使用筛选器

代理检索评估

代理检索已通过内部测试进行评估，包括对多个数据集的自动和人工判断。 测试包括评估代理检索结果与仅语义排名的结果的相关性。

评估方法

每个候选的智能检索配置，由其规划提示、模型变体、子查询数量和排序阈值定义，将与生产基线进行一对一评估。 我们将应用专为多查询检索方案选择的相关性、安全、延迟和成本指标套件。 为了确保跨实际用例的可靠性，优化和测试是在各种公共数据集和客户批准的数据集中执行的，这些数据集因语言、查询长度、格式设置、样式和对话语气而异。 测试材料源自：

文档源：

• 学术和行业基准
• 客户数据（仅测试，使用客户权限执行）
• 查询源：
• 基准查询组
• 客户提供的查询集（仅测试，使用客户权限执行）
• 合成查询集
• 人工生成的查询集

用于评分查询和文档对的标签来源：

• 学术和行业基准标签
• 客户标签（仅测试，使用客户权限执行）
• 综合数据标签
• 人工评分标签

评估并集成智能体检索到你的用例

由于代理检索规划器主要针对公共数据进行训练，因此生成的子查询的质量和相关性因域和特定用户提示而异。 若要最大程度地提高特定上下文中代理检索的优势，请考虑以下步骤：

• 在使用它驱动业务关键决策之前验证输出：手动检查生成的子查询和返回的文档示例，以确认它们符合域术语、准确性和合规性要求。
• 向规划器提供特定于域的信息。 提供 同义词映射和完整对话历史记录，以便 LLM 可以用与内容匹配的语言来解释和分解查询，从而提高召回率和精度。
• 实施回退或护栏逻辑：如果规划器生成低置信度或超出范围的子查询，将请求路由到更简单的关键字或向量搜索，或向用户显示澄清提示，防止不可靠答案向下游传播。