从零开始做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配置是rank=8到16，alpha取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速查表

实际项目里，数据泄漏是排查过最多次的问题。比如数据清洗时用到了全量数据的统计值做归一化，这在某些场景会把未来信息泄露给样本；再比如去重时把同一用户的多条重复工单拆到了训练集和测试集，导致评测指标虚高。要规避这个问题，我的经验是：任何统计类操作只能在训练集内部计算再映射到验证集和测试集，文本去重必须以整个原始样本为粒度，不能以清洗后文本为粒度。

4.2 我踩过的几个印象深刻的坑

第一个坑是迁移学习比例失调。有次微调模型把学习率设成默认的5e-5，但用的是LoRA方式，结果训练震荡非常严重。后来才意识到全参微调和LoRA的合适学习率区间差异很大，LoRA用1e-4到2e-4才是顺手范围。这个细节在文档里很少有人强调，踩过一次之后我就在实验模板里固定了参数默认值。

第二个坑是评测集“脏了”。有一版摘要模型上线前离线评测分数很高，但线上用户反馈说摘要经常漏掉关键金额信息。查下来发现评测集里大部分样本的“关键信息”标注不全，模型是在一个错误基准上优化，越优化越偏离业务需求。从那以后，我每两周会人工复核一次评测集质量，流程虽然繁琐但绝对必要。

第三个坑是死磕模型结构而回避数据问题。项目中期有一版分类模型效果怎么调都上不去，我花了两天折腾模型结构和超参，最后发现某个分类的标注边界本来就有歧义，人力资源部门也承认规范没写清楚。重新定义标签边界后，模型效果立刻涨了几个点。数据问题永远优先排查，这是我交过学费换来的经验。

最后再分享一点个人体会

带过多个从零开始的AI项目后，我最大的感触是：AI工程的成功从来不取决于某一个惊艳的模型，而在于整条链路的稳定可控。数据、模型、评测、部署几条腿要一起走，任何一条瘸了，整体都跑不远。

如果你正准备从零搭建自己的AI工程能力，我的建议是先找个具体的小项目跑通全流程，哪怕是做一个工单分类器、一个文档问答机器人都可以。过程中不要贪多，LLM和BERT先用熟一个，部署方案能跑通就行，评测集哪怕只有几百条也要建起来。链路完整，比单个环节做到极致重要得多。

最后再叮嘱一句：做一个AI工程项目的过程中，你可能会无数次怀疑“这次改动到底有没有变好”。解决这个焦虑的唯一办法，就是把评测体系做扎实。有了可靠的评测，每一次改动都有数字回答你。这件事怎么提前投入都不过分。