上周一个朋友拿着一个含糊到没法落地的需求来找我“帮我做一个AI客服能自动回复用户就行。”我问他数据在哪回答不好怎么算模型跑挂了找谁他全没想过。这大概是“从零开始做AI工程”最真实的起点了——所有人都在聊模型效果但真正让一个AI功能稳定跑起来的是模型之外那套完整的数据、训练、评估、部署、监控和迭代体系。这篇博文我就围绕“ai-engineering-from-scratch”这个主题完整复盘一套从0到1构建AI工程项目的全链路打法覆盖AI模型部署、prompt engineering、AI Agent编排、效果评估这些核心环节。无论你是想独立做项目的工程师还是刚接触AI的技术负责人照着这条路线走至少能少踩六成我当年踩过的坑。1. 整体设计与思路拆解1.1 AI工程到底是什么先把一个误区说透AI工程不是“跑通一个模型”。很多新手以为训练完模型、调通接口就算完事但真实的生产环境里模型只是链条上的一环。数据怎么持续供给、版本怎么管理、线上效果退化了怎么发现、模型答错时系统怎么兜底——这些才是工程的主体。我常用一个类比模型像发动机AI工程是整车。发动机再猛没有油箱、变速箱、刹车和仪表盘它连小区门口都开不出去。数据管道就是油箱推理优化是变速箱兜底策略是刹车监控告警是仪表盘。所以“从零开始做AI工程”本质上是在造一辆能上路、能保养、能维修的车而不是在实验室里点火听个响。也正因为如此AI工程要比传统软件开发多一层不确定性传统软件的逻辑是可预期的而模型行为在训练完成前无法完全预知。这要求工程方法从“一次性交付”转向“基线-优化-迭代”的循环思维。你不可能一开始就做到完美但你可以一开始就设计好“如何知道自己正在变好”。1.2 从零开始的核心顺序我反复推演过好几条路线最后收敛成一套相对稳妥的“六步走”需求边界 → 数据基线 → 模型选型 → 训练/微调 → 部署上线 → 评估迭代。顺序绝不能乱。先定需求边界是为了避免“什么都想做但什么都做不深”。做AI和做人一样最重要的是知道自己不做什么。一个客服系统你非要它同时处理售后、营销、闲聊那数据集会被撕成碎片模型效果必然稀烂。我会在下一节展开怎么把模糊需求拆成可验证的子任务。定了边界再做数据基线是为了在投入训练成本之前先用规则或提示词跑一个最简陋的版本看看数据分布是否支持你的预期。这一步非常关键很多人跳过它直接上模型微调结果发现输入数据本身质量极差再好的模型也白搭。然后是模型选型判断是调用现成API、微调开源模型还是干脆训练小模型取决于任务复杂度、数据规模和延迟预算。再往后是训练与微调、部署上线最后是靠评估迭代形成闭环。整个顺序的核心逻辑只有一个用最便宜的方式验证风险最大的假设。1.3 为什么不要一上来就选大模型这里必须泼一盆冷水大模型不是万能解药。我见过太多项目需求明明用几百条正则规则就能覆盖非要上大模型API结果延迟高、成本高、输出还不稳定也见过连1000条干净样本都没有就想全参微调13B模型最后除了过拟合什么都没得到。选不选大模型我给自己定了一个判断矩阵场景特征推荐路线单一分类/抽取样本量小规则或小模型优先语义理解要求高开放问答大模型API或开源大模型数据量大且领域性强开源模型做参数高效微调强实时低延迟交互小模型量化 规则兜底知识密集型内容大模型 检索增强RAG打个比方搬家不是非得雇集装箱卡车。搬几件行李叫辆出租车就够了只有搬整套家具才需要大车。大模型就是那辆集装箱卡车——载重强、油耗也高。你如果只是要“判断用户情绪正负”一个千行级参数的小模型或一套规则可能比调用几百亿参数的大模型更快、更省、更可控。这就是为什么“从零开始”的第一步不是选模型而是想清楚你到底需要多大的“运输能力”。2. 需求定义与数据工程实操2.1 把业务需求翻译成可评估问题“智能客服能帮我回答问题”这种描述直接当成机器学习任务来做大概率会翻车。因为它没有定义清楚什么算“回答得好”哪些问题必须回答哪些问题不该回答我习惯的做法是把这类模糊需求拆解成三个层次一是意图识别。用户进来先判断他到底想干嘛是“查订单”“问物流”还是“申请退款”这是一个分类任务可以用标注样本喂一个文本分类模型或大模型来做。二是检索回答。对于“你们发货多久到”“怎么退换货”这类标准化问题可以走FAQ检索从已有的问答对里找答案而不是让模型自由发挥。三是兜底转人工。当模型置信度低或问题是敏感投诉时系统必须能判断“我搞不定”并把会话转给真人而不是硬着头皮编答案。完成拆分后每个子任务都要有可量化的指标。意图识别看准确率和召回率FAQ检索看Top-3命中率兜底转人工看的是“误转率”和“漏转率”。有了指标之后“效果变好了”就不再是一句空话而是“意图识别准确率从82%提到91%”这样可验证的事实。这一步的产出物是一份一页纸的需求定义文档里面包含任务边界、评估指标、可接受的最低表现、以及明确不做什么。我建议所有从零开始的项目都先写这份文档它会在后续所有决策里帮你挡住无数诱惑。2.2 数据采集与清洗的四个原则数据工程是整个链路里最枯燥但最重要的一环。模型再强也扛不住“输入垃圾输出垃圾”。我践行的四个原则是最大程度贴近真实分布、保证标注口径一致、剔除低质量和敏感样本、给数据做版本管理。先说真实分布。很多团队喜欢从网上找现成数据集但这会导致严重的分布偏移——训练数据是电商评论实际线上来的却全是物流咨询效果自然崩盘。最靠谱的样本来源是历史工单、客服聊天记录和后台搜索日志没有历史数据时可以用小范围灰度收集真实输入再人工清洗标注建立一个最小的冷启动样本集。再说标注口径一致。同样是“用户骂了一句脏话”一个标注员标成“负面情绪”另一个标成“投诉”模型就会学到错误边界。清洗样本时尤其要注意有明显个人隐私信息的内容必须在源头脱敏后再进入数据集无意义的灌水消息、乱码、重复刷屏也应该直接剔除否则模型会被这类噪声带偏。最后是版本管理我习惯给每批数据打上版本号和统计摘要样本总量、类别分布、来源时段方便后续排查“为什么这版模型变蠢了”这类问题。2.3 数据标注与增强的实际操作标注规范是数据质量的护城河。以“用户意图三分类”为例我会写一份简单的标注手册里面明确每个类别的定义、边界案例和特殊规则。比如“查订单”类的要点是用户提到了订单编号或物流状态“退款”类的要点是出现“退”“款”“钱”等关键词或语义而两者同时出现时优先标“退款”——为什么因为退款是高优先级动作宁可多转也不漏接。如果你需要几十个人协作标注我建议至少做两件事一是在标注完成后抽10%的样本做二次校验计算标注一致性二是定期把标注员之间的分歧样本汇总成一份“疑难案例集”在评审会上讨论。别以为这些动作浪费时间我一个项目里最大的效果提升不是来自换模型而是来自把标注口径重新统一之后数据质量的提升。数据增强方面对于分类和抽取任务同义词替换、随机删除少量词、回译中→英→中都能扩大样本量。但我要提醒一句谨慎生产环境中过度增强会引入语义漂移。比如把“我要退货”回译成“我将要把购买的商品退回”虽然意思接近但句式风格已经偏离真实用户说话方式了。我现在的习惯是增强数据占比不超过训练集的20%且增强样本只作为辅助绝不让它们掩盖真实分布的不足。3. 模型选型与训练微调3.1 三类路线从头训练、微调、提示工程在数据准备好了之后才轮到模型这一步。我梳理了三类路线它们分别对应不同的投入产出比路线所需数据量成本适用场景从头预训练百亿级token以上极高几乎只有大厂或科研机构选择全参微调/参数高效微调数千到数十万样本中领域性强、输出格式固定、需要私有化提示工程/上下文学习几十到几百示例低快速验证、样本少、需求灵活绝大多数“从零开始”的项目最优解其实是第三条路起步第二条路提效第一条路基本不用想。你就算有10亿token的领域语料也没有几百张显卡的算力预算来完成一次从头预训练这个账每个人都会算。为什么要按这个顺序走因为风险是递增的成本也是递增的。先用提示工程验证“模型本身能不能理解这个任务”如果连让模型看几个示例都做不对那问题大概率出在数据或任务定义上而不是训练得不够多。等提示工程跑通、拿到了第一批真实调用日志再决定是否要用这些高质量数据做参数高效微调。这个“先提示、后微调”的顺序能帮你省下大量无效训练成本。3.2 微调实操数据准备、超参与显存估算假如你已经决定走微调路线我们从数据格式开始。指令微调最常用的格式是{ instruction: 请判断用户的意图只输出查订单/退款/其他, input: 我的快递两天没动静了什么时候能送到, output: 查订单 }训练时把instruction和input拼成用户侧文本output作为标准答案。这里有个容易踩的坑别把标答混进输入侧否则模型会学到“抄答案”而不是“学推理”。微调方式上我不建议一上来就全参微调优先考虑LoRA或QLoRA这类参数高效微调方法。LoRA只训练一小部分低秩矩阵显存占用低、效果在很多场景接近全参微调。以7B模型为例全参微调在16GB显存的显卡上基本就是奢望而LoRA可以把单卡训练跑下来。我常用的LoRA关键参数是rank8到16训练3到5个epoch学习率取1e-4到2e-4先用一个小数据集跑通流程再逐步加数据。显存怎么估算核心公式是模型权重占用 优化器状态占用 激活值占用。用AdamW优化器训练时每个参数会额外占8字节左右的优化器状态一阶动量加二阶动量梯度又占4字节。简单算下来一个7B模型的全参训练光是权重、梯度和优化器状态就可能超过100GB而LoRA的量化版QLoRA能把训练显存压到10GB以内。这就是我强烈推荐LoRA的原因。3.3 评估集设计别让模型“作弊”任何时候都不要用训练集来评估模型这句话我讲了无数次还是不断有人踩。更隐蔽的问题是很多团队把爬来的同一批数据既做验证集又做训练集导致模型“记住”了答案而不是“学会”了能力线上表现一落千丈。我建议至少在项目启动时单独留存一份“封印”测试集覆盖尽量多样的真实输入场景整条链路跑通之前绝不碰它。评估时不要只看一个综合指标要按子类别拆开看。比如意图识别任务分别计算“退款类”的召回率和“闲聊类”的误召回率因为这两类错误的代价完全不同。漏掉一个退款申请可能导致客诉升级而把闲聊当成业务问题只会多消耗一点资源。这种代价不对称光看总准确率根本反映不出来。大模型场景下还可以用“LLM-as-judge”的方式做辅助评估——用一个更强的模型给答案打分。但要注意这个裁判本身也可能有偏置所以关键样本上还是需要人工复核。评估集不是一次性工具它应该随着线上真实数据回流定期更新防止模型的“舒适区”和真实世界脱节。4. 部署上线与推理优化4.1 选型推理服务自建还是调API模型训练完接下来就是AI模型部署。这里先做选择题推理能力是自建还是买现成的对比项自建推理服务调用现成API成本前期基建投入高按量付费起步低数据私密性数据不出内网数据要交给第三方可控性可深度定制优化受限于厂商能力运维负担需要算法和运维人力几乎为零效果天花板取决于模型与优化通常较强且更新快如果需求是实时客服、数据敏感、需要完全离线部署那自建几乎是必选项。自建方案里我常用的推理框架有vLLM、Text Generation InferenceTGI和Ollama。vLLM胜在高吞吐它实现了连续的动态批处理能把GPU利用率拉得很高Ollama胜在简单本地调试和内部工具用起来很舒服。部署之后立刻要关注的是吞吐量和延迟的关系。单张A100显卡部署7B模型理论并发并不等于实际并发因为显存里除了模型权重还要装每个请求的KV Cache。这个计算很实在输入输出token越多KV Cache占用越大。所以做服务时必须给单请求的max_tokens设上限否则一个超长输出请求就可能吃光整卡内存拖垮所有其他请求。4.2 量化与推理加速的基础知识想要在更便宜的显卡上跑更大的模型第一个想到的应该是量化。FP16转INT8模型体积直接减半显存占用下降明显推理速度通常也会提升。但量化不是没代价精度会有些许损失尤其是对敏感的小任务可能从“可靠”跌到“偶尔出错”。我的建议是先跑FP16版本确定正确性没问题后再用INT8或BF16做优化对比确保关键指标下降在可接受范围以内。除了量化连续批处理continuous batching是现代推理框架的标配能力。以“等一班车坐满才发车”来类比传统批处理连续批处理则是“边发车边让新乘客上车”——一个请求跑完了立刻把位置让给排队的下一个请求GPU的每一块算力都被尽量填满。选择vLLM这类框架就是因为它们把这套机制内置了。至于投机解码等更进阶的加速手段可以后置到优化阶段再研究第一版能稳定跑起来比什么都重要。4.3 工程架构不止是一个接口自建推理服务后你很快会发现对外暴露一个模型接口是远远不够的。我推荐一个分层架构从上到下依次是接入层、路由层、推理层、存储层。接入层负责鉴权、限流和统一日志这层决定了你能不能在出问题时迅速定位到“谁在什么时间调了什么参数”。路由层做更细的决策哪些请求走规则引擎哪些走小模型哪些走大模型哪些直接转人工——这套决策逻辑才是AI产品的核心业务代码。推理层就是真实的模型服务需要做到多副本部署、自动扩容。存储层记录每一次请求的输入、输出、打分、耗时和用户反馈这些数据是后续迭代的生命线。别小看这层架构设计没有路由层和存储层你的模型就只是一个无法持续优化的黑盒子。我在早期项目里偷懒省略过存储层后来线上效果劣化时拿不出任何可分析的数据只能靠猜那是整条链路里最被动的时刻。5. 评估迭代与Agent工程实践5.1 线上效果怎么衡量离线评估再漂亮也不等于线上收益。我见过太多模型在测试集上刷到99%上线后用户却大量投诉原因就是离线评估无法覆盖真实交互中千奇百怪的输入。所以线上效果必须单独设一套衡量体系。第一种方式是小流量AB实验。把用户请求随机分流到新旧两个模型比较用户行为指标比如问题解决率、转人工率、用户主动终止率。这里有个细节模型指标和业务指标要分开看。模型准确率升了但转人工率没降说明你优化的方向可能根本不在用户痛点上。第二种方式是抽样人工审计。我要求运营或产品同学每周随机抽50条真实对话人工打标“好/中/差”这比任何自动指标都更接近真实体验。第三种是让用户反馈回流。页面上的点赞/点踩按钮客服会话结束后的满意度评分是成本最低的标注来源。这些反馈数据必须进入数据管道成为下一版训练集的养料。5.2 把“从零开始”延伸到Agent应用现在的AI工程很难绕开AI Agent。一个Agent的本质很简单模型负责理解和决策工具负责执行记忆负责跨轮上下文编排逻辑负责把这些串起来。用一个智能客服Agent示例来说当用户问“我前天买的鞋子到哪了”编排流程是这样的先由意图识别模块判断这是“查物流”然后调用订单查询工具拿到物流单号再检索物流API得到轨迹信息最后让语言模型用自然语言把结果组织成一句友好回复。整个过程里模型没有直接拍脑袋生成答案而是基于工具返回的真实数据来回答。构建Agent时最有价值的设计是把工具调用结果和模型生成的答案分开记录。一旦出现问题你可以分清到底是工具返回的数据错了、模型理解错了还是编排逻辑错了。我见过很多项目在Agent出bug时互相甩锅最后打开日志才发现是上游接口超时。没有清晰的边界和日志这种排查几乎不可能。5.3 Prompt工作流与多Agent协作Prompt engineering在Agent应用里依然扮演着核心角色。一个生产级prompt不只是“请帮我写个文案”这么简单它需要包含角色设定、任务目标、输入字段限制、示例输出、禁忌行为。我通常会在prompt里强制模型输出JSON结构方便程序解析并在失败时走重试或规则兜底。千万别让模型输出一段自由文本然后靠正则去猜那会把你逼疯。多Agent协作是现在很热的方向比如让一个Agent当规划者拆解任务、一个Agent当执行者调用工具、一个Agent当审查者检查结果。我的经验是先别急着上多Agent每一步之间都传递不可靠的文本错误会被逐级放大。更稳的打法是先用单Agent把单个任务的准确率做到95%以上再考虑把多个单Agent串起来做流水线。如果一定要上多Agent务必给每个子任务设置独立的验收标准而不是只看最终输出。6. 常见问题与经验快查6.1 高频踩坑清单这几年来我把最容易反复出现的坑整理成了一张速查表每次项目复盘都会对照一次现象根因对策测试集效果很好线上很差测试集与真实分布偏移从真实日志中采样子集构建测试集模型越训越差数据泄露或增强过度隔离“封印”测试集控制增强比例同一输入多次输出不一致采样参数太高线上调低temperature或加规则固定输出GPU显存OOM没算KV Cache和批处理峰值限制max_tokens使用动态批处理成本一周内翻倍没有限流和缓存接入层加配额和相似请求缓存模型答非所问后无感知缺少监控告警设置回答置信度阈值和人工抽样审计数据回流断掉日志没存或字段不全在存储层强制记录输入输出、耗时、评分6.2 我的三个小经验第一个经验是先做一个笨方案再谈智能。我做过一个需求分析项目第一版用20条正则规则跑起来效果虽然粗但让业务方看到了完整的交互链路后来换成模型才有一模一样的产品流程做对照。没有笨方案做基准你压根说不清楚“模型比规则好在哪里”。第二个经验是日志和数据回流是整个项目最重要的投资。我刚做AI时觉得模型、算法才是难点直到线上出了问题却翻不出有效日志才明白没有数据闭环的AI项目就像一个没有后视镜的车。现在我写接口时第一个需求永远是“把每次请求的输入、输出、性能指标原样留一份”。第三个经验是上线之前先写好降级方案。模型不可能永远稳定API也一定会超时。你的系统必须能在模型不可用时自动切换到规则兜底或直接转人工。很多项目只盯着模型指标却忘了给服务设计逃生通道结果每次模型抖动都变成一次事故。6.3 首个项目规模怎么定从零开始做AI工程我特别不建议第一个项目就选高难度、高风险的开放域任务。最理想的项目有三个特征范围小、可量化、无致命后果。比如“工单自动分类”“相似问题去重”“文档摘要生成”这类任务失败成本低、评估路径清晰很适合练手。等你完整跑过一遍需求定义、数据构建、模型微调、部署监控、迭代回流的闭环再挑战咨询客服、Agent编排、实时对话这些高复杂度场景心态和方法都会从容很多。我个人在实际操作中的体会是AI工程从零到一的真正难点从来不在于某一个算法的精妙而在于你能不能把数据、模型、部署、评估、迭代这五个环节做成一个互相咬合的飞轮。模型可以换、框架可以换但飞轮的每一环都得转起来。这个项目后续还可以这样扩展如果你已经顺利跑通了单模型的闭环下一步可以试着把两个Agent串联起来做更复杂的业务流程如果你在微调中积累了高质量领域数据还可以把这些数据顺着回流管道沉淀成一套专属评估集让每次模型迭代都有一把更精准的尺子。先在一个小范围里把飞轮转到顺再谈更大的野心。