1. 从零搭建AI工程体系为什么我劝你别一上来就啃论文ai-engineering-from-scratch这个标题第一次看到的时候我愣了一下。不是因为它有多高深恰恰相反——它戳中了一个特别尴尬的现实现在想入门AI工程的人绝大多数都卡在从哪开始这一步。网上要么是三个月速成调包侠的营销课要么是直接甩给你一篇Transformer论文让你硬啃中间那层一个真实项目到底怎么从零搭起来的东西几乎没人讲。我自己带过几个刚毕业的同事也帮朋友做过从传统后端转AI方向的规划。最深的感受是AI工程和机器学习研究是两码事。研究关注的是这个模型能不能在某个benchmark上刷到SOTA工程关注的是这套东西明天上线之后用户量翻十倍会不会崩、模型效果掉了怎么快速定位、换一版权重需不需要重写整个服务。前者是实验室思维后者是产品思维。而from scratch这个词我理解它真正的价值不在于让你手写一个反向传播虽然手写一遍确实有用而在于让你亲手把数据、训练、评估、部署、监控这条链路完整地走一遍哪怕每一环都用最朴素的方案。这篇文章适合谁如果你已经会写Python懂一点numpy和pandas但对一个AI项目从想法到跑起来没有完整概念那这篇就是写给你的。如果你已经能调库跑通模型但每次遇到线上问题就抓瞎那这篇也能帮你把工程视角补上。我会尽量把每一步为什么这么做讲清楚而不是甩一堆代码让你抄。毕竟工具会过时判断力不会。2. 整体设计思路为什么我选择最小可运行闭环而不是完美架构2.1 从零开始最容易踩的坑过度设计我见过太多人做AI项目第一步就是画一张特别漂亮的架构图数据湖、特征平台、模型注册中心、A/B测试框架、实时推理集群恨不得把大厂那套全搬过来。结果两周过去一行能跑的代码都没有。这不是能力问题是顺序问题。从零搭建的核心矛盾是你对业务的理解、对数据的理解、对模型边界的理解全都是模糊的。在这种模糊状态下设计出来的完美架构大概率是错的。所以我的思路很明确——先搭一个最小可运行闭环Minimum Viable Loop让数据能进来、模型能训练、结果能出来、效果能看见。这个闭环哪怕丑一点、慢一点、手动一点都没关系因为它能给你反馈。有了反馈你才知道下一步该优化哪里。具体来说这个闭环包含五个环节数据准备、特征处理、模型训练、评估验证、推理服务。每个环节我都倾向于先用最简单直接的方案比如数据先用CSV而不是数据湖特征先用pandas现算而不是特征平台模型先跑通一个baseline而不是纠结选哪个SOTA服务先用Flask起一个接口而不是上Kubernetes。等闭环跑通了哪个环节成为瓶颈再针对性地替换。2.2 技术选型的取舍逻辑选型这件事我的原则是用你debug得动的工具。什么意思如果一个工具出了问题你完全不知道从哪查那它再先进也不该出现在从零搭建的阶段。拿深度学习框架来说PyTorch和TensorFlow都能用但我更推荐PyTorch原因是它的动态图机制让调试变得直观——你可以像写普通Python一样print中间结果出错时的报错信息也更友好。对于从零开始的人来说能快速定位问题比性能优化重要一百倍。再比如实验管理。很多人一上来就上MLflow或者Weights Biases这没错但在最开始我建议你连这些都不用就用一个Excel或者CSV记录每次实验的超参数和指标。为什么因为你需要先亲手感受哪些参数影响大、哪些指标会骗人这个体感是工具给不了你的。等你实验做到几十上百次手动记录开始混乱了再上工具那时候你才知道自己真正需要工具帮你解决什么。数据处理同理。pandas在数据量小于内存的时候是最舒服的选择别急着上Spark。我见过一个团队几万条数据非要用分布式框架处理光是环境配置就折腾了一周最后发现单机pandas跑完只要三秒。2.3 目录结构一开始就要想清楚的事虽然我说不要过度设计但有一件事必须一开始就做对——目录结构。这不是洁癖是因为AI项目的文件类型特别杂原始数据、处理后的数据、配置文件、模型权重、日志、notebook、脚本。如果混在一起两周后你自己都找不到东西。我常用的结构是这样的project/ ├── data/ │ ├── raw/ # 原始数据只读不改 │ ├── interim/ # 中间处理结果 │ └── processed/ # 最终用于训练的数据 ├── src/ │ ├── data/ # 数据处理脚本 │ ├── features/ # 特征工程 │ ├── models/ # 模型定义与训练 │ └── serving/ # 推理服务 ├── configs/ # 配置文件 ├── experiments/ # 实验记录 ├── notebooks/ # 探索性分析 └── tests/ # 测试这个结构的关键在于data目录的分层。raw永远不动这是你的事实来源任何时候都能重新生成后面所有东西。interim和processed都是可以删掉重跑的。这个习惯能救命——当你发现特征处理有bug时只要回到raw重跑一遍就行不用去猜哪一步被污染了。提示notebook只用来做探索和可视化任何要复用的逻辑都要沉淀成src里的函数或脚本。我踩过的坑就是notebook里写了一堆处理逻辑结果训练脚本里又复制一遍两边慢慢就不一致了最后排查了半天才发现是特征对不上。3. 核心环节拆解数据、特征、训练到底怎么做才不返工3.1 数据准备先搞清楚标签从哪来AI项目里最容易被低估的环节就是数据。大家总觉得模型才是核心但实际上一个项目能不能成八成取决于数据质量。而数据环节里最要命的问题是标签从哪来、可不可信。我做过一个文本分类的项目一开始拿到的标注数据是运营同事随手打的标签准确率大概七成。用这批数据训练出来的模型离线指标看着还行一上线就崩。后来我们抽了五百条人工重新标注发现原来的标签里有一大批是错的。所以从零开始第一件事不是写模型是抽样检查你的标签质量。具体做法是随机抽100到200条自己一条条看统计错误率。如果错误率超过10%那这批数据就得先清洗否则后面全是白费功夫。数据准备的另一个重点是划分训练集、验证集、测试集。这里有个细节很多人忽略划分要按时间或者按业务维度不能纯随机。比如你做的是用户行为预测随机划分会导致同一个用户的数据同时出现在训练集和测试集里模型等于见过测试数据指标虚高。正确做法是按时间切用过去的数据训练用未来的数据测试这才符合真实场景。3.2 特征处理别急着上复杂方案特征工程这块新手最容易犯的错是一步到位。看到别人用embedding、用交叉特征、用自动特征工程自己也跟着上结果连最基础的缺失值处理都没做好。我的建议是分三步走。第一步只做最必要的处理缺失值填充、类别特征编码、数值特征归一化。这三件事做完先跑一个baseline。第二步看baseline的错误案例分析模型在哪些样本上错得多针对性地加特征。第三步才考虑复杂的特征交叉或者表示学习。归一化这件事值得单独说。很多人知道要归一化但不知道为什么。简单讲如果两个特征的数值范围差很多比如一个是0到1一个是0到10000那么基于距离的模型比如KNN、SVM和基于梯度的模型比如神经网络都会被大范围的特征主导小范围的特征等于没起作用。归一化就是把它们拉到同一个尺度上。常用的方法有min-max归一化和z-score标准化前者把值压到0到1后者变成均值0方差1。选哪个取决于你的数据分布如果数据有极端离群值z-score更稳一些。类别特征编码也有讲究。最朴素的是one-hot但类别一多维度就爆炸。这时候可以用目标编码target encoding用每个类别对应的标签均值来替代。但目标编码有个坑——容易过拟合尤其是类别样本很少的时候。解决办法是加平滑或者用交叉验证的方式计算编码值。3.3 模型训练baseline比SOTA重要从零开始做AI工程第一个模型永远应该是baseline而且越简单越好。什么叫简单逻辑回归、决策树、甚至就是猜多数类都算。为什么因为baseline给你一个下限让你知道什么都不做能到什么水平。如果baseline准确率是80%你费半天劲搞了个深度模型到82%那这两点提升值不值得就得好好算算账了。我一般会先跑一个逻辑回归或者梯度提升树比如LightGBM。这两个模型训练快、可解释性强、对特征处理要求不高非常适合快速验证这批数据里到底有没有信号。如果连这两个模型都跑不出比随机猜好的结果那大概率是数据或者标签有问题这时候上深度模型也是白搭。等baseline跑通了再考虑上神经网络。上神经网络的时候第一个要调的不是网络结构是学习率。学习率太大loss会震荡甚至发散太小收敛慢得让人怀疑人生。我的经验是从1e-3开始试如果loss不降就降到1e-4如果震荡就降到1e-4或者加warmup。batch size一般从32或64开始显存够就往上加但要注意batch size变了学习率通常也要跟着调。训练过程中一定要盯着训练集和验证集的loss曲线。如果训练loss一直降但验证loss开始涨那就是过拟合了该加正则化或者早停。如果两个都不降那是欠拟合该加模型容量或者检查数据。这个判断逻辑听起来简单但实际排查的时候很多人会忽略验证loss这个信号只看训练loss结果模型在训练集上完美一测试就露馅。注意随机种子一定要固定。我见过太多这次结果好下次结果差的情况最后发现只是没固定种子。在从零搭建阶段可复现性比绝对性能重要得多否则你根本不知道指标变化是因为你的改动还是因为随机性。4. 实操全流程从空目录到能跑的推理服务4.1 环境搭建与依赖管理环境这块我强烈建议用虚拟环境别在系统Python里直接装。conda或者venv都行我个人偏好conda因为AI相关的包依赖比较复杂conda处理得好一些。conda create -n ai-scratch python3.10 conda activate ai-scratch pip install numpy pandas scikit-learn lightgbm torch flask依赖管理有个细节一定要把版本号写进requirements.txt。AI生态更新快今天能跑的代码下个月换个版本可能就报错。我一般用pip freeze requirements.txt生成但会手动检查一遍把一些不必要的间接依赖去掉。环境搭好后第一件事是写一个check_env.py把关键库的版本打印出来顺便跑一个最小的矩阵运算验证GPU能不能用。这个脚本看起来多余但当你换机器或者过几个月回来重跑时它能帮你快速确认环境有没有问题。4.2 数据处理脚本的编写要点数据处理脚本我建议写成函数式的每个处理步骤是一个独立函数主流程按顺序调用。这样做的好处是每一步都能单独测试出问题容易定位。def load_raw(path): return pd.read_csv(path) def clean_missing(df): df df.dropna(subset[label]) df[age] df[age].fillna(df[age].median()) return df def encode_categorical(df, cols): for col in cols: df[col] df[col].astype(category).cat.codes return df def split_data(df, time_col, split_ratio0.8): df df.sort_values(time_col) idx int(len(df) * split_ratio) return df.iloc[:idx], df.iloc[idx:]这里有个实操心得处理后的数据一定要落盘别每次训练都重新算。我一般把processed数据存成parquet格式比CSV小、读得快、还能保留数据类型。存的时候带上处理日期比如train_20240115.parquet这样能追溯是哪版数据训出来的模型。4.3 训练脚本与实验记录训练脚本的核心是配置和代码分离。所有超参数、路径、模型选择都放在配置文件里yaml或者json代码只负责读配置、执行逻辑。这样你改参数不用动代码也方便做批量实验。import yaml def load_config(path): with open(path) as f: return yaml.safe_load(f) def train(config): train_df pd.read_parquet(config[train_path]) model build_model(config[model]) model.fit(train_df[config[features]], train_df[label]) return model实验记录我一开始就用一个CSV每跑一次实验追加一行记录时间、配置摘要、训练指标、验证指标。等实验多了用pandas一分析就能看出哪个参数影响最大。这个习惯坚持下来比任何自动化工具都管用因为它逼你主动思考每次改动的目的。4.4 推理服务先能跑再谈性能推理服务我建议先用Flask起一个最简单的接口能接收请求、返回预测就行。别一上来就上FastAPI加异步加批处理那些是优化阶段的事。from flask import Flask, request, jsonify import joblib app Flask(__name__) model joblib.load(model.pkl) app.route(/predict, methods[POST]) def predict(): data request.get_json() features [data[features]] pred model.predict(features) return jsonify({prediction: pred.tolist()}) if __name__ __main__: app.run(host0.0.0.0, port5000)这个服务很粗糙但它是完整的——你能用curl或者Postman发一个请求拿到一个预测结果。这就够了。接下来你要做的是加日志记录每个请求的输入输出、加异常处理输入格式不对要返回友好错误、加健康检查接口。这些才是让服务能用的关键而不是性能。提示模型加载一定要在服务启动时做一次别每次请求都加载。我见过有人把joblib.load写在predict函数里结果每个请求都要读一遍模型文件延迟高得离谱。这个坑很隐蔽因为功能上没问题只是慢。5. 常见问题与排查实录那些让我熬夜的坑5.1 指标虚高先怀疑数据泄漏模型指标好得不真实是新手最容易遇到的陷阱。我印象最深的一次一个二分类任务验证集AUC到了0.99当时还挺高兴结果上线后效果惨不忍睹。排查了半天发现是特征里混进了一个未来信息——某个字段是在标签产生之后才记录的等于把答案泄露给了模型。数据泄漏的排查思路是逐个检查每个特征问自己这个特征在预测时刻真的能拿到吗。如果拿不到那就是泄漏。常见的泄漏来源包括用了未来时间点的数据、用了标签的衍生字段、训练集和测试集有重叠样本。这个检查一定要做而且要在看指标之前做否则很容易被漂亮数字冲昏头脑。5.2 训练不收敛从学习率和数据两头查loss不降或者震荡原因通常就那么几个。我整理了一个排查顺序按这个顺序查基本能覆盖九成情况现象可能原因排查方法loss完全不降学习率太小调大10倍试试loss震荡剧烈学习率太大调小10倍或加warmuploss降一阵又涨过拟合加正则、早停、增数据loss一直是nan数据有异常值或除零检查输入是否有inf/nan训练降验证不降数据分布不一致对比训练验证的特征分布这个表我贴在工位上过因为排查的时候人容易慌有个清单能避免瞎试。特别说一下nan的情况很多时候是归一化的时候除了零或者log里出现了非正数。加一个assert not np.isnan(x).any()在关键步骤能省很多时间。5.3 线上效果和离线对不上这是最让人头疼的问题因为涉及的因素多。我的排查框架是分三层数据层、特征层、模型层。数据层先看线上请求的数据分布和训练数据是不是一致。比如训练时用户年龄都是20到40线上突然来了个200岁的可能是默认值没处理模型自然懵。特征层看特征计算逻辑线上线下是不是同一套代码我踩过的坑就是线上用Java重写了一遍特征逻辑结果和Python版本有细微差异导致特征值对不上。模型层看加载的模型版本对不对这个听起来低级但真的发生过——线上加载的是上一版的权重。排查顺序建议从数据层开始因为最容易查也最常见。具体做法是记录线上请求的原始输入和最终特征值和离线同样输入的处理结果对比一层层缩小范围。5.4 几个让我印象深刻的实操心得第一个心得日志要记全但别记敏感信息。我一般会记录请求ID、时间戳、输入特征的哈希值不记原始值、预测结果、耗时。这样出问题时能追溯又不会泄露用户数据。第二个心得模型文件要带版本号。model_v1.pkl、model_v2.pkl别用model.pkl覆盖。我吃过亏想回滚的时候发现旧模型被覆盖了只能重新训练白白浪费一天。第三个心得任何手动操作都要脚本化。我一开始更新模型是手动scp上传、手动重启服务结果有一次传了一半网络断了服务挂了半小时。后来写了个部署脚本虽然简单但至少不会传一半。第四个心得留一个逃生开关。推理服务里加一个配置可以一键切回规则或者上一个模型。当新模型出问题时能秒级回滚而不是手忙脚乱地重新部署。这个开关平时用不到但关键时刻能救命。6. 从能跑到好用下一步该往哪走闭环跑通之后你会自然发现瓶颈在哪。如果训练太慢可以考虑加GPU或者优化数据加载如果推理延迟高可以上批处理或者模型量化如果实验管理混乱可以引入MLflow如果数据量大了pandas扛不住可以换Dask或者Spark。注意这些都是在有明确瓶颈之后才做的而不是一开始就堆上去。我个人在实际操作中的体会是从零搭建AI工程最难的不是技术是克制。克制住一上来就上复杂方案的冲动克制住追求完美架构的执念克制住看到新工具就想换的欲望。先把一条最朴素的链路走通让数据流动起来让反馈产生出来后面的优化才有方向。我见过太多项目死在准备阶段不是能力不够是想得太多做得太少。最后再分享一个小技巧每完成一个环节写一段简短的README记录这个环节做了什么、为什么这么做、有哪些坑。不用写得多正式几句话就行。过一个月你回头看这些记录比代码本身更有价值因为它们保存的是你的判断而判断才是从零搭建过程中真正积累下来的东西。