很多人拿到一个AI工程的题目会下意识先打开GitHub找一个开源模型然后开始跑demo。但真正从零开始把一套AI系统做到能上线、能维护、能迭代难度完全不在模型本身而在模型外面的那圈工程骨架。今天想借这个ai-engineering-from-scratch的话题把我这些年从零搭AI项目的完整思路、踩过的坑、以及沉淀下来的工程方法一次性讲透。如果你是机器学习工程师、数据工程师或者刚被老板扔去带一个AI落地项目的负责人这篇文章应该能帮你少走不少弯路。这是一篇纯经验沉淀不绑定任何特定框架讲的都是底层通用的工程逻辑。所有步骤都来自实际项目复盘我尽量做到可以直接抄作业。1. 项目启动前的关键决策别急着写代码很多AI项目死在第一步不是因为技术不行而是因为一开始就把方向定错了。从零做AI工程最重要的不是模型选型而是先搞清楚你要解决的到底是不是一个AI问题以及有用的定义是什么。1.1 先定义清楚“能用的AI”到底长什么样我见过太多团队上来就追求吊打SOTA但真正上线时业务方根本不关心你的F1比竞品高0.5个点他们只关心这玩意能不能减少人力成本能不能把错误率降到可接受范围。所以第一步必须是跟业务方一起把成功标准量化成可验收的指标。比如做一个智能客服问答系统你要先明确用户问什么类型的问题系统必须能答答不上来时的兜底话术是什么准确率、召回率的底线是多少比如标准问题识别准确率不得低于90%响应时间要求比如P95在800毫秒以内多少比例的会话需要人工接管接管后的坐席效率是否提升。这些指标定义清楚后你才能反过来判断模型方案、数据处理策略、部署架构够不够用。我在每个项目启动时都会做一张指标-阈值-验收方法的对照表就三列简单粗暴但能避免后面无穷无尽的扯皮。提示不要用准确率越高越好这种话当目标。没有阈值约束的模型评估等于没有评估。定指标时一定带上业务方的签字确认否则后期模型上线效果不符合玄学预期时你会被无限要求再调一调。1.2 技术选型从零开始不等于重复造轮子有人误以为from scratch就是一切从零写包括Transformer。这是对学生作业的理解不是工程实践。真正从零做AI工程指的是你从需求出发自己搭建完整的技术栈和数据流但底层该用成熟框架就用框架该用开源模型就用开源模型。我一般从三个维度选型任务是判别式还是生成式分类/抽取类任务首选精调的BERT家族或DeBERTa生成任务摘要、对话、代码生成直接上LLM API或开源大模型的LoRA微调不要自己从头预训练成本远超出你的预算。团队熟悉度选团队最有经验的框架。PyTorch是常态TensorFlow也没毛病关键是团队能维护。我倾向于PyTorch加Hugging Face生态因为文档全、迭代快、社区踩坑记录多。部署环境约束如果只能在CPU上跑那就老老实实用蒸馏小模型或者小型CNN/线性模型别拿几十亿参数的模型硬刚。选型还有一个隐性要求必须能跟你们现有的日志系统、监控系统、CI/CD流程打通。否则模型再强你也会被集成地狱折磨到崩溃。1.3 资源与成本评估把账算明白再动手AI工程烧钱是常态。一块训练卡一小时几十块钱你以为只跑一晚上实际上调试代码会反复跑几十次。我的经验是预算至少要在你预估的3倍以上。而且除了训练算力别忘了这些隐形开销数据标注人力成本如果是外部标注团队按条计费会把你吃到破产推理阶段的GPU/CPU服务器费用很多项目上线后推理成本比训练高一个量级存储成本原始数据、特征工程中间结果、模型文件版本随随便便几百个GB实验追踪与日志告警系统的维护成本。我自己会在项目启动前做一张成本预估表项目启动后排好优先级哪些环节必须用GPU哪些可以CPU凑合数据标注先做500条还是5000条。记住一个原则从零起步的项目第一步永远是用最小资源验证可行性而不是一步到位建设豪华平台。2. 数据工程AI工程的隐形地基只要做过一个真实AI项目你就会承认数据和特征决定了算法的上限。但数据工程绝不只是收集数据、清洗、训练这么简单里面藏着大量让人抓狂的细节问题。2.1 数据获取与清洗的坑我做过一个文本分类项目从业务系统导出的原始数据有30万条但清洗完只剩不到4万条可用。你以为脏数据就是缺失值和重复项实际上真正的坑是这些字段漂移同一字段在不同月份、不同业务线中含义不同日期格式时而2024-01-01时而20240101枚举值一会儿英文一会儿中文标签噪声业务方手工打的标签主观性强相同条件下不同人标注结果差异很大时效性偏差模型上线后用户行为模式会变训练数据太旧会跟不上真实分布非法内容文本里混着广告、乱码、emoji、特殊字符不做过滤就会严重影响模型效果。我的清洗流程大致是先做字段探查每个字段的非空率、枚举值分布、长度分布、时间范围再写数据质量校验规则然后把清洗步骤固化成脚本每次新数据到达都跑一遍同一个流程。这样至少保证你喂给模型的数据不是一坨随机垃圾。清洗完毕还要做数据打样就是抽出一部分数据人工查看真实长相。这一步极其关键。很多模型效果差往往是清洗规则误伤了有效信息比如把VIP用户中的VIP当成广告词删掉了。2.2 标注质量怎么把控训练数据标注是AI工程里最容易被低估的环节。很多团队直接把原始数据丢给外包回来就训练结果模型学了一堆标注工的随机错误。我后来定了几个规矩先写标注手册不是我写而是跟业务方一起写。每条规则都要配正例、反例、边界情况比如这个类别到底包不包含咨询退款的场景。小批量试标第一批每人标50条然后计算标注员之间的一致性Kappa值。低于0.6就得重新培训、重新定义标准大于0.8才说明标准清晰。真实标注时至少抽10%的数据做二次校验发现问题立即反馈并修正历史标注。对标注结果做困难样本分析把模型预测错而标注正确的样本挑出来再加到下一轮标注任务中让标注员重点处理这些边界情形。做这些工序会拖慢进度但长远看是省钱的。你后面调模型要花的每一分钟都建立在数据质量上数据是污水模型就是污水里的鱼。2.3 数据版本管理与特征存储训练完一个模型三个月后想复现当时的结果发现代码还在数据却记不得用哪个版本了——这是我早期最痛的经历。AI工程的一个基本原则就是数据也进版本管理。我的做法是给每个数据集打上一个全局唯一ID包含来源批次、清洗版本、标注版本、生成时间等元信息。训练时把这个ID写进实验记录里同时把每个数据集存成不可变文件写后不修改。这样以后任何一个实验我都能追溯到当时用的是什么样的一批数据。特征工程同样需要版本化。每次调特征字段先拉分支、记录特征定义、保存特征算子不是保存特征值是保存生成特征的代码和配置然后通过特征存储服务统一管理避免不同团队重复算、算出来的口径不统一。3. 模型训练与评估从基线到可用数据就绪后才进入大家最熟悉的模型环节。但即使到了这里我仍建议保持工程化的克制不要一上来就堆花活。3.1 第一版模型用最小闭环验证可行性我的习惯是先搭一个超简单的规则或线性模型作为基线。别觉得丢人——基线真正的价值是帮你跑通整个数据管道和评估流程并给你一个必须打败的下限。比如文本分类先用TF-IDF加逻辑回归跑一遍如果是图像分类先上一个简单的ResNet18。基线模型的训练时间控制在几十分钟内能快速暴露数据读取、标签映射、评估脚本里的低级bug。等基线跑通再逐步换更强的模型。但换模型时不要一次性把所有技巧都堆上而是一次只改一个变量。比如基线跑完下一次只加预训练模型再下一次只加数据增强。这样每次效果变化你都能归因知道是哪里起了作用、哪里在帮倒忙。3.2 超参数调优与实验管理调参是玄学但工程上可以把它变成半自动化的流程。我不建议手动凭感觉改学习率而是用实验追踪工具比如MLflow、WB把所有实验参数、指标、代码版本、数据版本完整记录下来。这样你回头看时能对比几十组实验而不是好像当时那个版本更好。调参顺序也有讲究。我总结的顺序是先定batch size和初始学习率用learning rate finder找范围再调模型结构相关参数层数、隐藏维度最后调正则化项和训练策略warmup、weight decay、标签平滑。有一个很关键但常被忽略的点固定随机种子。在复现实验时数据加载顺序、dropout、模型初始化都会影响结果。工程上宁可损失一点随机性也要保证实验可复现。我通常在代码入口固定所有能固定的随机源并在实验记录里记录PyTorch版本、CUDA版本、numpy版本。别小看版本换个小版本都可能让结果漂移。3.3 评估指标选择的误区准确率99%也可能没用分类问题别只盯着准确率。如果你的场景是1000条数据里只有10条异常那模型全部预测为正常也能有99%准确率但这模型狗屁用没有。这时候必须看精确率、召回率或者AUC还要结合业务成本来确定阈值。比如做风险识别把正常用户误判为风险用户损失的是用户体验把风险用户漏掉损失的是资金。这两种错误的代价可能差几十倍。工程上要用代价矩阵来辅助定阈值而不是机械地把0.5当判定线。评估集也要小心。一定要把线上真实的数据分布作为评估分布的基准而不是只在训练集上分出一部分。如果训练数据和上线数据的分布不同离线评估再漂亮都是虚的。我习惯另外留存一个线上模拟集尽量从生产日志里采样并在上线前用这个集做一次影子评估看模型在真实数据上的表现。4. 部署与服务化让模型真正跑起来训练和评估只是冰山一角真正的AI工程重心在后半程——怎么把模型变成稳定、高效、可维护的线上服务。4.1 模型部署的几种方式与选型根据场景不同部署方案有几条路我按常见程度逐个说在线HTTP服务适合实时预测场景比如风控、实时推荐、智能客服。用Flask/FastAPI封装模型再加负载均衡和自动扩容。这个方案最通用但需要处理并发、超时、优雅退出等问题。批量离线预测适合量大但对时延不敏感的场景比如每天凌晨跑一次用户分群。直接用Spark或并行Python脚本读数据、批量推理、写回结果库。成本比在线低很多。嵌入式/边缘部署需要用ONNX或TensorRT导出模型压缩量化后跑在手机或边缘盒子。前期会麻烦但省带宽、省服务器。大模型API代理如果是调用外部LLM API那你要搭一层缓存和降级开关并且做好prompt版本管理和响应审计。我的建议是第一版永远用最简单的方案。对一个刚开始跑的业务先用一台小机器上FastAPI加一个简单的进程内缓存然后随时准备切换到更完整的方案。不要一开始就上K8s、上GPU集群那些是流量和需求验证以后才需要考虑的复杂度。4.2 推理性能优化延迟、吞吐、成本之间的平衡当你想让模型扛住线上流量会发现性能优化是个系统工程。主要的三个优化角度模型层面量化INT8/FP16、剪枝、蒸馏、批量动态paddingLLM推理中的continuous batching。我常用的是把训练好的模型从FP32转向FP16在大多数GPU上显存直接减半延迟也有改善如果需要进一步压缩就上ONNX 量化。服务层面加缓存相同输入直接返回缓存结果、连接池复用、异步推理、把推理服务拆分到独立的worker进程中避免GIL限制。基础设施层面模型加载到显存驻留避免每次请求重新加载模型设置合理的batch推理多个请求攒一起算用GPU打满而不是只用CPU。有一个经验是上线前做一次压力测试。用wrk或者locust模拟线上流量测出P95延迟、最大吞吐、内存上限。如果发现延迟超标先定位是模型推理时间还是网络开销再对症下药。我遇到最离谱的情况是——模型推理只花了10ms但JSON序列化和网络传输花了60ms导致整体超时。这在工程上比模型本身更值得优化。4.3 测试与灰度发布把模型当成软件来对待就要有测试、灰度、回滚机制。模型测试和普通单元测试不一样不光要测代码能不能跑还要测预测行为是否符合预期。我在项目里通常写两类测试业务用例测试准备一批典型输入、边界输入、异常输入空字符串、超长文本、特殊字符断言模型输出是否符合预期防止上线时把一个废模型带上去。性能基准测试固定一批压测脚本记录每次上线的延迟、吞吐、内存占用回归变化一目了然。灰度发布也不可省。新模型先切5%流量观察线上指标对比老模型确认没有异常后再逐步放大比例。而且一定要保留回滚开关一旦发现异常一键切回旧版本。AI工程经常翻车有回滚机制能救你于水火。5. 监控与持续迭代AI工程的长期战场模型上线不等于项目结束而是另一个开始。线上模型每天都在经历真实世界的风吹雨打如果没有监控和迭代机制模型会悄悄烂掉。5.1 线上指标监控不只是看服务器负载通用的服务器监控当然要有CPU、内存、GPU利用率、请求量、延迟、错误码但对AI服务来说更关键的是业务效果指标。你上线一个推荐模型光看接口错误率不够还要看用户点击率、转化率有没有变化。而这些业务指标常常不在模型服务本身的日志里你要跟业务团队约定好打通数据链路把预测结果和业务结果关联起来。我的做法是在模型服务中记录三个维度的日志输入数据日志脱敏后的特征和文本别记录个人隐私预测结果和置信度关联业务ID方便后续去业务库中匹配真实结果。然后定时任务把这些日志汇总生成监控报表设一个基线比如点击率低于上周均值5%就报警。很多团队不做这一步结果模型上线两周后业务效果变差还找不到原因非常被动。5.2 数据漂移与模型漂移这是AI工程中最隐蔽的危机。所谓数据漂移就是线上输入数据的分布跟训练数据不一样了。比如用户语言风格变化、新商品品类出现、季节波动都会让模型面对没见过的输入。检测数据漂移不需要多高深我常用统计方法计算特征均值、方差、分位数的变化对文本数据统计关键词频次和长度分布把线上输入embedding后和训练集embedding做分布距离对比比如用KLD或最大均值差异MMD更直白的做法是把线上收入存起来每隔几天跟训练集做个分类器AUC——如果分类器能轻松分开线上和训练数据说明漂移严重了。模型漂移则是指模型的效果随实际环境变化而下降。这只能通过真实业务指标来观察比如客服模型的解决率、识别模型的误报率是否变差。一旦发现漂移就要触发重新训练。5.3 反馈闭环与自动重训从零做AI工程我最想强调的就是闭环。模型必须能不断从线上反馈中学习才叫一个活系统。正常的闭环设计是线上预测结果 - 用户/业务反馈人工纠错、用户行为 - 进入标注队列 - 定期合并到训练集 - 重训模型 - 评估 - 灰度上线。中间每个环节要尽可能自动化但我并不建议一开始就上全自动重训风险太大。我自己的项目里是手动审批的半自动每天定时从线上收集新样本和反馈信号自动存入待标注池每周人工标注/核查一批合并进训练集每周跑一次重训实验生成评估报告如果新模型离线指标确实优于线上版本才手动触发灰度发布。这样既保证了模型持续更新又能在每次更新前过一遍人工把关防止自动流程把模型越练越歪。6. 团队与流程AI工程是系统工程组件都齐了但AI项目最终能不能成很大程度取决于团队协作和工程流程是否顺畅。6.1 角色分工与协作边界一个完整AI工程团队通常需要这些角色产品经理定义业务指标和验收标准数据工程师负责数据管道、清洗、调度AI工程师负责模型训练、调优、评估、部署后端/平台工程师负责服务化、API封装、监控告警、CI/CD标注团队或标注供应商跟AI工程师对齐标注标准。最怕的是每个人都在等别人或者互相推诿。我通常会画一张RACI矩阵谁负责、谁批准、咨询谁、通知谁明确每个交付物的Owner。比如训练数据集v3.0的Owner是数据工程师但验收者是AI工程师模型服务API的Owner是后端工程师但压测标准是AI工程师提供。边界越清晰扯皮越少。协作中还有一个高频坑就是模型交接。训练工程师把模型文件丢给部署工程师然后就不管了部署工程师不知道模型的输入输出格式、异常处理方式、超时阈值该设多少。我的办法是给每个模型配套一个模型卡里面写清楚模型用途和适用场景输入输出schema含示例预处理/后处理步骤同一段代码要入库已知限制和失败模式监控指标建议。这相当于把模型当成一个API交付而不是扔一个权重文件。6.2 从零到一的项目复盘最后聊一点复盘心得。每次AI项目结束后我都会做三层复盘技术复盘哪些技术决策是对的哪些是过度设计比如是不是本来没必要上分布式训练一台A100就够了是不是过早上了缓存和异步导致系统复杂又难排查流程复盘什么环节卡最久往往不是模型训练而是数据标注返工、跨团队Waiting、线上bug定位。把时间花在哪下个项目就要改哪里。饿货复盘业务指标到底有没有变好很多AI项目做完模型指标漂亮但业务数字纹丝不动那你得反思是不是一开始就选错了问题。真正有价值的AI工程是让业务得到了实实在在的提升而不是产出了一堆没人用的模型。从我的经验看从零起步做一个AI工程最大的成本不是算法而是大量看不见的数据治理、流程规范、监控运维。这些东西听起来不性感却是模型能不能落地的生死线。如果你正准备开一个新AI项目别急着找最新模型先把数据管道、评估标准、监控闭环这些地基一层层搭起来后面你会感谢现在的自己。最后分享一个我最近特别受用的小习惯每次上线新模型我都会手动跑一遍新模型打旧数据的批量预测把预测结果和真实标注拿到Excel里做人工抽样对比而不是只看自动评估报告。这个动作极其费时间但每次都能发现一些自动评估发现不了的问题比如某些固定模板输入被错误分类、某些特殊格式文本被截断。哪怕评估报告里的精度全面提升人工抽样也值得做。AI工程做到后期真正让你安心的永远是这些笨办法。