⚡

ML&AIEngineeringSystemSkill afrexai-ml-engineering

这是一套完整的方法论，用于构建、部署和运营从实验到规模化的生产级机器学习和人工智能系统。涵盖问题定义、数据工程、实验管理、模型评估、部署策略、监控和优化等多个方面。

机器学习 0 次安装 0 次浏览 更新于 2/24/2026

ML & AI Engineering System

构建、部署和运营生产级ML/AI系统的完整方法论 — 从实验到规模化。

第1阶段：问题定义

在编写任何代码之前，精确定义ML问题。

ML问题简介

problem_brief:
  business_objective: ""          # 什么业务指标会提升？
  success_metric: ""              # 量化目标（例如，“减少流失15%”）
  baseline: ""                    # 没有ML时的当前性能
  ml_task_type: ""                # 分类 | 回归 | 排名 | 生成 | 聚类 | 异常检测 | 推荐
  prediction_target: ""           # 我们究竟在预测什么？
  prediction_consumer: ""         # 谁/什么使用预测？（API | 仪表板 | 电子邮件 | 自动化操作）
  latency_requirement: ""         # 实时（<100ms）| 近实时（<1s）| 批量（分钟-小时）
  data_available: ""              # 今天存在什么数据？
  data_gaps: ""                   # 缺少什么？
  ethical_considerations: ""      # 偏见风险，公平性要求，隐私
  kill_criteria:                  # 何时放弃ML方法
    - "基线启发式方法达到>90%的ML性能"
    - "数据质量在2周清洁后太糟糕"
    - "模型在保留集上不能超过随机>10%"

ML与规则决策

信号 使用规则 使用ML
逻辑在<10条规则内可解释 ✅ ❌
模式对人类来说太复杂 ❌ ✅
训练数据>1,000个标记样本 — ✅
需要适应新模式 ❌ ✅
必须是100%可审计/确定性的 ✅ ❌
模式变化速度比你更新规则快 ❌ ✅

**经验法则：**从规则/启发式开始。只有当规则无法捕捉模式时才添加ML。

第2阶段：ML的数据工程

数据质量评估

对每个数据源进行评分（每个维度0-5分）：

维度 0 （糟糕） 5 （优秀）
完整性 >50%缺失 <1%缺失
准确性 已知错误，无验证 已验证真实来源
一致性 不同格式，重复 标准化，去重
时效性 几个月陈旧 实时或每日刷新
相关性 弱代理目标 直接信号预测
体量 <100样本 >10,000样本每类

最低分数继续： 18/30。低于18 → 先修复数据，不要构建模型。

特征工程模式

feature_types:
  numerical:
    - raw_value           # 如果正态分布，原样使用
    - log_transform       # 右偏分布（收入，计数）
    - standardize         # z分数，适用于对尺度敏感的算法（SVM，KNN，神经网络）
    - bin_to_categorical  # 当关系非线性且数据有限时
  categorical:
    - one_hot             # <20类别，基于树的模型自然处理
    - target_encoding     # 高基数（>20类别），使用K折以防止泄露
    - embedding           # 非常高基数（用户ID，产品ID）与深度学习
  temporal:
    - lag_features        # t-1，t-7，t-30时的值
    - rolling_statistics  # 窗口内的平均值，标准差，最小值，最大值
    - time_since_event    # 自上次购买以来的天数，自登录以来的小时数
    - cyclical_encoding   # 小时-天，周-天，月的正弦/余弦
  text:
    - tfidf               # 简单，可解释，好基线
    - sentence_embeddings # 语义相似性，现代NLP
    - llm_extraction      # 使用LLM从非结构化文本中提取结构化字段
  interaction:
    - ratios              # 特征A / 特征B（例如，点击/展示=CTR）
    - differences         # 特征A - 特征B（例如，价格-竞争对手价格）
    - polynomial          # A * B，A^2（慎用，高基数特征）

特征存储设计

feature_store:
  offline_store:         # 用于训练 — 批量计算，存储在数据仓库中
    storage: "BigQuery | Snowflake | S3+Parquet"
    compute: "Spark | dbt | SQL"
    refresh: "daily | hourly"
  online_store:          # 用于服务 — 低延迟查找
    storage: "Redis | DynamoDB | Feast online"
    latency_target: "<10ms p99"
    refresh: "streaming | near-real-time"
  registry:              # 特征元数据
    naming: "{entity}_{feature_name}_{window}_{aggregation}"  # 例如，user_purchase_count_30d_sum
    documentation:
      - description
      - data_type
      - source_table
      - owner
      - created_date
      - known_issues

数据泄露预防检查表

  • [ ] 特征中没有未来信息（时间旅行检查）
  • [ ] 在特征工程之前进行训练/验证/测试拆分
  • [ ] 目标编码仅使用训练折叠统计数据
  • [ ] 不从目标变量派生特征
  • [ ] 时间序列的时间拆分（不随机混洗）
  • [ ] 在任何EDA之前创建保留集
  • [ ] 在拆分之前删除重复项（同一实体不在训练和测试中）
  • [ ] 归一化/缩放拟合在训练上，应用于验证/测试

第3阶段：实验管理

实验跟踪模板

experiment:
  id: "EXP-{YYYY-MM-DD}-{NNN}"
  hypothesis: ""                 # "添加用户任期特征将改善流失预测AUC>2%"
  dataset_version: ""            # 训练数据的哈希或版本
  features_used: []              # 特征名称列表
  model_type: ""                 # 算法名称
  hyperparameters: {}            # 记录所有超参数
  training_time: ""              # 墙上时钟
  metrics:
    primary: {}                  # 最重要的一个指标
    secondary: {}                # 支持指标
  baseline_comparison: ""        # 与基线的差值
  verdict: "promoted | archived | iterate"
  notes: ""
  artifacts:
    - model_path: ""
    - notebook_path: ""
    - confusion_matrix: ""

模型选择指南

任务 从这里开始 扩展到 避免
表格分类 XGBoost/LightGBM 神经网络只有在>100K样本时 深度学习在<10K样本
表格回归 XGBoost/LightGBM CatBoost用于高基数类别 没有特征工程的线性回归
图像分类 微调ResNet/EfficientNet 视觉变换器如果>100K图像 从头开始训练
文本分类 微调BERT/RoBERTa LLM少量样本如果标记数据稀缺 细微任务的词袋
文本生成 GPT-4/Claude API 微调Llama/Mistral以降低成本 从头开始训练
时间序列 Prophet/ARIMA基线 → LightGBM 时序融合变换器 没有强理由的LSTM
推荐 协同过滤基线 双塔神经 <1K用户上的复杂模型
异常检测 隔离森林 如果高维，自编码器 没有标记异常的监督方法
搜索/排名 BM25基线 → 学习排名 交叉编码器重排序 没有语义的纯关键词

超参数调整策略

  1. 手动首先 — 了解3-5个最有影响力的参数
  2. 贝叶斯优化（Optuna）— 生产模型50-100次试验
  3. 网格搜索 — 只有最终微调2-3个参数
  4. 随机搜索 — 对于>4个参数比网格更好

模型的关键超参数：

模型 关键参数 典型范围
XGBoost learning_rate, max_depth, n_estimators, min_child_weight 0.01-0.3, 3-10, 100-1000, 1-10
LightGBM learning_rate, num_leaves, feature_fraction, min_data_in_leaf 0.01-0.3, 15-255, 0.5-1.0, 5-100
神经网络 learning_rate, batch_size, hidden_dims, dropout 1e-5至1e-2，32-512，架构依赖，0.1-0.5
随机森林 n_estimators, max_depth, min_samples_leaf 100-1000, 5-30, 1-20

第4阶段：模型评估

任务的指标选择

任务 主要指标 何时使用 注意事项
二元分类（平衡） F1分数 精确度/召回率同等重要 —
二元分类（不平衡） PR-AUC 正类稀有（<5%） ROC-AUC隐藏少数表现差
多类 宏观F1 所有类别同等重要 如果类别频率=重要性，使用微观F1
回归 MAE 异常值不应占主导 RMSE更严厉地惩罚大错误
排名 NDCG@K 最重要的顶部-K结果 如果二元相关性，MAP
生成 人工评估+自动化 质量主观 BLEU/ROUGE单独不足够
异常检测 Precision@K 假阳性代价昂贵 如果遗漏异常危险，召回率

评估严谨性检查表

  • [ ] 指标在真正的保留集上计算（从未在训练或调整中看到）
  • [ ] 小数据集（<10K样本）的交叉验证
  • [ ] 为不平衡类别进行分层拆分
  • [ ] 时间依赖数据的时间拆分
  • [ ] 报告置信区间（自助或交叉验证）
  • [ ] 按重要部分（地理，用户队列等）分解性能
  • [ ] 跨受保护群体的公平性指标
  • [ ] 与简单基线比较（多数类别，平均预测，规则）
  • [ ] 错误分析：手动检查前50个最差预测
  • [ ] 概率预测的校准图

线下到线上差距分析

部署前验证这些不会导致训练-服务偏差：

检查 线下 在线 行动
特征计算 批量SQL 实时API 验证相同逻辑，用重放测试
数据新鲜度 点时间快照 最新值 文档可接受的陈旧度
缺失值 在管道中插补 可能真正缺失 在服务中优雅处理
特征分布 训练期 当前期 部署后监控漂移

第5阶段：模型部署

部署模式决策树

是否需要<100ms的延迟？
├── 是 → 是否模型<500MB？
│   ├── 是 → 嵌入式服务（FastAPI + 内存中的模型）
│   └── 否 → 模型服务器（Triton，TorchServe，vLLM）
└── 否 → 是否批量预测？
    ├── 是 → 批量管道（Spark，Airflow + 离线推理）
    └── 否 → 异步队列（Celery/SQS → 工作程序 → 结果存储）

生产服务检查表

serving_config:
  model:
    format: ""                    # ONNX | TorchScript | SavedModel | safetensors
    version: ""                   # 语义版本
    size_mb: null
    load_time_seconds: null
  infrastructure:
    compute: ""                   # CPU | GPU (T4/A10/A100/H100)
    instances: null               # 自动扩展的最小/最大
    autoscale_metric: ""          # RPS | latency_p99 | GPU_utilization
    autoscale_target: null
  api:
    endpoint: ""
    input_schema: {}              # Pydantic模型或JSON模式
    output_schema: {}
    timeout_ms: null
    rate_limit: null
  reliability:
    health_check: "/health"
    readiness_check: "/ready"     # 模型已加载并预热
    graceful_shutdown: true
    circuit_breaker: true
    fallback: ""                  # 模型故障时基于规则的回退

容器化模板

# 多阶段构建最小图像
FROM python:3.11-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY --from=builder /usr/local/bin /usr/local/bin
COPY model/ ./model/
COPY src/ ./src/

# 非根用户
RUN useradd -m appuser && chown -R appuser /app
USER appuser

# 健康检查
HEALTHCHECK --interval=30s --timeout=5s CMD curl -f http://localhost:8080/health || exit 1

EXPOSE 8080
CMD ["uvicorn", "src.serve:app", "--host", "0.0.0.0", "--port", "8080"]

A/B测试模型

ab_test:
  name: ""
  hypothesis: ""
  primary_metric: ""              # 业务指标（收入，参与度等）
  guardrail_metrics: []           # 指标不能退化
  traffic_split:
    control: 50                   # 当前模型
    treatment: 50                 # 新模型
  minimum_sample_size: null       # 功效分析：使用statsmodels或在线计算器
  minimum_runtime_days: null      # 至少1个完整的业务周期（最少7天）
  decision_criteria:
    ship: "Treatment > control by >X% with p<0.05 AND no guardrail regression"
    iterate: "Promising signal but not significant — extend test or refine model"
    kill: "No improvement after 2x minimum runtime OR guardrail breach"

第6阶段：LLM工程

LLM应用架构

┌─────────────────────────────────────────────┐
│              应用层               │
│  （提示模板，链，输出解析器）  │
├─────────────────────────────────────────────┤
│              编排层              │
│  （路由，回退，重试，缓存）         │
├─────────────────────────────────────────────┤
│              模型层                     │
│  （API调用，微调模型，嵌入）  │
├─────────────────────────────────────────────┤
│              数据层                      │
│  （向量存储，上下文检索，内存）   │
└─────────────────────────────────────────────┘

LLM任务的模型选择

任务 最佳选项 成本效益选项 何时微调
一般推理 Claude Opus / GPT-4o Claude Sonnet / GPT-4o-mini 一般推理从不微调
分类 微调小型模型 少量样本与Sonnet >1,000个标记样本+高容量
提取 结构化输出API Regex + LLM回退 需要一致格式的大规模
摘要 Claude Sonnet GPT-4o-mini 需要特定领域风格
代码生成 Claude Sonnet Codestral / DeepSeek 内部代码库约定
嵌入 text-embedding-3-large text-embedding-3-small 特定领域词汇（医疗，法律）

RAG系统架构

rag_pipeline:
  ingestion:
    chunking:
      strategy: "semantic"         # semantic | fixed_size | recursive
      chunk_size: 512              # 令牌（大多数用例512-1024）
      overlap: 50                  # 令牌重叠在块之间
      metadata_to_preserve:
        - source_document
        - page_number
        - section_heading
        - date_created
    embedding:
      model: "text-embedding-3-large"
      dimensions: 1536             # 或者使用Matryoshka节省成本256/512
    vector_store: "Pinecone | Weaviate | pgvector | Qdrant"
  retrieval:
    strategy: "hybrid"             # dense | sparse | hybrid（推荐）
    top_k: 10                      # 检索更多，然后重新排名
    reranking:
      model: "Cohere rerank | cross-encoder"
      top_n: 3                     # 最终上下文块
    filters: []                    # 元数据过滤器（日期范围，来源等）
  generation:
    model: ""
    system_prompt: |
      仅根据提供的上下文回答。
      如果上下文不包含答案，请说"我没有足够的信息"。
      使用[Source: document_name, page X]引用来源。
    temperature: 0.1               # 事实较低，创意较高
    max_tokens: null

RAG质量检查表

  • [ ] 分块保留语义意义（不切割句子中间）
  • [ ] 元数据支持过滤（日期，来源，类别）
  • [ ] 检索返回相关块（用50+查询手动测试）
  • [ ] 重新排名提高精度（与/不使用比较）
  • [ ] 系统提示防止幻觉（用对抗性查询测试）
  • [ ] 引用来源并可验证
  • [ ] 优雅处理"我不知道"
  • [ ] 延迟可接受（交互<3s，复杂<30s）
  • [ ] 每查询成本跟踪并在预算内

LLM成本优化

策略 节省 权衡
提示缓存 重复前缀上的50-90% 需要缓存友好的提示设计
模型路由（小→大） 40-70% 稍高的延迟，需要路由器逻辑
批量API 50% 小时延迟，仅批量工作负载
更短的提示 与令牌减少成线性 可能降低质量
微调小型模型 大模型API的80-95% 训练成本+维护
语义缓存 相似查询的50-80% 可能返回陈旧/错误的缓存结果
输出令牌限制 与令牌减少成比例 可能截断有用信息

第7阶段：模型监控

监控仪表板

monitoring:
  model_performance:
    metrics:
      - name: "primary_metric"         # 与线下评估相同
        threshold: null                 # 如果低于则警告
        window: "1h | 1d | 7d"
      - name: "prediction_distribution"
        alert: "KL divergence > 0.1 from training distribution"
    latency:
      p50_ms: null
      p95_ms: null
      p99_ms: null
      alert_threshold_ms: null
    throughput:
      requests_per_second: null
      error_rate_threshold: 0.01       # 如果>1%错误则警告
  data_drift:
    method: "PSI | KS-test | JS-divergence"
    features_to_monitor: []            # 最重要的10个特征
    check_frequency: "hourly | daily"
    alert_threshold: null              # PSI > 0.2 = 显著漂移
  concept_drift:
    method: "performance_degradation"
    ground_truth_delay: ""             # 我们多久能得到标签？
    proxy_metrics: []                  # 真实标签之前可用的指标
    retraining_trigger: ""             # 何时重新训练

漂移响应剧本

漂移类型 检测 严重性 响应
特征漂移（输入分布偏移） PSI > 0.1 警告 调查原因，监控性能
特征漂移（PSI > 0.25） PSI > 0.25 严重 24小时内用最近的数据重新训练
概念漂移（关系变化） 性能下降>5% 严重 用新标签重新训练，审查特征
标签漂移（目标分布变化） 卡方检验 警告 验证标签质量，检查数据问题
预测漂移（输出分布偏移） KL散度 警告 可能指示上游数据问题

自动重新训练管道

retraining:
  triggers:
    - type: "scheduled"
      frequency: "weekly | monthly"
    - type: "performance"
      condition: "primary_metric < threshold for 24h"
    - type: "drift"
      condition: "PSI > 0.2 on any top-10 feature"
  pipeline:
    1_data_validation:
      - check_completeness
      - check_distribution_shift
      - check_label_quality
    2_training:
      - use_latest_N_months_data
      - same_hyperparameters_as_production   # 除非计划调整
      - log_all_metrics
    3_evaluation:
      - compare_vs_production_model
      - must_beat_production_on_primary_metric
      - must_not_regress_on_guardrail_metrics
      - evaluate_on_golden_test_set
    4_deployment:
      - canary_deployment: 5%
      - monitor_for: "4h minimum"
      - auto_rollback_if: "error_rate > 2x baseline"
      - gradual_rollout: "5% → 25% → 50% → 100%"
    5_notification:
      - log_retraining_event
      - notify_team_on_failure
      - update_model_registry

第8阶段：MLOps基础设施

ML平台组件

组件 目的 工具
实验跟踪 记录运行，比较结果 MLflow, W&B, Neptune
特征存储 集中特征管理 Feast, Tecton, Hopsworks
模型注册 版本控制，阶段性，批准模型 MLflow Registry, SageMaker
管道编排 基于DAG的ML工作流 Airflow, Prefect, Dagster, Kubeflow
模型服务 低延迟推理 Triton, TorchServe, vLLM, BentoML
监控 漂移，性能，数据质量 Evidently, Whylogs, Great Expectations
向量存储 用于RAG的嵌入存储 Pinecone, Weaviate, pgvector, Qdrant
GPU管理 训练和推理计算 K8s + GPU操作员，RunPod, Modal

ML的CI/CD

ml_cicd:
  on_code_change:
    - lint_and_type_check
    - unit_tests (data transforms, feature logic)
    - integration_tests (pipeline end-to-end on sample data)
  on_data_change:
    - data_validation (Great Expectations / custom)
    - feature_pipeline_run
    - smoke_test_predictions
  on_model_change:
    - full_evaluation_suite
    - bias_and_fairness_check
    - performance_regression_test
    - model_size_and_latency_check
    - security_scan (model file, dependencies)
    - staging_deployment
    - integration_test_in_staging
    - approval_gate (manual for major versions)
    - canary_deployment

模型注册工作流

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│  Development │ ───→ │   Staging    │ ───→ │  Production  │
│              │      │              │      │              │
│ - Experiment │      │ - Eval suite │      │ - Canary     │
│ - Log metrics│      │ - Load test  │      │ - Monitor    │
│ - Compare    │      │ - Approval   │      │ - Rollback   │
└──────────────┘      └──────────────┘      └──────────────┘

晋升标准：

  • 开发 → 暂存：在线下指标上击败当前生产
  • 暂存 → 生产：通过负载测试+集成测试+人工批准
  • 自动回滚：错误率>2倍或延迟>2倍或主要指标下降>5%

第9阶段：负责任的AI

偏见检测清单

  • [ ] 训练数据按比例代表所有人群
  • [ ] 按受保护属性分解性能指标
  • [ ] 平等机会：各组相似的真实阳性率
  • [ ] 校准：预测概率与每组的实际率相匹配
  • [ ] 没有代表受保护属性的代理特征（邮政编码→种族）
  • [ ] 在训练之前选择并定义公平性指标和阈值
  • [ ] 差异影响比率>0.8（80%规则）
  • [ ] 测试边缘情况：不寻常输入会发生什么？

模型卡模板

model_card:
  model_name: ""
  version: ""
  date: ""
  owner: ""
  description: ""
  intended_use: ""
  out_of_scope_uses: ""
  training_data:
    source: ""
    size: ""
    date_range: ""
    known_biases: ""
  evaluation:
    metrics: {}
    datasets: []
    sliced_metrics: {}             # 按子组的性能
  limitations: []
  ethical_considerations: []
  maintenance:
    retraining_schedule: ""
    monitoring: ""
    contact: ""

第10阶段：成本与性能优化

GPU选择指南

用例 GPU VRAM 成本/小时（云） 最适合
微调7B模型 A10G 24GB ~$1 LoRA/QLoRA微调
微调70B模型 A100 80GB 80GB ~$4 中型模型完整微调
服务7B模型 T4 16GB ~$0.50 大规模推理
服务70B模型 A100 40GB 40GB ~$2 大模型推理
从头开始训练 H100 80GB ~$8 预训练，大规模训练

推理优化技术

技术 加速 质量影响 复杂性
量化（INT8） 2-3倍 <1%降解 低
量化（INT4/GPTQ） 3-4倍 1-3%降解 中等
批处理 2-10倍吞吐量 无 低
KV缓存优化 20-40%内存节省 无 中等
推测性解码 2-3倍对LLM 数学上完全精确 高
模型蒸馏 5-10倍小模型 2-5%降解 高
ONNX Runtime 1.5-3倍 无 低
TensorRT 2-5倍 <1% 中等
vLLM（PagedAttention） 对LLM的2-4倍吞吐量 无 低

成本跟踪模板

ml_costs:
  training:
    compute_cost_per_run: null
    runs_per_month: null
    data_storage_monthly: null
    experiment_tracking: null
  inference:
    cost_per_1k_predictions: null
    daily_volume: null
    monthly_cost: null
    cost_per_query_breakdown:
      compute: null
      model_api_calls: null
      vector_db: null
      data_transfer: null
  optimization_targets:
    cost_per_prediction: null      # 目标
    monthly_budget: null
    cost_reduction_goal: ""

第11阶段：ML系统质量标准

给你的ML系统打分（0-100）：

维度 权重 0-2（差） 3-4（好） 5（优秀）
问题框架 15% 没有明确的业务指标 定义成功指标 杀伤标准+基线+ROI估计
数据质量 15% 临时数据，无验证 自动化质量检查 特征存储+血统+版本控制
实验严谨性 15% 无跟踪，一次性笔记本 MLflow/W&B跟踪 可重现的管道+适当评估
模型性能 15% 勉强击败基线 显著改进 校准，公平，对边缘情况健壮
部署 10% 手动部署 CI/CD用于模型 金丝雀+自动回滚+A/B测试
监控 15% 无监控 基本指标仪表板 漂移检测+自动重新训练+警报
文档 5% 未记录 模型卡存在 完整的模型卡+运行手册+决策日志
成本效率 10% 无成本跟踪 预算存在 优化推理+每预测成本跟踪

评分：

  • 80-100：生产级ML系统
  • 60-79：良好的基础，缺少运营成熟度
  • 40-59：原型质量，不适合生产
  • <40：科学项目，需要基本重做

常见错误

错误 修复
在修复数据之前优化模型 数据质量>模型复杂性。总是。
在不平衡数据上使用准确性 使用PR-AUC，F1或特定领域的指标
没有基线比较 始终从简单的启发式基线开始
在未来数据上训练 时间序列的时间拆分，严格的泄露检查
没有监控就部署 没有模型在生产中没有漂移检测
当提示有效时进行微调 首先尝试少量样本提示 — 仅在规模/成本上微调
一切都使用GPU CPU推理通常足够且便宜10倍
忽略校准 如果概率很重要（风险评分），则校准
一次性模型部署 ML是一个持续的系统 — 从第一天就计划重新训练
过早扩展 在构建实时服务之前，先用批量预测证明价值

快速命令

  • “Frame ML problem” → Phase 1 brief
  • “Assess data quality” → Phase 2 scoring
  • “Select model” → Phase 3 guide
  • “Evaluate model” → Phase 4 checklist
  • “Deploy model” → Phase 5 serving config
  • “Build RAG” → Phase 6 RAG architecture
  • “Set up monitoring” → Phase 7 dashboard
  • “Optimize costs” → Phase 10 tracking
  • “Score ML system” → Phase 11 rubric
  • “Detect drift” → Phase 7 playbook
  • “A/B test model” → Phase 5 template
  • “Create model card” → Phase 9 template