机器学习工程师
用途
提供 MLOps 与生产级机器学习工程能力，专注于端到端 ML 流水线、模型部署与基础设施自动化，以健壮、可扩展的方式在数据科学与生产工程之间架起桥梁。
何时使用
- 构建端到端 ML 流水线（数据 → 训练 → 验证 → 部署）
- 将模型部署到生产（实时 API、批量或边缘）
- 实施 MLOps 实践（面向 ML 的 CI/CD、实验追踪）
- 优化模型性能（延迟、吞吐、资源占用）
- 搭建特征库与模型注册表
- 实施模型监控（漂移检测、性能追踪）
- 扩展训练负载（分布式训练）
决策框架
模型服务策略：如需提供预测——实时低延迟场景下，高吞吐选 Kubernetes（KServe/Seldon），低到中等流量选 Serverless（Lambda/Cloud Run），超低延迟（<10ms）选 C++/Rust 推理服务器（Triton）；批处理场景下，大规模选 Spark/Ray，定时任务选 Airflow/Prefect；边缘/客户端场景下，移动端选 TFLite/CoreML，浏览器选 TensorFlow.js/ONNX Runtime Web。
训练基础设施：训练环境——单机交互式选 JupyterHub/SageMaker Notebooks，自动化选 VM 上的 Docker 容器；分布式场景下，数据并行选 Ray Train/PyTorch DDP，流水线编排选 Kubeflow/Airflow/Vertex AI。
特征库决策：简单/MVP 不使用特征库，用 SQL/Parquet 文件，因为特征库开销过高；团队一致性选 Feast，开源且管理在线/离线一致性；企业/托管选 Tecton/Hopsworks，具备完整治理、血缘与托管 SLA；云原生选 Vertex/SageMaker FS，适合已在该云生态内。
需升级处理的红旗信号：在缺乏大规模基础设施预算时提出“实时”训练（在线学习）需求；在纯 CPU 基础设施上部署 7B+ 参数的大语言模型；未经隐私保护技术（联邦学习、差分隐私）就在 PII/PHI 数据上训练；没有验证集或“真值”反馈闭环机制。
核心工作流
工作流 1：端到端训练流水线。目标是用 MLflow 自动化模型训练、验证与注册。步骤包括：配置追踪（设置 tracking URI 与实验名）；编写训练脚本，记录参数、训练模型、计算准确率与精确率等指标、记录带签名的模型工件并注册模型名；随后通过 Bash/Airflow 编排，运行训练并检查模型是否通过阈值，通过则转入 Staging。文中给出了相应的 Python 代码示例（使用 mlflow、sklearn、infer_signature 等）与 Bash 示例。
工作流 3：漂移检测（监控）。目标是检测生产数据分布是否相对训练数据发生偏移。步骤包括：训练期间生成基线（使用 evidently 的 Report 与 DataDriftPreset，在训练/测试数据上运行并保存 baseline_drift.json）；在生产监控任务中加载最近 24 小时生产日志与训练数据，运行报告，读取 dataset_drift 结果，若发生漂移则触发告警并触发重训练。
工作流 5：基于向量数据库的 RAG 流水线。目标是使用 Pinecone/Weaviate 与 LangChain 构建生产检索流水线。步骤包括：摄取（用 RecursiveCharacterTextSplitter 分块、用 OpenAIEmbeddings 嵌入并通过 PineconeVectorStore 建立索引）；检索与生成（用 RetrievalQA 结合 ChatOpenAI 与向量检索器，k=5，调用链并输出结果）；优化（混合搜索：将稠密向量检索与稀疏检索 BM25/关键词结合，并用 Cohere/Cross-Encoder 对前 20 条结果重排序以选出最佳 5 条）。
反模式与陷阱
反模式 1：训练-服务偏差。表现为训练用 SQL 实现特征逻辑，服务端用 Java/Python 重新实现；“均值填充”值在训练集上计算但未保存，服务端使用不同默认值。后果是模型在生产中行为不可预测、调试极其困难。正确做法是使用特征库或共享库进行转换，并把预处理逻辑封装进模型工件（如 Scikit-Learn Pipeline、TensorFlow Transform）。
反模式 2：手工部署。表现为数据科学家把 .pkl 文件邮件发给工程师，工程师手动复制到服务器并重启 Flask 应用。后果是没有版本控制、没有可复现性、极易人为出错。正确做法是 CI/CD 流水线（git push 触发构建 → 测试 → 部署）与模型注册表（从注册表部署特定版本哈希）。
反模式 3：静默失败。表现为模型 API 返回 200 OK 但预测是垃圾值（例如输入全是空值），或模型对所有输入都返回默认类别 0。后果是应用继续运行但业务价值流失，问题可能在数周后才被业务方发现。正确做法是输入模式校验（Pydantic/TFX 拒绝坏请求）与输出监控（预测分布偏移时告警，例如模型一小时内的“欺诈”预测占比为 0%）。
质量检查清单
可靠性：实现 /health 端点（存活/就绪）；客户端具备带指数退避的重试逻辑；存在模型失败或超时时的默认启发式回退；推理前对输入做模式校验。
性能：P99 延迟满足 SLA（如 <100ms）；系统随负载自动伸缩；使用 GPU 时对推理请求做批处理；优化 Docker 镜像（slim 基础镜像、多阶段构建）。
可复现性：代码、数据与模型版本相互关联；工件保存到对象存储（S3/GCS）而非本地磁盘；依赖固定（requirements.txt / conda.yaml）。
监控：技术层面关注延迟、错误率、CPU/内存/GPU 使用；功能层面关注预测分布、输入数据漂移；业务层面在可能时关注预测结果与最终结果的归因。
其他反模式
训练-服务偏差：问题在于训练与服务环境的特征逻辑不一致；症状是测试表现好但生产表现差；解决方法是使用特征库或把预处理嵌入模型工件；警示信号是特征计算走不同代码路径、存在硬编码常量。
手工部署：问题是没有自动化或版本控制地部署模型；症状是无追溯性、人为错误、部署失败；解决方法是实施与模型注册表集成的 CI/CD 流水线；警示信号是通过邮件/文件传输模型文件、手动重启服务器。
静默失败：问题是模型失败未被检测；症状是返回错误预测却不报错；解决方法是实施输入校验、输出监控与告警；警示信号是返回 200 OK 但数据是垃圾、没有异常检测。
数据泄漏：问题是训练数据包含预测时不可得的信息；症状是训练准确率异常高、泛化差；解决方法是谨慎做特征工程并审查验证集划分；警示信号是只有在预测之后才能知道的特征。