14.4 生产参考架构：SLO、变更单元、降级与回滚

模型工坊最后一次演练同时发生了三件事：远程模型限流，新索引漏掉一批权限标签，旧缓存仍在返回上个版本的答案。单个组件的健康检查都曾显示正常，用户看到的系统却已经不可靠。

生产 AI 应用不是“LLM 服务 + UI”。它是一条跨身份、数据、模型、工具和观测的请求链。架构的价值在于让失败被限制、变化可比较、结果可追踪，并能在依赖不可靠时安全降级。

本课目标

• 画出端到端 request/data/control planes；
• 把产品目标分解为 component SLO 与 error budget；
• 定义覆盖模型、prompt、索引、工具和缓存的变更单元；
• 设计隔离、降级、canary 与原子回滚；
• 用 trace、business outcome 和事件回流持续运营。

1. 一条参考请求链

Client
  ↓ identity / rate / request limits
API Gateway
  ↓ canonical request + trace + deadline
AI Policy & Model Gateway
  ├─ route → Model Serving / Provider
  ├─ retrieve → ACL Filter → Hybrid Search → Rerank
  └─ tools → Validate → Authorize → Approve → Execute
           ↑             Orchestrator state             ↓
           └──── evidence / tool results / budgets ─────┘
  ↓ schema / citation / safety / business validation
Response / Artifact Store
  ↓
Telemetry + Evaluation + Feedback + Incident Pipeline

Control plane 管理 deployment bundles、policies、schemas、index versions、quotas 和 feature flags；data plane 处理用户请求。分离二者可以限制运行时组件直接修改自己的策略和发布状态。

2. 身份与 Deadline 贯穿全链路

每层传播 principal、tenant、purpose、trace ID、deadline 和 cancellation。下游以自身资源重新授权，不能只相信上游说“已经检查过”。

Deadline 是总预算，不是每层各给 30 秒：

request deadline
  - gateway queue
  - retrieval/rerank
  - model TTFT/decode
  - tool calls
  - validation/serialization
  = remaining budget

重试和 fallback 共用剩余 deadline/cost budget。客户端取消后，向模型、检索和工具传播 cancellation；已产生的 side effect 仍需查询状态和记录。

3. SLO 从用户结果分解

例如“95% 的证据问答在 5 秒内给出有支持的答复”包含：

• availability：系统可接受并完成请求；
• latency：TTFT、E2E 和工具延迟；
• quality：correct/grounded/citation-complete；
• safety/security：无越权检索和危险副作用；
• freshness：引用在允许版本窗口内；
• business outcome：用户是否完成任务或升级人工。

Component SLI 帮助诊断，但不能替代 end-to-end SLO。Retriever Recall@K 正常，仍可能因 context truncation 或 generation failure 让用户失败。

Error budget 用于决定变更速度和可靠性投入。安全、隐私和重大权利伤害通常是 hard guardrails，不应被平均 availability budget 抵消。

4. Deployment Bundle 是真实变更单元

一个可复现版本包含：

application/orchestrator image
model/provider revision + tokenizer/template + adapter
system prompts + output schemas
retriever/embedding/reranker + index snapshot
tool schemas + tool service/API versions
safety/authorization policies
cache namespace/key version
feature flags + routing rules
evaluation report + migration/rollback plan

只给模型打版本号，会漏掉更常见的 prompt、索引和工具变化。Bundle manifest 使用 immutable IDs/hash，并记录依赖兼容矩阵。

DB 或 index migration 若不可逆，先设计 dual-read/write、backfill 验证和 forward-fix/restore 路径。模型回滚不能自动回滚已经发送的邮件或完成的付款。

5. 发布链路逐步扩大影响

unit/schema/property tests
→ component + end-to-end offline eval
→ security/privacy/red-team regression
→ shadow replay
→ internal / tenant canary
→ small traffic canary
→ staged rollout
→ post-release hold and review

每阶段预定义 promote/stop/rollback criteria。Canary 稳定分桶到 user/tenant/session，避免同一 workflow 混用版本；高风险租户不要默认成为早期试验流量。

在线比较同时看 success、quality guardrails、incident signals、TTFT/TPOT、cost、fallback、human escalation 和 cache correctness。短期指标正常也要留观察窗口覆盖文档更新、权限变化和长任务。

6. 回滚必须原子地恢复兼容组合

如果新 prompt 依赖新 tool schema，只回滚模型可能造成协议错配。以 deployment bundle 或兼容的 feature flags 回滚：

• route/model aliases；
• prompt/schema/policy；
• index read version；
• tool contract；
• cache namespace；
• application/orchestrator。

回滚前确认旧版本仍符合当前安全政策和数据要求。旧 index 可能缺少新 ACL，旧模型供应商也可能已停止服务。定期演练 rollback，而不是等事故时第一次执行。

7. 设计分级降级

依赖故障时，系统可按风险选择：

1. 功能降级：关闭写工具，只保留只读问答；
2. 质量降级：切到能力兼容的较小模型，并明确限制；
3. 数据降级：检索不可用时只回答不依赖私有/实时事实的请求；
4. 交互降级：停止长 Agent workflow，转固定流程或人工；
5. 容量降级：缩短最大输出、限制低优先级流量；
6. 安全停止：无法授权、验证或隔离时拒绝执行。

不要在 RAG 故障时让模型凭参数记忆继续回答“当前政策”；也不要在审批服务不可用时默认批准。降级行为进入产品说明和测试集。

8. 隔离 Failure Domains

• 每 tenant/priority 设 queue、quota 和 budget，防 noisy neighbor；
• 高风险工具与普通生成使用不同执行器/credential；
• 检索和模型 provider 用 circuit breaker 隔离；
• 评测/批处理流量不与在线关键请求抢同一无限资源；
• cache、index 和 object store 设容量/entry limits；
• 外部 provider failure 不触发跨层无限重试；
• control-plane compromise 不应直接获得业务数据权限。

Bulkhead 会牺牲部分资源利用率，换取故障不扩散。用 chaos/fault injection 验证，而不是只看架构图。

9. Observability 连接技术与业务结果

单次 trace 记录：

• resolved deployment bundle；
• queue、retrieval、rerank、model、tools、validation spans；
• documents/citations、auth decisions 和 policy reasons；
• tokens、latency、cost、cache events、retries；
• state transitions、side effects 与 stop reason；
• final artifact、business result、user correction/escalation。

Metrics 用于趋势和告警，traces 用于跨组件定位，logs 保存必要事件，evaluation samples 判断行为质量。三者都需要采样、脱敏、访问控制、保留和删除策略。

把技术指标连接到“任务是否完成”。Token 降了 20% 但用户返工上升，不是有效优化。

10. 成本是一种受控资源

拆分单位成本：input/output tokens、embedding/rerank、tool/API、GPU time、storage/cache、人工评审和事件处理。计算 cost/request 之外，还算 cost/successful task、cost/grounded answer 和 cost/approved action。

优化顺序通常是：删掉无价值调用，缩短/结构化上下文，选择合适模型，复用安全的中间结果，再做 kernel/serving 优化。不能用降低质量或绕过验证换取表面成本下降。

对 Agent 设置每 run/tenant budget 和异常花费告警；财务账单对账 trace usage，防供应商 token accounting 或 retry 行为变化无人察觉。

11. 运营循环

生产信号 / 申诉 / 事件
→ 去敏复现与 failure taxonomy
→ 定位 data/model/prompt/retrieval/tool/orchestration
→ 修复 + 邻近变体
→ 离线回归与风险复核
→ staged rollout
→ 监控 residual risk

Owner 不只包括 ML 工程师：产品、领域、安全、隐私、SRE、法务/合规和申诉运营各自持有不同控制。严重风险接受必须有具备相应权限的人签署。

12. 最终架构评审清单

请求与权限

• principal、tenant、deadline、cancellation 是否贯穿？
• 每个数据和工具访问是否在资源侧重新授权？
• side effects 是否幂等、可确认、可审计？

数据与版本

• 文档、索引、cache、model 和 prompt 能否定位到 immutable version？
• 删除、ACL 和紧急政策更新能否传播？
• 第三方变更是否能被 probe 和回归发现？

可靠性

• queue 是否有界，重试是否共享预算？
• 依赖故障是否有安全降级和 failure isolation？
• rollout/rollback/kill switch 是否演练？

质量与风险

• 组件与端到端评测能否定位故障层？
• 高风险 slices、红队和生产事件是否进入门禁？
• 人工复核、纠正和申诉是否真实可用？

常见误区

• 组件健康就代表系统健康：协议错配和跨层错误仍会发生。
• 回滚应用镜像就够了：模型、索引、prompt、schema 和 cache 也属于版本。
• 有 fallback 就高可用：fallback 可能不满足能力、数据或安全合同。
• 降级就是换小模型：高风险事实和动作有时必须停止。
• 模型指标就是业务指标：要追踪任务结果、返工、申诉和现实副作用。

练习

1. 为 RAG + Tool Agent 画 request/control/data planes。
2. 把“5 秒内可靠回答”分解成至少六个 SLI。
3. 写一个包含模型、prompt、index、tool 和 cache 的 deployment manifest。
4. 设计 provider 限流、ACL 索引错误和 cache 陈旧同时发生时的降级顺序。
5. 演练一次需要回滚 index 与 tool schema 的发布事故。

小结

生产 AI 架构把不确定模型放进确定的身份、权限、版本、预算和恢复边界。推理服务提供容量，网关和路由选择兼容能力，缓存复用可证明相同的计算，工作流执行受控动作，评测与观测为发布和事件提供证据。

模型工坊的门在这里打开。阿花没有带走一张“万能 AI 架构图”，而是带走了更可靠的判断顺序：先定义任务与伤害，再选择数据和模型；先建立验证、权限与回退，再扩大能力和流量。新的模型还会出现，这组边界仍然可以继续使用。