从“能做”到“做成”：AI项目全景与学习路径

很多人第一次做 AI 项目时，都会经历一个落差：你明明“会用模型”“能把代码跑通”，但项目却迟迟“落不了地”。原因往往不在于你不会调参，而在于你缺少一张全景地图：不知道该先解决哪类问题、怎样把业务语言翻译成机器可学的任务、怎么避免数据泄漏与不可复现、以及如何用最小成本验证“这条路值得走下去”。

你可以把“能做”理解为：能训练出一个看起来不错的模型；把“做成”理解为：能持续交付业务价值，并且可维护、可迭代、可解释、可上线。这两者之间的差距，正是本章要填平的鸿沟：先建立全书共用语境（AI/ML/DL/LLM 的边界与联系），再给出一套从需求到迭代的项目流程与常见陷阱清单，最后用“最小可行实验（MVE, Minimum Viable Experiment）”把方法论落到可执行的步骤与工具栈上。

---

术语地图：AI / ML / DL / LLM 到底是什么关系

层级关系：不要纠结名词，先抓住集合包含

• **AI（人工智能）**：最大的伞，包含规则系统、搜索、规划、机器学习等所有“让机器表现出智能”的方法。
• **ML（机器学习）**：AI 的子集，核心是“从数据中学习规律”，而不是手写规则。
• **DL（深度学习）**：ML 的子集，主要指多层神经网络（CNN/RNN/Transformer 等）。
• **LLM（大语言模型）**：DL 的子集，通常是基于 Transformer 的大规模预训练模型，擅长语言理解与生成，是当下生成式 AI 的主力。

用一张图把关系钉牢（后续章节会不断引用这张图的逻辑）：

```mermaid graph TD AI[AI: 人工智能] --> ML[ML: 机器学习] ML --> DL[DL: 深度学习] DL --> LLM[LLM: 大语言模型] AI --> Rule[规则/搜索/规划] ML --> Tree[树模型/线性模型/概率模型] ```

“用不用 LLM”的判断框架：任务性质 + 约束条件

中级读者常见的误区是：看到 LLM 火，就把所有问题都往“生成式”上套。更稳妥的做法是先判断任务类别与约束：

• **结构化表格数据 + 明确目标**：优先考虑传统 ML（如 LR、XGBoost、随机森林），成本低、效果稳、上线简单。

【标签：task/classification】【标签：data/tabular】

• **图像/语音/复杂非结构化信号**：优先 DL（CNN、Transformer 等），因为特征工程空间太大。

【标签：data/image】【标签：data/audio】

• **自然语言理解/生成、知识密集问答、总结改写**：LLM 或 LLM+RAG（检索增强生成）更匹配。

【标签：task/generation】【标签：pattern/RAG】

• **强实时、强可解释、强合规**：传统 ML 往往更易达标；LLM 需要额外的安全、审计与成本控制方案。

【标签：constraint/latency】【标签：constraint/compliance】

> 侧边栏（实践建议）： > 选技术栈的顺序通常应当是：业务目标 → 数据形态 → 约束（延迟/成本/合规/可解释）→ 再选模型家族。反过来做，失败概率会显著上升。

---

AI 项目全景流程：从需求到迭代的“工程化闭环”

一个可落地的 AI 项目不是“训练模型”四个字，而是一条链路。链路里任何一环断了，指标再好也无法交付。

```mermaid graph LR A[需求定义] --> B[数据获取/标注] B --> C[数据清洗与切分] C --> D[建模与训练] D --> E[离线评估] E --> F[部署上线] F --> G[监控与反馈] G --> H[迭代优化] H --> B ```

下面逐段拆解每一环的目标、产物与常见坑。

需求：把业务问题翻译成“可学习任务”

需求阶段的核心产物不是 PRD，而是一个可度量、可验证、可落地的学习问题定义。建议你把需求写成四句话（后续 MVE 会直接复用）：

1. 业务目标：要提升什么？（转化率、召回、降本、时效、风险降低） 2. 决策点：模型输出要驱动什么决策？（审批/排序/推荐/告警/分流/生成文案） 3. 成功指标：线上用什么衡量成功？（业务 KPI）离线用什么代理？（AUC、F1、MAPE、ROUGE…） 4. 约束条件：延迟、成本、解释、合规、可用性（SLA）分别是多少？

> 关键提醒： > 离线指标只是代理变量。如果你无法说明“离线提升 1% 能带来多少业务收益”，就很难在资源竞争中赢，也很难定义上线后的成败。

常见任务翻译示例（可作为你写需求时的模板）：

• “减少坏账” → 二分类：预测违约概率（输出为 score）【标签：task/classification】
• “更准确备货” → 回归/时间序列：预测未来销量【标签：task/regression】【标签：data/timeseries】
• “客服效率提升” → 文本分类（意图识别）+ 生成式总结/回复建议【标签：task/classification】【标签：task/generation】

数据：AI 项目真正的“主战场”

业界有个非常朴素的经验：多数项目的 60%–80% 时间会花在数据与评估设计上。这不是夸张，而是现实：数据质量与切分方式决定了你的模型上限与可信度。

数据阶段的产物建议至少包含：

• 数据字典（字段含义、取值范围、缺失含义、更新时间）
• 样本定义（什么是正例/负例、label 生成逻辑）
• 切分方案（train/val/test 的时间边界或人群边界）
• 数据版本号（日期、SQL/ETL 版本、抽样规则）

数据切分：防“数据泄漏”的第一道门

很多项目离线 AUC 0.95，上线一塌糊涂，根因是数据泄漏（Leakage）：模型在训练时看到了“未来信息”或“目标信息的影子”。

高频泄漏场景：

• **时间穿越**：用到了预测时点之后才产生的字段（例如“是否已退款”来预测“是否会退款”）。
• **目标泄漏**：label 的生成逻辑与特征共享了同一来源（例如用“是否触发风控规则”作为特征去预测“是否欺诈”，而 label 本身就由风控规则产生）。
• **分组泄漏**：同一用户/同一设备/同一订单在 train 与 test 同时出现。

切分策略建议（按常见度排序）：

• **时间序列/业务随时间变化**：按时间切分（更贴近上线）【标签：split/time】
• **用户级建模**：按用户切分，避免同一用户泄漏【标签：split/group】
• **样本独立且稳定**：随机切分（最简单，但风险也最大）【标签：split/random】

建模：从 Baseline 开始，而不是从“SOTA”开始

“做成”的核心能力之一是：先用最小成本跑通闭环。建模顺序建议：

1. 可解释 Baseline：线性模型/小树模型先上，快速建立基准线 2. 特征与数据迭代：你会发现，很多时候提升来自“更合理的特征与样本定义”，不是更大的模型 3. 再上复杂模型：当你确认数据与评估可靠、收益足够时，再投入 DL/LLM 成本

> 侧边栏（经验）： > 如果你连“朴素 baseline 为什么失败”都说不清楚，上复杂模型只会让问题更难定位。

评估：离线评估要“可信”，线上评估要“可归因”

评估必须同时回答两件事：

• 模型是否比基线好？（离线可信）
• 模型上线后是否真的带来收益？（线上可归因）

常见离线指标与适用场景：

• 二分类：AUC、PR-AUC、F1

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

• 回归：MAE、RMSE、MAPE（注意 MAPE 在接近 0 时会爆炸）
• 生成：自动指标（BLEU/ROUGE）+ 人评（更关键）+ 线上行为指标（点击、采纳率、工单时长）

离线到线上的关键桥梁：

• 指标要能映射业务：例如风控不是追求 AUC，而是追求“在固定通过率下坏账下降多少”
• 评估要模拟真实流量：包括分布、延迟、缺失、脏数据

部署：不是“把模型保存下来”，而是把能力交付出去

部署方式通常有三种：

• **离线批处理**：每天/每小时出一批分数或标签，稳定、便宜【标签：deploy/batch】
• **在线推理服务**：用户请求实时返回结果，对延迟和稳定性要求高【标签：deploy/online】
• **边缘/端侧**：在手机/设备端推理，强调模型压缩与隐私【标签：deploy/edge】

部署阶段的隐性成本经常来自：

• 特征工程线上一致性（训练用的特征，线上能否同样计算出来）
• 依赖与环境（CUDA、驱动、库版本）
• 监控与回滚（线上出了问题怎么快速止损）

监控与迭代：真正的“做成”发生在上线之后

上线不是终点，而是迭代的开始。你需要监控三类信号：

• **数据漂移**：特征分布变了（节假日、活动、渠道变化）【标签：monitor/drift】
• **概念漂移**：同样特征对应的标签规律变了（规则调整、市场变化）
• **系统指标**：延迟、错误率、吞吐、成本

---

三个案例：把“全景流程”落到手上

下面三个案例刻意覆盖不同数据形态与交付方式，你可以把它们当作“迁移模板”：换行业、换字段，方法论仍成立。

案例 A：二分类风控（表格数据）——指标很好，但业务亏钱

【标签：task/classification】【标签：data/tabular】【标签：deploy/batch】

需求翻译

• 业务目标：降低坏账
• 决策点：是否通过/是否加审
• 约束：通过率不能低于某阈值（否则业务量下滑）

常见错误：只看 AUC，不看决策阈值下的成本 风控的核心往往是一个成本矩阵：错放（把坏人当好人）和错杀（把好人当坏人）代价完全不同。你应该把评估改写为“在固定通过率下，坏账率降低多少”，或者“期望损失最小”。

一个简化的期望损失示意： $$\mathbb{E}[Loss]=C_{FP}\cdot FP + C_{FN}\cdot FN$$ 其中 $C_{FN}$ 往往远大于 $C_{FP}$。

数据泄漏示例

• 特征里包含“是否触发人工复核”，而人工复核本身是基于风险判断产生的，这等同于把部分 label 信息塞回了特征。

可落地 Baseline

• 逻辑回归（标准化 + 类别特征 one-hot）
• 输出概率作为 score，业务侧按通过率或损失最小选择阈值
• 批处理产出：`user_id, score, decision`

上线要点

• 必须固化：特征计算时间点、阈值版本、模型版本
• 监控：通过率、坏账率、分数分布漂移

案例 B：需求预测（时间序列回归）——离线误差低，上线缺货更严重

【标签：task/regression】【标签：data/timeseries】【标签：split/time】

需求翻译

• 业务目标：缺货率下降/库存周转提升
• 决策点：采购/补货数量
• 约束：预测必须提前 N 天给到供应链；宁可高估还是低估由业务决定

常见错误 1：随机切分导致“未来泄漏” 时间序列必须用时间切分，否则模型在训练时可能看到未来季节性模式，离线误差被虚假压低。

常见错误 2：只优化 MSE，忽略业务偏好 对缺货敏感的业务，低估的代价大于高估，你可能需要不对称损失或分位数回归思路（例如预测 P90 而不是均值）。

Baseline 推荐

• 朴素季节性基线：同周同日均值/移动平均
• 再上轻量模型：XGBoost/LightGBM + 滞后特征（lag）、节假日、活动信息
• 指标：MAE + 分品类加权（高销量品更重要）

上线要点

• 预测窗口、特征可用性（活动信息是否提前确定）
• 监控：误差分布、品类漂移、活动期间的异常

案例 C：客服工单总结（LLM 生成）——看起来很强，但风险不可控

【标签：task/generation】【标签：data/text】【标签：pattern/RAG】【标签：constraint/compliance】

需求翻译

• 业务目标：降低客服处理时长、提升一次解决率
• 决策点：生成总结/建议回复（通常先“辅助”，再逐步“自动化”）
• 约束：不能泄露隐私；不能编造政策；输出可审计

MVE 的正确起手式 1. 先做“辅助总结”：把长对话压缩成结构化要点（用户诉求/已尝试/待处理） 2. 再做“建议回复”：需要接入知识库，避免胡编（RAG） 3. 最后才考虑“自动发送”：必须引入审核与安全策略

评估的现实做法

• 自动指标只能参考；真正重要的是**人评与业务指标**：采纳率、平均处理时长、升级率、投诉率
• 必须做安全评测：敏感信息泄露、越权承诺、错误政策引用

上线护栏

• 明确系统边界：仅基于提供的知识库回答；无法确认则提示转人工
• 记录可追溯：输入、检索片段、输出、模型版本、提示词版本
• 成本控制：缓存、分层模型（简单问题用小模型）

---

常见误区清单：这些坑一踩就“做不成”

下面这份清单建议你在每次立项、每次上线前都过一遍（后续章节会反复引用）。

1. 只看指标不看业务：AUC/ROUGE 提升并不等于 KPI 提升 2. 数据泄漏：时间穿越、目标泄漏、分组泄漏是三大元凶 3. 过拟合与“调参幻觉”：在同一验证集上反复试，验证集变成了训练集 4. 不可复现：同一代码跑两次结果不同，或半年后无法还原数据与配置 5. 离线-线上分布不一致：线上缺失值、异常值、字段口径变化导致崩盘 6. 忽视部署约束：延迟、吞吐、成本、可解释、合规没有提前设计 7. 没有监控与回滚：上线后发现异常却无法定位、无法止损

---

推荐开发环境与工具栈：让实验可复现、上线可迁移

你不需要一开始就把 MLOps 搭到最豪华，但至少要做到：环境可复制、依赖可锁定、数据可追踪、实验可对比。

Python + 科学计算基础栈（建议作为全书统一底座）

• Python 3.10+（建议 3.11 也可，但注意部分库兼容）
• NumPy / Pandas：数据处理
• scikit-learn：传统 ML 与评估工具
• PyTorch：深度学习（LLM/Transformer 生态也更常用）
• CUDA（可选）：有 GPU 再装，没 GPU 也能做大量实验
• Docker：环境封装与部署迁移

一个尽量“少踩坑”的安装示例（二选一即可）：

```bash

方案 A：conda

conda create -n ai-practice python=3.10 -y conda activate ai-practice pip install -U numpy pandas scikit-learn torch

方案 B：venv（更轻量）

python -m venv .venv

macOS/Linux

source .venv/bin/activate

Windows（PowerShell）

.venv\Scripts\Activate.ps1

pip install -U pip pip install -U numpy pandas scikit-learn torch ```

检查 PyTorch 与 CUDA（可选）：

```python import torch print("torch:", torch.__version__) print("cuda available:", torch.cuda.is_available()) if torch.cuda.is_available(): print("cuda:", torch.version.cuda) print("gpu:", torch.cuda.get_device_name(0)) ```

可复现的最低标准：把“能跑”升级为“能复跑”

建议你把以下内容当作项目硬性规范（尤其是团队协作时）：

• **固定随机种子**（但要知道：GPU 下仍可能存在非确定性算子）
• **记录依赖版本**：`requirements.txt` 或 `pyproject` 锁定
• **记录数据版本**：数据抽取时间、SQL/ETL 版本、抽样规则
• **记录配置**：超参、特征列表、切分边界、阈值策略
• **记录代码版本**：至少记录 git commit hash

示例：常用随机种子设置

```python import os, random import numpy as np

seed = 42 random.seed(seed) np.random.seed(seed) os.environ["PYTHONHASHSEED"] = str(seed)

try: import torch torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) except Exception: pass ```

Docker：让你的环境“可交付”

当你需要把实验交给同事、交给线上、或在不同机器跑一致结果时，Docker 往往是最省沟通成本的方式。

一个极简 `Dockerfile`（CPU 版本示意）：

```dockerfile FROM python:3.10-slim

WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt

COPY . . CMD ["python", "main.py"] ```

---

MVE：最小可行实验（Minimum Viable Experiment）

很多项目不是败在技术，而是败在“投入太大、验证太晚”。MVE 的目标是：用最小成本回答最关键的问题——“这件事是否值得继续做下去？下一步该投哪里？”

MVE 的核心思想：把不确定性分层消灭

你可