很多人问我同一个问题我现在能调大模型的API能写Prompt能跑通一个Demo算不算一个AI工程师我的回答通常不太留情面不算甚至离得还挺远。ai-engineering-from-scratch这个项目我维护了快两年初衷特别朴素——把AI工程这摊子事从零开始拆透。不是让你从矩阵论和反向传播的数学推导啃起而是让你建立一整条完整的心智链路一个AI项目从想法到数据、从模型到评估、从部署到监控每一环到底在干什么、为什么这么干、坑最可能埋在哪里。这篇文章就是把这个项目的核心思路用文字完整梳理一遍。适合谁看想转行AI工程但不知道从哪下手的同学已经在调API但总觉得缺了底气的开发者以及被各种课程表搞晕、想建立自己知识体系的人。看完你会对AI工程到底包含什么有一个清晰的坐标系也知道自己卡在哪一环。1. 会调API不等于会做AI工程先撕掉这层幻觉1.1 调包侠和AI工程师的真正差距前阵子有个读者跟我分享他用大模型API做了个客服问答机器人能回答问题、能引用文档他觉得自己的AI工程能力已经到位了。我问他三个问题第一模型答错的时候你怎么定位是Prompt的问题、检索的问题还是上下文窗口截断的问题第二线上流量涨十倍你的服务延迟和成本怎么控制第三模型输出的内容怎么评估质量怎么持续改进他沉默了一会儿说这些问题他确实没想过。这就是调接口和做工程的分水岭。调API的本质是使用一个黑盒而AI工程的核心是驾驭一个黑盒。前者只需要知道输入输出格式后者需要理解黑盒内部的脾气它什么情况下会崩、什么输入会让它产生幻觉、怎么用工程手段兜住它的不稳定性。你不需要从零实现一个Transformer但你得知道注意力机制为什么让长文本处理变难嵌入向量之间的距离到底代表什么温度参数影响的是概率分布的哪个维度——这些认知决定你遇到问题时的排查方向是改数据还是换模型还是动服务架构。从零开始学AI工程真正的起点不是某一个框架的API文档而是建立这种分层归因的思维方式。1.2 从零开始不等于重复造轮子很多初学者一听from scratch就害怕以为要把整个技术栈从底层撸一遍。真不用也没必要。我理解的从零是每一层你都得亲手摸一遍哪怕只写一个玩具版本。比如数据清洗你当然可以用现成的库但你必须亲手处理过一份真实的生产数据——见过那种同一用户ID出现三种格式、同一商品名称有五个变体的烂摊子你才会理解垃圾进垃圾出这句话有多沉。再比如模型评估你用现成的评估框架写三行代码就能出指标但你不亲手标注过几十条样本、亲眼看模型在哪些case上翻车你就永远不知道准确率这个数字背后藏着多少猫腻。这个道理跟做饭一样。你不需要从种小麦开始学做面包但你必须亲手揉过面、见过面团发酵前后的变化否则你永远看不懂食谱里揉到扩展阶段到底是什么意思。AI工程同理——亲手写过数据pipeline的人和只会调现成ETL工具的人面对脏数据时的战斗力完全是两个量级。2. 起步阶段的技能栈数学补到哪、工程学到哪2.1 数学基础够用就好但必须有工作记忆总有人问我搞AI工程数学要学到什么水平是不是必须把PRML刷完我的建议很实际不需要成为数学家但四样东西必须有工作记忆——线性代数里的矩阵乘法与维度变换概率论里的分布与贝叶斯思想微积分里的梯度与链式法则以及统计学里的假设检验基本概念。为什么说是工作记忆因为调试模型、读论文、调超参数的时候你随时会用到这些概念的直觉。举几个真实场景你调大batch size导致训练不稳定如果你理解梯度估计的方差随batch size变化的关系就不会瞎试你看到一个向量检索的召回率异常如果你明白嵌入空间里距离的含义就知道该去看是哪一路数据把向量带偏了你对比两个模型的效果差异时如果不懂基础的显著性概念就可能把随机波动当成真实提升。有个挺形象的类比数学基础之于AI工程师就像乐理之于吉他手。你即兴弹solo的时候不会在脑子里做乐理分析但没有乐理底子的人弹到第五年就上不去了。2.2 工程能力清单这是决定你能走多远的底盘AI工程本质上是软件工程的一个特化分支。很多科班出身的人算法基础不错但一进真实项目就露怯——代码写得像科研脚本、不会用版本控制、部署全靠手动、出了问题不知道怎么排查。表里这几项我认为是入行的底线配置能力项掌握到什么程度为什么必须有Python类、装饰器、生成器、类型注解随手写所有AI生态的基础语言写不好寸步难行Git分支管理、rebase、冲突解决实验型项目最需要版本回溯不小心就翻车Linux/Shell常用命令、进程管理、日志查看服务器上排查问题全靠它Docker能写Dockerfile、理解镜像与容器环境一致性是AI项目的命门SQL/数据处理熟练join、聚合、窗口函数数据永远在数据库里不在CSV里基础网络HTTP协议、接口调试、鉴权方式模型要对外服务逃不开这些这套清单很多人觉得太传统、不够AI。但说实话我见过太多项目死因不是模型效果差而是代码没法复现、环境搭不起来、pipeline跑一半挂了没人能修。工程能力的价值平时看不出来一到关键时刻就是救命稻草。3. 从零搭建一个AI项目的完整链路以意图分类为例光讲概念太虚我拿一个真实做过的项目当例子给一个在线客服系统做意图分类判断用户的问题属于退款物流产品咨询投诉中的哪一类。这个项目不大但麻雀虽小五脏俱全完整走一遍大概需要两周。你会发现AI项目真正的难点不在模型而在模型前后那一大堆脏活累活。3.1 数据环节决定项目生死的第一关项目启动第一周我基本没碰任何模型代码。先把历史工单导出来——大概四万多条然后开始做数据手术。第一步是去重和清洗。合并同一个用户用不同入口提交的重复工单去掉那些只有你好在吗的无意义会话把错别字、繁体、中英混杂做基础归一化。这一步看着机械但直接决定后续所有环节的输入质量。第二步是标注。我拉了三个运营同学一起标每人标三千条然后抽样交叉检查。这里有个关键指标标注一致性。如果两个人对同一条数据标的类别不一样说明类别定义有歧义得先改标注规范再继续标否则模型学到的就是噪音。第三步是构造验证集。我从标注好的数据里专门留出1000条不参与任何训练当成模拟考卷只有这份考卷上的成绩才算数。数据准备阶段我见过最大的坑是类别不均衡。四个意图里产品咨询占了七成投诉只有5%。如果不处理模型全猜产品咨询都能有70%准确率但实际业务上一文不值。处理办法不只一种可以过采样少数类也可以在损失函数里给少数类加权重甚至可以考虑用异常检测的思路单独建模投诉意图。我的经验是先别急着上复杂方案做一次过采样加类别权重看验证集表现再决定。3.2 模型环节先跑通一个愚蠢的基线模型部分我有个雷打不动的习惯先做一个最笨的基线跑通全流程再谈优化。对意图分类这个任务最笨的基线就是TF-IDF向量加逻辑回归。为什么先做它三个理由第一它训练快几分钟出结果能立刻验证数据pipeline通不通。第二逻辑回归的权重可以直接映射回词汇你能直观看到模型到底在靠哪些词做判断——退款这个词权重高是合理的但如果亲这种称呼词权重异常高说明数据里有隐藏的bias。第三后续任何更复杂模型的提升都拿这个基线当参照系。没有基线你根本没法回答BERT比逻辑回归好多少这个问题。基线跑通之后我换成了微调一个开源的中文预训练模型。这里有几个调参细节值得记住学习率一定要小通常1e-5到5e-5之间预训练模型微调时学习率大了非常容易灾难性遗忘batch size受显存限制但注意batch太小梯度噪声大我一般从16起步epoch别贪多两到三个就够多了就过拟合。还有最重要的每次实验的随机种子固定住否则你没法判断效果差异是模型改动的功劳还是运气波动。3.3 评估环节别让准确率骗了你评估这块我栽过跟头。第一次调完模型准确率看起来挺漂亮我差点就直接上线了。后来习惯性做了个混淆矩阵才发现投诉这个最重要的类别的召回率只有不到五成——用户真的来投诉系统给他分到了产品咨询这在客服场景里是灾难级的体验。所以对于分类问题我现在的标准动作是先看混淆矩阵再算每个类的精确率、召回率和F1最后做错误分析——把验证集里预测错的样本全部打印出来一条一条看。这个过程会逼你发现很多卧底信号某某类别的样本里有相当一部分其实是标注错了某某类别和某某类别在真实语境下确实难分某类样本数量太少模型学不到有效特征。错误分析做完下一步优化方向自然就清楚了根本不用瞎猜。我还会给评估环节加一个业务视角的过滤离线指标再好看也要回到业务场景里判断这个错误能不能接受。客服系统的投诉漏召回和新闻推荐的点击率预估偏差0.5%后者无所谓前者会引发客诉。AI工程师一定要能跟业务方对齐什么程度的错误不可接受而不是沉迷于把F1从0.91调到0.92。4. 部署上线模型跑起来只是开始稳住才是本事模型在笔记本上跑通跟线上稳定服务几百万请求中间隔着一整个工程世界。这一节聊几个我从实战中总结的高频问题点。4.1 推理服务的性能延迟和吞吐怎么平衡模型上线第一关是把它封装成服务。我通常用FastAPI简洁且生态好但关键是处理模型加载这个细节。模型文件动辄几百MB到几个GB如果每个请求都重新加载一次服务直接瘫痪。常规做法是进程启动时加载一次放全局变量里推理接口只做forward。这个道理很多新手不懂或者懂了但代码组织得不对导致并发一上来就大量超时。再往上走就要考虑批处理。GPU推理的最优吞吐往往不在batch size为1的时候把请求攒起来一起推理单位时间能处理的请求数可能涨好几倍。但批处理会引入额外延迟实际工程里要在攒多久和多延迟之间做取舍。更进一步的技术是量化把模型从FP16压到INT8推理速度能提升一到两倍显存占用大幅下降而精度损失通常可控。我的经验顺序是先做批处理再考虑量化别一上来就上最重的优化方案。这里有个跟成本直接相关的经验现在很多大模型服务按token计费你以为只是简单的调用但请求里的历史对话、系统提示词、检索回来的参考文档都可能让上下文长度膨胀到几万token。我在一个实际项目里发现光优化提示词和上下文裁剪就把单次请求成本降了40%。AI工程师不能只管效果不管账单成本意识是必须刻进骨子里的。4.2 监控与反馈模型会悄悄变坏模型上线只是中场真正的硬仗是持续维护。为什么因为数据分布不是静态的。客服话术半年就会变一轮商品描述一改版向量检索的召回可能就出问题。所以监控体系必须上线之前就搭好不能等出事了再补。我建议至少监控四类信号。第一基础服务指标延迟、错误率、QPS这些是常规操作。第二输入分布漂移把线上输入的特征分布跟训练集的分布做对比如果差异变大说明用户输入变了模型效果可能正在悄悄退化。第三预测置信度如果模型输出的置信度整体走低往往意味着它遇到了训练分布外的数据。第四业务反馈闭环比如客服场景里用户的已解决/未解决标记、电商场景里推荐位的点击率这些真实的业务结果才是最终裁判。我把这套东西叫模型健康度仪表盘。上线初期每周看一次稳定后每月看一次每次例行巡检都留记录。有了这些历史数据下次模型效果突然下滑的时候你才有依据判断是数据问题、代码问题还是外部环境变化而不是对着虚空猜原因。5. 我踩过的坑和几条反直觉的经验最后聊几条我从这些项目里沉淀出来的、跟直觉相反但极其重要的经验。5.1 数据质量的收益永远大于模型结构的收益这几乎是AI工程的第一定律但几乎每个人都要自己撞一次南墙才肯信。我有一次做文本匹配任务先花三天清洗和增强数据同样的模型F1涨了8个点后来换更强的模型结构折腾一周只涨了1.5个点。这种对比我经历过太多次了现在已经形成肌肉记忆模型效果不行第一反应永远是回去看数据而不是换更花哨的模型。数据里藏着模型永远学不会的东西垃圾数据配再好的模型也是白搭。5.2 越是新手越容易一上来就上复杂方案这几乎是所有AI项目失败的同款剧本需求还没完全理解就开始搭微服务架构选了最潮的向量数据库接了好几个大模型最后发现根本的问题只是历史工单里类别定义本来就有歧义。我现在的原则特别朴素先跑通最简单的端到端流程验证整个链路价值成立再逐步加复杂度。简单方案的优势不只是快更在于它足够透明——出问题你能一眼看穿。复杂方案的bug藏得深排查成本是指数级上升的。5.3 版本管理的不只是代码AI项目的可复现性要求比传统软件高一个量级。传统项目里代码版本锁定了行为基本就锁定了。AI项目不行——同样的代码配不同的数据、不同的模型版本、不同的随机种子结果可能完全不同。所以我的项目目录里除了代码库必然有数据版本、模型版本和实验记录三样东西。数据用专门的版本管理工具模型文件按训练时间和指标命名归档每次实验的配置、参数、指标全部记录在实验跟踪表里。这套习惯一开始觉得麻烦但当你需要回溯三个月前那个F1 0.93的实验到底是怎么跑出来的你就知道它值多少钱了。做AI工程这两年最大的感触是这行的知识迭代速度确实快工具换了一茬又一茬但底层的工程思维没变过先定义清楚问题再找到衡量它的方法然后用最简路径去解决最后持续监控它别悄悄跑偏。把这条主线想明白了后面再多的新框架、新模型对你来说都是往这套方法论里填充的新工具而已。最后再分享一个小习惯我会每隔一段时间挑一个自己以为已经掌握的概念从头写一篇笔记讲给别人听。写不出来的地方就是理解还有窟窿的地方。AI工程的知识体系太庞杂靠看过是记不住的只有能输出、能复现、能给别人讲明白才真正变成你自己的东西。