手册

为 AI 服务自动化 API 密钥轮换，且不造成应用程序停机。

→在 Azure Key Vault 中存储主密钥和辅助密钥，并进行自动轮换。将应用程序配置为，如果主密钥失败，则尝试使用辅助密钥。

原因: Key Vault 管理轮换生命周期。双密钥模式可确保在轮换窗口期间始终有一个密钥有效。

确保 AI 服务流量永不离开 VNet，并且 Microsoft 不会将客户数据用于服务改进。

→通过专用终结点部署 AI 服务并禁用公共网络访问。另外，在资源上启用数据处理选择退出设置。

原因: 专用终结点提供网络隔离。数据选择退出是数据隐私的一项独立设置。两者并非互为条件。

为 Azure Kubernetes Service (AKS) 中的应用程序提供对 AI 服务的安全、免凭据访问。

→将用户分配的托管标识分配给 AKS Pod。授予此标识在 AI 服务资源上的“Cognitive Services User”RBAC 角色。

原因: 托管标识是 Azure 资源的无密码身份验证标准模式，无需在 Pod 配置中存储机密。

参考↗

跟踪 AI 服务成本并按部门强制执行支出限制，而无需使用单独的订阅。

→为每个部门创建单独的 AI 服务资源。为每个资源应用“department”资源标记。根据标记值配置 Azure 成本管理预算并设置警报阈值。

原因: 标记是成本分配的标准。Azure 预算可作用于标记，通过警报或操作强制执行支出限制。

当 AI 服务 API 错误率超过 5% 或延迟超过 2 秒时，向运维人员发出警报。

→在 AI 服务资源上配置 Azure Monitor 指标警报。使用“Failed Requests”和“Latency”指标并设置适当的聚合周期。

原因: Azure Monitor 提供直接的平台级指标，用于性能和可靠性监控，可实现实时警报而无需日志查询延迟。

为自定义 AI 模型（例如 Custom Vision、LUIS）设计一个具有低 RTO/RPO 的灾难恢复计划。

→在配对区域部署资源。自动化每日模型导出到异地冗余存储 (GRS)。使用 Azure Traffic Manager 进行基于运行状况探测的自动故障转移。

原因: AI PaaS 服务不受 Azure Site Recovery 保护。灾难恢复需要显式、脚本化的模型导出/导入以及 DNS 级别的流量路由服务。

为所有 AI 服务调用记录完整的请求和响应有效负载，以进行长期审计保留。

→在 AI 服务前放置 Azure API Management (APIM)。配置 APIM 策略以记录完整的请求/响应正文。将日志发送到具有不变性策略的 Azure 存储。

原因: 原生 AI 服务诊断不记录完整的有效负载。APIM 是日志记录和策略外观的标准模式。不可变存储确保审计跟踪的完整性。

部署一个处理患者数据且必须符合 HIPAA 的医疗保健 AI 解决方案。

→在支持 HIPAA 的美国 Azure 区域部署 AI 资源。为订阅与 Microsoft 签署业务伙伴协议 (BAA)。

原因: HIPAA 合规性需要技术控制（区域选择）和法律协议 (BAA)。两者都是强制性的。

实施一个内容审核系统，标记有害内容，但在阻止前允许人工审核。

→使用 Azure AI 内容安全 API。自动阻止标记为“高”严重性的内容。将标记为“中”或“低”严重性的内容排队进行人工审核工作流。

原因: 这种人机协作模式平衡了自动化安全与审核所需的细微差别，防止过度阻止合法内容。

检测和统计零售货架上的特定品牌产品，同时处理遮挡和不同方向的情况。

→训练 Custom Vision 对象检测模型。使用在真实货架环境中代表产品的已标记图像数据集。

原因: 对象检测提供分类和位置（用于计数）。识别特定产品 SKU 需要自定义模型。

参考↗

在互联网连接不可靠的工厂中执行实时质量控制图像分析。

→将用于图像分析的 Azure AI Vision 容器部署到边缘设备（例如 Azure IoT Edge）。

原因: 容器将云 AI 模型打包用于本地执行，提供低延迟和离线能力，同时在连接时仍允许模型更新。

从包含混合印刷体、手写文本和多种语言的扫描历史文档中提取文本。

→使用 Azure AI Vision Read API（图像分析的一部分）。指定最新的模型版本以确保在混合内容上获得最佳性能。

原因: Read API 是 Azure 最先进的 OCR 引擎，专门针对以文档为中心、混合内容的场景进行了优化，性能优于旧版 OCR API。

分析视频流以监控商店占用率、跟踪顾客移动模式并测量排队长度。

→将 Azure AI Vision 空间分析容器部署到连接到商店摄像头的边缘设备。

原因: 空间分析是一种专用的容器化解决方案，用于从视频中进行实时空间分析，提供诸如 `personcount`、`persondistance` 和 `personcrossingline` 等操作。

一个 Custom Vision 对象检测模型具有高精度但召回率低（遗漏许多对象）。

→通过更多丢失对象的不同示例来扩充训练数据集，特别是具有不同光照、角度、大小和部分遮挡的图像。

原因: 低召回率是数据数量/多样性问题。模型没有见过足够的变化来有效泛化。添加多样化的示例是主要解决方案。

分析客户评论，以识别对特定产品功能的情绪（例如，对“电池续航”持积极态度，对“屏幕”持消极态度）。

→使用 Azure AI 语言情绪分析 API，并启用 `opinionMining` 参数。

原因: Opinion Mining（也称为基于方面的情绪分析）是专门用于提取文本中与单个目标（方面）相关联情绪的特定功能。

参考↗

创建一个支持多种语言，但使用单一英语知识库的 FAQ 机器人。

→使用 Azure AI 语言的自定义问题解答功能。它具有内置的查询翻译功能，可将问题与英语知识库进行匹配。

原因: 内置的翻译功能消除了为每种语言维护单独知识库的需要，大大简化了内容管理。

一个会话语言理解 (CLU) 模型混淆了两个相似的意图（例如，“OrderPizza”与“ModifyOrder”）。

→为这两个意图添加更多不同的训练语句，重点关注突出区分性关键词和短语的示例。检查并移除模糊或重叠的示例。

原因: 模型准确性主要由训练数据的质量和清晰度决定。目标是在意图之间创建清晰的“决策边界”。

从法律文档中提取领域特定实体，例如“ContractValue”或“TerminationClause”。

→使用 Azure AI 语言训练自定义命名实体识别 (NER) 模型。提供来自您的文档的已标记示例。

原因: 预构建的 NER 模型仅识别通用实体（人物、地点等）。任何领域特定实体提取任务都需要自定义 NER。

自动查找并从文本中编辑个人身份信息 (PII)，例如姓名和电话号码。

→使用 Azure AI 语言 PII 检测 API。配置要检测的实体类别并设置编辑模式。

原因: 这是一个专为 PII 设计的 API，比正则表达式或通用 NER 更可靠、更全面，适用于此特定的合规性任务。

从临床笔记中提取医学实体、关系和断言（例如，否定）。

→使用 Azure AI Health Insights，特别是用于医疗保健的文本分析服务。

原因: 这是一项专业的、符合 HIPAA 要求的服务，经过医学本体（例如 UMLS）训练，能够深入理解通用 NLP 模型所缺乏的临床文本。

翻译技术文档，确保行业特定术语和品牌名称翻译正确。

→使用 Azure 自定义翻译器。使用您现有已翻译文档（平行文档）语料库训练自定义模型。

原因: 自定义翻译器可适应您特定领域的词汇和风格，提供比通用翻译模型更高的保真度，通用翻译模型可能会误译专业术语。

实时转录多参与者会议并将文本归属于每个发言者。

→使用 Azure AI 语音转文本服务，并启用会话转录和说话人分离。

原因: 说话人分离是按说话人分割音频的特定功能，在转录的同时提供“谁说了什么”的信息。

提高包含领域特定首字母缩略词、术语或专有名词的音频的语音转文本准确性。

→训练自定义语音模型。提供包含匹配人工标记转录的音频样本数据集，以及自定义术语的发音文件。

原因: 自定义模型可根据您特定的音频环境、说话风格和词汇调整基础声学和语言模型，从而显著提高准确性。

控制电子学习模块中文本转语音旁白的强调、音高、语速和停顿。

→在文本转语音 API 请求中使用语音合成标记语言 (SSML)。

原因: SSML 是 W3C 标准，用于向语音合成器提供详细指令，实现超越纯文本输入的精细控制。

为 1000 万以上文档设计一个搜索解决方案，要求在高并发查询量下具有低延迟。

→在标准或更高层级使用 Azure AI Search。通过副本进行横向扩展以处理查询负载，通过分区处理数据量。

原因: 副本用于查询吞吐量 (QPS)。分区用于索引大小和 I/O。高规模、高性能场景都需要两者。

使用户能够提出自然语言问题（例如，“退货政策是什么？”），并从文档集合中获取直接答案。

→使用启用语义搜索的 Azure AI Search。利用语义答案和字幕功能。

原因: 语义搜索超越了关键词匹配，能够理解用户意图，并能从源文本中提取并返回直接、简洁的答案。

参考↗

实施产品搜索，该搜索可以查找型号（关键词）的精确匹配项和概念上相似的商品（语义）。

→配置一个 Azure AI Search 索引，使其同时包含可搜索的文本字段和向量字段。发出结合了关键词 (`search`) 和向量 (`vectorQueries`) 参数的混合查询。

原因: 混合搜索结合了 BM25 关键词排名的精确性与向量相似度的概念相关性，提供了两者的最佳效果。

在 Azure AI Search 索引管道中提取自定义格式的实体，例如产品代码 (XX-####)。

→创建一个调用 Azure Function 的自定义技能集。该函数包含用于查找和提取实体的正则表达式或其他自定义逻辑。

原因: 自定义技能为扩充管道提供了一个扩展点，用于处理内置认知技能未涵盖的任何逻辑。

确保搜索“laptop”、“notebook”和“ultrabook”都返回同一组相关文档。

→在 Azure AI Search 中创建一个同义词映射，定义等效术语。将同义词映射与索引定义中相关的可搜索字段关联。

原因: 同义词映射是用于扩展查询以包含用户定义的等效术语的专用功能，直接提高了搜索召回率。

更新 Azure AI Search 技能集时，仅重新处理受更改影响的文档，以节省时间和成本。

→在索引器配置中启用扩充缓存。然后，索引器将对未更改的技能使用缓存结果，并且仅重新运行新的或修改过的技能。

原因: 缓存中间技能输出是实现高效增量扩充的关键，可避免对整个数据集进行昂贵的完全重新处理。

编排一个管道，从各种文档（例如发票）中提取数据，根据业务规则验证数据，并存储结构化输出。

→在 Azure AI Document Intelligence 中使用复合模型进行提取，使用 Azure Function 进行自定义验证逻辑，使用 Azure Cosmos DB 进行存储。通过 Azure Logic Apps 进行编排。

原因: 这种无服务器架构正确地分离了关注点：Document Intelligence 用于专业提取，Functions 用于定制业务逻辑，Logic Apps 用于工作流编排。

在单个事务中处理包含多种表单类型（例如索赔表、收据和照片）的文档包。

→使用 Azure AI Document Intelligence 复合模型。训练一个分类模型来识别文档类型，并将其路由到适当的自定义或预构建提取模型。

原因: 复合模型充当路由器，允许单个终结点智能处理混合的文档类型，每种类型都由其最佳模型处理。

在 Azure AI Search 索引文档之前，对其进行 PII 编辑，以确保敏感数据永不存储在搜索索引中。

→将 PII 检测认知技能添加到索引器技能集。配置该技能以屏蔽 PII 并将编辑后的文本字段映射到索引。

原因: 这在索引期间执行“即时”编辑，确保可搜索内容从一开始就是干净的，这是一个关键的安全和合规模式。

根据文档的近期性（发布日期）和流行度（浏览量）提升搜索结果。

→在 Azure AI Search 中定义一个自定义评分配置文件。在日期字段上使用 `freshness` 函数，在浏览量字段上使用 `magnitude` 函数。

原因: 评分配置文件允许您通过结合来自文档元数据的业务特定信号来修改基本的 BM25 相关性分数。

Azure OpenAI 聊天机器人需要为客户服务场景提供一致、专注且非创造性的响应。

→将 `temperature` 参数设置为一个较低的值，例如 0.1 或 0.2。对于大多数模型，避免将其设置为精确的 0。

原因: Temperature 控制输出的随机性。降低它会使模型更具确定性，更有可能选择概率最高的 token。

在 RAG 解决方案中，确保生成模型仅从特定用户被允许访问的文档中合成答案。

→在检索阶段实施安全裁剪。在 Azure AI Search 中，根据用户的 AAD 身份和组成员资格，对搜索查询应用安全过滤器。

原因: 必须在 LLM 查看数据之前强制执行访问控制。在搜索（检索）层进行过滤是实现此目的唯一安全的方法。

使用 Azure OpenAI，始终如一地将非结构化文本中的结构化数据提取为有效的 JSON 对象。

→使用包含以下内容的提示：1) 清晰的角色。2) 明确指示只返回 JSON。3) 带有字段名称和类型的所需 JSON 架构。4) 如果可能，提供少量示例。

原因: 高度结构化和明确的提示显著提高了从 LLM 获取格式良好、结构化输出的可靠性。

关键任务应用程序需要 Azure OpenAI 提供有保障的、一致的吞吐量，在高峰负载期间无限制。

→使用预配吞吐量单元 (PTU) 购买和部署模型。

原因: PTU 提供专用、保留的模型处理容量，这与标准按使用量付费部署不同，后者在共享容量模型上运行并受节流限制。

参考↗

在长时间运行的聊天机器人对话中保持上下文，而不超出模型的 token 限制。

→实施对话摘要策略。定期使用单独的 LLM 调用来总结对话的旧部分，并将此摘要加上最近的回合包含在提示中。

原因: 这种“总结和滑动”模式比简单的截断或发送整个（最终过长）历史记录更有效、更经济地保留了长期上下文。

使 Azure OpenAI 模型能够调用外部 API 以获取当前天气信息。

→使用精确的 JSON 架构格式将 API 定义为模型的工具。包含清晰的函数 `description` 和详细的 `parameter` 描述，以便模型知道何时以及如何使用它。

原因: 模型完全依赖于架构和描述来做出调用函数的明智决策。一个描述良好的函数对于可靠性至关重要。

使用 Azure OpenAI 总结一个比模型上下文窗口长得多的文档。

→实施“map-reduce”或“refine”策略。将文档分块，为每个块生成摘要（map），然后从块摘要的集合中生成最终摘要（reduce）。

原因: 这是将固定上下文模型应用于任意长输入的标准模式，确保考虑整个文档内容。

通过在 AI 响应生成时即时显示，提高聊天应用程序的感知响应能力。

→调用聊天完成 API 时，将 `stream` 参数设置为 `true`。在服务器发送事件到达时对其进行处理，以逐个 token 构建响应。

原因: 流式传输为实时应用程序提供了比等待完整响应生成更好的用户体验，完整响应可能需要数秒。

AI 代理必须动态决定使用几种工具（例如，数据库查询、网络搜索、电子邮件发送器）中的哪一种来满足用户请求。

→使用 Semantic Kernel 或 Azure AI Agent Service 等框架。将每种功能定义为不同的工具/插件，并让代理的规划器或 ReAct 循环编排工具调用。

原因: 代理框架提供了编排层（规划器/推理循环），使 LLM 能够超越简单的问答，成为使用工具的自主代理。

防止自主 AI 代理在没有监督的情况下执行高风险操作（例如，删除数据、花费金钱）。

→实施人机协作模式。当代理计划高风险操作时，系统必须暂停并要求人工操作员明确确认后才能执行。

原因: 这是代理系统的一个关键的负责任 AI 模式，通过控制不可逆或高影响的操作，平衡了自主性和安全性。