最近这波 AI 工具的火爆程度相信大家都感受到了。但我发现身边很多同学、同事包括一些已经在用 AI 辅助写代码的开发者对“AI 工程”这件事还是有点摸不着门道感觉 AI 很厉害但真让自己从零开始搭一个能用的 AI 系统又不知道从哪下手。我这个标题起的是 ai-engineering-from-scratch想聊的其实就是我自己从零到一搭建 AI 工程能力的那条完整路线——不是让你去读一堆高深的论文也不是让你去追那些一两天就换一茬的新模型而是把数据、模型、评估、部署这条链路上最实用、最绕不开的环节一个一个说清楚。这篇文章适合谁适合那些已经具备一定编程基础、但没系统做过 AI 项目的开发者也适合被业务推着要上 AI 能力、但团队里没有专职算法工程师的团队。我会把我实测过的路线、踩过的坑、以及那些文档里不会写但实际特别要命的细节全部整理出来。我希望你看完以后不是“知道了 AI 很牛”而是真正能动手去验证、去落地一个属于自己的 AI 工程闭环。1. 为什么需要一套从零开始的 AI 工程方法论1.1 从“调包”到“工程”的 gap 到底在哪先说一个我观察到的普遍现象很多人觉得 AI 工程难难在“模型调不准”。但实际上模型调不准只是最后呈现出来的一个表象真正难的是你压根没有一个系统性的方法来定位问题出在哪一环。我自己最早做文本分类项目的时候就是典型的“调包侠”拿一个预训练模型跑一下效果差换个模型再跑效果还是差然后就开始怀疑是不是自己数据太少了或者是不是 GPU 不够。折腾了好几天最后才发现问题根本不在模型而在数据标签有大量冲突——同一条文本在不同批次里被标注成了不同的类别。那一次经历让我意识到没有工程方法论的 AI 实践就是在撞大运。从零开始做 AI 工程跟从零开始学一个编程框架是不一样的。写业务代码的时候输入输出是确定的逻辑链路是给定的你照着接口文档调就是了。但 AI 工程是一个“不确定性问题”你不知道一个模型在这个数据上到底能跑出什么效果你不知道训练出来的模型在线上会遇到什么分布外的输入你也不知道一个优化策略到底是在真正提升模型能力还是在过拟合老样本。所以AI 工程方法论的核心不是教你某一个大模型的调用技巧而是教你一套管理不确定性的流程和习惯。1.2 我的目标边界不追大模型先把闭环跑通这里我必须先划一条边界。我现在讨论的“从零开始”不是让你从零去复现 GPT 或者从零去训练一个大参数模型那是超大团队和超多预算才能干的事。我讨论的从零开始是把一个 AI 项目的生命周期完整地跑一遍从定义问题、收集数据、训练一个哪怕很小的模型到把模型部署成服务、持续监控和迭代。先把闭环跑通比一开始就追求 SOTA 重要得多。理由很直接闭环跑通了你才能在每个环节获得真实的反馈。没有部署你就不知道模型上线后到底会收到什么样的输入没有监控你就不知道模型是不是在悄悄退化没有迭代机制你优化模型的努力就只是实验室里的自娱自乐。我见过太多团队模型训完就发一个报告然后没有然后了过了半年那个模型就成了文物。所以我强调的目标边界是用最小的成本把“数据—模型—评估—部署—迭代”这一整条链路走通让 AI 能力真正变成一个可以持续演进的系统。2. 地基阶段把数据、模型、评估三块拼图一次性摆正2.1 数据环节为什么比模型环节更早卡脖子很多人一上来就急着选模型但我的经验是数据问题永远比模型问题更早出现也更致命。我可以负责任地说在我接触过的大多数实际项目里模型效果差的原因排第一的是数据质量排第二的是数据与业务目标不匹配模型本身的问题反而排到了第三。数据环节有几个特别容易踩的问题。第一个是标签噪声。业务方拍脑袋给了一批标签里面互相矛盾的特别多这时候你训练得越努力模型学到的“错误规律”就越牢固。第二个是类别不平衡。比如你做的是缺陷检测正常样本 99%缺陷样本 1%模型只要全都预测成“正常”准确率就有 99%但这个模型毫无用处。第三个是数据分布与线上分布不一致。训练数据是从历史存量里抽的线上进来的却是新产生的数据两者的特征分布可能已经完全漂移了。那么该怎么操做我自己的标准动作是三步。第一步做一次彻底的数据探索包括每条样本的特征分布、缺失值占比、标签交叉情况把这些统计结果当作项目开工前的“体检报告”。第二步圈定一个“最小可信数据集”也就是人工反复确认过标签无误的一部分数据这个数据集要足够小小到你能靠人工记住其中大部分样本的形态这样你后续调模型时才能快速判断是数据问题还是模型问题。第三步建立数据版本管理不要直接改原始数据文件每一次清洗、转换都要保留可追溯的记录否则你复盘的时候根本不知道今天的模型是基于哪一版数据训练出来的。2.2 模型选型的最小可用判断标准数据摆正之后才轮到模型选型。很多人选模型的标准是“哪个论文刷榜刷得高选哪个”这是典型的工程灾难。因为你选模型不只是选一个网络结构你是在选一套后续所有的工程约束包括训练成本、推理延迟、可解释性、部署难易度。我给自己的选型判断标准非常简单就四个关键词足够好、足够小、足够懂、足够稳。“足够好”指在最小可信数据集上效果能达到业务的下限要求“足够小”指推理时的资源占用能在你的部署环境里撑得住而不是只能在 A100 上跑“足够懂”指你能理解这个模型的核心原理至少知道它的输入输出该怎么伺候它的失败模式大概是什么“足够稳”指模型对不同随机种子、不同训练数据子集跑出来的效果波动不要太大否则你无法判断改进到底有没有用。我一直推荐从基座模型加简单分类头的路线开始而不是一上来就搞复杂的大模型微调。原因在于分类头是你能完全掌控的基座模型参数冻结了你的变动面就很小问题定位就很容易。等你把这条链路跑熟了再引入 LoRA 这类轻量化微调手段就会顺畅得多。2.3 评估指标没跑过 baseline 之前别谈优化我见过太多人死在“盲人摸象式优化”上。今天调一个超参数看一眼损失下降觉得有进步明天换一个模型觉得准确率涨了又觉得有进步。但这都是错觉因为没有一套统一的评估协议你根本不知道这些变化是真改进还是随机波动。评估这件事我的建议是先把基线打牢。怎么做第一选一个最简单的启发式方法当 baseline。比如文本分类你就用 “TF-IDF 线性分类器”如果是回归任务你就用 “历史均值”。这个 baseline 的意义不是为了跟它比谁的算法高级而是为了给你一个参照系你花了大功夫搞出来的深度学习模型如果连这个简单 baseline 都打不过那你应该先回头去查数据和标签而不是继续堆模型。第二固定评估集和评估指标。评估集必须是在训练过程中从未见过的数据评估指标不能只看准确率要结合业务场景看精确率、召回率、F1甚至要看混淆矩阵。第三每次实验只改一个变量。这个原则听起来像废话但实际操作中特别难做到因为人的记忆是有偏差的你会不自觉地把两个实验之间的所有状态差异都归因于你人为改动的那一个变量而忽略了环境本身的变化比如数据版本变了、随机种子变了。所以实验记录要结构化把数据版本、模型版本、超参数、评估结果一次性记录下来别靠脑子记。3. 从零手写一个可运行的最小 AI 项目完整实操路线3.1 我刚动手时选的任务和数据集方法论说得再多都不如动手跑一遍。我建议你也选一个“小而完整”的任务来当练习。我当时选的任务是“商品评论情感二分类”数据集用的是网上公开的电商评论数据。为什么选这个因为这类数据不需要自己标注容易获得文本短训练快而且业务含义清晰方便你判断模型输出到底对不对。我给你的建议也是这样任务的选择必须满足三个条件。第一个公开数据集这样你能跟别人的实验结果做对比知道自己处于什么水平。第二个业务含义明确就是你不需要领域专家解释也能判断模型输出合理不合理。第三个数据量不大不小大概一万条左右太少了一分钟训练就结束了感受不到 Debug 的过程太多了机器跑不动容易把时间浪费在等待上。3.2 预处理、特征工程与训练脚本的骨架确定任务和数据后就要开始写代码。我建议你把整个流程拆成四个文件data_preprocess.py、train.py、evaluate.py、predict.py。这不是为了炫技而是为了让每个环节都能单独运行、单独验证。很多初学者喜欢把整个流程写在一个 Jupyter Notebook 里图一时方便后面灾难就来了今天改预处理明天重新训练你根本不知道之前那个结果是用哪版代码跑出来的。先看预处理。文本类任务的基础预处理包括去 HTML 标签如果数据爬自网页、统一大小写、特殊符号处理。但我强烈建议你不要做太激进的清洗比如不要把所有标点都删掉、不要把数字都替换掉因为很多语义信息就藏在这些看似不规则的字符里。分词这个环节中文任务要考虑是用逐字切分、分词工具还是用字粒度 BPE不同数据集最优方案不一样最好做个简单对比实验。英文任务则可以直接用子词切分。特征工程这块我的路线是“两步走”。第一步用最简单的文本特征比如 TF-IDF跑出一个 baseline。第二步再引入预训练向量例如直接用现成的中文词向量或句子向量模型把文本转成稠密向量后输入简单分类器。这里要注意一个细节如果你用预训练模型做特征提取需要冻结它的参数只把它当作一个特征提取器否则计算量会非常大而且容易过拟合。训练脚本的骨架我习惯这样组织先加载数据切分训练集和验证集然后定义模型结构再定义损失函数和优化器最后进入训练循环。这个循环里面最容易被忽略的是“模型保存策略”。不要最后一个 epoch 结束就把模型保存下来正确的做法是每次验证集指标提升时就把当前模型保存下来这样你最终拿到的模型是验证集上表现最好的那一个而不是训练过程末尾的那个。还要设置早停机制当验证集指标连续若干个 epoch 不提升时就终止训练这样可以极大节省算力和时间。3.3 训练结果不理想时的排查顺序训练跑完结果不理想怎么办这个环节我总结了一套固定的排查流程按顺序执行能省下大量瞎折腾的时间。第一步检查 loss 是否正常下降。如果 loss 根本没降或者剧烈震荡那大概率是学习率设置不合理或者优化器选得不对也有可能是训练数据里存在大量错标。第二步检查模型在训练集上的表现。如果训练集上都搞不定比如 loss 降不下去或者过拟合严重那就是模型容量不足或者正则化过度这时候要增加模型复杂度或者调整正则化强度。第三步如果训练集效果尚可、但验证集效果差那就是过拟合这时候应该优先考虑增加数据量、做数据增强、加大 Dropout 或引入早停。第四步如果训练集、验证集都正常但测试集上表现崩了那就要查是不是测试集和训练集的数据分布不一致比如文本长度分布、类别分布有明显差异。这里要特别强调一点不要迷信验证集。验证集本身也是从历史数据里切出来的它只能代表历史分布。如果业务场景里线上数据会不断变化那验证集上的指标只能作为参考你还需要建立一套线上的实时反馈通道才能真正知道模型在实际环境里的表现。这就是后面要讲到的部署和监控部分了。4. 工程化落地模型部署、线上推理与服务化改造4.1 把模型封装成接口时需要处理的细节模型训练完真正让它产生价值的动作是把它部署出去。我见过不少团队训练环节挺专业但一到部署环节就露怯直接把一个 Python 脚本交给运维让运维挂着跑结果线上稍微一点并发整个服务就崩了。这里我要讲的是部署时那些特别细节又不能忽视的点。第一模型格式的转换。训练框架里保存的模型文件跟推理框架要求的格式往往不一样。我常用的路径是先把模型转换成通用的格式比如 ONNX再交给推理引擎做加速。这个环节最要命的是“算子兼容性”问题——你的模型里可能有一些自定义算子转换的时候会报错或者转换成功但推理结果和训练结果不一致。所以我想提醒你格式转换完成后必须做一次“一致性验证”用同一批输入分别跑原始模型和转换后的模型比较输出的差异差异阈值控制在千分之一以内才算合格。第二输入数据的预处理统一。训练时你做了分词、去噪、截断那线上推理也必须做完全一样的预处理。很多部署事故就是这么来的训练和推理的预处理代码分属两个仓库维护人不是同一个人两边改着改着就对不上了。解决办法是把预处理逻辑抽成一个独立的模块训练和推理都调用同一份代码从根本上避免分叉。第三Batch 化的处理。即使你线上打分是一条一条请求进来也建议在推理引擎里做动态打包也就是把短时间内到达的若干条请求攒在一起组成一个 Batch 再喂给模型。这样能成倍提升 GPU 利用率。当然这样做会增加单条请求的延迟所以你要在吞吐量和延迟之间做权衡通常我会设置一个最多等待多少毫秒的窗口和最大批量大小。4.2 性能基准测试与并发问题部署完之后一定要做性能基准测试不要直接切线上流量。我的测试方法是分三步走。第一步单条延迟测试发一条请求统计从进入到返回的完整耗时包括网络开销、预处理耗时、模型推理耗时、后处理耗时。只有把这些耗时拆开看你才能找到瓶颈在哪。我见过最离谱的情况是模型推理只需要 20 毫秒但预处理阶段花了两百多毫秒因为在线上的输入格式里混入了大量需要复杂解析的字段。第二步并发压力测试用工具模拟多路并发请求观察服务的 P95、P99 延迟和成功率同时关注 CPU 和 GPU 的利用率。这里有一个关键点并发数一上去延迟会快速恶化因为这已经变成了资源竞争问题不只是模型算力问题还包括内存分配、锁竞争、网络线程池的调度。你要找到那个“延迟拐点”确定这个服务能安全承载的最大并发数。第三步长期稳定性测试让服务持续压测数小时甚至数天观察内存会不会缓慢泄露、响应会不会出现周期性的超时。这类问题在风控、交易等对稳定性要求极高的场景尤其致命。我记得有一次我部署一个图像分类服务压测两小时都正常但到第三小时突然开始大量超时一查才发现有缓存键没有设置淘汰策略缓存的键越来越多最终把内存耗尽了。4.3 监控、日志、版本管理AI 工程里最容易被忽略的三件事模型服务部署上线之后很多人的关注点就转移到新模型和新算法上去了工程上会出现一段“真空期”。但我要负责任地告诉你上线那一刻才是 AI 工程真正的起点因为你会开始接触到训练时完全没见过的真实数据、真实调用模式。监控方面除了常规的 CPU、内存、延迟、QPS 这类基础设施指标AI 服务还要监控“模型专属指标”。我举两个最典型的一个是“特征漂移指标”线上请求的特征分布跟训练集特征分布的差异程度用 PSI 或者 KL 散度来度量另一个是“预测置信度分布”如果模型给大多数请求的置信度都接近 0.5说明它处在很“迷茫”的状态这时候要警惕是不是线上输入出了什么问题。日志方面不能只记录错误日志和访问日志还要把每条请求的“模型输入特征关键值”和“预测结果、置信度”记录下来存成结构化日志。这样做的目的是当业务方反馈某个预测错了时你能快速回溯出错的请求找到模型出错的原因而不是干瞪眼。版本管理方面我强调模型文件必须和训练代码、数据版本、超参数配置一一对应地登记在册。我常用的方案是模型文件的命名带上日期时间和 commit 号并且把训练配置以 JSON 格式跟模型文件打包进同一个目录。这样做虽然增加了成本但你换模型、回滚模型、复现实验结果的时候就会发现这点成本极其划算。5. 进阶路线从单点模型走向多组件 AI 系统5.1 检索增强、Agent 工作流等系统级能力的引入时机单点模型部署上线这算是一个里程碑。但真实业务很少只依赖一个模型更多时候你要把模型组合成一个系统。这里我特别想聊的是检索增强RAG和 Agent 工作流这类系统级能力因为它们是当前除了基础模型之外最火、也最影响实际效果的方向。我的建议是不要为了追热点而引入这些复杂架构而是等你的单点模型闭环跑通之后再根据具体的业务痛点来决定要不要往系统方向走。什么时候该引入 RAG当你发现模型输出的知识密集型答案不准确、会一本正经地胡说八道而你的业务又特别依赖领域知识时RAG 就是值得考虑的方向。什么时候该引入 Agent 工作流当你发现任务需要多步推理比如先判断意图再决定调用哪个工具再根据工具结果生成最终答案每一步之间并非固定流程时Agent 工作流才有价值。引入系统级能力的最大风险在于复杂度陡增。RAG 不只是“检索模型拼接”还牵扯到文档切分策略、向量索引的选择、检索结果重排序、检索质量评估等多个环节每一个环节都能让你调上几天。Agent 工作流更麻烦因为流程的分支很多你必须在代码层面显式定义状态流转做好每一类分支的容错和兜底否则用户稍微一个超出预设的输入整个 Agent 就会在流程里撞死或陷入死循环。5.2 多模型协作时的接口设计与数据契约多组件系统必然带来“接口设计”的问题。这里我强烈建议你采用“模型即服务”的思路每一个模型组件都封装成标准的 HTTP 服务通过统一的接口协议对外提供服务。这个接口的输入和输出不能是“你好请帮我总结以下内容”这种自然语言而应该是结构化的 JSON里面带清晰的字段定义和可能的枚举值。为什么因为模型组件之间是程序化调用自然语言容易产生歧义程序拿到之后没法稳定地解析。这种场景下接口之间要约定好“数据契约”。我举一个实际例子假设你有一个意图识别模型一个实体抽取模型还有一个答案生成模型。意图识别模型的输出应该是一个结构体包含 intent 字段取值为有限的枚举列表和 confidence 字段取值范围 0 到 1并约定低于 0.6 时需要走兜底流程。实体抽取模型的输出应该是一个实体列表每个实体包含 type、start、end、text 四个字段。这样下游的答案生成模型才能确信地消费这些数据。此外多模型协作时要注意一个“错误传播”问题上游模型的预测错误会传导到下游而且可能会被下游模型放大。所以接口设计时要显式携带 confidence 信息并且下游模型要有判断上游输出是否可信的逻辑。否则整条链上只要一个环节出问题最终用户感受到的就是一次莫名其妙的坏体验。5.3 我踩过的几个坑和总结的避坑清单在我的实践里最让我印象深刻的坑有三个。第一个是参数传递不清的坑。我做过一个客服工单自动分类的系统上游模型输出的别名叫 category_id下游模型读的字段叫 cat_id两边字段没对齐结果所有预测结果全部变成了默认值系统还“安静”地跑了一个星期。第二个是无缓存策略的坑。某个高频查询接口直接命中大模型调用没有加缓存上线当天就把 API 额度打爆了。这看起来是常识但在“跑通功能”的兴奋状态下特别容易忘。第三个是缺少 fallback 路径的坑。Agent 工作流一旦某个工具调用失败整个流程就挂在那没有重试也没有给用户一句“系统忙请稍后再试”用户体验极差。这三个坑其实反映的是同一个问题做 AI 工程的人注意力全放在“模型多聪明”上而忽略了“系统的鲁棒性”。所以我的避坑清单里第一条写的是“所有外部依赖必须有超时和重试”第二条写的是“所有模型输出必须做格式校验”第三条写的是“所有高耗时算子必须加缓存”第四条写的是“所有关键路径必须有 fallback 逻辑哪怕只是返回一个预设的兜底答案”。6. 把 AI 工程从“能跑”变成“可信”的个人经验6.1 怎样用最小成本建立迭代闭环模型上线之后最难的不是“跑起来”而是“持续变好”。怎么用最小成本建立迭代闭环这是我最想分享的东西。我把这个闭环拆成四个节点线上数据回流、badcase 分析、模型再训练、灰度发布。第一步线上数据回流。我对所有线上请求都做了匿名化脱敏后记录入库请求里的原始输入、模型输出、置信度还有业务方标记的“对/错”反馈全都在表里。这个表就是我后续迭代模型的素材库。第二步badcase 分析。每周定期抽出一批预测错误的样本人工去分析错误模式。我建议不要一条条孤立地看而是把错误样本聚类成几类比如“长文本上的错误”“专业术语上的错误”“否定句式上的错误”这样你会发现模型的短板非常集中根本不需要漫无目的地调参直接针对这些短板找解法就行。第三步模型再训练。把新积累的正确样本和错误样本一起混入训练集重新训练模型。这里要特别小心“分布偏移”如果线上回流样本跟原始训练样本分布差异太大混训时需要对原始训练样本做降采样防止模型被线上数据带偏。第四步灰度发布。新模型先只对 5% 的线上流量生效对比它与旧模型的指标比如转化率、用户投诉率、预测置信度均值再逐步放开流量。这条闭环我一个人一星期基本能完整跑一遍。你不需要一个庞大的平台用离线脚本加定时任务就能完成大部分动作关键是流程要固定不能靠人肉驱动。6.2 给后来者的几条实操建议最后我再给准备从零开始做 AI 工程的朋友几句实在话。第一从小处着手找一个不超过两周能完成闭环的任务。别一上来就做那种需要多团队协作的大规模平台你的第一个项目不是展示领导看的大屏而是磨炼你完整踩通链路的过程。第二把“记录”当成第一生产力。我不是让你写华美的实验报告我是让你把每一次实验改了什么、基于哪版数据、用了什么参数、得到什么结果用最简单的表格记录下来。没有记录就没有复盘没有复盘就永远在低水平重复。第三训练和推理必须用同一套代码和同一套特征逻辑这个我之前反复强调过因为它是 AI 工程里最隐蔽、最消耗人力的坑之一。第四别怕 baseline 太土。用简单模型打底再用复杂模型超越每一步都有据可依这样即便复杂模型失败了你也有稳定可用的一版兜底而不是等到死线跟前发现所有方案都是半成品。这几点做下来你会发现 AI 工程这件事其实没有想象中那么玄学它跟写业务系统一样也有自己的纪律和章法。项目做到中后期真正撑起效果的往往已经不是某一个精妙的模型技巧了而是你那套稳稳当当从数据到部署的工程体系在持续出力。