通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

基于自有数据的 Azure OpenAI

  • 项目

本文介绍基于自有数据的 Azure OpenAI，它使开发人员可以更轻松地连接、引入和建立其企业数据，以便快速创建个性化 Copilot（预览版）。 它增强了用户理解能力、加快任务完成速度、提高运营效率并帮助决策。

什么是基于自有数据的 Azure OpenAI

通过基于自有数据的 Azure OpenAI，无需训练或微调模型即可基于自己的企业数据运行高级 AI 模型，例如 GPT-35-Turbo 和 GPT-4。 你可以更准确地聊天和分析数据。 可以根据指定数据源中可用的最新信息指定支持响应的来源。 可以通过 SDK 或 Azure OpenAI Studio 中基于 Web 的界面，使用 REST API 访问基于自有数据的 Azure OpenAI。 还可以创建一个连接到数据的 Web 应用，以提供增强的聊天解决方案，或在 Copilot Studio（预览版）中将其直接部署为 Copilot。

通过基于自有数据的 Azure OpenAI 进行开发

关系图显示了示例工作流。

通常，通过基于自有数据的 Azure OpenAI 进行开发的过程为：

  1. 引入：使用 Azure OpenAI Studio 或引入 API 上传文件。 通过此操作，可以将数据破解、分块并嵌入到 Azure OpenAI 模型可以使用的 Azure AI 搜索实例中。 如果具有现有的受支持数据源，也可以直接连接它。

  2. 开发：试用 Azure OpenAI on Your Data 后，请开始使用以多种语言提供的可用 REST API 和 SDK 开发应用程序。 它将创建要传递给 Azure OpenAI 服务的提示和搜索意向。

  3. 推理：在首选环境中部署应用程序后，它会将提示发送到 Azure OpenAI，这将在返回响应之前执行几个步骤：

    1. 意向生成：服务将确定用户提示的意向，以确定正确的响应。

    2. 检索：服务将通过查询连接的数据源来从其中检索相关的可用数据区块。 例如，通过使用语义或矢量搜索。 可利用严格性和要检索的文档数等参数来影响检索。

    3. 筛选和重新排名：通过对数据进行排名和筛选以优化相关性来改进检索步骤中提供的搜索结果。

    4. 响应生成：生成的数据会连同系统消息等其他信息一起提交到大语言模型 (LLM)，并将响应发送回应用程序。

首先，使用 Azure OpenAI Studio 连接数据源，然后开始基于数据提问和聊天。

用于添加数据源的 Azure 基于角色的访问控制 (Azure RBAC)

若要完全使用基于自有数据的 Azure OpenAI，需要设置一个或多个 Azure RBAC 角色。 有关详细信息，请参阅安全使用基于自有数据的 Azure OpenAI。

数据格式和文件类型

基于自有数据的 Azure OpenAI 支持以下文件类型：

  • .txt
  • .md
  • .html
  • .docx
  • .pptx
  • .pdf

有上传限制，需要注意一些关于文档结构以及它如何影响模型响应质量的事项：

  • 如果要将数据从不受支持的格式转换为受支持的格式，请通过确保转换来优化模型响应的质量：

    • 不会导致重大数据丢失。
    • 不会向数据添加意外的干扰。

  • 如果文件具有特殊格式（例如表和列或项目符号点），请使用 GitHub 上提供的数据准备脚本来准备数据。

  • 对于包含长文本的文档和数据集，应使用可用的数据准备脚本。 此脚本将对数据进行分块，使模型的响应更加准确。 此脚本还支持扫描的 PDF 文件和图像。

支持的数据源

需要连接到数据源才能上传数据。 若要使用数据与 Azure OpenAI 模型聊天，会在搜索索引中将数据分块，以便根据用户查询找到相关数据。

基于 vCore 的 Azure Cosmos DB for MongoDB 中的集成矢量数据库本身支持与 Azure OpenAI On Your Data 的集成。

对于某些数据源（例如从本地计算机上传文件（预览版）或 Blob 存储帐户中包含的数据（预览版）），将使用 Azure AI 搜索。 选择以下数据源时，Azure AI 搜索索引将引入你的数据。

通过 Azure AI 搜索引入的数据 说明
Azure AI 搜索 在基于自有数据的 Azure OpenAI 中使用现有的 Azure AI 搜索索引。
上传文件（预览版） 从本地计算机上传文件以存储在 Azure Blob 存储数据库中，并引入 Azure AI 搜索中。
URL/Web 地址（预览版） URL 中的 Web 内容存储在 Azure Blob 存储中。
Azure Blob 存储（预览版） 从 Azure Blob 存储上传文件以将其引入 Azure AI 搜索索引中。

矢量索引服务的示意图。

部署到 copilot（预览版）、Teams 应用（预览版）或 web 应用

将 Azure OpenAI 连接到数据后，可以使用 Azure OpenAI Studio 中的“部署到”按钮对其进行部署。

屏幕截图显示 Azure OpenAI Studio 中的模型部署按钮。

它提供了多个用于部署解决方案的选项。

你可以直接从 Azure OpenAI Studio 将模型部署到 Copilot Studio（预览版）中的 Copilot，从而将对话体验引入各种通道，例如：Microsoft Teams、网站、Dynamics 365 和其他 Azure 机器人服务。 Azure OpenAI 服务和 Copilot Studio（预览版）中使用的租户应相同。 有关详细信息，请参阅使用与基于自有数据的 Azure OpenAI 的连接。

注意

部署到 Copilot Studio（预览版）中的 Copilot 仅在美国地区可用。

安全使用基于自有数据的 Azure OpenAI

你可以使用 Microsoft Entra ID 基于角色的访问控制、虚拟网络和专用终结点保护数据和资源，从而安全地使用基于自有数据的 Azure OpenAI。 还可以使用 Azure AI 搜索安全筛选器限制可用于响应不同用户的文档。 请参阅安全使用基于自有数据的 Azure OpenAI。

最佳实践

以下部分介绍如何提高模型提供的响应的质量。

引入参数

将数据引入 Azure AI 搜索时，可以在工作室或引入 API 中修改以下附加设置。

区块大小（预览版）

基于自有数据的 Azure OpenAI 通过在引入文档之前将其拆分为区块来处理文档。 区块大小是搜索索引中任何区块的标记数的大小上限。 区块大小和检索的文档数共同控制发送到模型的提示中包含的信息量（标记）。 通常，区块大小乘以检索的文档数即为发送到模型的标记总数。

为用例设置区块大小

默认区块大小为 1024 个标记。 但是，鉴于数据的唯一性，你可能会发现不同的区块大小（例如 256、512 或 1536 个标记）更有效。

调整区块大小可以提高聊天机器人的性能。 虽然寻找最佳区块大小需要反复试验，但首先要考虑的是数据集的性质。 对于具有直接事实和较少上下文的数据集，较小的区块大小通常更好；较大的区块大小可能有利于提供更多上下文信息，但可能会影响检索性能。

较小的区块大小（如 256）会生成更精细的区块。 此大小还意味着模型将利用更少的标记来生成其输出（除非检索的文档数非常高），这可能会降低成本。 较小的区块也意味着模型不必处理和解释长段文本，从而减少噪音和干扰。 但是，这种粒度和焦点也会带来潜在问题。 重要信息可能不在检索到的区块中，尤其是在检索的文档数设置为低值（如 3）时。

提示

请记住，更改区块大小需要重新引入文档，因此首先调整运行时参数（如严格性和检索的文档数）非常有用。 如果仍未获得所需的结果，请考虑更改区块大小：

  • 如果在回答问题时遇到大量“我不知道”之类的回答，而这些问题的答案应该包含在你的文档中，则请考虑将区块大小减小到 256 或 512，以提高粒度。
  • 如果聊天机器人提供了一些正确的详细信息，但缺少其他详细信息（在引文中变得很明显），则将区块大小增加到 1536 可能有助于捕获更多上下文信息。

运行时参数

在 Azure OpenAI Studio 和 API 的“数据参数”部分，可修改以下其他设置。 更新这些参数时，无需重新引入数据。

参数名称 说明
限制对数据的响应 此标志配置聊天机器人处理与数据源无关的查询的方法，或者当搜索文档不足以提供完整答案时的方法。 禁用此设置后，除了你的文档外，模型还会使用自己的知识来补充其响应。 启用此设置后，模型会尝试仅依赖你的文档进行响应。 这是 API 中的 inScope 参数，默认设置为 true。
检索的文档 此参数是一个整数，可设置为 3、5、10 或 20，它控制提供给大型语言模型的文档区块数，以形成最终响应。 默认情况下，它设置为 5。 搜索过程可能会受到干扰，有时，由于分块，相关信息可能会分散在搜索索引中的多个区块中。 选择一个 top-K 数（如 5）可确保模型可以提取相关信息，尽管搜索和分块存在固有限制。 但是，这个数过高的话可能会分散模型注意力。 此外，可以有效使用的最大文档数取决于模型的版本，因为每个版本都具有不同的上下文大小和处理文档的能力。 如果发现响应缺少重要上下文，请尝试增加此参数。 这是 API 中的 topNDocuments 参数，默认值为 5。
严格性 确定系统基于相似性分数筛选搜索文档的激进性。 系统会查询 Azure 认知搜索或其他文档存储，然后确定要提供给大型语言模型（如 ChatGPT）的文档。 筛掉不相关的文档可以显著增强端到端聊天机器人的性能。 如果某些文档的相似性分数较低，则在转发到模型之前，会将它们排除在 top-K 结果之外。 这由一个介于 1 到 5 之间的整数值控制。 将此值设置为 1 意味着系统将基于用户查询的搜索相似性对文档进行最低程度的筛选。 相反，设置为 5 表示系统会激进地筛掉文档，并应用非常高的相似性阈值。 如果你发现聊天机器人省略了相关信息，请降低筛选器的严格程度（将值设置为更接近 1）以包含更多文档。 相反，如果无关的文档分散了响应的注意力，请增加阈值（将值设置为更接近 5）。 这是 API 中的 strictness 参数，默认设置为 3。

未引用的参考

对于从数据源检索到但未包含在引文中的文档，模型有可能在 API 中返回 "TYPE":"UNCITED_REFERENCE" 而不是 "TYPE":CONTENT。 这对于调试非常有用，可以如上所述通过修改严格性和检索的文档运行时参数来控制此行为。

系统消息

可以定义使用基于自有数据的 Azure OpenAI 时引导模型回复的系统消息。 通过此消息，可以在基于自有数据的 Azure OpenAI 使用的检索增强生成 (RAG) 模式的基础上自定义回复。 除了内部基本提示之外，还使用系统消息来提供体验。 为了对此提供支持，我们在特定的令牌数后截断系统消息，以确保模型可以使用你的数据回答问题。 如果在默认体验的基础上定义额外行为，请确保系统提示内容详细，并解释了确切的预期自定义。

选择添加数据集后，可以使用 Azure OpenAI Studio 中的“系统消息”部分或 API 中的 role_information 参数。

屏幕截图显示 Azure OpenAI Studio 中的系统消息选项。

潜在的使用模式

定义角色

可以定义需要的助手角色。 例如，如果你正在构建支持机器人，则可以添加“你是一名专家事件支持助手，可帮助用户解决新问题。”

定义要检索的数据类型

还可以添加要提供给助手的数据的性质。

  • 定义数据集的主题或范围，例如“财务报表”、“学术论文”或“事件报告”。例如，对于技术支持，可以添加“你使用检索到的文档中类似事件的信息回答查询。”
  • 如果数据具有某些特征，可以将这些详细信息添加到系统消息。 例如，如果你的文档是日语文档，则可以添加“你将检索日语文档，应仔细阅读日语文档并用日语回答。”
  • 如果文档包含结构化数据（例如财务报告中的表格），还可以将此事实添加到系统提示中。 例如，如果数据包含表格，则可以添加“你以与财务结果相关的表格形式提供数据，并且应逐行读取表格以执行计算来回答用户问题。”

定义输出样式

还可以通过定义系统消息来更改模型的输出。 例如，如果要确保助手的回答采用法语，可以添加类似于“你是一名 AI 助手，可帮助懂法语的用户查找信息。用户问题可能采用英语或法语。请仔细阅读检索到的文档，然后用法语回答。请将文档中的知识翻译为法语，以确保所有答案都是法语。”

再次确认重要行为

基于自有数据的 Azure OpenAI 的工作原理是，以提示的形式向大型语言模型发送指令，以使用数据回答用户查询。 如果某个行为对应用程序至关重要，则可以在系统消息中重复该行为以提高其准确性。 例如，若要引导模型仅从文档回答，可以添加“请仅使用检索到的文档进行回答，而不使用你的知识。请为回答中的每个观点生成对检索到的文档的引用。如果无法使用检索到的文档回答用户问题，请解释文档与用户查询相关的原因。无论如何，请勿用自己的知识回答。”

提示工程技巧

提示工程中有许多技巧，你可以利用它们尝试改进输出。 一个例子是思维链提示，你可以在其中添加“让我们逐步思考检索到的文档中的信息，以回答用户查询。逐步从文档中提取与用户查询相关的知识，并根据从相关文档中提取的信息形成答案。”

注意

系统消息用于修改 GPT 助手根据检索到的文档响应用户问题的方式。 这不会影响检索过程。 如果要提供检索过程的说明，最好将其包含在问题中。 系统消息仅供指导。 该模型可能不会遵循每个指定的指令，因为它已被灌输了某些行为，例如保持客观性和避免给出有争议的说法。 如果系统消息与这些行为相矛盾，则可能会发生意外行为。

回复上限

对每个模型回复的标记数设置限制。 基于自有数据的 Azure OpenAI 的上限为 1500。 这相当于在 API 中设置 max_tokens 参数。

仅限使用自有数据回复

此选项可促使模型仅使用你的自有数据进行回复，并且默认处于选中状态。 如果取消选择此选项，模型可能更倾向于应用其内部知识进行响应。 根据用例和方案确定正确的选择。

与模型交互

在与模型聊天时，请使用以下做法获得最佳结果。

会话历史记录

  • 在开始新对话（或提出与以前的问题无关的问题之前），请清除聊天历史记录。
  • 在第一个对话轮次和后续轮次之间，同一个问题可能会得到不同的回复，因为对话历史记录会更改模型的当前状态。 如果收到不正确的答案，请将其报告为质量 bug。

模型回复

  • 如果对某个特定问题的模型响应不满意，请尝试将问题修改得更具体或更普通，以查看模型如何回复，并相应地重新调整问题框架。

  • 经证明，思维链提示可以有效地让模型对复杂问题/任务生成所需的输出。

问题长度

请避免提出长问题，如果可能，请将其分解为多个问题。 GPT 模型对可接受的词元数有限制。 要计入词元限制的内容包括：用户问题、系统消息、检索的搜索文档（区块）、内部提示、对话历史记录（若有）以及回复。 如果问题超过词元限制，将会截断。

多语种支持

  • 目前，基于自有数据的 Azure OpenAI 中的关键字搜索和语义搜索支持的查询语言与索引数据中的相同。 例如，如果你的数据使用日语，则输入查询也需要使用日语。 对于跨语言的文档检索，建议在启用矢量搜索的情况下生成索引。

  • 为了帮助提高信息检索和模型响应的质量，我们建议为以下语言启用语义搜索：英语、法语、西班牙语、葡萄牙语、意大利语、德国、中文 (Zh)、日语、韩语、俄语、阿拉伯语

  • 建议使用系统消息来通知模型你的数据使用另一种语言。 例如：

  • *“*你是一名 AI 助手，旨在帮助用户从检索的日语文档中提取信息。请在制定答复之前仔细审查日语文档。用户的查询将采用日语，还必须使用日语进行响应。”

  • 如果文档有多种语言，建议为每种语言生成一个新索引，并将其单独连接到 Azure OpenAI。

流式处理数据

可以使用 stream 参数发送流式请求，实现以增量方式发送和接收数据，而无需等待整个 API 回复。 这可以提高性能和用户体验，尤其是对于大型或动态数据。

{
    "stream": true,
    "dataSources": [
        {
            "type": "AzureCognitiveSearch",
            "parameters": {
                "endpoint": "'$AZURE_AI_SEARCH_ENDPOINT'",
                "key": "'$AZURE_AI_SEARCH_API_KEY'",
                "indexName": "'$AZURE_AI_SEARCH_INDEX'"
            }
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "What are the differences between Azure Machine Learning and Azure AI services?"
        }
    ]
}

用于取得更好结果的对话历史记录

与模型聊天时，提供聊天历史记录将有助于模型返回更高质量的结果。 无需在 API 请求中包含助手消息的 context 属性即可获得更好的响应质量。 有关示例，请查看 API 参考文档。

函数调用

某些 Azure OpenAI 模型允许定义工具和 tool_choice 参数以启用函数调用。 可以通过 REST API /chat/completions设置函数调用。 如果要求中同时包含 tools 和 数据源，则会应用以下策略。

  1. 如果 tool_choice 是 none，则会忽略这些工具，并且仅使用数据源生成答案。
  2. 否则，如果未指定 tool_choice 或指定为 auto 或一个对象，则会忽略数据源，并且响应将包含所选函数名称和参数（如果有）。 即使模型决定不选择任何函数，数据源仍将被忽略。

如果上述策略未满足你的需求，请考虑其他选项，例如：提示流或助手 API。

基于自有数据的 Azure OpenAI 的令牌使用量估计值

Azure OpenAI On Your Data 检索增强生成 (RAG) 服务利用搜索服务（例如 Azure AI 搜索）和生成（Azure OpenAI 模型）来让用户根据提供的数据获取问题的答案。

作为此 RAG 管道的一部分，有三个大步骤：

  1. 将用户查询重新转换为搜索意向列表。 为此，请通过包含指令、用户问题和对话历史记录的提示调用模型。 让我们称之为“意向提示”。

  2. 对于每个意向，都会从搜索服务中检索多个文档区块。 根据用户指定的严格阈值筛选掉不相关的区块，并根据内部逻辑对区块进行重新排序/聚合后，将会选择用户指定的所选文档区块数。

  3. 这些文档区块以及用户问题、对话历史记录、角色信息和指令将发送到模型，以生成最终的模型响应。 让我们称之为“生成提示”。

总共会对模型进行两次调用：

  • 用于处理意向：“意向提示”的令牌估算将包括针对发送到模型以生成意向的用户问题、对话历史记录和指令的令牌。

  • 用于生成响应：“生成提示”的令牌估算将包括针对发送到模型以生成响应的用户问题、对话历史记录、检索到的文档区块列表、角色信息和指令的令牌。

在估算总令牌数时，需要考虑模型生成的输出令牌（意向和响应）。 将下面的四列相加，即可得出用于生成响应的平均总令牌数。

模型 生成提示令牌计数 意向提示令牌计数 响应令牌计数 意向令牌计数
gpt-35-turbo-16k 4297 1366 111 25
gpt-4-0613 3997 1385 118 18
gpt-4-1106-preview 4538 811 119 27
gpt-35-turbo-1106 4854 1372 110 26

上述数字是基于对具有以下特性的数据集的测试得出的：

  • 191 个对话
  • 250 个问题
  • 每个问题平均 10 个令牌
  • 每个对话平均 4 个对话轮次

以及以下参数。

设置 “值”
检索的文档数 5
严格性 3
区块大小 1024
使响应限于引入的数据？ True

这些估算将根据为上述参数设置的值的不同而有所不同。 例如，如果将检索的文档数设置为 10 且将严格性设置为 1，则令牌计数将会上升。 如果返回的响应不限于引入的数据，那么为模型提供的指令将会减少，令牌数将会下降。

这些估算还取决于文档的性质和所问的问题。 例如，如果问题是开放式的，则响应可能会更长。 同样，较长的系统消息会导致使用更多令牌的较长提示，而且如果会话历史记录较长，提示也会较长。

模型 用于系统消息的最大令牌数
GPT-35-0301 400
GPT-35-0613-16K 1000
GPT-4-0613-8K 400
GPT-4-0613-32K 2000
GPT-35-turbo-0125 2000
GPT-4-turbo-0409 4000
GPT-4o 4000
GPT-4o-mini 4000

上表显示了可用于系统消息的最大令牌数。 若要查看模型响应的最大令牌，请参阅模型文章。 此外，以下项也使用令牌：

  • 元提示：如果你将模型响应设为限于基础数据内容（API 中的 inScope=True），则最大令牌数会更高。 否则（例如，如果 inScope=False），则最大值较低。 此数量是可变的，具体取决于用户问题和聊天历史记录的令牌长度。 此估计值包括基本提示以及用于检索的查询重写提示。

  • 用户问题和历史记录：可变但上限为 2,000 个令牌。

  • 检索的文档（区块）：检索的文档区块使用的令牌数取决于多个因素。 此数量的上限是检索的文档区块数乘以区块大小。 然而，在对其余字段进行计数后，它将根据所使用的特定模型的可用令牌进行截断。

    20% 的可用令牌保留用于模型响应。 其余 80% 的可用令牌包括元提示、用户问题和对话历史记录以及系统消息。 检索的文档区块使用剩余的令牌预算。

若要计算输入（例如问题、系统消息/角色信息）使用的令牌数，请使用以下代码示例。

import tiktoken

class TokenEstimator(object):

    GPT2_TOKENIZER = tiktoken.get_encoding("gpt2")

    def estimate_tokens(self, text: str) -> int:
        return len(self.GPT2_TOKENIZER.encode(text))
      
token_output = TokenEstimator.estimate_tokens(input_text)

故障排除

若要对失败的操作进行故障排除，请始终查找 API 响应或 Azure OpenAI Studio 中指定的错误或警告。 下面是一些常见的错误和警告：

失败的引入作业

配额限制问题

无法在服务 Y 中创建名为 X 的索引。 此服务已超出索引配额。 必须先删除未使用的索引，在索引创建请求之间添加延迟，或升级服务以提高限制。

此服务已超出 X 的标准索引器配额。 你当前具有 X 标准索引器。 必须先删除未使用的索引器，更改索引器“executionMode”，或升级服务以提高限制。

解决方法：

升级到更高的定价层或删除未使用的资产。

预处理超时问题

由于 Web API 请求失败，无法执行技能

由于 Web API 技能响应无效，无法执行技能

解决方法：

将输入文档分解为较小的文档，然后重试。

权限问题

该请求无权执行此操作

解决方法：

这意味着使用给定凭据无法访问存储帐户。 在这种情况下，请查看传递给 API 的存储帐户凭据，并确保存储帐户不会隐藏在专用终结点后面（如果未为此资源配置专用终结点）。

每个用户消息都可以转换为多个搜索查询，所有这些查询都会并行发送到搜索资源。 当搜索副本和分区的数量较少时，这可能会导致限制行为。 单个分区和单个副本可以支持的每秒查询数可能不足。 在这种情况下，请考虑增加副本和分区，或在应用程序中添加睡眠/重试逻辑。 有关详细信息，请参阅 Azure AI 搜索文档。

区域可用性和模型支持

区域 gpt-35-turbo-16k (0613) gpt-35-turbo (1106) gpt-4-32k (0613) gpt-4 (1106-preview) gpt-4 (0125-preview) gpt-4 (0613) gpt-4o** gpt-4 (turbo-2024-04-09)
澳大利亚东部 ✅ ✅ ✅ ✅ ✅
加拿大东部 ✅ ✅ ✅ ✅ ✅
美国东部 ✅ ✅ ✅
美国东部 2 ✅ ✅ ✅ ✅
法国中部 ✅ ✅ ✅ ✅ ✅
日本东部 ✅
美国中北部 ✅ ✅ ✅
挪威东部 ✅ ✅
美国中南部 ✅ ✅
印度南部 ✅ ✅
瑞典中部 ✅ ✅ ✅ ✅ ✅ ✅
瑞士北部 ✅ ✅ ✅
英国南部 ✅ ✅ ✅ ✅
美国西部 ✅ ✅ ✅

**这是一个简单的仅文本实现

如果 Azure OpenAI 资源位于另一个区域，则无法使用基于自有数据的 Azure OpenAI。

后续步骤