1. AI工程到底是什么别把调接口当工程1.1 先从一次失败的“AI项目”说起去年帮朋友 review 一个所谓的“AI项目”团队花了三个月调好了 OpenAI 的接口做了个漂亮的聊天界面上线后用户给了一大堆低分评价。问了一下细节没有评测集没有 prompt 版本管理没有日志没有反馈收集渠道模型升级后没有任何回归测试同一个问题今天答得好明天答得烂团队完全不知道为什么。整个项目说白了就是“接口调用 前端美化”和真正的 AI 工程差了十万八千里。这不是个例。我见过太多团队把“能用大模型”和“做好一个AI产品”混为一谈。从零起步做 AI 工程第一步不是去学什么模型原理而是先建立一套工程思维数据怎么管实验怎么记服务怎么部署效果怎么评估线上怎么监控模型怎么迭代。这些东西统称 AI Engineering核心是让智能应用从“demo能跑”变成“线上能用、持续可维护、出了问题可回滚、迭代了效果可对比”。这个领域适合谁想转 AI 方向的软件工程师想给业务做智能化升级的技术负责人以及刚毕业准备入行的同学。它不要求你先成为算法科学家但要求你具备系统思维和工程基本功。1.2 工程化要做的事一句话讲清楚AI 工程的核心目标是把一个“看起来聪明”的模型变成一个“稳定靠谱”的产品服务。围绕这个目标工程化要解决的问题可以拆成六块数据、实验、训练、评估、部署、监控。数据环节解决的是“模型学什么”。不是你有什么数据就喂什么数据而是要清洗、转换、抽样、划分、脱敏让数据既干净又贴合业务。实验环节解决的是“哪版模型更优”。你改了 prompt、换了模型、加了 RAG 检索怎么证明它确实变好了靠评测集和指标不是靠感觉。训练环节对于大多数人来说会简化为“微调”或“提示工程”但你至少要懂训练的基本流程否则连报错都看不懂。评估环节是最容易被忽略的很多项目上线前连一个像样的评测集都没有完全靠人工抽几条样例“目测”。部署环节要把模型包成服务处理并发、延迟、成本、弹性扩缩容这跟传统后端服务差别巨大尤其是动态数据的场景。监控环节则是 AI 特有的痛点模型在线上会漂移、会退化、会静默地给出垃圾答案指标看不对等于没监控。这六块构成了一个闭环数据驱动模型模型产生效果效果通过评估反馈给下一轮迭代。从零开始做就要严格按照这个闭环去搭缺一块都能跑通但跑不长久。2. 从零开始的技术底座先把地基打牢2.1 你需要的基础技能没有想的那么玄不少读者问我做 AI 工程是不是要先把数学补完线性代数、概率论、最优化全精通我的回答可能让你失望不需要。AI 工程从业者绝大多数时间在跟数据、工具、代码和运维打交道真正的数学攻坚发生在算法研究阶段。你需要的是够用的数学感知知道什么是过拟合为什么学习率太大会振荡为什么评估指标要用 F1 而不是准确率这就够了。多数情况下你能读懂损失函数图像、能理解评估报告里的数字就足以完成工程闭环。真正卡人的是三项基本功Python 熟练度、Linux 操作能力、工程化意识。Python 至少要能达到“顺手”程度数据处理用 pandas、numpy 不卡壳Linux 至少要会看日志、管理进程、用 Docker 跑镜像工程化意识则体现在每一次改动都有记录、每一个结果都能复现。如果你这三项还弱不要急着碰大模型先花一个月补齐。当然如果你想做到资深水平还是值得补一点点机器学习基础梯度下降在做什么Embedding 是什么Transformer 为什么适合并行这些概念不求全会推导但求在选型、调参、排查问题时能理解现象背后的原因。举个简单例子为什么显存溢出多半发生在长序列场景因为 Transformer 的 attention 计算量跟序列长度是平方关系长度翻倍显存压力可能翻四倍。不懂原理的人只会盲调 batch size懂原理的人会先查序列长度分布再决定是否做截断。2.2 环境与工具链一套能复现的最小组合我推荐一套轻量但完整的工具组合全部免费社区成熟适合从零起步环境层用 Miniconda 管理 Python 虚拟环境用 Docker 固定运行时。这两个东西能解决最大的坑——环境漂移。上个月能跑的代码这个月跑不了十有八九是依赖版本变了。数据处理层用 pandas 做清洗用 DuckDB 做中等规模数据的查询分析。数据量不超过几十 GB 时DuckDB 比 Spark 香得多单机跑零运维。模型开发层用 PyTorch 加 Hugging Face 生态。Hugging Face 的 transformers 库把模型下载、tokenizer、训练器都封装好了是目前的实际标准。就算你只做推理不训练也绕不开这个生态。应用框架层如果做 RAG 或 Agent 类应用可以关注 LangChain 和 LangGraph但不要盲从。早期项目完全可以直接用原生代码调用模型 API自己写检索逻辑反而更可控。框架能提速但也会掩盖细节出现问题难以排查。服务与监控层用 FastAPI 做推理服务用 MLflow 做实验追踪用 Prometheus 加 Grafana 做线上监控。MLflow 很多人没用过我强烈建议从一开始就养成记录实验的习惯每条实验记录模型版本、参数、数据集版本、评估结果一个月后你就会感谢自己。这套组合的核心逻辑是每个环节选择社区主流、生态成熟、替换成本低的工具。不要把时间花在折腾冷门框架上。3. 一个完整AI工程项目的实操拆解3.1 项目选型与脚手架搭建别一上来就上大模型假设我们要做一个“客服工单智能分类系统”。工单进来后自动分到正确的部门。这个项目麻雀虽小五脏俱全难度适中非常适合复现整个工程流程。第一步是选型。很多人第一反应是用大模型 API 去分类这是可行的但我建议先在本地跑一个小的 TextCNN 或者 BERT 分类模型作为基线。为什么因为基线版本能帮你把整个数据管道、评估体系、部署流程跑通而且成本极低。后面如果想用大模型提升准确率只需要在已经跑通的工程骨架里替换模型层而不是从头开始搭。先搭好管线和评估机制再迭代模型这是 AI 工程最实用的策略。选型时还要考虑一个关键约束数据隐私和响应延迟。如果业务方要求数据不能出内网那模型 API 这条路直接堵死必须用私有化部署的开源模型。即便能走 API也要评估预算分类任务每天调用上万次API 费用会成为一笔可观的固定开支。这些约束必须在项目立项时就拉清楚否则后面返工成本极高。技术栈直接复用上面那套FastAPI 做服务层PyTorch 加 Hugging Face 做模型MLflow 记录实验Docker 做部署。数据库用 SQLite 起步完全够后期需要再迁移到 PostgreSQL。先把骨架搭好# 创建项目目录 mkdir ticket_classifier cd ticket_classifier conda create -n ticket_cls python3.10 -y conda activate ticket_cls # 安装核心依赖 pip install pandas scikit-learn torch transformers[torch] fastapi uvicorn mlflow duckdb这里不追求一步到位重点是让环境可复现。把依赖写进 requirements.txt并锁定版本别偷懒。等踩过“别人机器上跑不了”的坑你会明白锁定版本有多重要。3.2 数据管道从原始脏数据到高质量训练集工单数据大概率长这样来自不同渠道的表格、邮件转成的文本、客服手动填写的备注字段缺失、格式混乱、还有大量重复工单。数据管道要做的事是把这些乱七八糟的原始数据清洗成一条条干净的“标签正文”样本。清洗规则按优先级排列先做去重相同文本且相同标签的工单只留一条避免模型对重复样本过拟合再做标签标准化把“售后问题”“退换货”“退款申请”统一成“售后”最后做正文清理去掉 HTML 标签、多余空白、无意义的签名档。清理的逻辑用 Python 写并不复杂关键是每一步都要记录清理前后的样本数量这样能知道每步影响多大。清洗后的数据要做分层抽样按标签比例拆成训练集、验证集、测试集常见比例 8:1:1。分层抽样是为了防止某类样本全跑到测试集里导致评估结果虚高或虚低。sklearn 里用train_test_split加stratify参数即可。这里想特别强调一下标签分布。工单分类场景大概率是长尾分布售后类占 60%发票类占 30%剩下 10% 是十几种低频类别。如果你的评估只算整体准确率模型完全可以全部预测成“售后”拿到 60% 准确率看似不错实际毫无价值。所以从数据阶段起就必须按标签分布做分析并在评估阶段引入加权 F1 这类指标这是后面评估体系能发挥作用的前提。数据准备好后用 Hugging Face 的datasets库封装成 Dataset 对象方便后续喂给模型。别再用 pandas DataFrame 硬怼训练了Dataset 能做缓存、映射和分批操作训练时方便很多。3.3 模型开发与训练基线模型怎么跑通先用 sklearn 做一个 TF-IDF 加逻辑回归的模型作为第一个基线。这个模型虽然简单但速度快、可解释性强而且对短文本分类效果往往出人意料地好。我的习惯是永远先跑一个简单基线再上复杂模型这样复杂模型有没有真正带来提升一目了然。代码结构保持简单一个 train.py 包含从数据加载到模型保存的全部逻辑但要用 MLflow 在关键位置埋点。训练脚本的核心逻辑大致如下import mlflow from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import make_pipeline from datasets import load_from_disk # 读取已清洗好的数据集 dataset load_from_disk(./data/clean_dataset) with mlflow.start_run(): # 记录关键参数 mlflow.log_param(model_type, tfidf_lr) mlflow.log_param(ngram_range, (1, 2)) X_train dataset[train][text] y_train dataset[train][label] X_test dataset[test][text] y_test dataset[test][label] # 建模 model make_pipeline( TfidfVectorizer(ngram_range(1, 2), max_features20000), LogisticRegression(max_iter1000) ) model.fit(X_train, y_train) # 评估 acc model.score(X_test, y_test) # 这里记得要算 label 维度加权 F1别光算准确率 from sklearn.metrics import f1_score y_pred model.predict(X_test) f1 f1_score(y_test, y_pred, averageweighted) mlflow.log_metric(accuracy, acc) mlflow.log_metric(weighted_f1, f1) mlflow.sklearn.log_model(model, model)跑完后去 MLflow 界面看指标。如果 weighted F1 能到 0.85 以上这个项目作为基础版就已经合格了。接下来训练 BERT 分类模型作为强化版本。用小规模的 distilbert-base 或中文场景下的 chinese-bert-wwm。别一上来就用大模型distilbert 在分类任务上能到 BERT 九成以上的效果速度却快很多。训练时最关键的三个超参数batch size、学习率、epoch 数。我的经验值分类任务从 batch size 16、学习率 2e-5、epoch 3 开始然后根据验证集曲线微调。一定不要跑太多 epochBERT 类模型非常容易在几个 epoch 后过拟合验证 loss 开始回升而训练 loss 还在下降时就要停。训练和推理时都要注意 tokenizer 与模型的一致性。换模型版本时忘记换 tokenizer是 Hugging Face 生态里最常见的低级错误。你自己一个人开发时容易记得多人协作时不留意就会踩。3.4 评估体系不能只有“看起来不错”评估是这个项目里最值得花时间的部分。传统分类任务用准确率、精确率、召回率、F1 就够了但真实业务场景往往需要更多维度的评估。第一层是指标评估。整体指标看加权 F1低频类别的表现要看每个类别的 precision 和 recall。如果某个低频类别 recall 太低说明模型经常漏掉它需要重点补充这类样本或做类别平衡处理。第二层是人工抽检。再好的指标也不能完全替代人眼抽几百条样本人工看一遍你会发现一些指标体现不出来的问题比如客服规范用语、敏感词回避、错误标签之间的相关性。第三层是边界测试。好的评估集不要只包含“正常样本”要加入一些边缘情况超长工单、含特殊字符的工单、两种类别混杂的工单。这些边界样本能暴露出模型和管线的真实鲁棒性。比如超长工单可能会因为超出 tokenizer 长度而被截断从而丢失关键信息。边界测试不是上线前临时加的而是在搭建评估集时就要按比例混入让效果反馈更加真实。把评估集和评估脚本固化下来作为仓库的一部分每次模型变更后必须跑一次全量评估输出报告。这个机制能拦住绝大多数“看起来变好了实际变差了”的改动。3.5 部署与监控让模型真正开始服务模型训练好了评估也过了接下来部署。部署的核心思路是把模型包进一个无状态服务用 FastAPI 暴露推理接口。模型文件在启动时加载到内存请求进来后直接走预处理、推理、后处理三步返回结果。一个最小推理服务大概长这样from fastapi import FastAPI app FastAPI() app.post(/predict) def predict(text: str): label model_pipeline.predict([text])[0] return {label: label}但真实生产环境远不止这样。要考虑几个问题并发请求多高平均响应时间要求多少模型推理用 CPU 还是 GPUGPU 显存够不够多条请求能不能 batch 在一起推理这些问题在部署前就要评估。如果并发不高数据量不大CPU 部署完全够用成本低得多如果吞吐要求高再用 GPU 加 batch 推理。很多人一上来就上 GPU既花冤枉钱又增加运维复杂度。部署后监控必须要做。传统监控看 CPU、内存、QPSAI 服务光看这些远远不够。我维护的每个模型服务至少会盯五类指标请求量、响应时延、输入长度分布、预测标签分布、模型置信度分布。预测标签分布特别重要如果线上标签分布和训练集标签分布差异巨大基本能断定模型正在失效。置信度分布则是判断模型是否“迷茫”的好风向标大量预测落在低置信度区间说明输入分布可能已经偏移。监控指标用 Prometheus 收集Grafana 画看板。MLflow 负责实验记录Prometheus 负责线上指标两者各司其职。有问题时先看 Grafana再回 MLflow 对比历史实验基本能快速定位是线上数据变了还是模型本身退化了。4. 高频场景里最容易翻车的地方4.1 数据泄漏评估虚高的第一元凶数据泄漏在 AI 工程里极度常见而且是新手最容易踩的坑。说个真实案例有个团队做客服问答匹配把用户历史工单和对应回复文本做训练评估准确率做到 0.95上线后实际效果只有 0.6。排查后发现问题出在去重环节同一个用户问了几乎相同的问题出现在训练集和测试集里各一条。模型在测试时其实就是在“背诵”训练时见过的样本指标自然漂亮一到线上遇到真正的未见过样本就现出原形。防泄漏的几条硬规矩任何清洗和预处理都必须先划分数据再做不能先全量清洗再划分否则 stats 会被全局信息污染去重操作必须在全量数据上做但划分后训练集和测试集之间不允许存在重复样本如果样本里有用户 ID、设备号等标识信息要检查同一个 ID 是否同时出现在训练集和测试集。这些检查要写成脚本放到 CI 里面每次训练前自动跑一遍而不是靠人肉回忆。4.2 OOM 与显存管理问题往往不在显存本身训练和推理遇到 CUDA Out Of Memory第一反应都是“我要换更大显存的卡”但多数时候问题出在代码层面。最常见的原因有三个序列长度过长、batch size 过大、内部张量累积未释放。分类项目里的工单文本有的用户一个工单能写两千字远超过模型默认的 max length 512。如果不对输入做截断甚至按最大长度动态 padding显存压力会迅速膨胀。我的做法是训练前先统计训练集的文本长度分布选取覆盖 95% 样本的长度作为 max sequence length而不是直接硬编码 512。这样既保住了信息量也把显存控制在合理范围内。PyTorch 里还有一个隐形显存杀手在循环中累积梯度。写训练循环时每步必须显式optimizer.zero_grad()否则梯度会不断累积显存开销逐层递增。另外model.eval()和torch.no_grad()在推理时一定要用否则 Dropout 层仍然生效推理结果不稳定而且反向图会被自动构建白白浪费显存。4.3 评估指标的各维度陷阱准确率是最大的陷阱准确率是看起来最直观但最容易被误导的指标。回到工单分类的例子如果售后类占了 60%一个什么都不学的模型只要把所有样本都预测成售后准确率就有 60%。你用这个数字写周报领导觉得项目进展神速实际上是数字在骗人。遇到类别不平衡的场景请优先使用加权 F1同时给每个低频类别单独画混淆矩阵。混淆矩阵比任何单一数字都更有信息量它能直观地告诉你哪两个类别最容易混淆。比如“退款”和“退货”经常被分错那就要考虑是不是两个类别的业务定义边界不清晰需要回去看数据标注规范而不是一味地调模型。另外一个常被忽略的问题是评估集太小。测试集只有两百条波动会非常大你改了一个无关紧要的代码准确率上下跳 3 到 5 个点完全可能是随机波动。评估集至少要覆盖每个类别几十条样本最好达到几百条数字才有参考价值。4.4 推理延迟优化优化顺序和技巧很多项目模型训练得挺好一上线就翻车原因是延迟不过关。分类工单这种任务延迟要求不算苛刻但 RAG 和 Agent 类应用就非常敏感用户不会等十秒。延迟优化的顺序我建议是这样先看网络和序列化再看后处理和批处理最后才考虑换模型。很多人把精力放在换更小的模型上最后发现瓶颈根本不在模型本身。我遇到过一辆 RAG 服务模型推理只要 200ms但每次请求都实时计算全量文本的向量化再暴力遍历数据库做相似度搜索总延迟跑到 3 秒。后来给向量库加索引延迟直接降到 300ms。这个优化不涉及任何模型变更效果立竿见影。如果模型推理确实是瓶颈再考虑方案。第一是用 ONNX 或 TensorRT 做推理加速实践下来普遍能提升百分之几十第二是 batch 推理多条请求合并成一个批次在 GPU 上吞吐远大于逐条推理第三才是换更小的模型比如把 BERT large 换成 DistilBERT或用量化版本的模型。量化这个操作要评估精度损失但通常 4-bit 量化对分类任务的损失可控值得一试。4.5 线上反馈回路模型退化的隐形杀手模型上线后最容易被忽略的问题数据分布会漂移。用户的语言习惯会变、产品功能迭代会引入新概念、工单的表达方式会随节日或活动改变。今天训练出来的模型三个月后可能已经在静默退化了。所以要建立线上反馈回路核心是把“线上数据”持续带回评估体系。我的做法有两种一是定期抽样线上真实请求人工标注后进行离线评估对比新模型和线上版本的表现二是建立预测异常触发机制当预测标签分布发生明显偏移、或置信度整体低于阈值时自动告警提醒团队排查。这个机制不复杂但能把“模型悄悄变差”变成“模型在某个时间点开始变化事后可以追踪”。有条件的话把线上被用户纠正过的样例收集起来作为下一轮训练的增量数据。比如客服觉得系统分错了部门手动改派这个“系统预测人工修正”的过程就是宝贵的训练样本。很多项目上线后模型就没再更新过那不是工程化的态度。5. 从零到一的路线图适合普通人的学习路径5.1 分阶段路线设计别被大模型热词带偏很多想入行 AI 工程的朋友被大模型、Agent、RAG 这些热词带着跑今天学 prompt明天学微调后天又去搞向量数据库学了一个月回头发现自己连一个完整项目都没跑通过。我的建议是按下面三个阶段走每个阶段都要交“项目”而不是“学过”。第一阶段半个月到一个月专注经典机器学习加工程基础。随便找一份公开数据集做文本分类或房价预测把数据清洗、模型训练、指标评估、模型保存、简单 API 部署整个闭环跑一遍。这一阶段不碰大模型因为大模型会掩盖工程问题你在小模型上能踩的坑后面做大型模型全都要再踩一遍提前踩熟无比划算。第二阶段一个月到两个月专注深度学习与 Transformer 生态。用 Hugging Face 跑通一个 BERT 分类或相似度任务重点理解 tokenizer 的作用、训练参数的影响、显存的管理。能回答这几个问题就算过关为什么需要 padding为什么学习率 2e-5 而不是 0.1序列长度和显存什么关系这一阶段做完你已经具备独立实现一个模型服务的完整能力。第三阶段两个月以上做 LLM 应用工程。引入大模型 API、RAG 检索、Agent 编排。这一阶段的核心不是“调用模型”而是架构设计如何做信息检索、如何组织上下文、如何评估生成质量、如何控制成本与延迟。建议自己从零搭一个 PDF 问答助手直接用原生代码加向量数据库不依赖高级框架源码到手后再去比较 LangChain 的做法你会对每一步有更清晰的理解。5.2 学习项目怎么选难度适中闭环完整选练习项目非常关键。太简单没有工程感太复杂容易半途而废。我推荐的标尺是三条数据获取方便评估标准清晰能覆盖至少三个工程环节。推荐几个方向一个是“论文摘要生成器”抓取公开论文数据做摘要抽取和生成评估用 ROUGE 指标能覆盖数据抓取、模型推理、评估对比三个环节另一个是“企业知识库问答系统”用内部文档建索引做语义检索和生成回答能覆盖数据解析、向量检索、质量评估还有一个是“电商评论情感分析”数据公开、标注简单、评估标准明确适合第一条路径练习完整闭环。选好项目后给自己的目标是“上线运行”而不是“训练完了”。哪怕只有一个用户能用也要把监控、日志、反馈收集做齐。只有亲手经历过线上问题你才会真正理解 AI 工程和算法实验的不同。我见过太多训练了很久模型却从未部署过的人他们对“模型服务化”毫无体感这恰恰是工作中最常遇到的问题。5.3 一个容易被低估的学习习惯写工程日记最后分享一个我觉得特别值钱的个人习惯维护一份工程日志或者叫决策记录。不用很复杂一个 Markdown 文件就够了每个阶段记录这些内容尝试了什么方案预期是什么实际效果如何和预期有什么差异为什么会有这个差异下次可以怎么改进。这个习惯的价值会在几个月后显现。AI 项目最折磨人的点在于评估指标和线上效果之间常常对不上你改了 prompt 感觉变好了但没有量化记录两周后有人问你怎么改的你完全想不起来。有工程日志在手你可以非常清楚地回看当时的判断依据和数据而不是靠记忆和感觉。我自己的日志模板大致是日期、目标、变更内容、实验参数、评估指标变化、显著案例、一句话总结。每次改动哪怕很小也要花三分钟记下来。坚持一年这份日志就是你的私人项目复盘手册比任何教程都值钱。这个习惯也解决了一个 AI 工程里的核心痛点一切决策可回溯。从零开始做 AI 工程最重要的不是某个炫酷模型而是一套扎实、可持续、能自我修正的流程。把日志写好把评估做准把监控做细你的项目会越走越稳别人还在被线上问题追着跑的时候你已经能从容地对着数据判断下一步该怎么走了。