从零构建AI工程体系：打造可重复、可验证、可运维的AI流水线

1. 什么是“从零构建AI工程体系”——不是搭模型而是建生产线“AI Engineering from Scratch”这个标题乍看像在教人手写反向传播其实完全不是。我带过七支AI落地团队踩过所有坑现在回头看真正卡住90%项目的从来不是算法精度差那几个百分点而是没有一条能稳定跑通的AI工程流水线。所谓“from scratch”不是从Python空环境开始而是从一张白纸开始设计整套AI交付系统数据怎么进、特征怎么管、模型怎么训、版本怎么控、服务怎么发、效果怎么盯、故障怎么救。它解决的是“为什么我们调出的SOTA模型上线后三天就崩、两周就掉点、一个月没人敢动”的现实困境。核心关键词“AI Engineering”和“from-scratch”必须拆开理解“AI Engineering”是把AI当成一个需要可重复、可验证、可运维的工程产品来对待不是科研实验“from-scratch”强调不依赖现成平台黑盒比如某云AI平台一键部署而是亲手定义每个环节的契约、接口、监控点和回滚机制。适合三类人一是技术负责人要为团队建立长期AI交付能力二是资深算法工程师想跳出调参怪圈掌握全链路话语权三是MLOps工程师需要知道底层组件如何咬合而非只会配YAML。这不是速成课但你花三个月搭完这套体系后续每个新模型上线时间能从两周压缩到两小时模型迭代频率提升5倍以上——我去年帮一家保险科技公司重构后车险定价模型AB测试周期从14天缩短到17小时关键不是快是每次上线都敢用生产流量直接验证。这一体系的本质是把“模型”从孤立的.py文件变成像汽车发动机一样的工业品有明确的输入规格数据Schema、出厂检测标准验证集通过率线上A/B指标基线、装配说明书Docker镜像启动参数、维修手册日志结构告警阈值、备件目录历史模型快照特征版本映射。而“from scratch”的价值正在于让你亲手拧紧每一颗螺丝——当线上模型突然OOM你不会去翻平台文档找“内存超限怎么办”而是直接看自己写的资源申请模板里limit是不是设错了当特征漂移报警你不会等数据科学家手动查表而是立刻触发自己设计的自动重训练Pipeline。这种掌控感是任何封装平台给不了的。2. 为什么必须放弃“先搭模型再补工程”——血泪换来的四个认知断层我见过太多团队把AI工程当作模型训练后的“善后工作”模型跑通了再找人配个Flask API加个Prometheus监控最后发现根本扛不住真实流量。这种倒置顺序导致四个致命断层每个都足以让项目流产。下面这些不是理论推演而是我在三个不同行业金融、制造、医疗踩坑后总结的硬伤2.1 数据契约断层训练集和线上服务用的根本不是同一份数据最典型场景算法同学用清洗好的CSV训练模型工程同学用Kafka实时流喂服务。表面看都是“用户年龄、收入、设备类型”但训练数据里“收入”是月均值float线上流里却是原始字符串“¥12,345.67”。模型加载时直接报错排查两小时才发现是JSON序列化时没做类型强制转换。更隐蔽的是时间戳问题训练数据用UTC时间戳线上服务用本地时区导致特征计算窗口偏移整整8小时。我们后来强制推行“数据契约先行”原则所有数据源必须提供OpenAPI风格的Schema定义含字段名、类型、取值范围、业务含义模型训练脚本和线上服务启动前必须校验Schema一致性。这个动作看似多花两天但避免了后续80%的数据相关故障。2.2 特征生命周期断层训练时的特征和推理时的特征不是同一个“人”算法同学在Jupyter里用Pandas做特征工程导出一个feature_store.pkl工程同学用Java写服务用Spark读取同一份HDFS路径。问题在于Pandas的fillna()默认用0填充Spark的na.fill()默认用null填充。模型训练时看到的是0线上服务看到的是null结果就是同一批数据离线评估AUC 0.85线上AUC暴跌到0.62。我们最终方案是彻底废弃“特征代码复用”改用统一特征计算引擎Flink SQL UDF所有特征无论训练还是推理都走同一套SQL逻辑。代价是初期学习成本高收益是特征一致性100%保障——上线后特征相关bug归零。2.3 模型版本断层你以为部署的是v2.1实际运行的是v1.7某次大促前紧急上线新模型运维同学按流程执行kubectl apply -f model-v2.1.yaml但集群里早有v1.7的Pod在运行新yaml只更新了镜像tag没改Deployment的revision策略。结果新旧Pod混跑流量打到老模型上转化率直接跌23%。根源在于模型版本管理缺失没有将模型二进制、训练代码、特征代码、配置文件打包成不可变的“模型包”Model Bundle。我们现在强制要求每个模型发布必须生成唯一Bundle ID如mb-20240521-001Bundle内包含模型权重文件onnx格式、特征计算代码.py、配置文件config.yaml、依赖清单requirements.txt、SHA256校验码。部署时只认Bundle ID拒绝任何裸文件上传。2.4 监控反馈断层只监控CPU内存不监控模型健康度很多团队监控面板上全是绿色CPU使用率45%内存占用2.1GBQPS 1200。但业务方投诉“推荐结果越来越不准”。查日志发现模型预测置信度中位数从0.82降到0.41但监控系统根本没这个指标。我们后来增加三层监控基础设施层CPU/内存/延迟、服务层HTTP 5xx率/请求成功率、模型层预测分布偏移、特征漂移指数、标签延迟率。其中模型层监控全部基于Prometheus自定义指标比如特征漂移用KS检验统计量每小时计算一次并报警。这个改动让模型退化平均发现时间从3.2天缩短到47分钟。提示这四个断层不是独立存在而是环环相扣。数据契约断层必然导致特征断层特征断层引发模型版本混乱版本混乱让监控失去意义。所以“from scratch”必须从第一行代码就设计闭环而不是等模型跑通后再打补丁。3. 从零构建的六大核心模块——每个模块都附带可抄作业的最小可行实现“AI Engineering from Scratch”不是抽象概念而是六个可落地的模块。我不会推荐“用Kubeflow还是MLflow”而是告诉你每个模块必须解决什么问题、为什么选这个方案、具体怎么实现。以下所有代码和配置都是我在生产环境验证过的最小可行版本MVP删掉了所有非必要依赖确保你能30分钟内跑通。3.1 数据契约与接入模块用OpenAPI Schema定义数据生命线核心目标让数据生产者上游系统和消费者模型训练/服务对数据的理解绝对一致。我们不用复杂的数据目录工具而是用最朴素的OpenAPI 3.0 YAML定义契约。#>import yaml import jsonschema from jsonschema import validate def validate_data_contract(data_dict): with open(data-contract.yaml) as f: contract yaml.safe_load(f) # 提取UserEvent schema user_event_schema contract[components][schemas][UserEvent] try: validate(instancedata_dict, schemauser_event_schema) return True except jsonschema.exceptions.ValidationError as e: print(fData contract violation: {e.message}) return False # 使用示例 sample_data {user_id: a1b2c3..., event_time: 2024-05-21T10:00:00Z, event_type: click} assert validate_data_contract(sample_data) # True线上服务强校验Flask服务启动时加载契约每个请求解析后立即校验app.before_request def check_data_contract(): if request.path /predict: try: data request.get_json() if not validate_data_contract(data): abort(400, Invalid data contract) except Exception as e: abort(400, Invalid JSON format)这个模块的价值在于当上游系统修改字段类型时CI会立刻失败而不是等到模型上线后崩溃。我们曾因此拦截了三次重大数据变更事故。3.2 特征计算引擎用Flink SQL统一训练与推理特征放弃Pandas/Spark代码复用改用声明式SQL定义特征。所有特征逻辑写在SQL文件里训练和推理共用同一份SQL。-- features.sql -- 计算用户最近7天点击率 CREATE VIEW user_click_rate_7d AS SELECT user_id, COUNT(CASE WHEN event_type click THEN 1 END) * 1.0 / COUNT(*) AS click_rate_7d FROM user_events WHERE event_time CURRENT_TIMESTAMP - INTERVAL 7 DAY GROUP BY user_id; -- 计算用户设备类型占比 CREATE VIEW user_device_ratio AS SELECT user_id, SUM(CASE WHEN device_type mobile THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS mobile_ratio, SUM(CASE WHEN device_type desktop THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS desktop_ratio FROM user_events GROUP BY user_id;实操要点训练侧用Flink Batch SQL读取离线数据生成特征宽表flink run -d \ -c org.apache.flink.table.api.java.BatchTableEnvironment \ --jarfile flink-sql-gateway.jar \ --sql INSERT INTO feature_table SELECT * FROM user_click_rate_7d JOIN user_device_ratio USING(user_id)推理侧Flink Streaming SQL实时计算结果写入RedisINSERT INTO redis_output SELECT user_id, click_rate_7d, mobile_ratio FROM user_click_rate_7d JOIN user_device_ratio USING(user_id)服务调用Python服务用redis-py直接读取import redis r redis.Redis(hostredis, port6379, db0) features r.hgetall(fuser:{user_id}) # 返回字典 {click_rate_7d: b0.23, mobile_ratio: b0.78}这个方案的好处是特征逻辑修改只需改SQL文件训练和推理自动同步。我们曾用此方案将特征迭代周期从3天缩短到15分钟。3.3 模型包Model Bundle构建模块让模型成为可部署的原子单元模型不是单个.onnx文件而是一个包含所有依赖的ZIP包。结构如下mb-20240521-001/ ├── model.onnx # 模型权重 ├── features.sql # 特征计算SQL ├── config.yaml # 服务配置端口、超时等 ├── requirements.txt # Python依赖 ├── predict.py # 推理入口加载model.onnx 执行features.sql └── SHA256SUM # 校验码构建脚本build_bundle.sh#!/bin/bash BUNDLE_IDmb-$(date %Y%m%d)-$(printf %03d $((RANDOM%999))) mkdir $BUNDLE_ID cp model.onnx $BUNDLE_ID/ cp features.sql $BUNDLE_ID/ cp config.yaml $BUNDLE_ID/ pip freeze $BUNDLE_ID/requirements.txt echo from onnxruntime import InferenceSession; sess InferenceSession(model.onnx) $BUNDLE_ID/predict.py sha256sum $BUNDLE_ID/* $BUNDLE_ID/SHA256SUM zip -r ${BUNDLE_ID}.zip $BUNDLE_ID部署时只认Bundle ID# 下载并校验 curl -O https://storage.example.com/bundles/${BUNDLE_ID}.zip sha256sum -c ${BUNDLE_ID}.zip.SHA256SUM # 校验通过才解压 unzip ${BUNDLE_ID}.zip cd $BUNDLE_ID python predict.py # 启动服务这个模块解决了模型溯源难题线上出问题时直接查Bundle ID就能定位到对应训练代码、特征SQL、依赖版本无需人工追溯。3.4 模型服务化模块轻量级但生产就绪的推理服务不用Kubernetes Operator或复杂框架用Python FastAPI ONNX Runtime构建极简服务# serve.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import onnxruntime as ort import numpy as np app FastAPI() class PredictRequest(BaseModel): user_id: str features: dict # 从Redis读取的特征字典 # 加载模型启动时加载避免每次请求加载 session ort.InferenceSession(model.onnx) app.post(/predict) def predict(request: PredictRequest): try: # 构造输入张量假设模型输入名为input input_data np.array(list(request.features.values()), dtypenp.float32).reshape(1, -1) inputs {session.get_inputs()[0].name: input_data} outputs session.run(None, inputs) return {score: float(outputs[0][0][0])} except Exception as e: raise HTTPException(status_code500, detailstr(e))Dockerfile极致精简FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, serve:app, --host, 0.0.0.0:8000, --port, 8000, --workers, 4]requirements.txt仅三行fastapi0.104.0 onnxruntime1.16.0 uvicorn0.23.2这个服务实测QPS 1200内存占用150MB。关键是它足够简单任何Python工程师都能读懂、修改、调试。3.5 模型监控模块从基础设施监控到模型健康度监控监控分三层全部用Prometheus暴露指标# metrics.py from prometheus_client import Counter, Histogram, Gauge # 基础设施层 REQUEST_COUNT Counter(http_requests_total, Total HTTP Requests, [method, endpoint, status]) REQUEST_LATENCY Histogram(http_request_duration_seconds, HTTP Request Duration, [endpoint]) # 服务层 PREDICTION_SUCCESS Counter(prediction_success_total, Successful predictions) PREDICTION_ERROR Counter(prediction_error_total, Prediction errors, [type]) # 模型层核心 PREDICTION_CONFIDENCE Gauge(prediction_confidence, Model prediction confidence (0-1)) FEATURE_DRIFT_KS Gauge(feature_drift_ks, KS statistic for feature drift detection) LABEL_DELAY_SECONDS Gauge(label_delay_seconds, Delay between prediction and ground truth label) # 在predict函数中记录 app.post(/predict) def predict(request: PredictRequest): REQUEST_COUNT.labels(methodPOST, endpoint/predict, status200).inc() start_time time.time() try: result session.run(None, inputs) confidence float(result[0][0][0]) PREDICTION_CONFIDENCE.set(confidence) PREDICTION_SUCCESS.inc() # 计算特征漂移简化版用当前特征均值对比历史均值 current_mean np.mean(list(request.features.values())) historical_mean get_historical_mean() # 从Redis读取 ks_stat abs(current_mean - historical_mean) FEATURE_DRIFT_KS.set(ks_stat) return {score: confidence} finally: REQUEST_LATENCY.labels(endpoint/predict).observe(time.time() - start_time)Grafana看板必备面板模型健康度看板置信度中位数趋势图红线预警0.5、特征漂移KS统计量黄线预警0.15、标签延迟中位数绿线预警300秒服务稳定性看板P99延迟阈值200ms、错误率阈值0.1%、QPS基线±20%波动这个模块让我们第一次真正“看见”模型在衰减而不是靠业务投诉才发现。3.6 自动化重训练模块用CronJob驱动的闭环不追求全自动ML而是用最简单的CronJob触发重训练# retrain-cronjob.yaml apiVersion: batch/v1 kind: CronJob metadata: name: model-retrain spec: schedule: 0 2 * * * # 每天凌晨2点 jobTemplate: spec: template: spec: containers: - name: retrain image: retrain-job:v1.0 args: - --data-sources3://bucket/daily-data/ - --model-outputs3://bucket/models/ - --bundle-idmb-$(date %Y%m%d)-001 restartPolicy: OnFailure重训练脚本retrain.py核心逻辑def main(): # 1. 下载最新数据 download_data(args.data_source) # 2. 校验数据契约 if not validate_data_contract(latest_batch.json): send_alert(Data contract violation) return # 3. 训练新模型 model train_model(latest_batch.json) # 4. 评估必须通过基线 if evaluate_model(model) BASELINE_AUC: send_alert(Model performance below baseline) return # 5. 构建Bundle bundle_id build_bundle(model) # 6. 部署滚动更新 deploy_bundle(bundle_id) # 7. 发送报告 send_report(bundle_id) if __name__ __main__: main()这个模块的关键是“人工审核门禁”重训练成功后不是自动上线而是发企业微信消息给算法负责人“新Bundle mb-20240521-001已就绪AUC 0.8720.012是否上线[确认] [驳回]”。我们坚持“机器执行人类决策”。4. 实操避坑指南那些文档里绝不会写的血泪经验上面六个模块看似清晰但实际落地时90%的失败源于细节。以下是我在三个项目中总结的独家避坑清单全是文档里找不到的实战技巧4.1 数据契约模块的三大陷阱陷阱1枚举值动态扩展契约里写了event_type: [click,purchase]但业务方突然新增add_to_cart事件。如果契约校验严格报错整个流水线就停摆。解决方案契约中枚举字段加x-allow-unknown: true扩展属性并在校验逻辑里忽略未知值# 修改校验函数 def validate_enum_field(value, enum_list, allow_unknownFalse): if value in enum_list: return True elif allow_unknown: return True # 允许未知值但记录日志 else: return False陷阱2时间戳时区混淆OpenAPI的format: date-time默认是UTC但前端传过来的往往是本地时间。我们在契约里强制要求所有时间字段加时区标识2024-05-21T10:00:0008:00并在校验时用dateutil.parser.isoparse()解析拒绝无时区的时间字符串。陷阱3嵌套对象校验失效当契约定义{user: {id: string}}但实际数据是{user: null}时jsonschema校验会通过因为null符合object类型。解决方案在契约中显式声明nullable: false并用jsonschema.Draft7Validator启用validate方法的types参数。4.2 特征计算引擎的性能雷区雷区1Flink状态后端选型默认RocksDB状态后端在特征计算场景下GC频繁。我们改用EmbeddedRocksDB并调大state.backend.rocksdb.block.cache.size: 512mQPS提升40%。雷区2SQL JOIN导致数据倾斜user_events JOIN user_profile时少数超级用户产生大量事件拖慢整个作业。解决方案对高频用户ID加盐user_id || _ || rand()JOIN后再去重。雷区3Redis读取超时雪崩特征服务并发高时Redis连接池耗尽导致请求排队。我们用redis-py的ConnectionPool(max_connections1000)并设置socket_timeout100毫秒超时直接返回默认特征值避免级联失败。4.3 模型包构建的版本地狱地狱1ONNX Opset版本不兼容训练用PyTorch 1.13导出opset17但线上ONNX Runtime只支持opset15。解决方案构建Bundle时强制指定opset_version15并在requirements.txt里锁定onnxruntime1.14.0。地狱2Python依赖冲突scikit-learn1.2.0和xgboost1.7.0依赖不同版本的numpy。我们用pip-tools生成冻结依赖pip-compile requirements.in # 生成requirements.txt pip install -r requirements.txt --no-deps # 跳过依赖安装 pip install numpy1.23.5 scikit-learn1.2.0 xgboost1.7.0 # 显式安装地狱3Bundle ID生成冲突多人同时构建BundleID重复。我们改用Git commit hash 时间戳mb-$(git rev-parse --short HEAD)-$(date %s)确保全局唯一。4.4 模型服务化的隐形杀手杀手1ONNX Runtime线程争用默认InferenceSession是线程不安全的。我们用threading.local()为每个线程创建独立sessionlocal_session threading.local() def get_session(): if not hasattr(local_session, session): local_session.session ort.InferenceSession(model.onnx) return local_session.session杀手2FastAPI中间件阻塞自定义中间件里做耗时操作如调用外部API会阻塞整个事件循环。解决方案所有IO操作用asyncio.to_thread()转为线程池执行app.middleware(http) async def log_request(request, call_next): # 耗时日志记录放在线程池 await asyncio.to_thread(write_log, request) return await call_next(request)杀手3Docker内存限制误判docker run -m 512m限制容器内存但ONNX Runtime会预分配内存导致OOM。我们在Dockerfile里加启动参数CMD [sh, -c, export ORT_MEMORY_ALLOCATORarena exec uvicorn serve:app --host 0.0.0.0:8000]4.5 监控模块的指标幻觉幻觉1置信度指标失真模型输出logits直接softmax后取max作为置信度。但当模型过拟合时logits差异巨大置信度虚高。我们改用温度系数校准softmax(logits/T)T1.5让置信度更平滑。幻觉2特征漂移KS统计量误报单一特征KS0.15就报警但某些特征如时间戳天然漂移。解决方案为每个特征配置漂移容忍度在config.yaml里定义features: event_time: drift_tolerance: 0.5 # 时间戳容忍度更高 click_rate_7d: drift_tolerance: 0.1幻觉3标签延迟指标失效电商订单确认延迟可能长达72小时用固定300秒阈值会误报。我们动态计算label_delay_seconds median(delay_last_7_days) * 2基线随业务变化。4.6 自动化重训练的决策悖论悖论1AUC提升≠业务提升新模型AUC0.02但线上转化率-0.5%。原因AUC在样本不平衡场景下失真。我们增加业务指标监控conversion_rate,avg_order_value只有双指标达标才允许上线。悖论2每日重训练导致过拟合数据量少时1万样本每天用新数据重训练模型在最新数据上过拟合。解决方案动态调整重训练频率当new_data_size 0.1 * total_data_size时跳过本次训练。悖论3自动部署引发雪崩重训练成功后自动kubectl rollout restart但新模型需要warmup。我们加5分钟灰度期先切5%流量监控P99延迟100ms且错误率0.01%后再全量。注意所有这些避坑技巧都不是凭空而来。每一个都对应着一次线上事故有一次我们因Redis连接池耗尽导致整个推荐服务雪崩损失了23万GMV。这些经验比任何架构图都珍贵。5. 常见问题速查表从“为什么跑不通”到“怎么修好它”问题现象根本原因快速诊断命令修复方案我的实操心得模型服务启动报错ModuleNotFoundError: No module named onnxruntimeDocker镜像里没装ONNX Runtimedocker exec -it container pip list | grep onnx在Dockerfile里明确RUN pip install onnxruntime1.16.0不要用*通配版本曾因onnxruntime1.0导致装了1.17.0与训练环境不兼容debug 6小时特征服务返回空字典Redis key不存在或过期redis-cli -h redis -p 6379 GET user:123在predict.py里加fallback逻辑r.hgetall(...) or {click_rate_7d: 0.0, mobile_ratio: 0.5}线上必须有兜底值宁可不准不能报错Prometheus监控显示0指标FastAPI应用没暴露/metrics端点curl http://localhost:8000/metrics在serve.py里加from prometheus_fastapi_instrumentator import InstrumentatorInstrumentator().instrument(app).expose(app)不要自己手写metrics暴露逻辑用成熟库重训练Job卡在Pending状态Kubernetes节点资源不足kubectl describe pod job-pod查Eventskubectl patch node node-name -p {spec:{unschedulable:true}}临时隔离问题节点每次重训练前先kubectl top nodes看资源水位Bundle部署后预测结果全为0ONNX模型输入名与代码不匹配python -c import onnx; monnx.load(model.onnx); print([i.name for i in m.graph.input])用onnxruntime.InferenceSession.get_inputs()获取真实输入名不要硬编码我们曾因输入名从input改成input.1导致线上服务返回全0持续47分钟特征漂移报警频繁KS统计量计算窗口太小redis-cli -h redis KEYS feature:*看历史数据key改用滑动窗口计算current_window last_24h, historical_window last_24h_ago_to_48h_ago漂移检测必须跨周期对比单点数据无意义FastAPI服务QPS骤降uvicorn workers数设置不当ps aux | grep uvicorn看进程数uvicorn --workers $(nproc) --worker-class uvicorn.workers.UvicornH11Workerworkers数CPU核数不是越多越好我们试过32 workers反而QPS下降30%这张表里的每一个问题我都亲手解决过。最常被忽视的是最后一列“我的实操心得”——它告诉你为什么标准方案在这里会失效以及如何绕过它。比如“Bundle部署后预测结果全为0”标准文档只会说“检查输入名”但实际中你需要先用命令行确认真实输入名因为不同框架导出的ONNX命名规则完全不同。6. 从第一个Bundle到稳定产线我的三个月落地路线图“From scratch”不是一次性动作而是持续演进的过程。我给自己团队定的三个月里程碑不是“完成所有模块”而是“每个模块都达到可生产状态”6.1 第一周跑通最小闭环Day 1-7目标用真实数据让一个模型从训练到上线预测全程手动操作不写一行自动化脚本。Day 1-2定义数据契约YAML写校验脚本用真实数据测试Day 3-4用Flink SQL写第一个特征用户点击率导出CSV验证Day 5用Scikit-learn训练简单模型导出ONNXDay 6写FastAPI服务加载ONNX接受HTTP请求Day 7用curl发送请求拿到预测结果关键成果产出第一个可用的Bundlemb-20240521-001.zip包含所有必需文件。此时不追求性能只求“能跑通”。6.2 第二周注入工程约束Day 8-14目标让手动流程具备生产基本属性——可重复、可验证、可回滚。Day 8-9改造训练脚本加入数据契约校验、模型评估基线检查Day 10-11编写Bundle构建脚本自动生成SHA256校验码Day 12Dockerize服务docker build docker run验证Day 13添加Prometheus监控暴露基础指标Day 14写回滚脚本./rollback.sh mb-20240521-001关键成果Bundle具备完整元数据任何新人拉取代码make deploy就能上线。6.3 第三周建立自动化骨架Day 15-21目标用最简方式实现自动化不追求完美但求可靠。Day 15-16写CronJob触发重训练每天一次结果存S3Day 17写部署脚本下载Bundle、校验SHA256、替换服务Day 18配置Grafana看板监控P99延迟和错误率Day 19加企业微信通知重训练成功/失败都发消息Day 20-21压力测试hey -z 5m -c 100 http://localhost:8000/predict关键成果自动化流程跑通但需人工确认上线。此时QPS应稳定在500。6.4 第四周加固与扩展Day 22-30目标解决真实场景痛点让系统真正可用。Day 22-23加特征兜底逻辑处理Redis未命中Day 24实现灰度发布用Nginx按权重分流Day 25加模型A/B测试框架用HTTP Header控制路由Day 26-27写故障演练剧本模拟Redis宕机、模型文件损坏Day 28-30团队培训每人独立完成一次Bundle构建部署关键成果系统通过故障演练团队具备独立运维能力。6.