1. 先别急着学框架AI工程到底是什么这两年AI工程这个词被提得越来越频繁但很多人一开始都搞混了一个概念——把AI工程当成用Python调模型。我自己带过不少从算法转工程、从后端转AI的同事也见过很多被AI工程师这个岗位名吸引进来的新人大家最常见的误区就是先学PyTorch还是先学LangChain再不然就是从TensorFlow一路刷到Transformers结果刷到第三周连一个能跑通的项目都没落地。我想先说清楚一个容易被忽视的起点性问题AI工程不是算法研究也不是传统软件开发它更像是一套把AI系统从实验品变成生产工具的工程方法论。AI研究关心的是这个模型在评测集上能不能涨点AI工程关心的是这个模型在真实流量里能不能稳定赚钱或省成本。同样一个文本分类任务研究员需要调的是模型结构、损失函数、训练策略工程师需要想的却是数据管道怎么稳定产出、评估口径怎么对齐业务、模型出错了怎么兜底、流量上来之后怎么扩容。两者有一小段重叠区但越往后走分叉越大。还有一个维度是AI工程与传统软件工程的差别。传统软件工程里需求基本是确定的用户点按钮、系统写数据库、外部调接口行为是可预期的只要你按逻辑写对了它就是对的。AI系统不一样模型本身是概率性的同一个输入今天可能给A结果、明天可能给B结果数据一变行为就飘。所以AI工程的很多精力花在怎么让一个本质上不确定的系统在业务层面表现得足够确定上——这就要用到数据版本管理、模型评估体系、灰度发布、监控告警这些配套能力。说回标题ai-engineering-from-scratch。我的理解是它想表达的并不是从零学会所有深度学习理论而是从一个什么系统都没有的状态一步步搭出一套能开发、评估、部署、迭代AI应用的完整工程链路。这篇文章我就按这条主线来写从需求拆解和数据策略开始到评估体系搭建、模型训练再到部署上线的完整路径以及上线之后怎么持续迭代。整个过程我会尽量给出可复用的框架、表格和踩坑记录这样无论你是刚入门的新人还是已经被项目折磨过的工程师都能在里面找到对应自己阶段的那部分内容。关于从零开始还有一个经验想先分享新手最容易犯的毛病是铺太开今天看看向量数据库明天试试微调框架后天又研究推理优化一个月下来每个方向都只摸到皮毛。正确的做法是先按数据—评估—训练—部署—监控这条链路完整走通一个小项目哪怕这个项目很小。有了端到端的体感之后再纵深去补每一个环节的理论和工具你才会知道自己缺的到底是哪一块。2. 需求拆解与数据策略AI项目里最隐性的成本中心很多AI项目死得悄无声息不是因为模型太差而是从一开始就把问题定义错了。AI工程的第一道工序不是选模型而是把业务需求翻译成算法能优化的目标。这一步做不好后面所有环节都是白费力气。2.1 从业务目标到模型目标的翻译逻辑业务方说我们想要一个智能客服减少人工介入率这个需求直接抛给算法工程师十有八九会做出一个客户不买账的东西。因为智能客服太宽泛了你需要追问是指自动回答常见问题还是指辅助人工推荐话术还是指识别用户情绪并转接不同的答案对应的技术选型完全不同。我习惯用一个目标翻译四步法来处理这类需求列出业务可量化的关键指标。减少人工介入率、提升首响速度、缩短平均处理时长、提高满意度——先让业务方把这些指标按优先级排出来。明确模型输出的使用方式。模型结果是被系统直接采用还是辅助人工决策如果是直接采用那么错误容忍度极低如果只是辅助评估标准就可以放宽。定义正确的具体标准。以客服为例两套标注员对同一句话的理解不一致怎么办需要先制定打标规范明确边界案例。把业务目标翻译成模型训练目标。比如减少人工介入率对应的可能是意图识别准确率置信度阈值的组合也可能是相似问法匹配的召回率。这里有个常见误区以为业务指标可以直接作为模型训练目标。实际上业务指标通常是多个模型决策叠加的结果直接建模往往很难优化还是需要拆解到具体的分类或排序目标上。比如用户留存提升5%这个目标可能需要拆成推荐点击率、Push打开率、落地页转化率三个子目标分别建模再联动。2.2 冷启动阶段没有数据怎么办从零开始的项目大概率面临一个冷启动问题没有标注数据甚至没有原始日志。这时候最常见的错误是等数据攒够了再动工或者直接拿别人的开源数据集硬凑。我的建议是两条路并行第一先搭一套规则基线。规则系统虽然蠢但它有两个作用一是立刻给业务提供一个可用的兜底方案让流程先跑起来二是通过规则系统的失败案例快速积累真实样本。比如做一个工单自动分类系统第一版先拿关键词规则顶上如果有人工复核环节复核记录就是天然的标注数据。这个思路很多团队都验证过初始规则越笨越好因为它产生的错误才是后续训练数据里最有价值的部分。第二用人工标注小样本启动再通过主动学习扩充。常见的启动规模是每类500—1000条覆盖主要场景。我的经验是启动样本一定要人工精标不要用弱监督批量打标否则后面模型怎么调都带着系统性偏差。数据层面的工程投入必须比模型层的投入更早开始。我见过太多团队把数据管道写成一次性脚本跑完就扔结果每次模型迭代都要重新洗数据、重新对齐格式。正确的做法是把数据管道当产品做清洗规则要配置化版本要可追溯每个字段的来源和加工逻辑要有文档。看起来浪费时间实际上一次规范化能省下后面十次迭代的时间。2.3 数据清洗和标注规范的隐形坑数据清洗听起来不像技术活但大多数AI项目效果差根源都在这一环。我整理过一份高频问题清单问题类型典型表现后果标签噪声标注员理解不一致、边界案例随意标模型学习到错误规律评估指标虚高但线上效果差样本偏差训练数据里A类占80%B类占5%模型对B类完全失明线上出现B类时乱猜重复/近重复样本同一个问题被不同用户问了很多遍原始日志里大量重复训练集被冗余样本稀释指标失真时效性差异用三个月前的数据训练线上语义已经漂移新词、新说法全部识别不了字段缺失关键上下文字段缺失模型被迫在残缺信息上做判断表现波动大同一句话换个说法就崩标注规范这块我的经验是至少需要三个人参与制定业务方定义什么是对的算法工程师定义模型需要什么标注管理员定义标注员能不能一致执行。三方各出一版意见合并形成《标注手册》手册里除了正常规则一定要写清楚边界案例怎么处理。没有边界案例的标注手册等于没有手册。启动阶段还有一个常被忽略的成本标注外包的验收机制。我习惯每次抽检10%—15%的标注结果算标注员之间的一致性低于阈值的批次直接退回重标。这个动作看似增加管理成本但能防止整个数据集因为标注质量问题而作废。3. 评估体系先回答怎么算好再回答怎么做好绝大多数AI项目在评估这个问题上栽过跟头。一个很常见的现象是模型在开发集的准确率已经98%了业务方一用就抱怨这什么玩意儿——因为开发集和真实场景根本不是一回事。3.1 为什么评估要先于模型训练做设计我在前面提到的链路顺序里刻意把评估体系放在了模型训练之前。原因很简单如果没有明确的评估标准训练过程就没有方向你根本不知道一次参数调整是变好了还是变坏了。评估体系的设计需要包含三部分离线评估集模拟真实分布的样本集用于快速迭代。线上评估机制通过小流量或灰度方式观察模型在真实业务中的表现。人工评估流程针对AIGC这类难以自动判别的任务保留人类审核环节。对于从零搭建的团队我建议评估集的建设优先级高于模型训练本身。最少要预留项目周期的三分之一时间来做评估数据准备——这个比例在初听时很反直觉但实际执行下来几乎没有团队后悔过。评估集的建设要注意时间切分不要随机抽样划分训练集和测试集而是按时间切分用前一段时间的数据训练、后一段时间的数据评估。因为真实业务场景中用户行为、语言习惯都在随时间变化随机切分会让模型偷看未来信息评估结果虚高。3.2 单一指标陷阱与切片评估新手最爱问的问题是准确率到多少算合格。我的回答是先别管准确率看切片。同一批数据整体准确率90%可能掩盖了如下事实A类场景的准确率是98%B类场景只有60%C类场景的样本太少根本没统计意义。这在真实场景中就是灾难——业务方只记住B类场景的失败案例不会管你整体准确率多高。我习惯建立一个切片评估框架切片维度示例价值业务类目工单类型、商品品类、渠道来源发现弱势类目文本长度/复杂度短文本、长文本、多轮对话发现模型能力边界用户群体新用户/老用户、会员/非会员对齐产品策略时间维度工作日/周末、白天/夜间发现数据分布变化表格只是示例每个项目要根据自己的业务设计切片维度。但原则不变评估必须下钻到用户可感知的维度而不是停留在一个整体数字上。除了切片评估还有一类常见的指标幻觉是使用不当的评估口径。比如分类不平衡的场景用准确率评估基本等于没评估。这种场景应该看精确率、召回率、F1的组合尤其是针对少数类别的召回率。二分类问题里把阈值从0.5调到0.3精确率和召回率的变化往往是反方向的——这个调参过程本身就需要评估体系配合否则就是盲人摸象。3.3 离线指标与真实体验之间的鸿沟评估体系最难的还不是指标设计而是离线指标和真实体验不对齐。尤其在AIGC这类开放式生成任务里BLEU分数高不代表内容好ROUGE相似度高不代表回答让用户满意。这时候就需要引入人在回路的评估方式。我做内容生成类项目时会专门设计一个人工评估打分表从准确性、相关性、流畅度、安全性四个维度打分每个维度分1—5档。虽然比自动评估慢但它提供的信号是自动指标给不了的。实际操作中可以把人工评估抽样的频率定为每次模型迭代后抽样100条由两个评估员交叉打分遇到分歧超过2分的案例进行人工仲裁。这里有一个不得不提的教训评估人选的多样性。如果人工评估员全部来自算法团队内部评估结果会有明显的自嗨倾向——工程师知道模型哪些输出是好的潜意识里会忽略真实用户更在意的方面。最佳实践是让产品、运营、客服等角色参与抽样评估最好再引入真实用户的反馈信号。4. 模型训练与调优的系统化方法不要做调参赌徒当我看到一个人窝在终端里反复改learning rate、换模型结构、调整batch size却拿不出一套训练实验记录表的时候我就知道这个项目离失控不远了。模型训练阶段最大的效率杀手不是算力不够而是实验管理混乱。4.1 先建基线再谈优化任何新任务的第一个实验目标都不是效果好而是流程通。我通常会把基线模型设置得非常简单用通用预训练模型直接做zero-shot或few-shot推理不微调、不优化跑通完整流程记录推理速度和初步效果。这个基线的价值有三个验证数据管道的正确性——模型能跑起来说明数据格式、加载逻辑、推理代码没有大问题。提供一个对照锚点——后续所有优化都跟基线比而不是凭感觉说好像变好了。让业务方尽早看到可用版本——哪怕效果一般也能收集反馈避免等三个月后拿出来一个方向错误的东西。有些新手会觉得基线性能这么差跑它有什么意义。恰恰相反基线会把数据问题和模型问题分开。如果基线在某个切片上表现奇差你可以确定是数据覆盖不够而不是模型结构不够先进——这能避免你在错误方向上浪费几周时间。4.2 加数据不如改数据微调中的真实杠杆现在到了很多文章里最喜欢讲的微调环节。市面上的教程十有八九在教你怎么写训练脚本、怎么调超参数但很少讲一个残酷的事实对于大多数业务场景微调效果的上限由数据集质量决定而不是由训练技巧决定。我在多个项目里验证过一个规律清洗后的干净数据比脏数据用两倍的量效果更好。这个规律说起来平平无奇执行起来却极其考验团队定力——因为清洗数据这三个字意味着要把原始样本逐条过一遍去掉标签错的、语义含糊的、上下文残缺的样本。微调阶段另一个常被忽视的杠杆是数据配比。当训练集由多个来源的样本混合而成时各来源的比例直接决定模型的行为偏向。比如指令微调时如果通用对话数据占比过高模型会变得废话连篇如果业务数据占比过高模型会过拟合到说话都带模板味。我一般会把业务数据为主、通用数据做正则化辅助具体比例要看任务场景试出来但实验记录里一定要写清楚每一版的数据配比。超参数这块我的建议是不要盲目网格搜索。先把最影响结果的几个参数固定下来学习率通常用1e-5到3e-5的区间、batch size尽量大小batch稳定性差、训练轮数从小开始观察验证集曲线。每改一个参数只保留一份实验记录表记录模型版本、数据集版本、参数配置、评估结果。训练实验不是科学研究但至少要做成可追踪的工程活动。4.3 过拟合与欠拟合的判断和处理从零开始的项目里很多人第一版模型上来就过拟合——训练集loss蹭蹭往下掉评估集指标纹丝不动。这时候不要急着加正则化先复盘数据是不是训练集里重复样本太多是不是某个类别的样本太少导致模型死记硬背我整理了一个简单的排查表现象优先排查方向常规应对手段训练loss下降但评估指标不动数据泄漏/标签噪声/评估集分布差异清洗评估集、检查数据切分逻辑训练和评估指标同步差模型容量不够或特征表达不足换更大模型、增加训练数据某类样本表现骤降类别不平衡/边界样本不足针对性采集数据、类目加权训练评估都好但线上崩线上数据分布与评估集不一致补充线上真实样本、建立线上监控过拟合的处理不是加dropout这种单一操作而是要回到数据和评估的闭环里去调整。工程化的思路是每次发现过拟合先确认是数据问题还是模型问题再对症下药。盲目堆正则化只会掩盖问题让模型在评估集上看起来没问题、线上依旧崩。5. 部署与服务化从模型能跑到系统能扛模型训练完了评估也通过了接下来到部署环节。这一环节看起来就是把模型文件加载起来、暴露一个API实际做起来牵扯的东西非常多而且每个细节都能在线上出幺蛾子。5.1 离线批处理与在线API的选型逻辑很多AI应用的第一版需求是给存量数据打标而不是实时响应用户请求。如果业务场景可以接受分钟级甚至小时级的延迟那么优先选离线批处理架构而不是一上来就搭在线API服务。离线批处理的好处非常明显实现简单、排查容易、算力成本可控模型性能出问题影响面也小。缺点是没有实时性。在线API适合那些真正需要实时响应的场景比如客服机器人、实时审核拦截。我的建议是能离线就别在线先让业务跑起来等明确存在实时需求了再演进。如果确实需要在线API那部署层面就要考虑几件事模型服务的容灾和水平扩展单机部署挂了怎么办流量翻倍了能不能扛住推理性能优化首延迟多少算可接受要不要上量化、剪枝、蒸馏请求日志记录线上请求和推理结果一定要全量落日志这是后续分析和数据回流的基础。性能优化我多说一句不要为了优化而优化。先压测看业务瓶颈在哪——是模型推理慢还是前后处理慢还是网络延迟拖后腿。很多项目模型本身只占几十毫秒前后处理和数据传输反而占了几百毫秒。你费劲做模型量化不如先优化数据序列化和缓存策略。5.2 灰度发布与回滚机制把模型部署上线跟发版一样不应该直接全量切换。这里的关键是灰度——先让一小部分流量走新模型观察效果再逐步扩大。灰度发布的具体操作因基础设施而异但核心思路是用流量切分来控制风险。比如先放5%的流量给新模型跑一天对比新老模型的关键业务指标。如果新模型明显更差立即切回来如果差异不大或更好再逐步扩大比例。这里有个小细节容易被忽略灰度期间的评估指标不能只看模型的离线指标要看业务指标和用户反馈。有些模型离线分数高线上用户就是不买账有些模型离线分数略低但用户投诉少了。只有灰度数据能告诉你真相。回滚机制的设计要提前做好保留上一版模型的加载路径、配置信息和推理代码确保在检测到异常时一键切回旧版本。很多团队在灰度前不准备回滚方案真出问题时只能紧急改代码重新部署——这个操作在线上环境里每多一秒都是风险。5.3 一个稳定的推理服务里有哪些隐藏组件推理服务不只是加载模型、接收请求、返回结果这么简单。我拆一个典型的在线推理服务里面通常包含以下组件请求预处理文本清洗、格式规范化、长度截断。模型推理核心推断逻辑。结果后处理概率转标签、置信度过滤、兜底规则匹配。缓存层高频问同样问题的时候不重复跑模型。降级开关模型服务异常时自动切到规则兜底或返回预设文案。监控探针记录延迟、QPS、错题率、资源使用率。这些组件里我特别想强调兜底逻辑。在AI系统里模型一定会出错关键是出错之后有没有一个体面的退路。比如意图识别置信度低于0.6时不强行猜测而是回复我没太明白您可以换个说法比如生成式问答模型超时不返回空字符串而是返回人工坐席的转接提示。这些兜底逻辑能显著改善用户体感也能降低线上事故的严重程度。监控这块至少要有三个层面的指标系统层CPU、内存、GPU利用率、服务层请求量、延迟分布、错误率、业务层结果分布、阈值命中率、兜底触发率。业务层监控最容易被忽略但它恰恰最有用——万一哪天数据分布漂移了业务层指标会最先发出警告而不是等到用户投诉了才发现。6. 上线之后自适应优化才是AI系统的分水岭模型上线不是终点而是真正的起点。这是AI工程和传统研发发版之间最大的区别传统系统发完版只要不出bug就算完事了AI系统上线之后要面对的是一个会变化的真实环境。6.1 数据漂移监控与模型季度性退化所谓数据漂移指的是线上输入数据的分布和训练时用的数据分布发生了偏离。用户会造新词、业务方会改话术、季节变化会改变需求这些都会让模型效果随时间衰减。我在实践中观察到很多模型在上线后的1-3个月内表现尚可3个月后就开始出现明显退化。退化最早期的信号往往不是整体指标下降而是某个切片表现异常——比如某个新出的产品品类模型识别准确率直线往下掉。应对数据漂移不能靠重新训练一次解决而是要建立持续的监控和迭代机制定时统计线上请求的分布特征和训练集分布做对比。设定漂移阈值触发告警后启动数据采集和重训流程。积累线上高价值样本——尤其是模型出错但被用户或人工纠正过的样本。周期性比如每月或每季重训模型而不是等到效果崩了再救。这些机制里积累线上高价值样本是最核心的。我几乎在所有项目里都强调模型上线后人工修正的每一处错误都是金钱买不到的训练信号。把这些信号回流到训练集模型才会越用越聪明。6.2 大模型落地中的评估运维难题如果项目用的是大模型无论是API调用还是自建模型服务运维和评估的难度会再上一个台阶。首先是成本控制。大模型按token计费的时候一次不设上限的生成任务可以烧掉惊人的钱。我习惯在工程层面对token使用量做预算管理设置单次请求最大token数、每日总限额超限自动降级到小模型或规则方案。其次是生成内容的一致性。同一个问题换两天问答案可能完全不同这在专业场景里经常导致用户困惑。一致性问题的工程对策包括设置温度参数为较低值、引入固定模板的引导词、对敏感或关键问题强制走规则通道。还有一个很隐蔽的问题是大模型的错误比小模型更难以发现。小模型出错通常是分类分错、识别失败肉眼一看就知道不对大模型生成的内容看起来流畅完整但可能暗含事实错误或逻辑矛盾。这类问题的评估需要更精细的人工核查机制必要时配合事实校验工具做交叉验证。6.3 人机协同与反馈闭环的落地经验最后聊一聊人机协同。很多AI项目不是要完全替代人工而是让人工做得更轻松。这种情况下系统设计从一开始就要考虑人和AI分别负责什么、边界在哪里。我常用的协作模式是AI先行人工兜底AI处理常见、标准化、低风险的任务把不确定性高的案例交给人工。具体到系统设计上置信度阈值就是人机分工的决策边界。阈值定得太高AI能处理的量太少人工压力大阈值定得太低AI犯的错太多人工擦屁股更累。这个阈值需要根据人工处理成本、AI错误成本、业务风险承受力来动态调整。反馈闭环这块我的经验是反馈越轻越好。让用户或员工明确评价一条AI输出是否正确操作成本很高执行率会很差。反过来把反馈动作嵌入正常业务流里——比如人工坐席处理完一条工单顺带修正了AI的意图标签——这种无感反馈的执行率能达到90%以上。闭环跑通之后系统就进入了自我进化的状态线上数据产生信号信号回流变成训练样本重训模型灰度上线继续积累新信号。这个循环周期一开始可能是几周跑顺了之后可以压缩到几天。能把这条循环跑通才算是真正从零搭建起了一个AI工程体系而不是仅仅训练了一个模型。7. 写在最后的工程心法按惯例最后分享几点我这些年反复吃到红利的心法。第一AI工程里90%的价值在数据和评估上模型的先进程度只占一小部分。很多团队在模型结构上卷生卷死不如先把数据管道做稳、评估体系做实。在绝大多数业务场景用前沿模型加GoodOld数据清理方案效果远超盲目追新。第二要接受AI系统的不确定性和不完美。传统研发追求零bugAI工程追求可接受的错误率可控的兜底方案。把系统做诚实一点——知道自己哪里不行给用户一条体面的退路比假装自己什么都行更容易获得信任。第三从零开始不是把所有理论学完再动手而是先跑通第一个极小的闭环再逐步加厚每一层。第一个项目可以只是一个规则基线加一个分类模型但一定要把数据、评估、训练、部署、监控这条链路完整走一遍。走完之后你对AI工程这四个字的理解会超过读十本教材。最后再分享一个小技巧养成写实验记录和踩坑笔记的习惯不用很长每次两三行就行。半年之后回头看这些笔记里藏着你最值钱的工程经验。路子就是这么个路子剩下的就是去你的项目里动手了。