Notebook到生产环境的ML模型部署实战：7个致命细节与防御体系

1. 项目概述：这不是一次“部署上线”，而是一场从实验室到产线的系统性迁移

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被日常讨论轻描淡写带过的重量。它不是教你怎么把一个.pkl模型文件扔进Flask接口里跑通，也不是演示如何用Docker打包后docker run -p 5000:5000就宣告胜利。它直指机器学习工程中最常被回避、最易被低估、也最容易在交付前夜崩盘的核心命题：当模型离开Jupyter的舒适区，进入7×24小时无人值守、日均请求数万、数据漂移频发、运维权限受限、监控告警沉默、业务方随时打电话问“为什么推荐错了”的真实生产环境时，你靠什么守住底线？

我做过12个从0到1落地的ML项目，其中7个在上线后3个月内因“不可解释的性能衰减”或“偶发性服务超时”被临时下线；有3个在灰度阶段因特征计算逻辑与离线训练不一致，导致A/B测试结果完全失真；还有2个至今仍在“准生产”状态反复拉锯——不是模型不行，是整个交付链路缺了关键几环。Part 4之所以重要，正因为它不再谈模型本身，而是聚焦于模型生命周期中那个最脆弱、最沉默、也最决定成败的断层带：从Notebook验证完成，到第一个真实用户请求命中模型服务之间的那200米。这200米里没有算法公式，只有版本控制策略、特征一致性校验、服务健康水位定义、降级开关设计、可观测性埋点粒度、以及——最关键的——谁在凌晨三点收到告警后能真正看懂日志里的那行KeyError: 'user_last_7d_avg_session_duration'。

这篇文章面向三类人：一是刚跑通train.py和predict.py、正准备向Leader汇报“模型ready”的算法工程师；二是被业务方催着“快上模型提升转化率”，却对模型服务稳定性毫无掌控感的MLOps初级实践者；三是技术负责人，需要在资源有限的前提下，判断该为模型服务投入多少基建成本才不算“过度设计”。它不提供银弹，但会拆解出你在真实产线中必须亲手填平的每一个坑——不是理论推演，而是我踩过、修过、复盘过的真实路径。

2. 内容整体设计与思路拆解：为什么“Notebook to Production”不是单点技术问题？

2.1 核心矛盾的本质：开发范式与运行范式的根本错配

Jupyter Notebook的本质是探索式、交互式、状态依赖型的开发环境。你可以在Cell 1里import pandas as pd，Cell 5里df = pd.read_csv('data.csv')，Cell 12里model.fit(df)，然后Cell 18里model.predict(df.iloc[0:1])——所有中间变量都驻留在内存里，路径是相对当前notebook位置的，随机种子在Cell 3里设了一次就全局生效。这种模式极大提升了研究效率，但它与生产环境的确定性、可重现性、无状态性、隔离性要求完全相悖。

提示：生产服务不能接受“上次运行成功是因为我手动清空了缓存变量”，也不能容忍“模型预测结果随服务器时间戳变化而波动”。

因此，“Notebook to Production”的第一道关卡，从来不是“怎么部署”，而是如何将探索过程中的隐式依赖显性化、固化、并验证其在隔离环境下的行为一致性。Part 4的设计起点，就是围绕这个核心矛盾展开的四层防御体系：

1. 代码层防御：剥离Notebook中所有与探索强耦合的代码（如%matplotlib inline、print(df.head())、!pip install），将核心逻辑重构为纯函数式模块，强制输入输出契约；
2. 数据层防御：建立特征计算的“单一可信源”（Single Source of Truth），确保训练时用的user_last_7d_avg_session_duration，和服务时计算的，是同一段SQL/PySpark逻辑、同一套时间窗口定义、同一份基础表血缘；
3. 服务层防御：放弃“一个API端点包打天下”的粗放模式，按SLA分级设计服务形态——高可用核心路径用gRPC+Protobuf保障序列化效率与类型安全，低频调试路径用REST+JSON提供可读性；
4. 观测层防御：不满足于“CPU<70%、内存<80%”的基础设施监控，而是将监控指标下沉到模型推理的语义层——例如p95_latency_by_model_version、feature_null_rate_by_column、prediction_drift_score_weekly。

这套设计不是为了炫技，而是源于一个血泪教训：我在某电商推荐项目中，曾因未做数据层防御，导致线上服务调用的特征计算SQL漏掉了WHERE dt >= '2023-01-01'的时间过滤条件，结果用全量历史数据实时计算用户兴趣，单次请求耗时从120ms飙升至8.3s，触发熔断后业务方投诉“推荐系统拖垮了整个APP”。

2.2 方案选型背后的现实权衡：为什么不用Kubeflow？为什么坚持自建轻量调度？

市面上有大量MLOps平台方案：Kubeflow Pipelines、MLflow、SageMaker Pipelines、Vertex AI……它们功能强大，但落地时面临三个硬约束：

• 团队能力水位：一个5人算法团队，若要求全员掌握Kubeflow的Argo Workflows编排语法、K8s RBAC策略配置、以及自定义TFJob Operator的调试方法，学习成本远超项目周期承受力；
• 基础设施现状：客户已有稳定运行3年的Airflow集群用于ETL调度，强行引入K8s生态意味着要额外维护etcd、CoreDNS、CNI插件等组件，运维复杂度指数级上升；
• 迭代速度需求：业务方要求“模型每周迭代一次”，而Kubeflow Pipeline的CI/CD流水线配置平均需4人日，无法匹配敏捷节奏。

因此，Part 4采用的是一套“务实分层”架构：

• 底层调度：复用现有Airflow，通过PythonOperator封装模型训练任务，用BashOperator调用Docker构建命令，避免重复造轮子；
• 中间件抽象：自研轻量级ModelRegistry服务（基于PostgreSQL），仅管理模型二进制、元数据（训练数据版本、特征schema哈希、评估指标）、部署状态，不碰调度逻辑；
• 服务网关：用Nginx做反向代理+路由分发，将/v1/recommend流量导向最新Stable版本，/v1/recommend?version=20231001指向灰度版本，降低服务发现复杂度。

这个选择背后没有技术优越性宣言，只有一句大实话：在资源有限的现实世界里，能快速验证、快速修复、快速回滚的方案，永远比“理论上更先进”的方案更有生产力。我见过太多团队花3个月搭建Kubeflow平台，结果第一个模型上线时发现特征存储组件不兼容客户Hive版本，最终还是退回了脚本化部署。

2.3 影响范围分析：一次成功的迁移，改变的是整个团队的工作契约

“Notebook to Production”成功与否，影响远超技术栈本身。它实质上重新定义了算法、工程、数据、产品四个角色之间的协作契约：

• 对算法工程师：不能再以“模型AUC提升0.5%”作为交付终点，必须同步交付feature_schema.json、inference_contract.md（明确定义输入字段类型、取值范围、缺失值处理方式）、以及drift_detection_config.yaml（指定哪些特征需监控分布偏移）；
• 对后端工程师：从“接API文档写接口”升级为“共建服务SLA”，需共同定义max_request_size、timeout_ms、retry_policy，并在代码中实现fallback_to_popular_items()这样的业务降级逻辑；
• 对数据工程师：特征计算不再只是“跑完SQL就交差”，必须为每个特征生成data_lineage_report，标注上游表更新频率、ETL任务SLA、以及该特征在模型中的Shapley值贡献度；
• 对产品经理：需理解“模型不是静态规则引擎”，接受“推荐结果存在合理波动区间”，并在需求文档中明确标注“此功能在数据漂移检测触发后，将自动切换至冷启动策略，预计CTR下降15%-20%”。

这种契约重构带来的阵痛是真实的。我在某金融风控项目中，算法团队最初拒绝提供inference_contract.md，认为“太繁琐”，结果上线后因前端传入的user_age字段为字符串而非整数，服务直接抛出ValueError，而监控告警只显示“HTTP 500”，运维同学花了2小时才定位到是类型错误——这份契约文档，本质是给所有人装上的“防呆说明书”。

3. 核心细节解析与实操要点：从Notebook剥离的7个致命细节

3.1 细节一：随机种子的“全局污染”陷阱与隔离方案

Notebook中常见写法：

# Cell 1 import numpy as np import torch np.random.seed(42) torch.manual_seed(42) # Cell 5 model = train_model(X_train, y_train) # 内部调用np.random.choice()

问题在于：np.random.seed(42)设置的是全局随机状态，一旦服务进程启动后接收多个并发请求，不同请求的随机操作（如采样、Dropout）会相互干扰，导致结果不可重现。更隐蔽的是，某些第三方库（如scikit-learn的RandomForestClassifier）在初始化时会读取全局np.random状态，但你的服务代码可能并未显式调用seed()。

实操方案：

• 在模型加载时，为每个模型实例创建独立的随机数生成器（RNG）：

  class ProductionModel: def __init__(self, model_path): self.model = joblib.load(model_path) # 创建独立RNG，避免全局污染 self.rng = np.random.default_rng(seed=42) def predict(self, X): # 所有随机操作使用self.rng if hasattr(self.model, 'sample'): return self.model.sample(X, random_state=self.rng) return self.model.predict(X)

• 对PyTorch模型，在forward()中显式传递torch.Generator：

  def forward(self, x): generator = torch.Generator(device=x.device).manual_seed(42) x = F.dropout(x, p=0.1, training=self.training, generator=generator) return self.classifier(x)

注意：不要在__init__中调用torch.manual_seed()！这会污染全局状态。务必使用torch.Generator实例。

3.2 细节二：路径硬编码的“本地幻觉”与环境感知改造

Notebook中典型路径：

# Cell 3 MODEL_PATH = "./models/best_xgboost.pkl" FEATURE_CONFIG = "../configs/feature_v2.yaml"

当代码被打包进Docker镜像后，./指向容器内工作目录，而../configs/可能根本不存在。更糟的是，不同环境（开发/测试/生产）需要不同的配置路径。

实操方案：

• 强制使用环境变量驱动路径：

  import os from pathlib import Path # 定义基路径 BASE_DIR = Path(os.getenv("MODEL_BASE_DIR", "/app")) MODEL_PATH = BASE_DIR / "models" / os.getenv("MODEL_VERSION", "latest") / "model.pkl" CONFIG_PATH = BASE_DIR / "configs" / f"feature_{os.getenv('FEATURE_VERSION', 'v1')}.yaml"

• Dockerfile中注入环境变量：

  FROM python:3.9-slim ENV MODEL_BASE_DIR=/app ENV MODEL_VERSION=20231001 ENV FEATURE_VERSION=v2 COPY . /app WORKDIR /app

3.3 细节三：依赖版本的“隐式锁定”与可重现性保障

Notebook中常出现：

# Cell 2 !pip install scikit-learn==1.2.2 !pip install xgboost==1.7.5

问题：pip install命令未记录到requirements.txt，且不同Python小版本（3.8/3.9/3.10）下，相同包版本可能有ABI不兼容。线上服务用Python 3.10，而开发机是3.8，xgboost==1.7.5在3.10下需重新编译，耗时且易失败。

实操方案：

• 使用pip-tools生成锁文件（非pip freeze）：

  # requirements.in 列出顶层依赖 scikit-learn>=1.2.0,<1.3.0 xgboost>=1.7.0,<1.8.0 # 生成精确锁文件 pip-compile requirements.in --output-file=requirements.txt

• Docker构建时严格按锁文件安装：

  COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt

3.4 细节四：特征计算的“时空错位”与血缘对齐

这是最致命的细节。Notebook中特征计算逻辑：

# Cell 8: 计算用户7天平均会话时长 user_features = ( raw_logs .filter(col("event_time") >= "2023-09-25") # 硬编码日期 .groupBy("user_id") .agg(avg("session_duration").alias("user_last_7d_avg_session_duration")) )

而线上服务用的SQL：

SELECT user_id, AVG(session_duration) as user_last_7d_avg_session_duration FROM logs WHERE event_time >= DATE_SUB(CURRENT_DATE, 7) -- 动态计算 GROUP BY user_id

表面看都是“最近7天”，但DATE_SUB(CURRENT_DATE, 7)在每天0点执行，而Notebook训练用的是固定日期切片，导致特征分布系统性偏移。

实操方案：

• 特征计算逻辑必须统一托管在数据仓库，Notebook仅通过read_table("feature_store.user_7d_stats")读取；
• 服务端调用特征时，传入as_of_date参数，由特征服务动态拼接SQL：

  def get_user_features(user_ids: List[str], as_of_date: str) -> pd.DataFrame: # 构造参数化SQL sql = f""" SELECT user_id, AVG(session_duration) as user_last_7d_avg_session_duration FROM logs WHERE event_time >= DATE_SUB('{as_of_date}', 7) AND user_id IN ({','.join([f"'{uid}'" for uid in user_ids])}) GROUP BY user_id """ return spark.sql(sql).toPandas()

• 每次模型训练时，记录as_of_date到training_metadata表，服务端调用时必须使用相同日期。

3.5 细节五：日志的“信息黑洞”与结构化埋点

Notebook中日志：

# Cell 15 print(f"Prediction for user {user_id}: {pred}")

线上服务中，这行print会被重定向到stdout，混在K8s日志流中，无法按user_id检索，也无法区分是INFO还是ERROR。

实操方案：

• 使用结构化日志库（如structlog），强制输出JSON：

  import structlog logger = structlog.get_logger() def predict_handler(request): try: user_id = request.json["user_id"] pred = model.predict(user_id) logger.info("prediction_success", user_id=user_id, prediction=pred, model_version="20231001", latency_ms=int((time.time()-start)*1000)) return {"prediction": pred} except Exception as e: logger.error("prediction_failed", user_id=user_id, error_type=type(e).__name__, error_msg=str(e)) raise

• 日志采集端（如Filebeat）配置JSON解析，将user_id、model_version等字段提取为Elasticsearch的独立字段，支持Kibana中按user_id: "U12345"精准检索。

3.6 细节六：模型输入的“宽容陷阱”与契约式校验

Notebook中假设输入干净：

# Cell 10 def predict(user_profile: dict) -> float: features = [user_profile["age"], user_profile["income"]] return model.predict([features])[0]

线上服务收到{"age": "25", "income": null}，直接TypeError崩溃。

实操方案：

• 在服务入口层做强契约校验（使用pydantic）：

  from pydantic import BaseModel, Field, validator class PredictionRequest(BaseModel): user_id: str = Field(..., min_length=1) age: int = Field(..., ge=0, le=120) income: float = Field(..., ge=0.0) @validator('age') def age_must_be_int(cls, v): if not isinstance(v, int): raise ValueError('age must be integer') return v @app.post("/v1/predict") def predict(request: PredictionRequest): # 此处request已确保age是int，income是float features = [request.age, request.income] return {"score": model.predict([features])[0]}

• 校验失败时返回标准错误码422 Unprocessable Entity及详细字段错误信息，前端可据此提示用户修正输入。

3.7 细节七：服务健康的“伪阳性”与多维水位定义

传统监控只看HTTP 200 Rate > 99.5%，但模型服务健康需多维定义：

实操方案：

• 在服务中暴露/healthz端点，聚合多维检查：

  @app.get("/healthz") def health_check(): checks = { "http_ok": check_http_ok(), "latency_ok": check_latency_p95(), "drift_ok": check_drift_score(), "null_rate_ok": check_feature_null_rate() } status = "ok" if all(checks.values()) else "degraded" return {"status": status, "details": checks}

• Prometheus抓取/healthz，Grafana配置多状态面板，点击drift_ok: false可直接跳转到漂移分析Dashboard。

4. 实操过程与核心环节实现：一个可落地的端到端流程

4.1 环境准备：从Notebook到可部署代码的重构清单

重构不是重写，而是有章法的剥离。我用一张表定义Notebook到Production代码的映射关系，确保无遗漏：

提示：重构时，我习惯用# TODO: PRODUCTION标记Notebook中待迁移的Cell，在迁移完成后删除标记。这比凭记忆追踪更可靠。

4.2 Docker镜像构建：最小化、可验证、可审计

Dockerfile不是技术展示，而是生产环境的“契约声明”。我的标准模板如下：

# 使用多阶段构建，分离构建与运行环境 FROM python:3.9-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir pip-tools && \ pip-compile requirements.in --output-file=requirements.txt RUN pip install --no-cache-dir -r requirements.txt FROM python:3.9-slim # 设置非root用户，符合安全基线 RUN addgroup -g 1001 -f mlgroup && adduser -S mluser -u 1001 USER mluser WORKDIR /app # 复制构建好的依赖和代码 COPY --from=builder /usr/local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages COPY --chown=mluser:mlgroup . . # 声明环境变量，强制使用者配置 ENV MODEL_BASE_DIR=/app ENV MODEL_VERSION=latest ENV FEATURE_VERSION=v1 ENV LOG_LEVEL=INFO # 健康检查，确保服务能启动 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8000/healthz || exit 1 EXPOSE 8000 CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "api.app:app"]

关键验证步骤：

• 构建后检查镜像大小：docker images | grep my-model，应≤350MB（Slim基础镜像+依赖+代码）；
• 运行容器并验证健康检查：docker run -d -p 8000:8000 --name test my-model && docker ps，等待30秒后docker inspect test | grep Health确认状态为healthy；
• 手动进入容器验证路径：docker exec -it test sh -c "ls -l /app/models/latest/"，确认model.pkl存在且权限为-rw-r--r--。

4.3 CI/CD流水线：从Git Push到服务就绪的5分钟闭环

我们用GitHub Actions实现全自动发布，核心是“三不原则”：不人工干预、不跨环境拷贝、不跳过验证。

name: Deploy Model Service on: push: branches: [main] paths: - 'src/**' - 'requirements.in' jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.9' - name: Install dependencies run: | python -m pip install --upgrade pip pip install pip-tools - name: Compile requirements run: pip-compile requirements.in --output-file=requirements.txt - name: Run unit tests run: pytest tests/ --cov=src/ --cov-report=term-missing - name: Build Docker image run: docker build -t ${{ secrets.REGISTRY }}/my-model:${{ github.sha }} . deploy-to-staging: needs: build-and-test runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' steps: - name: Login to Container Registry uses: docker/login-action@v2 with: registry: ${{ secrets.REGISTRY }} username: ${{ secrets.REGISTRY_USERNAME }} password: ${{ secrets.REGISTRY_PASSWORD }} - name: Push to Registry run: | docker tag ${{ secrets.REGISTRY }}/my-model:${{ github.sha }} ${{ secrets.REGISTRY }}/my-model:staging docker push ${{ secrets.REGISTRY }}/my-model:staging - name: Deploy to Staging Cluster run: | # 使用kubectl patch滚动更新 kubectl patch deployment model-service-staging -p \ "{\"spec\":{\"template\":{\"spec\":{\"containers\":[{\"name\":\"model\",\"image\":\"${{ secrets.REGISTRY }}/my-model:staging\"}]}}}}"

流水线设计要点：

• 测试先行：pytest必须覆盖所有features/compute.py函数，特别是边界情况（如as_of_date为周末、空数据集）；
• 镜像唯一性：使用github.sha作为镜像Tag，确保每次Push对应唯一可追溯镜像；
• 零停机发布：kubectl patch触发K8s滚动更新，新Pod就绪后才终止旧Pod，/healthz探针确保新Pod真正可用。

4.4 服务部署与灰度发布：用Nginx实现低成本金丝雀

不依赖复杂Service Mesh，用Nginx实现精准流量切分：

upstream model_stable { server model-service-stable:8000 max_fails=3 fail_timeout=30s; } upstream model_canary { server model-service-canary:8000 max_fails=3 fail_timeout=30s; } server { listen 80; location /v1/predict { # 10%流量导给灰度版本（按请求头X-User-ID哈希） set $canary 0; if ($http_x_user_id ~ "^U[0-9]{5}$") { set $hash_val $http_x_user_id; } if ($hash_val) { set $hash_mod $hash_val; # 简单哈希：取ID最后一位，0-9中0-1为灰度 if ($hash_mod ~ "[01]$") { set $canary 1; } } if ($canary = 1) { proxy_pass http://model_canary; } if ($canary = 0) { proxy_pass http://model_stable; } } }

灰度发布Checklist：

• ✅ 监控面板已配置p95_latency_by_upstream，确认灰度组延迟不劣于稳定组；
• ✅prediction_drift_score指标在灰度组中连续2小时<0.1；
• ✅ 业务方已确认灰度用户群（如VIP用户）无负面反馈；
• ✅ 执行kubectl scale deployment model-service-canary --replicas=10将灰度比例提升至50%；
• ✅ 全量发布前，执行kubectl rollout history deployment model-service-stable确认回滚版本可用。

4.5 观测性建设：从“有没有日志”到“能不能归因”

观测性不是堆监控工具，而是建立“问题-指标-日志-链路”的归因闭环。我的最小可行方案：

• 指标（Metrics）：用Prometheus采集prediction_requests_total{model_version, status_code}、prediction_latency_seconds_bucket；
• 日志（Logs）：用Loki收集结构化JSON日志，标签{service="model-api", version="20231001"}；
• 链路（Tracing）：用Jaeger记录/v1/predict请求的完整Span，包括feature_fetch、model_inference、postprocess子Span；

归因实战示例：
当p95_latency突增时：

1. Grafana中点击prediction_latency_seconds_bucket图表，下钻到le="0.3"的rate()曲线；
2. 发现model_version="20231001"的曲线尖峰，而20230925平稳；
3. 切换到Loki，搜索{service="model-api", version="20231001"} | json | duration_ms > 300；
4. 发现日志中高频出现WARNING feature_fetch took 280ms；
5. 切换到Jaeger，筛选model_version=20231001的Trace，发现feature_fetchSpan中db_query子Span耗时275ms；
6. 定位到SQL：SELECT * FROM user_features WHERE user_id IN (...)未加索引，优化CREATE INDEX idx_user_features_uid ON user_features(user_id);。

这个闭环，让故障定位从“猜”变成“查”，是我坚持投入观测性的最大动力。

5. 常见问题与排查技巧实录：那些凌晨三点教会我的事

5.1 问题一：“模型预测结果每天都不一样！”——时间相关特征的幽灵

现象：业务方反馈“今天推荐的商品和昨天完全不同”，但模型版本、代码、配置均未变更。
排查路径：

• 第一步：确认是否所有特征都与as_of_date绑定。检查features/compute.py中是否有datetime.now()或date.today()调用；
• 第二步：检查特征存储表的分区字段。某次事故中，user_features表按dt STRING分区，但查询SQL写成WHERE dt = '2023-10-01'，而实际分区是dt='20231001'（无横杠），导致全表扫描；
• 第三步：验证特征服务的as_of_date参数传递。发现API网关在转发时，将?as_of_date=2023-10-01的URL参数丢弃，改用服务内部datetime.utcnow().date()，造成时间错位。

根治方案：

• 在特征计算函数开头强制校验as_of_date格式：

  from datetime import datetime def compute_user_features(as_of_date: str): try: datetime.strptime(as_of_date, "%Y-%m-%d") except ValueError: raise ValueError(f"Invalid as_of_date format: {as_of_date}, expected YYYY-MM-DD") # ... rest of logic

• 在API入口层打印as_of_date值到日志，确保可审计。

5.2 问题二：“服务突然503，但CPU和内存都很低”——连接池耗尽的静默杀手

现象：服务在流量高峰时返回503 Service Unavailable，kubectl top pods显示CPU<20%，内存<50%。
排查路径：

• kubectl describe pod <pod-name>查看Events，发现Back-off restarting failed container；
• kubectl logs <pod-name> --previous看到ConnectionRefusedError: [Errno 111] Connection refused；
• 检查代码，发现特征服务调用使用requests.Session()，但未设置pool_connections和pool_maxsize，默认10连接，而并发请求数达200；
• netstat -anp | grep :8000显示大量TIME_WAIT状态连接。

根治方案：

• 全局复用Session并配置连接池：

  import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session = requests.Session() retry_strategy = Retry( total=3, backoff_factor=1, status_forcelist=[429, 500, 502, 503, 504], ) adapter = HTTPAdapter( pool_connections=100, # 连接池大小 pool_maxsize=100, # 最大连接数 max_retries=retry_strategy ) session.mount("http://", adapter) session.mount("https://", adapter)

• 在/healthz中增加连接池健康检查：session.get("http://feature-service/healthz", timeout=2)。

5.3 问题三：“模型准确率下降了，但AUC没变？”——指标盲区的陷阱

现象：线上监控显示auc_score=0.82稳定，但业务方反馈“推荐点击率下降20%”。
排查路径：

• AUC衡量排序能力，