3. 生成式AI应用架构设计

原型阶段的目标是“跑通”，生产阶段的目标是“跑稳、跑快、跑得起”。这两者之间的差距，往往不是模型能力，而是架构。一个典型的生成式AI应用，从用户输入到最终回答，中间要经过接入、编排、检索、模型推理、安全过滤、缓存、可观测等多个环节。如果把这些环节全部塞进一个函数里，原型能演示，生产必然失控。因此，本节的核心任务是：把生成式AI应用拆成清晰的分层架构，明确每层的关键组件，并给出Azure服务选型的判断依据。

一、分层架构：五层职责与边界

推荐将生成式AI应用划分为五层，自下而上依次为：基础设施层、模型服务层、编排与检索层、应用接入层、体验与治理层。分层的意义在于：每层只暴露有限接口，变更影响可控。例如，更换模型不应影响前端会话管理；调整检索策略不应改动API网关。

• 基础设施层：负责计算、网络、存储与密钥管理。生产环境通常使用Azure Kubernetes Service（AKS）或Azure Container Apps承载自研编排服务，使用Azure Key Vault管理模型密钥与连接字符串，使用Azure Monitor与Log Analytics收集日志和指标。
• 模型服务层：承载大语言模型与嵌入模型。Azure OpenAI Service提供GPT-4o、GPT-4o mini、text-embedding-3-large等模型，支持按Token计费、内容过滤、私有网络接入。对于需要完全控制权或离线推理的场景，可使用Azure Machine Learning托管开源模型。
• 编排与检索层：这是生成式AI应用区别于普通Web应用的核心层。编排负责提示词组装、对话历史管理、工具调用、多步推理；检索负责从知识库中召回相关片段。常用组件包括Prompt Flow、Semantic Kernel、LangChain，以及Azure AI Search作为向量与关键词混合检索后端。
• 应用接入层：负责认证、限流、路由、会话保持。Azure API Management是常见选择，可在网关层完成JWT校验、Token配额、语义缓存命中判断，避免无效请求打到模型服务。
• 体验与治理层：面向最终用户与运维人员，包括前端应用、反馈收集、内容安全、成本看板、评估流水线。Azure AI Content Safety用于拦截有害内容，Application Insights用于追踪端到端延迟与Token消耗。

下面用一张分层架构图展示各层组件及其调用方向。图中箭头表示请求与数据流向，自下而上为基础设施支撑，自上而下为业务请求路径。

二、关键组件选型：从需求到服务

选型不是“哪个服务最火就用哪个”，而是从约束出发。以下给出四个典型判断维度及对应Azure服务。

需要特别说明的是，Azure AI Search的向量检索并非“开箱即用”。生产环境通常需要同时配置HNSW索引参数（如m、efConstruction）和语义排序器。一个合理的起点是：m=4、efConstruction=400、efSearch=500，再根据召回率与延迟做调优。这些参数属于示例建议，实际值需以压测结果为准。

三、从原型到生产：三个必须补齐的缺口

原型通常只验证“模型能不能答对”。生产必须补齐以下三个缺口。

缺口一：检索质量。原型往往把整篇文档塞进提示词，生产必须做分块、嵌入、召回、重排。分块大小建议从512 Token起步，重叠64 Token；嵌入模型选用text-embedding-3-large，维度3072；召回Top 20后经语义重排取Top 5注入上下文。判断依据是：回答中引用的片段是否来自正确文档，可用人工标注的50条问答对做召回率评估。

缺口二：成本与延迟。GPT-4o的输入Token价格远高于GPT-4o mini。生产架构应做模型分级：简单意图识别、分类、摘要走mini；复杂推理、多步工具调用走GPT-4o。同时，在API Management层启用语义缓存，对相似度高于0.92的请求直接返回缓存结果。示例：若日均10万次请求，缓存命中率30%，按每次输入800 Token、输出200 Token估算，可节省约三成模型调用成本。

缺口三：可观测与安全。生产必须能回答“这次回答为什么慢、为什么贵、为什么被拦截”。建议在编排层埋点记录：请求ID、召回文档ID、提示词Token数、补全Token数、模型名称、端到端延迟、内容安全拦截标记。这些字段写入Application Insights，并用Kusto查询做聚合。安全方面，Azure AI Content Safety应在输入和输出两侧各做一次过滤，拦截阈值根据业务容忍度调整，默认建议对仇恨、暴力、自残类别使用中等阈值。

四、一个可参考的生产部署拓扑

以下给出一个中等规模生成式AI应用的生产拓扑示例，供架构设计时参考。用户请求先到Azure Front Door做全球接入与WAF，再进入API Management完成认证、限流与语义缓存判断；未命中的请求转发到AKS上运行的编排服务；编排服务调用Azure AI Search做混合检索，调用Azure OpenAI做推理；推理结果经Content Safety过滤后返回，同时将埋点数据写入Application Insights。模型密钥存放在Key Vault，AKS通过托管身份访问，避免密钥硬编码。

请求路径示例（简化）：
Client → Front Door → APIM (JWT校验/限流/语义缓存)
  → AKS 编排服务 (Prompt Flow Runtime)
    → Azure AI Search (向量+关键词混合召回)
    → Azure OpenAI (GPT-4o / GPT-4o mini)
    → Azure AI Content Safety (输入/输出过滤)
  → 返回响应 + 埋点写入 Application Insights
密钥与配置：Key Vault ← AKS 托管身份

这个拓扑的关键判断点是：语义缓存放在APIM层而非编排层，因为缓存命中时无需进入AKS，可显著降低延迟和计算成本；内容安全过滤放在编排服务之后、返回之前，确保输出侧也被检查。若业务要求数据完全不出虚拟网络，则需为Azure OpenAI和Azure AI Search配置私有终结点，并关闭公共访问。

架构设计的最终检验标准不是图有多漂亮，而是：当模型版本升级、检索策略调整、流量突增或安全策略收紧时，能否只改动一层而不影响其他层。能做到这一点，分层架构才算真正落地。