贷款审批模型不得基于性别或种族歧视申请人。
应用负责任 AI 的公平性原则：评估并缓解不同人口群体间的偏见。
原因: 公平性旨在实现公平对待；不要将其与可靠性（一致结果）或隐私（数据保护）混淆。
最后审核：2026年6月
AI-901 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。
贷款审批模型不得基于性别或种族歧视申请人。
应用负责任 AI 的公平性原则：评估并缓解不同人口群体间的偏见。
原因: 公平性旨在实现公平对待；不要将其与可靠性（一致结果）或隐私（数据保护）混淆。
自动驾驶模型必须在意外情况下保持一致行为并安全地失效。
应用可靠性和安全性：针对边缘情况进行严格测试、监控和设置防护措施。
原因: 可靠性和安全性是指在不确定性下保持一致且避免伤害的行为，而不是关于数据涉及的对象。
健康应用处理个人数据，必须保护其免遭泄露或滥用。
应用隐私和安全性：保护个人数据，控制访问，并尊重同意。
原因: 此原则涵盖数据保密性和保护；公平性和包容性则关乎系统服务于谁。
解决方案应赋能并吸引所有人，无论其能力或背景如何。
应用包容性：设计时应使所有人受益，包括残障人士。
原因: 包容性关乎广泛的可访问性和覆盖范围；公平性则特指无偏见的结果。
用户必须了解 AI 系统如何做出决策及其局限性。
应用透明度：解释系统的工作原理、目的、功能和局限性。
原因: 透明度使系统易于理解；问责制则关乎谁应对其负责。
需要明确的所有权和治理，以便有人对 AI 系统的行为负责。
应用问责制：人们在治理框架内设计、构建和操作，并承担责任。
原因: 问责制明确了人类的责任；透明度只解释系统，不赋予所有权。
解释生成式 AI 模型如何根据 prompt 生成连贯的段落。
大型语言模型利用从海量训练文本中学习到的模式，重复预测下一个 token。
原因: Generative models 通过概率 token 预测生成新内容；它们不会逐字检索存储的答案。
选择模型：一个需要经济高效且处理大量聊天的模型，另一个则需要复杂的多步骤推理能力。
根据任务匹配模型 — 较小/更快的模型用于常规聊天，较大的推理模型用于复杂任务。
原因: 越大并非总是越好；能力、成本和延迟需要权衡，因此应根据工作负载需求进行选择。
决定如何使用模型：托管标准 endpoint vs. 专用容量。
对于可变负载，使用标准（按使用量付费）部署；对于稳定大容量、可预测的性能，则使用预置吞吐量。
原因: 预置容量可确保一致的延迟；标准部署按 token 计费，并且最容易上手。
输出过于重复；您需要更有创意、更多样化的响应。
提高 temperature 参数；将其降低到接近 0 可获得确定性、专注的输出。
原因: Temperature 控制 token 选择的随机性；高 = 有创意，低 = 一致。
响应在句中被截断，或者您需要限制输出长度和成本。
调整 max tokens（最大完成长度）参数以设置响应上限。
原因: Max tokens 限制输出长度；它不会改变创造力 — 那是 temperature 或 top-p 的作用。
您希望将 token 选择限制在最可能的一组，而无需严格的 temperature 控制。
使用 top-p (nucleus sampling) 将采样限制在概率之和为 p 的最小 token 集合。
原因: Top-p 通过概率质量缩小候选池；调整它或 temperature，通常不要同时积极调整两者。
工作负载必须根据 prompt 起草营销文案和摘要。
这是一个 generative AI 工作负载 — 从自然语言指令创建内容。
原因: Generative workloads 产生新内容；文本分析仅从现有文本中提取见解。
系统必须在最少监督下规划步骤、调用工具并朝着目标行动。
这是一个 agentic AI 工作负载 — 由 LLM 驱动的 agent，能够推理、使用工具并采取行动。
原因: Agentic 在生成的基础上增加了自主性和工具使用；纯粹的 generative AI 仅返回内容。
工作负载从客户评论中挖掘 sentiment、key phrases 和 named entities。
这是一个文本分析 (NLP) 工作负载。
原因: 文本分析解释现有文本；它不像 generative workload 那样生成新散文。
工作负载必须转录通话内容并朗读响应。
这是一个 speech 工作负载 — speech-to-text recognition 和 text-to-speech synthesis。
原因: Speech 涵盖音频输入/输出；computer vision 处理图像，而非音频。
工作负载必须检测物体并从照片中读取文本。
这是一个 computer vision 工作负载 — 图像分类、物体检测和 OCR。
原因: Computer vision 解释图像；从文档中提取信息是相关但不同的任务。
工作负载必须从扫描发票中提取日期、总计和供应商等字段。
这是一个信息/数据提取工作负载（document understanding）。
原因: 提取从文档中拉取结构化字段；通用 OCR 仅返回原始文本，而非带标签的字段。
您需要从一段文本中获取主要主题，而无需全部阅读。
使用 key phrase (keyword) extraction 来呈现最重要的术语。
原因: Key phrase extraction 列出显著术语；entity detection 则分类命名实体，如人或地点。
您必须识别文本中提及的人物、组织、地点和日期。
使用 named entity recognition (entity detection) 对这些实体进行分类。
原因: Entity detection 标记命名实体；sentiment analysis 则评估情感语调。
您想知道评论是正面的、负面的还是中性的。
使用 sentiment analysis 来评估文本中表达的观点。
原因: Sentiment 衡量语调；summarization 浓缩内容，它不判断极性。
您需要一份长报告的简短摘要。
使用 text summarization（extractive 或 abstractive）来浓缩文档。
原因: Summarization 在保留意义的同时缩短内容；key phrase extraction 仅列出术语，而非可读的摘要。
区分将音频转换为文本和将文本转换为音频。
Speech recognition (speech-to-text) 转录音频；speech synthesis (text-to-speech) 生成语音音频。
原因: Recognition 是输入音频→文本；synthesis 则相反 — 不要混淆这两个方向。
您需要一个单一平台来发现模型、部署模型并在 Azure 上构建 AI 应用。
使用 Microsoft Foundry portal — 它托管模型目录、部署、playground 和 agent 工具。
原因: Foundry 是统一的中心；虽然存在独立的 Azure AI 服务，但 Foundry 是您编写和部署解决方案的地方。
您希望模型始终以礼貌的客服 agent 身份回答，无论提出的问题是什么。
在 system prompt 中设置行为和 persona；将具体问题放入 user prompt。
原因: system prompt 设定整体行为和规则；user prompt 是每一轮的请求。
您在目录中选择了一个模型，需要使其可从应用中调用。
在 Foundry portal 中为模型创建部署，这将提供一个 endpoint 和密钥。
原因: 目录中的模型在部署之前无法使用；部署会公开可调用的 endpoint。
您想在编写任何代码之前测试 prompt 并调整 temperature。
使用 Foundry portal 中的 chat playground 与部署的模型交互并调整参数。
原因: playground 允许您交互式地迭代 prompt 和设置；无需 SDK 即可进行实验。
您需要从应用程序代码中调用已部署的聊天模型。
使用 Foundry (Azure AI) SDK 创建一个聊天客户端，向部署 endpoint 发送消息。
原因: SDK 使用类型化客户端封装 endpoint；您传递 system 和 user 消息并读取完成内容。
您的应用必须对部署的模型进行身份验证。
使用部署的 endpoint URL 和 API 密钥或 Microsoft Entra ID (Azure AD) 凭据。
原因: 基于密钥的身份验证最简单；Entra ID 更安全，并避免在代码中嵌入秘密。
您想要一个遵循指令并使用工具的 AI 助手，且无需大量代码即可构建。
在 Foundry portal 中创建单个 agent — 定义其指令、模型和工具（Agent Service）。
原因: portal agent builder 声明性地配置行为和工具；您无需手动编写编排循环。
您的 agent 应始终引用来源并拒绝离题请求。
将这些规则编码到 agent 的指令中（其系统级指导）。
原因: Agent 指令在不同轮次中引导一致行为，类似于普通聊天模型的 system prompt。
您的 agent 必须从公司文档而非仅其训练数据中获取答案。
为 agent 提供知识/grounding 工具（例如，文件搜索或 Azure AI Search），以便它检索您的数据。
原因: Grounding/RAG 提供当前、私有的上下文；没有它，模型可能会产生幻觉或使用过时知识。
您需要一个自定义应用来编程驱动 Foundry agent。
使用 Foundry SDK 构建 agent 客户端应用 — 创建一个 thread，添加消息，运行 agent，读取响应。
原因: SDK 暴露 threads、runs 和 messages，因此您的应用可以将 agent 集成到任何工作流中。
您必须构建一个从传入文本中提取 sentiment 和 entities 的应用。
通过 Foundry 访问，使用 SDK 或 REST 调用 Azure AI Language (text analysis) 的 sentiment 和 NER 功能。
原因: 对于经典 NLP 任务，Language 服务是专门构建的，并且比 prompt 通用 LLM 更经济。
用户想要说出问题，并让已部署的模型回答。
将音频发送到接受语音输入的 multimodal 模型，或者先转录，然后 prompt 模型。
原因: Multimodal 模型可以直接接收音频；否则，使用 speech-to-text 来喂给文本模型。
您的应用需要高质量的转录和自然的语音输出。
在 Foundry Tools 中使用 Azure AI Speech 进行 speech-to-text 和 text-to-speech。
原因: Speech 服务提供经过优化的识别和逼真的 neural voices，超越了单独的聊天模型所能提供的功能。
您需要应用以自然的声音朗读响应。
使用 Azure AI Speech 的 text-to-speech 和 neural voice；如果需要，使用 SSML 控制韵律。
原因: Neural voices 听起来自然；SSML 允许您调整语速、音高和发音。
应用必须描述用户提供的照片中发生的事情并回答相关问题。
将图像发送到 Foundry 中的 multimodal 模型，并使用问题对其进行 prompt。
原因: Multimodal LLM 对图像内容进行推理；经典的 Vision 服务仅返回固定标签和标题。
应用必须按需从文本描述生成图像。
在 Foundry 中部署一个 text-to-image 模型（例如，DALL-E / image generation 模型），并从您的应用中调用它。
原因: Image generation 模型从 prompt 创建视觉内容；vision 模型仅分析现有图像。
您需要一个能够分类图像并从中读取印刷文本的应用。
通过 Foundry 访问，使用 Azure AI Vision（图像分析和 OCR）构建 vision 应用。
原因: Azure AI Vision 提供现成的图像分析和 OCR；您无需为常见任务训练模型。
应用必须从扫描页面中提取印刷体和手写文本。
使用 Azure AI Vision 的 OCR (Read) 功能来返回识别的文本及其位置。
原因: OCR 返回带坐标的原始文本；结构化字段提取需要 Content Understanding。
您必须从发票和表格中提取结构化字段（总计、日期、明细）。
在 Foundry Tools 中使用 Azure AI Content Understanding 从文档和表格中提取结构化数据。
原因: Content Understanding 提取带标签的字段；普通的 OCR 只返回非结构化文本。
您需要从一批图像中提取结构化描述和 metadata。
使用 Azure AI Content Understanding 分析图像并返回结构化输出。
原因: Content Understanding 针对不同内容类型生成一致的结构化结果，超越了自由文本标题。
您必须将通话录音转换为包含关键数据点的结构化摘要。
对音频使用 Azure AI Content Understanding 进行转录和提取结构化字段。
原因: Content Understanding 将转录与提取相结合；单独的 Speech 只提供转录文本。
您需要从训练视频中提取场景、主题和关键字段。
使用 Azure AI Content Understanding for video 来跨模态提取结构化见解。
原因: 它同时分析音频和视觉流以生成结构化输出，而不仅仅是转录文本。
您必须以最小的代价将您公司的私有 FAQ 知识添加到模型答案中。
通过对您的文档进行检索 (RAG) 来 grounding 模型，而不是 fine-tuning。
原因: RAG 在查询时注入当前数据，更简单/更便宜；fine-tuning 改变行为，而非知识的新鲜度。
您必须阻止已部署模型输出有害或不安全的文本和图像。
在部署上启用 Azure AI Content Safety 过滤器，以检测和阻止有害内容。
原因: Content Safety 在运行时强制执行负责任 AI 的防护措施；仅基础模型无法保证安全。
部署后，您需要衡量响应质量并监控漂移。
使用 Foundry evaluation 和 monitoring 工具来评估输出并跟踪随时间变化的指标。
原因: Evaluation 量化质量（groundedness、相关性）；monitoring 捕获生产中的回归。
您需要为单个应用程序组织模型、agent 和连接。
创建一个 Foundry project，它将该解决方案的部署、连接资源和工具分组。
原因: 一个 project 是工作区边界；connections 连接外部资源，如 Azure AI Search 或存储。