企业官网建设流程全解析

1. 这不是“上传模型就完事”——AI模型交付前的真实战场

很多人以为训练完一个模型，导出个.pt或.onnx文件，丢进某个框架里 run 一下，就算完成了“部署”。我带过三届 AI 训练师培训班，每届都有至少 60% 的学员卡在这一步：模型在 Jupyter Notebook 里准确率 92%，一放到生产环境就报错、OOM、延迟飙升、输出乱码，甚至根本起不来。这不是能力问题，而是对“模型管理与部署”这个环节存在系统性认知偏差——它根本不是训练的附属品，而是一条独立、严谨、需要工程化思维的交付流水线。

你看到的热搜词里反复出现的 “ollama 部署”、“ONNX 模型部署流程”、“树莓派5上部署YOLOv5”、“本地部署音频转文字AI模型”，背后全是真实场景：一个嵌入式工程师要在 4GB 内存的树莓派上跑目标检测；一个内容团队想在 Mac 上离线运行一个 7B 参数的对话模型；一个医疗 SaaS 公司需要把图像分割模型集成进现有 Web 系统，且必须满足 HIPAA 合规审计要求。这些需求，和你在 Kaggle 上调参、在 Colab 上跑 demo，完全是两个世界。

核心关键词“模型管理”和“模型部署”，拆开看是两件事，合起来才是闭环。模型管理解决的是“我有几十个版本的模型，哪个该上线？哪个在灰度？哪个已废弃？谁改的？改了什么？影响范围多大？”——这本质上是软件版本控制（Git）在 AI 领域的延伸，但比 Git 复杂得多，因为模型文件动辄几百 MB，参数结构无法 diff，性能指标又依赖特定数据集。模型部署解决的是“这个二进制文件，如何变成一个稳定、可监控、可伸缩、可回滚的网络服务？”——它不关心你用 PyTorch 还是 TensorFlow 训练，只关心你能不能提供标准 HTTP 接口、能不能承受每秒 200 次请求、能不能在 GPU 显存不足时优雅降级。

我见过最典型的错误，就是把训练环境直接当生产环境用：用torch.save(model)保存整个模型对象，然后在服务器上torch.load()加载——结果发现训练时用的 CUDA 版本和服务器不一致，或者model.eval()忘了调用，或者DataLoader里的num_workers=8在容器里直接卡死。这些坑，不是靠查文档能绕开的，是踩出来的。这篇图解，不讲抽象概念，只讲我在给制造业客户部署缺陷检测模型、给教育机构落地作文评分模型、给本地政务平台上线政策问答 Agent 过程中，真正用到的工具链、检查清单和应急方案。所有步骤，都经过至少三次不同硬件、不同框架、不同业务压力下的实测验证。

2. 模型交付包：从“一堆文件”到“可审计资产”的标准化封装

模型交付包（Model Delivery Package），是你在训练完成后、部署之前，必须亲手构建的第一个正式产物。它不是简单的model.pth + requirements.txt打个 zip 包，而是一个包含元数据、可执行逻辑、验证脚本和文档的完整资产包。它的核心目的，是让下游（运维、测试、安全审计）无需理解你的训练代码，就能独立完成部署、验证和监控。我把它称为“模型的身份证+说明书+体检报告”。

2.1 必须包含的五大核心组件

一个合格的交付包，必须包含以下五个目录，缺一不可。我用一个实际部署到边缘设备的 YOLOv8s 缺陷检测模型为例说明：

yolov8s_defect_v2.3_delivery/ ├── model/ # 模型本体（非原始训练对象） │ ├── model.onnx # ONNX 格式，跨框架通用（首选） │ ├── model.pt # 原始 PyTorch 权重（仅作备份） │ └── config.yaml # 模型超参、输入尺寸、类别映射（JSON/YAML） ├── assets/ # 推理必需的静态资源 │ ├── class_names.txt # 类别ID到名称的映射（如 0: scratch, 1: dent） │ └── preprocessor.py # 输入预处理逻辑（归一化、resize、pad等） ├── inference/ # 可执行推理逻辑（独立于训练框架） │ ├── infer.py # 主推理脚本（加载ONNX，执行推理，返回JSON） │ └── requirements.txt # 仅含推理依赖（onnxruntime, numpy, opencv-python-headless） ├── test/ # 自动化验证套件 │ ├── smoke_test.py # 快速冒烟测试（单张图，耗时<1s） │ ├── accuracy_test.py # 准确率回归测试（固定小数据集，对比基线） │ └── stress_test.py # 压力测试（模拟100并发，检查内存泄漏） └── docs/ # 人类可读文档 ├── README.md # 关键信息摘要（模型用途、输入输出格式、性能指标） └── deployment_guide.md # 针对不同环境（Docker/K8s/树莓派）的部署步骤

提示：为什么首选 ONNX 而非.pt？因为 ONNX 是模型的中间表示（IR），剥离了训练框架的实现细节。torch.save(model)保存的是 PyTorch 的内部对象序列化，强耦合于torch.__version__和torch.cuda状态；而 ONNX 是纯计算图描述，onnxruntime在 Windows/macOS/Linux/ARM64 上都能跑，且启动快、内存占用低。我实测过，同样一个 YOLOv5s 模型，PyTorch 加载需 1.2s，ONNX Runtime 加载仅需 0.18s，这对边缘设备至关重要。

2.2 元数据（Metadata）：让模型“会说话”

交付包里最常被忽略，却是管理基石的部分，是model/config.yaml和docs/README.md中的元数据。它不是写给机器看的，是写给未来可能接手你项目的同事、审计员、甚至是你自己三个月后看的。我强制要求每个交付包必须包含以下字段：

# model/config.yaml model: name: "yolov8s_defect_detection" version: "2.3" # 语义化版本号（MAJOR.MINOR.PATCH） description: "用于金属表面微小划痕与凹坑的实时检测，支持640x480输入" framework: "pytorch-2.1.0" # 训练框架及版本 export_format: "onnx-1.14" # 导出格式及版本 input_shape: [1, 3, 480, 640] # NCHW 格式，明确指定 output_schema: # 定义输出结构，供下游解析 - name: "boxes" # 边界框坐标 dtype: "float32" shape: [1, 100, 4] # [batch, max_detections, xyxy] - name: "scores" # 置信度 dtype: "float32" shape: [1, 100] - name: "classes" # 类别ID dtype: "int64" shape: [1, 100] performance: hardware: "NVIDIA Jetson Orin Nano (8GB)" # 测试环境硬件 latency_p95_ms: 42.7 # 95分位延迟（毫秒） throughput_fps: 23.5 # 每秒帧数 memory_mb: 1840 # GPU显存占用（MB） validation: dataset: "defect_test_v2.1" # 测试数据集名称 mAP_0.5: 0.872 # COCO mAP@0.5 accuracy_drop: "<0.5%" # 相比v2.2的精度变化

注意：input_shape必须精确到具体数值，不能写[1, 3, -1, -1]。很多部署失败，根源就在于推理时输入尺寸与训练时不一致，导致 ONNX 图中的 reshape 操作崩溃。我吃过亏：一次在树莓派上部署，训练用640x480，交付包里却写了[-1, 3, 480, 640]，结果onnxruntime在 ARM 上解析-1时行为异常，花了两天才定位。

2.3 推理脚本（inference/infer.py）：最小化、可移植、无副作用

这是交付包里最核心的代码。它的设计哲学是：只做一件事，且做到极致——把输入数据，变成标准 JSON 输出。它必须满足三个硬性要求：

1. 零训练框架依赖：不能 importtorch或tensorflow。只依赖onnxruntime、numpy、cv2（或更轻量的PIL）。
2. 无全局状态：所有变量在函数内声明，不使用global或模块级变量。保证多进程/多线程安全。
3. 输入输出严格契约：输入是bytes（图片二进制）或dict（JSON），输出是dict（JSON），格式在config.yaml中明确定义。

以下是经过生产环境验证的infer.py骨架（Python 3.8+）：

# inference/infer.py import os import json import numpy as np import onnxruntime as ort from PIL import Image from io import BytesIO # 1. 从环境变量或配置文件加载路径，避免硬编码 MODEL_PATH = os.getenv("MODEL_PATH", "model/model.onnx") CONFIG_PATH = os.getenv("CONFIG_PATH", "model/config.yaml") def load_model(): """加载ONNX模型，启用GPU加速（如果可用）""" providers = ['CUDAExecutionProvider', 'CPUExecutionProvider'] try: # 尝试GPU，失败则自动fallback到CPU session = ort.InferenceSession(MODEL_PATH, providers=providers) print(f"[INFO] Loaded model with providers: {session.get_providers()}") return session except Exception as e: print(f"[WARN] GPU load failed: {e}. Falling back to CPU.") session = ort.InferenceSession(MODEL_PATH, providers=['CPUExecutionProvider']) return session def preprocess_image(image_bytes: bytes, input_shape) -> np.ndarray: """标准化预处理：PIL读取 -> resize -> normalize -> NHWC->NCHW""" img = Image.open(BytesIO(image_bytes)).convert('RGB') # 严格按config.yaml中的input_shape[2:]进行resize h, w = input_shape[2], input_shape[3] img = img.resize((w, h), Image.BILINEAR) img_array = np.array(img, dtype=np.float32) # 归一化：[0,255] -> [0,1] -> [-1,1]（YOLO常用） img_array = (img_array / 255.0 - 0.5) * 2.0 # NHWC -> NCHW img_array = np.transpose(img_array, (2, 0, 1)) # 添加batch维度 img_array = np.expand_dims(img_array, axis=0) return img_array def postprocess_output(outputs, conf_threshold=0.25): """将ONNX输出转换为标准JSON格式""" # outputs 是 list of np.ndarray，顺序与ONNX模型输出端口一致 boxes, scores, classes = outputs[0], outputs[1], outputs[2] # 过滤低置信度 mask = scores > conf_threshold boxes = boxes[mask] scores = scores[mask] classes = classes[mask].astype(int) # 转换为标准JSON可序列化格式 detections = [] for i in range(len(boxes)): det = { "box": boxes[i].tolist(), # [x1, y1, x2, y2] "score": float(scores[i]), "class_id": int(classes[i]), "class_name": class_names[classes[i]] if classes[i] < len(class_names) else "unknown" } detections.append(det) return {"detections": detections, "count": len(detections)} # 全局模型会话（单例模式，避免重复加载） _session = None def predict(image_bytes: bytes) -> dict: """主预测函数：输入bytes，输出dict""" global _session if _session is None: _session = load_model() # 1. 预处理 input_tensor = preprocess_image(image_bytes, input_shape=[1,3,480,640]) # 2. 推理 # 获取ONNX模型的输入输出名（关键！不能硬编码） input_name = _session.get_inputs()[0].name output_names = [o.name for o in _session.get_outputs()] outputs = _session.run(output_names, {input_name: input_tensor}) # 3. 后处理 result = postprocess_output(outputs) return result # 供命令行测试用 if __name__ == "__main__": import sys if len(sys.argv) != 2: print("Usage: python infer.py <image_path>") sys.exit(1) with open(sys.argv[1], "rb") as f: img_bytes = f.read() result = predict(img_bytes) print(json.dumps(result, indent=2))

实操心得：input_name和output_names必须通过_session.get_inputs()[0].name动态获取，绝不能硬编码为"input"或"output". 因为不同导出工具（torch.onnx.export,onnx-simplifier）生成的节点名可能不同。我曾在一个客户项目中，因硬编码了"images"作为输入名，而他们的模型导出时用了"input.1"，导致服务启动就报错InvalidArgument: Input node not found，排查了整整一个下午。

3. 模型部署：从单机脚本到高可用服务的四层演进

部署不是“找个地方把模型跑起来”，而是一个渐进式的工程化过程。我把它分为四个清晰的层级，每一层都解决一类特定问题，且后一层建立在前一层的坚实基础上。跳过任何一层，都会在后续埋下巨大隐患。很多“本地部署失败”的案例，根源就在于试图用 Level 1 的方式去解决 Level 3 的问题。

3.1 Level 1：单机可执行脚本（Dev & Quick Test）

这是最基础的形态，目标是：在开发机上，用一条命令，验证模型能否正确推理。它不考虑并发、不考虑服务化、不考虑监控，只为快速验证交付包本身是否有效。

操作步骤：

1. 解压交付包yolov8s_defect_v2.3_delivery.zip
2. 创建虚拟环境：python3.8 -m venv venv && source venv/bin/activate
3. 安装推理依赖：pip install -r inference/requirements.txt
4. 运行冒烟测试：cd inference && python infer.py ../test/sample.jpg

关键检查点：

• 是否成功输出 JSON 结果（非空、格式正确）？
• 是否有ImportError？（说明requirements.txt不全）
• 是否有onnxruntime.capi.onnxruntime_pybind11_state.InvalidArgument？（说明 ONNX 模型损坏或输入不匹配）
• 单次推理耗时是否在预期范围内？（对比config.yaml中的latency_p95_ms）

经验：Mac 用户常遇到onnxruntime安装失败，报错clang: error: unsupported option '-fopenmp'。这是因为 macOS 默认 Clang 不支持 OpenMP。解决方案是：brew install libomp && pip install onnxruntime --no-binary onnxruntime。这个坑，我帮 17 个 Mac 用户填过。

3.2 Level 2：轻量级 Web API（Flask/FastAPI）

当 Level 1 验证通过，下一步就是把它变成一个可通过 HTTP 访问的服务。这是大多数中小型应用、内部工具、PoC（概念验证）的终点。选择 FastAPI 而非 Flask，是因为它原生支持异步、自动生成 OpenAPI 文档、类型提示驱动，开发效率和健壮性更高。

FastAPI 服务骨架（app.py）：

# app.py from fastapi import FastAPI, UploadFile, File, HTTPException from fastapi.responses import JSONResponse import uvicorn import sys import os # 将inference目录加入Python路径，以便导入 sys.path.insert(0, os.path.join(os.path.dirname(__file__), "inference")) from infer import predict app = FastAPI( title="Defect Detection API", description="YOLOv8s-based surface defect detection service", version="2.3" ) @app.post("/predict/") async def predict_image(file: UploadFile = File(...)): try: # 读取上传的图片 image_bytes = await file.read() # 调用核心推理函数 result = predict(image_bytes) return JSONResponse(content=result) except Exception as e: # 所有异常统一处理，避免暴露内部细节 raise HTTPException(status_code=500, detail=f"Inference failed: {str(e)}") @app.get("/health") def health_check(): return {"status": "ok", "model_version": "2.3"} if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0:8000", port=8000, workers=1)

启动与测试：

# 安装FastAPI和Uvicorn pip install "fastapi>=0.104.0" "uvicorn>=0.23.2" # 启动服务（注意：workers=1，单进程，适合调试） uvicorn app:app --host 0.0.0.0:8000 --port 8000 --reload # 测试（curl） curl -X POST "http://localhost:8000/predict/" \ -H "accept: application/json" \ -F "file=@./test/sample.jpg"

Level 2 的核心价值与局限：

• ✅ 价值：提供了标准 RESTful 接口，前端、移动端、其他后端服务均可调用；自动生成 Swagger UI（访问http://localhost:8000/docs）；内置健康检查/health。
• ❌ 局限：单进程，无法利用多核 CPU；无负载均衡；无自动重启；无日志聚合；无指标暴露。它只是一个“能用”的原型，而非“生产就绪”的服务。

3.3 Level 3：容器化与进程管理（Docker + systemd）

当服务需要长期稳定运行，且要部署到多台服务器时，就必须进入 Level 3。核心是：将服务及其所有依赖（Python、ONNX Runtime、CUDA）打包成一个不可变的镜像，并由操作系统级别的进程管理器（systemd）来守护它。这解决了单机部署的可靠性问题。

Dockerfile（精简版，针对 Ubuntu 22.04 + CUDA 11.8）：

# 使用NVIDIA官方ONNX Runtime镜像，已预装CUDA和cuDNN FROM nvcr.io/nvidia/onnxruntime:1.16.3-cuda11.8-py310 # 设置工作目录 WORKDIR /app # 复制交付包内容（假设已解压到当前目录） COPY yolov8s_defect_v2.3_delivery/ . # 安装FastAPI和Uvicorn（ONNX Runtime镜像里没有） RUN pip install "fastapi>=0.104.0" "uvicorn>=0.23.2" "python-multipart>=0.0.6" # 暴露端口 EXPOSE 8000 # 启动命令 CMD ["uvicorn", "app:app", "--host", "0.0.0.0:8000", "--port", "8000", "--workers", "4"]

构建与运行：

# 构建镜像（tag为模型版本，便于追踪） docker build -t defect-detection:v2.3 . # 运行容器（挂载GPU，设置内存限制） docker run -d \ --gpus all \ --memory=4g \ --restart=always \ -p 8000:8000 \ --name defect-v2.3 \ defect-detection:v2.3

systemd 服务文件（/etc/systemd/system/defect-detection.service）：
（适用于裸机部署，当 Docker 不可用时的备选方案）

[Unit] Description=Defect Detection Service (v2.3) After=network.target [Service] Type=simple User=aiuser WorkingDirectory=/opt/defect-detection/v2.3 ExecStart=/opt/defect-detection/v2.3/venv/bin/uvicorn app:app --host 0.0.0.0:8000 --port 8000 --workers 4 Restart=always RestartSec=10 Environment="PATH=/opt/defect-detection/v2.3/venv/bin" Environment="MODEL_PATH=/opt/defect-detection/v2.3/model/model.onnx" [Install] WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload sudo systemctl enable defect-detection.service sudo systemctl start defect-detection.service sudo systemctl status defect-detection.service # 查看状态

关键经验：--gpus all是 Docker 运行 GPU 容器的必要参数，但很多用户会漏掉。另一个常见错误是--restart=always没加，导致服务器重启后服务消失。我建议所有生产服务都加上RestartSec=10，避免因依赖服务（如数据库）未启动而频繁重启。

3.4 Level 4：云原生编排与可观测性（Kubernetes + Prometheus）

当你的 AI 服务需要支撑高并发、多租户、灰度发布、自动扩缩容时，就必须进入 Level 4。这不再是“部署一个模型”，而是“运营一个 AI 微服务”。核心是 Kubernetes（K8s）编排和 Prometheus/Grafana 监控栈。

K8s Deployment YAML（关键片段）：

# k8s/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: defect-detection labels: app: defect-detection spec: replicas: 3 # 启动3个副本，实现高可用 selector: matchLabels: app: defect-detection template: metadata: labels: app: defect-detection spec: containers: - name: predictor image: your-registry/defect-detection:v2.3 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 # 申请1块GPU memory: "4Gi" cpu: "2" requests: nvidia.com/gpu: 1 memory: "2Gi" cpu: "1" livenessProbe: # 存活探针，K8s定期检查 httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: # 就绪探针，决定是否接入流量 httpGet: path: /health port: 8000 initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: defect-detection-service spec: selector: app: defect-detection ports: - protocol: TCP port: 80 targetPort: 8000 type: LoadBalancer # 对外暴露，云厂商会分配公网IP

Prometheus 监控指标（在 infer.py 中添加）：

# 在infer.py顶部添加 from prometheus_client import Counter, Histogram, Gauge import time # 定义指标 PREDICTION_COUNTER = Counter('defect_prediction_total', 'Total number of predictions') PREDICTION_LATENCY = Histogram('defect_prediction_latency_seconds', 'Prediction latency in seconds') PREDICTION_ERROR = Counter('defect_prediction_errors_total', 'Total number of prediction errors') def predict(image_bytes: bytes) -> dict: PREDICTION_COUNTER.inc() start_time = time.time() try: # ...原有推理逻辑... latency = time.time() - start_time PREDICTION_LATENCY.observe(latency) return result except Exception as e: PREDICTION_ERROR.inc() raise e

Grafana 仪表盘关键视图：

• QPS（每秒请求数）：监控流量峰值，判断是否需要扩容。
• P95 Latency（95分位延迟）：核心性能指标，应稳定在config.yaml承诺值附近。
• GPU Memory Usage（GPU显存使用率）：超过90%需告警，可能引发OOM。
• Error Rate（错误率）：持续高于1%需立即介入。

真实案例：我们为一家汽车零部件厂部署的缺陷检测服务，在上线首周，Grafana 显示 P95 Latency 从 42ms 飙升至 120ms。排查发现是 K8s 的livenessProbe配置不当（initialDelaySeconds: 30太短），导致服务刚启动就被 K8s 误判为死亡并重启，形成恶性循环。调整为60后，问题解决。这印证了一点：AI 部署的瓶颈，往往不在模型本身，而在基础设施的精细调优。

4. 模型管理：从“版本混乱”到“全生命周期可追溯”的实践体系

如果说部署是让模型“活”起来，那么管理就是让模型“活得明白、活得长久”。在实际项目中，一个业务线往往同时运行着 5-10 个不同版本的模型（v1.0 到 v2.3），服务于不同的客户、不同的渠道、不同的合规要求。没有一套清晰的管理机制，就会陷入“不知道线上跑的是哪个版本”、“新版本上线后老版本数据无法复现”、“安全审计时拿不出模型变更记录”的混乱局面。

4.1 模型注册中心（Model Registry）：集中存储与元数据索引

模型注册中心，是模型管理的“中央数据库”。它不存储模型文件本身（太占空间），而是存储模型的元数据、指向模型文件的 URI、以及版本间的血缘关系。我推荐两种轻量级、易落地的方案：

方案A：MLflow Model Registry（推荐给 Python 生态）MLflow 是开源的 MLOps 平台，其 Model Registry 功能成熟、文档完善、社区活跃。它天然支持 PyTorch/TensorFlow/Scikit-learn，且可与我们的交付包无缝集成。

操作流程：

1. 注册模型：在训练脚本末尾，将交付包上传到 MLflow：

   import mlflow mlflow.set_tracking_uri("http://mlflow-server:5000") mlflow.set_experiment("defect-detection") with mlflow.start_run() as run: # ...训练代码... # 将整个交付包目录作为模型 artifact 注册 mlflow.log_artifacts("yolov8s_defect_v2.3_delivery/", "model") # 记录关键指标 mlflow.log_metric("mAP_0.5", 0.872) mlflow.log_param("train_dataset", "defect_train_v2.0") # 将此版本标记为 "Staging" mlflow.register_model( "runs:/{}/model".format(run.info.run_id), "DefectDetectionModel" )

2. 版本管理：在 MLflow UI 中，你可以看到DefectDetectionModel下的所有版本（v1, v2, v2.1, v2.3），并为每个版本设置阶段（None,Staging,Production,Archived）。点击任意版本，即可查看其完整的元数据、关联的 Run ID、以及config.yaml的快照。
3. 生产部署：部署脚本不再硬编码路径，而是通过 MLflow API 动态拉取：

   import mlflow client = mlflow.tracking.MlflowClient() # 获取最新 Production 版本的模型URI model_uri = client.get_latest_versions("DefectDetectionModel", stages=["Production"])[0].source # 下载到本地 mlflow.artifacts.download_artifacts(model_uri, dst_path="/tmp/model")

方案B：自建 MinIO + SQLite（推荐给资源受限或私有化部署）当无法部署 MLflow 时，一个极简但有效的替代方案是：用 MinIO（S3 兼容的对象存储）存模型文件，用 SQLite 数据库存储元数据。

SQLite 表结构（models.db）：

CREATE TABLE models ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, -- 模型名，如 'defect-detection' version TEXT NOT NULL, -- 版本号，如 '2.3' stage TEXT DEFAULT 'staging', -- 阶段：staging, production, archived s3_uri TEXT NOT NULL, -- MinIO URI，如 's3://models/defect-detection/v2.3.zip' created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, author TEXT, description TEXT, performance_json TEXT, -- JSON字符串，存config.yaml中的performance部分 UNIQUE(name, version) );

优势：零外部依赖，MinIO 可单机部署，SQLite 是文件，备份极其简单。所有操作可通过sqlite3CLI 或 Pythonsqlite3库完成，运维成本极低。

4.2 模型血缘（Lineage）：追踪“这个结果从哪里来？”

模型血缘，是回答“为什么这个预测是这样？”的终极依据。它记录了从原始数据、到训练代码、到超参、到最终模型、再到每一次推理的完整链条。没有血缘，AI 就是黑箱；有了血缘，AI 才是可解释、可审计、可追责的工程产品。

血缘追踪的三层实现：

1. 数据层血缘：在数据预处理脚本中，为每个数据集生成唯一哈希（如sha256），并将哈希值写入assets/dataset_hash.txt。交付包中的config.yaml引用此哈希。
2. 代码层血缘：在训练脚本开头，获取 Git Commit ID：

   import subprocess commit_id = subprocess.check_output(["git", "rev-parse", "HEAD"]).decode().strip() mlflow.log_param("git_commit", commit_id)

3. 模型层血缘：在交付包的docs/README.md中，明确写出：

   This model v2.3 was trained on:

   • Dataset:defect_train_v2.0(SHA256:a1b2c3...)
   • Code:git commit a1b2c3...in repohttps://gitlab.example.com/ai/defect-detection
   • Framework:pytorch-2.1.0,torchvision-0.16.0
   • Hardware:NVIDIA A100 80GB

血缘可视化（简易版）：
用 Mermaid 语法（虽然你禁用，但这里仅作原理说明，实际不用）可以画出：

graph LR A[Raw Images] --> B[Preprocess Script v1.2] B --> C[Dataset v2.0 SHA:a1b2c3] C --> D[Train Script v2.1] D --> E[Model v2.3] E --> F[Inference API v2.3] F --> G[Production Traffic]

在实践中，我用一个简单的 HTML 页面，动态渲染这个关系图，链接到 GitLab 仓库、MinIO 文件、K8s Dashboard，让任何一个 QA 或审计员，都能在 30 秒内，从线上一个错误预测，追溯到当初训练用的那张原始图片。

4.3 模型监控（Model Monitoring）：从“上线即结束”到“持续进化”

部署上线，不是终点，而是监控的起点。模型会漂移（Drift），数据会变化，业务需求会升级。一个不被监控的模型，就像一辆没有仪表盘的汽车，你永远不知道它何时会抛锚。

必须监控的三大维度：

一个真实的监控闭环案例：
我们在某电商平台部署的商品识别模型，上线三个月后，监控显示confidence_score_mean从 0.82 逐渐下降到 0.65。起初以为是模型退化，但accuracy_test.py