“AI工程”这个词这两年被炒得火热但说实话真正动手把一个AI项目从零开始推向生产环境和跑通一个Notebook完全是两码事。我最近完整走了一遍一个叫“ai-engineering-from-scratch”的个人项目从数据收集、模型选型到服务上线全程没有套用现成的模板每一步都自己动手踩坑。这篇文章会把我的完整思路、关键决策过程和实际遇到的问题都整理出来希望能给同样在“没有现成作业可以抄”状态下硬啃AI工程的朋友一些参考。1. 内容整体设计与思路拆解1.1 核心需求解析这个项目到底要解决什么问题我给自己定的项目目标很朴素不经由任何已有的AI平台或全套封装方案从一个原始需求出发用手写代码的方式独立搭建一条能够完成数据标注、模型训练、性能评估、服务部署的AI应用流水线。听起来像是重复造轮子但做工程的人都明白轮子可以复用但螺丝怎么拧、扭矩怎么定、材料怎么选这些基本功只有亲手做过才会真正内化。需求拆解下来真正核心的问题有三个数据从哪里来、怎么洗干净、标注标准怎么定这一步决定了模型的天花板。模型怎么选、训练过程怎么调优在算力有限的情况下如何在效果和成本之间找平衡。训练好的模型怎么低成本、高稳定地对外提供服务并且可以持续迭代。整个项目我限定在单机四卡的环境里不用大规模分布式训练不做自动化标注平台聚焦在核心环节的手工落地。因为从零开始做AI工程最难的不是调参本身而是对完整链路的掌控力。这种掌控力只有自己亲手把每一环节的坑都踩一遍才能真正建立起来。1.2 方案选型背后的考量为什么不用现成框架“糊”过去做这个项目期间不是没有朋友劝我直接用现成的能力和平台大家都说现在的开源生态已经很成熟了没必要花几个月时间“重新发明轮子”。我心里很清楚这句话在八成场景下是对的但这个项目的价值不在“生产流程最快的解法”而在“把黑盒打开看懂里面的结构”。选择方案的标准我归纳成三条能解决问题的核心环节但不过度引入重量级依赖。每个结构模块都能在代码层面看到具体实现而不是调接口、看文档。计算的路径尽量贴近真实生产环境避免“实验能跑、上线就挂”的脱节问题。我用PyTorch做模型训练部分这是当前工程落地最通用的选择生态完善、社区成熟而且动态图机制对调试非常友好。数据清洗和增强部分自己写了一套基于Pandas和NumPy的预处理管线没有引入额外的数据平台因为小规模数据量下标准工具链反而更灵活。模型服务部分则自己用FastAPI封装没有直接上完整的模型推理框架因为项目体量和并发要求并不需要保持简单才更容易维护。这里面最核心的一个决策是训练集、验证集、测试集的划分策略。我坚持按时间序列切分而不是随机洗牌。这个决策的代价是模型的表现会比随机划分差一些但好处是模拟了真实场景下的数据漂移情况模型在“未来”数据上的泛化能力才可以被真正检验。做AI工程最忌讳的就是训练环境评估很好、上线之后迅速掉点而按时间划分数据集可以最有效地规避这个问题。2. 工具选型与数据工程实录2.1 数据全链路搭建从原始采集到高质量训练样本数据是这个项目投入时间最多、也最耗时的一个环节。我的目标是从互联网公开渠道采集一批与指定场景相关的原始语料做清洗、去重、筛选、标注、增强之后整理出约3万条高质量训练样本。采集阶段用了一套基于Scrapy的爬虫框架。每个爬虫任务对应一个独立的数据源爬到的数据统一存储为JSON行格式。这一步有几个容易踩的坑反爬策略太弱采集到大量重复和低质量页面。下载的内容里混入了大量HTML标签、脚本代码和无意义字符。编码不统一UTF-8、GBK、Latin-1混在一起解析时容易乱码。我引入了一个清洗管线依次执行标签剥离、异常字符过滤、URL去重、段落长度过滤。清洗之后的数据干净程度大幅提升但依然不适合直接训练因为里面存在大量近重复文档这些文档如果同时出现在训练集和测试集里会造成严重的数据泄漏导致评估指标虚高。我后来用MinHash加局部敏感哈希做了一次近似去重这一步让我最终的有效样本量缩减了约18%精确去重后的数据分布更健康。清洗之后进入人工标注环节。我先定义了标注规范文档覆盖了类别定义、边界情况处理、标注优先级和争议解决规则。然后组织了三个标注小组每一条数据都经过两人独立标注不一致的样本进入仲裁环节。标注质量的控制通过周期抽样复检完成我自己会随机抽取10%的已标注数据做二次审核发现系统性偏误时立即组织标注人员重新培训。2.2 训练集、验证集、测试集的划分策略数据集划分这是AI项目中最容易被低估风险的一个环节。我最终选择了按时间顺序划分的方式把所有样本按时间排序后前70%作为训练集接下来15%作为验证集最后15%作为测试集。这样划分有一个直接后果训练集和测试集中的数据分布会出现一定差异也因为这种差异导致模型的测试指标比随机划分时低两到三个百分点。从工程角度看我非常认可这个选择。因为AI模型落地之后面对的几乎是“未来数据”而不是训练时见过的“历史数据”。按时间划分可以让离线评估结果更接近线上真实表现也为后期的模型监控定了一个更合理的基准线。如果只追求好看的测试分数用随机划分确实可以很快达到漂亮的结果但那样的模型面对真实场景时往往会迅速崩溃。划分完成后我重新统计了每部分数据的标签分布确认各类别比例大致一致然后用英文命名的方式保存为三个独立的Parquet文件文件格式上还能保留原始字段。这一步虽然不起眼但对后续训练环节的回溯和调试非常重要能让你在发现模型表现异常时快速回到数据层面找原因。2.3 数据增强与样本平衡处理原始数据的天然分布很不均衡热门类别的样本量可能是冷门类别的二十倍以上。如果不处理模型会对高频类别产生严重偏向。我没有选择最简单的欠采样或过采样方案因为前者会浪费大量数据后者容易导致过拟合。最终用到的是两套组合策略对少数类别做基于规则的数据增强同时在训练阶段引入类别加权的损失函数。规则增强具体包括同义词替换、随机插入、随机交换和回译四类操作按比例随机组合保证生成样本的多样性。代价是增强之后的样本存在一定噪声但这种噪声对模型的泛化能力反而有帮助因为真实数据里本来就存在表达多样性。加了增强之后少数类别的样本数量提升到了多数类别的40%左右比之前的5%有了本质改善。在这个基础上损失函数里的类别权重继续保护少数类别的学习信号双管齐下的方式让整体F1分数至少提升了四个百分点。3. 模型训练与核心环节实现3.1 基线模型的建立与评价体系搭建项目进入模型阶段时我没有急着上复杂结构而是先把Facebook的FastText作为基线模型训练了一版。因为从零开始做AI工程首先要验证的不是花哨的结构而是整个训练和评估管道是否通畅。FastText训练速度快、占显存极低、超参数少非常适合排查数据管线、评估指标、实验记录中隐藏的问题。基线模型在测试集上的宏平均F1分数只有0.71这个数字单独看并没有太多意义但它给了我一个明确的比较起点。此后无论用了多复杂的模型都会拿这个分数作为参照判断复杂度的提升是否真正换来效果提升。没有基线后面所有实验都会失去判断依据这是工程方法论里的基本常识却常被大量项目忽略。评估体系搭的是P/R/F1加混淆矩阵和按类别细分的指标报告。我不看单一准确率因为类别不平衡时准确率是一个极其欺骗性的指标——98%的准确率可能只是把所有样本都预测成了多数类而已。这些评估代码全部基于sklearn实现只用了少量几行代码就在评估过程中扩展了多个分析维度性价比很高。3.2 模型结构选择与训练细节调优基线验证通过后主干模型我选择了一个中文预训练语言模型作为特征抽取器后接结构简单的分类头。选择这个模型的原因首先是中文语料上的预训练效果有公开评测数据支持其次模型参数量适中单卡就能跑无需模型并行第三是HuggingFace的生态成熟后续部署在兼容性上不会突然出幺蛾子。迭代训练过程中我重点盯了三个指标训练损失、验证损失和每轮的F1。我发现当训练轮次超过四轮之后训练损失仍在持续下降但验证损失开始反弹这是典型的过拟合信号。解决方式是用早停法当验证损失连续三轮没有改善时停止训练并回滚到验证集最优的检查点。这样一改最终模型的宏平均F1从0.71提升到了0.84相比基线有了实质性的提升。微调时的关键超参数如下表所示这些数值是多次试验后的折中选择并非某个框架的默认值能直接套用超参数设定值调整说明批次大小32显存受限下的折中再大会OOM再小会训练不稳定学习率2e-5预训练模型微调常用的安全范围过高会灾难性遗忘训练轮次6配合早停实际训练在第5轮中止梯度累积步数2等效批次变大提升训练稳定性最大序列长度128覆盖90%以上样本长度保留少量截断加权策略类别加权损失少数类权重设为其频率倒数的对数训练阶段我坚持在CPU上完成数据预处理和数据加载把宝贵显存全部留给模型计算。这个策略让四张卡的显存利用率一直稳定在85%以上相比一张卡跑完的日均时间完整体验了数据并行训练的提速效果。数据并行本身不复杂核心就是把批次切分到多个设备上各自算梯度再汇总更新。我这里用的是PyTorch官方的数据并行接口整体代码改动量不大但对思维方式的转变帮助很大——模型训练不是单点计算而是一个吞吐量工程。3.3 推理优化与部署方案落地模型训练出来之后工程化的工作才完成一半剩下的是把模型高质量地部署成服务。在推理优化上我先是把模型切到半精度推理模式在几乎不损失精度的前提下把推理速度提升了1.6倍。接着用ONNX导出模型结构配合对应设备端的执行引擎继续加速最终单次推理耗时稳定在45毫秒左右相比原始PyTorch推理提升了近3倍。这个优化是纯工程链条上获得的收益与模型本身的精度没有关系。服务端我用了FastAPI封装推理接口。接收入参后先做文本标准化和编码再送进模型得到原始输出最后经后处理把索引映射回标签名。接口设计遵循规范路径一次推理请求走“参数校验、预处理、推理、后处理、返回”五个环节。并发控制这一块没有引入特别重的依赖而是通过信号量控制同时推理的请求数量防止显存暴涨导致服务崩溃。部署环境用容器打包构建镜像时区分了开发镜像和生产镜像。生产镜像里只保留模型权重文件、推理代码和运行依赖隔离了开发工具链。模型服务启动时先做一次自检确认权重加载无误、示例输入输出正常后才对外宣告健康这个习惯帮我避免过好几次“人还在睡、线上服务已经静默挂了”的凌晨事故。4. 常见问题与排查技巧实录4.1 数据集阶段最容易翻车的三个细节整个项目走下来数据阶段的问题占了总数的一半以上这一点很值得引发重视。第一个高发问题是近重复数据我最初用最简单的哈希去重法过滤了一遍自以为数据已经很干净了直到后面做测试时发现模型的表现异常优秀进一步排查才发现验证集和训练集之间还隐藏着大量近似重复这才紧急引入MinHash和局部敏感哈希填补漏洞。第二个问题出在标注一致性上。第一批标注完成后我抽查发现两名标注员对同一个类别的判定分歧率竟然有15%左右。问题不在标注员的能力而在于标注规范里对边缘案例的定义太模糊。后来修订了规范补充了十几个新的示例重新组织培训之后分歧率降到了4%以内。第三个坑是增强数据的错误引入。我在做同义词替换时发现部分替换词会导致语义反转例如“不喜欢”被替换成“不讨厌”句子意思完全变了。这类样本被错误地标为原类别反而成了训练噪音。后来我给替换操作增加了人工审阅环节并控制替换密度这类问题的发生频率才真正降下来。4.2 训练阶段的调参与排错经验训练时最常见的现象是损失值不降或者下降极慢。我遇到过一次loss卡在初始值附近不动的情况排查很久发现是学习率设置得太低加上权重初始化不够理想导致梯度更新幅度过小。把学习率调大三倍之后问题迅速缓解。这个经历告诉我遇到loss不动优先检查的不是模型结构而是梯度本身是否正常流动。另一个高发场景是显存溢出。模型训练过程中突然爆出显存不足的报错通常不是模型本身太大而是数据加载没有做显存和内存之间的均衡。我的解决策略是在数据加载阶段就把输入张量转成半精度或直接用内置接口做异步预取同时在训练循环里手动释放不再需要的中间变量。经过几轮调整显存占用曲线稳定了下来。还有一次被卡了很久的问题是推理结果跟训练预期不符。模型在训练时的评估指标很好但部署之后的首次推理结果跟预期差距很大。后来发现是推理阶段对输入文本做了和训练阶段不一样的预处理导致tokenizer产生的编码完全不同模型自然就“看不懂”了。这个教训让我养成了一个习惯训练和推理共用同一套预处理函数而不是在两端各写一份实现。4.3 服务上线前后的监控和稳定性保障服务上线前我做的最后一项工作是建立一套轻量级的监控体系。每次推理请求都会记录耗时、输入长度、返回标签和置信度定期落盘用于分析。一旦发现低置信度样本比例上升或者某个类别的输出频率发生明显变化就说明线上数据分布可能正在偏离训练分布该考虑更新模型了。日志监控方面我统一用JSON格式记录结构化日志核心字段包括时间戳、请求ID、模型版本、输入样本hash、输出类别和置信度。这样后期分析问题时可以快速按模型版本做分维度汇总定位影响范围。服务没有接入重量级的监控平台只是用一套简单脚本定时扫描近一小时日志发现异常就触发告警在项目体量下已经够用。稳定性保障里我认为最重要的经验是预留降级预案。当模型服务的响应时间超过阈值或连续报错时自动切换到规则兜底策略。先保证接口不挂、调用方能拿到结果再通过告警通知人介入。真正上线之后这套兜底确实触发过一次避免了线上服务完全不可用的尴尬局面。5. 复盘总结与扩展思考项目从启动到完成核心功能前后花了大概三个月时间。最直观的成果是完成了一条从零搭建的AI工程链路宏平均F1从基线0.71到最终0.84模型推理单次耗时从原始实现到优化后稳定在45毫秒左右。如果只评价这些数字它算不上一个能惊艳任何人的项目。但在我自己的工程成长路径上这段经历带来的价值远超过数字本身。从零开始做AI工程最大的收获不是学会了某个模型或者某个框架而是建立了完整的工程直觉。我现在拿到一个新需求脑子里会自动浮现数据从哪来、质量怎么控、模型的评价标准是什么、部署后怎么监控这条完整的链路。这种全局视角是看再多教程也得不到的只能在真实的项目压力下一步一步熬出来。关于后续扩展我认为有几个方向值得继续深挖。当前版本对线上数据漂移的感知是滞后的通过定期分析日志来人工识别漂移信号这种方式存在明显的时延。下一步想引入自动化的数据漂移检测模块对比线上输入分布与训练分布的偏差指标当偏差超过阈值时自动触发重新训练提醒。另外当前数据标注完全依赖人工成本较高且扩展性有限后续值得尝试用弱监督的方式做初步标注再交给人工校验这可能让样本准备效率大幅提升。如果让我给同样想走“从零开始”路线的同行一个建议我会说不要一上来就追新模型、新框架先把你手里的数据管明白再关心模型结构最后才是花哨的部署方案。数据质量决定了你的基线基线决定了后面所有优化的信任度。没有可靠的数据和评估体系再精妙的模型结构都是空中楼阁。这个顺序是我这个项目踩了无数坑之后真正学到的东西。