1. 从零搭建AI工程体系，为什么我劝你别急着调包
"ai-engineering-from-scratch"这个标题，第一次看到的时候我愣了一下。不是因为陌生，恰恰相反——过去两年里，我见过太多人问同一个问题：想入门AI工程，到底该从哪儿下手？是先把Python学透，还是直接上框架跑模型？是先啃论文，还是先做项目？
我自己的答案是：从零开始，但不是从零学Python。这两件事经常被混为一谈。所谓"from scratch"，指的是你要亲手把一条AI工程链路搭起来——数据怎么进、模型怎么训、服务怎么出、线上怎么盯——而不是指你要从变量类型开始学编程。这个区别很关键，因为它决定了你三个月后是能独立交付一个AI服务，还是还在纠结列表推导式。
这篇文章适合三类人：第一类是有一定编程基础、想转AI工程方向的开发者；第二类是已经在做AI相关项目、但链路是别人搭好的、自己只会调API的工程师；第三类是想搞清楚AI系统到底怎么运转的产品或项目负责人。我会把整条链路的搭建思路、关键环节、踩过的坑，尽量讲透。不堆术语，不搞玄学，能抄的作业直接给你。
先说一个我反复验证过的判断：AI工程的核心难点，从来不在模型本身。模型是开源的，论文是公开的，算力是可以租的。真正拉开差距的，是你怎么把数据喂进去、怎么把结果稳定地吐出来、怎么在出问题的时候快速定位。这三件事，才是"from scratch"要解决的东西。
2. 整体链路怎么设计，先想清楚再动手
2.1 一条最小可用的AI工程链路长什么样
我习惯把AI工程链路拆成五段：数据层、训练层、评估层、服务层、监控层。这五段不是并列关系，是有先后依赖的。很多人一上来就冲训练层，结果数据是脏的，训出来的模型自己都不敢用。
数据层负责采集、清洗、标注、版本管理。训练层负责模型选择、微调、超参调整。评估层负责离线指标和线上指标的对齐。服务层负责推理接口、并发处理、降级策略。监控层负责延迟、错误率、数据漂移的观测。
这五段里，我建议新手把70%的精力放在数据层和评估层。原因很简单：训练层现在有太多工具帮你兜底，但数据和评估是没人能替你的。你喂进去什么，模型就学什么；你怎么评估，就决定了你优化什么方向。
提示：不要一开始就追求全链路自动化。先把每一段手动跑通一遍，知道每个环节的输入输出长什么样，再考虑用工具串起来。
2.2 技术选型背后的取舍逻辑
选型这件事，我的原则是"够用就好，留好退路"。举几个具体例子。
数据处理用Pandas还是Spark？数据量在千万行以内，Pandas完全够用，别为了显得专业硬上Spark，运维成本高得离谱。超过这个量级再考虑分布式。
训练框架用PyTorch还是TensorFlow？2024年之后入行的话，我建议直接PyTorch。生态活跃、调试直观、社区资源多。TensorFlow在工业部署上有历史积累，但新项目没必要给自己加难度。
服务框架用FastAPI还是Flask？做AI推理服务，FastAPI的异步支持和自动文档生成能省你不少事。Flask更轻，但你要自己处理并发和文档。
向量库用FAISS还是Milvus？单机小规模用FAISS，部署简单、零依赖。要做分布式、要支持增删改查，再上Milvus。
这些选择没有绝对对错，关键是你要知道每个选择的代价是什么。我见过太多项目因为一开始选型过重，后期维护成本压垮了整个团队。
2.3 为什么我坚持先跑通再优化
有个坑我踩过不止一次：在链路还没跑通的时候，就开始优化某个环节的性能。结果链路一通，发现那个环节根本不是瓶颈。
正确的顺序是：先用最笨的方法把整条链路跑通，拿到一个能用的baseline，然后再看哪里慢、哪里不准、哪里不稳定。这时候你的优化才有靶子。
比如做文本分类，先用TF-IDF加逻辑回归跑一版，准确率可能只有80%，但你知道整条链路是通的。然后再换BERT微调，看能提升多少。如果一上来就上大模型，出了问题你都不知道是数据的问题、模型的问题还是服务的问题。
3. 数据层：脏活累活才是真正的护城河
3.1 数据采集与清洗的实操要点
数据采集这一步，很多人以为就是爬数据或者导数据库。实际上，采集的核心是"定义清楚你要什么"。我一般会先写一份数据规格说明，包含字段名、类型、取值范围、是否必填、缺失处理方式。这份说明写清楚了，后面清洗和标注才有依据。
清洗环节，我总结了一个"三查"流程。一查重复：完全重复的直接去重，近似重复的用SimHash或MinHash找出来人工确认。二查异常：数值型字段看分布，超出3倍标准差的标记出来；文本型字段看长度分布，过短过长的单独处理。三查一致性：同一实体的不同表述要统一，比如"北京"和"北京市"要归一化。
注意：清洗规则一定要版本化。我吃过亏，改了清洗逻辑但没记录，两个月后复现实验发现数据对不上，排查了一整天才找到原因。
3.2 标注体系怎么设计才不返工
标注是数据层最容易被低估的环节。我见过一个项目，标注做了三轮，每轮都推翻重来，浪费了两个月。问题出在一开始没设计好标注体系。
我的做法是：先标100条做试点，让标注员和算法工程师一起过一遍，把边界case讨论清楚，形成标注手册。手册里要包含正例、负例、边界例，每个类别至少5个例子。然后再批量标注。
标注质量怎么控？三个手段：交叉标注（同一批数据两个人标，算一致性）、抽检（每天抽10%复核）、埋雷（故意放一些已知答案的数据，看标注员有没有认真标）。一致性低于85%就要停下来重新对齐标准。
3.3 数据版本管理，别等出事才后悔
数据版本管理这件事，没出事的时候觉得多余，出事的时候觉得救命。我现在的做法是：每次数据变更都打tag，记录变更内容、变更人、变更时间。数据文件用DVC或者类似的工具管理，不要直接扔在共享盘里。
为什么要这么较真？因为模型效果出问题的时候，你第一个要排查的就是数据。如果数据版本混乱，你连"这次和上次用的是不是同一份数据"都说不清楚，排查就无从谈起。
4. 训练与评估：别让模型在你看不见的地方翻车
4.1 模型选型的三个判断维度
选模型不是越大越好，我一般看三个维度：任务复杂度、数据量、推理成本。
任务简单、数据量小，用传统机器学习就够了，别硬上深度学习。任务复杂、数据量充足，再考虑预训练模型微调。推理成本这块经常被忽略——一个准确率高2%但推理慢10倍的模型，在线上可能是灾难。
具体到预训练模型的选择，我的经验是：文本任务优先看中文社区的实际评测，不要只看论文指标。很多模型在英文benchmark上漂亮，中文场景一塌糊涂。图像任务看推理速度，移动端部署和服务器部署选型完全不同。
4.2 训练过程中的关键监控指标
训练不是跑起来就不管了。我一般盯四个指标：训练loss、验证loss、学习率、梯度范数。
训练loss下降但验证loss上升，过拟合了，该加正则或早停。两个loss都不降，学习率可能太大或太小。梯度范数突然变大，可能有异常样本。这些判断听起来基础，但实际训练中80%的问题都能从这四个指标看出来。
提示：训练日志一定要结构化存储，方便后面画曲线对比。我习惯用CSV存每个step的指标，简单直接，不依赖任何平台。
4.3 离线评估与线上表现的对齐
离线评估漂亮、线上一塌糊涂，这是AI工程最经典的翻车场景。原因通常有三个：评估集和线上数据分布不一致、评估指标和业务指标不匹配、线上有离线没考虑到的因素。
我的做法是：离线评估集一定要从线上真实数据里采样，不要用公开数据集凑数。评估指标除了准确率、F1这些，还要加上业务指标，比如点击率、转化率。上线前做小流量AB测试，观察至少一周再全量。
5. 服务与监控：让模型真正跑在生产环境
5.1 推理服务的性能优化思路
推理服务的第一要务是稳定，第二是快。稳定这块，核心是做好降级：模型服务挂了，要有兜底逻辑，哪怕返回默认值也比报错强。
性能优化我一般按这个顺序来：先看批处理，把单条推理改成批量推理，吞吐量能提升好几倍。再看量化，FP32转FP16或INT8，速度提升明显，精度损失通常可接受。最后看模型蒸馏或剪枝，这个成本高，非必要不做。
并发处理用异步框架，FastAPI的async支持能让你用少量资源扛住更多请求。但要注意，模型推理本身是CPU或GPU密集型的，异步只能解决IO等待，真正的瓶颈还是在计算。
5.2 监控体系怎么搭才有效
监控不是装个Prometheus就完事了。我一般分三层：系统层看CPU、内存、GPU利用率；服务层看QPS、延迟、错误率；业务层看模型输出的分布变化。
业务层监控最容易被忽略，但最重要。模型输出分布突然偏移，往往意味着线上数据变了，模型该更新了。我习惯每天统计一次输出的类别分布，和上周对比，偏差超过阈值就告警。
5.3 模型更新的节奏把控
模型更新不是越频繁越好。更新太频繁，稳定性差；更新太慢，效果衰减。我的经验是：小版本（微调）两周一次，大版本（换模型）一个季度一次。每次更新都要有回滚方案，新模型上线后观察至少三天再下掉旧模型。
6. 常见问题与排查技巧实录
6.1 训练不收敛的排查清单
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| loss不下降 | 学习率过大 | 降低10倍重试 |
| loss震荡 | batch size太小 | 增大batch size |
| loss变NaN | 梯度爆炸 | 加梯度裁剪 |
| 验证loss上升 | 过拟合 | 加正则或早停 |
6.2 线上服务不稳定的典型场景
最常见的是内存泄漏。推理服务跑几天内存涨满，重启就好，过几天又满。排查方法是看内存增长曲线，如果和请求量成正比，多半是缓存没清理；如果和时间成正比，可能是日志或中间结果没释放。
另一个是冷启动慢。模型第一次加载要几十秒，导致首批请求超时。解决办法是服务启动时预热，用几条假数据先跑一遍。
6.3 我踩过的三个印象最深的坑
第一个坑：数据泄露。评估集里混进了训练集的数据，离线指标虚高，上线打脸。后来我强制要求评估集和训练集做ID去重。
第二个坑：版本错配。服务用的模型和评估的模型不是同一个版本，排查了半天。后来我强制要求模型文件带版本号，服务启动时打印版本。
第三个坑：监控盲区。只监控了服务层，没监控数据层，线上数据格式变了导致模型输出异常，两天后才发现。后来加了数据schema校验。
7. 一些掏心窝子的经验
做AI工程这几年，我最大的体会是：这行拼的不是谁模型调得好，是谁的工程体系稳。模型效果差一点，业务能忍；服务天天挂，业务忍不了。
所以如果你刚开始搭链路，我的建议是：先把数据和服务做扎实，模型可以慢慢调。数据是根，服务是命，模型是锦上添花。
另外，别迷信工具。工具是帮你提效的，不是帮你思考的。我见过太多人花大量时间折腾工具链，结果核心问题一个没解决。工具够用就行，把省下来的时间花在理解数据和业务上。
最后分享一个小技巧：每次做完一个项目，写一份复盘文档，记录做了什么、为什么这么做、哪里可以改进。这份文档三个月后你自己看，价值比任何教程都大。因为那是你自己的经验，不是别人的。
