1. 先搞明白AI工程和“调模型”到底差在哪1.1 什么是真正的 ai-engineering而不是跑通一个 demo先说个我自己的经历。前两年我第一次接触一个所谓的“AI项目”实际上就是拿到一个公开的模型权重写了个30行的Python脚本调用了一下输出了几个结果。那叫“用AI”不叫“AI工程”。真正让我意识到两者差距的是后来接了一个内部需求公司想让员工在一个集中式入口里用自然语言提问然后系统从几十万份技术文档里找到答案还要带着来源引用返回。一开始我觉得这有什么难的——模型加载起来做个embedding接个向量库完事了。结果真正做下去才发现模型加载跑通只是这个项目里最不起眼的5%。剩下95%的时间都在处理数据质量、环境一致性、训练稳定性、线上延迟、评测标准、回归回归回归——这才是ai-engineering from scratch的核心。所以这篇文章想分享的不是某一个模型的调用代码而是当你决定“从零开始把一条AI产品线真正落地”时你需要面对的那些绕不开的问题以及我踩过之后留下的方案。适合刚入门的算法工程师、想把模型产品化的后端开发以及正在复现论文或开源项目、却被环境、数据、部署折磨到怀疑人生的学生。标题里的“from scratch”有两层含义技术栈上的从零不是用别人封装好的Paas平台拖几个组件而是自己掌握链路里的每一个关键环节。认知上的从零打破“模型就是一切”的幻觉建立工程化思维。1.2 为什么选择自建而不是直接套现成平台做AI工程第一件事通常是选型用现成的大模型API还是自己微调部署用托管的向量数据库还是自己起一个这里没有标准答案但有决策框架。我当时的判断标准是四看看数据敏感性企业内部文档涉及业务细节不能随便出网。看定制深度问答效果依赖对私有术语的理解通用模型明显不够。看长期成本调用量上来之后按token付费的费用远高于自建推理。看团队成长希望团队借这个项目真正建立AI工程能力而不是变成一个API转发器。四条下来“自建 开源模型微调 私有部署”是唯一合理的路径。但自建有一个被严重低估的代价链路变长了。以前用一个API只需要关注输入输出自建之后你要关注数据管道、GPU资源、训练稳定性、推理吞吐、监控告警。每多一个环节就多了一批潜在的故障点。这是所有从零开始的人要先做好的心理建设。1.3 一个贯穿全文的实例内部文档问答机器人为了让下面的内容不至于飘在理论上我以“企业内部文档问答机器人”作为贯穿案例。项目目标很明确用户输入一个问题系统返回一段答案并附带来源文档和页码。业务上要求准确率不低于85%首字节延迟低于2秒支持30个并发。训练数据来自公司内部的技术文档、产品手册、历史工单大约50万条。这个例子覆盖了AI工程的主要模块数据管道、模型微调、推理部署、评测反馈。后面每个章节都会用它来说明“为什么这么做”“参数怎么定”“踩了什么坑”。2. 环境与基础设施搭地基的姿势决定上层建筑的稳定程度2.1 GPU选型与驱动别一上来就被显存卡死做AI工程第一道坎通常是硬件环境。我当时拿到的是一台双卡机器配置是2块24G显存的GPU。很多人会问“显存选多大”其实这个问题不应该脱离模型规模去谈。如果目标是微调一个7B参数量的模型采用LoRA方式24G显存跑fp16是够的如果要全参数微调24G会很吃力。训练和推理的显存需求差异也很大推理阶段可以用量化大幅压缩。选型的时候我列过一个粗略的评估表模型规模推理最低显存FP16微调推荐显存LoRA全参微调推荐显存1B以下4G8G16G7B16G24G80G13B32G48G160G注意这只是经验值实际要看序列长度和batch size。序列越长、batch越大显存需求越高。驱动和CUDA版本这块我吃过一次亏机器上预装了CUDA 11.8但PyTorch版本要求CUDA 12.1结果程序没有报CUDA错误而是直接报“illegal memory access”排查了一天最后才发现是版本不匹配。现在我的原则是先查PyTorch官方对应的CUDA版本再回过头配置驱动。跑一个简单的验证命令确认环境正常python -c import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))如果输出显示的GPU名称正确CUDA可用再开始装模型能省掉一大半玄学问题。2.2 用Docker把环境固化下来不要相信“在我电脑上是好的”AI工程的复现性有一个大敌环境漂移。“在我电脑上跑得好好的”这句话在AI项目里出现的频率远超其他软件项目。原因很简单训练脚本依赖的Python包有几百个每个包又有不同版本某次升级一个小版本可能就带来数值变化。为了把环境固化我强烈建议从第一步就引入Docker。我用的基础镜像形如FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime RUN apt-get update apt-get install -y git curl RUN pip install --no-cache-dir transformers datasets accelerate peft trl COPY ./requirements.txt /app/ RUN pip install --no-cache-dir -r /app/requirements.txt这样做的好处有三个环境与宿主隔离不会再因为系统Python升级导致依赖崩掉。训练、推理、测试用同一个镜像结果可以对比。部署的时候直接把镜像推到内部仓库生产机和开发机环境完全一致。我用的是conda还是Docker答案是都要。conda负责创建Python虚拟环境Docker负责把整个系统层传下去。在Docker里面再用conda管理Python环境可以兼顾灵活与可复现。2.3 实验跟踪没有记录的训练都是白训从零开始做AI工程最容易忽略的一个环节是实验记录。我早期就是这样改个参数跑一晚上第二天醒来发现效果好了但忘了昨天改了什么。那种“明明前一天还在变好现在怎么退步了”的困惑基本都源于没有做好跟踪。后来我引入了MLflow配合一套简单的命名规范。每个实验记录三样东西超参数学习率、batch size、epoch数、LoRA rank指标训练loss、验证loss、准确率、F1产物模型检查点路径、评测报告、日志文件命名规范是“日期-模型-版本-说明”比如“20240601-bert-base-zh-v01-lr2e5”。不要小看命名一个清晰的名字能让你三个月后翻记录时省下大量时间。如果你不想引入额外的服务也可以用最简单的CSV记录表。核心不是工具而是“每次改动都有迹可循”这个习惯。2.4 项目目录结构让数据、代码、模型、实验各归其位从零搭建AI工程第一个该建立的不是模型而是目录结构。混乱的目录是后期维护的地狱。我最后固定的结构是这样的ai-engineering/ ├── configs/ # 所有训练、推理、评测的配置 ├── data/ # 数据原始、清洗后、切分后 ├── src/ # 代码 │ ├── data/ # 数据处理逻辑 │ ├── models/ # 模型定义 │ ├── train/ # 训练脚本 │ ├── infer/ # 推理逻辑 │ └── eval/ # 评测逻辑 ├── experiments/ # 实验记录与产物 ├── models/ # 最终模型权重 └── scripts/ # 运行入口脚本这个结构的原则是数据和模型不跟代码混在一起配置和实验结果又跟代码分开。实际用下来的好处是很多时候只需要拷贝某个子目录就能完成交接不用把“那一堆乱七八糟的文件”一起拷走。3. 数据是真正的上线难点清洗、版本化、切分3.1 从原始文档到训练数据清洗规则怎么定很多从零开始做AI工程的人会低估数据处理的比重。真实情况是一个生产中可用的模型其数据工程耗时往往占总工时的60%以上。尤其像文档问答这种场景原始数据是PDF、Word、HTML混在一起排版各异直接拿去训练根本不可能。我的清洗分四步走第一步做格式转换。PDF用解析工具抽出文本Word转成纯文本HTML剥掉标签。这里要注意PDF双栏排版很容易抽取错乱需要按栏切分再拼接。第二步做段落切分。按标题层级和段落边界把文档切成“语块”而不是简单按字符数硬切。我当时用了一套基于标题编号的规则同时保留每块的来源元数据文档名、章节路径、页码。第三步做规则过滤。批量去掉页眉页脚、导航重复段落、空行、乱码字符。规则要写成脚本反复迭代不要手动删。第四步做人工抽检。每清洗完一批数据随机抽100条检查质量。如果错误率超过2%说明清洗规则还需要补。一点心得清洗规则宁多勿少因为脏数据给模型带来的伤害是隐性的——它不会报错只会让效果差一点、再差一点最终你根本不知道是模型的问题还是数据的问题。3.2 数据版本管理改过什么永远要能查谈到数据AI工程师圈子里流传着一句话“模型是数据的影子。”你改了一版数据模型效果完全不同。这时如果你没记录数据版本那么复现就是一个笑话。我做数据版本管理的办法不复杂用类似DVC的方式但核心是把两样东西固定下来——数据文件的哈希值和一份数据清单。每当数据变更我会生成一个新的数据版本号格式是“v日期-序号”并记录原始数据来源清洗脚本版本清洗参数清洗后样本数量人工抽检结果这份记录放在数据目录的“CHANGELOG.md”里。为什么这么在意因为当我发现模型效果下降时第一件事就是检查数据版本是否被动过。有一次团队同事顺手“优化”了清洗脚本去掉了一个去重步骤结果数据量从50万变成55万模型准确率掉了3个点。查了两天最后定位到就是数据版本变了。如果一开始就查CHANGELOG十分钟就能解决。3.3 切分与分布检查训练集验证集的划分要防止“作弊”数据切分看起来是个简单问题——随机分一下就行其实不是。文档问答场景有一个典型风险同一份文档的不同段落可能既出现在训练集又出现在验证集。模型见过相关内容验证集分数虚高上线后面对新文档效果骤降。这就是数据泄露。我的切分原则是按文档级别切分而不是按段落切分。同一篇文档的段落放进同一个集合。验证集和测试集不使用同一批文档。切分之后人工检查类别分布。比如工单类的数据占了60%验证集也要保持类似的占比否则指标会有偏。切分完一定要跑一个简单的分布检查脚本输出训练/验证/测试三个集合的样本量、来源分布、平均长度。看到三组数字大致匹配再进入训练环节。这里特别提醒一点不要反复在测试集上调参。测试集的唯一使命是最终评估一次。想调参用验证集。这个原则违反了你的指标就只是“对测试集的记忆”不是真实能力。4. 模型训练与微调的实操从加载到收敛4.1 训练循环骨架每一行都有存在的理由从零开始写训练循环不是把模型的forward和backward拼在一起就完事。一个生产可用的训练脚本要考虑的东西比教科书示例多得多梯度累积、混合精度、梯度裁剪、checkpoint保存、日志频率。我用的训练循环骨架大致长这样for epoch in range(num_epochs): model.train() for step, batch in enumerate(train_loader): batch {k: v.to(device) for k, v in batch.items()} outputs model(**batch) loss outputs.loss / grad_accum_steps loss.backward() if (step 1) % grad_accum_steps 0: torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() scheduler.step() optimizer.zero_grad() if step % log_steps 0: logger.info(fepoch {epoch}, step {step}, loss {loss.item():.4f}) # 每N步做一次验证 evaluate(model, val_loader)看起来平平无奇但有几个点值得展开。梯度累积是为了在单卡显存受限时用多个小batch模拟大batch的效果。grad_accum_steps 理想batch size / 实际batch size。比如理想batch是32显存只放得下8那accum_steps就是4。混合精度AMP可以让训练加速且省显存。PyTorch里用torch.cuda.amp即可一般不改业务代码。但要注意部分模型在FP16下数值不稳定loss会突变成nan。如果你遇到这种问题可以退回FP32或者用BF16在许多新卡上更稳。4.2 超参数的起点以及调参的顺序逻辑超参数是玄学吗某种意义上是的但调参顺序是有逻辑的。我的经验是从学习率开始调。找一个大致的范围比如1e-5到5e-5先用小数据集快速跑几个epoch观察loss走势。loss不降说明学习率太小或者模型结构有问题loss震荡说明学习率太大。选定学习率之后再调batch size。batch size主要影响训练稳定性和收敛速度太大会显存爆炸太小会导致梯度噪声大、收敛慢。再然后是epoch数。epoch数其实不是一个需要“调”的参数而是和早停early stopping配合的概念。我一般设置一个上限比如10个epoch如果验证指标连续3个epoch没有提升就提前结束训练并保存验证集上表现最好的那个检查点。warmup比例也值得一说。很多模型微调时会设置一段“预热期”学习率从零线性上升到目标值再按余弦曲线下降。warmup的比例我习惯设为总步数的3%到5%。它的作用是防止训练初期由于学习率过大导致模型参数剧烈震荡。4.3 什么时候上分布式单卡能解决的事别浪费时间在多卡上很多从零开始的人有个误区一上来就研究分布式训练框架。其实大多数项目单卡就能搞定。我的判断标准是如果单卡训练一轮的时间在可接受范围内比如一个晚上能跑完就绝对不要上分布式。分布式训练带来的增益不是没有但它同时引入通信开销、调试难度和版本兼容问题。性价比极低。只有当训练时间超过资源容忍度比如单卡要跑一周以上才是考虑DDPDistributedDataParallel的时机。如果可以优先用LoRA这种参数高效微调技术而不是全参微调。它在保持效果接近的情况下显存占用和训练时间都能大幅降低。微调一个7B模型的LoRA24G单卡完全够用。这个决策让我的团队省下了一整台A100预算。4.4 模型产物管理检查点怎么存选哪个版本上线一个训练任务跑完会留下很多检查点每个epoch保存一次加上早停保存的最佳检查点以及最后一轮检查点。不可能全部上线需要一套选择逻辑。我现在的规则是候选检查点都跑一遍评测集记录核心指标准确率、F1、延迟。上线选择不只看单一指标。比如准确率最高的检查点可能在某类问题上的稳定性很差我会看分项指标再决定。所有检查点统一命名格式模型名-训练数据版本-epoch号-指标值。这个格式保证三个月后还能定位到“为什么选它”。保存检查点的时候不只是存权重还要把训练配置和tokenizer一起打包。有过一次教训三个月后想恢复一个模型继续训练结果只找到权重文件tokenizer配置丢了那个模型直接报废。权重可以不要tokenizer和config一定要留在模型目录里。5. 推理部署与性能调优模型跑起来只是开始5.1 在线服务还是离线批量先想清楚业务形态部署的第一步不是写API而是判断业务到底需要什么形态。文档问答这个场景用户需要实时交互所以必须是在线服务接口响应要快。而像“每周自动给全量工单打标签”这种就不需要API跑一个批量脚本就行。在线服务又分同步和异步。同步返回适合单次问答场景简单直接。异步适合处理慢操作比如生成很长的答案先返回任务ID用户再通过轮询拿结果。我当时的业务首字节延迟要求是2秒同步就够用没有引入额外的消息队列。这里提醒一点不要为了“看起来高级”而加消息队列。每多一个组件就多一层运维负担。先把同步接口做好发现瓶颈再演进。5.2 推理加速量化、批处理、缓存三板斧模型部署之后第一件事就是压测。我的经验是不要凭感觉判断性能直接用压测工具跑指标。压测看三个数字QPS每秒能处理多少请求、P99延迟最慢的1%请求耗时、显存占用。我的压测结果是单卡初始QPS只有5P99延迟4秒远远不够。之后我做了三板斧优化第一板斧是量化。把模型从FP16量化到INT8或INT4显存占用直接下降50%以上推理速度提升明显。当时用的是类似GPTQ的思路通过校准集选择量化参数。INT4的量化会让效果略有下降但在这个业务场景下可接受。第二板斧是批处理。在线推理服务默认是一个请求一个请求地过模型GPU利用率很低。改成动态批处理服务在极短的时间窗口比如50ms内收集多个请求合并成一个batch同时推理。这个改动把GPU利用率从20%拉到80%以上QPS直接翻了几倍。第三板斧是结果缓存。高频问题往往占线上请求的大头。对完全相同或高度相似的query直接用Redis缓存之前的结果。这个改动把30%的请求变成“零推理”效果立竿见影。优化后我的最终指标是QPS 25P99延迟1.2秒满足业务需求。别小看这些优化它们是“从能跑到能扛流量”的关键。5.3 API服务怎么做才像话模型推理服务本质上是一个高并发的接口服务工程上不能裸奔。我用FastAPI搭的服务骨架大概长这样from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class Query(BaseModel): question: str top_k: int 3 app.post(/v1/qa) async def qa(query: Query): try: result pipeline.run(query.question, top_kquery.top_k) return {answer: result[answer], sources: result[sources]} except Exception: raise HTTPException(status_code500, detailinternal error)但光有这个还不行生产环境至少还要有超时控制每个推理请求设置超时上限比如5秒避免慢请求拖垮线程池。重试策略对偶发的GPU显存不足、临时CUDA错误做有限重试。限流对用户或客户端IP做每分钟请求数限制防止恶意调用。队列上限当并发过大时服务的策略是“快速失败”还是“排队等待”要提前定好。我当时选的是快速失败返回503让调用方自己退避。5.4 上线后的监控没有监控的服务是一颗定时炸弹服务上线后我开始搭建最基本的监控指标。不是要什么花哨的可观测性平台而是先把最关键的指标看住。GPU监控利用工具每10秒采集一次显存使用率、GPU利用率和温度写入时序数据库画到面板上。显存持续上涨是泄漏的典型信号基本可以断定服务代码或推理框架有内存管理问题。请求监控记录QPS、P99/平均延迟、超时率和5xx错误率。延迟突增和错误率飙升是两大核心告警。数据漂移监控上线后的模型会面对未知的线上数据分布。我的做法是定期从线上日志里取最新的query样本和训练时的query做embedding距离分布对比。如果分布偏移过大就需要考虑重新训练。这个问题在文档问答场景很常见——业务人员提问习惯会随时间变化。不做监控模型就像蒙着眼开车。你永远不知道它在生产环境里已经被用户的真实请求折磨成什么样了。6. 评测体系与回归测试不评测等于白做6.1 评测集是AI工程的“法律文件”模型好用不好用不是训练指标说了算而是评测集说了算。很多人只盯着训练集上的loss降没降这是最大的误区。Loss降了可能是过拟合可能是数据泄漏可能只是“背题”。真正衡量模型能力的是一份和训练集完全独立、由人工标注、覆盖真实业务场景的评测集。我当时花了两周时间做评测集。从50万条数据里挑出2000条作为评测样本覆盖几十种问题类型每条由三个人独立标注取多数作为最终答案。同时保证评测集里的文档不会出现在训练集里。评测集要包含两类样本常规样本绝大多数线上请求长什么样评测集就长什么样。边界样本故意放一些模糊问题、带错别字的query、语义相近但答案不同的陷阱题。没有边界样本你的评测分数会很漂亮但上线后被真实用户一问就原形毕露。6.2 自动化回归测试改一个参数不要把全线上搞挂有了评测集下一步是把评测自动化。我设计了一套回归测试流程每次模型更新或者数据更新都会跑一遍。流程分三段第一段是冒烟测试。用10条左右的高置信度样本验证模型能不能正常加载、推理会不会报错。耗时两分钟作用是把明显的代码问题挡在门口。第二段是核心评测。用完整的2000条评测集跑一遍生成详细报告。包括总体准确率、分类型准确率、和上一版模型的对比。如果新版模型总体指标下降超过1%除非有明确理由否则默认不通过。第三段是错误case留档。每次评测失败的样本自动记录下来标记“待人工分析”。这些case是数据迭代最宝贵的来源。我从这个流程里吃到最大的甜头是再也不用担心团队里任何人“偷偷把参数改了”之后影响线上效果看不到——自动化测试会用指标说话。6.3 基于bad case的迭代闭环AI工程的“永动机”效果提升不是靠突然的灵感而是靠对bad case的持续分析。我的操作流程是收集错误样本从评测失败和线上日志里汇总bad case。聚类分析把bad case归类。比如“模型分不清‘退款’和‘退货’的区别”“模型对缩写理解错误”“检索结果缺失导致生成失败”。每类给一个标签。定位根因有些bad case是数据问题有些是检索问题有些是模型能力边界。根因不同解决方案完全不同。数据补强针对根因补充对应的训练数据或调整清洗规则。重新训练和评测回到训练阶段跑完自动化测试看是否解决。这个循环跑上个10轮模型效果就会逐步逼近业务预期。数据版本管理、实验记录、自动化评测的意义在这个闭环里全部体现出来。7. 常见问题与排查技巧实录7.1 环境与训练阶段的高频问题现象常见原因排查思路启动就报“illegal memory access”CUDA版本与PyTorch不匹配先核对PyTorch官方要求的CUDA版本再检查驱动与CUDA训练中途显存OOMbatch size过大或显存碎片化先减小batch size或开启梯度累积再检查是否有变量未释放loss是NaN学习率过大、FP16数值不稳定、数据里有脏标签降低学习率可尝试BF16检查数据清洗loss一直不降学习率太小或训练数据分布混乱快速跑5个epoch看loss斜率排除数据标签大量错误训练完指标高线上效果差数据泄漏或评测集覆盖不足检查切分是否按文档级别补充边界样本OOM是我遇到最多的。一开始我以为是GPU显存不够排查老半天发现是某个代码片段把中间结果列表全部积在内存里batch的loss都正常但内存先爆了。用free -g看一眼系统内存能快速区分是显存还是内存问题。7.2 部署与服务阶段的高频问题现象常见原因排查思路P99延迟持续走高并发排队过多或批处理窗口设置不合理看队列长度调整动态批处理最大等待时间GPU显存使用率只增不减推理框架或服务代码内存泄漏用监控工具观察显存曲线最小化复现定位是框架还是业务代码请求大量返回503队列上限触发快速失败放宽队列上限或增加实例检查限流配置是否误伤正常用户修改代码后推理结果变了未固定随机种子或模型未加载同一检查点固定PYTHONHASHSEED和随机种子核对模型路径与config服务重启后首次请求特别慢模型冷加载上线时写预热脚本启动后发送几条请求让模型预热再对外服务部署阶段有个细节容易被忽视模型文件的加载路径。我犯过一次错部署时从网盘下载模型下载完成度没有校验结果服务用的是一半的权重文件准确率低到不可思议还没有报错。后来我在所有模型加载环节都加了一步校验加载后跑一遍冒烟测试检查输出是否符合预期。这个习惯救了我好几次。7.3 数据层面的问题排查数据的问题最隐蔽因为不报错。我发现过一个现象模型对英文缩写理解特别差一开始以为是模型能力问题后来分析是清洗脚本把所有句点都去掉了导致“U.S.A”这种词被粘连成“USA”含义还算对但“app.v1.2.3”这种版本号被破坏训练样本全乱了。这类问题只能靠“清洗后人工抽检”和“数据分布统计”这类预防机制出了再查往往为时已晚。另一个高发问题是重复数据。很多文档的内容是重复粘贴的如果不做去重某些句子在训练集中出现几十次模型就会严重偏向这些说法对其他同义表达不敏感。至少做一次MinHash或simhash去重比任何调参都管用。8. 最后分享两个亲测有效的习惯写到最后说点不太能写进项目汇报里的体会。第一个习惯是把每一步的关键决策和踩坑记录下来。不是写API文档那种而是记录“为什么当时那么选”“后来发现有什么问题”“下次怎么做更好”。这种草根笔记看着不起眼但在项目中期回头查问题时它的价值超过任何一本教科书。第二个习惯是永远从最小闭环开始。不要一开始就规划一个完美的大系统而是先做一个丑但通全链路的版本10条数据、1个模型、1个接口、10条评测样本。跑通之后再一步步把工程化能力加进去。所有大的AI工程问题都是在闭环里逐个暴露、逐个解决的。从零到一搭建AI工程确实不容易但这个过程建立的工程判断力和排错能力才是真正的资产。项目会结束模型会迭代但这些能力会留在这个团队的血液里后面的路自然会越走越稳。