一个聊天功能以高吞吐量运行，对话简短、简单，且延迟和成本预算紧张。
从 Foundry 模型目录部署小型语言模型 (SLM)，例如 Phi，而不是前沿 LLM。
原因: SLM 降低了狭窄任务的成本和延迟；将大型 LLM 保留给复杂推理。根据任务而非品牌匹配模型大小。
最后审核：2026年6月
AI-103 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。
一个聊天功能以高吞吐量运行，对话简短、简单，且延迟和成本预算紧张。
从 Foundry 模型目录部署小型语言模型 (SLM)，例如 Phi，而不是前沿 LLM。
原因: SLM 降低了狭窄任务的成本和延迟；将大型 LLM 保留给复杂推理。根据任务而非品牌匹配模型大小。
一个 agent 必须在一个请求中对用户上传的图像和文本进行推理。
在 Foundry 目录中选择多模态模型（例如 GPT-4o 系列），而不是将视觉模型链式连接到仅文本的 LLM。
原因: 原生多模态模型在一个 prompt 中接受图像和文本；仅文本模型强制进行有损的字幕交接，从而丢失视觉细节。
答案必须以私有企业知识库为基础，而不是模型的预训练。
构建检索层：在 Azure AI Search 中使用 vector embedding 索引语料库，并通过 RAG 在该索引上对模型进行 grounding。
原因: Grounding 在推理时注入检索到的、可引用的上下文；微调会静态地烘焙知识，并且不能廉价地引用或更新。
一个 agent 需要调用内部 REST API 并从索引文档存储中检索。
将 API 注册为 agent tool（function/OpenAPI），并将 AI Search 索引作为知识源附加到 Foundry agent。
原因: Tool 赋予 agent 行动能力；知识源提供 grounded 检索。它们是不同的集成界面，而不是相同的连接器。
多个团队需要在共享治理下实现独立的 agent 配置、连接和部署。
使用 Foundry hub 和每个团队的 Foundry project；每个 project 都有自己的连接、部署和访问范围。
原因: hub 集中了网络、策略和共享资源；project 是应用程序或团队的工作区单元。不要在团队之间共享一个 project。
生产应用程序需要可预测的数据驻留和模型部署的预留吞吐量。
对于对驻留敏感、高吞吐量的工作负载，使用标准（区域）或预配吞吐量 (PTU) 部署，而不是全球部署。
原因: 全球部署会路由到任何区域以获取容量；标准部署固定区域，PTU 预留容量以实现稳定的延迟。根据驻留和 SLA 需求进行选择。
Prompt 和 agent 定义必须通过审查和回滚从开发环境迁移到生产环境。
将 prompt flow/agent 定义作为代码存储在 repo 中，并通过 Azure DevOps 或 GitHub Actions 管道在环境中推广。
原因: 将 prompt 和 agent 配置视为版本化 artifact；生产环境中的手动 portal 编辑没有审计跟踪或回滚路径。
流量突增导致模型部署触发 429 错误。
在可用时提高部署的 TPM/RPM 配额，添加客户端重试并采用指数退避策略，并考虑使用 PTU 部署以保证容量。
原因: 配额是每分钟 token 数的上限；退避可平滑瞬态节流。在没有配额规划的情况下启动重复资源只会转移瓶颈。
支出不可预测，且主要由长 RAG prompt 决定。
限制最大输出 token 数，将检索到的上下文修剪为 top-k，缓存可重用系统上下文，并在 Azure Monitor 中跟踪每个部署的 token 使用情况。
原因: 成本随着输入和输出 token 数的增加而增加；缩小上下文和输出是直接的杠杆。切换区域或 SKU 很少能显著改变每个 token 的价格。
数周内，生产环境中的答案质量和 grounding 准确性似乎有所下降。
在 Foundry 中对采样的实时流量运行持续的在线评估，以评估 groundedness、相关性和连贯性，并在分数下降时发出警报。
原因: 计划的评估器会检测到您在原始延迟指标中看不到的漂移；仅 CPU/延迟仪表板无法揭示 grounding 退化。
RAG 答案过时，因为新文档未被检索。
监控 AI Search indexer 运行历史和文档计数；安排增量索引并在 indexer 运行失败时发出警报。
原因: 当 indexer 失败或滞后时，检索质量会悄然中断；模型侧指标看起来正常，因为问题出在数据管道中。
应用程序必须调用 Foundry 模型部署，且配置中没有 secrets。
在应用程序上启用 managed identity，并授予其“Cognitive Services OpenAI User”角色；使用 Entra ID token 而不是 API 密钥进行身份验证。
原因: 无密钥的 Entra 身份验证消除了可泄露的 secrets 并集中了 RBAC；即使在 Key Vault 中存储 API 密钥，仍然留下一个需要轮换和保护的密钥。
Foundry 流量绝不能遍历公共互联网。
将 Foundry 资源和依赖项置于 private endpoint 之后，禁用公共网络访问，并通过私有 DNS 区域解析。
原因: Private endpoint 将流量固定到 VNet；防火墙 IP 允许列表仍通过公共 endpoint 路由，并且隔离性较弱。
生成的响应偶尔包含仇恨或暴力内容。
在部署上应用 Azure AI Content Safety 过滤器，并为仇恨、性、暴力和自残类别设置适当的严重性阈值。
原因: 内容过滤器在服务器端筛选 prompt 和完成内容；仅依赖系统 prompt 指令很容易被 jailbreaks 绕过。
自主 agent 可以执行不可逆转的操作，例如发放退款。
为高影响工具配置人工审批关口，并将 agent 限制在允许的操作集合中。
原因: 审批模式和 tool 访问限制了自主性；不受约束的自主 agent 在执行破坏性 tool 调用时没有制动。
审计员需要查看哪些来源和 tool 调用产生了给定答案。
在 Foundry 中启用 tracing (OpenTelemetry) 以捕获每个请求的 prompt、检索到的引用、tool 调用和输出。
原因: 端到端跟踪提供来源和可重现性；聚合 token 指标本身无法重建单个答案的推理链。
后端服务必须调用 Foundry project 中定义的模型和 agent。
使用 Azure AI Foundry SDK (AIProjectClient) 以及 project 连接字符串和 DefaultAzureCredential 来获取模型和 agent 客户端。
原因: project 客户端集中解析连接和部署；硬编码每个模型的 endpoint 和密钥会绕过 project 治理。
构建一个基于策略文档的问答应用程序。
嵌入并索引文档，每个查询检索 top-k 块，并将它们作为上下文传递给聊天完成，并附带引用来源的指令。
原因: RAG 无需重新训练即可保持知识的最新性和可引用性；将整个语料库传递到 prompt 会超出上下文窗口并增加成本。
模型必须在对话期间查找实时订单状态。
定义一个带有 JSON schema 的 tool，让模型发出 tool 调用，在服务器端执行它，然后返回结果供模型总结。
原因: Function/tool calling 让模型能够确定性地调用真实系统；让它“猜测”状态会产生虚假信息。
一个任务在最终回答之前需要多次依赖的 tool 调用。
运行 tool-use 循环：将每个 tool 结果反馈给模型，并迭代直到它返回最终消息，并设置最大迭代次数限制。
原因: 迭代 tool 循环支持多步骤推理；单次往返无法链式连接依赖查找，无限制循环可能失控。
在发布之前，量化 RAG 应用程序出现幻觉或偏离主题的频率。
在标记的测试集上运行 Foundry 评估器以评估 groundedness、相关性和连贯性，并根据阈值分数决定发布。
原因: 内置评估器提供可衡量的质量和安全信号；仅仅凭肉眼查看少量样本无法发现系统性的虚假信息。
定义一个具有清晰角色、目标和界限的支持 agent。
设置 agent 的系统指令（角色、目标、拒绝规则），并仅附加其范围所需的 tool。
原因: 严格的指令加上最少 tool 访问权限使 agent 专注于任务；宽泛的指令和所有 tool 会导致范围蔓延和不安全的操作。
一个 agent 必须在会话中的多个轮次中记住上下文。
使用 Foundry Agent Service 线程，它为每个对话持久化消息历史记录，以便每次运行都能看到之前的轮次。
原因: 线程提供 managed 对话内存；每次调用手动重新发送整个 transcript 既脆弱又容易错误截断。
一个 agent 需要 web grounding 和代码执行，而无需自定义管道。
附加内置的 Foundry agent tool，例如 Grounding with Bing Search 和 Code Interpreter，而不是手动编写集成。
原因: Managed tool 开箱即用，受治理和支持；自定义重新实现会增加维护成本并跳过平台安全控制。
主 agent 应将计费问题委托给专业的计费 agent。
使用 connected agent：将计费 agent 暴露为主要 agent 可以调用的 tool，这样它就可以将子任务路由给专家。
原因: Connected agent 实现了分层委托；将每个领域都塞进一个 mega-agent 会使指令臃肿并降低准确性。
一个工作流需要一个 planner、一个 researcher 和一个 writer 协作并共享状态。
使用 multi-agent 框架（Foundry 上的 Semantic Kernel / AutoGen）通过定义的编排模式和共享上下文进行编排。
原因: 框架管理轮流、状态和终止；agent 之间临时传递字符串没有协调或停止条件。
一个 agent 在夜间无人值守运行，并且不能单独执行有风险的操作。
通过允许的 tool、每次操作的预算、内容过滤器以及在需要审批时升级高影响步骤的检查点来限制它。
原因: 分层 safeguards 保持自主性安全；一个拥有完整 tool 访问权限且没有审批关口的自主循环可能会造成不可逆转的损害。
一个 agent 在任务中途间歇性失败，您必须找到失败的步骤。
在 Foundry 中检查运行的 traced 步骤和 tool 调用输入/输出，以定位失败的 tool 或格式错误的参数。
原因: 步骤级跟踪可精确定位运行中断的位置；单个最终错误消息隐藏了实际失败的 tool 调用或推理步骤。
输出不一致且忽略格式指令。
使用清晰的系统消息、few-shot 示例和明确的输出约束；对于严格的形状，启用 structured outputs/JSON schema。
原因: 结构化 prompting 和 schema 强制输出使结果可靠；盲目提高 temperature 或重试无法解决指令遵循问题。
创意文案任务感觉过于重复；数据提取任务过于随机。
提高创意任务的 temperature/top-p，并将其降低至接近 0 以使提取任务具有确定性。
原因: 采样参数在多样性和确定性之间进行权衡；当参数设置是真正原因时，切换模型是过度杀伤。
一个推理 agent 在困难任务上会犯可避免的逻辑错误。
添加 reflection/self-critique 步骤，让 agent 审查和修改其草稿，或在该步骤中使用推理模型。
原因: Chain-of-thought 和 self-critique 提高了困难任务的准确性；单个前向传播没有机会发现自己的错误。
运营部门需要在生产环境中每个请求的 token 支出、延迟和安全信号。
从应用程序向 Azure Monitor/Application Insights 发送 OpenTelemetry 跟踪和指标，捕获 token、延迟和内容安全标志。
原因: 统一的可观测性将成本、性能和安全性联系在一起；手动抓取日志无法将缓慢的轮次与其 token 使用情况关联起来。
一个应用程序混合了廉价分类和偶尔的复杂推理。
编排多个部署：将简单轮次路由到 SLM，并将困难轮次通过一个应用程序层升级到前沿 LLM。
原因: 模型路由优化了每个轮次的成本和质量；对所有事情都使用一个 premium 模型会为简单的多数情况支付过高的费用。
营销应用程序必须从文本 prompt 生成原始图像。
部署图像生成模型（例如 Foundry 目录中的 DALL-E/GPT-image），并使用文本 prompt 和大小参数调用它。
原因: 生成式图像模型合成新的视觉效果；图像分析 (vision) API 仅描述现有图像，无法创建它们。
仅替换现有产品照片的背景，保持产品完整。
使用图像编辑 (inpainting) endpoint，提供源图像以及仅标记可编辑区域的 mask。
原因: mask 将编辑范围限定在绘制区域；普通的 text-to-image 调用会重新生成整个帧并丢失原始产品。
根据文本描述生成短视频片段。
使用 Foundry 目录中的 text-to-video 模型（例如 Sora），并提供 prompt、时长和分辨率参数。
原因: 视频生成是独特的模型系列；图像模型输出单帧，无法产生时间运动。
用户就上传的图表图像提出自由形式的问题。
将图像和问题发送到多模态 LLM (GPT-4o) 进行视觉问答并获得自然语言答案。
原因: 多模态聊天处理开放式视觉问答；固定分类法图像标记返回标签，而不是对任意问题的答案。
为数千张图像自动生成描述性 alt text 以提高可访问性。
使用 Image Analysis caption/dense-captions 功能大规模生成人类可读的描述。
原因: 字幕直接生成简洁的 alt text；目标检测返回的 bounding box 仍需要转换为散文。
从长时间录制的视频中提取结构化字段和片段级洞察。
使用 Azure AI Content Understanding 和视频分析器，以获取跨时间线的结构化、schema 定义的输出。
原因: Content Understanding 生成跨模态的 grounded 结构化输出；逐帧图像调用无法提供时间线感知的结构。
多模态 agent 读取用户图像，其中可能包含隐藏的指令文本。
启用 prompt shields/间接注入检测，并将图像内的文本视为不受信任的数据，而不是指令。
原因: 嵌入图像文本是经典的间接 prompt injection 向量；将 OCR 的文本直接传递到系统 prompt 会让攻击者劫持 agent。
将电子邮件中的姓名、日期和金额提取到类型化的 JSON 记录中。
使用目标 JSON schema 提示 LLM，并启用 structured outputs，以便每个字段都以固定形状返回。
原因: schema 约束的 LLM 提取处理开放格式并保证可解析的 JSON；脆弱的 regex 会在自然语言多样性上失效。
生成长支持 transcript 的简洁、重写摘要。
使用 LLM 进行抽象 summarization，并带有长度和焦点指令，或使用 Language 服务 summarization 技能。
原因: 抽象摘要概括了要点；提取式句子选择只是复制句子，可能会错过整体要点。
按 sentiment 对客户消息进行分类并标记激进语气。
使用 LLM（或 Language sentiment API）标记极性并检测语气，返回类别和置信度。
原因: Sentiment/tone 分析是具有明确标签的分类任务；没有标签 schema 的自由文本生成很难在下游进行路由。
以准确且低成本的方式将大量 UI 字符串翻译成 30 种语言。
使用 Azure AI Translator 进行批量、确定性翻译；为细致、上下文丰富的段落保留 LLM。
原因: Translator 是专用的，成本更低，并且在大规模应用中保持一致；每个字符串使用 LLM 会花费更多，并且在不同运行中语气可能会漂移。
语音 agent 必须实时转录呼叫者音频。
使用 Speech service 实时 speech-to-text（或快速转录）将文本输入 agent 管道。
原因: 流式 STT 为实时对话提供低延迟的部分 transcript；批量转录用于离线文件，而不是实时轮次。
转录错误地识别了产品名称和医学术语。
使用领域音频和短语列表训练 Custom Speech 模型，以提高对专业词汇的识别。
原因: Custom Speech 使声学/语言模型适应您的术语；基础模型没有接触过您的私有术语。
agent 必须用听起来自然的语音音频回复。
使用带有适当声音和 SSML 的 neural Text to Speech 来控制韵律、停顿和发音。
原因: Neural TTS 加上 SSML 产生逼真、可控的语音；没有 SSML 的纯文本在数字和名称上会产生平淡的措辞。
仅 vector 检索会错过精确的关键字和代码标识符匹配。
在 Azure AI Search 中使用混合搜索（vector 加关键字）和 semantic ranking 来重新排序合并结果。
原因: 混合搜索加 semantic reranking 优于任何单一信号；纯 vector search 可能会错过文字术语，纯关键字搜索会错过释义。
语料库包含文本不可选的扫描 PDF。
在索引技能集中添加 OCR 认知技能（Document Intelligence/Vision），以便在分块和 embedding 之前提取扫描文本。
原因: OCR 增强从图像中提取文本以供检索；索引原始扫描 PDF 不会产生任何可搜索的内容。
在 ingestion 期间，您需要对每个文档应用 OCR、关键短语提取和翻译。
定义一个 AI Search skillset，链式连接所需的认知技能，将输出投影到 indexer 填充的索引字段中。
原因: skillset 在索引时声明性地编排增强；在应用程序代码中按查询进行会重复工作并破坏重用。
您希望在索引管道内部处理分块和 embedding，而不是在应用程序代码中。
使用 AI Search integrated vectorization 在索引时和查询时分割文档并调用 embedding 模型。
原因: 集成 vectorization 在 ingest 和查询之间保持分块/embedding 的一致性；自定义客户端 embedding 存在模型不匹配的风险。
从布局多样的发票中提取结构化字段。
使用 Document Intelligence 预构建的发票模型，或训练自定义模型，以返回带有置信度和 bounding region 的类型化字段。
原因: Document Intelligence 理解布局并返回类型化字段；仅 OCR 的 dump 提供原始文本，没有字段语义。
您需要用于 RAG 的混合文档的干净、grounded 的 markdown 表示。
使用 Content Understanding 分析器生成结构化/markdown 输出，该输出保留标题、表格和字段 grounding。
原因: Grounded markdown 为检索保留结构和引用；扁平化的纯文本会丢失模型所需的表格和 section 上下文。
Foundry agent 必须在运行时从您丰富的搜索索引中检索。
将 AI Search 索引添加为 agent 上的知识源/tool，以便每次运行都以检索到的、引用的结果为基础。
原因: 将索引作为 agent tool 连接提供实时 grounded 检索；将静态片段粘贴到指令中无法与语料库保持同步。