最近这一两年ai-engineering这个热度一直没降过。但说实话很多人对这个词的理解还是停留在“调一个现成模型跑通 demo”的阶段。标题里“from scratch”这几个字特别关键它意味着不是套模板、不是拼积木而是把一套完整的东西从头搭起来。我自己在过去几个月里就是以这种“从零开始”的方式把一个 AI 项目真正落地到了生产环境期间踩过的坑、走过的弯路比过去几年加起来都多。这篇博文没有高大上的理论堆砌全是这套系统从需求分析到最后跑稳定下来的实际过程包括架构怎么搭、模型怎么选、数据怎么管、上线之后怎么观测。如果你也在负责一个 AI 项目从零到落地的全过程或者正准备把一个实验性质的模型推向生产那这篇文章应该能帮你省下不少时间。1. 为什么“从零搭建”和“跑通Demo”完全是两回事先说个很现实的问题很多人觉得既然模型框架这么成熟预训练模型随手就能下那 AI 工程化不就是写几个脚本、调一下参数的事如果你只是做个演示给领导看确实是这样。但一旦进入生产环境事情就彻底变了。我这次从零搭建的是一套视觉检测系统核心任务是实时识别特定场景中的异常目标。最开始的两周我就在本地用 Python 加开源模型库很快就把准确率调到了不错的水平demo 跑起来很顺。但到了要部署的时候问题一个接一个冒出来模型推理速度达不到实时要求、GPU 显存不够跑多路视频流、训练数据和应用场景的数据分布不一致、模型更新之后旧版本的回退策略没设计……这些没有任何一个是你调参能解决的。它们属于工程问题而工程问题恰恰是“从零开始”最耗费精力、也最锻炼人的地方。我的核心体会有三点。第一AI 工程化是一条完整的技术链路模型训练只是其中一环数据管道、模型部署、服务监测、版本管理每一环都会成为瓶颈。第二生产环境对“稳定”的要求远超“效果”你可以接受模型偶尔误报但绝不能接受服务频繁崩溃。第三在很多团队里AI 工程师不仅要懂模型还要懂系统设计、懂运维逻辑、懂如何把一个研究原型变成可靠产品。2. 迷雾检测系统的架构选型从需求拆解到技术落地这套视觉检测系统我内部叫它“迷雾检测”因为它的核心任务是持续分析摄像头画面在画面中检测出一些模糊、被遮挡或低置信度的目标并给出预警。名字听起来简单但需求拆解之后一点也不轻松。2.1 原始需求里的隐藏约束用户最初的需求是“检测画面中的异常物体出现时及时告警。”听起来很直接但实际拆解时我发现了几个需要特别处理的隐藏约束实时性要求很高。现场摄像头有 8 路全部并行分析单次推理的端到端延迟必须控制在 300 毫秒以内否则告警就失去意义。最初我用开源目标检测模型做推理单帧就要 200 多毫秒再算上图像预处理和结果后处理直接超了。误报率要低同时召回率要高。这两个指标天然矛盾尤其检测目标是“低可见度”物体时模型很容易漏掉或者报错。后来我只能按场景设计置信度双阈值高置信度直接告警低置信度推送到人工确认队列。GPU 资源有限。不能为了效率无限堆显卡要在有限资源下跑更多路视频这就逼着我去做推理管线优化。2.2 推理引擎选型对比模型框架定了之后推理引擎的选择是第一个大决策。我分别测了三种方案结果整理如下方案延迟单帧GPU 显存占用开发难度结论原生 PyTorch 推理215 ms2.8 GB低不适合作为生产方案ONNX Runtime GPU130 ms1.6 GB低可以作为初步方案TensorRT FP1658 ms900 MB中最终采用我最终选了 TensorRT FP16原因是它能同时解决延迟和显存两个核心矛盾。转换过程比较折腾需要对模型结构做一些调整而且 TensorRT 的算子兼容性并不完美不是所有层都能直接转换。但收益非常明显推理速度快了接近 4 倍显存占用砍到了原来的三分之一。注意如果你也要用 TensorRT 部署 PyTorch 模型建议优先检查模型里有没有动态 shape 的算子比如动态 Resize这类算子在转换时需要固定 shape操作不当会导致推理结果不对。2.3 图像管道设计模型推理只是整个系统的一部分图像怎么从摄像头到模型中间经过多少次压缩、缩放、格式转换每一步都会影响最终效果。我设计了这样一个管道摄像头推流 - RTSP 拉流 - 视频解码 - 抽帧 - 缩放/归一化 - 模型推理 - 后处理 - 结果推送每一步都有讲究。RTSP 拉流我选用了 FFmpeg 的 Python 绑定但发现它的默认解码缓冲会引入大约 400 毫秒的额外延迟这个必须调小。抽帧策略上我一开始做的是每帧分析后来发现对于静止场景变化不大改成“运动检测触发 定时检测兜底”的双重策略CPU 和 GPU 压力都小了很多。缩放这步也踩过坑直接用 Pillow 缩放的图像色彩空间和模型训练时不一致导致检测效果下降后来统一用 OpenCV 做 BGR 到 RGB 转换加线性缩放问题才解决。图像管道的完整数据流是这样的摄像头以 RTSP 协议推流系统用 FFmpeg 以低延迟模式拉取视频流并解码为原始帧接着抽帧模块会根据运动检测结果决定是否送入预处理模块预处理模块完成缩放和归一化后把张量送到 TensorRT 推理引擎推理结果经后处理模块过滤和格式化最终通过回调接口推送给告警服务。这个流程看起来长但每一步都必须是可控的否则你很难定位问题到底出在哪一环。3. 数据、模型与迭代增量学习在未登录样本上的挣扎说完了架构讲讲数据和模型迭代。这是我觉得整个项目里最有深度、也最折磨人的部分。因为你要面对的不只是一开始标注数据集里有的那些目标还有随着时间不断出现的“未登录样本”——也就是模型训练时从未见过的目标变体。3.1 第一个版本模型的失利我第一个版本用的是一套公开数据集训练出来的预训练模型加上一些迁移学习微调。在测试集上mAP 能到 0.78看起来不错。但一上线就露馅了现场环境的光照条件、摄像头角度和目标形态和公开数据集差别很大实际召回率掉到了 0.45 左右。这就是典型的“数据分布漂移”问题训练数据和应用数据不一致。很多人只关注模型结构调整和超参数优化但工程上第一优先应该是让训练数据尽量贴近真实应用场景。之后我花了两周时间从现场摄像头录制了大量视频从里面抽取了 2 万多帧做了精细标注才把问题初步稳住。3.2 增量学习框架的搭建模型上线之后新的目标变体仍然不断出现。每次都重新训练一版模型不现实成本太高。我做了一个简单的增量学习框架核心思路有两个第一建立一个未登录样本归档库。日常推理时凡是置信度落在低置信度区间的结果自动截取图像块保存下来每周由人工审核一次把其中有价值的部分标注并加入训练集。第二采用“基座模型 增量微调”的方式不是从头训练整个模型而是冻结大部分层只微调最后几层。这样每次增量训练只需要大约 20 分钟就能覆盖新样本的特征。这里有个重要的降级策略新模型训练完成后并不直接替换线上模型而是先在灰度环境跑一段时间用小流量对比新旧模型的准确率和召回率确认没有明显回退才正式切换。这样做的好处是即使增量训练引入了某些负面影响线上服务也不会受到冲击。3.3 样本质量比样本数量更重要我在增量学习过程中最深的感受是样本质量远重要于样本数量。刚开始我恨不得把所有置信度低的结果全部丢进训练集结果模型越训越糊涂误报率暴涨。后来发现归档库里大量样本是模糊帧、运动拖影帧这类无效数据它们不但不会让模型变好反而会让特征提取混乱。后来我加入了一个“质量过滤”步骤只保留连续 3 帧以上稳定出现的目标图像块模糊度过高的直接丢弃效果立刻改善。4. 服务质量观测切模型延迟、置信度分档和图像质量过滤模型训练好了系统跑起来了不代表工作结束了。AI 工程化里我始终坚持一个观点可观测性就是生命线。系统上线之后你必须清楚地知道它任何一个时刻的表现如何、瓶颈在哪里、有没有劣化趋势。4.1 关键指标的设计我设计的观测指标体系分为三层模型层指标单次推理延迟、GPU 利用率、显存占用、每秒处理的帧数。这一层直接反映推理引擎的效率和资源消耗。服务层指标API 响应时间、告警推送成功率、视频流断流次数。这一层反映整个服务的稳定性和可用性。业务层指标误报率、召回率、置信度分布、未登录样本归档数量。这一层反映模型的实际效果和长期演进状态。4.2 延迟分解与坑点记录有一次模型层指标显示推理延迟突然从 58 毫秒涨到 160 毫秒但 GPU 利用率并不高我一开始怀疑是代码逻辑问题排查了很久。后来才发现是同一台服务器上另一个日志进程占用了大量 CPU导致图像预处理成了瓶颈模型反而在空转等待输入数据。这种问题靠看模型层指标根本发现不了必须把整条图像管道的每一步单独计时形成一条延迟火焰链。各环节延迟分布拉流解码26 ms抽帧 运动检测12 ms预处理缩放/归一化18 msTensorRT 推理58 ms后处理 结果推送9 ms从那以后我把整条链路上的每一步都加了耗时统计任何一环超过预设阈值都能立刻定位到根因。4.3 置信度分档和图像质量过滤的联动置信度分档是我认为最实用的工程决策之一。我没有用一个硬性阈值而是把结果分成三档高置信度0.85直接告警中置信度0.6 到 0.85进入待确认队列由人工审核低置信度0.6默认丢弃但图像块会进入未登录样本归档库。这套设计解决了两个问题一是高置信度和低置信度之间的灰色地带不再因为一个死阈值而错杀或漏报二是它为增量学习提供了稳定的数据来源——中低置信度恰好是模型“不太确定”的区域也是最有增量学习价值的样本来源。图像质量过滤是置信度分档的前置步骤。即在分档之前先对输入的图像块做一次质量评估清晰度不足的直接丢弃不进入任何后续环节。质量过滤和置信度分档是串联协同的质量过滤剔除的是“模型无论怎么改进都识别不出来”的噪声样本置信度分档处理的是“模型当前能力边界附近”的可学习样本。两者一结合归档库的数据质量有了保障后续增量训练的效果也稳定了。5. 工具链与协作机制一个人也必须有流程从零搭建一个 AI 工程项目很多人会觉得那就是写代码、跑模型的事。但真正做起来之后你会发现如果不在工具链和协作机制上提前投入很快就会被自己搞乱。5.1 模型注册与数据版本管理模型文件和数据集如果没有版本管理绝对是一场灾难。我第一次切模型后就发现旧模型的权重文件被新文件覆盖了想回退的时候已经找不到原始版本只能重新训练浪费了两天时间。后来我搭了一套简单的模型注册机制每个模型版本记录清楚训练日期、训练数据版本、模型指标、推理引擎版本、上线状态。数据集同理。每次增量训练之前对训练集打一个版本标签记录新增样本来源和时间段同时保留一个训练集与验证集的映射。这样任何时候回溯都能准确知道当前模型是用哪些数据、哪个时间的数据训练出来的排查问题会方便很多。5.2 持续集成管线的搭建传统软件开发有 CI/CDAI 工程同样应该有自己的流水线。我不需要那种特别庞大的平台就用 GitLab CI 结合自动化脚本搭了一套简单的流程代码提交 - 自动化测试 - 模型推理性能基准 - 构建部署包 - 灰度发布自动化测试包括单元测试和模型效果断言每次代码更新用一小批固定的验证集跑一次推理确认 mAP 和延迟没有回退。这等于给 AI 工程套上了一道安全网防止改动代码时不小心破坏了已有功能。灰度发布我之前提到过不再赘述。这套流程在项目里基本是一个人维护但有了它我的“一个人”也能像一个小团队一样有序运转。6. 一些体会整个项目做下来我最想强调一点AI 工程化比拼的从来不是谁跑出了一个更漂亮的准确率而是谁的整套系统能在真实环境里稳定、高效、可持续地运行。模型效果只是这个系统的一部分它依赖数据质量的支撑依赖推理引擎的效率依赖观测体系提供的反馈依赖版本管理和流程规范兜底。如果你正在负责类似的项目我的建议是先花时间想清楚整条链路而不是急着去调那个模型。工程上的问题晚一步面对就要多花好几步的成本去解决。