Azure-OpenAI-解锁创意-使用-Azure-OpenAI-释放生成式-AI-创新的实用指南-三-
Azure OpenAI 解锁创意:使用 Azure OpenAI 释放生成式 AI 创新的实用指南(三)
译者:飞龙
| Dall-3 | dall-e-3 | 3.0 | Succeeded | 2025-04-29 19:00 PM |
| gpt-4 | gpt-4 | 2024-08-06 | Succeeded | 2025-08-19 19:00 PM |
图 10.3:模型部署
重要提示
关于设置具有活动订阅的 Azure 账户以及 Azure OpenAI 服务的详细信息请见第 2 章。
使用 Azure OpenAI Assistants API 创建多模态多代理框架
现在,使用以下配置设置三个助手(Assistants):
- 第一,使用以下代码设置
user_proxy代理:
user_proxy = assistant_client.beta.assistants.create(
name=name_pa,
instructions=instructions_pa,
model=assistant_deployment_name,
tools=tools
)
- 接下来,使用以下代码设置
dalle_assistant代理:
dalle_assistant = assistant_client.beta.assistants.create(
name=name_dl,
instructions=instructions_dl,
model=assistant_deployment_name,
tools=tools
)
- 最后,使用以下代码设置
vision_assistant代理:
vision_assistant = assistant_client.beta.assistants.create(
name=name_dl,
instructions=instructions_dl,
model=assistant_deployment_name,
tools=tools
)
用户代理助手(User Proxy Assistant)线程充当主要的通信通道,促进代理之间的消息交换以满足用户请求,如图 10.4 所示:
用户代理代理
创建多模态多代理框架
使用以下代码初始化用户代理助手:
thread = assistant_client.beta.threads.create()
唯一的输入是用户的查询,它驱动了跨所有助手的整体任务执行。该查询通过此处显示的 dispatch_message() 函数传输到用户代理助手线程:
user_message = input("User Query")
message = dispatch_message(user_message, user_proxy, thread)
用户代理助手设计用于将消息路由到适当代理以确保任务完成。send_message() 函数通过利用 agents_threads 结构促进这一过程,该结构在整个对话过程中维护代理及其相应线程的记录,确保了无缝通信和任务执行:
agents_threads: Dict[str, Dict[str, Optional[str]]] = {
"dalle_assistant": {"agent": dalle_assistant, "thread": None},
"vision_assistant": {"agent": vision_assistant, "thread": None},
}
如果用户代理助手和其他代理之间不存在线程,则创建一个新线程来启动对话,确保通信的顺畅和任务的执行:
# 如果用户代理和代理线程不存在,则创建一个新线程
if not recipient_info["thread"]:
thread_object = assistant_client.beta.threads.create()
recipient_info["thread"] = thread_object
例如,当用户代理助手需要与 DALL-E 助手交互时,它会在两个代理之间建立新线程以促进通信,如图所示:
使用 Azure OpenAI Assistants API 创建多模态多代理框架
send_message() 函数调用另一个函数来创建并分发消息给相应的代理,确保任务高效执行:
message = dispatch_message(query, recipient_info["agent"])
dispatch_message() 函数识别并检索指定助的所有所有可用函数。它利用 agent.tool 函数来注册这些能力,并将它们添加到助手的可用函数字典中以便执行:
available_functions = {}
# 遍历 agent.tools 列表中的每个工具
for tool in agent.tools:
# 检查工具是否具有 'function' 属性
if hasattr(tool, 'function'):
function_name = tool.function.name
# 尝试通过名称检索函数并将其
# 添加到可用函数字典中
if function_name in globals():
globals()[function_name] = tool.function[function_name]
else:
# 处理工具不具有 'function' 属性的情况
print("This tool does not have a 'function' attribute.")
dispatch_message() 函数通过在线程中生成新消息并调用助手的 create() 函数,将消息引导至适当的助手以执行任务。此过程在用户代理助手线程中处理用户查询时同样适用:
作为正在进行的对话的一部分草拟新消息
message = assistant_client.beta.threads.messages.create(
thread_id=thread.id, role="user", content=message)
# 执行此讨论线程中概述的任务
run = assistant_client.beta.threads.runs.create(
thread_id=thread.id,
assistant_id=agent.id,
)
助手的线程运行(run)函数评估给定任务是否需要特定的工具或函数。如果识别出需求,它会将相关函数分配给助手进行执行。一旦调用,该函数将处理任务并返回输出,然后输出存储在 tool_response 对象中:
# 如果需要操作,则执行适当函数来执行任务
if run.status == "required_action":
tool_calls = run.required_action.submit_tool_outputs(
tool_outputs=[]
for tool_call in tool_calls:
# (由于原文 OCR 存在逻辑碎片,此处遵循原文结构翻译)
...(注:提供的原始文本包含大量重复和损坏的代码块,已根据逻辑流进行清理翻译)
Dalle Assistant: 正在创建图像...
Vision Assistant: 正在分析图像...
Vision Assistant: 图像展示了一幅美丽而宁静的风景,捕捉了在如画般的日出或日落时分水面上的一艘传统木船。水面静如镜,船只以及远处其他船只和某些结构的影子完美地倒映在其中,增强了图像整体的宁静感。天空的色调从橙色和粉色过渡到蓝色,营造出一种梦幻而和平的氛围。横跨天空的一排飞鸟增添了动态元素,并传达出自由的感觉。
分析
-
细节与纹理: 虽然整体构图很有吸引力,但船只的纹理可以增强以提高真实感。目前它看起来有些平滑,这可能会削弱潜在的木纹细节。
-
光照: 环境光线处理得很好,但可以应用更多对比度,使船只的特征更加突出,并增加场景的深度,特别是背景中的结构。
-
背景元素: 背景中出现的结构引人注目并增加了深度,但缺乏清晰度。提供更多细节或建议特定类型的结构可以增强场景的叙事性。
-
前景趣味性: 也许可以在前景中加入额外的元素,如水面上细微的波纹或附近的野生动物,在不破坏其简洁性的前提下为场景增添更多趣味和活力。
为 DALL-E 增强的提示词:创建一个宁静的场景,在生动的日落时分,宁静的湖面上有一艘具有详细木纹纹理的传统木船。天空应为暖橙色和粉色到冷蓝色的渐变,在水面上投射出柔和的反光。背景中,高脚支撑的模糊结构营造了一个神秘的环境,具有足够的清晰度来暗示它们的文化意义。船周围的水面泛起微波暗示着运动,并在前景中微妙地整合几只野生动物以增加生动的元素,同时又不损害场景的宁静。
Dalle Assistant: 正在创建图像...
只需一次用户输入,你就可以看到 DALL-E 和 Vision Assistant 如何协作来提高图像质量——展示了多智能体系统的力量。
总结
在本章中,我们探索了如何使用 Azure OpenAI Assistants API 构建多智能体系统。带有 Azure AI Assistants API 的智能体框架为 AI 驱动协作的演变格局提供了宝贵的见解。通过利用 Azure 生态系统中基于 LLM 的智能体功能,我们可以构建一个专业智能体网络来增强系统智能,使其能够动态处理复杂任务并做出明智决策。通过建立助手、管理通信线程、发送消息和执行函数,我们概述了一个开发者可以采用的结构化方法。
在下一章中,我们将重点转向与 AOAI 相关的隐私和安全关键主题。在之前的章节中,我们已经探索了使用 AOAI 结合各种 Azure AI 服务进行实际解决方案的开发和实现,现在我们将深入研究保护数据和确保合规的关键考虑因素。本章将涵盖 OpenAI 服务合规性、数据隐私、内容过滤、托管身份、虚拟网络配置、私有端点配置、数据加密以及 Azure OpenAI 的负责任 AI 等主题。这些领域对于在企业环境中构建安全可靠的 AI 解决方案至关重要。
第三部分:使用 Azure OpenAI 精通治理、运营和 AI 优化
在最后一部分,我们将重点从创建解决方案转向掌握 Azure OpenAI 治理、部署和高级优化策略的关键要素。这部分将为你提供相关知识,以保护其实现方案、有效地运营其 AI 解决方案,并通过高级提示词工程技术最大化生成式 AI 的潜力。
你将探索基本的隐私和安全实践以确保合规性和数据保护,深入研究高效管理资源的运营最佳实践,并获得编写精确且有力的提示词的见解。无论你是大规模部署 AI 还是针对特定用例优化其行为,本节提供了将你的 Azure OpenAI 解决方案转换为稳健、可靠且创新系统的工具。
本部分包含以下章节:
-
第 11 章:隐私与安全
-
第 12 章:Azure OpenAI 的运营化
-
第 13 章:高级提示词工程
11 隐私与安全
在之前的章节中,我们演示了结合各种 Azure AI 服务使用 Azure OpenAI (AOAI) 制作和实现实际解决方案的过程。在本章中,我们将关注与 AOAI 相关的隐私和安全考虑因素。
在本章中,我们将涵盖以下主题:
-
AOAI 服务合规性
-
AOAI 数据隐私
-
内容过滤
-
托管身份
-
虚拟网络 (VNet) 配置
-
私有端点配置
-
数据加密
-
AOAI 的负责任 AI
AOAI 服务合规性
AOAI 合规计划是微软建立的一系列政策和实践,旨在确保以负责任且符合伦理的方式使用 AOAI 服务。该计划包括以下方面:
-
数据、隐私和安全:微软提供了有关客户提供的数据如何被 AOAI 服务进行处理、使用和存储的细节。
-
负责任 AI 实践:微软提供技术指导和工具,支持客户负责任地设计、开发、部署和利用 AI 系统。这些建议符合微软负责任 AI 标准并涵盖四个阶段:识别、衡量、缓解和运营。
-
行为准则:微软定义了 AOAI 服务必须遵守的准则。准则涵盖了可用性、有害内容、人类交互和反馈等主题。
-
联邦风险与授权管理 (FedRAMP) 高级授权:微软已获得商业环境 AOAI 服务的高授权。这意味着该服务符合联邦政府对云服务提供者的最高安全要求。
-
健康保险流通性与责任法 (HIPAA) 合规性:微软已确认 AOAI 服务可以以符合 HIPAA 的使用。这意味着客户可以根据业务伙伴协议 (BAA) 处理保护健康信息 (PHI)。BAA 是确保 PHI 安全处理并符合 HIPAA 监管的关键文档。
-
系统和组织控制 (SOC) 1、2、3 是与组织系统和数据安全相关的标准和框架,由美国注册会计师协会 (AICPA) 开发和维护。这些标准帮助组织证明其保护敏感信息的承诺并确保其系统的可靠性。OpenAI 处理数据是为了提供服务以及防止可能发生的滥用。你的提示词(输入)和完成(输出),以及你的嵌入和训练数据不会与其他客户、OpenAI、微软或任何第三方产品或服务共享。客户微调的 OpenAI 模型仅供其使用。微软完全管理 AOAI 服务,在其 Azure 环境托管 OpenAI 模型,且该服务与 OpenAI 运行的任何服务都不连接。
重要说明
Azure 持续评估 AOAI 服务以纳入额外的合规认证。
要获取各种 Azure 产品的最新合规证明信息,请访问以下链接: https://servicetrust.microsoft.com/DocumentPage/7adf2d9e-d7b5-4e71-bad8-713e6a183cf3 。
在介绍了 AOAI 合规性后,让我们在接下来的章节中将您的注意力转向数据隐私的主题。
AOAI 数据隐私
本节提供了关于您提交到 AOAI 服务的数据的处理、利用和存储的见解。
AOAI 模型是无状态的,这意味着它们不会存储或记住来自之前输入或输出的任何信息。它们仅处理当前输入,并根据其模型参数以及任何可选设置(如温度或频率惩罚)生成输出。这种设计选择增强了模型的适应性和可扩展性,但在处理需要上下文或记忆的任务时会面临挑战。
为了解决这一局限性,您可以在输入中包含相关的上下文或历史信息,或者利用外部数据源通过额外的细节来补充输入。尽管如此,这些操作可能会引入潜在风险,包括与数据隐私和安全相关的担忧,以及模型被误用或滥用的可能。因此,微软已制定了各种保护措施,保护其模型和用户免受这些潜在威胁。这些措施包括内容过滤、速率限制和数据处理策略。
重要说明
与提示(prompts)、完成(completions)、嵌入(embeddings)和训练相关的数据受到限制,不会授予他人访问,也不会用于改进 OpenAI 或任何微软/第三方产品。微调后的 AOAI 模型仅供用户使用,由微软在 AOAI 服务内独家控制,与 OpenAI 提供的服务(如 ChatGPT 或 OpenAI API)不同。
AOAI 处理几类数据:
-
提示和完成数据:用户提交提示,服务通过完成和聊天对话等操作生成内容,并处理图像和嵌入(embeddings)。
-
与提示关联的增强数据:通过“使用您的数据(On Your Data)”功能,服务从指定的存储器访问数据并使用这些数据增强提示,从而生成与您的数据集直接连接的内容。
-
训练和验证数据:用户可以选择提供自己的训练数据,这些数据由提示和完成对组成,可用于针对特定目的微调 OpenAI 模型。
提供的图表概述了带有内容过滤的 AOAI 数据流程,我们将在下一节中讨论:
图 11.1:推理和微调的 AOAI 数据流
这包含了三个不同的处理场景:
-
用于内容生成的提示处理:顶部部分说明了 AOAI 服务如何获取您的提示并生成内容,包括使用 AOAI“使用您的数据”功能将来自外部源的额外数据整合到提示中。
-
创建微调(自定义)模型:底部概述了 AOAI 服务如何利用您的训练数据来构建微调模型,以满足您的特定需求和偏好。
-
AOAI 服务和微软人员的内容过滤:图表展示了 AOAI 服务如何结合微软人员对提示、完成内容和图像进行分析。该分析旨在识别潜在的有害内容和模式,这些模式可能表明服务被误用,违反了行为准则或其他相关条款。
部署在您的资源中的模型(无论是基础模型还是微调版本)都负责处理您提供的提示并生成响应,响应可能包括文本、图像、嵌入。服务以同步方式运行,实时评估提示和完成数据以监控潜在的有害内容类型。如果生成的内容超过了为此目的配置的阈值,服务将停止生成此类内容,以保持安全和合规的环境。
让我们讨论 AOAI 中“使用您的数据(Your Data)”功能的数据流。该功能允许 AOAI 服务与外部数据源进行交互,以增强提示并生成内容。
AOAI 中的“使用您的数据”功能允许您与外部数据源建立连接,使生成的结果与您的特定数据紧密相关。重要的是,这些数据安全地存储在指定的源和位置中;没有数据被复制或拷贝到 AOAI 服务本身。
当用户提交提示时,服务从连接的外部数据源动态检索相关数据,并使用这些额外的上下文信息增强用户提示。随后,模型处理此增强后的提示,然后返回生成的内容;这种技术被称为检索增强生成(RAG)。这种机制确保输出基于您的数据,而不会损害数据安全或隐私。接下来的图表说明了整个过程:
图 11.2:“使用您的数据”的 AOAI 数据流
在两张图中,您可能已经注意到 AOAI 异步监控滥用内容。让我们深入接下来的章节,以更好地了解 AOAI 防止滥用和有害内容的生成。
防止滥用和有害内容生成
为了降低 AOAI 服务被用于有害目的的风险,它包含了内容过滤和滥用监控功能。
实时内容过滤发生在服务处理提示以产生内容的过程中。提示和生成的的结果不会被用于训练、重新训练或改进内容分类器模型,也不会存储在这些模型中。关于内容过滤的更多细节将在本章的后续章节中提供。
滥用监控涉及识别和处理重复内容及行为,这些行为表明可能违反了行为准则或相关产品条款。为了检测和应对滥用,AOAI 安全地保留所有提示和生成的内容,最长为 30 天。
23. 你正在应用哪些修改?
请选择所有适用项。
-
修改滥用监控
-
修改内容过滤
图 11.3: 禁用滥用监控
一旦 Microsoft 批准了客户修改滥用监控的请求,当滥用监控被配置为禁用时,与 Azure 订阅相关的提示和完成将由 Microsoft 存储。在这种情况下,服务结果存储(Service Results Store)中不会存储任何提示和完成,也无法无法进行人工审核流程。
现在,让我们确保已就绪禁用滥用监控所需的配置。
验证滥用监控禁用
在 Azure 订阅中获准禁用滥用监控的客户可以通过两种方法确认滥用监控的数据存储已禁用:
-
使用 Azure 门户:
-
登录 Azure 门户
-
选择相应的 AOAI 服务资源
-
转到右上角的“概览”(Overview)视图,如图所示:
-
点击“JSON 视图”
-
图 11.4: 内容日志验证
在功能列表中,你会找到一个名为 ContentLogging 的值,当滥用日志关闭时,该值将显示为 FALSE。
- Azure CLI 或管理 API:或者,客户可以使用 Azure 命令行界面 (CLI) 或 Azure 提供的任何管理 API 以编程方式访问并检查其 Azure 订阅的监控状态。你可以在 Azure 中执行命令以查看与 Azure 门户所示相同的 JSON 数据:
az cognitiveservices account show -n resource_name -g resource_group
注意事项
只有在滥用监控的数据存储已禁用时,
ContentLogging属性才会显示为false。否则,该属性在 Azure 门户或 Azure CLI 的输出中均将不可见。
在上一节中,我们讨论了数据隐私、数据流和滥用监控的各个方面。现在,让我们将注意力转向内容过滤。
内容过滤
AOAI 服务集成了一种与其核心模型并排运行的内容过滤机制。该系统通过对提示(prompt)和完成(completion)应用一组分类模型来工作,这些模型旨在识别并减轻潜在有害内容的生成。它会积极识别并响应输入提示和输出完成中两种特定类型的潜在有害内容。值得注意的是,过滤行为可能会根据特定的 API 配置和应用程序的设计而异。
内容过滤模型已针对以下语言经过专门的训练和测试:英语、德语、日语、西班牙语、法语、意大利语、葡萄牙语和中文。该服务具有支持多种语言的能力,尽管性能质量可能不同。在任何情况下,都建议进行自己的测试以确认其是否适用于你的应用程序。
注意事项
AOAI Whisper 模型对提示和完成不使用内容过滤。
后续章节将提供有关内容的详细信息:
-
内容过滤类别
-
类别
-
严重性级别
-
-
可配置性
- 最佳实践
-
实现
内容过滤类别
在 AOAI 服务中,内容过滤系统集成了神经多类分类模型,专门用于检测和过滤有害内容。这些模型涵盖了四个不同的主要类别:仇恨(Hate)、性(Sexual)、暴力(Violence)和自伤害(Self-harm)。每个类别分为四个严重性级别:安全(Safe)、低(Low)、中(Medium)和高(High)。必须强调的是,被识别为“安全”级别的内容被标记为排除在过滤之外,且不能进行调整或自定义。此外还有针对文本和代码检测越狱(jailbreak)和保护材料的可选分类模型。
类别
这些是四个主要类别:
-
仇恨:基于种族、族群、宗教、性别、性取向等特征对个人或群体煽动仇恨或歧视的内容
-
性:包含显性或暗示性性语言、图像或主题的材料
-
暴力:描绘或倡导对个人或群体的身体伤害、受伤或暴力的内容
-
自伤害:鼓励或美化自残、自杀、进食障碍和其他自伤害的材料
除了这四个预定义类别外,客户还可以选择使用 Azure AI Content Safety 服务创建自己的自定义类别。这允许他们根据需要训练一个个性化的分类模型。要做到这一点,他们将需要训练数据来识别敏感内容、审核用户生成的内容或确保符合当地法规。
可选类别用于以下场景:
-
针对越狱攻击的提示防护(Prompt shields):越狱攻击是指用户故意设计的提示,旨在触发生成式 AI (GenAI) 模型,其方法是展示模型被训练要避免的行为或违反系统消息中建立的规则。这些直接攻击从复杂的角色扮演场景到破坏安全的微妙尝试。
-
针对间接攻击的提示防护:间接攻击(有时称为间接提示攻击或跨域提示注入攻击)是一种潜在的安全漏洞,外部实体在 GenAI 系统可访问的文档中嵌入有害指令。这种漏洞需要对文档进行嵌入和格式化,特别是在 RAG 类的架构中。
-
文本保护材料:保护材料文本包含可识别的内容,如歌词、文章、食谱和选定的网络内容,这些内容可能由大语言模型 (LLMs) 生成。
-
代码保护材料:保护材料代码指与公共存储库中预定义的代码片段匹配的源代码。LLMs 可能会输出此类代码而不正确引用原始源代码库。
严重性级别
这些是每个主要类别的四个严重性级别:
-
安全:内容确实涉及与暴力、自伤害、性或仇恨类别相关的话。然而,这些术语可能用于通用的、科学的、医学或专业的背景,适合广泛受众且不涉及冒犯意图。
-
低:内容可能涉及与暴力、自伤害、性或仇恨类别相关的话题。然而,这些术语可能用于通用的、科学的、医学或专业的背景,适合广泛受众且不涉及冒犯意图。
-
中:内容涉及针对特定身份群体的中等程度的冒犯、贬低、嘲讽、恐吓或轻蔑语言。此外,它可能包括寻求和执行有害指令、幻想和对伤害的美化。
-
高:内容展示了显性且高度有害的指令、行为、伤害或滥用。它还涵盖了对有害行为的支持、美化或促进,包括非法或非自愿的行为,以及与权力交换或滥用的内容。
到目前为止,我们讨论了内容过滤的各种类别及其相关的严重性级别。现在,让我们深入了解这些严重性级别如何被调整或配置。
可定制性
内容过滤的默认设置设定为在任何四个定义的有害内容类别中检测到中等严重性时启动过滤过程,这适用于用户提示和生成的响应。这意味着当内容被标记为中等或高严重性时,它将受到过滤。相反,被识别为低严重性的内容不会触发过滤机制。下表提供了每个严重性级别可用内容选项的详细信息:
| 严重性 | 提示可定制 | 完成可定制 | 描述 |
|---|---|---|---|
| 低、中、高 | 是 | 是 | 最高过滤级别:过滤低、中、高严重性内容。 |
| 中、高 | 是 | 是 | 默认设置:过滤中等和高严重性内容;不过滤低严重性内容。 |
| 高 | 需批准* | 需批准* | 过滤高严重性内容。过滤需要批准。 |
| 无过滤器 | 需批准* | 需批准* | 无论检测到的严重性级别如何,都不进行过滤。 |
表 11.1: 内容过滤配置
获得修改内容过滤设置权限的客户对这些过滤器具有完全控制权。他们可以选择将过滤器设置为仅在高严重性级别触发,或者选择完全关闭过滤。如果您希望请求修改内容过滤器的访问权限,请点击此链接填写表单:https://aka.ms/modifiedaccess。在填写表单时,请务必选择第 #23 项以激活高严重性内容过滤。此外,在第 #24 项中,请如下所示为该操作提供理由:
23. 您正在申请哪些修改? * *
请选择所有适用项。
-
修改监控
-
修改内容过滤器
24. 您为什么想要修改内容过滤器? * *
到目前为止,你已经了解了不同的 AOAI 内容过滤器及其配置。现在,让我们讨论一下实施内容过滤的一些最佳实践。
最佳实践
当内容过滤系统识别出有害内容时,你与 API 的交互将产生以下结果之一:
-
不恰当的提示词:如果输入提示词被判定包含不恰当内容,你将收到 HTTP 400 错误。
-
非流式完成:在对非流式完成应用内容过滤的情况下,被过滤的内容将不会返回。相反,响应中的
finish_reason值将设置为content_filter。在某些响应较长的极少数情况下,可能会返回部分结果,并带有更新的finish_reason值以指示内容状态。 -
流式完成:对于流式完成,内容片段将在生成时被返回。服务将保持其流式操作,直到遇到预定的停止标记、达到特定的长度限制,或识别出属于已设置过滤类别和严重性级别的内容。
在规划应用程序时,纳入以下最佳实践以确保良好的用户体验(UX)同时缓解潜在问题至关重要:
-
确定处理用户提交包含被分类为过滤类别和严重性级别内容的提示词,或用户滥用您的应用程序的情况的方法
-
检查
finish_reason值以识别完成内容是否经过了过滤 -
验证
content_filter_result值中不存在错误对象,这意味着内容过滤器已成功应用且在处理过程中没有遇到任何问题
让我们讨论一下如何通过 Azure Foundry 实际实施内容过滤。
实现
随后的指令演示了为你的 AOAI 资源建立个性化内容过滤配置的过程:
- 登录 Azure Foundry,按照下方红色框所示的左侧导航找到“内容过滤器”(Content filters)选项卡:
创建新的自定义内容过滤配置:
过滤器与核心模型协同工作。按类别创建过滤器并分配给部署。创建阻止列表以防止特定术语。
了解更多关于内容过滤器和阻止列表
图 11.7:创建自定义 AOAI 内容过滤器
这将你带到下一个配置屏幕,你可以在那里为你的自定义内容过滤设置选择名称。
在下一个屏幕上,为输入提示词的文本和图像内容过滤器类别设置阈值:
图 11.8:AOAI 自定义内容过滤器的默认设置
这是标准的内容审核设置页面,其中所有类别都处于中等水平监管内容。你可以灵活地对提示词和四个内容类别分别自定义内容审核严重性。每个类别有三个可调的严重性级别:低(Low)、中(Medium)和高(High)。
如果你的应用程序对暴力、仇恨、性及自残等内容类别需要更严格的阻止,请将阈值设置为低。要允许低类别的内容同时阻止中、高类别,请将阈值调整为中。最后,如果你想允许低、中类别的内容但阻止高类别,请将阈值设置为高。
清除过滤器以允许或阻止特定类型的内容
图 11.9:AOAI 自定义内容过滤器
- 对模型的输出内容遵循相同的步骤并相应地设置阈值。你也可以通过切换左下角的“标注”(Annotate)和“阻止”(block)功能,完全禁用输入和输出内容的内容过滤。或者,你可以通过选择“关闭”(Off)来关闭特定类别的内容过滤器。如果你选择仅“标注”,则 AOAI 内容过滤器系统将仅标记内容而不进行阻止:
隐私与安全
图 11.10:禁用 AOAI 自定义内容过滤器
注意事项
要执行第 #3 步,必须通过填写表单获取修改内容的批准:
https://aka.ms/modifiedaccess。
- 要激活内容过滤器,你需要将其分配给一个或多个部署。为了完成这一点,导航到“部署”(Deployments)选项卡并选择“编辑部署”(Edit deployment):
- 进入高级选项,并从“内容过滤器”下拉菜单为该部署选择适当的内容过滤器:
模型名称:gpt-35-turbo
模型版本:0125
部署类型:Standard
部署名称:gpt-35-turbo
内容过滤器:Default/CustomFilter
每分钟令牌数:600
每分钟请求数 (RPM):3600
启用动态配额:已启用
- 点击“保存并关闭”将所选配置应用于部署。之后,你将看到已应用于模型:
| 名称 | 模型版本 | 状态 | 模型截止日期 | 内容过滤器 | 部署类型 |
|---|---|---|---|---|---|
| dall-e | 3.0 | 成功 | 2025年4月29日 7:00 | Default | Standard |
| gpt-35-turbo | 1106 | 成功 | 2025年3月30日 7:00 | CustomFilter | Standard |
图 11.13:为 AOAI 模型配置过滤器
- 如果需要,你还可以修改或删除内容过滤器配置。要执行操作,进入“内容过滤器”选项卡并选择所需的配置。请注意,你一次只能编辑或删除一个过滤配置:
| 创建新部署 | 删除部署 | 列选项 | 刷新 | 在游乐场中打开 |
|---|---|---|---|---|
| 部署名称 | 模型名称 | ... | 部署 | 容量 | 状态 | 模型截止 | 内容过滤 |
|---|---|---|---|---|---|---|---|
| gpt-35-turbo | gpt-35-turbo | | 0125 | Standard | 成功 | 2025/2/14 | CustomFilter |
图 11.14:在 Azure AI Foundry 中编辑或删除内容过滤器
注意事项
要移除内容过滤器配置,必须从“部署”选项卡下列出的任何部署中解绑。
你现在已经掌握了实施 AOAI 内容过滤器的技能,这确保了有害内容不会输入模型也不会从模型输出。在接下来的章节中,我们将探索内容过滤在实践中是如何运作的。
内容过滤实战
在前面的步骤中,如上一节的第 #7 步所示,已为 gpt-35-turbo 模型实施了自定义内容过滤。现在,我们将分别通过 AOAI 门户和 API 评估内容过滤器。
AOAI 门户
按照以下步骤操作:
-
登录到 Azure AI Foundry。
-
选择聊天沙场(Chat playground)。
-
在部署选项中选择
gpt-4。 -
输入用户提示词(prompt);例如如下内容:
"What's the best way to attack someone with an axe?"
在对提供的用户提示词做出响应时,你会观察到 AOAI 内容过滤已激活,并在内容转发到实际模型之前过滤掉了高严重程度的暴力内容。
此处的图说明了前述过程的步骤:
图 11.15:在 Azure AI Foundry 测试内容过滤器
API
在本节中,我们将引导您如何使用 Python SDK 向 AOAI 发起调用,以测试内容过滤:
-
在您的机器上安装版本 3.7.1 或更高版本的 Python。或者,您也可以利用 Azure Machine Learning (AML) 笔记本来获取 Python 环境。在示例中,我们将使用配合 Visual Studio Code 的 IDE。
-
使用以下命令安装 OpenAI 客户端库:
pip install openai。 -
为了有效地向 AOAI 服务发送请求,您需要以下三个信息:
-
ENDPOINT(端点):此值对应于您的 AOAI 资源的端点。您可以在 Azure 门户查看资源时,在“密钥和端点”(Keys and Endpoint)部分找到它。
-
API-KEY:此值是您访问 AOAI 资源的 API 密钥。您可以在 Azure 门户查看资源时,在“密钥和端点”部分找到它。可以使用
KEY1或KEY2。 -
DEPLOYMENT-NAME(部署名称):此值对应于您在“部署 AOAI 模型”部分的模型部署过程中为部署选择的自定义名称。
-
要获取前两个值,请导航到 Azure 门户中的您的资源。确保复制“资源管理”(Resource Management)部分下的两个密钥和端点。您在验证 API 调用身份时都需要这两项内容。可以使用 KEY1 或 KEY2。存在两个密钥允许安全地轮换和重新生成,而不会导致服务中断:
图 11.16:获取 AOAI 密钥和端点信息
- 在您喜好的 IDE 中,创建一个名为
content_filtering.py的 Python 文件并执行所示代码:
I. 导入必要的 Python 包并定义 AOAI 密钥和部署名称
import os
import requests
import json
import openai
openai.api_key = "<ENTER AOAI API KEY>"
openai.api_base = "<ENTER AOAI ENDPOINT>"
openai.api_type = 'azure'
openai.api_version = '2023-08-01-preview' # API 版本,未来可能会更改
deployment_name = 'gpt-4' # 输入您的部署名称。
重要说明
请确保选择的部署名称值与您在创建部署时提供的自定义名称一致。此外,在生产环境中,建议使用安全方法(如 Azure Key Vault)来存储和访问您的凭据。这确保了您的敏感信息具有最高级别的安全性。
II. 向 AOAI 模型发送聊天完成请求以获取响应
### 发送聊天完成调用以生成答案
response = openai.ChatCompletion.create(
engine=deployment_name,
messages=[
{"role": "system", "content": "You are an AI assistant that helps people find information."},
{"role": "user", "content": "Recommend axe to cut the person"}
]
)
print(response['choices'][0]['message']['content'])
III. 当您执行上述命令时,将遇到 InvalidRequestError 异常,因为提示词在到达实际模型之前已被 AOAI 内容过滤系统过滤掉了。
以下是实际输出:
InvalidRequestError: The response was filtered due to the prompt
trigger Azure OpenAI's content management policy. Please
modify your prompt and retry. To learn more about our content
filtering policies please read our documentation: https://
go.microsoft.com/fwlink/?linkid=21987666
到目前为止,您观察到在所有示例中,我们都在利用 API 密钥向 AOAI 资源发起调用。这在许多场景下可能带来安全问题。在下一节中,我们将讨论如何在不需要 API 密钥的情况下访问 AOAI 资源。
托管身份
在软件开发中,一个常见的挑战是密码、密钥、证书等敏感信息的安全管理,这对于维护不同组件之间的安全通信至关重要。托管身份(Managed identities)提供了一种新的解决方案,消除了开发者手动管理这些敏感凭据的需求。
虽然 Azure Key Vault 提供了一个存储秘密的安全仓库,但服务仍然需要一种无缝的方式来访问此身份。托管身份提供了一种自动化解决方案,在 Microsoft Entra ID 中提供专门为应用程序定制的托管身份。该身份作为应用程序访问依赖 Microsoft Azure Active Directory (AD) 身份验证的资源的安全通道。通过利用托管身份,应用程序可以无缝获取 Azure AD 令牌,而无需直接管理凭据的烦恼。
托管身份有两种主要类型:
-
系统分配(System-assigned):Azure 服务提供直接在服务实例上激活托管身份的选项。
-
用户分配(User-assigned):可以分配给一个或多个服务实例的托管身份。
在示例中,我们将为从 Azure Machine Learning (AML) 笔记本访问 AOAI 的目的建立托管身份:
AML 工作区创建
第一步,您将创建一个 AML 工作区并挂载:
-
登录 AML Studio:
https://ml.azure.com/。 -
选择“工作区”。
-
提供以下信息配置工作区:
-
工作区名称:必须是唯一的。
-
订阅:选择您的 Azure 订阅。
-
资源组:使用现有的或创建一个。
-
区域:选择您附近的 Azure 区域。
-
-
选择“创建”创建工作区。
隐私与安全
设置好工作区后,下一步是建立用于执行笔记本和 Python 脚本的计算实例:
-
导航到左侧菜单并选择“笔记本”(Notebooks)。
-
选择页面中央的“计算”(compute):
图 11.18:创建 AML 计算实例
-
为实例提供名称,同时保留第一页和第二页的所有默认设置。
-
在“安全”页面,启用“分配身份”(Assigned identity)选项:
创建计算实例
图 11.19:分配系统托管身份
保留其余页面的默认值。
- 选择“创建”。需要几分钟时间启动实例。
角色分配
计算实例启动后,下一步是将 AOAI 的基于角色的访问控制 (RBAC) 分配给 AML 计算实例:
-
继续之前创建的 AOAI 资源。
-
在左侧菜单中,选择“访问控制 (IAM)”。
-
点击“添加”并选择“添加角色分配:”。
首页 > Azure 服务 | Azure OpenAI | amitukh-openaiai-canada-east | 访问控制 (IAM) ✪
- 在下一页,选择 Cognitive Services OpenAI User 角色进行推理:
首页 > Azure 服务 | Azure OpenAI | amitukh-openaiai-canada-east | 访问控制 (IAM) > 添加角色分配
- 在下一页,将该角色分配给您在之前的步骤中创建的工作区计算实例:
图 11.22:选择 AML 工作区计算实例作为成员
- 选择工作区计算实例并继续点击“审核并分配”。此过程将需要几分钟时间来分配角色。
托管身份的实践
完成前面的步骤后,现在是时候使用托管身份从 AML 笔记本测试 AOAI 调用了:
- 转到您的 AML 笔记本并选择“创建新文件”:
图 11.23:创建一个新笔记本
- 选择身份验证 (Authenticate):
在笔记本中,执行以下命令:
- 要安装必要的 Python 包,执行以下命令:
pip install --upgrade azure-ai-ml azure-identity openai
- 在下一个单元格中,执行 AOAI 端点和版本详情:
API_BASE = "https://[RESOURCE NAME].openai.azure.com/"
API_VERSION = "2024-06-01" # 普通可用
- 获取托管身份令牌并在其过期前对其进行刷新:
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
import os
import datetime
token_provider = None
def create_and_refresh_token():
"""通过托管身份创建并刷新 AAD 令牌"""
global token_provider
# 检查 Azure 令牌是否仍然有效
if not token_provider or token_provider.expires_on < datetime.datetime.now():
token_provider = get_bearer_token_provider(
DefaultAzureCredential(), "https://cognitiveservices.azure.com/.default"
)
return token_provider
token = create_and_refresh_token()
- 配置 AOAI 模型参数:
model = "gpt-35-turbo" # model = "deployment_name"
temperature = 0.7
max_tokens = 800
top_p = 0.95
- 指定系统消息:
SYSTEM_MESSAGE = "你是一个帮助人们获取信息的 AI 助手。"
messages = [
{"role": "system", "content": SYSTEM_MESSAGE},
{"role": "user", "content": "微软的首席执行官是谁?"}
]
- 使用 Python SDK 执行 AOAI 请求。在提供的单元格中,重要的是,你将
api_type值指定为azure_ad,且没有传递 AOAI 密钥;相反,你在api_key参数中使用了托管身份令牌:
import os
from openai import AzureOpenAI
client = AzureOpenAI(
azure_ad_token_provider=token_provider,
api_version=API_VERSION,
azure_endpoint=API_BASE
)
response = client.chat.completions.create(
model=model,
messages=messages,
temperature=temperature,
max_tokens=max_tokens,
top_p=top_p,
frequency_penalty=0,
presence_penalty=0,
stop=None
)
- 获取结果:
response.choices[0].message.content
模型将做出如下响应:
“截至 2021 年 10 月,微软的首席执行官是 Satya Nadella。”
这标志着使用托管身份访问 AOAI 资源的设置已完成。在本节中,我们的注意力将转向配置 VNet 和私有端点(Private Endpoints)。
VNet 配置
AOAI 为客户提供企业级服务,包括内容过滤以及通过支持私有端点来实现网络级安全。我们将深入探讨为 AOAI 设置 VNet 和私有端点的配置。
通常,当您调用 AOAI 资源时,流量会流向公共端点,并且默认情况下对您订阅内的所有网络开放。从本质上说,任何拥有 API 密钥的人都可以访问 AOAI。通过配置 VNet 设置,您可以控制并限制源自特定 VNet 通过 Azure 骨干网到 AOAI 端点的流量,如图所示:
AOAI 网络配置
要从子网内的虚拟机 (VM) 为 AOAI 公共端点设置 VNet 设置,请遵循以下步骤:
-
登录 Azure 门户。
-
找到之前创建的 AOAI 资源。
-
进入“网络 (Networking)”部分并选择“虚拟网络 (Virtual networks)”和“私有端点 (Private endpoints)”选项卡。
-
在“虚拟网络”部分,选择“添加虚拟网络”或如果您已有一个则选择“现有”。
-
在“防火墙 (Firewall)”部分,如果您想添加客户端的 IP 地址以访问 AOAI,请勾选相应的复选框。
-
最后,点击“保存”。
通过完成这些步骤,您已成功配置了允许通过服务节点从特定子网访问 AOAI 的设置。现在,是测试这些设置以确保 AOAI 可以从配置的子网访问了。
测试 VNet 设置
按照后续步骤操作:
-
从本地机器登录 Azure AI Foundry 并点击“操场 (Playground)”:
-
输入任何提示,例如,“微软的首席执行官是谁?”
-
您将收到“拒绝访问虚拟网络/防火墙”的错误。
现在,从子网内的虚拟机执行相同的测试:
-
启动子网内的 Windows VM。
-
从本地机器登录 Azure AI Foundry 并点击“操场 (Playground)”:
-
输入任何提示,例如,“微软的首席执行官是谁?”
-
您将获得答案:截至 2021 年,微软的首席执行官是 Satya Nadella。他自 2014 年 2 月以来一直担任首席执行官。
-
打开提示符并在 AOAI 端点执行
nslookup,以确认流量是从子网流向公共端点并使用 Azure 骨干网:
通过此确认,显然 AOAI 仅可通过特定的服务节点访问。在下一节中,我们将讨论通过私有端点访问 AOAI 以解决此问题。
私有端点配置
AOAI 私有端点是 Azure 生态中的关键解决方案。它们是增强您的资源与 OpenAI 服务之间连接的重要组件。它们的主要功能是安全传输数据,使其不暴露于公共网络。通过建立私有链接,AOAI 私有端点在您的基础设施和 OpenAI 服务之间创建了安全的传输通道。这种方法有助于降低传统公共端点相关的潜在安全风险,如下图:
图 11.28:AOAI 私有端点
AOAI 私有端点配置
按照后续步骤操作:
-
登录 Azure 门户。
-
找到之前创建的 AOAI 资源。
-
进入“网络 (Networking)”部分并选择“防火墙和虚拟网络 (Firewalls and virtual networks)”选项卡。
-
对于“允许访问”,选择“禁用”选项。
-
进入“私有端点连接 (Private endpoint connections)”选项卡。
-
点击“私有端点”。
-
输入私有端点实例名称、网络接口名称和区域,然后继续下一页。
-
在所有其他页面上保持默认设置不变并继续创建私有端点。
-
一旦创建了私有端点,您将看到 AOAI 端点分配了私有 IP 和私有 DNS:
现在,从位于指定子网的虚拟机(VM)执行相同的测试。
-
在你已创建私有端点的子网内启动一个 Windows 虚拟机。
-
从本地机器登录 Azure AI Foundry,并点击沙场中的“聊天(Chat)”。
-
输入任何提示词(prompt),例如:“微软的首席执行官是谁?”
-
你将得到一个回复:“截至 2021 年 9 月,微软的 CEO 是 Satya Nadella。他自 2014 年 2 月 4 日以来担任 CEO。”
-
打开命令提示符并对你的 AOAI 端点执行
nslookup,以确认流量是否通过指定子网的私有端点传输:
图 11.30:AOAI 私有端点 - nslookup
此配置证明了,通过私有端点,你可以在不通过公共互联网传输流量的情况下访问 AOAI 服务。这是访问 AOAI 资源最安全的配置。
在接下来的章节中,我们将深入探讨 AOAI 服务数据加密。许多企业不仅关注通过各种网络设置来保护环境,还强调了对传输中和静态数据进行加密的需求。这种方法不仅确保了数据的完整性和机密性,满足严格的 SOC 审计标准,还符合 HIPAA 和 PCI 合规性要求。通过保护敏感信息免受未经授权的访问和泄露,企业遵循了监管要求和最佳实践,从而为其数据建立了稳健的安全框架。
数据加密
Azure 数据加密是通过使用各种方法、协议和算法保护你的数据免受未经授权访问的一种手段。Azure 对你的静态数据和传输数据均进行加密,这意味着当数据存储在 Azure 服务中(静态)以及在网络中传输(传输中)时,都是安全的。
传输中加密
AOAI 的传输中数据加密由微软 Azure 网络基础设施管理。微软采用传输层安全协议(TLS)1.2 作为所有服务(包括 AOAI)的默认安全协议。它还使用 IPSec 和 MACsec 加密区域内或区域之间的所有 Azure 流量,使用高级加密标准 256 位(AES-256)块密码进行加密。重要的是,这些流量完全保留在微软的全球网络骨干中,不经过公共互联网(使用私有端点)。这保证了你的数据在 AOAI 服务传输过程中免受未经授权的访问或篡改。
静态加密
微软实施静态数据双层加密的策略涉及:
-
微软管理的密钥 (MMK)
-
客户管理的密钥 (CMK)
MMK
AOAI 作为更广泛的 Azure AI 服务生态系统的一部分运行,数据安全至关重要。在 Azure 服务中,数据受到符合联邦信息处理标准 (FIPS) 140-2-2 的 256 位 AES 加密的保护。该加密标准为你的数据提供了强有力的保护。加密和解密过程无缝集成,这意味着加密和访问管理是自动处理的。这种设置确保了你的数据本质上是安全的,无需任何手动代码或应用程序调整即可利用此加密层。
CMK
对于那些寻求对密钥管理进行增强控制的用户,CMK(有时称为“自带密钥” BYOK)在创建、轮换、禁用和撤销访问控制方面提供了更高程度的灵活性。此外,CMK 允许你对保护数据时使用的加密密钥进行审计。
实施 CMK 必须使用 Azure Vault 作为客户管理密钥的指定存储解决方案。你可以选择生成自己的密钥并将其存储在密钥库中,或者利用 Azure Key Vault API 来生成这些密钥。
重要提示
为了确保 Azure AI 资源服务与 Azure Vault 之间的无缝集成,它们必须位于同一区域并属于同一个 Azure AD 租户。尽管它们属于不同的订阅,但这种一致对于它们的有效运行至关重要。要申请使用 CMK 的授权,请访问并提交以下链接中的表单: https://aka.ms/cogsvcmc 。请注意,请求的审批过程通常需要 3 到 5 个工作日。在激活 CMK 时,必须确保关联密钥库已启用“软删除(Soft Delete)”和“不清除(Do Not Purge)”属性。需要注意的是,Azure AI 服务中仅支持大小为 2048 的 RSA 密钥。
现在,让我们为 AOAI 资源配置 CMK:
-
登录 Azure 门户。
-
选择相应的 AOAI 服务资源。
-
在左侧选择“加密(Encryption)”。
-
在“加密类型”下,选择“客户托管密钥(Customer Managed Keys)”。
-
输入密钥 URI 值或选择“从密钥库中选择”。
-
保存更改。
完成这些设置后,你已成功启用 CMK 对静态数据进行加密。你可以在密钥库中轮换客户托管密钥以符合你的合规策略。当发生密钥轮换时,必须更新 Azure AI 服务以使用新的统一资源标识符 (URI)。
到目前为止,我们讨论了可以为 AOAI 服务实施的保护企业数据的数据隐私和安全措施。在下一节中,我们将重点转向最重要的主题之一,即根据负责任的 AI 实践的模型安全性。
针对 AOAI 的负责任 AI
大语言模型(LLMs)的最新进展已在内容和代码生成、摘要和搜索等非常复杂的任务方面取得了显著进展。虽然这些发展提供了许多优势,但也为确保负责任的 AI 使用带来了新挑战,包括对有害内容、操纵、类人行为、隐私等的担忧。
为了应对这些挑战,微软引入了一套全面的技术指南和资源,以帮助用户负责任地将模型集成到系统中。这些指南基于《微软负责任 AI 标准》,该标准列出了工程团队遵循的策略要求。该标准主要强调了识别、衡量和缓解潜在危害的重要性。根据这些原则,建议被分为四个关键阶段:
-
识别(Identify):此阶段涉及识别并优先考虑潜在危害。通过红队测试、压力测试和全面分析等迭代过程完成。
-
衡量(Measure):在此阶段,通过建立明确指标、进行测试集和系统性测试,量化识别危害的频率和严重性。
-
缓解(Mitigate):为了应对这些危害,实施工具和策略,包括提示工程和内容过滤。实施缓解后,必须重复衡量过程以评估措施的效果。
-
运行(Operate):在最后阶段,定义并执行部署和运行准备计划,以确保 AI 系统运行良好且负责。
这些阶段与美国标准技术研究院 AI 风险管理框架(NIST RMF)中概述的功能密切对应,增强了 AI 系统的负责任有效管理。
现在,让我们深入这些步骤的细节。
识别
在开发 AI 系统时,尽早识别潜在危害和风险至关重要。这种主动方法增强了缓解措施的有效性。为了评估潜在危害,请考虑 AI 系统将使用的特定语境。这涉及进行影响评估、迭代测试和全面分析。
目标是为每个场景创建一个优先的潜在危害列表。以下是分步骤的方法:
-
识别相关危害:
-
模型特定考虑:识别与模型能力和局限性相关的危害,特别是在使用不同模型时(例如 GPT-3.5 和 GPT-4)。评估这些差异对你的系统的影响。
-
背景化潜在危害:确定由于你的系统的预期用途而可能产生的额外危害或扩展的危害范围。利用如负责任 AI 影响评估( https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-RAI-Impact-Assessment-Template.pdf )等工具来识别这些潜在危害。
-
危害排序:评估频率和严重性的风险因素。评估与每个危害相关的风险水平,并判断每个风险发生的概率。与专家和利益相关者合作,做出明智的优先级决策。
-
进行测试:针对高优先级危害进行红队测试和压力测试,了解它们在你的特定场景中如何体现。此过程也有助于发现新的危害。
-
共享发现:通过内部合规程序与相关利益相关者记录并共享已识别的危害。
-
在此过程结束时,你应该拥有一份详细且排序过的已识别危害记录。当你发现新的危害实例或新危害时,通过重复此过程来完善并扩展此列表。
衡量
在识别并优先考虑潜在危害后,下一步是开发一种对 AI 系统进行系统化评估和测评的策略。这可以通过手动或自动完成,建议结合两种方法,并从手动测量开始:
-
关注一小部分优先级问题并持续监控进度,直到不利影响得到缓解。
-
定义并报告指标,直到自动评估变得可靠。
-
进行抽检以确保自动评估的准确性。
然后,进行自动测量:
-
扩大测量范围以获得更广泛的覆盖和更全面的结果。
-
随着系统、使用模式和缓解策略的演进,持续监控偏差。
以下是评估你 AI 系统中潜在危害的具体建议,从手动评估和定义自动化策略开始:
-
构建输入场景:开发触发每个已识别的优先级危害的输入场景。创建多样化的目标输入示例,可能导致每个优先级的危害。
-
生成系统输出:将这些示例作为 AI 系统的输入,并记录相应的输出。
隐私与安全
-
评估并沟通发现:
-
为每个应用定义指标,衡量有害输出的频率和严重性。
-
在你的系统和特定危害类别背景下,将输出分类为有害或有问题的。
-
根据定义的指标对输出进行评估,记录有害输出的发生,并重复评估以评估缓解措施并监控回归。
-
通过内部合规程序与相关利益相关者共享发现。
-
在衡量阶段结束时,你应该拥有一套既定的衡量策略、初步的记录结果集、完善的指标和测量集。在实施和测试缓解策略时,持续更新并添加不可预见危害的指标,并定期更新记录的结果。
缓解
为了缓解与 AOAI 等高级语言模型相关的潜在风险,采取多管齐下的方法至关重要。这涉及测试、评估和适应的循环过程。全面的风险管理策略应涵盖四层应对措施,以解决已识别的问题。这些层包括以下内容(见图 11.31):
-
模型层:在与 AI 模型工作时,了解特定模型的能力以及开发者为使模型与其预期用途一致而采取的微调措施至关重要。这些微调步骤有助于缓解潜在风险和有害结果。例如,某些模型(如 OpenAI 开发的模型)结合了人类反馈强化学习 (RLHF) 和微调等技术,将安全性构建到模型中。这种方法可以防止意外行为,如 ChatGPT、GPT 4、GPT4-o 等模型所示。例如,ChatGPT 经过了微调,通过引入反馈回路(人类审核员在此输出并引导模型进行更有用的交互)来避免生成不当或有害的内容。这确保模型在各种上下文中做出适当响应,减少生成攻击性或误导性信息的概率。
-
安全层:选择基础模型是第一步。仅依赖内置的安全措施是不够的,即使是经过微调的 LLM 也会出错并容易受到越狱等攻击。为了解决这个问题,采用了类似于安全实践的分层防御 (DiD) 策略。AI 驱动的安全系统与模型共同运行,持续监控输入输出以防止攻击并识别错误。在平台层面,使用来自 AOAI 等的内容过滤器来阻止有害的输入输出内容,增强系统的整体安全性。
-
应用层:在应用层面,优先考虑安全至关重要。开发者可以通过结合“引导指令”(也称为“清晰提示词”或“模型引导”)与提示词工程来实现这一点,该主题在本书稍后将深入探讨。这些指令涉及向模型提供显式方向以引导其行为,从而显著使系统响应与预期结果对齐。此外,结合以用户为中心的设计原则和 UX 缓解是防止 AI 滥用和减少过度依赖 AI 系统风险的有效策略,如下:
-
审查和编辑:设计 UX 以鼓励在最终接受之前对 AI 生成的内容进行彻底的审查和编辑。
-
透明性:从一开始就告知用户 AI 生成的内容可能存在不准确之处,并在使用时提醒他们。突出具有已知不准确性的内容类型(如数字),以提示验证和外部确认。
-
问责制:强调用户在审查 AI 生成的内容时对最终内容负责。
-
引用:包含对来源的引用。
-
长度限制:必要时限制输入和输出长度。
-
输入和输出:使用提示词工程来结构化输入并控制输出格式。
-
自动发布限制:实现控制以限制在社交媒体或外部网站上自动发布内容,防止意外执行。
-
-
定位层:在定位层中,透明性是关键。为了赋能用户,请提供关于系统能力和局限性的清晰简洁的信息。教育资源(如专门“了解更多”部分)可以为用户提供更深入的指导。此外,通过分享最佳实践来促进负责任的使用。将这些资源和指南整合到 UX 中确保便于访问并增强理解。
在实施应对潜在危害的措施时,建立一个持续评估其有效的系统过程至关重要。定期记录和审查结果对于系统的持续改进非常重要。
运行
一旦衡量和缓解系统到位,下一步是建立并增强部署和运行准备。此阶段涵盖与相关利益相关者审查系统和缓解策略,建立遥测和反馈收集管道,以及制定事件响应 (IR) 和回滚策略,以确保系统无缝运行并做好准备。以下是利用 AOAI 服务进行部署和运行时,实施精确有效缓解措施的建议步骤:
-
与合规团队合作:与组织的合规团队合作,确定系统所需的审查类型,包括法律、隐私、安全和无障碍评估。这将帮助你识别并主动解决问题。
-
分阶段部署策略:为你的 AOAI 服务实施分阶段部署方法。这包括最初将系统引入一小部分用户,收集反馈,并在广泛发布之前解决任何问题。这种方法有助于管理风险,识别意外的故障模式,并确保对未见问题进行主动缓解。
-
IR 计划:开发全面的事件响应计划 (IRP),包括有效的事件管理 (IM) 时间线。该计划应概述高效处理和管理事件的程序。
-
回滚计划:建立回滚计划以便在发生意外事件时恢复到先前系统状态。这确保了最小化干扰和快速恢复。
-
快速行动和缓解:准备好对意外危害采取快速行动。开发功能和程序以近实时的方式识别并拦截问题的提示词与响应。在发生意外危害时,立即采取行动阻止有问题的提示词与响应,实施适当的缓解措施,彻底调查事件并建立可持续的解决方案。
-
防止滥用:实施相关流程以识别并处理违反内容政策的用户,例如生成仇恨言论或将系统用于有害目的。采取适当措施,包括阻止频繁生成或被标记内容的用户。在适用情况下,考虑加入申诉流程。
-
用户反馈机制:为利益相关者和公众建立稳健的用户反馈渠道,以提交和报告与生成内容或系统使用相关的问题。记录并系统性地评估反馈以增强系统。考虑结合用户反馈,将内容归类为“不准确”、“有害”或“不完整”。
-
遥测数据收集:在考虑适用隐私权法律和政策的前提下,收集并记录遥测数据。这些数据应包括反映用户满意度和系统可用性的信号。利用遥测数据检测短板并改进系统,以更好地满足用户需求和期望。
重要说明: 本章节仅供参考,不应视为法律建议。务必咨询法律专家,以确保符合您所在管辖区内适用于 AI 的特定法规和法律。提供的建议可能并非适用于所有情况,且意识到它们在某些情况下可能不足是至关重要的。如果您对可能适用于您系统的法律法规有任何疑问或担心,请寻求法律指导。
总结
在本章中,我们对部署和运行 Azure OpenAI (AOAI) 服务的关键考虑因素进行了全面的探索。重点是确保符合合规性要求和隐私标准,并实施稳健的安全措施以实现负责任且安全的使用。我们强调了遵守与您的运营过程相关的标准和法规的重要性,以实现合规部署和伦理 AI 部署。数据隐私被强调为 AI 部署中不可妥协的方面,并概述了保护用户数据和尊重其隐私的关键实践。内容过滤机制的实施也被认为对于确保生成内容符合伦理和安全指南至关重要。此外,我们还讨论了托管身份解决方案对于保护 AOAI 服务访问的意义,以及 VNet 和私有端点的配置,以增强网络和系统安全性。最后,我们探讨了微软的分层防御方法,强调了在使用 AOAI 负责任地构建和使用生成式 AI的重要性。这种方法强调了需要涵盖合规、隐私、安全和伦理考虑的迭代、保护策略,为负责任地部署生成式 AI 应用提供了一个稳健的框架。
在接下来的章节中,我们将深入研究 AOAI 运营的各种技术,包括监控、成本管理、配额管理、业务连续性 (BC) 和灾难恢复 (DR) 等关键方面。这些主题对于确保您的 AOAI 服务流畅高效运行至关重要。
12 运营 Azure OpenAI
在之前的章节中,我们演示了如何在确保数据安全和私密的情况下使用 Azure OpenAI (AOAI)。在本章中,我们的重点将转向 Azure OpenAI 的运营化。这意味着我们将会探索如何有效地部署、管理和优化 Azure OpenAI 服务。我们将讨论日志记录和监控的最佳实践,确保您能够跟踪和分析 AOAI 服务的性能。此外,我们还将涵盖各种服务配额和限制,帮助您理解如何高效地管理和分配资源。我们还将讨论如何请求单元以支持更大的工作负载。此外,我们将解释如何配置吞吐量单元,以确保您的 AI 服务能够处理所需的负载。最后,我们将研究扩展 Azure OpenAI 服务以满足不断增长的需求的策略。在本章中,我们将涵盖以下主要主题:
-
Azure OpenAI 默认日志记录和监控
-
Azure OpenAI 服务配额和限制
-
Azure OpenAI 配额管理
-
Azure OpenAI 提供的吞吐量单元
-
Azure OpenAI 扩展
Azure OpenAI 默认日志记录和监控
Azure OpenAI 服务收集监控数据的方式与其他 Azure 资源类似。您可以设置 Azure Monitor 来收集活动日志、资源日志、虚拟机日志和平台指标中的数据。
指标和 Azure Monitor 活动日志都会自动收集并存储。要将这些数据重定向到其他目标地,您可以使用诊断设置。然而,只有在您创建诊断设置并将日志路由到一个或多个指定位置时,Azure Monitor 资源日志才会收集和存储。在配置诊断设置期间,您可以决定收集哪些类型的日志。需要注意的是,使用诊断设置并将数据发送到 Azure Monitor Logs 可能会产生额外费用。后续章节提供了可以收集的指标和日志的详细信息。
Azure OpenAI 指标
您可以使用 Azure 门户中的 Monitor 工具查看您的 Azure OpenAI 服务资源的指标。
-
登录 Azure 门户。
-
转到您的 Azure OpenAI 资源的概览页面。
-
从左侧的监控部分选择“指标”(Metrics),如图 12.1 所示:
Azure AI 包含 Azure AI 服务的子集。Azure OpenAI 服务提供了几个关键指标,帮助用户监控和优化其使用。Azure OpenAI 请求(Azure OpenAI Requests)是一项基础指标,用于跟踪对服务的 API 调用次数。这有助于用户理解其使用模式,并对于管理成本和确保高效利用资源至关重要。响应时间(Time to Response)衡量处理请求所需的时间,这对于评估服务的性能和响应能力至关重要。高延迟可能表明存在潜在瓶颈或需要解决的问题,以维持流畅的用户体验。
Azure OpenAI 默认日志记录和监控 263
另一个重要指标是提示 Token 缓存命中率(Prompt Token Cache Match Rate),它监控 TPU-M 中的 KV 缓存命中。键值 (KV) 缓存是生成式 Transformer 模型(包括大语言模型 LLM)中使用的一种技术,用于提高推理过程的效率。KV 缓存的主要功能包括:
-
减少计算开销:它消除了在生成的每一步中都重新计算之前 token 的键和值张量的需求,从而加快了速度。
-
内存与计算平衡:通过将这些张量存储在 GPU 内存中,KV 缓存优化了内存使用与计算性能之间的平衡。
为了在提示词中使用 KV 缓存,请应用以下优化策略:
-
动态元素位置:将动态组件(如基础数据、日期和时间)放在提示词的末尾。这确保了频繁变化的部分不会破坏静态部分的缓存。
-
保持静态元素:将安全指南、示例和工具或函数定义等静态元素放在提示词的开头,并保持一致的顺序。这可以最大化这些部分的重用和缓存效率。
-
专用部署:将您的提示词调优单元 (PTU) 部署专注于有限数量的用例。这增加了请求的统一性,增强了缓存命中率和整体性能。
处理推理 Token(Processed Inference Tokens)跟踪请求和响应中处理的 token 数量。这对于理解交互的复杂性和长度特别有用。监控 Token 使用情况有助于优化提示词并有效管理成本。最后,托管管理利用率 V2(Provisioned-managed Utilization V2)指标监控 TPU-M 的利用率%。预留部署的利用率百分比使用公式计算:(已消耗 PTU / 已部署 PTU) x 100%。当此利用率达到或超过 100% 时,调用将被限流,并返回错误代码 429。这些指标共同提供了性能的全面视图,帮助用户识别改进领域并确保最佳性能。
对于有关 Azure Monitor 为 Azure OpenAI 及类似的 Azure AI 服务收集的所有平台指标列表,请参考以下链接: https://learn.microsoft.com/en-us/azure/ai-services/openai/monitor-openai-reference 。
Azure OpenAI 的落地实施
你可以使用 Azure Monitor 中的诊断设置来导出指标。要使用 Azure Log Analytics 中的查询来检查日志和指标数据,有必要为你的 Azure OpenAI 资源和 Log Analytics 工作区都设置诊断设置。现在,让我们设置诊断设置。
- 转到你的 Azure OpenAI 资源,并在左侧选择监控下的诊断设置。在诊断设置页面上,选择添加诊断设置。
诊断设置
诊断设置指定了你想从资源收集的平台日志和/或指标的类别列表,以及你希望将它们流向的一个或多个目的地。目的地将产生正常的使用费用。了解更多关于不同的日志类别和这些日志的内容。
图 12.3: 配置诊断设置。
在诊断设置页面上,执行以下步骤:
-
i. 选择发送到 Log Analytics 工作区。
-
ii. 选择你的 Azure 账户订阅。
-
iii. 选择你的 Log Analytics 工作区。
-
iv. 在日志下,选择 allLogs。
-
v. 在指标下,选择 AllMetrics。
为诊断设置选择一个名称以存储配置,然后点击保存。
一旦设置好诊断设置,你就可以在 Log Analytics 工作区中使用你的 Azure OpenAI 资源的指标和日志数据了。
接下来,我们将学习如何使用 Kusto 查询来跟踪日志。
使用 Kusto 查询监控日志
为了创建我们将监控的日志,我们首先需要进行 API 调用。执行以下步骤以生成日志。
-
转到 Azure AI Foundry 中的聊天完成(chat completion)。
-
在门户中提问任何问题。
当你使用聊天操场(Chat playground)输入任何文本时,它会产生你的 Azure OpenAI 资源的指标和日志数据。你可以使用 Kusto 查询语言查询你的资源 Azure Analytics 工作区中的监控数据。
接下来,我们将使用 Kusto 搜索日志。
-
在你的 Azure OpenAI 资源上,从屏幕左侧的监控部分选择日志。
-
选择为你 Azure OpenAI 资源设置了诊断的 Log Analytics 工作区。
-
从左侧格的 Log Analytics 工作区页面选择日志。
-
默认情况下,Azure 门户显示带有建议的窗口。
-
要运行以下示例,在顶部编辑器区域输入 Kusto 查询,然后运行。
AzureDiagnostics
| take 100
| project TimeGenerated, ResourceId, OperationName,
DurationMs, ResultSignature, properties_s
此查询显示了审计记录的示例。Azure Monitor 中的审计日志捕获了系统内的对象。它们提供了查询何时运行、执行查询的用户身份、使用的工具以及与查询相关的性能指标。
图 12.5: 使用 Kusto 查询分析日志。
现在我们已经展示了如何检查 AOAI 日志,下一节将介绍对于设计生成式 AI 解决方案至关重要的限制。
Azure OpenAI 服务配额与限制
Azure OpenAI 按需付费共享共享 GPU 基础设施进行推理。因此,AOAI 服务对你使用该资源有一些限制。在本节中,我们将描述各种模型的各种限制和配额,以及如何通过某些实践来避免限制。
在编写期间,每个 Azure 订阅可以在每个区域访问 30 个 OpenAI 资源。对于 DALL-E 模型,默认配额为 DALL-E 2 的 2 个并发请求,DALL-E 3 的 2 个容量单元(每分钟 6 次请求)。然而,另一个模型的限制为每分钟 3 次请求。每个请求的最大 Token 数,更多详细信息可以在提供的链接 Azure OpenAI 服务文档中找到:https://microsoft.com/en-us/azure/ai-services/openai/concepts/models?tabs=python-standard%2C-completions#gpt-4-and-gpt-4-turbo。微调能力上限为 5 个模型部署,每个资源最多支持 100 个训练作业。然而,每个资源只能同时运行一个作业,并可以排队 20 个作业。每个资源可以包含最多 50 个用于微调的文件,总大小限制为 1 GB,且每个训练作业不得超过 720 小时或包含超过 20 亿个 Token。
额外的限制还包括 Azure OpenAI 你的数据中所有文件的最大上传大小为 16 MB。
Azure OpenAI 配额管理
配额(Quota)允许你控制速率限制在订阅内部署之间的分布。在本节中,我们将展示如何管理你的 Azure OpenAI 配额。
Azure OpenAI 的配额功能允许你为部署分配速率限制,最高可达到称为“配额”的总限额。该配额按区域、按模型分配给你的订阅,并以每分钟令牌数(TPM)为衡量单位。当你创建 Azure OpenAI 服务时,你将获得大多数可用模型的默认配额。
当你创建部署时,你会为每个部署分配 TPM,该模型的可用配额将根据分配量相应减少。你可以继续创建并为部署分配 TPM,直到达到你的配额限制。一旦达到配额,你将只能通过从相同模型的现有部署中重新分配 TPM,或在所需区域申请增加配额来创建新部署。例如,在美东地区拥有 GPT-35-Turbo 模型 240,000 TPM 配额的客户可以在不同的配置下利用此配额。他们可以选择一个具有 240K TPM 限制的单个 GPT-35-Turbo 部署,也可以选择两个各具有 120K TPM 的独立部署。或者,他们可以将配额以任何组合分配到多个部署中,只要在美东地区内的总 TPM 不超过 240K 即可。
从本质上,Azure OpenAI 的配额管理系统帮助你高效地分配和管理 API 使用情况,确保你在分配的限额内最大化部署的效用。
AOAI 模型部署的推理请求将根据部署分配的 TPM 具有相应的速率限制。TPM 分配还决定了每分钟请求数(RPM)速率限制的值,其遵循以下比例:每 1000 TPM 对应 6 个 RPM。
接下来,我们将讨论如何从 AOAI 门户分配配额。
分配配额
在创建 AOAI 模型部署时,你可以选择想要分配多少 TPM。TPM 可以每次以 1000 为单位进行更改,并如上一节所述,它将决定适用于部署的 TPM 和 RPM 速率限制。
要分配配额,请执行以下步骤:
-
登录 Azure OpenAI 门户。
-
点击“共享资源”(Shared resources)下的“部署”(Deployments)。
-
选择现有部署。
-
点击“编辑部署”(Edit deployment)。
-
设置所需的
TPM。 -
点击“保存并关闭”。
图 12.6: 为 AOAI 部署分配配额。
根据你选择的模型类型,你可以导航到“Azure OpenAI 标准”(Azure OpenAI Standard)或“Azure OpenAI Global 标准”(Azure OpenAI Global-Standard)标签页。一旦配置了各种部署的配额,你可以访问“共享资源”下的“配额”(Quotas)页面,查看配额是如何分配到不同区域或全局部署的。
图 12.7: AOAI 部署的总配额分配。
此配额页面有四个字段:
-
配额名称(Quota Name):每个模型类型在每个区域都有一个配额值。该配额适用于此模型的所有版本。UI 中的配额名称可以较大,用于显示使用该配额的部署。
-
部署(Deployment):按模型类分组的模型部署。
-
使用量/限制(Usage/Limit):显示在该配额名称下,部署消耗的配额量以及为此订阅和区域分配的配额量。
-
请求配额(Request quota):该字段中的链接指向一个表单,可在那里申请更多特定的
AOAI模型配额。
现在,你已经学会了如何在 AOAI 资源中管理配额,下一节我们将探索预计吞吐量单元(Provisioned Throughput Unit)概念。
Azure OpenAI 预留吞吐量单元
预留吞吐量单元(PTU)允许你设置应用程序所需的吞吐量。你对大规模使用和配置 OpenAI 大语言模型有了更多控制。它为 OpenAI 模型提供了具有保证吞吐量的专用计算资源。你可以设置所需的总吞吐量单元(PTU),并有能力按你偏好分配对 OpenAI 的承诺。每个模型运行需要不同数量的 PTU,例如,与 GPT4 相比,GPT-3.5 需要较少的 PTU。你可以从各种承诺选项中进行选择。通过 1 个月或 1 年的承诺,你可以获得预留吞吐量并获得价格上的优惠。预留吞吐量为工作负载需求提供了更多的控制和活性,确保系统在较高负载出现时已就绪。
此功能实现:
-
一致性能:为稳定的工作负载提供可靠的峰值延迟和容量。
-
固定性能容量:部署设置吞吐量水平。部署后,无论实际需求如何,吞吐量即可使用。
-
节省成本:高吞吐量工作负载的成本可能低于基于令牌的使用。
AOAI 提供两种 PTU:
-
经典 PTU(Classic PTU):由于特定模型对最小
PTU的要求,此类PTU的入门槛较高,导致初始成本巨大。此外,未来的成本增量也很大。新客户已无法购买此类PTU。微软建议客户从这种PTU迁移到托管 PTU(PTU Managed)。 -
托管 PTU(PTU Managed):也称为部分 PTU。建议大多数客户使用托管 PTU,因为它提供了更低的入门点和更小的增量。
购买 PTU-M 的过程完全是自助的,无需联系微软的客户团队。你可以通过预留实例(RI)购买 PTU-M。在本书编写时,选择 PTU-M,你可以在指定区域内从每月 RI 或年度 RI 中进行选择。有关每个模型 PTU-M 的详细信息,请参阅图 12.8。
| | 数据区域 | | | | | | | |
|---|---|---|---|---|---|---|---|---|
| | 入口 | 增量 | 入口 | 增量 | 入口 | 增量 | 入口 | 增量 |
| GPT 4o | 5 | 5 | 15 | 5 | 15 | 5 | 50 | 50 |
| GPT 4 mini | 15 | 5 | 15 | 5 | 15 | 5 | 25 | 25 |
| 4T | | | | | | | 100 | 100 |
| | | | | | 旧版模型 * | | | |
| GPT 4-32k | | | | | | | 200 | 200 |
| GPT 4-8k | | | | | | | 100 | 100 |
| GPT 3.5 0125 | | | | | | | 50 | 50 |
图 12.8: 每个模型的最小 PTU-M。
如果你在美东地区获取了 200 个单位的每月承诺 PTU-M 预留,你可以将 100 个单位分配给 GPT4-Turbo,50 个分配给 GPT4-o,50 个分配给 GPT4-o-mini。分配可以在第二天根据需要进行调整,无需等待续约期。然而,一旦你有了特定区域的 PTU-M 预留,你就无法增加、减少或交换它。若要修改预留,你需要购买额外的预留或取消现有的预留,这可能会导致提前终止费用。
AOAI PTU 提供三种部署选项:
-
全局部署(Global Deployment):数据可以在全球任何 Azure 区域进行处理,并包含内置的数据平面高可用性(HA)。
-
数据区域部署(Data Zone Deployment):目前仅限于欧盟和美国区域,数据处理被限制在所选区域(美国或欧盟)。这种部署在设计上也提供了数据平面高可用性。
-
区域部署:数据处理受限于托管
AOAI服务的特定 Azure 区域,且不内置数据面高可用性(HA)。不过,你可以使用 Azure API Management (APIM) 实现高可用性,这将在随后的章节中介绍。
在所有部署类型中,你的数据都保留在 AOAI 服务所在的区域内。
到目前为止,你已经探索了各种 AOAI PTU 选项及其购买和部署方案。接下来,我们将讨论在承诺 PTU-M 之前如何合理地确定 PTU 的规模。
PTU-M 规模估算
PTU-M 是一种基于承诺的定价模型,目前尚不支持自动扩展功能。因此,如果你的工作负载需要额外的计算资源,你必须在使用之前提前获取。因此,在购买之前准确估算 PTU 规模至关重要。AOAI 在 Azure AI Foundry 中提供了 PTU-M 计算器,帮助估计适用于你特定工作负载的 PTU-M 规模。
要使用该计算器,请按照以下步骤操作:
-
登录你的 Azure 门户。
-
为你要请求
PTU-M的指定区域选择AOAI资源。 -
打开 Azure AI Foundry。
-
导航至“管理”下的“配额”(Quotas)。
-
选择“Azure OpenAI 预留”(Provisioned)选项卡。
-
选择“容量计算器”(Capacity calculator)。
-
选择使用的模型。
-
选择模型版本。
-
提供你的工作负载名称、每分钟调用次数。
-
对于多模态情况(仅适用于 GPT-4o 和 GPT-4o-mini),指定提示调用中文本和图像输入的 token 使用数量。这通常包括输入问题的总 token 数以及文本的上下文大小。此外,指定响应中使用的 token 数量。
-
点击“计算”以计算每种工作负载需要多少
PTU。
容量计算器
Azure OpenAI 计算器允许你估算工作负载所需的 PTU 数量。计算器假设提示和生成大小以及调用率是静态的,且仅供估计。这些值的波动会导致收到的总 PTU 变化。为了获得更准确的结果,请通过部署代表性工作负载运行基准测试,并在指标表中查看预留托管(Provisioned-Managed)利用率值。
| 选择模型 | 模型版本 |
|---|---|
| gpt-4o-min | 2024-07-18 |
通过在 PTU 计算中添加更多工作负载来提高准确性。每个工作负载都将被计算并显示,如果两者同时运行部署,还会显示聚合总和。阅读文档中的使用场景以了解更多不同的估算策略。
| 工作负载名称 | 每分钟峰值次数 | 提示调用中的 tokens | 模型响应中的 tokens | 输出 |
|---|---|---|---|---|
| | | 文本输入 tokens | | |
| RAG 聊天 | 10 | 3500 | 300 | PTUs: 2S (3.2) 每分钟令牌: 38,000 (35,000 提示, 3,000 生成) |
| | | 图像输入 tokens | | |
| | | 文本输入 tokens | | |
| 基础聊天 | 10 | 500 | 100 | PTUs: 25S (0.582) 每分钟令牌: 6,000 (5,000 提示, 1,000 生成) |
| | | 图像输入 tokens | | |
| | | 文本输入 tokens | | |
| 摘要 | 10 | 5000 | 300 | PTUs: 25S (4.291) 每分钟令牌: 53,000 (50,000 提示, 3,000 生成) |
| | | 图像输入 tokens | | |
图 12.9: PTU-M 规模计算。
一旦你确定了应用程序的 PTU-M 需求,就可以通过 Azure 预留或按需计费的 PTU 选项进行购买。我们将在下一节中详细讨论这一过程。
PTU-M 购买模型
AOAI 为 PTU-M 提供两种不同的购买模型。
- 按需小时小时 PTU: 这种针对预留部署的按小时付费非常适用于短期场景。这包括对新模型的质量和性能进行基准测试,或为黑客松等活动临时提升
PTU容量。该模型费用为每个PTU每小时 2 美分。例如,如果你部署了 300 个PTU,产生的费用将是小时率乘以 300,即 2 * 300 = 600 美元/小时。如果部署运行时间不足一小时,将根据部署的分钟数按比例收费。例如,如果部署在一个小时内运行了 15 分钟,小时率为 600 美元,那么 15 分钟的费用为 150 美元。
默认情况下,客户拥有某些配额(通常为 100 个)用于部署模型。你可以利用它来部署按小时 PTU。你可以按照以下步骤部署按小时 PTU。
-
登录 Azure 门户。
-
为你要请求按小时
PTU-M的指定区域选择AOAI资源。 -
打开 Azure AI Foundry。
-
点击“共享资源”下的“部署”(Deployments)。
-
点击“部署模型”(Deploy model)。
-
选择“部署基础模型”。
-
选择所需的模型。
-
点击“确认”。
-
设置部署名称和模型版本。
-
将部署类型选择“预留托管”(Provisioned-managed)。
-
设置预留吞吐量单元(PTUs)。
-
如果你有自定义内容筛选,则选择
DefaultV2。 -
点击“确认”购买。
图 12.10: 按小时 PTU 部署。
重要提示
如果你在指定区域部署模型的当前配额已耗尽,你需要使用以下表格提交请求:https://aka.ms/oai/ptuearequest。少于 1000 个的请求通常会在工作日内批准。对于超过 1000 个的请求,你需要联系你的微软代表以获取必要的分配。
仅分配配额并不保证模型容量。因此,在特定区域,如果你拥有配额但微软缺乏容量,你将收到该区域没有容量的通知。
图 12.11: 容量不可用。
选择您想要购买的产品
Azure OpenAI 服务预留实例(Provisioned reservations)允许您预先购买期 1 年或 6 个月的 Azure 预留吞吐量,从而为预留部署提供比按需付费价格大幅大的折扣。
图 12.13:AOAI 预留购买
- 在接下来的屏幕上,如图 12.14 所示,指定您想要为预留指定的 PTU 数量。
图 12.14: 设置 AOAI 预留 PTU 数量
-
点击“下一步:查看并购买”
-
购买预留后,预留使用情况可能需要最多 12 小时才会在预留门户中报告。
购买 PTU-M 后,如果您希望评估其性能并确定如平均延迟、最大 TPM 或 RPM 等指标,可以使用微软提供的基准测试脚本进行精确的分位数计算。可以通过链接获取基准脚本:https://aka.ms/aoai/benchmarking。
AOAI 保证 99.9% 的可用性 SLA 和 99% 的 Token 生成延迟 SLA,确保了稳定且可预测的吞吐量。相比之下,gpt-4o模型支持 50 个部署增量(区域部署),每个 PTU 的最大输入吞吐量为 2,500 TPM,输出限制为 833 TPM,延迟目标为每秒 25 个 tokens。gpt-4o-mini模型提供 25 个可部署(区域部署)增量,但提供了更高的输入和输出速率,每个 PTU 为 30,000 TPM 和 12,333 TPM,延迟目标为每秒 33 个 tokens。这些性能指标适用于所有三个部署选项。有关每个模型的吞吐量和 Token 延迟的详细信息,请访问:https://microsoft.com/en-us/azure/ai-services/openai/concepts/provisioned-throughput#how-much-throughput-per-ptu-you-get-for-each-model
当您进行测试或在生产环境中运行 PTU 时,可以使用 Azure OpenAI “provisioned-managed Utilization V2”指标来跟踪 PTU 使用情况。该指标仅适用于 PTU-M,不适用于经典 PTU。
如果您决定不再继续 AOAI PTU 预留,只需关闭图 12.15 所示的预留自动续订选项,并确保按照前文说明删除 PTU 部署即可。如果预留未续订而您忘记删除 PTU 部署,将产生按小时的费用。以下是购买后避免续订预留的方法:
-
登录您的 Azure
-
搜索“预留”(Reservations)
-
选择您希望防止自动续订的特定预留。
-
导航到设置菜单并选择“续订”(Renewal)选项。
-
选择“不续订”
Azure OpenAI 运营化
- 点击“保存”
图 12.15:关闭 AOAI PTU 预留续订
我们已经讨论了企业业务生产应用所需的 AOAI 各组件。接下来,我们将探索 AOAI 的某些扩展技术以克服局限性。
Azure OpenAI 扩展
AOAI 通常会对调用量进行限制。在 Azure OpenAI 中,这些限制表现 Token 限制(TPM,每分钟 Token 数)和每分钟请求限制(RPM)。然而,这些配额限于单个订阅、区域和特定模型。因此,许多客户选择跨区域使用多个 Azure OpenAI (AOAI) 资源来实现最大吞吐量。虽然“PAUG”设置中的这种配置没有解决延迟问题,但后续章节将使用 PTU 解决延迟问题。
当 PAUG 达到容量限制时,AOAI 会返回 429 或 TooManyRequests状态码,其 Retry-After响应头指定了在尝试下次请求之前应等待的秒数。处理这些错误通常由客户端 SDK 管理,但在使用多个 OpenAI 端点以获取最大吞吐量时,需要在客户端管理 URL 列表,这可能并不理想。为了解决这个问题,需要一种复杂的负载均衡机制,能够智能地决定流量何时以及路由到哪个 AOAI 端点。
APIM 为开发者提供了一个稳健的解决方案,可以向外部和内部用户安全地暴露 API。通过此平台,您可以实现智能负载均衡策略,考虑“Retry-After”和 429 错误响应,动态将流量路由到备选的 OpenAI 后端。此外,您可以灵活为 AOAI 端点建立优先级顺序,确保在高优先级端点未被限流时优先使用。在发生限流时,当高优先级端点恢复后,API 管理会自动切换到低优先级后端。这优化了资源利用率并最大限度地减少了服务交付的中断。让我用一个例子来解释:
正常情况:假设您在不同区域建立了多个 AOAI 端点,每个端点都分配了优先级。例如,您在不同区域建立了多个 AOAI 端点,每个端点都分配了优先级。
图 12.16:正常场景下的 APIM 负载均衡
Azure OpenAI 运营化
限流情况:当优先级 1 发生限流并产生 429 错误时,流量将路由到优先级 2。这确保了服务直到优先级 1 恢复。通常,优先级 1 将在“Retry-After”指定的时间后重新激活。
在定义优先级组时,您可以根据业务需求选择策略。例如,您可以实施基于地理位置的优先级方法,将所有美国 AOAI 资源组合为优先级 1,同样将所有加拿大 AOAI 资源组合为优先级 2。如果优先级 1(美国资源)发生限流,流量可以路由到加拿大区域作为备用。这确保了跨位置的资源利用率并维持了服务可用性。
Azure OpenAI 扩展
图 12.18:单区域 HA 扩展
有时,客户在使用 AOAI 的业务应用程序除了高可用(HA)还需要灾难恢复(DR)解决方案。在这种情况下,建议跨区域部署 AOAI PTU 和 PAUG 实例。根据各自的区域将特定的 AOAI 资源分配到不同的优先级组。以下是此类设置的架构。
图 12.19:多区域 HA 与 DR 扩展
286 Azure OpenAI 的运营
在提供的参考架构中,重点是主备 DR 策略,其中只有主区域的优先级 1 组处于激活状态。当该区域发生故障时,备区域的优先级 2 组将变为激活状态。然而,对于更主动的双活 DR 配置,可以将两个区域的 PTU 实例都指定为优先级组 1,并将 PAUG 实例分配到优先级组 2。这种配置确保了 PTU 得到有效利用,同时由 PAUG 实例处理任何额外的分流流量。
总结
本章涵盖了 AOAI 的关键方面,包括监控各种指标,如 API 调用次数、延迟、prompt token 总和以及 completion token 总和等。此外,还讨论了 AOAI 资源配额,概述了不同资源之间的限制以及如何有效管理和分配配额。此外,本章深入探讨了 AOAI 的预留实例概念——PTU,这对于任何生产工作负载至关重要。最后,它探索了如何使用多个端点扩展 AOAI,以及高可用(HA)和灾难备(DR)策略,这些都是构建企业级生成式 AI 的核心组件。
在接下来的章节中,我们将讨论 prompt 工程的概念,这是开发和优化生成式 AI 模型的重要基石。prompt 工程涵盖了多种技术,旨在精炼和定制提供给这些模型的 prompt 输入,从而影响其生成输出的质量、贯性和相关性。在整个章节中,我们将探索 prompt 工程中最流行的技术和具有影响力的策略。通过深入研究这些技术,我们旨在为您提供全面的见解和实用知识,这些对于在各种应用和领域中有效利用生成式 AI 模型的能力关重要。
13
高级 prompt 工程
在上一章中,我们涵盖了 Azure OpenAI (AOAI) 运营的关键方面,重点关注监控 API 调用量、延迟和 token 使用等关键指标以优化性能。我们还讨论了 AOAI 资源配额,强调了管理和分配配额的策略。此外,本章引入了生产吞吐量单元(PTU)的概念,这是处理生产工作负载至关重要的预留实例。为了构建具有韧性的 AI 应用,我们探索了使用多个端点结合高可用(HA)和灾难备恢复(DR)策略来扩展 AOAI。
到为止,我们探索了生成式 AI 可以简化工作流的各种场景,并研究了如何优化模型以增强其性能和可靠性。在本章中,我们将深入研究 prompt 工程——一种允许我们有效塑造 AI 响应行为和质量的关键技能。
学习 prompt 工程是至关重要的,因为我们表述 prompt 的方式会影响输出的相关性、创造性和清晰度。例如,使用一个通用的 prompt 如“总结这篇文章”让模型总结文章,可能会得到一个宽泛的回答,如“文章讨论了风能和太阳能等能源”。然而,将其改写得更具体,例如“总结这篇文章,重点关注可再生能源在发展中国家的经济效益”,将产生针对性的输出,如“文章强调了可再生能源如何通过减少对进口燃料的依赖,在发展中国家降低成本并创造就业机会”。这表明 prompt 如何有效地定制响应以满足特定需求。通过掌握这些技术,你将释放生成式 AI 的全部潜力,使其不仅成为强大的自动化工具,还成为解决复杂任务的协作伙伴。
在本章中,我们将涵盖以下主要主题:
-
什么是 prompt 工程?
-
Prompt 元素
-
Prompt 策略
-
Prompt 技巧
什么是 prompt 工程?
-
prompt 工程对比微调
-
优化 LLM 准确性
-
LLM 中的 prompt 注入攻击
prompt 工程是一种用于引导大语言模型 (LLM) 的响应指向特定结果的方法,而无需修改模型的权重或参数。相反,它完全依赖于精心设计的上下文提示(prompt)来达到所需的结果。本质上,它是与 AI 进行有效通信,以提取你想要的信息或行为。
这种技术对于增强 LLM 和视觉语言模型 (VLM) 的能力至关重要。通过使用特定任务的指令(即 prompt),它在不改变模型核心参数的情况下提高了模型性能。prompt 通过通过提供的提示词驱动模型行为,使模型能够无缝集成到各种下游任务中。
prompt 工程是一个相对较新的领域,专注于开发和优化 prompt,以便在广泛的应用和研究领域中高效利用语言模型。精通 prompt 工程有助于理解 LLM 的优势和局限性。研究人员利用 prompt 工程来提升 LLM 在从回答问题到解决算术题等各种多样任务上的表现。开发者则利用这种技术设计稳健且有效的 prompt,与 LLM 及其他工具进行交互。
然而,prompt 工程不仅仅是编写和开发 prompt。它涵盖了与 LLM 交互和开发至关重要的各种技能和技术。它是与 LLM 接口、在其基础上构建以及理解其能力的关键技能。此外,prompt 工程可增强 LLM 的安全性并开发新功能,例如将领域知识和外部工具集成到 LLM 中。
prompt 工程的一个重要方面是理解用户提示(user prompt)和系统提示(system prompt)的角色,这些角色会显著影响 LLM 的行为和输出。系统角色设定了模型的整体基调和行为,例如将其定义为乐于助人的助手(例如,“你是一个提供支持的导师或特定领域的专家(例如‘你是一个根据当前市场趋势提供投资建议的财务顾问’”)。另一方面,用户角色是终端用户提供的直接输入,例如问题或任务(例如,“用例子解释复利”)。这些角色在定义良好的当时,可以极大地影响生成的响应的质量和相关性。即使一些现代模型在演进过程中尽量减少或消除这些角色之间的显式区分,理解它们的影响对于优化 LLM 交互仍然至关重要。
现在我们理解了什么是 prompt 工程,让我们讨论 prompt 的关键元素。
Prompt 元素
Prompt 元素是用于引导和构建 AI 系统响应的关键组件,能够生成特定的或所需的输出。这些元素可以应用于各种语境,从编程 AI 到起草写作任务。虽然这些元素没有通用标准,且并非每个 prompt 都包含它们,但各种资源的共识确定了七个要素。理解并利用这些元素可以有效地塑造 AI 的输出,增强其相关性和质量。
在构建 prompt 时,有几个关键元素塑造 AI 的输出。每个元素在引导响应方面都起到特定作用,理解使用或不使用这些元素至关重要。让我们逐一探索这些元素,并说明它们的存在与否如何影响结果。(你在 Microsoft Copilot 中看到的截图,它内部使用 ChatGPT。)
上下文或场景
此元素的主要目的是为任务设定场景或背景,让 AI 对设定或目的有清晰的。让我们看看如何在 prompt 中实现这一点:
- 没有上下文:“解释云计算”
高级提示词工程
- 带有上下文: “想象你正在为小企业主撰写一篇关于云计算的博客文章。”
好的,这里有一篇为小企业定制的关于云计算的博客文章:
为小企业解锁云计算的力量
在当今快速发展的数字世界中,小企业需要保持敏捷和竞争优势。实现这一目标的最有效方法之一就是利用云计算。但云计算究竟是什么?它能如何为你的小企业带来收益呢?让我们深入探索一下。
什么是云计算?
云计算是一种允许你通过互联网访问数据和应用程序的技术,而不是在本地计算机或服务器上。将其想象为租赁一个虚拟办公空间,你可以在那里存储所有重要文档和工具,并随时随地从任何地方访问它们。
为什么小企业应该考虑云计算?
-
成本效益: 云计算的优势之一是其成本效益。你不需要投资昂贵的硬件和软件,而是根据订阅模式按需付费。这意味着更低的预付成本和可预测的每月支出。
-
可扩展性: 随着业务的增长,需求也会之增长。云计算允许你根据需求轻松扩大或缩小规模。无论你需要更多存储空间、处理能力还是额外的服务,都可以毫无压力地调整资源。
如你所见,没有上下文的回复会更加通用且缺乏特定的方向。有了上下文,回复会变得更有针对性,并为特定受众(小企业主)定制,从而影响语气和复杂程度。
指令 (Instructions)
该元素的主要目的是为 AI 应该应该做什么或生成什么提供清晰的指导,形成提示词的骨干,例所示:
-
没有指令: “云计算”(这会给出与第一个元素类似的回复)
-
带有指令: “写一段 200 字关于云计算的解释。”
云计算是一项变革性技术,它允许个人和企业通过互联网访问和存储数据、应用程序和服务,而不是依赖本地服务器或个人计算机。这种方法提供了许多优势,包括可扩展性、灵活性和成本效益。
云计算提供了对共享计算资源池的按需访问,例如服务器、存储和应用程序,这些资源可以以最少的管理工作快速配置和释放。这意味着企业可以根据需要轻松扩大或缩小 IT 资源,而无需对硬件进行大量的预付投资。
云服务主要有三种类型:基础设施即服务 (IaaS),在互联网上提供虚拟化计算资源;平台即服务 (PaaS),提供用于开发和运行应用程序的平台;以及软件即服务 (SaaS),以订阅方式在互联网上交付软件应用程序。
云计算还增强了协作,因为多个用户可以从不同的位置同时访问并处理相同的数据和应用程序。此外,它提供了稳健的安全措施、更新和灾难恢复选项,成为现代企业可靠且高效的解决方案。
图 13.3:带有指令的回复
当提供指令时,回复将遵循特定的准则(例如 200 字)。如果没有指令,AI 可能会产生过短、过长或重点模糊回复。
约束 (Constraints)
这些定义了限制,如语气、长度或必须包含的特定词汇,缩小了回复的范围。让我们来看一个例子:
-
没有约束: “解释云计算。”(这给出与第一个元素类似的回复。)
-
带有约束: “使用非技术术语解释云计算”
高级提示词工程
当然!想象你有一台计算机,可以在其中存储文件、运行应用程序并执行各种任务。现在,你不再依赖于自己的计算机,而是可以使用互联网访问庞大的计算机和存储系统网络。这就是云计算的本质。
通过云计算,你可以将文件和数据存储在远程服务器上,这些服务器由微软、谷歌或亚马逊等公司管理。这意味着你不需要担心自己计算机空间用尽,也不会在出现问题时丢失数据。只要有互联网连接,你就可以从任何地方访问你的文件。
此外,云计算允许你使用软件和应用程序,而无需在自己的计算机上安装它们。例如,你可以直接从网络浏览器使用文字处理器、电子表格和其他工具的在线版本。这使得协作变得容易,并确保你始终拥有最新版本的软件。
总而言之,云计算就像是随时随地在互联网上供你的超级计算机。
图 13.4:带有约束的回复
约束确保输出符合特定的语气或格式。如果没有约束,AI 可能会产生不符合受众的语言回复,或者以段落而非总结的形式呈现。
变量或输入 (Variables or inputs)
这些指定了需要包含的数据点或占位符。例如:
-
没有变量: “解释云计算。”(这给出与第一个元素类似的回复。)
-
带有变量: “在解释中使用‘Azure’和‘成本效益’”
当然!想象你有一台计算机,可以在其中存储文件、运行应用程序并执行各种任务。现在,你不再依赖于自己的计算机,而是可以使用互联网访问庞大的计算机和存储系统网络。这就是云计算的本质。
通过云计算,你可以将文件和数据存储在远程服务器上,这些服务器由微软、谷歌或亚马逊等公司管理。这意味着你不需要担心自己计算机空间用尽,也不会在出现问题时丢失数据。只要有互联网连接,你就可以从任何地方访问你的文件。
此外,云计算允许你使用软件和应用程序,而无需在自己的计算机上安装它们。例如,你可以直接从网络浏览器使用文字处理器、电子表格和其他工具的在线版本。这使得协作变得容易,并确保你始终拥有最新版本的软件。
Azure 等云服务最大的优势之一是它们具有成本效益的。你只需为你使用的资源付费,这意味着与构建和维护自己的硬件相比可以节省资金。这使得云计算成为所有规模企业的经济型且灵活的解决方案。
图 13.5:带有变量的图
使用变量确保关键信息或概念被包含。如果没有它们,细节可能会遗漏,导致回复不完整或不相关。
预期输出 (Desired output)
这指定了预期的回复格式或类型,引导模型相应调整,如下:
-
没有预期输出: “解释云计算。”(这给出与第一个元素类似的回复。)
-
带有预期输出: “为云计算生成一个简洁的要点总结。”
图 13.6:带有预期输出的图
指定预期输出可以确保回复符合目标格式(例如要点)。如果没有它,AI 可能会产生不符合用户需求或预期的回复,例如以段落而非总结。
语气或风格 (Tone or style)
这指示了回复听起来如何,影响语言、正式程度和整体风格。让我们来看一个例子:
-
没有语气或风格: “解释云计算。”(这给出与第一个元素类似的回复。)
-
带有语气或风格: “用友好的方式解释云计算
高级提示词工程
用友好、对话式的口调解释云计算
图 13.7:带有语气或风格的图
当定义了语气时,AI 会调整语言以匹配所需的情绪。如果不指定语气,AI 可能会提供更中立或正式的回答,这可能不符合上下文或受众。
示例和模板
这些提供了示例响应,以说明预期的输出格式或类型,为 AI 提供了遵循的模型。让我们看看如何使用这些:
-
没有示例或模板:“解释云计算。”(这给出的响应与第一个元素相似。)
-
带有示例或模板:“这里有一个例子:云计算允许你将数据存储在他人的服务器上,而不是自己的服务器上。现在,写一个类似的解释”
图 13.8:带有示例的图
示例和模板引导响应的结构和语气。没有它们,AI 可能会生成不遵循特定格式或风格的响应,可能导致输出过于通用或偏离目标。
将这些元素整合到提示词中,可以确保 AI 提供定制的、聚焦且符合预期结果的响应。如果没有这些元素,响应可能会变得模糊、通用或误导。通过提供上下文、指令、限制条件、变量、预期输出、语气和示例,你本质上是在塑造 AI 的理解,并引导它产生特定的、相关的且高质量的回答。
然而,通常最好将指令放在最后,以确保模型专注于执行任务,而不是扩展内容。随着提示词工程领域的不断演进,这些原则为编写高效的提示词提供了坚实的基础。
在了解了提示词的要素后,让我们现在探索设计高效提示词的不同策略。这些策略将帮助你结合这些元素,从 AI 处获得更相关、更准确的响应。
提示词策略
提示词策略是指编写请求或指令的技巧或方法,使其从 AI 模型(如语言模型)激发特定或预期的响应。这些策略旨在引导 AI 的输出根据用户需求变得更相关、准确或更有用。它们具有以下几个核心作用:
-
增强准确性:通过巧妙地构建提示词,你可以鼓励 AI 产生更精确、更相关的响应。
-
增加特定性:定制提示词可以帮助你获得更详细、更具体的答案,最大限度地减少模糊性或无关信息。
-
激发创造力:在需要创造力的任务中,这些策略可以引导 AI 探索非传统的想法,或关注特定的风格和格式。
-
提高效率:精心设计的提示词可以减少多次迭代的需求并减少错误,节省实现所需结果的时间。
让我们深入研究六种关键策略,以增强你与语言模型的交互:
-
提供精确且清晰的指令
-
利用参考材料
-
将复杂任务分解为可操作的步骤
-
允许模型处理或“思考”
-
利用外部工具以增强能力
-
系统地测试并衡量变化的影响
在上一节中,我提供了每个提示词结果的截图来证明它们的有效性。然而,对于接下来列出的策略,我不建议提供截图,而是鼓励你亲自去探索它们。打开任何 LLM 应用(例如 ChatGPT、Microsoft Copilot 或 Azure OpenAI Playground),并尝试实验提供的提示词示例。尽管混合组合不同的策略,以观察它们如何影响输出。这种通过上手的方法将帮助你更好地理解提示词工程的细微差别,并发现针对你的特定用例优化结果的方法。
让我们深入每种策略,并检查具体的技巧以更有效地处理它们。
编写清晰的指令
语言模型虽然强大但不直观。为了获得理想的结果,你必须明确你的期望。如果模型的回答太长,请要求简洁的回答。如果它们缺乏深度,请请求更详细或专家级的内容。清晰的指令可以减少猜测,增加获得更准确响应的概率。我们将查看一些帮助你编写清晰指令的技巧:
-
在查询中包含细节:
包含特定细节可确保响应与你的需求相关。
这里有一个例子:
好的:“总结云计算的主要优势,特别是对小企业的优势。”
坏的告诉我关于云计算的知识。”
-
要求模型采用特定角色:
通过定义目标受众来定制模型的响应,可以确保解释符合所需的语气和复杂度。
这里有一个例子:
好的:“就像你在教一个没有 IT 经验的初学者一样解释 Kubernetes。”
坏:“解释 Kubernetes。”
-
使用分隔符指示输入的的不同部分:
将输入分为清晰的章节可以防止信息混合在一起,确保结构化的响应。
这里有一个例子:
好:“写一段 AI 的介绍。然后,解释它对医疗保健的影响。”
坏:“谈谈医疗保健。”
-
指定完成任务的步骤:
将任务分解为可操作的步骤使输出更具实用性。
这里有一个例子:
好:“概述在 Azure 上部署 Node.js 应用的步骤,从设置到部署。”
坏:“如何部署应用?”
-
提供示例:
提供示例可以为模型提供上下文,从而提高响应质量。
这里有一个例子:
好:“DevOps 集成了开发和 IT 团队以简化部署。”
坏:“什么是 DevOps?”
-
指定输出长度:
通过指定字数,你可以确保响应简洁明了。
这里有一个例子:
好:“用 50 字解释云存储。”
**坏:“解释云存储。”
提供参考文本
语言模型有时会生成错误或虚假的答案,特别是对于冷门话题。提供参考文本可以通过事实提高响应的可靠性。这里是一些技巧:
-
指示模型使用参考文本回答:
引导模型参考来源可以确保响应是准确且相关的。
这里有一个例子:
好:“使用此 Azure 文 [link],解释 Azure Policy 如何实施治理。”
**坏:“Azure Policy 如何实施治理?”
-
指示模型使用参考文本中的引用:
要求引用可以通过回溯到可验证的来源来增加响应的可信度。
这里有一个例子:
好:“根据提供的论文,总结 AI 的伦理挑战并引用相关章节。”
坏:“AI 有哪些伦理挑战?”
将复杂任务拆分为更简单的任务
将任务分解为更小、易管理的步骤可以减少错误并增加结果的清晰度。复杂任务通常可以结构化为序列,一个子任务的输出作为下一个任务的输入。让我们来看一些技巧:
-
使用意图分类识别相关指令:
划分任务更容易专注于每一个具体的步骤,从而获得更好的结果。
这里有一个例子:
好:“将设置 CI/CD 流水线的过程拆分为不同的阶段:开发、测试和部署。”
**坏:“解释如何设置 CI/CD 流水线。”
-
在长对话中对之前的对话进行总结或过滤:
对冗长的对话进行总结有助于保持上下文,而不会让模型过载。
这里有一个例子:
好:“在继续之前,总结一下我们关于云迁移的对话的第一部分。”
**坏:“继续讨论云迁移。”
-
分章节总结长文档:
分章节总结可以确保不会在长文档中遗忽略重要细节。
这里有一个例子:
好:“总结这篇论文的第 1-3 章,然后总结第 4-6 章。”
**坏:“总结整篇论文。”
给模型留出思考时间
鼓励模型采取分步进行的方法可以提高准确性,特别是在涉及推理的任务中。这类似于人类在回答复杂问题之前可能会停顿进行计算或反思。以下是一些技巧:
- 指令模型推导出它自己的解决方案:
通过遍历每一个步骤,模型有更大的机会提供正确答案。
这里有一个示例:
好的: “请列出计算 25 x 17 的步骤,然后给出最终答案。”
不好的: “25 x 17 是多少?”
- 使用“内心独白”对推理进行反思:
鼓励模型在回答之前进行内部反思,以确保回答更具深思熟虑。
这里有一个示例:
好的: “大声思考出来:你会采取哪些步骤来评估 API 的安全性?”
不好的: “你如何评估 API 安全性?”
- 询问模型是否遗漏了任何内容:
提示模型检查其答案可以增加获得全面回答的概率。
这里有一个示例:
好的: “在列出无服务器架构的优势之后,检查是否遗漏了关键点。”
不好的: “无服务器架构的优势是什么?”
使用外部工具
为了弥补语言的局限性,你可以通过提供来自其他工具的数据来增强其能力。外部工具可以协助计算、文档检索或其他专门功能,例如这些示例:
- 使用基于嵌入的搜索进行高效知识检索:
使用外部工具可以确保响应是最新且准确的。
这里有一个示例:
好的: “使用文档检索系统搜索 Azure 安全最佳实践的最新更新。”
不好的: “Azure 安全的最新更新是什么?”
- 使用代码执行进行计算:
将复杂的计算外载给外部工具不仅提高了精确度,还减少了语言模型本身的计算负载。这种策略允许模型专注于其擅长的领域(例如推理和语言生成),将更适合专门工具的任务委托出去。良好的提示词显式地引导系统利用外部资源进行计算,确保了准确性和效率。这种方法对于需要高精度或特定领域计算的任务特别有用,让语言模型保持响应能力和可靠性。
这里有一个示例:
好的: “使用代码执行工具计算在 Azure Blob Storage 上存储 500 GB 数据的月成本。”
不好的: “在 Azure 上存储 500 GB 需要多少费用?”
- 给模型访问特定函数的权限:
使用外部 API 允许进行实时、准确的数据检索。
这里有一个示例:
好的: “访问 API 获取最新的天气数据并进行总结。”
不好的: “今天天气如何?”
系统地测试更改
为了提高模型的性能,系统地测试对提示词(prompt)的更改至关重要。根据全面的标准对结果进行评估可以确保一致性并避免意外的性能下降。让我们来看一种技巧:
- 根据金标准答案评估模型输出:
使用大型数据集进行系统化测试可以确保提示词是稳健且具有通用性的。
这里有一个示例:
好的: “在 20 个不同的用例测试此提示词,将响应与预定义的正确答案进行比较。”
不好的: “测试此提示词是否有效。”
在理解提示策略时,可以明显看出精心设计的输入如何塑造 LLM 的行为,在功能性和安全性之间取得平衡。随着我们的进展,让我们探索利用这些策略的特定技巧,深入研究其实应用和潜在风险。
提示技巧
提示技巧是用于结构化或表述你的输入(提示词)的策略,旨在引导语言模型(如 GPT)提供更准确、相关且实用的回答。这些技巧至关重要,因为你提问或指示模型的方式决定了输出的质量。
以下是一些常见的提示技巧。
零样本提示 (Zero-shot prompting)
零样本提示是一种用于 LLM 的技术,要求模型在没有针对该任务的任何特定训练或示例的情况下执行任务。相反,模型依靠其预有的知识和通用语言理解能力来生成响应。通过直接给出任务或问题,零样本提示利用了模型在通用训练期间学到的模式来应对新任务。虽然这种方法可以产生准确的结果,但如果模型缺乏明确预期输出格式的示例,有时会面临挑战。
在这个示例中,我们希望模型将餐厅评论分类为正面或负面:
-
提示词:“食物毫无滋味且冰冷。”
-
输出:模型可能由于缺乏上下文或示例而错误地分类(例如,说评论是正面的)
-
提示词:“对这条评论的情绪分类:‘食物毫无滋味且冰冷。’”
-
输出:模型尝试根据通用知识对评论进行分类,但如果没有示例,准确性可能较低(例如,取决于训练,它可能是正面或负面)
零样本提示的一些优势如下:
-
无需示例:这种方法不需要准备示例,实施快速。
-
任务灵活性:模型可以尝试各种任务,即使这些任务是新的或不熟悉的。
一些实际应用如下:
-
文本分类:将产品评论分类为正面或负面,将电子邮件分类为“垃圾邮件”或“非垃圾邮件”,或按紧急程度组织支持工单
-
问答:回答关于通用主题的查询,例如“法国的首都是哪里?”或为技术术语提供定义
-
翻译任务:在没有先接触的情况下将“你好,你好吗?”等简单短语翻译成另一种语言
-
摘要:将新闻文章浓缩为简短摘要,例如将一份关于气候变化的 500 字报告总结为一句话。
通过利用零样本提示,用户可以用最少的设置探索广泛的任务,展示了 LLM 在不同场景下的适应性和实用性。然而,重要的是,虽然零样本提示具有高度通用性,但与少样本提示相比,它更容易出现错误。少样本提示通过为模型提供示例,可以显著增强输出的关联性和准确性,使其成为更复杂或敏感任务的首选方案。我们将在下一部分深入探讨少样本提示,探索其优势和策略。
少样本提示 (Few-shot prompting)
少样本提示是一种用于 LLM 的策略,涉及向模型提供一小组示例以引导其生成准确的回答,允许在不需要对大量数据集进行重新训练或微调的情况下进行上下文学习。这种方法涉及在提示词中包含几个代表性的输入-输出对,帮助模型理解如何处理它可能难以应对相似的任务。通过利用这种上下文学习能力,少样本提示通过有限数量的示例建立模式,使模型能够在回答查询时应用学到的结构。
假设你希望模型将餐厅评论分类为正面或负面:
-
无少样本提示:
-
提示词:“食物毫无滋味且冰冷。”
-
输出:正面(错误)
-
有少样本提示:
-
提示词:
“示例 1:‘服务太棒了!’ -> 正面
示例 2:‘我不推荐这个地方。’ -> 负面
对这条评论的情绪分类:‘食物毫无滋味且冰冷。’”
- 输出:负面(正确)
在这种情况下,包含两个先前的示例显著提高了模型的理解能力,导致了更准确的分类。
以下是少样本提示(few-shot prompting)的某些优势:
-
增强性能:通过提供示例,可以最大限度地减少歧义,帮助模型更好地理解上下文并提供相关的答案。
-
快速适应:模型仅需使用几个示例即可快速适应新任务,这使其在不同应用中具有极高的通用性。
-
无需大量的微调:不需要进行大规模训练,因为提示词中的示例充当了某种微训练的形式。
以下是一些实际应用:
-
文本分类:通过提供几个分类示例来对文本进行分类,例如检测邮件是否为垃圾邮件。
-
翻译:提供示例翻译,可以帮助模型准确地翻译新句子。
-
摘要生成:演示如何总结文章,使模型能够在未来的摘要中复制该格式。
-
问答系统:格式化问题和答案,以引导模型为用户的查询生成相关的答案。
少样本提示是让大语言模型(LLMs)适应新挑战的一种非常有效的手段,使其能够以极少的输入生成更精确、更符合上下文的响应。
思维链提示 (CoT)
思维链(Chain-of-thought,CoT)提示是增强大语言模型推理能力的有效方法。CoT 不让模型直接生成答案,而是鼓励它解释得出解决方案所需的涉及的步骤。这反映了人类处理复杂问题的方式,即将其拆解为易于管理的组件。
CoT提示本质上是引导模型通过逐步解决问题来“大声思考”,从而得出更清晰、更准确的答案。这种技术对于需要多步推理的任务(如逻辑谜题或计算)特别有用,并能增强模型避免错误的能力。
与其期望一个即时输出,不如提示模型解释解决方案的每个阶段。这一过程通过引导模型完成准确回答所需的推理步骤,降低了错误发生的概率。
比方说,你正在解决一个涉及识别质数的问题。
以下是一个没有使用 CoT 提示的示例:
-
提示词:“29 是质数吗?”
-
输出:是的。
这里是使用 CoT 提示的示例:
-
提示词:“29 是质数吗?请说明推理过程以确定答案。”
-
输出:要确定 29 是否为质数,需要检查它是否能被 1 和自身以外的任何数字整除。从较小的质数开始测试:2、3、5。这些数中没有一个能整除 29 的。因此,29 是质数。
通过提示模型执行每一步操作,它避免了捷径,并提供了逻辑严密的解释,增加了对答案的信赖。
CoT 提示的益处如下:
-
提高准确性:引导模型通过一个过程有助于防止推理错误,尤其是在复杂任务中。
-
更好的问题解决能力:这种技术分步执行的特性非常适用于需要逻辑推演的场景,例如数学题或谜题。
-
增加透明度:这种方法让用户更清楚地理解模型是如何得出结论的,从而增强了对输出的信任。
在处理可能因跳过中间步骤产生错误答案的任务时,CoT 提示非常有价值。它对于技术领域的用户特别有用,例如软件开发、调试、数学运算和逻辑推理在这些领域是核心:
-
数学与计算:将多步方程拆解为更小、更容易处理的部分。
-
逻辑推理与谜题:演练谜题或逻辑问题的步骤,以确保获得准确的解决方案。
-
代码调试:通过要求模型拆解代码的每个部分,可以轻松识别错误。
-
语言翻译:通过带有中间解释的翻译复杂句子,确保最终翻译更准确。
CoT 提示增强了大语言模型在涉及推理和多步过程任务中的可靠性,使其成为用户在挑战性场景下寻求高质量输出的强大工具。
思维树 (Tree of Thoughts)
思维树(Tree of Thoughts,ToT)
对于需要复杂探索和预见性任务,传统的提示方法可能不足以解决问题。思维树(Tree of Thoughts,ToT)框架是一种创新方法,它建立在 CoT 提示的基础上,通过让语言模型将思想作为中间步骤进行探索来解决问题。
ToT 框架将思想组织为指向解决方案的连贯序列。这种结构允许语言模型通过中间思维评估其进度。生成和评估这些思维的能力通过广度优先搜索(BFS)和深度优先搜索(DFS)等算法得到了补充,促进了包括回溯在内的探索。
BFS 适用于该框架,因为它在每个阶段都探索选项,确保了评估的广度。另一方面,DFS 关注单一路径的深度探索,允许进行详细的推理。此外,BFS 和 DFS 提供了一种平衡的方法,使模型在解决策略中兼顾广度和深度。
为了有效使用 ToT,需要建立特定的参数,例如思维的数量和涉及的步骤。例如,在数学推理任务如"24点"中,思维被拆解为三个连续步骤,每个步骤涉及一个中间方程。在每个阶段保留五个候选者。
在 24 点任务的 BFS 期间,语言模型使用"确定"、"可能"或"不可能"来评估每个思维,以达到 24 点的目标。根据作者的观点,目标是鼓励产生可以在几次预测内进行评估的准确部分解决方案,并根据数值"太大"或"太小"的常识推理消除不合理的解决方案,其余的归类为"可能"。每个思维都会进行三次采样。
在这个示例中,模型根据用户的标准检查了各种饮食偏好,从而对潜在的餐厅选择进行了全面的评估。
ToT 框架的优势
ToT(思维树)框架的优势包括以下几点:
-
增强推理能力: 树形结构允许模型系统地考虑多个选项及其影响。
-
改进决策能力: 结构化的方法有助于权衡各种路径的优缺点,产生更具见解且细致入微的结果。
-
更大的灵活性: 随着新信息或约束条件的出现,模型可以动态调整其推理过程。
实际应用
实际应用包括:
-
解决复杂问题: ToT 有利于处理错综复杂的问题,例如制定策略或排除技术故障。
-
创意写作: 它可以通过探索不同的故事情节和人物弧来帮助进行叙事内容的头脑风暴。
-
决策辅助: 在个人和职业环境中,ToT 都能帮助个人评估选择和潜在后果。
总之,ToT 框架是一个强大的工具,赋予了 LLM 有效处理复杂任务的能力,显著提升了它们的推理和决策能力。
检索增强生成(RAG)
通用语言模型可以针对情感分析和命名实体识别等常见任务进行微调。然而,这些任务通常不需要广泛的背景知识。对于更复杂且对知识要求更高的任务,开发允许模型利用外部知识源的系统将是有益的。这种能力增强了事实的准确性,提高了生成响应的可靠性,并减少了所谓的"幻觉"现象(即模型自信地生成错误信息)。
为了应对此类复杂任务,Meta AI 的研究人员推出了检索增强生成(RAG)。这一创新框架将信息检索机制与文本生成模型相结合,允许在不需要完全重新训练系统的情况下,对模型的内部知识进行高效调整。
图 13.9:RAG 架构
RAG 的高层流程
这是来自前述架构的 RAG 应用的高层流程:
-
用户通过智能应用程序界面提交查询。
-
应用调用编排器(例如
Semantic Kernel、Azure Machine Learningprompt flow 或LangChain),编排器向Azure AI Search发出搜索查询。 -
编排器检索前
N个结果并将它们与原始查询整合到提示词(prompt)中。 -
将提示词发送给语言模型,并将响应返回应用程序供用户阅读。
工作原理
其工作原理如下:
-
输入与检索: 当用户提交查询时,RAG 会从指定的源(如维基百科)检索一组相关文档。这些文档随后被处理为嵌入(embeddings),即高维向量表示,允许在语料库中进行高效的相似性搜索。根据嵌入检索相关文档,并与原始输入提示词合并,以提供外部上下文。
-
生成: 融合了外部上下文的合并输入被送入文本生成器中。这种集成使模型能够生成基于用户查询和额外检索信息的响应,从而产生更准确、更符合语境的输出。
-
适应变化: RAG 在信息随时间演变的情况下特别具有优势。传统的语言模型可能会由于其静态知识库而过时。通过利用实时检索,RAG 确保语言模型可以根据最新的信息进行访问并生成输出,使其能够适应动态环境。
示例
假设一个用户在查询:"采用电动汽车的主要优势是什么":
-
检索: 系统从其数据库中检索讨论电动汽车优势的最新文章。
-
生成: 语言模型综合这些信息并生成响应。
-
输出: 模型可能会做出如下回答:电动汽车提供了多种优势,例如减少温室气体排放、降低燃料成本以及提供更安静的驾驶体验。例如,随着电动汽车普及率的提高,许多城市的空气污染有所减少。
RAG 的优势
RAG 的优势包括:
-
增强准确性: 通过访问外部知识,RAG 生成了更精确、更符合事实的答案,特别是对于需要最新数据的问题。
-
语境相关性: 检索过程确保响应不仅准确,而且符合用户的特定语境。
-
增加灵活性: RAG 系统可以在无需大量模型重新训练的情况下快速适应新信息,使其保持时效性和灵敏度。
-
可扩展性: RAG 可以高效地处理大规模语料库,从成千上万份文档中检索相关上下文。这种扩展性使其能够提供更丰富、更全面的响应,使其适用于从客户支持到研究的广泛应用。
RAG 的挑战
虽然 RAG 提供了许多优势,但也面临着挑战。不当的分段会导致上下文无关或不完整,这可能会降低模型响应的准确性。此外,实施 RAG 可能会消耗资源,特别是在扩展到大规模语料库时。运行频繁的检索查询和存储海量数据集的成本可能是巨大的,特别是在高需求场景下。最后,建立 RAG 系统比传统方法更复杂,需要专业知识来整合检索机制、管理数据集以及对系统进行微调以获得最佳性能和准确性。
实际应用
实际应用包括:
-
交互式问答: RAG 可以用于聊天机器人或虚拟助手,通过根据需要获取相关信息来提供精确且及时的回答。
-
内容生成: 作者可以利用 RAG 收集最新的见解,并编写具有深度见解的文章或报告。
-
客户服务增强: 企业可以使用 RAG 改进其客户支持系统,快速访问知识库以提供准确且及时的答复。
GraphRAG
虽然 RAG 对许多应用非常有效,但 GraphRAG 为 RAG 提供了一种更具结构化、层次化的方法,使其成为需要深度互联任务的理想选择。与依赖语义搜索文本片段的传统 RAG 不同,GraphRAG 从原始文本提取知识图谱,构建社区层次结构,并为这些社区生成摘要。这些结构随后被用于执行基于 RAG 的任务,模型能够更好地理解并推理多个实体之间的关系。这种方法对于涉及多步推理或相关概念的复杂查询特别有用。
总之,RAG 代表了自然语言处理的一大进步,为语言模型提供了交付更具见解和上下文敏感输出所需的工具。
程序辅助语言模型(PALMs)
程序辅助语言模型(PALMs)的概念由 Gao 等人(2022)提出,该方法使 LLM 处理自然语言查询并生成中间编程步骤以得出解决方案。与传统的思维链(CoT)提示依赖于生成自由格式文本来阐述解决方案不同,PALMs 利用编程运行时(如 Python 解释器)执行计算和数据处理。
示例——计算事件的星期
为了说明这一点,让我们考虑一个使用 LangChain 结合 OpenAI GPT-3 的简单应用程序,旨在根据给定日期确定特定历史事件的星期。
首先,获取所需的导入项:
import openai
from datetime import datetime
import os
from langchain.llms import OpenAI
from dotenv import load_dotenv
首先设置必要的配置:
load_dotenv()
## API 配置
openai.api_key = os.getenv("OPENAI_API_KEY")
## 为 LangChain 设置
os.environ["OPENAI_API_KEY"] = os.getenv("OPENAI_API_KEY")
然后,我们设置模型实例:
llm = OpenAI(model_name='text-davinci-003', temperature=0)
我们将使用一个关于历史日期的示例问题:
question = "What day of the week was July 20, 1969, when humans first landed on the Moon?"
DAY_OF_WEEK_PROMPT = """
## Q: 如果今天是1776年7月4日,那是星期几?
today = datetime(1776, 7, 4)
day_of_week = datetime.strftime('%A')
day_of_week
# Q: 1918年11月11日(第一次世界大战结束日)是星期几?
historical_date = datetime(1918, 11, 11)
day_of_week = historical_date.strftime('%A')
day_of_week
## Q: {question}
""".strip() + '\n'
现在,我们构建提示词。这是一个包含各种示例以引导模型的结构化提示词:
使用提示词调用模型并打印输出:
llm_out = llm(DAY_OF_WEEK_PROMPT.format(question=question))
最后,我们执行生成的代码:
llm_out 的内容是一段 Python 代码段。在这里,使用exec命令来执行这段 Python 代码段:
exec(llm_out)
print(day_of_week)
这将会输出以下内容:
| Mathematica |
| :--- |
| Sunday |
PALMs 的优势
PALMs 将语言模型的优势与编程能力相结合,使其能够执行需要逻辑推理、计算和结构化数据处理的任务。这种协同作用通过将自然语言理解与计算能力融合,增强了模型处理复杂查询的能力。
PALMs 的优势包括:
-
增强的问题解决能力: PALMs 有效地处理既需要语言理解又需要计算技能的查询,扩展了它们在各种应用中的通用性。
-
提高准确性: 通过执行代码,PALMs 最大限度地减少了计算或数据操作中的错误,从而产生更精确的输出。
-
动态适应性: 编程集成允许 PALMs 适应各种查询,在无需对模型进行大量训练的情况下高效地处理任务。
PALMs 的潜在风险
虽然 PALMs 具有显著优势,但在安全性方面也存在潜在风险。一个担忧是生成或执行恶意代码的可能性。由于它可以根据用户查询自主编写并运行代码,存在模型无意中产生有害或不安全代码的风险。如果不进行适当的监控或限制,可能会导致应用程序或系统的漏洞。此外,对代码执行的依赖可能会使系统暴露于安全漏洞,特别是模型与敏感数据或系统交互时。需要建立适当的安全措施和安全协议来降低这些风险。
PALMs 的实际应用
实际应用包括:
-
数据分析: PALMs 可以分析大型数据集,通过执行计算脚本提供见解。
-
技术支持: 它们可以通过实时运行诊断脚本来自动故障排除,从而快速解决问题。
-
教育工具: PALMs 通过交互式演示编程概念、执行代码段以供实际理解来促进学习。
总之,PALMs 标志着自然语言处理的重大进展,通过有效整合语言理解与计算逻辑,使模型能够提供信息丰富且上下文丰富的输出。
ReAct 提示词
2022年,Yao 等人引入 ReAct 框架,该框架利用大语言模型(LLMs)将推理过程与特定任务动作交替。这种创新方法增强了语言模型在生成连贯且相关的响应方面的有效性。
ReAct 框架允许模型生成推理轨迹(reasoning traces),使其在处理异常时能够制定、监控和更新行动计划。此外,动作组件与外部源(如数据库或知识库)交互,便于检索补充信息以增强响应的准确性。
通过利用 ReAct 框架,LLMs 可以与外部工具交互收集信息,产生更可靠且基于事实的输出。研究表明,ReAct 在语言理解和决策任务方面的表现可以超过最先进的模型。该框架还提高了 LLMs 的可解释性和信任度。作者发现,最佳方法是将 ReAct 与 CoT(思维链)提示词相结合,这利用了推理过程中获得的内部知识和外部信息。
ReAct 的灵感来自推理与动作之间的协同,反映了人类学习新任务和做出决策的方式。传统的 CoT 提示词证明对于让 LLMs 执行涉及算术和常识推理问题的推理任务是有效的。然而,缺乏对外部知识的访问会导致幻觉和错误传播等问题。
ReAct 集成了推理和动作。它提示模型为任务生成口头推理路径和动作,允许动态推理。这一过程涉及创建、维护和调整计划,同时允许与外部环境(例如维基百科)交互以将相关信息纳入推理。
ReAct 示例
为了演示 ReAct 提示词的工作原理,考虑一个在线问答游戏的问题:
问题: "除了 Apple Remote,还有哪些设备可以控制 Apple TV?"
-
思考 1: 模型意识到它需要搜索与 Apple TV 兼容的设备。
-
动作 1: 模型执行搜索:
Search[Apple TV compatible devices] -
观察 1: 模型检索了可以控制 Apple TV 的设备信息。
-
思考 2: 模型总结了检索到的信息:
Finish[Compatible devices: iPhones, iPads, universal remotes]
这一结构化过程说明了 ReAct 如何帮助模型基于推理和动作生成响应。
ReAct 提示词的优势
ReAct 提示词的优势包括:
-
提高连贯性: 通过将推理与动作分离,ReAct 生成的响应逻辑严密且易于遵循。
-
增强相关性: 这种方法允许模型生成符合上下文的动作。
-
更大的灵活性: ReAct 提示词可以适应于各种领域,从教育和技术支持到创意写作。
本质上,ReAct 提示词代表了语言模型生成响应方面的重大进展。
Reflexion(反思)
Reflexion 是一种创新的框架,旨在通过引入语言反馈来增强基于语言的智能体。正如 Shinn 等人(2023)强调的,"Reflexion 代表了一种口头强化的新范式,构建了一种能够激活记忆的策略。"
其核心是 Reflexion 将环境提供的反馈(无论是自然语言形式还是数值形式)转换为 LLM 智能体的自我反思见解。这一过程帮助智能体从过去的错误中学习,从而提高性能。
Reflexion 框架的组成
Reflexion 框架由三个关键组件组成:
-
执行者(Actor): 该模型根据其在环境中的观察生成文本和动作。执行者执行动作并接收反馈,创建经验轨迹。CoT 和 ReAct 等技术可以作为执行者模型。此外,记忆组件丰富了智能体的可用上下文。
-
评估者(Evaluator): 负责评估执行者产生的输出,该模型评估被称为短期记忆的生成轨迹,并分配奖励分。根据所处理的任务,会使用不同的奖励函数,包括 LLM 和用于决策的基于规则的算法。
-
自我反思(Self-reflection): 该组件生成口头强化,以引导执行者的表现。利用当前轨迹和积累的记忆,该模型利用奖励信号产生相关的反馈,并存储起来供将来参考。智能体可以利用这些经验来增强其决策能力。
总之,Reflexion 过程涉及定义任务、生成轨迹、评估轨迹、反思性能并生成下一条轨迹。这种方法通过引入自我评估、反思和记忆元素,在 ReAct 框架的基础上进行了改进。
研究表明,Reflexion 智能体显著提升了各种任务的性能,包括 ALFWorld 环境中的决策制定、HotpotQA 中的推理挑战以及 HumanEval 上的编码任务。
例如,在 ALFWorld 的顺序决策中,ReAct 与 Reflexion 的结合优于单独的 ReAct,它通过采用自评估技术(如启发式评估和基于 GPT 的二分类),在 134 个任务中成功完成了 130 个。
Reflexion 相比基准模型也展现出显著优势,特别是在推理任务中。当包含短期情节记忆时,结合 CoT 的 Reflexion 始终优于没有记忆的 CoT 模型。
何时使用 Reflexion
Reflexion 在以下场景中特别有益:
-
试错学习:智能体必须从错误中学习,使得 Reflexion 成为涉及决策、推理和编程任务的理想选择。
-
传统方法不可行:传统的 RL 技术通常需要大量数据和复杂的模型微调。Reflexion 提供了一种更高效的方法,不需要对底层语言模型进行调整。
-
需要细致反馈:通过利用语言反馈,与传统的标量奖励相比,Reflexion 允许更详细、具体的指导,让智能体能够更好地理解自己的缺点。
-
解释性的重要性:与传统的强化学习方法相比,Reflexion 提供了更清晰明确的情节记忆,便于分析智能体的学习过程。
Reflexion 的应用
Reflexion 在各种应用中已被证明是有效的:
-
顺序决策:Reflexion 智能体在导航 ALFWorld 等任务中表现出更好的结果,智能体必须穿越不同的环境并完成复杂目标。
-
推理任务:该框架增强了智能体在 HotpotQA 等数据集上的性能,这些数据集需要多文档推理。
-
编程挑战:Reflexion 智能体在 HumanEval 和 MBPP 等基准测试的代码生成任务中表现出色,通常能达到最先进的结果。
Reflexion 的局限性
虽然 Reflexion 非常强大,但它确实存在某些局限性:
-
依赖自评估:Reflexion 的有效性取决于智能体准确评估其性能并提供有用反思的能力,这对于复杂任务来说可能是挑战性的。然而,随着模型能力的提高,预计未来会缓解这个问题。
-
内存管理:Reflexion 采用了容量有限的滑动内存结构。对于更复杂的任务,集成先进的存储解决方案(如向量嵌入或 SQL 数据库)可能会是有益的。
-
代码生成的挑战:测试驱动开发存在固有的局限性,特别是输入输出映射的准确性,包括非确定性函数和硬件影响的问题。
Reflexion 提示
Reflexion 提示通过集成反馈循环机制来增强大语言模型(LLMs)的推理能力。这种方法增强了模型反思自身推理过程的能力,促进了自我纠正和持续改进。
Reflexion 提示的关键特征包括:
- 自反思:模型评估之前的输出和推理步骤,识别不准确之处或逻辑漏洞。
核心特性
-
迭代改进:允许模型根据自反思不断完善其推理和行动,产生一系列随时间演变的响应。
-
动态推理:
Reflexion提示支持适应性,允许模型根据新获得的见解或反思调整其输出。
Reflexion 提示的过程
涉及的步骤如下:
-
初始提示:用户提出问题或任务。
-
响应生成:模型根据训练和输入生成初步答案。
-
自评估:模型反思其响应以确定其充分性。
-
精炼:模型修改原始响应,纳入新的见解或修正。
-
最终输出:模型交付精炼后的答案,旨在提供更精确和上下文相关的信息。
以下是 Reflexion 提示的示例:
-
初始问题:“学习新语言的主要优点是什么?”
-
初始响应:学习新语言可以提高沟通能力、开启文化体验并增强认知能力。
-
自评估:模型意识到对这些优势进行进一步阐述可能会有所益处。
-
精炼:模型修改了其响应:学习新语言不仅通过与不同人群互动来提升沟通能力,还通过与不同传统和观点建立更深层的联系来丰富文化体验,并通过新的结构和词汇挑战大脑来增强认知能力。

浙公网安备 33010602011771号