生产级机器学习系统：从模型交付到决策流嵌入的四大支柱
1. 项目概述：当模型走出笔记本，真正开始“呼吸”现实世界
你有没有经历过这样的时刻？模型在 Jupyter Notebook 里跑得飞起，AUC 0.92，F1 0.88，交叉验证稳如老狗；团队围在白板前击掌庆祝，业务方当场拍板上线；PR 合并，CI/CD 流水线绿光闪烁，部署脚本一键执行——然后，系统安静了三分钟。接着，告警群开始刷屏：延迟 P99 从 47ms 暴涨到 1200ms；下游服务报 503 Service Unavailable；风控策略的拒绝率一夜之间跌了 37%，而当天的坏账率却悄悄爬升了 0.8 个基点。没人知道为什么。日志里没有报错，指标图上只有几条诡异的毛刺，监控面板像一张沉默的嘴。你翻遍特征工程代码，重跑离线评估，结果一切如旧。问题不在模型里，它数学上依然完美。问题在模型之外——在它被塞进支付网关时少传了一个 header，在它依赖的实时用户画像服务因 GC 停顿 800ms 而超时降级，在它生成的决策被前端缓存了 5 分钟而未刷新……这才是 Part 4 的真实起点：机器学习落地的最后一公里，从来不是模型精度的比拼，而是系统韧性、治理颗粒度与人机协作边界的精密校准。本文关键词——“Towards AI - Medium”——并非指向某个平台或渠道，而是代表一种稀缺的实践视角：它不教你怎么调参，不堆砌 SOTA 架构，而是直面银行、保险、支付等强监管、高并发、低容错场景中，一个模型工程师每天要擦三次汗的真实战场。适合谁读？刚把第一个 XGBoost 模型推上测试环境的算法新人；正被线上模型“偶发性失灵”折磨得睡不着觉的 MLOps 工程师；需要向风控委员会解释“为什么这个月模型没出问题，但坏账率还是涨了”的数据科学负责人；以及所有相信“能跑通 notebook 就等于能交付价值”的人——这篇就是给你泼的那盆冷水，也是帮你搭的第一级台阶。
2. 核心设计思路：为什么“部署”不是终点，而是系统性风险的引爆点
2.1 从“模型交付”到“决策流嵌入”的范式迁移
绝大多数 ML 教程和论文的终点，是 model.save() 或 joblib.dump() 那一行代码。但现实世界的终点，是模型决策被写入核心交易数据库、触发实时反欺诈拦截、或决定某位客户能否在 3 秒内获得授信额度的那一刻。这两者之间，横亘着一条由网络协议、服务契约、数据血缘、故障域隔离和人为操作组成的“死亡峡谷”。我参与过三个银行级信贷评分模型的上线，最深的教训是：模型本身出错的概率，远低于它被错误集成的概率。举个具体例子：某次上线，模型预测服务（Python + Flask）被要求嵌入到 Java 主流程中，通过 HTTP 调用。开发同学按文档配置了 5s 超时，但没注意到主流程的全局熔断阈值是 800ms。结果当模型服务因特征计算慢了 1.2s，主流程直接熔断，返回默认“拒绝”，而监控只显示“调用失败”，没人去查失败原因是否来自下游。这个设计缺陷，在 notebook 里永远无法复现——因为 notebook 里没有熔断器，没有线程池，没有 JVM GC 停顿。所以 Part 4 的核心设计思路，首先是认知上的“降维”：把“部署一个模型”重新定义为“将一个决策组件无缝注入现有业务流”。这意味着设计阶段就必须回答：这个决策流的 SLA 是什么？它的上游数据源有哪些？下游消费者是谁？失败时的 fallback 策略由谁定义、如何生效？这些答案，决定了你选 Flask 还是 FastAPI，选 REST 还是 gRPC，选同步调用还是异步消息队列。
2.2 “正确性”让位于“可观测性”与“可退化性”
在学术界，“模型正确”意味着在 holdout test set 上指标达标。在生产环境，“系统正确”意味着你能清晰回答：过去 24 小时，模型对 100 万次请求的响应时间分布如何？其中 5% 的长尾延迟，是由哪个特征计算模块拖累的？当用户画像服务不可用时，模型是否自动切换到基于静态规则的降级策略？降级后的准确率下降了多少？这些能力，统称为“可观测性”（Observability）和“可退化性”（Degradability）。它们不是锦上添花的功能，而是生存必需品。我见过最典型的反例，是一个推荐系统模型，其特征管道严重依赖 HBase 实时查询。上线后，HBase 集群因磁盘 IO 瓶颈导致 P95 查询延迟从 15ms 涨到 300ms。模型服务没有设置任何超时或熔断，结果整个推荐 API 的 P99 延迟飙升至 2.3s，用户流失率当日上升 12%。事后复盘发现，问题根源不是模型，而是缺乏两个简单机制：第一，特征获取层必须有硬性超时（我们后来设为 50ms）；第二，必须预置降级开关，当特征获取失败率 > 5% 时，自动切到基于历史点击率的兜底策略。这两个机制，加起来不到 50 行代码，却让系统从“一触即溃”变成“优雅跛行”。这就是 Part 4 强调的设计哲学：不要问“模型能不能工作”，而要问“当它不能完美工作时，系统还能不能提供可接受的服务”。这种思维，直接决定了你的架构选型——比如，为什么我们坚持用 Prometheus + Grafana 而非仅用 MLflow 的 metrics tracking？因为前者能关联 CPU、内存、网络延迟、GC 时间等基础设施指标，让你一眼看出“模型延迟突增”和“JVM Full GC”是否同步发生。
2.3 治理前置：把“谁负责”刻进系统 DNA
很多团队把治理（Governance）当成上线后的补救措施：等审计来了，再补模型文档、填审批表、导特征清单。这就像等房子塌了才去查地基图纸。Part 4 的关键洞见是：治理必须是设计阶段的第一公民，而非运维阶段的附加项。在我们为某股份制银行构建反洗钱模型时，治理要求被拆解成硬性技术约束：第一，所有特征必须带元数据标签，包括来源系统、更新频率、业务含义、GDPR 分类（PII/Non-PII），这些标签在特征注册中心（Feature Store）创建时强制填写，缺失则无法发布；第二，模型版本每次部署，必须关联一个唯一的“决策变更单”（DCR），该 DCR 包含业务影响分析、回滚步骤、审批链路，且 DCR ID 必须写入模型服务的 HTTP 响应头 X-Decision-Change-Request-ID；第三，所有线上决策必须记录原始输入、模型输出、决策依据（如 top-3 影响特征及权重）、人工 override 标记，并持久化到审计日志库，保留期 ≥ 7 年。这些看似繁琐的规则，带来的实际收益是惊人的：当某次模型更新后，可疑交易漏报率异常升高，我们 15 分钟内就定位到是新加入的“跨境支付频次”特征因上游数据延迟，导致 30% 请求拿到空值，而模型未做空值处理。更关键的是，我们能立刻追溯到该特征的 DCR 编号，找到当初的业务影响评估报告，确认“允许空值场景下漏报率容忍上限为 0.5%”，从而快速判定这是重大偏差，启动紧急回滚。治理不是刹车，而是给高速行驶的系统装上导航仪和黑匣子。
3. 核心细节解析：生产级 ML 系统的四大支柱实操要点
3.1 部署与集成：让模型成为可靠服务的七道工序
部署不是“把模型文件扔进 Docker”，而是一套标准化、可审计、可回滚的七道工序。我在三家金融机构推行的 SOP 如下，每一步都对应一个真实踩过的坑：
-
契约先行（Contract First）：在写任何模型代码前，先与上下游服务方（如支付网关、用户中心）签署 API 契约（OpenAPI 3.0 spec）。明确约定：请求体字段名、类型、必填项、取值范围；响应体结构、HTTP 状态码语义（如
200表示决策成功，422表示输入数据格式错误，503表示服务不可用）；SLA（P95 延迟 ≤ 80ms，可用性 ≥ 99.95%）。教训：曾因契约未约定空字符串处理逻辑，导致用户手机号为空时模型返回NaN，下游解析失败引发雪崩。 -
特征管道容器化（Feature Pipeline Containerization）：特征计算代码（Python/Scala）与模型服务分离，各自打包为独立 Docker 镜像。特征管道镜像暴露
/features接口，接收原始事件，返回结构化特征字典；模型服务镜像暴露/predict接口，只接收特征字典。两者通过 Kubernetes Service 发现。好处：特征逻辑升级无需重启模型服务；模型算法更换不影响特征计算。 -
超时与熔断双保险（Timeout & Circuit Breaker）：在模型服务的 HTTP 客户端（如 Python 的
requests）中，必须设置两级超时：connect_timeout=100ms（建立 TCP 连接），read_timeout=50ms（等待响应体）。同时，在服务入口（如 Nginx Ingress）配置熔断器：当 10 秒内失败率 > 20%，自动熔断 30 秒，期间所有请求返回预设的降级响应（如{"decision": "ALLOW", "reason": "MODEL_UNAVAILABLE"}）。参数依据：银行业务要求 99% 的决策在 100ms 内完成，故超时必须严于 SLA。 -
降级策略预埋（Fallback Strategy Embedding）：模型服务启动时，加载两套决策逻辑：主模型（ML）和降级策略（Rule-based）。降级策略必须是纯函数式、无外部依赖的代码（如
if user_age < 18: return "REJECT"）。通过环境变量FALLBACK_ENABLED=true控制开关，并在健康检查接口/healthz中暴露当前状态。实操：降级策略的代码必须和主模型一样走 CI/CD，确保一致性。 -
灰度发布与流量染色（Canary Release & Traffic Tagging）：使用 Istio 或 Linkerd 实现灰度。将 5% 的生产流量打上
canary=true标签，路由到新模型版本；其余 95% 走旧版本。所有请求日志必须包含X-Canary-Flag头，便于在 ELK 中对比两个版本的指标。关键：灰度期间，禁止任何手动修改模型参数，所有变更必须通过版本控制。 -
配置即代码（Configuration as Code）：模型阈值、特征权重、降级开关等所有可变参数，不得硬编码。统一存于 HashiCorp Vault，服务启动时通过 Sidecar 注入环境变量。每次参数变更，必须提交 PR 到
config-repo，经 CI 测试（如阈值变更是否导致模拟数据集的误拒率超标）后，由自动化流水线推送至 Vault。价值：杜绝“谁在服务器上改了 config 导致事故”的扯皮。 -
一键回滚（One-Click Rollback）：部署流水线必须包含
rollback任务。执行时，自动将 Kubernetes Deployment 的镜像 tag 切回上一版本，并将 Vault 中的配置恢复至上一 commit。整个过程 ≤ 90 秒，且回滚后自动触发 smoke test（如发送 10 条测试请求，验证响应格式和基本逻辑）。底线：回滚不是应急手段，而是日常演练。每月至少执行一次。
提示：这七道工序，每一道都对应一个可能的故障点。我建议团队用“故障注入”（Chaos Engineering）方式定期验证：随机 kill 特征管道 Pod，看模型服务是否自动降级；手动修改 Vault 中的阈值，看是否 2 分钟内生效；模拟网络分区，看熔断器是否在 10 秒内触发。只有被反复破坏过的系统，才值得信任。
3.2 性能、延迟与可扩展性：在毫秒级战场上守住阵地
生产环境的性能瓶颈，90% 不在模型推理本身，而在数据搬运、序列化、网络传输和资源争抢。以下是我们在高频交易、实时风控等场景中验证有效的实操要点：
模型推理加速：
- 对于树模型（XGBoost/LightGBM），禁用
sklearn的predict()，改用原生库的predict()（LightGBM 的predict()比 sklearn 封装快 3-5 倍）； - 对于深度学习模型，使用 ONNX Runtime 替代原生框架（PyTorch/TensorFlow），在 CPU 上平均提速 2.1 倍，内存占用降 35%；
- 所有模型加载后，必须调用
model.set_params(n_jobs=-1)（LightGBM）或ort_session.set_providers(['CPUExecutionProvider'])（ONNX），显式启用多核并行。
特征序列化优化：
- 禁止使用 JSON 作为特征传输格式！JSON 解析慢、体积大。改用 Protocol Buffers（protobuf）：定义
.proto文件，生成 Python/Java 类，序列化后体积仅为 JSON 的 1/4，解析速度快 8 倍。我们曾将一个 120 字段的特征向量，从 JSON 的 18KB 压缩到 protobuf 的 4.2KB，P95 延迟下降 22ms。 - 特征向量中，将高基数类别特征（如用户 ID）转为 int64，而非 string；数值特征统一用 float32（非 float64），节省 50% 内存带宽。
服务层调优：
- Web 服务器选型：FastAPI + Uvicorn（async）比 Flask + Gunicorn（sync）在高并发下吞吐量高 3.7 倍，P99 延迟稳定在 15ms 内；
- 连接池：Uvicorn 的
--workers数 = CPU 核数 × 2，每个 worker 的--limit-concurrency设为 1000，避免连接耗尽； - 内核参数：在 Kubernetes Node 上，调大
net.core.somaxconn=65535和net.ipv4.tcp_tw_reuse=1，解决 TIME_WAIT 连接堆积。
可扩展性设计：
- 水平扩展：模型服务必须是无状态的（Stateless）。所有状态（如用户会话、缓存）外置到 Redis Cluster。我们曾用 16 个 4C8G Pod 支撑峰值 12,000 QPS，P95 延迟 < 60ms；
- 垂直扩展：单 Pod 的 CPU Request 设为 2000m（2 核），Limit 设为 4000m（4 核），避免突发流量压垮；
- 弹性伸缩：HPA（Horizontal Pod Autoscaler）的指标不只看 CPU，必须加入自定义指标
model_latency_p95_ms（通过 Prometheus 抓取），当该指标 > 50ms 持续 2 分钟，自动扩容。
注意：性能优化必须有数据支撑。我们强制要求：每次优化前，用
locust工具进行基准测试（Baseline Test），记录 TPS、P50/P95/P99 延迟、错误率；优化后，用相同脚本复测，差异必须显著（p-value < 0.01）。没有 baseline 的优化，都是玄学。
3.3 监控与漂移检测：构建模型的“生命体征监护仪”
生产模型的监控，绝不能只盯着 accuracy 或 auc 这些离线指标。它们像体检报告里的“血压”，但模型真正的“生命体征”，是实时流动的数据和决策。我们构建的四层监控体系如下：
第一层：基础设施层（Infrastructure）
- 指标：Pod CPU/Memory 使用率、网络 I/O、磁盘 IO wait；
- 告警：CPU > 90% 持续 5 分钟；Memory > 85% 持续 10 分钟；
- 工具：Prometheus + Grafana，Dashboard 命名为
ML-Service-Infra。
第二层：服务层（Service）
- 指标：QPS、P50/P95/P99 延迟、HTTP 2xx/4xx/5xx 状态码比例、特征获取成功率；
- 告警：P95 延迟 > SLA × 1.5 持续 2 分钟；5xx 错误率 > 0.1% 持续 1 分钟；
- 工具：Prometheus + Grafana，Dashboard 命名为
ML-Service-Health。
第三层：数据层（Data Drift） —— 这是 Part 4 的核心创新点
- 指标：
- 输入数据漂移：使用 KS 检验（Kolmogorov-Smirnov）计算每个数值特征的分布变化（
ks_statistic），阈值设为 0.1； - 类别特征漂移：使用 PSI（Population Stability Index）计算分布变化，阈值设为 0.25；
- 特征缺失率：每个特征的
null_rate，阈值设为 0.5%（业务敏感特征如user_income为 0.1%）；
- 输入数据漂移：使用 KS 检验（Kolmogorov-Smirnov）计算每个数值特征的分布变化（
- 告警：任一特征
ks_statistic > 0.1或psi > 0.25，持续 1 小时； - 工具：自研
drift-detector服务，每小时从 Kafka 消费最新 10 万条样本，计算漂移指标，写入 Prometheus。
第四层：决策层（Decision Drift）
- 指标：
- 决策分布：
ALLOW/REJECT/REVIEW的比例，与基线（上线首日）对比，偏差 > 5% 触发预警； - 分数分布：模型输出的 raw score（如 0-1 的概率），计算其均值、标准差、分位数，与基线对比；
- 人工干预率：
override_rate = (人工 override 次数) / (总决策次数)，阈值设为 2%；
- 决策分布：
- 告警：
override_rate > 2%持续 30 分钟；score_mean偏离基线 > 10%； - 工具：ELK Stack，Kibana Dashboard 命名为
ML-Decision-Insight。
实操心得：漂移检测的阈值不是拍脑袋定的。我们采用“业务驱动法”：对每个关键特征，找业务方一起看历史数据，找出“业务可容忍的最大波动”。例如，
user_age的 PSI 阈值设为 0.25，是因为业务方确认：当该特征分布变化超过此值，意味着客群结构发生实质性迁移（如从 25-35 岁主力变为 18-24 岁学生），必须重新审视模型。记住：漂移检测不是为了消除漂移，而是为了在业务可接受的范围内，捕捉到漂移发生的精确时刻，从而启动人工研判。
3.4 模型验证与压力测试：用“极限拷问”代替“纸上谈兵”
在金融等强监管行业，模型上线前的验证，不是证明它“能工作”，而是证明它“在各种极端情况下，不会造成不可接受的损失”。我们的压力测试框架包含四个维度：
维度一：数据质量压力（Data Quality Stress）
- 场景：模拟上游数据源故障：
- 100% 的
user_credit_score字段为空； transaction_amount字段 30% 为负数（非法值）；device_id字段 50% 为超长字符串（> 100 字符）；
- 100% 的
- 验证点：模型服务是否返回
422错误（而非崩溃）？降级策略是否被触发？日志是否清晰记录错误字段？ - 工具：
pytest+ 自定义data_corruptorfixture。
维度二：性能压力（Performance Stress）
- 场景：使用
k6工具施加阶梯式负载：- 1 分钟：1000 QPS；
- 1 分钟：5000 QPS；
- 1 分钟：10000 QPS；
- 1 分钟：维持 10000 QPS；
- 验证点：P95 延迟是否始终 < 80ms？错误率是否 < 0.01%？CPU 使用率是否平稳？
- 工具：
k6+ Prometheus，生成stress-test-report.pdf。
维度三：对抗性压力（Adversarial Stress）
- 场景：构造恶意输入，测试模型鲁棒性：
- 对数值特征，添加 ±10% 的高斯噪声；
- 对类别特征，随机替换为高频值（如
country=US→country=CN）； - 对文本特征，插入 Unicode 零宽空格（U+200B）；
- 验证点：决策结果变化率是否 < 5%？分数波动是否在 ±0.1 范围内？
- 工具：
textattack+ 自定义feature_perturber。
维度四：业务逻辑压力（Business Logic Stress）
- 场景：模拟高风险业务场景：
- 单用户 1 秒内发起 100 笔小额支付（疑似洗钱）；
- 同一设备 ID 在 5 分钟内关联 50 个不同用户（疑似黑产）；
- 用户在申请贷款后 2 秒内，征信报告被查询 3 次（疑似多头借贷）；
- 验证点：模型是否能识别这些模式？决策是否符合业务规则（如“同一设备多用户”必须
REJECT）？ - 工具：
locust+ 业务规则引擎（Drools）。
关键经验：压力测试报告必须包含“可行动项”（Actionable Items）。例如，测试发现“当
user_income为空时，模型返回NaN而非降级”，则报告中必须写明：“修复方案：在特征管道中增加fillna(0)步骤，并更新 DCR 文档”。没有修复路径的测试，只是浪费时间。
4. 实操过程：从零搭建一个银行级信贷评分模型的生产流水线
4.1 环境准备与工具链选型
我们以一个真实的银行信贷评分模型（目标：预测用户未来 6 个月违约概率）为例，完整复现 Part 4 的实操过程。环境基于 Kubernetes 1.24，所有工具均为开源、免许可、企业级成熟方案。
基础设施：
- Kubernetes Cluster：3 个 Master（t3.xlarge），6 个 Worker（c5.4xlarge，16vCPU/32GB RAM）；
- 存储：AWS EBS gp3（500GB，15000 IOPS）用于模型存储，Amazon EFS 用于共享日志；
- 网络：Calico CNI，Istio 1.18 服务网格。
核心工具链：
- 特征存储（Feature Store）：Feast 0.25（开源版），后端用 PostgreSQL 14；
- 模型注册与追踪：MLflow 2.10，后端用 MySQL 8.0；
- 模型服务：KServe 0.12（原 KFServing），支持 SKLearn、XGBoost、ONNX 模型；
- 监控：Prometheus 2.45 + Grafana 10.1 + Alertmanager；
- 日志：Elasticsearch 8.9 + Logstash + Kibana；
- CI/CD：GitLab CI 16.3，Runner 用 Kubernetes Executor；
- 配置管理：HashiCorp Vault 1.14。
选型理由：我们放弃了一些“炫技”方案（如用 Ray Serve 做模型服务），因为银行环境首要需求是稳定性、可审计性和社区支持度。Feast 和 MLflow 有成熟的金融行业案例；KServe 是 CNCF 毕业项目，被多家银行采用；Vault 是密钥管理的事实标准。工具链的复杂度，必须与团队的运维能力匹配——宁可用“笨办法”保证 99.95% 可用性，也不用“聪明办法”追求 99.99% 却增加 3 倍故障排查时间。
4.2 特征管道构建：从原始数据到实时特征向量
特征管道是生产系统的“心脏”，其健壮性直接决定模型寿命。我们采用 Feast + Airflow 的组合，分为离线和实时两部分：
离线特征管道（Batch）：
- 数据源：银行核心系统 Oracle DB（用户基本信息）、Hive 数仓（历史交易）、Spark 集群（行为日志）；
- 工具：Airflow 2.6 DAG，每日凌晨 2 点触发；
- 步骤：
extract_oracle: 用cx_Oracle连接 Oracle，抽取user_profile表（user_id,age,income,employment_status）；transform_hive: 用 Spark SQL 计算user_transaction_stats（过去 30 天交易笔数、金额均值、最大单笔）；join_features: 将 Oracle 和 Hive 数据 Join，生成宽表user_features_daily；feast_apply: 调用 Feast CLIfeast apply，将宽表注册为user_offline_features特征视图；
- 输出：Feast Online Store（PostgreSQL）中，每个
user_id对应一条最新离线特征。
实时特征管道（Streaming）：
- 数据源：Kafka Topic
user_events（用户登录、浏览、申请等事件）； - 工具：Flink 1.17 Job；
- 步骤：
parse_json: 解析 Kafka 消息，提取user_id,event_type,timestamp；window_aggregate: 滚动窗口（1 小时）计算user_recent_clicks（点击次数）、user_active_minutes（活跃分钟数）；enrich_with_offline: 与 Feast Online Store Join，补充income,age等离线特征；feast_write: 将结果写入 Feast Online Store；
- 输出：Feast Online Store 中，每个
user_id的实时特征每 10 秒更新一次。
特征服务（Feature Serving）：
- 模型服务启动时，通过 Feast SDK 初始化
FeatureStore； - 每次预测请求到达，服务调用
store.get_online_features()，传入user_id，返回一个pd.DataFrame，包含所有离线+实时特征； - 关键配置：
timeout=50ms，max_workers=10，避免特征获取拖慢整体延迟。
实操注意：特征管道的“血缘”（Lineage）必须可追溯。我们在 Feast 中为每个特征视图配置
owner: "credit-team@bank.com"和description: "Derived from Oracle user_profile table, updated daily"。Airflow DAG 的每个 task 都记录task_instance.log_url到 MLflow，确保任何特征异常都能快速定位到源头。
4.3 模型服务部署：KServe 的生产级配置详解
KServe 是我们选择的模型服务框架，因其原生支持多框架、多格式、金丝雀发布和自动扩缩容。以下是针对信贷模型的生产级配置（credit-score-service.yaml）：
关键配置解读：
minReplicas: 3：保证基础容量，避免冷启动；scaleTargetCPUUtilizationPercentage: 70：CPU 使用率 > 70% 时触发扩容，留出 30% 余量应对突发；livenessProbe和readinessProbe：健康检查路径/healthz返回{"status": "ok", "uptime_seconds": 12345}，/readyz返回{"status": "ready", "feature_store_connected": true, "vault_connected": true}；transformer：独立容器处理特征转换和降级，与模型解耦；env中的VAULT_ADDR：服务启动时，从 Vault 获取模型阈值和降级开关。
部署命令：
实操心得：KServe 的
storageUri必须指向一个高可用对象存储（如 S3、MinIO）。我们严禁将模型文件放在本地磁盘或 NFS 上，因为节点宕机会导致服务不可用。S3 的versioning功能，让我们能随时回滚到任意历史版本的模型文件，这是生产环境的生命线。
4.4 监控仪表盘搭建：Grafana 的 12 个核心看板
一个合格的生产监控，不是堆砌指标，而是用指标讲清故事。我们在 Grafana 中构建了 12 个核心看板，覆盖全链路。以下是其中 4 个最具实战价值的看板配置：
看板 1：ML-Service-Health（服务健康）
- Panel 1：
QPS（每分钟请求数），折线图，对比昨日同期； - Panel 2：
Latency P95 (ms)，柱状图，按 HTTP 状态码分组（2xx, 4xx, 5xx）； - Panel 3：
Error Rate (%)，饼图，展示 4xx/5xx 占比； - Panel 4：
Feature Fetch Success Rate (%)，折线图，阈值线设为 99.5%； - 告警规则：当
Latency P95 > 80且Error Rate > 0.1同时成立，触发 PagerDuty。
看板 2：ML-Data-Drift（数据漂移）
- Panel 1：
Top 5 Features by PSI，水平条形图，显示user_income,age,transaction_count等 PSI 值； - Panel 2：
KS Statistic Trend，折线图，展示user_income的 KS 值过去 7 天变化； - Panel 3：
Null Rate Heatmap，矩阵图，X 轴为特征名，Y 轴为小时，颜色深浅表示缺失率； - 告警规则：当任一特征
PSI > 0.25持续 1 小时，邮件通知数据科学家。
看板 3：ML-Decision-Insight（决策洞察）
- Panel 1：
Decision Distribution，堆叠面积图，展示ALLOW/REJECT/REVIEW比例； - Panel 2：
Score Distribution，直方图，对比今日与基线（上线首日）的
387 373 2135 395 430 347 298 465 425 371 665 556 351 435 424 311 382 402 417 413