1. 从零开始先别急着写模型经常有人问我AI工程从零开始第一门课是不是该去啃Transformer我的回答是先把“活下来”这件事想清楚再谈先进模型。ai-engineering这个词最近被翻来覆去地讲但真正从零开始做落地系统的人都会告诉你同一句话最难的不是把模型训练出来而是把模型放进一个能长期运转的系统里让它有价值、可维护、能迭代。我见过太多人把“从零开始”理解成“从模型开始”。他们花三个月玩转PyTorch背熟了各种损失函数一上来就在Kaggle上刷到高分然后信心满满地说“我要做一个AI项目”。结果呢训练脚本在个人电脑上跑得飞快一到团队协作就彻底失控数据文件夹叫final_v2代码里全是魔法数字环境依赖全靠人品AI能力再强也扛不住这样的工程底座。这不是AI工程这是算法实验。AI工程和算法实验最大的区别就是你必须对“系统不崩”负责而不是只对“模型精度”负责。我这篇文章想聊的就是我这些年从零开始折腾AI工程时总结下来的一套套路先搞清楚工程和算法的边界再搭一套能复用的骨架接着老老实实把部署和监控补上最后学会和业务方对齐目标。这条路径不是为了让你炫技而是为了让你在真实环境里少撞几面墙。适合三类人刚入行的算法工程师、想转行做AI的后端工程师以及已经在项目里被各种工程问题折磨得想辞职的初学者。1.1 先把“AI工程”这顶帽子戴清楚AI工程不是说你会训练模型就够的。它涵盖的是从数据准备、特征工程、模型训练、模型评估、部署上线、监控告警到持续迭代的整条链路。简单说算法工程师解决的是“模型能不能预测”的问题AI工程师解决的是“系统能不能稳定地预测”的问题。这两者之间的差距就像做饭和开餐厅前者能让家里人吃得开心后者要让不知道什么口味的陌生客人天天来吃还得保证食材不断供、后厨不炸锅、上菜不超时。我自己在这种事情上吃过亏。最开始我迷信“谁的模型准谁说了算”结果上线之后用户反馈越来越差——后来才发现是我只看了离线AUC根本没看线上真实用户的分布已经变了。模型再能打离开了工程化的数据和部署管道它就是个实验室里的花盆挪到野外就会被现实直接晒死。1.2 我见过最多的“假起点”“从零开始”这四个字我见过五个常见的假起点一上来就学大数据框架Hadoop、Spark、Flink全都装上结果一个业务都没跑过一上来就搞分布式训练8卡机器都准备好了实际上数据量连一张卡都用不满一上来就追求SOTA把一个十亿参数的模型加载起来才发现机器内存根本不够一上来就做微服务把AI推断拆成八个服务结果延迟高到没法用一上来就研究强化学习结果连基础的数据集怎么清洗都还没弄明白。这些不是我编的是我身边真实发生过的案例很多我也踩过。它们的共同点是你在学工具而不是学系统你在追热点而不是追问题。真正的从零开始起点应该是“我现在手里有一个什么问题”而不是“我现在想学什么技术”。2. 我踩过的第一道坑把算法当工程把笔记本当生产环境刚开始做AI项目的时候我犯过一个现在想起来都会脸红的错误在一个图像分类任务里我在Jupyter Notebook里把模型训练好了准确率91%我特别高兴直接把Notebook里所有的单元格从头到尾跑了一遍然后把生成的模型文件发给同事说“可以上线了”。同事的眼神我现在还记得。2.1 一次训练完为什么所有人都在骂我问题不是模型本身而是整个流程。同事拿到模型文件发现自己没有对应的Python环境我把需要的依赖写在一个txt里但没写版本代码里的相对路径都是基于我电脑的数据预处理步骤藏在笔记本的第12个单元格里注释只有一句“处理脏数据”。同事试着复现跑了三个小时没成功。最后我自己重新跑也跑了半天没成功——因为我改了数据路径但忘了在笔记本里同步。这件事让我明白了一个最基本的道理AI工程必须从“可复现性”开始。你训练出一个模型不算什么别人能复现你的模型、你能复现你三个月前的模型才叫工程。后来我专门花了一整天把那个项目从Notebook里拆出来全部改成Python脚本加上命令行参数固定所有依赖版本才终于实现“一个人能跑通、两个人也能跑通”。2.2 从Notebook到自动化流水线的转变Notebook不是不能用它适合做探索性分析和可视化。但你一旦要进入工程化阶段就必须完成三个转变代码从单元格变成模块把数据加载、特征工程、模型定义、训练逻辑、评估逻辑拆成独立的.py文件每一个都可以单独导入和测试配置从硬编码变成参数化路径、超参数、模型名、批次大小、学习率全部抽出来用配置文件管理不要写死在代码里环境从“我这能跑”变成“哪里都能跑”用依赖锁定文件锁定所有包版本最好再用容器把你的整个运行环境固化下来。我知道有人会反驳“是不是过度工程了我就一个小任务有必要这么折腾吗”答案是如果这个小任务你只跑一次确实没必要如果你要面对的是持续变化的业务数据你就要为未来三个月的自己负责。未来的你会感谢现在肯花两小时搭脚手架的你。3. 从零搭建一个可复用的AI工程骨架被那次Notebook事故狠狠教育过之后我开始琢磨怎么搭一个属于自己的AI工程骨架。所谓骨架就是一套固定的项目结构以后每一个新项目都能往里面套不用每次都从零开始思考文件夹该怎么放、代码该怎么组织、流程该怎么串。这件事花了我不少时间但收益非常巨大。3.1 我把代码组织成了这样先给你看一个我实际在用的最小骨架my_ai_project/ ├── configs/ │ ├── train.yaml │ └── inference.yaml ├── data/ │ ├── raw/ │ ├── processed/ │ └── splits/ ├── src/ │ ├── data_preprocessing.py │ ├── features.py │ ├── models.py │ ├── train.py │ ├── evaluate.py │ └── predict.py ├── tests/ │ ├── test_preprocessing.py │ └── test_predict.py ├── models/ │ ├── checkpoints/ │ └── archived/ ├── notebooks/ │ └── exploration.ipynb ├── requirements.txt └── README.md你可能已经发现我把数据分成了raw、processed、splits三份。raw就是你拿到的原始数据绝对不能动processed是清洗之后的干净版本splits是划分好的训练、验证、测试集。这样做的原因是一旦你某天想回头检查某个数据是怎么来的、逻辑有没有问题你可以从原始数据重新跑一遍而不是对着已经改得面目全非的中间文件发愁。src里的每个模块都只干一件事而且都留了入口和出口方便测试和替换。train.py负责读配置、加载数据、训练模型、保存checkpointevaluate.py负责在验证集和测试集上算指标predict.py负责把训练好的模型加载起来对外提供推理接口。3.2 配置、实验跟踪、评估指标的工程化光有目录结构还不够你还需要一套管理实验的思维。我见过太多人训练十次模型模型文件和日志全放在同一个文件夹里名字叫model_final_2.pth三个星期后根本分不清哪个是哪个。我个人的解决办法是每次训练前自动生成一个带有时间戳和配置哈希值的实验目录模型checkpoint、训练日志、评估结果全部扔进去把当时使用的所有超参数写进这个目录里的config.yaml确保任何一个实验都能完整复现训练结束立即输出评估报告包括各类指标和图表保存在实验目录里方便以后对比。用表格总结一下不同实验的组织方式管理方式优点缺点手动命名文件简单直接极易混淆无法追溯超参数时间戳配置哈希自动化、可追溯需要花一点时间写日志代码实验跟踪工具功能强大、可视化需要额外维护工具服务强烈建议哪怕你的项目再小也从第二天开始养成“一个实验一个目录”的习惯。这个习惯在初期不会立竿见影但当你的实验数量超过十个的时候它会救你的命。4. 模型上线前必须想清楚的五件事当你把模型训练好、代码工程化也做完了接下来最容易被忽略的就是部署和监控。很多人在这一步栽跟头觉得模型能跑就万事大吉结果一上线就卡顿、报错、效果崩盘。我在这里总结了五件必须在模型上线前想清楚的事都是我从真实事故里换来的。4.1 延迟、吞吐、成本怎么算模型快不快不是靠感觉判断的。你要先问自己这几个问题每秒会有多少次请求峰值是多少单次请求的延迟预算是多少50毫秒还是500毫秒能用的机器资源是什么CPUGPU还是边缘设备成本上限是多少每个月能花多少钱在这一推理服务上举个具体例子如果你要做一个在线推荐服务单次请求需要实时响应那你就不能把一个700亿参数的模型直接挂在接口后面否则延迟和成本都会失控。这时候你有三种选择换更小的模型、做量化压缩、把推理拆到合适的服务上。工程不是最好的模型而是在预算和约束下最合适的模型。4.2 监控到底监控什么很多人以为监控就是看看服务器CPU高不高、内存够不够但对AI服务来说你要监控的东西更多特征漂移、预测分布变化、置信度变化、上游数据质量、模型版本是否在预期范围内。我遇到过一次几乎导致事故的情况数据源突然开始返回同一类型的重复数据模型预测结果开始偏斜但因为CPU和内存都正常监控一点告警都没出。从那以后我的监控列表里至少包括输入特征的基础统计量如均值、标准差、缺失值比例预测结果的分布比如分类概率分布是否和训练时一致延迟和吞吐的百分位数而不只是平均值上下游数据源的可用性和延迟。4.3 回滚和重训不是同一个东西模型上线之后如果效果突然下降你需要的是快速回滚到上一个还能用的版本而不是立刻重新训练。重训至少需要几小时甚至几天而回滚只需要几秒钟。因此你的部署系统必须具备以下能力同时保留多个模型版本一份代码可以加载不同版本的权重发布新版本时保留旧版本的路由入口方便一键切换对新版本做灰度测试先放一部分流量观察指标后再全量开放。我见过一个团队因为模型效果下降没有回滚版本而是立刻让算法工程师重新训练结果用户投诉了三天新模型还是没准备好。这种时候工程上的“退一步”比算法上的“进一步”更重要。5. 从零开始的第二个阶段把“能跑”变成“能用”当你把上面这些工程骨架和部署监控都搭起来之后你的AI项目就算从“能跑”迈向了“能用”。但“能用”还不等于“好用”。真正从零开始做AI工程走到这一步才算走出新手村接下来你要面对的是更复杂、更考验耐心的协作和迭代问题。5.1 和业务方对齐目标准确率不是全部我经常对团队里的新工程师说一句话“你交给业务方一个94%准确率的模型不如交给他一个90%准确率但响应时间是0.2秒的模型因为后者真正能落到业务里。”AI工程的价值永远是在真实业务约束下产生的。一个典型的例子业务方想要“识别出所有坏评论”但你的模型为了追求召回率把大量正常评论也误判成了坏评论导致运营一天要处理几百个假告警。这时候准确率和召回率的权衡就不是算法问题而是业务决策问题。你必须和业务方一起明确哪一种错误更容易接受是漏掉坏评论还是误伤好评论定下来之后再去找最优阈值。这一步做得越快你的项目落地就越顺。5.2 数据漂移与反馈闭环模型上线之后数据分布一定会变。你训练时用的是三月份的数据到了八月份用户的线上行为已经变了你的模型却还停留在三月份。所以你必须在系统里埋一个反馈闭环线上记录模型对每条样本的预测结果定期抽样做人工标注得到新的标签系统自动对比新数据分布和训练数据分布的差异差异超过阈值时主动提醒团队考虑重训或增量更新。这个闭环听起来很复杂但最小实现可能只需要一个定时任务加两张表一张存线上预测一张存标注结果。关键是你要有这种意识而不是等到业务方抱怨“你们的AI是不是傻了”才去查。5.3 我在三个真实项目里学到的迭代节奏在我做过的项目里有一个搜索意图识别系统一个异常检测系统还有一个客服问答助手它们的迭代节奏完全不同但都遵循一个共同原则小步快跑永远留有余地。搜索意图识别项目用户请求量巨大我们对模型做了量化压缩又把推理服务做了多级缓存最终把单次请求成本降了一半。异常检测项目数据和标签非常稀少我们干脆不用黑盒模型只用了一套可解释性强、阈值透明的统计检测规则业务方反而觉得非常可靠。客服问答项目用户对话格式千变万化我们首版甚至没有用大模型而是用检索加规则兜底每天分析失败样本再逐步迭代。这些事情说明一点AI工程的本质不是堆技术而是在正确的地方做正确的取舍。从零开始不可怕可怕的是你用从零开始的心态去处理已经上线半年、数据翻了三倍的系统。最后再分享一个小技巧无论你做什么AI项目一定要把“失败记录”也纳入工程流程。不要只记录成功的超参数也要记录每一次失败的假设和结果。我个人的实验目录里总有一份失败笔记每当我重新踩进同一个坑这份笔记都能提醒我你不是第一次犯这个错了上一次你已经想清楚了。从零开始做AI工程真正的成长不是学会了一个新框架而是你越来越清楚地知道什么情况下该把精力放在算法、什么情况下该把精力放在系统、什么情况下该把精力放在人。想明白这件事你就已经比绝大多数初学者走得更远了。
AI工程从零开始：模型部署、监控与迭代的完整实践指南
1. 从零开始先别急着写模型经常有人问我AI工程从零开始第一门课是不是该去啃Transformer我的回答是先把“活下来”这件事想清楚再谈先进模型。ai-engineering这个词最近被翻来覆去地讲但真正从零开始做落地系统的人都会告诉你同一句话最难的不是把模型训练出来而是把模型放进一个能长期运转的系统里让它有价值、可维护、能迭代。我见过太多人把“从零开始”理解成“从模型开始”。他们花三个月玩转PyTorch背熟了各种损失函数一上来就在Kaggle上刷到高分然后信心满满地说“我要做一个AI项目”。结果呢训练脚本在个人电脑上跑得飞快一到团队协作就彻底失控数据文件夹叫final_v2代码里全是魔法数字环境依赖全靠人品AI能力再强也扛不住这样的工程底座。这不是AI工程这是算法实验。AI工程和算法实验最大的区别就是你必须对“系统不崩”负责而不是只对“模型精度”负责。我这篇文章想聊的就是我这些年从零开始折腾AI工程时总结下来的一套套路先搞清楚工程和算法的边界再搭一套能复用的骨架接着老老实实把部署和监控补上最后学会和业务方对齐目标。这条路径不是为了让你炫技而是为了让你在真实环境里少撞几面墙。适合三类人刚入行的算法工程师、想转行做AI的后端工程师以及已经在项目里被各种工程问题折磨得想辞职的初学者。1.1 先把“AI工程”这顶帽子戴清楚AI工程不是说你会训练模型就够的。它涵盖的是从数据准备、特征工程、模型训练、模型评估、部署上线、监控告警到持续迭代的整条链路。简单说算法工程师解决的是“模型能不能预测”的问题AI工程师解决的是“系统能不能稳定地预测”的问题。这两者之间的差距就像做饭和开餐厅前者能让家里人吃得开心后者要让不知道什么口味的陌生客人天天来吃还得保证食材不断供、后厨不炸锅、上菜不超时。我自己在这种事情上吃过亏。最开始我迷信“谁的模型准谁说了算”结果上线之后用户反馈越来越差——后来才发现是我只看了离线AUC根本没看线上真实用户的分布已经变了。模型再能打离开了工程化的数据和部署管道它就是个实验室里的花盆挪到野外就会被现实直接晒死。1.2 我见过最多的“假起点”“从零开始”这四个字我见过五个常见的假起点一上来就学大数据框架Hadoop、Spark、Flink全都装上结果一个业务都没跑过一上来就搞分布式训练8卡机器都准备好了实际上数据量连一张卡都用不满一上来就追求SOTA把一个十亿参数的模型加载起来才发现机器内存根本不够一上来就做微服务把AI推断拆成八个服务结果延迟高到没法用一上来就研究强化学习结果连基础的数据集怎么清洗都还没弄明白。这些不是我编的是我身边真实发生过的案例很多我也踩过。它们的共同点是你在学工具而不是学系统你在追热点而不是追问题。真正的从零开始起点应该是“我现在手里有一个什么问题”而不是“我现在想学什么技术”。2. 我踩过的第一道坑把算法当工程把笔记本当生产环境刚开始做AI项目的时候我犯过一个现在想起来都会脸红的错误在一个图像分类任务里我在Jupyter Notebook里把模型训练好了准确率91%我特别高兴直接把Notebook里所有的单元格从头到尾跑了一遍然后把生成的模型文件发给同事说“可以上线了”。同事的眼神我现在还记得。2.1 一次训练完为什么所有人都在骂我问题不是模型本身而是整个流程。同事拿到模型文件发现自己没有对应的Python环境我把需要的依赖写在一个txt里但没写版本代码里的相对路径都是基于我电脑的数据预处理步骤藏在笔记本的第12个单元格里注释只有一句“处理脏数据”。同事试着复现跑了三个小时没成功。最后我自己重新跑也跑了半天没成功——因为我改了数据路径但忘了在笔记本里同步。这件事让我明白了一个最基本的道理AI工程必须从“可复现性”开始。你训练出一个模型不算什么别人能复现你的模型、你能复现你三个月前的模型才叫工程。后来我专门花了一整天把那个项目从Notebook里拆出来全部改成Python脚本加上命令行参数固定所有依赖版本才终于实现“一个人能跑通、两个人也能跑通”。2.2 从Notebook到自动化流水线的转变Notebook不是不能用它适合做探索性分析和可视化。但你一旦要进入工程化阶段就必须完成三个转变代码从单元格变成模块把数据加载、特征工程、模型定义、训练逻辑、评估逻辑拆成独立的.py文件每一个都可以单独导入和测试配置从硬编码变成参数化路径、超参数、模型名、批次大小、学习率全部抽出来用配置文件管理不要写死在代码里环境从“我这能跑”变成“哪里都能跑”用依赖锁定文件锁定所有包版本最好再用容器把你的整个运行环境固化下来。我知道有人会反驳“是不是过度工程了我就一个小任务有必要这么折腾吗”答案是如果这个小任务你只跑一次确实没必要如果你要面对的是持续变化的业务数据你就要为未来三个月的自己负责。未来的你会感谢现在肯花两小时搭脚手架的你。3. 从零搭建一个可复用的AI工程骨架被那次Notebook事故狠狠教育过之后我开始琢磨怎么搭一个属于自己的AI工程骨架。所谓骨架就是一套固定的项目结构以后每一个新项目都能往里面套不用每次都从零开始思考文件夹该怎么放、代码该怎么组织、流程该怎么串。这件事花了我不少时间但收益非常巨大。3.1 我把代码组织成了这样先给你看一个我实际在用的最小骨架my_ai_project/ ├── configs/ │ ├── train.yaml │ └── inference.yaml ├── data/ │ ├── raw/ │ ├── processed/ │ └── splits/ ├── src/ │ ├── data_preprocessing.py │ ├── features.py │ ├── models.py │ ├── train.py │ ├── evaluate.py │ └── predict.py ├── tests/ │ ├── test_preprocessing.py │ └── test_predict.py ├── models/ │ ├── checkpoints/ │ └── archived/ ├── notebooks/ │ └── exploration.ipynb ├── requirements.txt └── README.md你可能已经发现我把数据分成了raw、processed、splits三份。raw就是你拿到的原始数据绝对不能动processed是清洗之后的干净版本splits是划分好的训练、验证、测试集。这样做的原因是一旦你某天想回头检查某个数据是怎么来的、逻辑有没有问题你可以从原始数据重新跑一遍而不是对着已经改得面目全非的中间文件发愁。src里的每个模块都只干一件事而且都留了入口和出口方便测试和替换。train.py负责读配置、加载数据、训练模型、保存checkpointevaluate.py负责在验证集和测试集上算指标predict.py负责把训练好的模型加载起来对外提供推理接口。3.2 配置、实验跟踪、评估指标的工程化光有目录结构还不够你还需要一套管理实验的思维。我见过太多人训练十次模型模型文件和日志全放在同一个文件夹里名字叫model_final_2.pth三个星期后根本分不清哪个是哪个。我个人的解决办法是每次训练前自动生成一个带有时间戳和配置哈希值的实验目录模型checkpoint、训练日志、评估结果全部扔进去把当时使用的所有超参数写进这个目录里的config.yaml确保任何一个实验都能完整复现训练结束立即输出评估报告包括各类指标和图表保存在实验目录里方便以后对比。用表格总结一下不同实验的组织方式管理方式优点缺点手动命名文件简单直接极易混淆无法追溯超参数时间戳配置哈希自动化、可追溯需要花一点时间写日志代码实验跟踪工具功能强大、可视化需要额外维护工具服务强烈建议哪怕你的项目再小也从第二天开始养成“一个实验一个目录”的习惯。这个习惯在初期不会立竿见影但当你的实验数量超过十个的时候它会救你的命。4. 模型上线前必须想清楚的五件事当你把模型训练好、代码工程化也做完了接下来最容易被忽略的就是部署和监控。很多人在这一步栽跟头觉得模型能跑就万事大吉结果一上线就卡顿、报错、效果崩盘。我在这里总结了五件必须在模型上线前想清楚的事都是我从真实事故里换来的。4.1 延迟、吞吐、成本怎么算模型快不快不是靠感觉判断的。你要先问自己这几个问题每秒会有多少次请求峰值是多少单次请求的延迟预算是多少50毫秒还是500毫秒能用的机器资源是什么CPUGPU还是边缘设备成本上限是多少每个月能花多少钱在这一推理服务上举个具体例子如果你要做一个在线推荐服务单次请求需要实时响应那你就不能把一个700亿参数的模型直接挂在接口后面否则延迟和成本都会失控。这时候你有三种选择换更小的模型、做量化压缩、把推理拆到合适的服务上。工程不是最好的模型而是在预算和约束下最合适的模型。4.2 监控到底监控什么很多人以为监控就是看看服务器CPU高不高、内存够不够但对AI服务来说你要监控的东西更多特征漂移、预测分布变化、置信度变化、上游数据质量、模型版本是否在预期范围内。我遇到过一次几乎导致事故的情况数据源突然开始返回同一类型的重复数据模型预测结果开始偏斜但因为CPU和内存都正常监控一点告警都没出。从那以后我的监控列表里至少包括输入特征的基础统计量如均值、标准差、缺失值比例预测结果的分布比如分类概率分布是否和训练时一致延迟和吞吐的百分位数而不只是平均值上下游数据源的可用性和延迟。4.3 回滚和重训不是同一个东西模型上线之后如果效果突然下降你需要的是快速回滚到上一个还能用的版本而不是立刻重新训练。重训至少需要几小时甚至几天而回滚只需要几秒钟。因此你的部署系统必须具备以下能力同时保留多个模型版本一份代码可以加载不同版本的权重发布新版本时保留旧版本的路由入口方便一键切换对新版本做灰度测试先放一部分流量观察指标后再全量开放。我见过一个团队因为模型效果下降没有回滚版本而是立刻让算法工程师重新训练结果用户投诉了三天新模型还是没准备好。这种时候工程上的“退一步”比算法上的“进一步”更重要。5. 从零开始的第二个阶段把“能跑”变成“能用”当你把上面这些工程骨架和部署监控都搭起来之后你的AI项目就算从“能跑”迈向了“能用”。但“能用”还不等于“好用”。真正从零开始做AI工程走到这一步才算走出新手村接下来你要面对的是更复杂、更考验耐心的协作和迭代问题。5.1 和业务方对齐目标准确率不是全部我经常对团队里的新工程师说一句话“你交给业务方一个94%准确率的模型不如交给他一个90%准确率但响应时间是0.2秒的模型因为后者真正能落到业务里。”AI工程的价值永远是在真实业务约束下产生的。一个典型的例子业务方想要“识别出所有坏评论”但你的模型为了追求召回率把大量正常评论也误判成了坏评论导致运营一天要处理几百个假告警。这时候准确率和召回率的权衡就不是算法问题而是业务决策问题。你必须和业务方一起明确哪一种错误更容易接受是漏掉坏评论还是误伤好评论定下来之后再去找最优阈值。这一步做得越快你的项目落地就越顺。5.2 数据漂移与反馈闭环模型上线之后数据分布一定会变。你训练时用的是三月份的数据到了八月份用户的线上行为已经变了你的模型却还停留在三月份。所以你必须在系统里埋一个反馈闭环线上记录模型对每条样本的预测结果定期抽样做人工标注得到新的标签系统自动对比新数据分布和训练数据分布的差异差异超过阈值时主动提醒团队考虑重训或增量更新。这个闭环听起来很复杂但最小实现可能只需要一个定时任务加两张表一张存线上预测一张存标注结果。关键是你要有这种意识而不是等到业务方抱怨“你们的AI是不是傻了”才去查。5.3 我在三个真实项目里学到的迭代节奏在我做过的项目里有一个搜索意图识别系统一个异常检测系统还有一个客服问答助手它们的迭代节奏完全不同但都遵循一个共同原则小步快跑永远留有余地。搜索意图识别项目用户请求量巨大我们对模型做了量化压缩又把推理服务做了多级缓存最终把单次请求成本降了一半。异常检测项目数据和标签非常稀少我们干脆不用黑盒模型只用了一套可解释性强、阈值透明的统计检测规则业务方反而觉得非常可靠。客服问答项目用户对话格式千变万化我们首版甚至没有用大模型而是用检索加规则兜底每天分析失败样本再逐步迭代。这些事情说明一点AI工程的本质不是堆技术而是在正确的地方做正确的取舍。从零开始不可怕可怕的是你用从零开始的心态去处理已经上线半年、数据翻了三倍的系统。最后再分享一个小技巧无论你做什么AI项目一定要把“失败记录”也纳入工程流程。不要只记录成功的超参数也要记录每一次失败的假设和结果。我个人的实验目录里总有一份失败笔记每当我重新踩进同一个坑这份笔记都能提醒我你不是第一次犯这个错了上一次你已经想清楚了。从零开始做AI工程真正的成长不是学会了一个新框架而是你越来越清楚地知道什么情况下该把精力放在算法、什么情况下该把精力放在系统、什么情况下该把精力放在人。想明白这件事你就已经比绝大多数初学者走得更远了。