前阵子有个朋友找我聊天说想做AI产品问我从哪下载个开源模型开始调。我反问了一句模型你有的是地方找但你打算怎么衡量它好不好、怎么把它接进业务、怎么在模型变差时第一时间知道他愣了一下。这个问题的答案才是AI工程AI engineering真正要解决的事。我在这个领域摸爬滚打了好几年从一个人单干到带一个小团队踩过的坑比调参调出来的点还多今天把从零起步做AI工程的路线、工具和那些文档里不会写的经验一次性讲透。1. AI工程到底在做些什么先避开模型崇拜这个坑1.1 模型开发和AI工程不是一回事很多人一提到AI工程脑子里浮现的是训练模型、调参、做特征工程。但那是机器学习研究或者模型研发。AI工程的范围要大得多而且它的核心难点不在模型本身而在模型周围那一大圈基础设施和流程。打个比方。模型研发有点像研发一款新发动机你负责让它在台架上爆发出最大马力。AI工程则像是造一辆能每天上路跑的车你得考虑怎么把发动机装进底盘、怎么加油保养、怎么让驾驶员及时发现异常、出了故障怎么维修。很多团队死磕发动机马力结果造出来的车根本开不出车库。具体来说一个完整的AI工程体系至少包含这几层数据层采集、清洗、标注、版本管理、质量监控评测层离线评测集、线上评估指标、bad case回收机制模型层基座选择、训练/微调、模型版本管理服务层推理服务、接口封装、容量规划、降级策略反馈层线上日志、用户行为回收、自动标注、再迭代这五层缺一个短期看不出问题跑两三个月一定出乱子。我见过太多团队把全部精力押在模型层评测集随手拿个开源数据集顶替数据管线用一次性脚本凑合上线后只有准确率一个指标连bad case都不知道去哪看。这种项目运气好撑过Demo期运气不好第一周就被用户骂回原型。1.2 我见过最典型的翻车现场说一个真实案例。2022年我参与过一个文本审核项目团队里算法同事花了三周微调一个模型离线准确率从87%刷到93.5%大家都很兴奋。结果上线第一天线上误杀率是离线测试时的6倍。为什么因为离线评测集是从公共数据集里抽的清一色标准书面语。线上的真实输入呢有错别字、有表情、有倒装句、有方言梗甚至有条消息只有两个字母加三个感叹号。模型在离线集上看着很聪明一到真实环境就原形毕露。这个翻车现场教会我一件事AI工程项目翻车极少翻在模型能力不够绝大多数翻在数据分布不一致、评测口径失真、反馈链路断裂。所以从零开始搭建AI工程体系第一站不是选模型而是把数据和评测的地基打扎实。2. 从零起步的第一站不是模型是数据与评测2.1 为什么先做评测集如果只能带一样东西进入AI工程项目我会选评测集。评测集是项目的方向盘没有它你做的每一次模型更新、每一次prompt修改都像是闭着眼睛开车。有了它你能明确地回答新版本到底比旧版本强在哪、弱在哪。很多人觉得评测集就是攒几百条数据填个准确率。我建议直接推翻这种想法。一个真正能用的评测集至少要满足三个条件第一数据是你的真实业务数据不是公开数据集。哪怕刚开始只有50条也要从真实用户输入里挑。第二覆盖典型场景和边界场景比如电商客服至少要有售前咨询、售后投诉、价格询问、物流查询、闲聊这五类外加几十条恶意输入和极端情绪输入。第三必须有明确的答案标准。两条标注员对同一条case给出不同答案在评测环境里不是小事要提前定好规则。以客服意图识别为例一个可复用的评测集长这样[ { id: case_0001, input: 你们这破快递三天了还没到能不能退了, expect: {intent: after_sale, tone: negative}, note: 情绪词破不能影响意图判断 }, { id: case_0002, input: 在吗在吗在吗想问问XL码还有没有, expect: {intent: inventory_query, tone: neutral} } ]注意我个人强烈建议在评测集里专门留一个陷阱区放那些人类一眼懂、模型容易错的case。比如上面第一条用户其实在催快递退货只是气话。这种case才是评测集真正的价值所在它记录的不是标准答案而是任务背后的业务经验。2.2 数据处理干净、可追溯、可复用数据管线在项目初期最容易沦为一次性脚本。今天从Excel里读数据明天从数据库拉后天爬接口。等三个月后要复现某个实验时你根本不知道当时用的是哪份数据、清洗过没有。这个问题不一定要上重型工具。小团队起步阶段做到三件事就够了数据版本化每次清洗后的数据集存到独立目录或用DVC管理文件名里带日期和版本如train_20250601_v2.csv绝不在原文件上原地打补丁数据血缘用README记录每份数据从哪来、经过什么处理、被谁用于什么实验哪怕只是三行字清洗脚本入库所有清洗逻辑写成函数而不是临时命令行的手工操作这意味着下个月你可以用同一套脚本把七月份的数据重新洗一遍我见过最有反差的团队数据管道搞得像盘丝洞模型却正规军一样做实验记录。方向全反了。模型实验最多损失几个星期的训练时间数据版本错乱会直接导致评测结果失真给项目带来瘫痪式的倒退。2.3 基线先行先跑通一个朴素的版本手里有了评测集下一步是跑基线。这里我给一条铁律第一个版本永远用最笨的方法实现。可以是纯规则匹配可以是TF-IDF加逻辑回归甚至可以是人工if-else加一个关键词列表。不要一上来就微调大模型。这么做的目的有两个。第一基线定义了问题至少能及格的下限后续你调模型得到了什么进展才有一个可量化的参照系。第二基线上线后能帮助你跑通整条工程链路数据怎么流入、预测结果怎么输出、置信度怎么处理、失败时怎么兜底。链路通了后面换更强的模型只是替换一个环节链路不通再强的模型也是无根之萍。我遇到过一个项目团队跳过了基线直接微调千亿参数模型。三个多月过去模型效果确实好但后端衔接、监控、反馈一个都没落地。被拉到生产环境演示时系统在高峰期直接崩溃。试想一下如果最早跑通的是一个朴素规则版本整个系统会稳定得多而模型模块随时可替换。3. 最小端到端系统从代码到服务的完整链路3.1 系统骨架设计AI系统听起来很高大上但骨架其实很朴素。以一个典型的内容分类系统为例无非是六段链路输入接收 → 数据校验与预处理 → 特征/检索 → 模型推理 → 输出校验 → 结果落地与反馈采集这六段可以分开写成独立模块。在项目初期我不建议把模型逻辑和业务逻辑搅在一个文件里。你想想如果模型接口变了业务代码也要跟着改那每次模型迭代都要同时改动一堆接口最后维护成本会非常突兀。初期骨架尽量把离线训练链路和在线服务链路分开。离线链路负责数据清洗、评测、训练、生成模型产物在线服务只做一件事加载模型产物并产出预测同时记录请求日志供后续离线分析。两个链路通过模型产物这个中间件衔接。哪怕你的模型产物只是一个huggingface模型文件夹加配置文件也要当成正式接口来对待。3.2 部署的不是模型而是带版本的服务很多初学者以为部署就是把模型load进来然后跑predict。真正生产环境里部署的从来不是孤立的模型而是模型 配置 代码三者组成的一个不可分割版本。我给团队定过一条简单可执行的规定每次发布必须能回答三个问题——用的是哪个版本的模型权重用的什么预处理/后处理逻辑哪份配置文件生效任何时候出问题能快速定位是模型变了、代码变了还是参数变了。看着简单实际操作中消耗大量排查时间的问题八成是这三者之间没对齐。部署方式上小团队起步没必要上Kubernetes那一套。以云服务器为例单机Docker再加一个进程守护就够用。我早期的生产系统就是一台2核4G的云主机跑着FastAPI容器搭配Docker Compose管理。这个配置在日均几千次推理请求的内部工具场景下完全是够的。核心原则是简单可维护留出升级空间。一个最小可用的服务目录结构如下my_ai_service/ ├── app/ │ ├── main.py # FastAPI入口 │ ├── schemas.py # 输入输出schema │ ├── predictor.py # 模型加载与推理逻辑 │ └── config.yaml # 版本相关配置 ├── models/ │ └── intent_v3.bin # 模型产物名字里带版本 ├── tests/ │ └── test_api.py # 接口冒烟测试 ├── Dockerfile └── requirements.txt看这个结构部署模型实际上部署的是一个完整的服务单元。模型权重只是这个单元里的一个文件而已。我一直认为让模型文件像代码一样进入版本管理、像软件包一样被发布是AI工程从实验室脚本走向生产系统的标志性一步。3.3 观测与反馈闭环系统上线只是开始真正考验工程能力的是上线之后。传统软件如果没有Bug行为是可预期的AI系统不是模型今天表现好不代表明天也好。数据分布会漂移用户行为会变第三方接口质量会波动。所以AI系统从上线第一天就必须有观测手段。最低成本的观测方案是三件套日志每条请求记录输入、输出、置信度、耗时、版本号存够一定周期指标响应时间、请求量、置信度分布、兜底触发次数做成定时聚合任务抽检每天人工抽查看几十条预测结果把明显错误的case捞出来扔进bad case池这套机制跑起来之后你才真正进入了反馈闭环状态生产环境捞bad case → 定期整理进评测集 → 评测集驱动模型迭代 → 新版本再上线。这个过程是整个AI工程的心脏。这个闭环就是你掌握主动权的关键否则模型迭代就是在黑暗中碰运气。我见过很多团队在Demo期做得漂亮却败在上线后的反馈机制上误报没人管坏case没人回收下个月模型还是一年前的版本。而从零开始搭好反馈机制无非是几百行日志代码加一张每天的抽检表格成本极低收益却极高。4. 工具链怎么选别为了时髦上重武器4.1 先分清你处在哪个阶段AI工程的工具链市场非常拥挤从数据标注平台到特征平台到模型仓库到在线推理引擎每个方向上都有好几个选择。新手的第一反应是全都要资深工程师的第一反应是现在需要吗。我用阶段来判断工具需求分清楚了就不纠结阶段特征推荐工具策略原型期验证想法是否成立数据量小于10万Notebook加轻量代码数据库用SQLite或者PostgreSQL即可生产期有真实用户使用需要稳定服务FastAPI加Docker数据存PostgreSQL日志落文件或对象存储规模化期多模型多团队并用需要统一治理再上向量库、MLflow/模型注册、Feature Store等行业方案注意这个顺序不能跳。我本人犯过这样的错误在原型期就搭了一套带外键关系的严格数据库schema结果每天实验的数据格式都在变表结构频繁迁移浪费了大量时间。后来老老实实用一套极简工具速度立刻回升。4.2 我推荐的最小工具组合如果是做垂直领域的AI应用我会推荐下面这套组合起步它足够撑起80%的中小规模场景。核心编排用Python因为它生态最全。在线服务用FastAPI自带schema校验和文档省太多写接口定义的精力。数据库用PostgreSQL最稳的关系库所有结构化数据都可以先塞进去。跑批任务用简单的Python脚本加Cron定时运行即可不必上复杂的调度框架等真正同时在线跑几十个任务的时候再引入Airflow之类的工具。如果业务涉及语义检索在原有数据库容量已经撑不住的时候再考虑接一个向量检索组件而非一开始就上。向量库带来的维度灾难和运维复杂度很多小团队扛不住。还有人会问该不该买现成的ML平台或者AI中台。我的建议是预算允许可以买但前提是你已经搞清楚自己的核心环节是什么。AI中台解决的问题是规模化如果你的团队连一个完整的闭环都没跑通中台上的工具你也用不明白。4.3 重武器的代价说到底工程化的工具链是一种成本不是收益。每次引入一个新组件都意味着新增一份学习、部署、监控、修Bug的负担。我见过一个很极端的案例一个只有5人的小团队为了保证架构先进上了Kubernetes加三个开源中间件结果整整一个季度都在调试基础设施业务需求几乎没有推进。负责人后来自己说这套系统交付的Demo和年初做出来的几乎没有区别。工程化的正确姿态是够用就好按需加码。不是所有系统都要微服务化不是所有模型都要上GPU集群不是所有数据都要建数据湖。等业务量拖着你的系统跑不动了再引入下一级工具才是成本最低的演进方式。技术选型要跟着业务节奏走。真正的关系是业务增长带动系统演进而不是系统先豪横起来等着业务来填空。5. 迭代和团队协作AI项目是系统项目5.1 一个人单干时的工程纪律不是每个人都有团队很多读者起步阶段就是一个人。一个人做AI工程最大的敌人其实是自己的随意性今天这个思路明天换另一个库重写一遍过了两周连自己都忘了当时的实验条件。一个人单干更要立工程纪律。我自己的实践有三条第一每次实验必须有记录哪怕是Markdown里写几句话改了什么、评测结果如何、为什么改。需要再花30秒就能回答上个月那个版本为什么更好。第二代码在改动之前先commit保持随时可以revert到上一个效果。很多人怕麻烦就越来越乱最后连一个好版本都没留下。第三用周迭代而非想到哪做到哪的节奏来推进。周五花一小时跑一遍评测看本周的改动是变好还是变坏。5.2 多人协作的角色配置团队配合是AI工程里面最容易被低估的瓶颈。一个正常的AI应用项目其实包含四类工作数据、模型、平台、产品。数据负责整理吃透脏乱差的业务数据模型负责模型选型、训练与评估平台负责服务链路、稳定性和监控产品负责需求侧——定义这个系统到底为谁服务、怎么衡量它是否成功。小团队里四个人不齐是常态多数人都是从一人多岗开始。但即使一人多岗也要避免同一个人同时背数据清洗和服务稳定性这两个职责因为在紧急时刻他会不自觉地偏向自己更熟的领域另一边的漏洞就越拖越大。拆分职责与接口对齐是团队协作里最值得做的功课。最见功夫的是两层接口设计的对齐数据接口和模型接口。数据接口规定好每次版本迭代使用的数据长什么样模型接口规定好调用方传什么参数、拿到什么输出。接口一旦定下来数据组和模型组就能各自独立推进不用天天开会等对方进度。这一点我以前吃过教训模型组按自己的喜好改了输出格式接口层崩溃前后端对联花了两天之后我强行为每个模型服务补上输出schema并写入测试用例。5.3 与业务方打交道的经验做AI工程最大的隐性负担其实是管理预期。技术人习惯讲准确率、召回率但业务方真正关心的是成本降低了多少、转化率提升了多少、客服工单下降了多少。你如果不能把模型指标翻译成业务语言就很难获得持续的资源支持。我常用的做法是每次模型升级除了技术评测报告再加一页业务影响说明用抽样估算的方式说明按当前流量预估本次升级预计每天能帮客服少转接X通电话或者预计减少X条无效审核。哪怕估算粗糙只要给出推导过程业务方就愿意理解和支持。另外一个重要预期是AI不是完美的。上线前把边界讲清楚——哪些case系统会兜底给人处理、置信度低于多少自动转人工是系统性工程问题也是治理问题。这比上线后再解释为什么AI漏了要省心一百倍。6. 从零到一之后的迭代给后来者的实在建议项目从零到一后不管你是个人维护还是团队协作接下来会进入一段最考验人的运维迭代期。这个阶段的建议不多但每一条都是我付过学费之后换来的。第一把bad case当资产而不是麻烦。用户每一次投诉、每一句这什么破玩意都是免费赠送的高价值训练数据。我团队有个习惯每周固定时间整理线上翻车记录挑出同类型问题里最具代表性的case写入回归测试集。积累半年后这个回归集比任何公开数据集都珍贵因为它是业务真实现场的浓缩。新模型过不了这个回归集绝不发布。第二不要频繁更换基座模型。很多团队一看到新模型发布就如坐针毡连夜追赶。实际上模型的每一次更换都牵动评测、服务、效果验证成本非常大。我认为一个稳妥的节奏是基座模型稳定期至少一个季度除非新模型带来了明确、可复现的评测大幅提升否则不要动。调prompt和调后处理逻辑能解决的问题不要轻易换发动机。第三给自己的系统留一个降级逃生门。AI服务的典型特征是扛不住时会持续表现出奇怪状态比如超时变长、误杀率变高、置信度普遍走低。小团队没有大规模容错的资源但至少要有一个规则兜底系统检测到连续一分钟错误率超过阈值自动切换为规则提示比如内容不符合要求请调整后重试下游业务不至于完全中断。这个逃生门很粗糙但它能在最坏情况下保住服务的可用性底线。第四把一次项目当作一套可复用的能力资产。第一遍从零搭起来的过程本质上是在验证你的组织能不能交付AI系统。跑通之后数据管线能不能复用、基础服务能不能复用、评测方法能不能复用是团队效率的真正分水岭。如果每次新需求都要从数据清洗开始重来一遍那就说明工程化还远远没有到位你只是在重复地写实验脚本而不是在建立工程体系。最后说一句大实话AI工程没有银弹路线再清晰也要靠一版一版的模型、一条一条的数据、一个又一个踩过的坑慢慢拱出来。我之所以愿意写这些是因为当初自己单打独斗时太缺这样一篇文章来按图索骥了。希望这些实战中的取舍对你有一点实在的帮助。