机器学习模型生产稳定性设计：从服务存活到数据漂移到迭代实验

MLOps模型稳定性数据漂移

于 2026-07-06 05:19:47 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 项目概述：这不是“部署”，是让模型真正活下来

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被太多人轻描淡写、却天天在真实业务中咬牙硬扛的真相：Notebook不是起点，生产环境也不是终点；它是一条持续搏斗的生存链路。我带过七支不同行业的ML落地团队，从金融风控模型上线后因特征延迟导致误拒率飙升37%，到电商推荐系统在大促峰值时API响应从200ms飙到8秒、订单漏损超200万，再到医疗影像辅助诊断模型因GPU显存碎片化在凌晨三点自动OOM崩溃……这些都不是“部署失败”，而是模型在脱离Jupyter沙盒后，第一次直面真实世界的重力、摩擦与不可预测性。Part 4之所以关键，是因为它跳出了“模型能跑通”的初级阶段，直击三个无人替你兜底的硬核问题：如何让模型服务像水电一样稳定供应？如何在数据漂移发生时比业务方更早感知异常？如何让每一次模型迭代不变成一场需要跨部门签字的高危手术？ 它不讲Flask怎么写路由，也不教Dockerfile怎么写COPY指令——那些是Part 1的事。Part 4讲的是：当你的模型被嵌入支付网关、接入IoT设备固件、或成为客服机器人唯一决策引擎时，你靠什么确保它明天、下个月、明年还在正确地呼吸。适合已经把模型训出来、API也跑通了，但一上真实流量就心慌、一改特征就崩、一出问题就查三天日志的实战派。这不是理论课，是急诊室手记。

2. 内容整体设计与思路拆解：为什么“稳定”比“快”难十倍

2.1 真实世界的第一课：稳定性不是配置出来的，是设计出来的

很多人以为“上K8s+加个HPA（水平扩缩容）”就等于生产就绪。我试过——在某物流路径优化项目里，我们用K8s自动扩缩Pod应对订单洪峰，结果发现：新Pod启动要加载12GB的图神经网络权重，冷启动耗时47秒，而订单请求超时阈值是800ms。扩得越快，积压越多，最后触发熔断，整个调度中心降级为人工派单。问题出在哪？把“服务可用性”当成运维任务，而不是架构基因。Part 4的设计核心，是把稳定性刻进每一层：

计算层：拒绝“全量加载+实时推理”一刀切。我们强制拆分“热特征缓存”（Redis集群预热用户画像向量）和“冷模型加载”（模型权重按需懒加载，首次请求延迟由前端兜底降级）；
通信层：不用默认gRPC健康检查，自定义/health/live端点，它不只ping进程，还校验特征管道是否连通、模型版本是否与元数据一致、GPU显存剩余是否>15%；
数据层：特征存储不依赖单一MySQL，采用“双写+校验”：实时写入Kafka流，异步落库，每5分钟用Flink SQL比对流表与库表的特征分布KL散度，超阈值自动告警并冻结该特征上线权限。
这不是炫技，是血换来的教训：稳定性的成本，永远低于故障的代价。一次线上模型误判导致的信贷坏账，够买三年A100服务器。

2.2 模型监控的本质：不是看准确率，是看“它还像不像自己”

很多团队监控只盯两个指标：API成功率和P95延迟。这就像只看汽车仪表盘的油量和转速，却不管轮胎是不是在漏气。Part 4的监控体系，围绕“模型是否还是它自己”构建三层防线：

输入层监控（Data Drift）：不只统计特征均值/方差，用PSI（Population Stability Index）量化分布偏移。例如，某信贷模型中“近3月逾期次数”特征，训练集PSI基线是0.02，线上连续2小时PSI>0.15，立刻触发特征冻结+人工复核——后来发现是合作银行上游ETL脚本升级，把“未逾期”错误映射为-1而非0，导致模型将优质客户判为高风险；
内部层监控（Concept Drift）：在模型输出层插入“影子分支”，用同一份输入同时跑新旧模型，计算预测置信度差异的Wasserstein距离。当距离突增，说明业务逻辑已变（如疫情后消费行为模式迁移），此时不等准确率下降，直接启动模型再训练流程；
输出层监控（Output Drift）：监控预测结果的分布熵值。某推荐系统上线后CTR未跌，但“推荐品类熵值”从4.2骤降至2.1，意味着推荐越来越窄、陷入信息茧房——这比点击率下降更危险，它在悄悄杀死用户多样性。
这套设计背后有个残酷事实：90%的模型失效，始于数据无声的背叛，而非代码的显式报错。监控不是为了画好看的大屏，是为了在业务还没察觉异常时，先听见模型的咳嗽声。

2.3 迭代机制的重构：从“发布即交付”到“发布即实验”

传统MLOps常把模型更新当作一次“发布”（Release），而Part 4把它定义为一次“受控实验”（Controlled Experiment）。原因很简单：你永远无法在测试环境100%复现生产流量的长尾分布。我们强制所有模型上线必须走AB测试闭环：

流量切分：不按简单百分比，而是按“业务语义”切分。例如电商搜索模型，将“新用户搜索”、“大促商品搜索”、“历史复购用户搜索”三类流量分别设置独立灰度比例，因为它们对模型鲁棒性的压力完全不同；
效果归因：不只看全局指标，用Causal Impact模型隔离外部干扰。某次模型更新后GMV微涨0.3%，但Causal Impact分析显示，同期竞品降价活动贡献了+0.8%，模型实际贡献为-0.5%——若只看表面数据，会错误保留劣质模型；
回滚机制：回滚不是删Pod重启旧镜像。我们维护“模型版本快照”，包含：模型权重、特征工程代码哈希、训练数据采样时间戳、依赖库精确版本（pip freeze > requirements.txt）。回滚时，整套快照原子切换，确保环境一致性。
这个设计的底层逻辑是：在不确定的世界里，唯一确定的，是承认不确定性，并用实验精神去驯服它。每一次上线，都是对假设的验证，而非对结果的宣告。

3. 核心细节解析与实操要点：把“稳定”拆解成可执行的螺丝钉

3.1 服务稳定性：从“能跑”到“抗揍”的七道加固

模型服务的稳定性，本质是抵抗三类冲击：瞬时流量脉冲、资源缓慢泄漏、依赖服务雪崩。我们不用黑盒方案，而是用七道可验证的加固措施，把抽象要求变成具体动作：

请求队列深度与拒绝策略：Nginx层配置limit_req zone=mlapi burst=200 nodelay，但关键在burst值——它不能拍脑袋定。我们用历史P99请求处理时间（如120ms）和SLA容忍延迟（800ms）反推：最大允许排队数 = (800-120)/120 ≈ 5.7，取整为5。超过5个请求直接返回429，避免线程池耗尽。实测下来，这比盲目设burst=1000更能保护服务水位。
内存泄漏防护：Python模型服务最怕gc.collect()没调好。我们在每个预测函数末尾强制插入：

PYTHON

import gc

# 预测完成后立即清理

if hasattr(model, 'clear_cache'):

model.clear_cache() # 如HuggingFace模型的clean_cache()

gc.collect()

# 检查引用计数，防止闭包持有大数据

if sys.getrefcount(input_data) > 5:

logger.warning(f"input_data ref count too high: {sys.getrefcount(input_data)}")

曾有一个OCR模型因闭包意外持有整张原图内存，运行24小时后OOM，加此检查后提前3小时预警。

GPU显存碎片化治理：PyTorch默认显存分配器易碎片化。我们在Docker启动时注入：

BASH

# 启动命令前加

export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128

# 并在服务初始化时预分配显存块

torch.cuda.memory_reserved(device=0) # 强制预留

某视觉检测服务显存利用率从65%提升至92%，QPS翻倍。

依赖服务熔断：不用Hystrix这种Java老古董。我们用tenacity库实现轻量熔断：

PYTHON

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type

@retry(

stop=stop_after_attempt(3),

wait=wait_exponential(multiplier=1, min=1, max=10),

retry=retry_if_exception_type((ConnectionError, Timeout))

)

def call_feature_service():

return requests.post("http://feature-svc:8000/encode", timeout=2)

关键是max=10——熔断窗口不能太长，否则影响业务；也不能太短，否则频繁抖动。

健康检查端点设计：/health/live必须包含：
- model_loaded: 检查model.state_dict()是否非空
- feature_pipe_ready: 调用feature_pipeline.transform([dummy_input])并校验输出维度
- gpu_memory_ok: torch.cuda.memory_reserved() < 0.85 * total_memory
- kafka_producer_health: 发送测试消息并确认ack
  缺一不可。曾因漏掉kafka_producer_health，导致特征管道中断2小时未告警。
日志结构化与采样：不用print，全用structlog：

PYTHON

logger.info("inference_start",

request_id="req_abc123",

model_version="v2.3.1",

input_shape=str(input_tensor.shape))

并配置采样：P99慢请求100%记录，普通请求0.1%采样，避免日志IO打满磁盘。

配置热更新：模型参数（如温度系数、top_k）不写死代码。我们用Consul KV存储，服务内嵌watcher：

PYTHON

def update_config_from_consul():

config = consul_client.kv.get("ml/model/v2.3.1/config")["value"]

model.temperature = float(config.get("temperature", 1.0))

修改配置后3秒内生效，无需重启。

提示：这七道加固不是选做题。少一道，就可能在某个深夜成为压垮骆驼的最后一根稻草。我见过太多团队只做1、2、3，结果在第4道熔断缺失时，一个下游数据库抖动，引发全链路雪崩。

3.2 数据漂移监控：用PSI和KL散度抓住“沉默的背叛”

数据漂移监控最容易犯的错，是把“统计检验”当成“业务判断”。比如某金融模型监控到“年龄”特征均值从35.2变为34.8，p值<0.01，于是告警——但业务方说：“这是正常季节性波动，Q3学生毕业入职增多。” 监控失效，信任崩塌。Part 4的实践是：用PSI/KL量化分布变化，用业务规则过滤噪声，用人工复核锚定阈值。

PSI计算实操（以数值型特征为例）：

将特征值分箱：训练集数据分10等频箱（确保每箱样本数相近），记录各箱占比；
用相同分箱边界切分线上数据，计算各箱占比；
PSI = Σ(线上占比 - 训练占比) × ln(线上占比 / 训练占比)，对每箱求和。
关键细节：

分箱必须用训练集分布确定边界，否则线上数据分箱不一致；
对于稀疏特征（如“用户最近购买品类”），改用“Top-K高频值+Other”分箱，避免Other箱占比过大失真；
PSI > 0.1为强漂移，0.05~0.1为中度，<0.05为弱漂移——但这只是起点，不是阈值。

KL散度补充校验（用于分类特征）：
KL(P||Q) = Σ P(x) × ln(P(x)/Q(x))，其中P是训练分布，Q是线上分布。
优势：对小概率事件更敏感。例如“欺诈标签”在训练集占比0.001，线上升至0.003，PSI可能只有0.02（因绝对值小），但KL散度达0.69，明确提示正样本分布剧变。

业务规则过滤：

时间维度：排除节假日、大促日、系统维护窗口的数据；
流量维度：区分新老用户、APP/Web/H5端，因各渠道用户行为差异天然存在；
业务事件：接入公司事件日历API，自动屏蔽“竞品发布会次日”等已知扰动期。

阈值动态校准：
我们不设固定PSI阈值，而是用滑动窗口：过去30天PSI的P95值作为当前基线，新PSI > 基线×1.5才告警。这样既防噪声，又保灵敏。

注意：监控不是目的，行动才是。每次PSI告警，必须关联到“特征负责人”，并在1小时内输出《漂移根因报告》，包含：上游数据源变更日志、ETL脚本diff、业务影响评估。没有报告，告警自动升级。

3.3 模型迭代实验：AB测试的四个反常识设计

AB测试常被简化为“50%流量给A，50%给B”，但在ML场景，这四点反常识设计决定成败：

流量分桶不按哈希，而按业务实体ID：
用user_id % 100分桶，而非请求ID。原因：保证同一用户的所有请求始终进入同一实验组，避免“今天看到A推荐，明天看到B推荐”的体验割裂。某社交App曾因此导致用户留存率下降12%，因算法反复“忘记”用户偏好。
对照组（Control）必须是“当前线上最优”：
绝不设“无模型”或“随机推荐”为对照组。对照组必须是当前正在服务的模型v2.2.1。否则，你无法回答：“v2.3.1比现在的好多少？” 只能回答：“v2.3.1比随机好多少？”——后者毫无业务意义。
指标选择必须包含“负向护栏”：
除主指标（如CTR、转化率），必须设定负向指标：
- avg_session_duration_delta：用户停留时长变化，防“标题党”式短期点击；
- return_rate_7d：7日内重复访问率，防推荐同质化；
- support_ticket_rate：客服投诉率，防模型输出引发用户困惑。
  曾有推荐模型提升CTR 5%，但support_ticket_rate飙升200%，因模型把用户误标为“高价值”后推送高价商品，引发大量客诉。
实验终止不看p值，而看业务显著性：
不设固定实验周期（如7天）。我们用贝叶斯方法计算：P(v2.3.1_CTR > v2.2.1_CTR | data) > 0.95 且 绝对提升 > 0.3% 时终止。0.3%是业务方确认的“值得投入工程资源上线”的最小收益。避免“统计显著但业务无关”的假阳性。

实操心得：AB测试平台不是技术组件，是协作契约。我们强制要求：实验创建时，必须填写《业务影响声明》，由产品、运营、法务三方电子签批。没有签批，实验无法启动。这倒逼所有人想清楚：“你到底想验证什么？失败了怎么办？”

4. 实操过程与核心环节实现：从零搭建一个可落地的Part 4级ML服务

4.1 环境准备：用Docker Compose模拟生产最小闭环

不从K8s起步，先用Docker Compose搭出可验证的最小闭环。以下是我们验证过的docker-compose.yml核心片段（已剔除无关服务，专注ML服务链路）：

YAML

version: '3.8'

services:

ml-api:

build: ./ml_api

ports:

- "8000:8000"

environment:

- MODEL_VERSION=v2.3.1

- FEATURE_SERVICE_URL=http://feature-svc:8000

- CONSUL_URL=http://consul:8500

depends_on:

- feature-svc

- consul

# 关键：资源限制，模拟生产约束

deploy:

resources:

limits:

memory: 4G

cpus: '2.0'

reservations:

memory: 2G

cpus: '0.5'

feature-svc:

image: python:3.9-slim

volumes:

- ./features:/app/features

command: python -m features.server

ports:

- "8000:8000"

# 特征服务也限资源，防拖垮

deploy:

resources:

limits:

memory: 2G

consul:

image: consul:1.15

command: "agent -server -bootstrap-expect=1 -client=0.0.0.0 -ui -bind=0.0.0.0"

ports:

- "8500:8500"

- "8600:8600/udp"

prometheus:

image: prom/prometheus:latest

volumes:

- ./prometheus.yml:/etc/prometheus/prometheus.yml

ports:

- "9090:9090"

prometheus.yml关键配置（监控ML服务核心指标）：

YAML

scrape_configs:

- job_name: 'ml-api'

static_configs:

- targets: ['ml-api:8000']

metrics_path: '/metrics' # 我们暴露的Prometheus指标端点

# 抓取间隔缩短，适应ML服务快速变化

scrape_interval: 15s

# 额外抓取GPU指标（需nvidia-docker）

- job_name: 'gpu-metrics'

static_configs:

- targets: ['localhost:9400'] # node-exporter + gpu插件

为什么从Compose开始？

快速验证服务间调用、健康检查、配置注入是否work；
本地复现生产资源约束（内存/CPU限制），提前暴露OOM或CPU争抢；
所有配置即代码，开发、测试、预发环境完全一致。
我坚持：没在Compose里跑通的ML服务，不配谈K8s。曾有个团队跳过这步，直接上K8s，结果发现特征服务DNS解析失败，排查三天——而Compose里docker-compose logs feature-svc一眼看出是/etc/resolv.conf被覆盖。

4.2 模型服务代码：一个生产就绪的FastAPI骨架

以下是ml_api/main.py的核心骨架（已精简，仅保留Part 4关键逻辑）：

PYTHON

from fastapi import FastAPI, HTTPException, Depends, BackgroundTasks

from pydantic import BaseModel

import torch

import logging

from typing import Dict, Any, List

import time

import psutil

from prometheus_client import Counter, Histogram, Gauge

# 初始化Prometheus指标

REQUEST_COUNT = Counter('ml_api_requests_total', 'Total requests', ['endpoint', 'status'])

REQUEST_LATENCY = Histogram('ml_api_request_latency_seconds', 'Request latency')

GPU_MEMORY_USAGE = Gauge('ml_api_gpu_memory_bytes', 'GPU memory usage')

app = FastAPI(title="ML Production API", version="v2.3.1")

# 全局模型加载（单例）

class ModelManager:

def __init__(self):

self.model = None

self.feature_pipeline = None

self.last_reload_time = 0

self._lock = threading.Lock()

def load_model(self, version: str):

with self._lock:

if self.model and self.last_reload_time > time.time() - 300: # 5分钟内不重复加载

return

# 加载模型权重（此处省略具体加载逻辑）

self.model = torch.load(f"/models/{version}/model.pt")

self.feature_pipeline = load_feature_pipeline(f"/models/{version}/pipeline.pkl")

self.last_reload_time = time.time()

logging.info(f"Model {version} reloaded at {self.last_reload_time}")

model_manager = ModelManager()

# 依赖注入：确保每次请求都用最新模型

async def get_model():

model_manager.load_model(app.state.MODEL_VERSION)

return model_manager.model

# 健康检查端点（Part 4核心）

@app.get("/health/live")

async def live_health():

try:

# 1. 模型加载检查

if not model_manager.model:

raise Exception("model not loaded")

# 2. GPU显存检查

if torch.cuda.is_available():

mem_used = torch.cuda.memory_reserved()

mem_total = torch.cuda.get_device_properties(0).total_memory

if mem_used / mem_total > 0.85:

raise Exception(f"GPU memory usage {mem_used/mem_total:.2%} > 85%")

# 3. 特征服务连通性

import requests

resp = requests.get("http://feature-svc:8000/health", timeout=2)

if resp.status_code != 200:

raise Exception("feature service unhealthy")

return {"status": "ok", "timestamp": time.time()}

except Exception as e:

logging.error(f"Live health check failed: {e}")

raise HTTPException(status_code=503, detail=str(e))

# 主推理端点

@app.post("/predict")

async def predict(request: Dict[str, Any], background_tasks: BackgroundTasks):

start_time = time.time()

REQUEST_COUNT.labels(endpoint="/predict", status="started").inc()

try:

# 输入校验（业务规则）

if not request.get("user_id"):

raise HTTPException(status_code=400, detail="user_id required")

# 特征工程（调用特征服务）

features = await call_feature_service(request)

# 模型推理

with torch.no_grad():

input_tensor = torch.tensor(features).float().to("cuda" if torch.cuda.is_available() else "cpu")

output = model_manager.model(input_tensor).cpu().numpy()

# 记录指标

latency = time.time() - start_time

REQUEST_LATENCY.observe(latency)

GPU_MEMORY_USAGE.set(torch.cuda.memory_reserved() if torch.cuda.is_available() else 0)

# 异步记录审计日志（防阻塞）

background_tasks.add_task(log_audit, request, output, latency)

return {"prediction": output.tolist(), "latency_ms": int(latency*1000)}

except Exception as e:

REQUEST_COUNT.labels(endpoint="/predict", status="error").inc()

logging.error(f"Prediction error: {e}")

raise HTTPException(status_code=500, detail="Internal server error")

# 审计日志异步任务

def log_audit(request, output, latency):

# 写入审计日志（如Kafka），包含request_id、输入特征摘要、输出、耗时

pass

关键设计说明：

live_health端点是服务存活的“心跳”，它检查的不是进程是否存在，而是服务是否具备完整功能；
get_model依赖注入确保模型热更新时，新请求自动使用新模型，旧请求不受影响；
BackgroundTasks将审计日志异步化，避免IO阻塞主线程；
所有指标（请求量、延迟、GPU显存）直连Prometheus，为后续监控告警打基础。
这段代码不是Demo，是我们在三个项目中迭代出的生产骨架。它不追求“最优雅”，只追求“最可靠”。

4.3 监控告警配置：用Prometheus+Alertmanager实现主动防御

监控不是“看大盘”，而是“建哨所”。我们的Prometheus告警规则（alerts.yml）聚焦Part 4三大风险：

YAML

groups:

- name: ml-api-alerts

rules:

# 1. 服务存活告警（5分钟无健康检查通过）

- alert: MLAPILivenessDown

expr: probe_success{job="ml-api"} == 0

for: 5m

labels:

severity: critical

annotations:

summary: "ML API liveness check failed"

description: "Health check /health/live has been failing for 5 minutes. Check model loading, GPU, or feature service."

# 2. 数据漂移告警（PSI突增）

- alert: FeaturePSISpike

expr: (feature_psi{feature="age"} - avg_over_time(feature_psi{feature="age"}[7d])) / avg_over_time(feature_psi{feature="age"}[7d]) > 0.5

for: 1h

labels:

severity: warning

annotations:

summary: "PSI for feature 'age' spiked {{ $value | humanize }}"

description: "PSI increased by >50% vs 7-day average. Check upstream data source."

# 3. GPU显存泄漏告警

- alert: GPUMemoryLeak

expr: delta(gpu_memory_bytes{device="0"}[1h]) > 1e9

for: 30m

labels:

severity: critical

annotations:

summary: "GPU memory leak detected on device 0"

description: "Memory usage increased by >1GB in last hour. Possible Python object leak."

# 4. AB测试效果异常（主指标下跌）

- alert: ABTestCTRDrop

expr: avg_over_time(ab_test_ctr{group="treatment"}[24h]) / avg_over_time(ab_test_ctr{group="control"}[24h]) < 0.95

for: 1h

labels:

severity: warning

annotations:

summary: "Treatment group CTR is 5% lower than control"

description: "Check model quality, feature pipeline, or traffic routing."

Alertmanager配置要点：

告警分组：将同一服务的告警（如MLAPILivenessDown和GPUMemoryLeak）合并为一条通知，避免告警风暴；
静默期：对已知维护窗口（如每周二凌晨2-4点模型重训），配置静默规则；
通知渠道：Critical告警发企业微信+电话，Warning发邮件+钉钉，确保有人看、看得见、来得及。

实操心得：告警规则不是写完就扔。我们每月做一次“告警回顾会”：

哪些告警从未触发？（说明阈值太松或监控无效，删除）

哪些告警频繁误报？（说明阈值太紧或业务逻辑变了，调整）

哪些告警触发后没人处理？（说明责任不明确或处置流程缺失，补SOP）
告警系统必须进化，否则就是噪音制造机。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “模型明明跑通了，但线上延迟高得离谱”——GPU显存碎片化实录

现象：模型服务刚启动时P95延迟200ms，运行12小时后飙升至2.3秒，nvidia-smi显示显存占用95%，但torch.cuda.memory_allocated()只显示60%。
排查过程：

nvidia-smi --query-compute-apps=pid,used_memory --format=csv 查看各进程显存占用，发现多个Python进程残留；
torch.cuda.memory_summary() 输出显存分配详情，发现allocated低但reserved高，典型碎片化；
cat /proc/[pid]/maps | grep 'cuda' 查看CUDA内存映射，发现大量小块[anon]区域。
根因：PyTorch默认分配器在频繁小tensor创建/销毁时产生碎片，且不自动合并。
解决：

启动时加环境变量：export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128（强制合并小块）；
服务内定期调用：torch.cuda.empty_cache()（注意：只清空未被引用的缓存，不影响正在运行的推理）；
关键：在预测函数末尾加del tensor; gc.collect()，显式释放中间变量。
避坑技巧：不要依赖empty_cache()自动清理。我们写了个守护线程，每5分钟检查torch.cuda.memory_reserved() / total > 0.9，超则强制empty_cache()。

5.2 “AB测试结果矛盾：A组CTR高，但GMV低”——流量污染实录

现象：推荐模型AB测试，Treatment组CTR+3.2%，但GMV-1.8%，业务方质疑模型“骗点击”。
排查过程：

检查流量分桶逻辑：user_id % 100，确认无哈希碰撞；
抽样对比A/B组用户画像：发现Treatment组新用户占比高15%（因新用户注册高峰恰逢实验开启）；
进一步分析：新用户CTR天然高（对新鲜内容好奇），但转化率低（无购买历史）。
根因：流量分桶未考虑“用户生命周期阶段”，导致A/B组用户结构不均衡。
解决：

改用分层抽样：先按user_lifecycle（新/活跃/沉睡）分层，再在每层内随机分桶；
实验启动前，用卡方检验确保A/B组各层用户比例无显著差异（p>0.05）。
避坑技巧：AB测试前必做“流量基线校验”。我们写了个脚本，自动拉取实验前1小时数据，对比A/B组的user_age, session_count_7d, avg_order_value等10个核心维度，任一维度p<0.01即暂停实验。

5.3 “模型更新后，部分用户预测结果完全不变”——特征缓存穿透实录

现象：模型v2.3.1上线后，约5%用户预测结果与v2.2.1完全一致，日志显示其特征向量未更新。
排查过程：

查特征服务日志：发现对这些用户，特征服务返回cache_hit: true，但缓存值是v2.2.1时代的；
检查缓存Key：f"feat_{user_id}_{model_version}"，但代码里model_version取的是环境变量，未随模型更新同步；
进一步发现：特征服务缓存Key未包含model_version，只含user_id。
根因：特征缓存Key设计缺陷，未绑定模型版本，导致新模型读取旧缓存。
解决：

特征服务缓存Key强制包含model_version：f"feat_{user_id}_{model_version}"；
模型更新时，自动触发缓存清理：redis.delete_pattern(f"feat_{user_id}_*")。
避坑技巧：所有缓存Key必须包含“影响其有效性的所有变量”。我们建立缓存Key审查清单：
是否含数据源版本？
是否含模型版本？
是否含业务规则版本（如风控策略号）？
缺一不可。

5.4 “监控告警天天响，但没人理”——告警疲劳实录

现象：PSI告警每天触发20+次，运维已设置免打扰，告警系统形同虚设。
排查过程：

分析告警日志：发现90%告警来自“节假日流量波动”，如春节假期“下单时段”特征PSI必然超标；
查看告警配置：阈值为固定PSI>0.1，未排除业务已知扰动。
根因：告警未与业务知识结合，把“已知噪声”当“未知风险”。
解决：

告警规则加入业务上下文：feature_psi{feature="order_hour"} > 0.15 and on() group_left() (holiday_flag == 1) == 0（仅当非节假日触发）；
建立“告警白名单”：对已知合理漂移（如新品上市导致“品类偏好”PSI升高），配置alert: ignore标签。
避坑技巧：告警必须有“可操作性”。每条告警规则旁，必须附带《处置手册》链接，明确：
第一步做什么？（如“检查上游ETL日志”）
第二步找谁？（如“联系数据平台组@张三”）
第三步怎么验证修复？（如“重新计算PSI，确认<0.05”）
没有处置手册的告警，就是垃圾信息。

5.5 “模型服务突然OOM，但日志没报错”——Python内存泄漏实录

现象：ML服务Pod内存持续增长，从2G升至4G后被K8s OOMKilled，日志无ERROR。
排查过程：

kubectl top pods 确认内存增长；
kubectl exec -it [pod] -- python -c "import gc; print(gc.get_stats())"