从零开始做AI工程：数据治理、模型微调、评测部署全链路实战指南

最近一年多身边不少朋友都在聊“AI工程师”这个岗位但聊下来发现大家理解差别挺大。有人觉得AI工程师就是调库跑模型有人以为是复现论文还有人把算法工程师和AI工程师混成一谈。我自己从算法研究转向工程化落地这两年踩了不少坑也慢慢整理出一套“从零开始做AI工程”的方法论。这个主题我用“ai-engineering-from-scratch”来概括意思是抛开花哨的概念把模型训练、数据治理、评测迭代、部署监控这条链路老老实实跑通。这篇文章就把我实际走过的路径、用到的工具、以及那些文档里不会写的坑一次讲清楚。1. 先想清楚AI工程到底在解决什么问题1.1 算法研究和AI工程不是一回事很多人误以为AI工程的核心是模型算法其实恰恰相反。算法研究的目标是探索模型能力的上限比如在某个benchmark上把指标再推高0.5个点而AI工程的目标是把模型放进真实业务里稳定运行保证准确率不抖、延迟可控、数据流不中断、出问题能快速定位。我习惯用一个类比算法研究员是造概念车的追求极限速度和创新结构AI工程师是造量产车的要关心油耗、安全性、维修便利性、极端天气下的表现。概念车可以天天上头条但路上跑的还是量产车。AI工程就是搞定“量产”这回事数据够不够干净、训练能不能复现、推理扛不扛得住流量、模型几个月后还灵不灵。从零入门的人如果一开始就扎进Transformer架构、损失函数推导里很容易迷失方向。更务实的路径是先理解AI工程的全貌再针对薄弱环节逐个补齐。1.2 AI工程师的四项核心能力以我个人的招聘和带人经验一个合格的AI工程师通常需要四项核心能力缺哪块都会在实践中吃苦头第一是数据工程能力。很多人以为数据就是“收集起来丢给模型”实际上一个真实项目里数据清洗、去重、标注规范、类别平衡、版本管理占掉的时间往往超过60%。处理不好数据后面的模型再花哨也是白搭。第二是模型训练与调优能力。这里不是指从零手写神经网络而是熟练使用PyTorch、Hugging Face生态理解训练脚本里的关键参数学习率、批次大小、序列长度、梯度累积能用LoRA这类参数高效微调方法快速迭代知道Loss异常时该往哪个方向排查。第三是推理与部署能力。模型训出来只是开始要把它变成一个接口服务需要考虑推理延迟、吞吐、显存占用、量化精度损失、并发控制、灰度发布。这是一整套系统工程很多从研究转过来的同学在这里最不适应。第四是评测与持续迭代能力。没有评测体系模型好不好全靠感觉这在大项目里是灾难。合格的AI工程师会建设一套离线评测集加线上监控指标每次改模型都能量化对比涨跌。1.3 一个真实的项目画像我近期带团队做了一个客服工单分类与摘要生成项目预算不大、周期三个月典型的中型AI工程任务。具体要做的事情包括从历史工单里清洗出有效数据、设计分类标签体系、微调一个文本分类模型、用大模型生成工单摘要、上线一个可供业务方调用的HTTP接口、再配一套监控报表。这个项目几乎涵盖了AI工程的全部环节。后面讲的内容我都会拿这个项目作为例子展开方便你理解每个环节里“为什么这么做”以及“怎么做”。2. 技术栈选型够用优先别一上来就追新2.1 编程语言与深度学习框架Python没什么争议AI生态里最全的工具链都围绕它AI工程师至少要能达到“熟练写工程化Python”的水平不光是写Notebook而是会写模块、会处理异常、会写单元测试。我自己一般用FastAPI写推理服务用Pydantic做参数校验这块Python的成熟度远超其他语言。深度学习框架首选PyTorch。它占市场主流地位Hugging Face Transformers、PEFT、DeepSpeed这些上层工具默认优先支持PyTorch社区问答覆盖也最广。TensorFlow目前更多出现在一些老旧的工业场景里新项目不太建议再踩进去了。LLM相关的入门组合我个人很推荐Transformers做模型加载和推理PEFT做LoRA微调配合bitsandbytes做量化加载。如果你要训更大的模型再上DeepSpeed。这套组合不追求炫技但覆盖了从微调到推理的完整链路文档也全遇到奇怪的报错基本都能搜到答案。2.2 数据与实验管理工具数据层面pandas用于中小规模数据清洗如果数据量大到内存放不下可以用polars或者Dask。我个人在客服工单项目里直接用pandas就够了几十万条文本数据完全无压力。特征存储这类重量级方案等数据量到千万级别再考虑。实验管理我推荐MLflow它做了三件事记录每次实验的参数和指标、管理模型版本、提供模型注册功能。从零开始的团队不需要自己写实验记录脚本用现成工具能省很多时间。工作流调度方面项目早期用cron加Shell脚本就能跑等任务复杂了再上Airflow或Prefect。很多团队一上来就搭Airflow结果调度任务没几个维护成本倒是先上去了。2.3 推理部署工具推理服务这块我见过几种路线直接用Transformers加载模型再包一层FastAPI适合流量小的内部工具用vLLM做LLM推理吞吐量高且支持Continuous Batching用Triton Inference Server做生产级部署支持多模型管理、动态批处理和GPU资源调度。如果是团队第一个AI项目量级不大我的建议是先走FastAPI加Transformers的组合把链路跑通再说。之后再视流量情况迁移到vLLM或者Triton。搞清楚为什么需要并发控制、为什么要量化比盲目上一套重工具重要得多。Docker是必须掌握的模型依赖的Python包版本特别敏感不容器化的话换个机器可能就跑不起来了。3. 从零到一的完整落地路径3.1 数据优先先把数据治理做明白数据环节是整个AI工程里最不性感但最要命的部分。客服工单项目启动时我们从业务系统里导出了大约80万条历史工单但真正能用于训练的在清洗后只剩不到30万条沉默成本全在脏数据上。我的标准数据处理流程分四步。第一步是格式清洗包括去除HTML标签、统一全半角符号、修正OCR乱码、过滤掉只有“你好”这类无意义内容的对话。第二步是去重文本相似度去重可以用SimHash或者MinHash简单场景下直接对字符集合做Jaccard相似度也能解决去掉重复工单能显著降低模型过拟合风险。第三步是脱敏客服工单里有大量手机号、地址、姓名这类信息要用正则规则识别并替换成占位符既是合规要求也避免模型死记硬背个人信息。第四步是质量过滤比如长度低于5个字符的工单直接删掉因为这些文本没有足够语义信息。数据标注建议做成“预标注加人工修正”的方式先用一个粗糙的规则模型打底再让标注员改错比从零手标效率高出不少。标注规范的编写很关键需要把每个分类的边界案例写清楚比如“退款申请”和“退款投诉”的区分标准是什么。我当时花了一周时间写标注规范真正标注时返工率低了很多。数据版本管理也是很容易被忽略的环节。数据集文件不是放在硬盘里就完事了我推荐用DVC管理数据版本让每轮训练都可以追溯到具体的数据集快照。没有这步等出了问题想查“这个模型当时是用哪批数据训的”你只能抓瞎。3.2 模型选型与微调策略基座模型的选择直接决定后面所有工作的复杂度。我的选型逻辑很简单第一看任务类型文本分类、抽取、生成对应不同的模型结构第二看部署资源如果只有单张消费级显卡就不要迷恋百亿参数以上大模型第三看延迟要求实时对话场景和离线批处理完全是两码事。分类模型比较省资源的方案是微调一个BERT系模型比如chinese-roberta-wwm-ext之类的中文预训练模型在单卡上跑完全没问题。摘要生成任务则建议走大模型路线可以是开源模型本地部署也可以调用商用API取决于你的数据隐私要求和预算。客服工单摘要这个场景不太涉及极敏感的私密数据但终究是业务数据客户对此有要求所以我们最终选择了本地部署开源模型。微调首选LoRA它通过在原始权重旁叠加低秩矩阵来学习任务差异训练参数量通常只有全量微调的1%左右显存和训练时间都大幅下降。我常用的LoRA配置是rank8到16alpha取rank的两倍学习率设置在1e-4到2e-4之间优化器用AdamW。训练时的批次大小不一定大小批次加梯度累积往往更稳定。LoRA适配器的权重只有几十到几百MB发布和版本管理非常方便。如果你在做一个通用任务现有模型已经表现不错我会诚实地建议你别上来就微调。先跑提示词工程再考虑RAG最后才微调。很多场景靠提示词优化就能解决80%的问题微调是为那最后20%效果付代价代价包括训练成本、模型版本分裂、评测责任加重。3.3 评测不是走过场评测体系是区分“玩模型”和“做AI工程”的分水岭。没有量化评测你根本不知道一次改动到底是在进步还是退步。对于分类模型评测集至少要按业务场景分层不能全随机抽样。比如客服工单要覆盖不同来源渠道、不同客户情绪、不同时间段防止模型在某一类数据上隐性过拟合。指标上分类任务看准确率、召回率、F1如果类别不平衡还要看各类别的单独表现。生成式模型的评测难度更高。我在摘要项目里采用双重评估客观指标加主观评估。客观指标用ROUGE、BERTScore这类基于相似度的分数能快速发现明显劣化主观评估采用评分卡加人工抽检给摘要从“信息完整性”“表述流畅性”“关键信息准确率”三个维度打分。最近大家都在用大模型充当裁判LLM-as-Judge这确实能省人力但要注意大模型裁判本身也有偏好比如偏爱更长更完整的答案。我的经验是定期抽样50到100条让人工评分和大模型评分做一致性对比Kappa系数低于0.6就说明裁判需要重新调教。评测集一定要持续沉淀每发现一个线上bad case就补充进评测集。这个过程看起来很慢但几个月下来你会拥有一套高价值的数据资产这套资产比任何单个模型都值钱。3.4 部署上线与线上监控部署环节的核心理念是“尽可能让模型推理变得简单可控”。FastAPI加Transformers的轻量方案里模型加载一次常驻内存请求进来直接走推理这种做法在中低流量下非常稳定。接口设计我会注意三点请求和响应都用JSON结构化字段方便对接方使用超时时间一定要设置防止模型偶尔异常卡死拖垮调用方加入prometheus指标记录包括请求量、推理耗时、显存占用等。如果流量上来了纵向能做的优化包括增大batch、开启torch.compile、使用半精度推理横向可以把服务多副本部署放负载均衡后面。再往后就该上服务化推理框架了。以LLM推理为例vLLM是个很好用的中间阶段选择它能通过PagedAttention和Continuous Batching把GPU利用率拉高吞吐量能比原生Transformers高出好几倍。最关键的是它接口兼容OpenAI格式业务方接入成本很低。量化是部署环节绕不开的话题。ASTW8这类8bit量化在很多场景下精度损失可以忽略适合快速落地INT4量化则更激进适合显存紧或对吞吐极敏感的场景。量化之后一定要跑一遍评测集对精度损失的量化评估是能不能上线的硬指标。用AWQ或GPTQ做4bit量化部署7B到13B模型是很多团队的常规配置。上线只是生命周期起点。我见过太多模型上线后效果衰减却没人发现的案例原因就是没有监控。分类模型要监控各类别的置信度分布变化摘要模型要抽检实际输出质量同时要跑输入侧的数据漂移检测比如特征分布PSI这个指标超过阈值就触发告警。一旦发现明显劣化要有预案回滚到上一个稳定模型版本或者快速用最近数据重新微调一版。4. 常见问题与排查技巧实录4.1 高频Bug速查表现象可能原因排查手段训练Loss居高不下学习率过高或数据标签噪声太大先降低学习率一个数量级再抽检训练集标注质量Loss先降后涨模型过拟合训练轮数过长观察验证集指标早停或增加正则化推理显存溢出批次太大、序列过长、未开半精度逐步减小batch开启FP16/INT8截断输入训练和验证指标差距过大数据泄漏或评测集分布不一致检查预处理是否把标签信息带入了特征接口偶尔返回超时冷启动、锁竞争或显存反复申请释放开启模型常驻并预热排查推理路径是否有重复加载线上效果与离线评测差异大线上数据分布和训练集偏移采集线上样例分析补充到训练集并重建评测集LoRA训练不收敛rank过小或基座模型不匹配任务尝试增大rank或换表达能力更强的基座模型实际项目里数据泄漏是排查过最多次的问题。比如数据清洗时用到了全量数据的统计值做归一化这在某些场景会把未来信息泄露给样本再比如去重时把同一用户的多条重复工单拆到了训练集和测试集导致评测指标虚高。要规避这个问题我的经验是任何统计类操作只能在训练集内部计算再映射到验证集和测试集文本去重必须以整个原始样本为粒度不能以清洗后文本为粒度。4.2 我踩过的几个印象深刻的坑第一个坑是迁移学习比例失调。有次微调模型把学习率设成默认的5e-5但用的是LoRA方式结果训练震荡非常严重。后来才意识到全参微调和LoRA的合适学习率区间差异很大LoRA用1e-4到2e-4才是顺手范围。这个细节在文档里很少有人强调踩过一次之后我就在实验模板里固定了参数默认值。第二个坑是评测集“脏了”。有一版摘要模型上线前离线评测分数很高但线上用户反馈说摘要经常漏掉关键金额信息。查下来发现评测集里大部分样本的“关键信息”标注不全模型是在一个错误基准上优化越优化越偏离业务需求。从那以后我每两周会人工复核一次评测集质量流程虽然繁琐但绝对必要。第三个坑是死磕模型结构而回避数据问题。项目中期有一版分类模型效果怎么调都上不去我花了两天折腾模型结构和超参最后发现某个分类的标注边界本来就有歧义人力资源部门也承认规范没写清楚。重新定义标签边界后模型效果立刻涨了几个点。数据问题永远优先排查这是我交过学费换来的经验。最后再分享一点个人体会带过多个从零开始的AI项目后我最大的感触是AI工程的成功从来不取决于某一个惊艳的模型而在于整条链路的稳定可控。数据、模型、评测、部署几条腿要一起走任何一条瘸了整体都跑不远。如果你正准备从零搭建自己的AI工程能力我的建议是先找个具体的小项目跑通全流程哪怕是做一个工单分类器、一个文档问答机器人都可以。过程中不要贪多LLM和BERT先用熟一个部署方案能跑通就行评测集哪怕只有几百条也要建起来。链路完整比单个环节做到极致重要得多。最后再叮嘱一句做一个AI工程项目的过程中你可能会无数次怀疑“这次改动到底有没有变好”。解决这个焦虑的唯一办法就是把评测体系做扎实。有了可靠的评测每一次改动都有数字回答你。这件事怎么提前投入都不过分。