从零开始的AI工程和写几个脚本完全是两回事。我见过太多人刚开始雄心勃勃地训练一个模型结果在数据清洗、环境迁移、部署上线的环节反复折腾最后项目烂尾。这篇内容就是我实际踩坑走通之后的总结面向那些真正想把手上的想法落地成可靠AI系统的工程师——不管你是做算法出身还是开发出身按这条路子走能帮你省掉大量试错成本。1. 从零搭建AI工程的路线图先想清楚再动手很多人一上来就急着写模型代码这是个典型的误区。AI工程的第一步永远不是选模型而是把需求拆成问题。以我的经验至少要先回答三个问题这个AI系统要解决什么核心任务是分类、生成、检索还是决策输入和输出是什么形态用户会怎么交互最坏情况下系统的错误会造成什么后果这直接决定后续测试和运维的强度。1.1 把业务需求翻译成技术指标一个常见错误是项目经理说做一个智能客服结果开发组直接开始训练对话模型到最后才发现数据根本不够。我通常的做法是先画一条链路用户提问 → 意图识别 → 知识库检索 → 答案生成 → 兜底策略。每一步都应该有明确的输入输出以及对应的评估指标。比如意图识别的准确率、检索结果的Top5命中率、生成内容的忠实度。这些指标是后续所有工作的靶子。1.2 制定MVP和迭代计划不要追求一开始就做出完美系统。我习惯的做法是先做一个最简版本拿开源预训练模型加一条固定的prompt先跑通端到端流程。这一步不是偷懒而是尽快暴露工程细节——数据格式有没有问题、接口调不通的地方在哪、响应延迟能不能接受。MVP跑通之后再开始做微调、做Agent编排、做更复杂的上下文管理。每轮迭代只改一个变量否则出了问题根本没法定位。1.3 关键决策从零训练还是站在巨人肩膀上这也是路线图里最优先要确定的点。预训练一个大规模模型需要的数据、算力和时间绝大多数团队都扛不住。更务实的方案是选择开源基座模型然后针对业务数据做指令微调或直接走提示词工程。只有当业务有极强的领域属性比如罕见专业术语多、私有知识占比高且微调无法满足时才需要考虑从领域语料继续预训练。我在项目里的判断标准是先用RAG解决知识缺失再用微调解决表达风格最后才考虑从头训练——90%的情况走完前两步就够了。2. 环境与工具链选型三个最容易忽略的配置细节AI工程的环境准备比普通后端要麻烦得多。CUDA版本、Python环境、依赖库之间的兼容性问题能卡掉新手一整天。我的建议是直接上Docker把环境和代码一起打包避免换台机器就崩溃。2.1 版本锁定的艺术requirements.txt里只写版本号远远不够。我见过的坑包括PyTorch和CUDA版本不匹配导致某些算子报错、Tokenizers库在某次更新后分词结果变了、甚至transformers强依赖的huggingface_hub悄悄升版导致缓存失效。正确的做法是锁定全量依赖推荐用uv或poetry管理生成完整锁文件。同时整个镜像里固定操作系统版本和显卡驱动版本保证生产环境和训练环境完全一致。2.2 硬件与训练粒度的匹配不是所有项目都需要A100。我的经验是只有真正做微调或大规模数据训练才需要高端GPU。如果只是跑推理、做RAG或调promptM系列芯片的Mac或一张24GB显存的显卡完全够用。另外务必提前判断梯度检查点、混合精度、模型并行这些技术在你的代码里是否开启。很多新手在小模型上跑通后直接拿大模型重跑结果显存溢出——这就是没理解训练粒度要和硬件能力对齐。2.3 实验追踪的基建从第一个实验开始就应当使用实验追踪工具。不是等实验多了才补。MLflow和wandb我都在用一个轻量一个可视化更强。关键是要养成记录的习惯数据集版本、超参数、prompt全文、模型检查点路径、评估指标每条都记。这样后期复盘时才能准确找到为什么上个月效果很好这个月突然崩了的原因——很可能是数据无意识被替换了。3. 数据管线决定系统上限的工程环节数据质量直接决定AI输出的质量这个道理大家都懂但真正把数据作为工程来管理的团队太少了。训练集、验证集、测试集的划分不是随便随机切一下就完事要考虑分布一致性和去重问题。3.1 数据收集的源头治理从业务系统里导出的原始数据通常脏得没法看空值、格式化错误、重复内容、字段语义混乱。我在做项目时会先花一整天只做一件事——看数据。不是看统计摘要而是实际抽取几十条样本逐行读。这样可以快速发现很多统计指标看不出来的问题比如某种语言的文本乱码混在中文数据里或某个类别的样本明显是模板复制的。数据治理没有银弹只能靠人工抽检和规则过滤层层递进。3.2 数据标注怎么做才不浪费标注质量是AI工程的隐形杀手。我推荐的做法先让标注员试标50条算法工程师和项目负责人一起检查确定标注规范再大规模铺开。规范里要写明边界情况怎么处理比如用户输入包含调侃语气时意图该怎么归类。同时安排抽检流程抽检比例至少10%中间发现标注一致性差就及时纠正否则后面训练出来的模型会带着标注噪声。3.3 数据集版本化把数据集做成Git那样的版本管理听起来重实则必要。DVC是常见方案。每一个版本的数据集都要记录来源、处理脚本、清洗规则、统计分布。我经常遇到的一种情况是模型训练中途需要回溯到两周前的数据版本重跑实验如果当时没有打标签就只能拍大腿了。数据版本化配合实验追踪才能保证算法的每个决策都可复现。4. 模型开发基线、调优、Agent编排的工程化模型开发不是从训练一个模型开始而是从跑一个开源基线开始。我习惯叫它占位模型——先用最快的方式让整个链路跑起来哪怕效果差一点至少可以拿到一个可用的评估值。后续所有优化都是在和这个基线作对比。4.1 制定Baseline的三步法第一步是选择一个和任务接近的开源模型比如做中文对话就选ChatGLM或Qwen这类第二步是把输入输出结构定下来包括prompt模板和后处理逻辑第三步是写一套评估脚本把测试集跑一遍得到准确率/召回率/忠实度等核心指标。这个过程应当控制在两天以内。一旦基线数值有了后面任何优化都能量化收益。4.2 提示词工程和微调的实际分工很多人纠结任务效果不好时到底是调prompt还是微调。我的经验是先用提示词把上限试出来。如果是有明确知识边界和格式要求的任务提示词少量示例就能解决大部分问题。只有当你发现模型遵循指令不稳定、输出风格与业务预期明显不符、或者领域术语出错率太高才进行微调。微调要克制先做LoRA这类参数高效微调用少量高质量数据做3-5个epoch不要一上来就全量微调。很多场景下LoRA加上精心设计的prompt效果已经足够好。4.3 Agent和最简协作模式提到AI工程绕不开Agent这个话题。做AI Agent的工程化和我最初想象的很不一样——最难的不是让模型调用工具而是设计状态流转和异常恢复。我不建议新手一上来就做复杂的多Agent编排那基本等于在管理一个很脆弱的分布式系统。更稳妥的办法是先做Single Agent加工具调用模型负责决策外部Python函数负责执行每一步的结果回填给模型作为上下文。等这条路走通了再考虑把多个Agent按规划-执行-审查这种简单管道组织起来。多Agent协作的工程难点集中在任务拆分和上下文传递越早点沉淀出状态机管理逻辑后面越省心。4.4 超参数调优的经验边界模型训练的调参严格来说不是玄学但也接近玄学。我常做的做法是固定随机种子做小规模搜索学习率、batch size、LoRA rank、微调epoch数控制在16组组合之内。再多就是浪费算力。关键是设置一个自动评估hook每个checkpoint训练完就跑到固定测试集上算指标保存最佳模型。这套流程可以自动化用GitHub Actions在GPU集群上跑把调优变成可重复执行的管道任务而不是每次手动盯着输出。5. 测试与评估别让模型裸奔上线传统软件的单元测试比较容易理解AI系统的测试难在评估标准模糊。但工程化落地必须要强制建立一套评估骨架否则上线后回出现各种诡异问题。5.1 离线评估的构建要点离线评估的核心是三个数据集训练集、验证集、测试集再加上一个专门的对抗样本集。对抗样本的作用是防止模型在简单分布上过拟合比如把提示词换一种说法、增加错别字、改变语序看模型是否还能稳定输出。评估指标根据任务不同来选择分类任务看F1生成任务看忠实度可以用LLM作为评判器也可以人工抽检检索任务看TopK命中率。建议把评估脚本固化成一个CLI命令输入模型路径和数据路径输出一份结构化报告。这样每次实验都跑同样流程才有可比性。5.2 测试里的边界和异常注入我最常踩的坑是忽略异常输入。AI系统接收的是自然语言用户不按套路出牌的概率很高。工程对策是把输入校验、长度截断、敏感内容提示、空输入兜底这些逻辑全部写进管道里。测试时除了正常用例一定要加这些边界用例。另外要模拟依赖服务超时、API限流等故障场景确保Agent系统不会因为一步失败就整个崩溃。5.3 线上评估和灰度发布离线没问题不代表线上没问题。我的做法是灰度发布先让5%流量走新模型用线上实时日志对比新旧版本的转化率、用户反馈和平均响应时长。同时接入一个影子评估任务随机截流部分的查询把新一代模型的回答和旧版一并展示给标注员打分。持续跑一周再决定是否全量发布。这样不仅验证了模型效果也验证了系统的稳定性。6. 部署与监控从POC到稳定服务的最后一公里一个跑得通的Notebook离生产系统还有很大距离。把模型封装成服务、保证推理性能、监测线上数据漂移这是AI工程落地最重要也最枯燥的环节。6.1 服务化与推理优化如果不选择托管平台我通常会选FastAPI封装模型推理接口把模型加载、预训练处理、推理、后处理都放在一个独立进程里。启动时加载模型到显存运行时只做计算。并发控制必须做否则多个请求同时推过来显存会爆或者队列延迟飙升。推理优化手段可按需选动态batch、半精度推理、把不必要的前处理挪到向量化操作里。实际项目里我真的一次性把推理吞吐提高了三倍仅仅是因为把Token化操作和模型推理并行起来。6.2 监控不只是堆指标AI系统的监控和传统系统不一样除了常规的CPU、内存、响应时间还必须盯数据和概念漂移。数据漂移指的是线上输入分布和训练分布逐渐拉开比如用户用词变了概念漂移则是任务本身的定义变了比如电商单品的类目调整。我能想到的比较实际的监控组合输入特征分布定时统计、模型置信度均值、业务核心指标如点击率、解决率。这些指标一旦超过阈值自动触发告警或切换回备用的历史模型。6.3 灰度回收与快速回滚机制上线前就要想好出问题怎么办。我习惯把新旧模型部署成两个独立服务通过网关做流量切分。这样一旦线上指标异常只需要在网关改配置就把流量切回旧模型不需要重新部署。这个机制的实现并不复杂但价值极高——它意味着你可以大胆尝试新版本而不用害怕出大事故。6.4 成本治理的一点个人心得最后想说说GPU成本。模型部署很花钱尤其是生成式模型。我常用的手段是小模型优先、量化优先、缓存优先。同一个任务能用7B绝不用34B能用INT8量化就不保留FP16用户问相同的问题直接用缓存答案命中。这三招合起来通常能省掉一半以上的推理成本而效果下降不明显。这也是我在多个项目里反复验证过的结论。AI工程从零起步真正拦住人的不是模型内部的数学原理而是把琐碎工程细节全部串联起来的能力。我自己在前面几个项目里交了不少学费现在把这些经验固定的套路化出来希望后来者能少走一段弯路。还是那句老话先把数据、测试、部署这几根地基竖起再谈模型五花八门的玩法不然它迟早会倒。