4. 质量治理框架设计
在 Databricks AI 平台中，AI 资产不只是模型本身，还包括特征表、训练数据集、推理端点、向量索引、评测集、提示模板以及监控指标。质量治理框架的目标，是把“质量好不好”从主观判断变成可度量、可追责、可闭环的工程机制。本节围绕四个核心构件展开：质量维度、SLI/SLO、责任矩阵与治理流程，并给出可直接落地的示例。
一、质量维度：先定义“好”的边界
质量维度是治理的起点。对 Databricks AI 资产而言，建议至少覆盖六个维度：
- 数据质量：完整性、唯一性、时效性、分布漂移。例如特征表
gold.customer_features要求主键唯一率 ≥ 99.99%，每日 06:00 前完成刷新。 - 模型质量：离线指标（AUC、F1、RMSE）、校准度、公平性切片差异。例如风控模型要求整体 AUC ≥ 0.82，且不同客群切片 AUC 差异 ≤ 0.05。
- 服务性能：推理端点 P95 延迟、吞吐、错误率。例如在线推理 P95 ≤ 200ms，5xx 错误率 ≤ 0.5%。
- 成本效率：单位推理成本、GPU 利用率、DBU 消耗。例如每千次推理成本 ≤ 0.8 DBU。
- 安全合规：PII 脱敏覆盖率、访问审计完整性、模型卡与数据卡齐备率。
- 可观测性：日志采样率、指标上报延迟、漂移检测覆盖率。
维度确定后，需要为每个维度指定资产类型 × 生命周期阶段的适用矩阵。例如特征表在“开发”阶段关注唯一性与空值率，在“生产”阶段额外关注时效性与漂移；推理端点在“上线前”关注压测延迟，在“运行中”关注 P95 与错误率。
二、SLI/SLO：把维度变成可告警的数字
SLI（Service Level Indicator）是实际测量的指标，SLO（Service Level Objective）是目标阈值。设计时遵循“可测量、可归因、可行动”三原则。以下是一组示例参数（属于教学示例，非实测结果）：
| 资产 | SLI | SLO | 测量窗口 | 数据来源 |
|---|---|---|---|---|
| 特征表 customer_features | 主键唯一率 | ≥ 99.99% | 每日 | Delta 表约束校验 |
| 特征表 customer_features | 刷新完成时间 | ≤ 06:00 | 每日 | Job 运行记录 |
| 推理端点 fraud-endpoint | P95 延迟 | ≤ 200ms | 5 分钟滚动 | Model Serving 指标 |
| 推理端点 fraud-endpoint | 5xx 错误率 | ≤ 0.5% | 5 分钟滚动 | Model Serving 指标 |
| 模型 fraud-v3 | PSI 漂移 | ≤ 0.2 | 每日 | Lakehouse Monitoring |
| 向量索引 product-index | 召回率@10 | ≥ 0.90 | 每周 | 离线评测 Job |
SLO 需要配套错误预算。例如“5xx 错误率 ≤ 0.5%”对应每月允许约 3.6 小时不可用预算。当预算消耗超过 50% 时触发预警，超过 100% 时冻结该资产的新功能发布，优先修复稳定性。这样 SLO 才真正约束发布节奏，而不是墙上的数字。
三、责任矩阵：谁对哪个指标负责
治理失败最常见的原因是“指标有人看，没人负责”。建议用 RACI 明确四类角色：
- R（Responsible）：直接执行者，如数据工程师负责特征表刷新。
- A（Accountable）：最终责任人，通常为资产 Owner，对 SLO 达成负总责。
- C（Consulted）：被咨询方，如合规团队对 PII 脱敏规则提供意见。
- I（Informed）：被通知方，如业务方在 SLO 违约时收到通报。
示例：推理端点 fraud-endpoint 的 P95 延迟 SLO，R 是 ML 平台工程师，A 是模型 Owner，C 是网络与基础设施团队，I 是风控业务负责人。责任矩阵应写入 Unity Catalog 的资产标签或治理台账，做到“点开资产即见责任人”。
四、治理流程：从检测到闭环
治理流程不是一次性评审，而是持续运行的闭环。核心环节包括：指标采集 → 阈值判定 → 告警路由 → 分级响应 → 复盘改进。下图展示了这一闭环与四类构件的对应关系：
流程中的关键判断点在于分级响应。建议按影响面分三级：P1 为生产推理中断或 SLO 严重违约，要求 15 分钟内响应、1 小时内恢复；P2 为指标持续劣化但未中断，要求 4 小时内定位；P3 为趋势预警，纳入周度治理例会。告警路由应基于责任矩阵自动分派，避免“告警发到群里无人认领”。
五、落地示例：一次 SLO 违约的处理
假设 Lakehouse Monitoring 在 2025-06-10 检测到 fraud-endpoint 的 P95 延迟从 180ms 升至 320ms，5xx 错误率升至 1.2%，两项均突破 SLO。系统按以下路径处理：
- 指标采集：Model Serving 每 5 分钟上报延迟与错误率至指标表。
- 阈值判定：连续 3 个窗口超过 SLO，触发 P1 告警。
- 告警路由：根据 RACI，通知 R（平台工程师）与 A（模型 Owner），抄送 I（风控业务）。
- 分级响应：平台工程师检查发现新版本模型输入特征维度增加，导致预处理耗时上升；回滚至上一版本，延迟恢复至 190ms。
- 复盘改进：将“预处理耗时”新增为 SLI，SLO 设为 P95 ≤ 50ms；同时把该检查加入上线前压测清单。
这个闭环的价值在于：一次故障不仅被修复，还转化为新的 SLI 和发布门禁，使治理框架持续进化。
综上，质量治理框架的本质是把质量维度、SLI/SLO、责任矩阵和治理流程四者绑定成一个可运行的闭环。维度定义“看什么”，SLI/SLO 定义“达到什么标准”，RACI 定义“谁来负责”，流程定义“违约后怎么办”。四者缺一，治理就会退化为报表或口号。