从零搭建AI工程：模型选型、微调、RAG与部署全流程实战

从去年开始我所在的技术团队正式把“自研AI能力”提上日程。当时团队里没有算法背景的同学没有现成的GPU集群甚至没人完整跑通过一次模型训练。项目标题叫“ai-engineering-from-scratch”说白了就是一件必须做的事在没有AI基础、没有可抄作业的条件下把一个能用的AI系统从零搭起来。这篇博文就是这次从零落地的全过程总结包括怎么做模型选型、数据工程、微调、部署和评测全文按实操路径展开适合那些正被“要不要招算法博士”困扰的工程团队也适合刚拿到AI任务但不知道第一步往哪踩的技术负责人。我踩过的坑不少选型时差点买了一堆A100却不知道要配多少CPU内存微调时数据没洗干净让模型学会了胡说上线后才发现推理速度跑不满业务要求。这些教训如果只停留在自己脑子里太可惜了整理出来给同样打算从零做AI工程的团队当一份绕坑指南。1. 项目启动前的整盘思考AI工程到底缺什么1.1 大家以为缺算法其实缺的是整条链路好多团队接到“做个AI产品”的需求时第一反应都是“招几个算法工程师”。但这个思路在从零起步的项目里往往并不成立。AI工程不是“有一个模型就完事”而是数据、训练、部署、评测、迭代五个环节缺一不可的系统工程。现实里纯算法岗位的成本很高而且如果业务数据链路没打通、部署平台没有准备招来的人也只能干等。我观察到的实际情况是大多数中小团队真正缺的是两样东西一是把业务问题转成AI问题的拆解能力二是把模型接进生产环境的工程能力。这两样恰恰是普通后端工程师通过系统学习能补上的不需要从零培养一个算法专家。所以项目启动前我建议先做一件事把“AI能力建设”拆成模型、数据、推理、评测四个子项目分别评估自己团队在每个环节的现状。这样能看到瓶颈在哪儿而不是笼统地觉得“我们不懂AI”。1.2 几条路线怎么选开源为主、买API为辅从零搭建AI工程能力摆在面前的第一条岔路就是用开源模型自己部署还是直接买商业API。我的结论是两条腿走路但以开源为主必须分清主次。选开源模型的核心理由是可控性和成本。以当时几个主流开源模型为例7B到14B参数量级的模型在单张消费级显卡上就能完成推理成本远低于按token付费的商业API。而且私有化部署意味着数据不出内网对很多有数据合规要求的业务场景来说这是刚需。商业API更适合用作“短期验证”和“效果上限”的参照物。我们在项目初期用商业API跑了一批样例数据用生成结果来校准我们对模型能力的预期。这个经验很重要你总得先知道“理想答案”长什么样才能判断自建系统做到什么程度算达标。1.3 诚实地划定能力边界别什么都自己造从零开始时最容易犯的毛病是“过度自研”。embedding模型、RAG链路、向量数据库、推理引擎、评测工具什么都想自己造一套结果三个月过去还在造轮子。我的原则是和核心业务差异化直接相关的东西自己造通用基础设施能用现成的就用现成的。向量库选成熟的开源组件推理引擎用社区维护的vLLMembedding模型用开源的bge系列这些都属于“不该重复发明”的部分。真正需要投入精力自研的只有三块业务数据的清洗和构造流程、针对业务的微调方案、评测集的设计。2. 模型底座选型别一上来就训大模型2.1 先算一笔显存账再谈选什么模型很多团队第一步就想上几十B甚至上百B的大模型但没有先算算手里的显卡到底能不能跑起来。这里有一个最基本的显存估算公式每个做AI工程的人都应该刻在脑子里模型显存 ≈ 参数量 × 精度字节数。以7B模型、FP16精度为例单份权重就需要 7×10⁹ × 2字节 ≈ 14GB。如果要做训练或微调还需要额外空间存放优化器状态、梯度如果用Adam优化器这部分大约是权重的2-3倍也就是再来28GB到42GB。还没有算上推理时的KV Cache和激活值。这个计算告诉我们一件事拿一张24GB显存的消费级显卡跑7B模型推理是够用的但要微调就得用LoRA这类参数高效微调方案或者直接上更大显存的卡。我们团队的方案是两张RTX 4090起步用一张跑推理一张跑微调后面加了A100才算真正放开手脚。定这个方案之前我先把所有候选模型的参数量、精度、显存占用算清楚再对照手里的预算选型自然就收敛了。2.2 开源和商用API的取舍标准用数据说话选模型底座时我们会用一套简单的评测动作来对比不同选项。准备三个维度业务样例上的输出质量、推理延迟、每千次调用的成本。在这三个维度上分别给候选模型打分。拿我们当时的业务举例需要做基于内部文档的问答系统。商业API在长文档理解和语言丰富度上确实领先但在成本上如果日均调用量达到几十万次月成本会高到让项目直接被砍掉。开源模型虽然初始效果差一些但通过微调和RAG的补充能把效果拉近到可用水平而推理成本几乎只占电费。所以我的最终建议是先用商业API确定效果基线再用开源模型做技术验证一旦验证通过就切换。这个顺序能最大程度降低从零起步的试错成本。2.3 从Base模型微调而不是从零预训练另一点必须反复强调团队刚起步千万不要碰从零预训练。预训练需要数千张显卡、数月的训练周期、PB级别的数据清洗管线这不是“从零开始”的AI工程该干的事而是大厂和大模型公司才玩得起的游戏。从零开始的正确姿势是选一个开源Base模型或Chat模型基于自己的业务数据做微调。对于绝大多数企业级应用LoRA微调甚至全参数微调7B-14B模型已经完全够用。我们实际验证过通过一个精心构造的2万条指令数据集微调7B模型在垂直领域的效果可以提升20%以上这在业务上已经是巨大差异了。3. 数据工程决定AI天花板的脏活累活3.1 数据从哪来业务日志、文档库和人工标注缺一不可模型能力的天花板很大程度上是数据喂出来的。从零搭建AI工程时最花时间的不是写代码而是把数据搞干净。我们的数据来源主要有三个内部文档库产品文档、技术方案、历史工单、业务日志API调用记录、用户反馈文本、人工标注针对典型问题写标准答案。内部文档库适合做RAG的语料业务日志适合挖掘真实用户问题人工标注则直接影响微调数据集的质量。三者搭配使用才能让模型既懂知识又懂业务语气。前期不要指望数据一次到位先把手头能拿到的数据整理出一版跑通整个链路再迭代补充。3.2 清洗管线三步走去重、去噪、去隐私数据清洗是脏活但必须做。我们搭了一套三步走的清洗管线。第一步去重用MinHash算法对文本做近重复检测把相似度超过阈值的文档合并或剔除避免模型在训练时被重复样本带偏。第二步去噪去掉HTML标签、乱码、无意义的对话框文本、超长的代码片段规则加人工抽检结合。第三步去隐私用正则和命名实体识别把手机号、身份证、内部工号等信息替换成占位符这一步关系到合规底线不能省。每个清洗步骤都加上统计日志记录清掉了多少数据、为什么清掉。这个习惯后来帮了大忙当模型表现异常时我们能回查数据管线定位是不是清洗规则误伤了有效信息。3.3 SFT数据集构造指令质量比数量更重要很多团队一上来就想构造十万条微调数据但实际效果往往撑不起这个野心。我在实操中发现两万条高质量的指令数据效果远好于十万条从网上爬来的、格式混乱的数据。构造SFT数据集时要注意三点。第一指令要覆盖真实的业务场景不要凭空想象而是从历史工单、用户反馈中归纳典型问题。第二回答要标准、准确、格式一致同一个意思不要一会儿用列表一会儿用长句。第三要控制答案的长度和风格让模型学会“简洁但完整”地回答问题。我们当时用了一套半自动构造流程先人工写500条高质量样例作为种子再用LLM辅助扩充相似问题最后人工抽检和修正。这样既保证了质量又在可控时间内把数据量堆到了两万条。4. 微调实操从Base模型到业务可用4.1 LoRA是什么以及关键参数怎么设微调阶段我们选了LoRALow-Rank Adaptation。它的核心思路是冻结原模型权重在注意力层的权重矩阵旁加一个低秩的增量矩阵只训练这个增量。效果上LoRA以极低的训练参数量逼近全参数微调的效果非常适合显卡资源有限的从零团队。LoRA的关键参数有三个rank秩、alpha缩放系数、target_modules目标模块。我踩过几次坑之后总结出的经验值是rank设16alpha设32target_modules覆盖q_proj和v_proj如果效果不够再加k_proj和o_proj。rank不是越大越好在垂直领域任务上rank 64和16的差距很小但显存占用会明显上升。训练超参方面我们用的学习率是2e-4配合cosine学习率调度器批次大小设为4到8之间取决于显存。训练轮数控制在3到5轮之间轮数太多容易过拟合到训练集导致模型对训练集中的表述模式产生偏好。4.2 一条可复用的微调命令从零跑通直接给一套可以照着用的命令。环境是PyTorch transformers peft模型是Qwen2.5-7B数据集是JSON格式的指令数据。核心代码如下from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from datasets import load_dataset model_name Qwen/Qwen2.5-7B-Instruct dataset load_dataset(json, data_filessft_data.jsonl) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypeauto, device_mapauto ) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj, k_proj, o_proj], lora_dropout0.05 ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./qwen-lora, num_train_epochs3, learning_rate2e-4, per_device_train_batch_size4, gradient_accumulation_steps4, logging_steps10, save_strategyepoch, ) model.train() model.save_pretrained(./qwen-lora-final)这段代码的关键点在于device_map设为auto让模型自动分配到可用显卡上save_strategy设为epoch确保每个epoch结束都能留下一个恢复点方便回滚。训练过程中我习惯盯着loss曲线看正常情况loss会在前几百步快速下降然后进入稳定下降区间。4.3 对抗过拟合与灾难性遗忘的几条经验微调中最容易遇到两个问题过拟合和灾难性遗忘。过拟合的现象是训练集loss很低但遇到没见过的问法就答非所问灾难性遗忘则是模型把原本的通用能力丢了变得只会在垂直领域“念经”。对抗这两个问题我的经验是三条。第一微调数据里按一定比例混入通用数据比如10%到20%的通用指令让模型不要忘记基础能力。第二控制训练轮数在3到5轮超过5轮后效果往往不升反降。第三微调后用一组通用能力测试集做回归测试专门检查模型在常识问答、摘要、翻译等通用任务上的表现有没有明显下滑。5. 部署与推理让模型真正跑进生产环境5.1 推理引擎选型vLLM是当前最稳的起步选择模型训练好了下一步是部署。从零搭建时推理引擎的选型不要自己造直接选社区成熟方案。我们的选择是vLLM核心原因有两点一是它实现了PagedAttention显存利用效率显著优于原生transformers推理二是它自带OpenAI兼容的API服务接业务后端时几乎没有适配成本。具体操作上用vLLM启动一个模型服务只需一条命令python -m vllm.entrypoints.openai.api_server \ --model ./qwen-lora-final \ --served-model-name qwen-business \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9注意这里我们直接把LoRA微调后的完整模型目录传给了vLLM加载的是合并后的权重。如果只想在基座上动态加载LoRA适配器vLLM也支持但配置会复杂一些建议起步阶段直接加载合并权重减少变量。5.2 推理参数和并发调优别让GPU闲着推理部署不是“能响应”就完事要在延迟和吞吐之间找平衡。我们压测中发现几个关键参数影响很大max-model-len决定能处理的最长输入设太大会浪费显存设太小会截断长文档建议根据业务场景实际长度来定gpu-memory-utilization是vLLM允许使用的显存比例设到0.9可以充分利用显存但也要留出一点余量给其他进程。并发调优方面vLLM的Continuous Batching机制可以自动混批理论上不需要手动配置batch大小但需要关注吞吐量指标——每秒处理多少个请求。我们实测在4090上跑7B模型max-model-len设为4096时单卡吞吐能到每分钟几十个并发请求满足中小业务场景完全够用。5.3 补全RAG链路让模型学会查资料再回答纯靠微调模型的记忆来做问答是不可靠的尤其是面向不断更新的内部文档时。我们在这个项目里同步搭了一套RAGRetrieval-Augmented Generation链路核心组件包括文档切分、向量化、向量检索、重排序和最终生成。文档切分时我们按512个token的chunk大小切分相邻chunk保留50个token的重叠避免关键信息被切断。向量化用bge-m3模型向量检索用开源的Milvus向量数据库。检索阶段取出top-20候选chunk再用bge-reranker重新排序取top-5喂给大模型生成答案。这套链路补全之后效果提升非常明显。模型不再需要“背下”全部文档内容而是每次回答前先查资料再用自己的语言组织答案。这也是从零搭建AI工程时性价比最高的一个环节投入产出比远高于盲目堆微调数据。6. 评测闭环上线之前怎么证明系统可用6.1 评测指标怎么定准确率、延迟、成本一个都不能少AI系统上线的拦路虎是评测怎么证明模型真的可用。我们设计了三维度评测框架。效果维度在测试集上算准确率、相关性和格式合规率性能维度记录P95延迟、吞吐量成本维度算单次请求的GPU成本和总调用成本。这个框架最有价值的地方在于把“感觉模型变聪明了”这种模糊判断转成了可量化的标准。每次改动模型、数据或RAG配置都跑同一套评测看一下指标是升是降。从零搭建阶段没有这个闭环你根本无法判断改动方向对不对。6.2 评测集构造业务测试集加红队测试集评测集不能只找“简单题”。我们构造了两套评测集一套是业务测试集从历史真实工单里抽300条典型问题对应标准答案由业务方审核确认另一套是红队测试集专门用来“找茬”包含常见刁钻问题、需要拒答的问题、模型容易一本正经胡说八道的问题。红队测试集很重要。我们第一次评测时模型在业务测试集上表现很好但放到红队测试集上立刻暴露了问题面对超出知识范围的问题不会主动说“不知道”而是编造答案。后来我们在微调和RAG两个环节都加了拒答逻辑才把红队通过率提上去。6.3 数据飞轮让系统越用越准的迭代节奏评测的最终目的不是给个结论而是驱动迭代。我理解的“AI工程”和“传统软件工程”最大的区别就在这里传统软件上线即结束AI系统上线才是开始。我们建立了周级的迭代节奏每周从真实线上日志里挖出模型回答不合格的case人工修正后加入评测集和训练集再跑一轮微调和评测。这样滚动两三个月后系统在典型业务问题上的准确率从刚上线时的75%提升到了91%这个提升完全是数据飞轮带来的不是换个大模型能比的。7. 完整实操记录从零到上线的一次真实推进过程7.1 时间线和关键里程碑把前面这些内容落到时间线上能更直观地看到从零推进需要多久。我们团队实际用了大约十周完成首版上线。第1到2周做需求拆解和模型选型同时搭好基础环境GPU服务器、容器化平台、代码仓库。第3到4周集中做数据收集和清洗产出了第一批约8000条SFT数据和约2万篇可检索文档。第5到6周跑通LoRA微调流程训练出第一个可用模型同时搭起RAG原型。第7到8周部署推理服务整合API网关和业务后端完成端到端联调。第9到10周构造评测集跑出首个正式评测结果修复暴露的问题后上线。这里想特别提醒一句前期数据准备的两周是最难熬的看不到模型效果容易怀疑方向。但数据工作的复利效应会在微调和评测阶段集中爆发一定不能跳过或压缩。7.2 关键节点的现场记录与心得第一个关键节点是微调首跑。我们当时用8000条数据训练loss降到0.8左右但实测效果很差模型经常重复问题中的原话。排查后发现是SFT数据里有一部分答案直接从原文摘抄模型学到的只是“抄原文”而不是“回答问题”。清洗掉这批数据后效果立刻改善。这个案例我后来反复讲数据质量的问题会在模型效果上放大显现不要指望模型自己“悟”出正确答案。第二个关键节点是RAG接入。接入前模型面对文档细节问题经常出错接入后引用来源成了回答的标配。做RAG时体验建议先跑通最小闭环切分-向量化-检索-拼接-回答再逐步优化切分大小和重排序不要一开始就追求完美配置。第三个关键节点是压测。上线前我们压了一轮并发发现P95延迟高达3秒远超业务要求的2秒。优化方案是降低max-model-len、开启vLLM的prefix caching以及把无关的日志输出降到最低最终P95降到了1.2秒。排查延迟问题时我非常建议用分阶段打点的方式定位瓶颈而不是靠猜。8. 常见问题与避坑实录8.1 高频问题速查表把这几个月里反复被问到的问题整理成一张表基本覆盖了从零搭建AI工程最常见的坑问题现象原因解决方案模型训练后变笨通用能力明显下降灾难性遗忘训练数据混入10%-20%通用数据模型答非所问训练集loss低但效果差SFT数据质量差严格抽检数据去掉回答含糊的样本生成内容重复输出不断重复某句话训练轮数过多或学习率过高减少epoch调低学习率推理延迟过高并发一高响应就慢max-model-len过长或显存碎片化调低max-model-len开启vLLM优化检索结果不相关RAG回答引用错误文档chunk过大或切分方式不对调小chunk增加重叠使用重排序上线后模型乱答遇到未知问题不会拒答缺少拒答训练和评测构造拒答数据集做红队测试8.2 几条独家避坑技巧第一显卡显存不够时不要只想着加卡。先检查是不是数据加载和中间缓存占用了太多显存开启gradient_checkpointing可以把激活值显存占用降低约30%到60%。第二评估“效果够不够好”一定要结合业务场景。我们的经验是与其追求模型在通用评测集上刷分不如把测试集做成你的真实业务问题集。评测与业务脱节是AI项目最大的隐性风险。第三微调模型版本要进行规范化管理模型文件名带日期和数据版本号。没有版本管理时上线后发现效果回退根本说不清用的是哪个模型。第四尽量做好服务可观测性。除了常规的请求日志、耗时指标还要记录模型每次回答的置信度、检索命中的文档ID。没有这些信息线上出了问题就只能干瞪眼。8.3 后续还能怎么扩展这套系统从零搭建的AI工程能力绝不只为单一场景服务。我们在这套基础之上已经复用了数据管线、微调流程和推理服务接入了智能客服、文档问答、工单分类三个业务场景。每次新场景接入核心流程都不用重来只需要换数据、换评测集、重新微调。往前走的方向有两个一是把单轮问答升级成多轮对话系统需要考虑上下文管理和记忆机制二是把系统从“回答问题”升级为“执行动作”比如自动生成工单回复、自动提取结构化信息。这套从零搭起来的地基越往后越值钱。就我自己的体会来说从零做AI工程最怕的不是技术太难而是用错了力气。我们有过半个月的时间花在调模型效果上最后发现数据清洗几分钟就能带来的提升远大于算法调参。也希望这份记录能让你少走一点弯路把力气花在数据、链路和评测这些真正决定成败的事情上。