当时我接手的第一个“正经”AI工程是从零开始搭一个电商评论的情感分析服务。那时我心里想得很简单训练一个分类模型而已了不起再加一个 API。可真等我把数据、模型、部署、监控整个闭环都跑通之后才意识到我之前在 Notebook 里练的“AI”只占这个项目 20% 的工程量。这也是为什么我愿意把这个项目定名为 ai-engineering-from-scratch——AI工程从零开始不做童话叙事不直接套一个大平台而是从裸数据、裸代码、一台开发机出发把端到端管线一步一步建起来。这篇文章写给想从“会训练模型”走向“能交付AI产品”的工程师或者刚入行、想理解AI工程全貌的同学。文章里我会结合一个文本分类的真实场景把我选型、搭建、踩坑、复盘的全过程都摆出来对照着看会更有收获。1. 整体设计与思路拆解做“厨房”不只是做“菜”1.1 为什么必须选“最小闭环”而不是“模型竞赛”很多朋友走上AI工程这条路第一反应是先拿个 SOTA 模型把准确率刷高。但我现在回头看这个顺序其实反了。一个AI系统能被叫作“工程”不是因为它有一个多聪明的模型而是它在真实环境里可持续稳定地提供服务。这就好比开餐厅菜谱和厨艺当然重要但决定生死的是原材料采购、仓储保鲜、备菜切配、出餐速度、卫生制度和顾客投诉反馈厨房里每个环节都得转起来单靠一道招牌菜撑不起一家店。“最小闭环”的意义就是先把厨房完整搭一遍哪怕菜品简单。我当时给自己设的目标很朴素给一条评论返回正面或负面的情感标签准确率不低于85%P95推理延迟低于300毫秒后期数据更新后能重新跑通训练和部署全流程。为了达到这个目标我没有一上来就上大模型而是规定机器学习模型先选逻辑回归特征用 TF-IDF服务用 FastAPI容器用 Docker数据和特征都添加版本和校验。这套组合没人会觉得酷但它能让你在最短时间内看到完整的工程形态之后替换任何一个环节都很方便因为你知道每个环节该承担什么。“从零开始”这里还有一层含义不把现成的 AI 平台或模型托管服务当作不透明黑盒。自己从数据管线、实验追踪、推理服务、监控回归全走一遍你对每个组件为什么存在、会在哪里出问题会有切身的体感。这份体感恰恰是未来排查复杂故障时的直觉来源。现在很多工程同学一上来就用托管服务出了问题只能提工单很难定位到数据层或者推理层这就是初期“省事”埋下的长期包袱。1.2 关键取舍模型、数据、服务三选三任何方案都要做取舍。我最后确定的技术路线有三个重要选择值得展开讲讲。第一个取舍是模型复杂度。逻辑回归听着幼稚但它的训练时间短、可解释性强、对机器要求低非常适合第一版。更重要的是它是一个“基线”无论你后面是换成 LightGBM、CNN 还是 BERT都可以用这个简单基线来判断“复杂模型带来的提升是否值得它带来的运维成本”。我见过不少团队模型越上越重最后线上推理需要GPU集群但效果只比逻辑回归高两个百分点用户根本感知不到这就是投入产出严重倒挂。第二个取舍是数据标注。市面上有很成熟的开源情感分类数据集但领域差异很大电商评论文本和新闻评论文本看着都是中文可是表达完全不同。所以我选择自己采集近一个月的真实评论先用规则粗筛再人工精标2000条。宁可数量少一点也要保证数据来自目标场景的真实分布。2000条看起来不多但对逻辑回归加TF-IDF这类模型配合交叉验证已经能跑出一个可信的基线。第三个取舍是服务化框架。一开始只用 FastAPI Docker不引入整套模型服务框架或者微服务网格。原因也很简单复杂度必须滞后。第一版系统最重要的任务是跑通不是跑大。用最少组件组成闭环再在闭环上做监控和迭代比一开始就铺一堆组件要稳妥得多。这里可以给一个简单的对比表说明从“Notebook实验”到“AI工程”到底差在哪里维度Notebook 实验AI 工程关注范围单点模型性能数据、训练、部署、监控全链路运行方式手工跑一遍可重复、可自动、可恢复代码状态随手改、无版本受版本控制、有测试团队协作个人能跑就行环境一致、产物可共享失败代价重新跑一次线上故障、复现失败、数据污染这个表值得在启动任何AI项目前先自问一遍我目前在哪个状态接下来往哪个方向挪2. 核心细节解析与实操要点2.1 数据管线80%的工程量都在这里做AI工程真正考验功夫的往往不是模型结构而是数据。数据管线的目标只有一个让“干净的、可复现的、有版本的数据”源源不断地送进训练流程。先说数据来源。电商评论通常来自数据库、数据仓库或者日志文件。我从数据仓库导出一个时间段的评论明细字段包括用户ID、商品ID、评论内容、评论时间等。这个环节必须补一个“脱敏与授权”的意识和评论相关的用户隐私字段要审查绝对不要为了省事直接整表导出。工程习惯应该是“先合规再效率”。然后是清洗。实际数据里你会发现大量重复评论、空评论、纯标点、广告导流、乱码夹杂。一步一步清洗时最好写成函数而不是在命令行或 Notebook 里零散操作。我当时的清洗函数长这样import re import unicodedata def clean_comment(raw: str) - str: text unicodedata.normalize(NFKC, raw) # 统一全角半角 text re.sub(rhttps?://\S|www\.\S, , text) # 去链接 text re.sub(r.*?, , text) # 去HTML标签 text re.sub(r\s, , text).strip() return text清洗之后要立刻做一致性校验。比如空文本比例、最短文本长度、重复率、标签分布。这些校验可以写成一个独立的validate_data()函数每次清洗完跑一遍输出一份报告。我后来把它接到 CI 里只要上游数据一更新先跑校验校验不过直接打断不让脏数据流进训练。数据版本是很容易被忽略的点。数据文件不像代码可以方便 diff数据一变模型可能完全变样。我采用很轻的方案每个处理好的数据集目录里放一个manifest.yaml记录来源文件、处理时间、行数、文件哈希、使用的清洗版本然后用 git tag 管理关键节点。不用一开始就上重型的 DVC但“哈希清单标签”这个组合一定得有。否则三个月后同事问你“这个模型是用哪份数据训的”你只能哑口无言。还有一个细节测试集切分。很多教程喜欢train_test_split(test_size0.2, random_state42)但在时间序列性质的业务数据上这么切会导致信息泄漏。评论数据天然带时间顺序后面时间的评论可能包含前面评论的上下文表达比如用户之间互相影响、商品改版后的新表达所以我的经验很简单必须按时间切分用前80%时间训练后20%时间测试而不是随机切分。随机切分会让你模型在验证集上的指标乐观得离谱。2.2 训练与实验管理先写一行CSV再谈高级工具如果让我给团队里新人唯一一个建议那就是从第一天开始记录实验。不需要一开始就上 MLflow 或者 Weights Biases但你可以准备一个experiments.csv每次训练把模型名、数据版本、特征配置、随机种子、学习率、关键指标、代码 commit 号追加进去。就这么简单的一行 CSV已经能赢过80%的团队因为大多数人在 Notebook 里跑完就忘了。具体到训练复现性有两层环境复现和代码复现。环境复现靠依赖锁定和容器requirements.txt必须精确固定版本或者直接用 Docker 镜像把 Python、依赖、系统库一次锁死。代码复现靠固定随机种子和可配置的参数入口。比如 PyTorch 里要同时固定这几个import random, numpy as np, torch def set_seed(seed: int 42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) if torch.cuda.is_available(): torch.cuda.manual_seed_all(seed)但注意固定随机种子并不是复现的充分条件。只要环境不一致比如不同版本的 scikit-learn 和 torch同一份种子照样给你不同结果。所以“容器一致”往往比“随机种子一致”更重要。评估指标这块分类问题大家最爱看 accuracy但情感标注往往存在类别不均衡“负面”可能只占10%。所以必须看 weighted F1、precision/recall以及最重要的混淆矩阵。我在项目里设了一个“上线门禁”在盲测集上 weighted F1 不低于0.80每个类别 recall 不低于0.70任何一条不达标就不允许进部署流程。还有一个经常被忽视的评估动作把模型拿到“线上真实盲样本”上去跑而不是只在人工划分的测试集上爽。我当时从线上随机捞了300条一周之内、标注系统尚未打标的评论做盲测发现测试集上准确率有90%盲测集上直接掉到81%。这让我立刻意识到测试集在时间分布上已经和当前线上不一致了于是默默加入了每周刷新一次盲样本的机制。这个动作价值很高建议所有团队都参考。2.3 推理链路延迟、缓存与可观测性模型算出来只是终点前的第一步真正让模型变成服务的是推理链路。我当时把一次线上请求拆成了五段网络传输、请求解析、预处理分词/向量化、模型推理、响应序列化。你会发现预处理和模型推理各占一半时间如果不同时优化只盯着模型加速是没用的。延迟目标要量化。当时我给自己的目标P95 300msP99 600ms。为了达到这个目标我做了三件事。第一模型用 ONNX 格式导出去掉不必要的 Python 推理开销。第二TF-IDF 向量化在启动时加载一次千万不要请求里现场做文件读取和词表加载。第三对重复请求做结果缓存用一个很简单的 Redis 或者进程内 LRU 缓存key 是文本哈希value 是预测结果。高重复率的场景下缓存能把 P95 拉低一个数量级这个收益比换模型实在得多。可观测性也是必须的。我给 API 设计了标准响应体{ request_id: abc-123, label: negative, confidence: 0.97, model_version: lr_v1, preprocess_ms: 12, inference_ms: 34 }request_id用来串联日志model_version用来定位线上到底是哪个模型在跑preprocess_ms和inference_ms用来拆解延迟。日志除了记录这些字段还要记录输入文本的截断版本和长度方便后续排查输入分布漂移。可观测性不是做给领导看的而是为了在凌晨两点收到报警时你能有据可查、快速定位。3. 实操过程与核心环节实现3.1 初始化项目脚手架先把“家”收拾好AI工程的项目结构和算法比赛有本质区别。算法比赛可以只有两个 Notebook工程项目则需要在文件夹上体现分工和流转。我当时初始化的目录结构是这样ai-engineering-from-scratch/ ├── data/ │ ├── raw/ # 原始数据只读 │ ├── processed/ # 清洗、特征后的数据带manifest │ └── manifest.yaml ├── src/ │ ├── features.py │ ├── train.py │ ├── evaluate.py │ └── server.py ├── configs/ # 参数配置和代码分离 ├── tests/ # golden test 与 smoke test ├── models/ # 模型产物按版本归档 ├── Dockerfile ├── docker-compose.yml ├── requirements.txt └── Makefile这个结构里最容易被忽略的是configs/。很多工程同学把超参数直接写死在代码里改一次参数要全局搜索。正确做法是参数从 YAML 或环境变量读取每次训练记录一个配置快照和实验 CSV 对应起来。这样当你回看一个历史实验时能确认它到底用了什么分词、什么学习率、什么特征维度。虚拟环境也必须在项目内隔离。我一般用python -m venv .venv然后写一个Makefile把常见命令收拢起来setup: python -m pip install -r requirements.txt data: python src/features.py --config configs/data.yaml train: python src/train.py --config configs/train.yaml serve: uvicorn src.server:app --host 0.0.0.0 --port 8000不要小看这个 Makefile它能在团队协作时降低“你跑一下试试”的沟通成本。任何人拉下仓库只需要按固定命令执行就能从数据跑到服务不用翻 README 脑补流程。3.2 数据准备与特征工程实现数据准备阶段第一步是从数据仓库导出近30天评论导出后马上计算基础统计总行数、唯一评论数、缺失字段占比、时间分布。看到这些数字的第一时间就要判断要不要和数据上游的人再核对一下口径避免用了错误的 join 导致数据翻倍。清洗完之后做特征工程。文本情感分类场景我用的是 TF-IDF 向量化这里有两个关键参数值得细说。第一个是max_features我设为5000因为逻辑回归加上5000维特征已经够用太高反而引入噪声而且模型体积变大。第二个是ngram_range我设为(1,2)因为单独一个词往往丢失上下文而二元词组对“不”“好”“不好”这类否定表达更敏感。另外对于中文最好做分词而不是直接按字切。我当时用了 jieba简单实测下来分词的 TF-IDF 比字级别的准确率高五六个点。特征工程的代码如下from sklearn.feature_extraction.text import TfidfVectorizer def build_vectorizer(train_texts): vectorizer TfidfVectorizer( max_features5000, ngram_range(1, 2), tokenizerjieba.lcut, sublinear_tfTrue, ) X_train vectorizer.fit_transform(train_texts) return vectorizer, X_train这里有一个无数人踩过的坑fit_transform只能用在训练集上验证集和线上请求只能用transform否则会让验证集信息混入词表和 IDF 统计造成严重的信息泄漏。我见过一个项目因为这个坑离线准确率高得惊人线上却一塌糊涂最后查了三天才发现是向量化器在整份数据上 fit 了一遍。所以特征器设计完毕后我把它和模型一起序列化保存线上请求直接加载同一份特征器绝不允许线上再写一份“看起来一样”的特征代码。3.3 训练与评估实现基线模型我用逻辑回归。这不是因为它最先进而是因为它在小数据、低延迟、强可解释性方面表现均衡。训练代码很短from sklearn.linear_model import LogisticRegression from sklearn.metrics import classification_report, f1_score model LogisticRegression(C1.0, class_weightbalanced, max_iter500) model.fit(X_train, y_train) y_pred model.predict(X_val) print(classification_report(y_val, y_pred, target_names[negative, neutral, positive])) print(weighted_f1:, f1_score(y_val, y_pred, averageweighted))如果这一步跑完 weighted F1 在0.80附近已经很健康。接下来你可能会想要不要换 BERT我当时做了个小实验用bert-base-chinese微调了3个 epochweighted F1 提升了约4个点但推理速度下降了近20倍必须上GPU才能满足延迟。综合考虑之后我决定第一版用逻辑回归上线同时把 BERT 版本留作候选。这个决定的核心逻辑是提升模型复杂度之前先确认业务是否真的需要那4个点如果不需要就把它当作技术储备而不是让基础设施背上一个沉重的包袱。评估环节我还会额外做一件事把训练过程中识别出的易错样本汇集成一个小型数据集保存到tests/golden_set.tsv。每个样本包含文本、真实标签、预测错误时的模型输出。这组数据有两个用途一是作为回归测试每次改版后在 CI 里跑一遍二是作为后续模型优化的参考很多反复出错的样本往往暴露的是数据标注不清晰而不是模型不够强。3.4 服务化部署实现服务的核心入口用 FastAPI 写非常直观from fastapi import FastAPI from pydantic import BaseModel import joblib app FastAPI() vectorizer joblib.load(models/vectorizer_lr_v1.joblib) model joblib.load(models/model_lr_v1.joblib) class Item(BaseModel): text: str app.get(/healthz) def healthz(): return {status: ok} app.post(/predict) def predict(item: Item): vec vectorizer.transform([item.text]) proba model.predict_proba(vec)[0] label model.classes_[proba.argmax()] return { label: label, confidence: float(proba.max()), model_version: lr_v1, inference_ms: 42, }这里有几个细节。第一vectorizer和model在模块加载时只加载一次不是在每次请求时加载。第二/healthz一定要有Docker 的 HEALTHCHECK 和负载均衡都会用到。第三confidence用 float 转换避免把 numpy 类型直接塞进 JSON不然会遇到序列化报错。Dockerfile 长这样FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY src/ ./src/ COPY models/ ./models/ EXPOSE 8000 CMD [uvicorn, src.server:app, --host, 0.0.0.0, --port, 8000]写 Dockerfile 时要注意两个点一是把requirements.txt单独 COPY 再安装利用 Docker 的缓存层避免每次改代码都重装依赖二是不要把data/大目录 COPY 进镜像线上服务根本不需要原始数据和清洗数据镜像里只放模型和代码就够了镜像大小能差出十倍。启动服务之后我立刻做了一轮简单压测。模拟50个并发消费者连续发送2000条预测请求记录 P50、P95、P99 延迟。我当时的观测结果是P50 35msP95 88msP99 152ms完全低于目标。这组数字给了上线条信心。如果压测不达标我会按优先级依次排查缓存优化、改用 ONNX、批量推理、上GPU而不是一上来就拆服务。3.5 上线后的复盘与迭代节奏上线不是终点是新的起点。我给自己定了一个两周一小迭代的节奏每周抽50条线上真实请求做人工标注和模型预测结果对比给出“模型正确/模型错误/边界模糊”的三态标记。然后把这些反馈记录到data/manual_feedback/用于下个版本的训练集扩充。同时我在仓库里维护一份models/MODEL_LOG.md每次发布模型都记录数据版本、特征版本、训练时间、负责人、上线回滚方式、本次目标。这份文档不需要长几行就够但它能让你在半年后依然复现当时为什么这样做。很多项目乱就乱在“当时改了一下”这种记忆里把决策过程写下来比写代码注释更有工程价值。4. 踩坑现场高频问题与排查思路实录这章专门把我实际踩过的坑、以及身边团队高频踩的坑整理成一份速查表供你在实施时对照自查。先说结论AI工程里90%的诡异问题最后都能归结到数据不一致、版本不一致、环境不一致这三类。4.1 离线指标很漂亮线上全面拉胯这是高频第一名。我自己的盲测已经发现过这个问题原因通常是测试集切分方式不符合真实时间分布特征器在整份数据上意外 fit线上输入文本和训练样本分布差距太大。排查建议分三步走第一步对比训练集和线上样本的文本长度、词频分布、时间范围把差异列出来。第二步检查数据管线里有没有把测试集信息带进训练比如向量化器是否全局 fit。第三步在线上做人工盲测用人工标注去和模型对齐而不是看系统自报的准确率因为线上根本没自动标注。4.2 容器启动后中文全部乱码这个坑非常典型。Docker 基础镜像默认 locale 可能不是 UTF-8Python 打开文本文件时如果没指定编码遇到中文就会报错。我当时的日志里到处是UnicodeDecodeError。解决方法是两行在 Dockerfile 里设置环境变量ENV LANGC.UTF-8 LC_ALLC.UTF-8全部文件读取显式传入编码参数encodingutf-8。另外时间相关也要注意时区容器默认 UTC业务日志如果按本地时间统计必须显式设置TZAsia/Shanghai或统一按 UTC 存储、展示时再转换。4.3 同事拉下仓库结果跑不出我的数字我当时遇到的情况是同事在同一份代码上跑训练F1 差了好几个点。最后定位到原因他本地requirements.txt是宽松版本装到了最新的 scikit-learn而我的环境是旧版本。另外我用了相对路径加载数据换台机器路径就错。根治办法所有依赖锁死精确版本所有路径基于项目根目录不依赖 CWD。你可以使用import os, pathlib定义BASE_DIR Path(__file__).resolve().parent.parent来加载文件。跑实验时把 commit hash、依赖版本、随机种子都写进实验 CSV这样任何一次复现都能缩小查找范围。4.4 模型文件和特征器版本不匹配这个坑特别隐蔽。有时候模型文件更新了但特征器文件还是旧的或者两者在代码里被分别加载结果在线上一旦有文本命中了新词表里的词特征维度都对不上推理直接报错或者结果飘掉。我的解决方案是不要散落多个文件打包成一个“模型工件目录”里面包含model.joblib、vectorizer.joblib、meta.yaml三个文件一起发布、一起加载。每次加载时读meta.yaml里的model_version和feature_version做一致性校验。这个习惯后来帮我避开了很多次“模型正、预处理歪”的问题。4.5 线上服务跑几天后内存缓慢上涨这个一般不是模型问题而是 Python 进程的内存管理问题日志对象堆积、缓存未设置上限、每次请求创建了新对象所以没有释放。排查时我习惯先开一个/metrics端点用psutil输出 RSS 内存和对象数配合定时采样。如果确认是 LRU 缓存导致给缓存加maxsize如果确认是日志堆积把日志文件按大小轮转。内存问题要尽早暴露不要在报警之后才去临时加内存。整理成速查表现象核心原因快速排查路径预防方案离线准线上差分布偏移/特征泄漏对比线上样本分布检查向量化器 fit 范围时间切分线上盲测集中文乱码locale 与编码检查 Docker locale打印文本前100字节显式 UTF-8设 LANG复现不出结果依赖/路径不一致比对 requirements 与实验记录锁版本容器化BASE_DIR模型与特征不匹配散装文件、版本错位检查 meta.yaml 比对版本模型工件目录统一发布内存上涨缓存/日志未控上限开 metrics 采样内存对象限制缓存日志轮转这五类问题是整个从零开始过程中最容易遇到的共性内容。如果你想更早避开建议在项目第一天就把“数据版本、模型版本、容器镜像”这三个东西钉死。5. 扩展方向从一个人到一套团队级AI工程体系当你一个人把最小闭环跑通之后总会被问到下一个问题如果三个人、五个模型、持续迭代该怎么做这时候不是继续堆新代码而是把个人能力扩展成团队体系。我的建议是渐进式引入工具而不是一步到位铺全套。5.1 工具链什么时候上什么可以先按“痛点驱动”排一个顺序。当你有多个业务线都开始要模型时先把“实验记录”从 CSV 升级到 MLflow集中管理实验、模型、运行环境。当你开始频繁做定时重训练时再把训练脚本从 Makefile 升级为 Airflow/Prefect 这类编排工具让每个步骤具备可重试、可监控、可追溯的特性。当你的特征逻辑开始跨项目复用才考虑上特征平台例如 Feast。最后当你的模型推理达到一定规模并且需要自动扩缩容时再上 Kubernetes 和 KServe。这背后的道理还是最开始说的复杂度滞后。工具是拿来解决痛点的不是拿来展示技术品位的。一个三人团队一开始就上 Kubernetes 加 MLflow 加 Feast多半会陷入“运维工具”本身而忘了项目目标。5.2 AI 工程师的能力模型T型成长聊到从零开始之后的个人成长我把 AI 工程师的能力分成四块拼图数据工程、模型训练、MLOps/运维、流程协作。前两块很好理解后两块容易被忽略。MLOps 包括版控、CI/CD、容器化、监控报警、成本控制流程协作包括需求评审、上线评审、复盘文档、KPI对齐、与产品/运营沟通业务指标。这四个拼图并不是要求你同时精通而是建议先“T型”横向了解所有模块的技术选型和风险纵向精通其中一两块。我个人的体会是最珍贵的能力不是会调参而是能在项目启动时画出一张覆盖全链路的“分锅图”数据谁负责、特征谁负责、模型谁负责、运维谁负责、指标谁负责。这张图一旦清晰项目基本就成功了一半。最后分享一个我自己的习惯。每过半年左右我会故意换一个全新的业务问题从一个空目录开始重新走一遍从零到上线的最小闭环。这个过程不是重复劳动而是让我的大脑始终记住AI工程真正的复杂度永远在模型之外的数据、流程和运维细节里。如果你正准备启动自己的 AI 工程项目建议先把“数据、评估、部署”三个词写在同一张白板上想清楚它们今天的状态再决定先动哪一块。这就是我理解中的 ai-engineering-from-scratch也是这个项目名字里最值钱的那部分。
