你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Important
仅为方便起见，提供非英语翻译。 请参阅 EN-US 版本以获取最终版本的此文档。
许多 Azure OpenAI 模型都是生成 AI 模型，这些模型演示了内容和代码生成、摘要和搜索等高级功能方面的改进。 由于这些改进，许多与有害内容、操控、类似人类行为、隐私等相关的负责任AI挑战也增加了。 有关这些模型的功能、限制和适当用例的详细信息，请查看 透明度说明。
除了透明度说明之外，我们还提供技术建议和资源，帮助客户设计、开发、部署和使用负责任的 Azure OpenAI 模型。 我们的建议以 Microsoft负责任的 AI 标准为基础，该标准设置我们自己的工程团队遵循的策略要求。 标准的大部分内容都遵循一种模式，要求团队识别、衡量和缓解潜在危害，并计划如何作 AI 系统。 根据这些做法，这些建议分为四个阶段：
- 确定：通过迭代的红队演练、压力测试和分析，确定 AI 系统可能产生的潜在危害，并设定其优先级。
- 度量 值：通过建立明确的指标、创建度量测试集以及完成迭代、系统测试（手动和自动化）来衡量这些伤害的频率和严重性。
- 缓解 ：通过实施工具和策略（如 提示工程 和使用 内容筛选器）来缓解危害。 在实施缓解措施后，重复度量以测试有效性。
- 操作 ：定义和执行部署和运营准备计划。
除了与Microsoft负责任的 AI 标准通信外，这些阶段还与 NIST AI 风险管理框架中的功能密切相关。
Identify
负责任的 AI 生命周期的第一个阶段是确定 AI 系统可能发生或导致的潜在危害。 在你越早开始确定潜在危害时，你就能更有效地减轻它们。 评估潜在危害时，请了解特定上下文中使用 Azure OpenAI 服务可能导致的危害类型。 本部分提供可用于通过影响评估、迭代红队测试、压力测试和分析来识别危害的建议和资源。 红队测试和压力测试是一组测试人员有意探测系统以确定其限制性、风险面暴露和漏洞的方法。
这些步骤为每个特定方案生成潜在危害的优先列表。
- 确定与特定模型、应用程序和部署方案相关的危害。
- 确定与系统中使用的模型和模型功能（例如 GPT-3 模型与 GPT-4 模型）关联的潜在危害。 每个模型具有不同的功能、限制和风险。
- 确定你正在开发的系统的预期使用带来的任何其他伤害或增加的危害范围。 请考虑使用 负责任的 AI 影响评估 来确定潜在的危害。
- 例如，请考虑汇总文本的 AI 系统。 文本生成的某些用途比其他用途风险更低。 如果系统在医疗保健领域用于汇总医生笔记，由不准确而导致的伤害风险要高于系统总结在线文章时的风险。
- 根据风险元素（例如频率和严重性）确定危害的优先级。 评估每个伤害的风险级别以及每个风险发生的可能性，确定确定的伤害列表的优先级。 在适当的时候，可以与组织内部的主题专家和风险管理人员合作，并与相关的外部利益干系人进行沟通。
- 从优先级最高的危害开始进行红队测试和压力测试。 更好地了解在你的情境中已识别的危害是否发生以及如何发生。 确定最初未预料到的新危害。
- 使用组织的内部合规性流程与相关利益干系人共享此信息。
在此标识阶段结束时，你有一个有记录的、优先的危害列表。 当新的伤害和新伤害实例通过进一步测试和使用系统出现时，请更新和改进此列表。
Measure
确定优先的伤害列表后，制定一种方法来系统测量每个伤害并评估 AI 系统。 可以使用手动和自动化方法来度量。 建议使用这两种方法，从手动度量开始。
手动度量的适用场景：
- 衡量一小部分优先问题的进展情况。 在缓解特定危害时，最有效的做法通常是继续手动检查小型数据集的进度，直到不再观察到危害，然后再转向自动度量。
- 定义并报告指标，直到自动度量足够可靠，才能单独使用。
- 定期抽查以评估自动度量的质量。
自动度量的适用场景：
- 大规模度量并增加覆盖范围，从而提供更全面的结果。
- 随着系统、使用情况和缓解措施的发展，进行持续度量来监视是否有任何性能回归。
以下建议可帮助你衡量 AI 系统的潜在危害。 建议先手动完成此过程，然后制定计划将其自动化：
创建可能生成每个优先伤害的输入： 通过生成许多可能生成优先伤害的目标输入的各种示例来创建度量集。
生成系统输出： 将度量集中的示例作为输入传入系统以生成系统输出。 记录输出。
评估系统输出并向相关利益干系人报告结果
- 定义明确的指标。 对于系统的每个预期用途，建立度量每个潜在有害输出的频率和严重性指标。 针对你确定的每种优先伤害类型，创建明确的定义，对系统与方案上下文中认为有害或有问题的输出进行分类。
- 根据明确的指标定义评估输出。 记录和量化有害输出的发生。 定期重复测量以评估缓解措施并监视任何回归。
- 使用组织的内部合规性流程与相关利益干系人共享此信息。
在此度量阶段结束时，应具有一种定义的度量方法，用于对系统针对每个潜在危害以及初始记录的结果集进行基准测试。 继续实施和测试缓解措施时，请优化指标和度量集。 例如，为最初未预料到的新危害添加指标。 更新结果。
Mitigate
缓解像 Azure OpenAI 模型这样的大型语言模型可能带来的风险，需要一种迭代的分层方法，这种方法包括试验和持续度量。 建议制定一个缓解计划，该计划包含四层缓解措施，这些缓解措施适用于你在此过程的早期阶段确定的危害：
- 在 模型级别，了解你使用的模型以及模型开发人员为使模型与预期用途保持一致以及降低潜在有害用途和结果风险的微调步骤。
- 例如，开发人员使用强化学习方法作为负责任的 AI 工具，以便更好地将 GPT-4 与设计人员的预期目标保持一致。
- 在 安全系统级别，了解开发人员实现的平台级别缓解措施，例如 Azure OpenAI 内容筛选器 ，有助于阻止有害内容的输出。
- 在 应用程序级别，应用程序开发人员可以实现元项目和以用户为中心的设计和用户体验缓解措施。 元提示是用于指导模型行为的指示。 他们的使用在指导系统按照预期行事方面可能会产生重大影响。 以用户为中心的设计和用户体验（UX）干预也是防止滥用和过度依赖 AI 的关键缓解工具。
- 在 定位级别，向使用或受系统影响的人员讲解其功能和限制。
以下各节提供了特定建议，用于在不同层实施缓解措施。 并非所有这些缓解措施都适用于每个方案。 相反，这些缓解措施可能不足以满足某些方案。 仔细考虑你的方案以及你确定的优先伤害。 实施缓解措施时，制定一个流程来 衡量和记录系统 与方案的有效性。
模型级别缓解措施： 查看并确定最适合要构建的系统的 Azure OpenAI 基础模型。 自行了解其功能、限制和采取的任何措施，以降低你确定的潜在危害的风险。 例如，如果使用 GPT-4，除了阅读此透明度说明外，请查看 OpenAI 的 GPT-4 系统卡 ，该卡片解释了模型提出的安全挑战以及 OpenAI 为部署准备 GPT-4 而采用的安全流程。 尝试不同版本的模型（包括通过红队测试和衡量），来观察危害如何以不同方式呈现。
安全系统级别缓解措施： 确定和评估平台级解决方案（如 Azure OpenAI 内容筛选器 ）的有效性，以帮助缓解你识别的潜在危害。
应用程序级别缓解措施：提示工程（包括元提示调优）可以是有效应对多种不同伤害的缓解措施。 查看并实施元提示（也称为“系统消息”或“系统提示”）指南，以及此处记录的最佳实践。
实现以下以用户为中心的设计和用户体验（UX）干预、指导和最佳做法，指导用户按预期使用系统，并防止 AI 系统上过度依赖：
- 查看和编辑干预： 设计用户体验（UX），以鼓励使用系统查看和编辑 AI 生成的输出，然后再接受它们（请参阅 HAX G9：支持高效更正）。
- 突出显示 AI 生成的输出中可能存在的不准确之处 （请参阅 HAX G2：明确系统能够执行的功能），无论是在用户首次开始使用系统时，还是在持续使用期间的适当时机。 在第一次运行体验 (FRE) 中，通知用户 AI 生成的输出可能包含不准确之处，应验证信息。 在整个体验中提醒检查 AI 生成的输出是否有潜在的不准确，包括整体和与系统可能生成的特定内容类型相关的错误。 例如，如果测量过程确定系统对数字的准确性较低，请在生成的输出中标记数字以提醒用户，并鼓励他们检查数字或寻求外部源进行验证。
- 用户责任。 提醒人们，他们在查看 AI 生成的内容时对最终内容负责。 例如，在提供代码建议时，提醒开发人员在接受之前查看和测试建议。
- 披露 AI 在交互中的作用。 让人们意识到他们正在与 AI 系统（而不是另一个人）交互。 在适当情况下，通知内容使用者内容部分或完全由 AI 模型生成。 法律或适用的最佳做法可能要求此类通知。 他们可以减少对 AI 生成的输出的不适当的依赖，并可以帮助消费者使用自己的判断来解释和处理此类内容。
- 防止系统进行人为化。 AI 模型可能会输出包含观点、表情陈述或其他可能暗示它们类似于人的内容。 此类内容可能误认为是人为身份。 此类内容可能会误导人们认为系统在没有时具有某些功能。 实现降低此类输出风险或合并披露的机制，以帮助防止错误解释输出。
- 引证引用和信息来源。 如果你的系统基于发送到模型的引用生成内容，则清楚地引证信息源有助于人们了解 AI 生成的内容来自何处。
- 根据需要限制输入和输出的长度。 限制输入和输出长度可以减少产生不良内容、超出预期用途滥用系统或者其他有害或意外使用的可能性。
- 构造输入和/或系统输出。 使用应用程序中的 提示工程 技术来构建对系统的输入，以防止开放式响应。 还可以将输出限制为以某些格式或模式进行结构化。 例如，如果系统为虚构字符生成对话来响应查询，请限制输入，以便人们只能查询预先确定的概念集。
- 准备预先确定的响应。 模型会收到可能生成冒犯性、不当或其他有害响应的某些查询。 检测到有害或冒犯性查询或响应时，可以设计系统来向用户提供预先确定的响应。 应深思熟虑地制定预先确定的响应。 例如，应用程序可以提供预写的答案来回答“你是谁？”等问题，以避免系统使用人为化响应做出响应。 还可以对诸如“使用条款是什么？”等问题使用预先确定的回答，将人员定向到正确的策略。
- 限制在社交媒体上自动发布。 限制用户如何自动执行产品或服务。 例如，可以选择禁止将 AI 生成的内容自动发布到外部网站（包括社交媒体），或禁止自动执行生成的代码。
- 机器人检测。 设计并实施一种机制，禁止用户在产品的基础上生成 API。
定位级别缓解措施：
- 适当透明。 为使用系统的人员提供适当的透明度，以便他们可以就使用系统做出明智的决策。
- 提供系统文档。 为你的系统生成并提供教育材料，包括其功能和限制的解释。 例如，此内容可能采用通过系统访问的“了解详细信息”页面的形式。
- 发布用户指南和最佳做法。 通过发布最佳做法，帮助用户和利益干系人适当地使用系统，例如提示创建、在接受生成的内容之前进行评审等。 此类指南可以帮助人们了解系统的工作原理。 尽可能将准则和最佳做法直接合并到 UX 中。
实施缓解以解决潜在识别的危害时，请制定一个过程，以持续衡量此类缓解措施的有效性。 记录测量结果。 查看这些度量结果以不断改进系统。
Operate
设置度量和缓解系统后，定义和执行部署和执行作准备计划。 这一阶段包括与相关利益干系人完成对系统和缓解计划的相应评审、建立收集遥测数据和反馈的管道，以及制定事件响应与回滚计划。
请考虑以下建议，用于部署和操作使用 Azure OpenAI 服务的系统，并具备适当、有针对性的危害缓解措施：
与组织中的合规性团队协作，了解系统需要哪些类型的评审以及何时完成评审。 评审可能包括法律评审、隐私评审、安全评审、辅助功能评审等。
开发和实现以下组件：
- 分阶段交付计划。 通过分阶段交付方法逐步启动使用 Azure OpenAI 服务的系统。 此方法使一组有限的人员有机会尝试系统、提供反馈、报告问题和关注点，并在系统发布更广泛之前建议改进。 它还有助于管理意外故障模式、意外系统行为和报告意外问题的风险。
- 事件响应计划。 制定事件响应计划，并评估响应事件所需的时间。
- 回滚计划。 确保在发生意外事件时，能够快速、有效地回滚系统。
- 立即采取行动，处理意料之外的伤害。 构建必要的功能和流程，在发现有问题的提示和响应时尽可能接近实时地阻止它们。 发生意外的危害时，请尽快阻止有问题的提示和响应。 开发和部署适当的缓解措施。 调查事件并实施长期解决方案。
- 阻止滥用系统的人员的机制。 制定一种机制来识别违反内容策略的用户（例如，发布仇恨言论），或者出于非预期或有害目的使用系统的用户。 采取行动，防止进一步滥用。 例如，如果某个用户频繁地使用系统生成被内容安全系统阻止或标记的内容，可以考虑禁止其继续使用系统。 建立适当的申诉机制。
- 有效的用户反馈渠道。 实施反馈渠道，确保利益干系人（如适用，甚至是公众）能够提交反馈或报告生成内容中的问题，或在使用系统过程中遇到的其他问题。 记录您如何处理、考虑和回应此类反馈。 评估反馈意见，并根据用户的反馈不断优化系统。 一种方法是包含生成的内容的按钮，允许用户将内容识别为“不准确”、“有害”或“不完整”。此方法可以提供更广泛使用、结构化和反馈信号进行分析。
- 遥测数据。 识别并记录（符合适用隐私法律、政策及承诺的前提下）能够反映用户满意度或能否按预期使用系统的信号。 使用遥测数据来识别差距并改进系统。
本文件不构成法律建议，不应被视为提供法律建议。 你所在的司法管辖区可能有各种适用于你的 AI 系统的监管或法律要求。 如果你不确定哪些法律或法规可能适用于你的系统，特别是如果你认为这些法律或法规可能会影响这些建议，请咨询法律专家。 请注意，并非所有这些建议和资源都适用于每种情况，相反，这些建议和资源可能不足以满足某些情况的需求。