从零开始做AI工程：数据、模型、部署到稳定上线的完整路径

这两年AI相关岗位的JD像是同一个模子刻出来的要懂大模型微调、要会Agent框架、要能扛住线上流量。很多人一上来就pip install一个深度学习框架跑通一个ResNet、调用一次ChatGPT接口就觉得已经入了AI的门。可真把模型放进业务流里问题全挤在模型之外。数据脏得一塌糊涂、模型效果时好时坏、线上延迟高到没人用、规则一改整个pipeline就崩。我今天想聊的是从零开始做AI工程的那条完整路径不是教你训练某个网络而是把一个AI想法收拾成能上线、能维护、能迭代的系统。这条路其实比大多数人想的更难但也更值得走。尤其是AI大模型普及之后做AI的范围被大大拓宽了不只有算法工程师需要懂工程业务开发、测试工程师、产品经理都在用AI能力解决真实问题。如果你也想从零开始把AI真正落到自己的项目里这篇文章会把整个流程拆成可执行的七步每一部分我都结合自己实际踩过的坑来讲希望能帮你少走几个月的弯路。1. 先搞懂AI工程要解决什么问题1.1 AI研究是找上限AI工程是守下限经常有人把AI研究和AI工程混为一谈。研究的目标是探索模型能不能做到这件事比如能不能在某个benchmark上刷到新SOTA能不能生成更逼真的图片。研究者天然关注上限追求哇居然能这么强。而工程的目标完全反过来了工程要守下限。你需要回答的是这个模型在真实、嘈杂、脏乱差的数据下能不能稳定地给我一个可接受的结果。更直白一点AI工程的核心不是模型有多聪明而是这个系统在没人盯着的时候会不会自己挂掉或者给用户输出一堆胡话。我用一个生活里的类比AI研究像航天科研验证人类能不能上火星AI工程像航空运营关心每天几百个航班怎么按时到达、不出事故。同样是飞机科研飞机摔了也是一次伟大的探索商用客机摔了就是重大事故。所以如果你要做的是一次作业、一个demo那怎么折腾都行但如果你想交付一个可以给别人用的功能就得把自己切换到工程的思维上来。1.2 一套AI系统的完整形态很多刚从研究与demo转过来的人以为AI系统就是一个输入进去、结果出来的黑盒。实际上一套完整的AI工程系统至少包含这些环节数据层采集、清洗、标注、版本化保证模型吃到的每一批数据都有来源、有版本。模型层基座选择、提示词编写、微调、评测这是大部分人最熟悉的部分。推理层把模型包成接口处理并发、延迟、超时、降级。反馈层收集线上真实反馈、监控输入分布、持续发现badcase。运维层部署、日志、告警、回滚保证出问题能快速恢复。这五层只要断掉一环整个系统就转不起来。我自己见过太多项目模型做得漂漂亮亮训练出来的准确率也好看结果上线后因为数据分布一变效果马上打对折又因为没有回流机制连哪里出了问题都不知道。从零开始做AI工程本质是在建立这套闭环。别小看闭环两个字很多团队做了几年AI还在原地打转就是因为只盯着模型层其他几层全是空白。2. 从零起步需求定义与数据工程2.1 先定义输入输出别急着上模型很多人拿到需求第一反应是我去找一个模型来试试。但成熟的工程团队一定是先做一件事把模糊的业务需求翻译成清晰的输入-输出问题。比如业务方说帮我们做一个客服工单自动分诊系统。这句话听起来很清楚但落到AI工程上必须拆成输入是什么工单文本还包含用户历史是否包含截图OCR结果输出是什么一个分类标签比如退款物流账号问题还是一个结构化JSON分类体系是谁来定的业务方现有的客服分组是什么每个组有没有明确的边界判断成功的标准是什么是分诊准确率达到90%就算成功还是漏掉某一个特定类型就要命如果你问不出这些问题后面所有工作都是白做。一个真实的教训我曾经接过一个需求说要做一个自动回复助手我直接开始调Prompt结果发现业务方真正想要的是识别用户情绪并优先安排人工介入。输入输出定义完全不同之前的模型工作全废了。所以我在每个项目启动阶段都会先写一个一页纸的AI用例定义包含业务目标、输入数据样例、输出格式样例、成功指标、不允许出现的错误。这个文档和团队对齐之后才允许进入下一步。2.2 数据是AI的命根子清洗、标注、版本管理很多入门教程都忽略数据因为他们拿到的数据集已经是洗干净的。但现实世界的数据用千疮百孔来形容一点不过分。我见过工单文本里夹杂着各种口癖、错别字、表情符号乱码也见过标签体系是三个不同部门各自定义的合并以后同一类问题有三个名字。数据清洗的最低要求是去除完全无意义的内容、统一编码格式、处理缺失值。但除了清洗更关键的是标注一致性。你必须确定两个标注员对同一条数据是否给出相同标签。有一个简单指标叫标注一致性比例做法是抽出一部分样本让两个人同时标注算一下重合率。如果一致性低于80%说明你的标注规范定义得太模糊得先修订规范否则模型学到的也是混乱的东西。数据版本管理在小项目里最容易被忽略。我今天用了一批新标注的数据明天训练了一个新模型下周想复现三天前的效果发现数据不记得是哪个版本了。更稳妥的做法是每次训练的数据集都打上版本号并且把数据版本代码版本模型版本提示词版本统一记录下来这样才能做到可复现。2.3 做一个最小的数据样例设计以工单分诊为例我在项目里会这样设计数据样例从历史工单里随机抽500条。先把明显的垃圾数据过滤掉空文本、纯测试数据。和业务方一起定义标签退款、物流、账号、投诉、咨询。让两位同学分别独立标注计算一致率。规定如果两位标注结果不同由第三人仲裁。这个流程听起来很简单但实际跑下来一致率通常只有70%出头大部分分歧发生在咨询和投诉边界上。于是我们就重新定义用户主动表达负面情绪或提出质疑为投诉单纯询问进度为咨询。修改规范后的一致率立刻升到了90%以上。这就是数据工程的本质它不是技术难点而是需要你反反复复和业务对齐、细化规则、验证结果。把这一步做好后面的模型工作会轻松一半。3. 模型选型与训练调优的工程化思考3.1 大模型时代还要不要训练在今天的AI工程里很多人遇到的最大困惑是我应该用现成的大模型API还是要自己训练一个模型我一般会按照下面这个表格来决策场景推荐方案说明通用任务不涉及敏感数据现成模型API提示词成本最低迭代最快需要输出稳定结构如JSON提示词输出约束或函数调用能解决大部分问题领域术语密集通用模型效果差微调开源基础模型需要准备高质量垂直数据隐私要求高数据不能出内网内部部署开源模型兼顾效果与合规实时要求极高需要低延迟蒸馏小模型/量化模型牺牲部分效果换取速度这里我想特别强调一点绝大多数业务场景不需要微调。大模型已经具备很强的通用理解能力只要你的提示词写得合适效果往往够用。我自己见过太多人上来就微调花了两周准备数据训练完效果还不如把需求拆细一点、把提示词改得更结构化。微调有它的价值但它不是银弹它的作用是把模型的特定行为锚定住不是让模型学会常识。3.2 Prompt Engineering是窗口不是全部提示词工程Prompt Engineering可能是这两年被讨论最多的词。也有人把它吹成魔法咒语但在我看来它就是大模型交互工程的起点。你可以把提示词理解成一份工作说明书模型是那个按说明书办事的员工。说明书越清晰、越结构化员工的输出越可控。但提示词并不是全部。真实AI工程里尤其是做AI Agent智能体的时候你需要考虑的是模型如何和外部世界交互。一个完整的Agent通常会包含几个模块规划拆解任务比如帮我安排周五的会议要拆成查看日程、找空闲时间、发参会通知三个子任务。工具调用让模型调用你预先定义好的函数或接口比如calendar_book()、send_email()。记忆保存对话历史、长期偏好。反思在关键节点让模型检查自己的输出是否满足约束。举一个实际场景我想做一个邮件分类助手让它判断一封新邮件是待办事项、通知还是广告。单靠一条提示词也能做但效果不稳定。后来我调整思路让模型先输出一个JSON结构{category: ..., reason: ..., suggested_action: ...}这样我就能在后端严查category字段不合理的输出直接拒绝掉。其实质就是把模型自由度降低把边界框住。所以做提示词工程的时候不要只想着写得更好要想着如何给模型设计一个可以约束输出的上下文框架。函数调用Function Calling就是一个很好的约束方式它会强制模型按你的JSON schema吐结果极大降低解析错误率。3.3 微调的适用场景与实操步骤如果你判断下来确实需要微调比如业务术语太多、大模型老是把某个实体识别错、或者你需要一个特别小的模型部署在用户本地那么微调的工程化流程是这样的收集1000条以上高质量样本尽量覆盖所有边界情况。少于1000条微调效果通常不明显。确定基座模型。以中文场景为例通常选择Qwen、GLM、Baichuan这些开源模型注意授权协议和可商用性。定义训练格式。如果是做对话模型用Chat格式system/assistant/user如果是做抽取把输入输出组织成指令输入输出。配置超参数。业内常用的起步配置是学习率5e-6左右、epoch设3~5、batch_size根据显存调节。记住微调的第一目标不是指标而是不破坏原有能力所以学习率别贪快。训练评估。每个epoch结束都用固定的评测集测一下防止过拟合。我通常会让模型生成结果再和baseline对比保持新增能力的同时不能丢掉之前的通用能力。部署。用vLLM或SGLang起推理服务做并发和延迟验证。微调的坑里我觉得最容易被忽视的是数据重复。如果你从语料里抽出10000条里面有一半都是同一模板生成的模型会被带偏严重的时候甚至会把某个性质的样本当成万能答案。所以微调之前一定要做去重和分布检查。4. 评估与测试AI工程里最容易翻车的环节4.1 离线评测集怎么建很多AI项目翻车不是因为模型不行而是因为压根没有定义什么算行。训练时看着loss在下降就以为万事大吉这是典型的研究思维工程思维要求你拿着评测集狠狠去测。离线评测集要注意三点覆盖面、难度、更新频率。覆盖面指评测集要包含真实业务中常见的各种输入变体。比如你做简历信息抽取不能全是排版规整的PDF简历还得有手机拍摄的照片、有一行文字说明、有中英混杂的版本。难度是指故意塞进一些badcase看看模型能不能抗住。更新频率则是说评测集不能一成不变每两周要补充新出现的case进去。以简历信息抽取为例我会准备两个评测集主评测集100份标注好的简历覆盖各种排版用于每次迭代后跑分。对抗评测集20份异常简历比如没有姓名、有多个电话号、千奇百怪的日期格式专门用来测试模型会不会乱编。4.2 线上指标怎么盯评测集做得再好也只是离线视角。上线之后必须换一套线上指标体系。我见过的常见误区是只盯着模型准确率但业务部门根本不关心准确率他们关心的是客服接起率用户满意度工单处理时长。正确的做法是把业务指标和模型指标串起来。还是工单分诊的例子你可以建立这样的监控链路模型输入特征工单文本长度、关键词分布、分类结果的置信度。模型输出分布每个预测类别的占比是否稳定。业务结果分诊后的工单转发时间、用户是否有二次吐槽。一旦发现输出分布突然偏离历史基线比如之前退款类占比一直是10%今天突然变成40%那极有可能出现了数据漂移或者上游业务调整了入口。这个信号能让你比用户更早发现异常。4.3 回归测试与数据漂移这里我要单独强调回归测试。传统软件工程里回归测试是指改代码后跑一遍老用例确保旧功能没坏。AI项目里同样需要但很多人不做。你改了提示词加了几个example结果原来能处理的case开始出错这种情况太常见了。我的习惯是任何一次模型相关的改动不管是换Prompt、加微调、换基座都必须跑一遍完整的主评测集并且把评测结果记录下来。同时准备一个红线集里面放上绝对不允许错的高优先级场景比如识别身份证号时不能漏数字、无法确定情绪时不能强行安抚。只要红线集里有一个过不了前面就算发散到天上也不能上线。数据漂移监控则是更长期的事。线上用户输入内容的口径总在变去年大家投诉快递不派送今年都在投诉价格不一致。要捕捉这种变化最简单的办法是持续统计输入文本的关键词频率做周期性对比。我给很多项目设计过漂移告警阈值一般设置为某一类关键词频率周同比增长超过2倍就发邮件提醒。这套机制拯救过我好几次都是赶在大规模badcase爆掉之前就调整了方案。5. 部署上线与持续迭代5.1 从Notebook到服务的距离机器学习工程师最大的通病是拿Notebook当生产环境。本地跑出来一个漂亮的输出然后拿给后端说你帮我接一下。抱歉这个接口如果不考虑以下这些事上线必挂启动速度大模型加载动辄几十秒需要预热后才接流量。并发控制显存/内存够支撑多少个同时请求要不要做排队。延迟要求用户能等多久如果是异步任务可以宽松处理如果是实时交互就需要优化。失败降级模型超时了是返回默认回复还是转人工还是让用户重试以部署一个文本分类模型为例最朴素的工程做法是把模型封装成一个Python类暴露一个predict(text)方法。用FastAPI起一个HTTP服务路由是 /predict请求体是 {text: ...}响应体是 {label: 退款, confidence: 0.9}。加一个健康检查接口 /health。在服务外面套一层线程池或信号量防止并发把服务打垮。在反向代理层设置超时时间比如5秒超过就触发降级逻辑。很多开发者觉得这些步骤是脏活累活但恰恰是这些业务后端同学能看得懂、能接得住的工程化细节决定了一个模型能否真正落地。5.2 版本化与回滚模型上线不是训练完就完事而是要像管理代码一样管理版本。我所在的项目现在有三个版本号model_v20250601表示模型的训练数据截止日期prompt_v12表示提示词的第几轮迭代app_v3.2.1表示整个服务的代码版本。为什么要这么细致因为线上出了问题你需要能在十分钟内定位是哪个改动导致的。假设切换模型后准确率下降如果没有版本记录你可能花了三天才发现是数据分布变了而不是模型变笨了。回滚机制同样重要。最简单的做法是线上同时部署两个版本的模型服务通过路由层的流量权重来控制新旧版本的比例。先让新版本承担5%的流量观察业务指标稳定后再放大到50%、100%。一旦发现异动把流量切回老版本。这比直接替换部署要安全得多也是A/B测试的基础。5.3 成本与延迟的平衡很多人忽略AI工程的持续性成本。大模型API按tokens计费开源模型按GPU租用计费。我没有办法拍脑袋说一定要怎么选但可以分享一套成本决策思路先量化请求量猜一个日请求量比如10万次。估算单次成本如果是大模型API按平均输出长度计算如果是自部署GPU按请求处理效率折算。再考虑用户体验如果业务容忍2秒延迟就可以用批量推理把多个请求合并成一个GPU batch成本能降一大截如果要求200毫秒响应就得考虑小模型、量化、缓存。我最近做的一个电商客服问答项目一开始用最大的参数模型延迟高、费用贵。后来我加了一层缓存相同或高度相似的问句直接返回历史答案命中率有40%。就这么一个改动成本直接降了三分之一。所以做AI工程别一味追求聪明还要追求恰到好处的聪明。6. 一个完整的最小案例做一个简历关键信息提取工具6.1 目标与数据定义理论说了这么多我干脆用一个最小可复现的案例把整个流程串起来。假设我们要做一个简历关键信息提取工具从一段纯文本简历里提取姓名、联系电话、邮箱和掌握技能。业务定义是输入一段简历文本可以是从PDF、Word里抽出来的纯文本。输出JSON格式包括name、phone、email、skills数组。成功标准四个字段的准确率都大于95%并且不出现任何编造的信息。为了评估我开始收集了20份真实简历脱敏处理并人工标注好了正确提取结果。这20份简历里包含了各种花样有的没有邮箱、有的手机号是分段的、有的技能写了十几个还有的没有电话。这些花样本正是为了测试模型的鲁棒性。6.2 提示词与函数调用我使用一个大语言模型的函数调用能力先定义一个结构化输出schema再让模型按schema输出。示例提示词如下你是简历信息提取助手。从用户提供的简历文本中提取以下字段 - name人名如果文本中没有明确人名则输出空字符串 - phone11位手机号或座机号只保留数字和- - email邮箱地址如果没有则输出空字符串 - skills技能关键词列表最多列出5个 请调用 extract_resume 函数返回结果不要输出任何多余解释。配合后端定义函数def extract_resume(text: str) - dict: return { name: , phone: , email: , skills: [] }在真实代码里我们会把这段提示词传给模型的function calling接口让它返回一个结构化的函数参数。这里有一个容易被忽略的地方提示词里的如果缺失则输出空字符串是必须写的。如果不写模型倾向于硬编一个假的信息填进去这是信息抽取里最可怕的幻觉问题。6.3 评测与迭代闭环接下来在20份简历上跑一轮评测。我先写一个简单的评测脚本import json def exact_match(gold: dict, pred: dict) - dict: result {} for field in [name, phone, email, skills]: g gold.get(field) p pred.get(field) if isinstance(g, list): result[field] set(g) set(p) else: result[field] (g p) return result第一次跑下来的结果四个字段里skills匹配率只有60%其他字段还不错。我抽了几条错误案例来看发现模型把精通Python、Java、熟悉MySQL、Linux里熟悉后面的内容当成技能了还多抽了Linux。问题不在模型而在提示词里没有明确定义技能是精通/熟悉/了解都算还是只算精通。于是我把提示词改为技能指该候选人熟练掌握的技术包括精通、熟悉、掌握普通了解不列入。重新跑一轮skills准确率直接升到95%。这个例子就是想说明AI工程的迭代核心是评测-定位-调整的循环。每次只改一个变量然后评估有没有变好。而不是一次把所有提示词、模型、参数全换了然后看运气。7. 踩坑记录与实战心得7.1 常见问题速查表为了让你少走弯路我把这几年在AI工程里最常撞见的问题整理成一张速查表现象可能原因解决思路模型输出全都不符合格式提示词缺少严格约束使用函数调用或JSON schema来锁死输出结构线上效果和测试时差距大线上输入分布与训练数据不一致建立线上数据抽样回流持续对比分布成本飙升每个请求都白白调用重模型增加缓存、用小模型做前置筛选、降级策略模型偶尔回复乱码/幻觉缺乏约束和拒绝机制在提示词中明确不知道就回答不知道微调后通用能力倒退微调数据单一、学习率过大冻结基座参数用低学习率混入通用语料并发一高服务就挂没有限流和排队设计增加连接池、服务降级、消息队列异步化数据更新后模型变差数据版本混乱没记录统一数据版本管理每次训练记录数据快照另外还有一句经验如果模型输出不对先怀疑数据再怀疑提示词最后才怀疑模型本身。现场排查时按这个顺序来往往能帮你省一半的调试时间。7.2 我给新人的几条建议除了上面这些方法论最后再分享几条比较软的心得都是我实际带新人时反复强调的东西。第一别追逐所有新概念。这两年AI圈每个月都有新词Agent、RAG、多模态、AI原生。有几个是真正适合你现在项目的我见过一个小团队为了炫技引入了一整套Agent编排框架结果业务只需要一个分类器最后项目延期了两个月。基础打牢比学一百个花架子更有用。第二一定要给自己建一个实验日志。每次改动无论改提示词还是换模型都要记录意图、做法、评测结果。不记日志过两周你自己都说不清当时为什么这么做。这个习惯极大减少重复劳动。第三主动接脏活。很多刚入行的朋友觉得数据处理、流程部署不是AI的核心不愿意做。但AI工程恰恰是脏活驱动的你处理的数据越深越能理解模型的边界在哪里。我在做简历抽取这个项目时最花时间的不是调模型而是把那20份简历里乱七八糟的格式整理成可用评测集。等到模型上线后遇到各种badcase我最先反应过来的就是这些格式问题。最后永远记住AI工程的成功标准不是模型有多厉害而是它有没有稳定地为业务创造价值。很多时候我已经调试到凌晨全部原因是某一段输入文本里的转义符没有处理好。正因为一次次见过这些和模型无关的坑我才对AI工程这四个字格外敬畏。如果你也正打算从零开始做一个AI项目希望这篇文章能帮你把散落在各处的知识点串起来扎扎实实从数据、模型、评估、部署一路走到稳定的系统。这条路没有捷径但每一步都踩实的人走得更远。