1. 课程导入与全景认知

在把一个大语言模型接入业务之前，很多团队会先遇到一个认知落差：在本地用几行代码调用模型接口，和把同一套能力稳定地交付给成百上千名用户，是两件完全不同的事。前者关注“模型能不能答对”，后者关注“请求能不能被接住、成本能不能被控制、回答能不能被追溯、故障能不能被隔离”。本课程讨论的正是后者——以 Azure 为底座，构建一个可上生产的生成式 AI 应用平台。

先建立全景。一个典型的 Azure 生成式 AI 应用平台，可以拆成六个层次。最底层是模型与推理层，由 Azure OpenAI 提供 GPT 系列对话模型、嵌入模型，以及可选的微调与批处理能力；模型部署以“部署名”暴露，应用只认部署名，不直接绑定底层模型版本，这是后续做灰度与切换的关键。往上是数据与检索层，包括 Azure AI Search 的向量与混合检索、Blob Storage 中的原始文档、以及文档切分与嵌入的索引流水线。第三层是编排层，负责提示词组装、检索结果注入、工具调用与多轮状态管理，可以用 Prompt Flow、Semantic Kernel 或自研编排代码实现。第四层是应用服务层，承载 API 与前端，通常落在 Azure Container Apps 或 AKS 上。第五层是平台治理层，涵盖托管标识、Key Vault 密钥管理、内容安全过滤、配额与限流。最上层是可观测与运营层，用 Application Insights 采集延迟、Token 消耗、检索命中率与失败率。

这张分层图有一个重要含义：越靠上的层，越决定生产可用性；越靠下的层，越决定能力上限。很多项目失败不是因为模型不够强，而是因为治理层和可观测层缺位，导致上线后无法定位问题、无法控制成本、无法通过安全评审。

生产部署真正难在哪里

把生成式 AI 应用推上生产，挑战集中在四个方面，它们彼此耦合，不能单独解决。

第一，非确定性带来的质量波动。同一个问题，模型两次回答可能不同。这意味着传统“断言输出等于某值”的测试方法失效。实践中需要把评测拆成两层：离线用一组固定问题集做回归，观察答案是否覆盖关键事实、是否引用正确来源；在线用抽样人工评审加自动指标（如引用命中率、拒答率）持续监控。示例性地，可以准备 50 条覆盖高频业务问题与边界问题的评测集，每次提示词或模型版本变更后重跑，记录通过率变化，而不是只看单次回答“感觉不错”。

第二，延迟与吞吐的权衡。一次带检索的问答，链路是“嵌入查询 → 向量检索 → 组装提示词 → 模型生成”。假设嵌入耗时 80ms、检索 120ms、模型首 Token 600ms、生成 900ms，端到端约 1.7 秒。若把检索条数从 5 条增加到 20 条，检索耗时可能升到 300ms，同时提示词变长使生成阶段 Token 增加，总延迟可能突破 2.5 秒。因此检索条数、切分粒度、模型选择都是需要实测调优的参数，而不是拍脑袋设定。

第三，成本随用量非线性增长。成本主要由输入 Token、输出 Token 和检索调用构成。一个容易被忽视的点是：把整篇文档塞进提示词，输入 Token 会迅速膨胀。用检索只注入相关片段，通常能把输入 Token 降低一个数量级。生产上应设置每请求 Token 上限、按用户或租户的配额，并对异常高的消耗告警。

第四，安全与合规。包括密钥不落代码、模型访问走托管标识、用户输入与模型输出都经过内容安全过滤、敏感数据不进入日志。这些不是上线前补的检查项，而是从第一天就要设计进架构的约束。

学习路径与本节定位

本课程按“先建底座、再通链路、后上生产”的顺序展开。前期聚焦 Azure OpenAI 部署、身份与密钥管理、AI Search 索引构建，把模型与数据两层打通；中期进入编排与应用服务，完成检索增强问答、工具调用、多轮会话的端到端实现；后期处理生产化议题，包括评测体系、可观测性、限流降级、成本优化与灰度发布。每一章都会给出可操作的配置、参数或代码片段，并说明结果如何观察与判断。