人工智能工程全景：从问题到系统

很多团队在第一次“做 AI 项目”时会陷入一种错觉：只要模型效果（离线指标）高，就等价于业务成功。现实往往相反——模型只是系统中的一个组件；真正决定成败的是你是否把“任务—数据—模型—训练—评估—部署—监控”做成闭环，是否把需求、数据、工程、合规、运维这些环节用同一套语言描述清楚，并能持续迭代。本章的目标，就是为全书建立共同语境：我们到底在构建什么系统？如何定义成功？交付物应该长什么样？团队如何分工？以及如何从第一天起就避免“只会调参不会落地”。

1.1 术语对齐：AI、ML、DL 以及“工程化”的边界

在工程语境里，术语的准确性决定了沟通成本与返工概率。

1.1.1 AI / ML / DL 的关系：集合论而不是流行语

• **人工智能（AI）**：用机器实现“智能行为”的总称，既包含基于规则/搜索/规划/知识图谱的系统，也包含学习系统。
• **机器学习（ML）**：AI 的子集，强调从数据中学习映射关系（例如分类、回归、排序、聚类、强化学习）。
• **深度学习（DL）**：ML 的子集，强调用多层神经网络学习表示与决策（Transformer、CNN、RNN 等）。

工程上更重要的是： DL ≠ 端到端系统。DL 只解决“模型如何从数据学到函数”的问题；而端到端系统还包括数据获取、特征/表征一致性、线上推理稳定性、监控告警、A/B 实验、隐私与安全等。

1.1.2 AI 工程与传统软件工程：相同与不同

相同点：

• 都需要需求、架构、测试、部署、监控、迭代。
• 都要管理复杂性：版本、依赖、可观测性、故障恢复。

不同点（决定了 AI 工程的独特方法论）： 1. 行为由数据定义：模型行为高度依赖训练数据分布，而数据分布随时间变化（概念漂移、数据漂移）。 2. 正确性是统计意义的：软件常用“确定性断言”，模型更多用概率、置信区间、阈值策略与业务代价函数。 3. 可复现难度更高：随机种子、并行非确定性、数据切分、特征生成、框架版本都会影响结果。 4. 测试维度更多：除了功能测试，还需要数据测试（schema/范围/漂移）、模型测试（公平性/鲁棒性/校准）、系统测试（延迟/吞吐/降级）。

> 关键结论：AI 工程的核心交付不是“一个模型文件”，而是一个可持续运行、可迭代优化的“数据与模型驱动系统”。

1.2 闭环全景：任务—数据—模型—训练—评估—部署—监控

把一个 AI 项目拆成可执行的闭环，可以避免“局部最优”的陷阱。下面给出一条通用链路，并说明每一步的输入、输出与常见坑。

1.2.1 任务（Task）：把业务问题翻译成可学习的形式

任务定义至少包含：

• **对象与场景**：谁在什么时刻使用预测（用户、运营、风控、客服、机器设备）。
• **动作与决策**：模型输出将触发什么动作（排序、过滤、分流、提醒、拦截、自动化处理）。
• **约束条件**：延迟（P95/P99）、吞吐、成本、可解释性、合规（个人信息、敏感属性）、可用性。
• **成功标准**：业务指标 + 线上实验口径 + 容错边界（坏案例能否接受）。

常见坑：

• 只写“做个分类模型”，但没有说清楚“分类结果用于什么决策、误判代价多少、可接受延迟是多少”。

1.2.2 数据（Data）：决定上限，也决定故障类型

数据工作不是“拿到 CSV 就训练”。至少要明确：

• **数据来源**：日志、交易、工单、传感器、第三方数据、人工标注。
• **数据粒度**：样本单位是什么（一次点击、一次会话、一个用户、一个工单）。
• **标签定义**：正负样本口径、延迟窗口（label delay）、弱监督/噪声策略。
• **划分策略**：随机切分 vs 时间切分；是否存在泄漏（例如未来信息）。
• **质量与偏差**：缺失、重复、长尾类、采样偏差、反馈回路（模型上线影响数据分布）。

1.2.3 模型（Model）：选择“足够好”而不是“最复杂”

模型选择应服务于系统约束：

• 低延迟边缘端：轻量模型、量化、蒸馏、ONNX/TensorRT。
• 高精度离线批处理：更大模型、更复杂特征、更长训练。
• 强可解释性：可解释模型或解释方法（SHAP/LIME、规则抽取），并配合审核流程。

1.2.4 训练（Train）：从一次性脚本走向可重复流水线

训练不仅是 `fit()`：

• 训练配置（超参、种子、优化器、损失、采样）
• 数据版本（快照、增量、时间窗）
• 资源与分布式（GPU/TPU、DDP、混合精度）
• 失败恢复（checkpoint、断点续训）
• 产物管理（模型权重、tokenizer、特征映射、label encoder）

1.2.5 评估（Eval）：离线指标只是“必要不充分”

评估至少三层： 1. 离线指标：AUC、F1、NDCG、Recall@K 等 2. 系统指标：延迟、吞吐、资源占用、稳定性、冷启动 3. 业务指标：转化率、客诉率、拦截损失、处理时长、人工成本

离线指标与业务指标之间通常有一层“策略层”（阈值、规则、排序融合、灰度、人工兜底）。工程上必须把这层显式化，否则上线后很难解释“离线很好线上不好”。

1.2.6 部署（Deploy）：从模型文件到可用服务

部署关注：

• **服务形态**：在线推理服务、批处理、流式计算、端侧推理
• **一致性**：训练/推理特征一致、tokenizer 一致、预处理一致
• **发布策略**：灰度、A/B、回滚、金丝雀
• **安全与合规**：鉴权、脱敏、审计、输出安全（越权/提示注入/敏感信息）

1.2.7 监控（Monitor）：上线不是结束，是开始

必须监控三类漂移：

• **数据漂移**：输入分布变化（长度、词表、数值范围、缺失率）
• **概念漂移**：同样输入对应的标签关系变化（业务规则变了、用户行为变了）
• **反馈回路**：模型干预导致数据偏置（例如推荐系统越推越同质化）

监控也包含：

• **线上指标**：延迟 P95/P99、错误率、QPS
• **效果指标**：线上 A/B、人工抽检、投诉与申诉
• **安全指标**：异常调用、越权输出、敏感内容触发率

1.3 一条贯穿全书的主线示例：客服工单文本分类（可替换为推荐/异常检测）

为便于贯穿后续章节，我们选一个“文本分类”主线：客服工单自动分流。读者也可以把它替换为“推荐排序”或“异常检测”，但闭环结构与交付物基本一致。

1.3.1 业务背景与决策点

某平台每天产生大量工单（退款、物流、账户、安全等），目前由人工分流到不同处理队列。目标是：

• 自动预测工单类别（多分类），将工单路由到对应队列；
• 对低置信度样本进入人工池；
• 对高风险类别（账号安全）要求更低漏判率。

这意味着输出不是“一个类别”这么简单，而是一个策略：

• `top1_class` + `confidence`
• `topk_classes` 供人工参考
• 规则兜底（敏感词、历史黑名单、异常账号）

1.3.2 指标体系：业务指标 vs 离线指标

离线常见指标：

• 精确率/召回率/F1（宏/微平均）
• 混淆矩阵（特别关注高代价类别）
• 校准（calibration）：预测概率与真实频率是否匹配

F1 的定义： $$ \text{Precision}=\frac{TP}{TP+FP},\quad \text{Recall}=\frac{TP}{TP+FN},\quad F1=\frac{2PR}{P+R} $$

业务指标示例（更贴近价值）：

• **平均处理时长（AHT）**：自动分流后是否下降
• **一次解决率（FCR）**：分流正确可减少转派
• **升级率/客诉率**：错误分流会引发投诉
• **人工分流成本**：人工池比例越低越省，但不能牺牲安全类召回

把离线指标映射到业务指标，需要定义代价函数/收益函数。例如对安全类，漏判（FN）代价远高于误判（FP），因此需要：

• 为该类设置更高召回目标（或更低阈值）
• 或采用分层阈值策略（不同类不同阈值）
• 或使用代价敏感学习/重采样

> 如果你只追求整体 F1，往往会牺牲少数关键类，最终线上“看似准确”但业务不可用。

1.3.3 基线（Baseline）：把“可上线的最低版本”尽快跑通

基线的目标不是 SOTA，而是尽快验证闭环并建立对照组。推荐按三个层次递进：

1. 规则/词典基线

• 关键词/正则触发（如“退款”“发票”“登录不了”）
• 优点：可解释、上线快
• 缺点：覆盖有限、维护成本高、泛化差

2. 传统 ML 基线（TF-IDF + 线性模型）

• 向量化：TF-IDF、n-gram
• 模型：Logistic Regression、Linear SVM
• 优点：训练快、可解释性较强、作为强基线很常用
• 缺点：对长文本语义理解有限，跨域迁移差

3. 深度学习基线（Transformer 微调）

• 模型：BERT/RoBERTa/中文预训练模型
• 优点：语义能力强，通常显著提升
• 缺点：部署成本更高，需要更严格的工程治理

工程建议：先把 2 跑通，再上 3。这能避免“直接上大模型，结果发现数据口径不对、标签噪声大、线上预处理不一致”的典型翻车路径。

1.4 典型 AI 项目生命周期：从立项到持续迭代

下面给出一条常见生命周期，你可以把它当作“迭代式瀑布 + 持续交付”的组合：

1. 需求澄清与可行性评估（1–2 周）

• 明确决策点、成本/收益、上线约束
• 输出：需求文档、指标口径、风险清单、里程碑

2. 数据审计与标注方案（1–4 周）

• 数据源梳理、字段字典、缺失与偏差分析
• 标注指南、抽样策略、一致性检验（Kappa 等）
• 输出：数据字典、标注规范、数据质量报告

3. 基线实现与端到端打通（1–2 周）

• 从数据拉取→训练→评估→导出→推理服务→监控 的最小闭环
• 输出：可运行流水线、基线报告、上线草案

4. 迭代优化与实验管理（持续）

• 特征/表征、采样、损失、阈值策略、模型结构
• 输出：实验记录、模型卡、对比报告

5. 上线与灰度（1–2 周）

• 性能压测、降级策略、回滚方案、A/B 实验
• 输出：部署方案、SLO、告警规则、验收报告

6. 监控与再训练（持续）

• 漂移检测、数据回灌、主动学习、再训练节奏
• 输出：监控看板、再训练计划、版本变更记录

1.5 角色分工：谁负责什么，交接点在哪里

一个能稳定交付的团队，往往不是“全栈天才”，而是有清晰接口与交付物。

• **产品经理/业务负责人**：定义决策点与业务指标；推动流程改造与验收；管理收益与风险。
• **数据分析师（DA）**：指标口径、数据探索、实验分析（A/B 设计与解读）。
• **数据工程师（DE）**：数据管道、数据仓库/湖、特征/样本生成、数据质量监控。
• **算法工程师/数据科学家（DS）**：建模、离线评估、误差分析、实验设计。
• **机器学习工程师（MLE）**：训练工程化、推理优化、模型服务化、特征一致性、模型注册与发布。
• **后端/平台工程师**：业务系统集成、接口、权限、灰度、队列与缓存。
• **SRE/运维**：SLO、容量规划、监控告警、应急预案、发布流程。
• **QA/测试**：数据与模型的回归测试策略、端到端验收用例。
• **安全/合规/法务（视行业）**：隐私合规、审计、敏感内容治理、模型输出风险。

交接点建议用“文档 + 自动化”固化，例如：

• DS→MLE：模型导出规范（输入输出 schema、tokenizer、阈值、依赖版本）
• DE→DS：样本生成脚本与数据快照版本（可复现）
• MLE→SRE：服务的指标、告警阈值、回滚步骤

1.6 交付物清单：让项目可追踪、可复盘、可审计

下面是一个实用的交付物清单（可按项目裁剪），每一项都对应一个“减少返工”的关键点。

1.6.1 需求文档（PRD/FRD 的 AI 版本）

至少包含：

• 业务背景与决策点（模型输出如何影响动作）
• 业务指标与验收口径（含对照组、统计显著性标准）
• 约束：延迟、成本、可解释性、合规
• 风险与兜底：人工审核、规则降级、黑白名单
• 里程碑与上线策略（灰度/A/B/回滚）

1.6.2 数据字典（Data Dictionary）

建议包含字段级信息：

• 字段名、类型、取值范围、缺失含义
• 来源表/日志、更新频率、延迟
• 是否含个人信息（PII）、脱敏方式
• 与标签的关联方式（join key、窗口）

示例（片段）：

| 字段 | 类型 | 说明 | 例子 | 质量规则 | |---|---|---|---|---| | `ticket_id` | string | 工单唯一标识 | "T2026..." | 非空、唯一 | | `text` | string | 工单正文 | "登录失败..." | 长度 5–2000 | | `created_at` | datetime | 创建时间 | 2026-03-12 | 不得晚于现在 | | `label` | int | 业务类别 | 0..N-1 | 允许延迟更新 |

1.6.3 实验记录（Experiment Log）与可复现模板

建议把“可复现”当成硬指标，而不是良好愿望。最小模板如下（可以是 Markdown，也可以由实验平台自动生成）：

• 实验编号：`exp_20260312_bert_v3`
• 目标：提升安全类召回，控制误判率
• 数据版本：`data_snapshot=2026-03-01`，切分：按时间（train: 1-20 日，valid: 21-25 日，test: 26-28 日）
• 预处理版本：`preprocess_commit=abc123`
• 模型：`bert-base-chinese`，max_len=256
• 训练：batch=32，lr=2e-5，epoch=3，seed=42，fp16=true
• 指标：macro-F1、关键类 recall、校准 ECE、P95 延迟
• 结果：与基线对比表 + 显著性说明
• 误差分析：Top 错误类型、代表样本、改进假设
• 结论：是否进入候选上线
• 产物：模型文件、tokenizer、阈值配置、推理脚本版本

为了可复现，建议把关键配置固化为 `config.yaml`：

```yaml data: snapshot_date: "2026-03-01" split: "time" train_range: ["2026-02-01", "2026-02-20"] valid_range: ["2026-02-21", "2026-02-25"] test_range: ["2026-02-26", "2026-02-28"]

model: name: "bert-base-chinese" max_length: 256 num_labels: 12

train: seed: 42 batch_size: 32 lr: 2e-5 epochs: 3 fp16: true

eval: metrics: ["macro_f1", "per_class_recall", "ece"] key_classes: ["account_security"] ```

1.6.4 模型卡（Model Card）：面向“使用者”的说明书

模型卡建议包含：

• 适用场景与不适用场景
• 训练数据范围与代表性说明
• 关键指标（整体 + 关键类）
• 伦理与合规声明（敏感属性、偏差风险）
• 推理输入输出 schema（含阈值策略）
• 版本信息与变更点
• 监控项与再训练策略

一个简化模板（可直接用作仓库中的 `MODEL_CARD.md`）：

> 模型名称：TicketRouter-v1 > 任务：客服工单多分类与置信度输出 > 适用：中文工单文本，长度 5–2000 > 不适用：包含大量表格/图片的工单（需 OCR 或结构化解析） > 关键指标：macro-F1=0.86；安全类 recall=0.95（阈值=0.35） > 风险：新业务类冷启动；节假日活动导致分布变化 > 监控：输入长度分布、OOV 比例、关键类召回抽检、人工池占比

1.6.5 部署方案（Deployment Plan）

至少覆盖：

• 服务接口（请求/响应示例、错误码）
• 性能目标（P95/P99 延迟、QPS、成本）
• 灰度策略（流量比例、观测窗口、回滚条件）
• 降级策略（规则兜底、返回人工池）
• 安全与审计（鉴权、日志脱敏、访问控制）
• 运维（告警、仪表盘、应急手册）

1.7 端到端流水线：从数据到线上监控（Mermaid）

下面给出一个可复用的端到端流水线图。你可以把它映射到任意任务（推荐、异常检测同理），只需要替换“样本与标签”的生成方式与评估指标。

```mermaid graph TD A[需求与指标定义] --> B[数据源盘点/权限合规] B --> C[样本与标签生成] C --> D[数据质量检查] D --> E[训练集/验证集/测试集切分] E --> F[基线训练] F --> G[离线评估与误差分析] G --> H{达标?} H -- 否 --> C H -- 是 --> I[模型打包/注册] I --> J[推理服务/批处理部署] J --> K[灰度/A-B实验] K --> L[线上监控:效果/性能/漂移] L --> M{触发再训练?} M -- 是 --> C M -- 否 --> L ```

1.8 从“调参”走向“系统”：三类常见失败模式与对策

1.8.1 失败模式一：离线很高，线上无提升

典型原因：

• 数据泄漏（使用了未来信息或与标签直接相关字段）
• 训练/推理预处理不一致（分词、归一化、截断策略不同）
• 线上策略层写错（阈值、融合、路由逻辑）
• 指标口径不一致（离线看 F1，线上看客诉率）

对策：

• 强制时间切分与“泄漏审计清单”（每个特征问：线上可得吗？会不会间接包含标签？）
• 用同一份预处理代码构建训练与推理（或把预处理导出为可复