深度学习项目流程

零基础做第一个深度学习项目，最容易卡在两头：一上来就纠结选哪个模型，或者模型跑通了却不知道怎么把它变成别人能用的东西。这篇不教你调参玄学，而是把「数据准备—基线—训练—评估—部署—监控」这条链路拆成可执行的动作，告诉你每一步的产出物是什么、什么情况下这一步可以跳过，以及哪几件事必须在动手前就想清楚。

零基础做第一个深度学习项目，最容易卡在两头：一上来就纠结选哪个模型，或者模型在本地跑通了却不知道怎么让别人用上。这篇不聊调参玄学，而是把「数据准备—基线—训练—评估—部署—监控」这条链路拆成能照着做的动作，每一步都告诉你产出物是什么、拿什么当完成标准、什么时候该停手回退。

先说一个前提：下面这套流程是给「有明确任务、能拿到数据、需要交付结果」的项目用的。如果你只是想练手跑个公开数据集，部署和监控两节可以大幅简化甚至跳过；反过来，如果任务本身没定义清楚，后面每一步都会返工。

先定义问题，再谈模型

最容易被跳过的其实是第一步。很多人拿到数据就开始想模型结构，结果做到一半发现「判断错了的代价」根本没想清楚：漏检和误报哪个更严重？这个答案会直接决定后面用哪类指标、阈值卡在哪。先把它写下来，比选模型重要得多。

任务形态

分类、回归、生成还是检索；先确定输入和输出分别长什么样，别用「智能一下」这种描述

验收口径

看什么指标、在什么数据上算、达到多少算能用；这三个不定，后面所有评估都是空的

出错代价

判断错了会怎样；是浪费一次点击，还是影响真金白银，权重完全不同

兜底边界

哪些情况模型不该给答案，比如低置信、超范围输入，以及这时人和系统怎么接管

• 把业务描述翻译成一句话：输入是什么、输出是什么、什么算对什么算错
• 和需求方确认「能用」的标准，最好能落到一个可测量的口径上
• 列出模型不该回答的场景，并写明这些场景下走什么流程
• 把上面的结论写成半页纸，动手前先让相关的人看一眼

数据准备：先把脏活干完

数据阶段花的时间通常比训练多，而且很难压缩。这个阶段的目标不是「数据越多越好」，而是「数据能不能支撑你前面定的验收口径」。来源是否合规、标注口径是否统一、切分有没有时间泄漏，这三件事没处理好，后面模型再漂亮也是白搭。

1. 来源与合规逐条确认数据从哪来、有没有使用授权；拿不准的字段先剔掉，别等上线前才发现问题
2. 标注口径先标一小批做一致性检查，两个人标同一批看重合度；口径不统一就回去改规范
3. 切分方式按时间切还是随机切，取决于线上是不是预测未来；涉及时间序列时随机切会直接造成泄漏
4. 分布核对按类别、按来源统计样本量，找出长尾和缺失，判断是要补数据还是收窄任务范围

判断标准很简单：数据处理能不能一键重跑。如果每次都靠手工点几下、改几个文件名，那这个项目已经埋了雷。把清洗、切分、统计固化成脚本，换台机器也能跑出同样结果，才算这一步过关。术语不统一的话，可以先去 /ai-dict/category/tech 把概念对齐，省得团队里各说各话。

先做基线，别急着上大模型

基线的意义不是交差，而是给后面所有改动一个参照物。花几个小时用规则、传统方法或一个小模型跑出个分数，后面每换一次方案，你都能回答「到底提升了多少」。没有基线，涨了跌了都是感觉。

• 最简单可行的方案先跑通，哪怕准确率不好看，先有个数
• 记录基线用的数据切分和指标口径，后面必须一模一样地比
• 基线结果存下来，换人接手时能复现
• 如果规则方案已经能满足验收口径，就别急着上模型

什么情况下可以跳过基线？任务本身没有可解释的简单做法，或者数据量小到只能靠预训练模型兜底。除此之外，跳过基线通常意味着你后面没法判断复杂方案值不值。

训练环节：把配置和结果对应起来

训练阶段最大的坑不是调不好参，而是「改了一堆东西，不知道是谁起的作用」。纪律比技巧重要：一次只动一个变量，数据、模型、超参分开试，每次实验的配置和结果都留档。

算力不够时有个大致顺序：先降模型规模或输入尺寸，再考虑量化和租卡。具体显存和卡数怎么估，别凭感觉，去 /compute/sizing 按自己的模型算一遍。训练阶段自己走到哪一步了，也可以对照 /training 里的分类理清楚，免得在错的阶段反复折腾。

# 每次实验固定三件事：配置、指标、产出物
python train.py --config conf/exp_001.yaml \\
  --out runs/exp_001 \\
  --seed 42
# 跑完立刻把 config 和指标一起归档，别等想起来再补

评估：别只看一个总分

总分是最容易骗人的指标。同一个模型，在长输入上表现好、短输入上崩掉，平均下来可能还是「不错」。所以评估要按切片看：不同类别、不同来源、不同长度分别多少分，哪一类拖后腿一目了然。

• 按类别、来源、输入长度分别统计，找出被平均掩盖的短板
• 固定一批真实场景的疑难样例，每次改动后都跑一遍
• 关注指标和业务口径的对应关系，别只看模型侧数字
• 对比公开结果时留意题目饱和和任务不匹配，判断方法见 /benchmarks 与 /benchmarks/registry

疑难样例库是这个阶段最值得积累的资产。它不需要多，几十条覆盖典型失败场景就够，作用是在你每次「优化」之后固定验一遍，防止改好一个坏一个。评估标准拿不准时，站内 /tools/quality-check 可以作为自查起点，先把口径对齐再谈提升。

部署：从能跑到能用

本地跑通和线上能用之间差着一整套东西。先明确形态：是离线批量跑，还是接口实时响应？前者关心吞吐和总耗时，后者关心延迟、并发和超时处理，两者的优化方向完全不同。

1. 定形态写清楚是批量还是实时、调用方是谁、失败时对方看到什么
2. 测基线上线前先量一遍接口延迟和单次耗时，用 /tools/speed-test 测出延迟基线
3. 处理异常超时、空输入、超范围输入分别怎么返回，别让异常直接抛给调用方
4. 选路线租卡还是调接口，成本口径去 /compute/platforms 和 /compute 对齐后再决定

这里没有绝对答案，判断标准是你的场景对延迟和成本的容忍度。对响应时间敏感、调用量又大的场景，自建推理通常更可控；调用量小、想快速验证的，直接调接口往往更划算。具体数字到站内对应页面核对当时的行情，别用别人的结论套自己的场景。

监控与迭代：上线不是终点

上线后要盯三类信号：输入分布有没有漂移、输出质量有没有下滑、调用错误率和延迟有没有异常。前两类靠定期抽样和指标对比，第三类靠日志和告警。没有这三样，模型退化了你也只能等用户投诉。

• 留一条回退路径，新版本出问题能切回旧版本，别让回滚变成临时救火
• 把线上抽样结果和疑难样例库定期比对，发现新的失败模式就补进去
• 按影响面和成本排优先级，别条件反射式地重训
• 区分「该重训」和「只需调阈值或补规则」两种情况的处理方式

什么时候该重训？数据分布已经明显变了、或者老模型在新场景上系统性变差时。如果只是个别边界情况出错，补规则或调阈值往往更快更省。先按影响面排序，再决定投入。

新手最容易踩的几个坑

这几个坑的共同点是：出问题时不会报错，只会让你得出错误的结论。所以它们没法靠调试发现，只能靠流程上的检查项提前拦住。把上面这张表当成上线前的自查清单，逐条过一遍再交付。

深度学习项目的难点通常不在模型，而在那些不出声、却让你判断错的地方。