1. 为什么我最终选择了微调这条路1.1 从RAG的甜头到瓶颈去年下半年我接手了一个垂直领域的问答项目需求很明确让模型能准确回答某专业领域的细节问题。第一反应当然是上RAG毕竟那会儿“RAG知识库”几乎成了大模型落地的标配方案。我用了不到一周时间基于LangChain搭了一套检索增强的流程把领域文档切片、向量化、存进向量库再挂到对话链路上。刚开始效果确实不错问一些文档里明确写过的内容命中率挺高回答也像模像样。但用着用着问题就来了。用户的问题稍微绕一点比如需要跨多个文档做推理或者问的是“为什么”而不是“是什么”RAG就开始露怯。检索回来的片段要么不完整要么相关性不够模型拿到一堆半成品上下文生成出来的答案就开始胡编。我调了切片大小、换了嵌入模型、加了重排序命中率从60%多提到了75%左右但再往上就卡住了。这就是典型的RAG瓶颈检索环节的天花板决定了整个系统的上限。更麻烦的是风格问题。这个领域有一套自己的表达习惯和术语体系RAG只能把原文片段塞给模型模型输出的语气、格式、推理方式还是通用助手那一套。用户一看就知道“这不是我们这行的说话方式”。我试过在提示词里写大量风格约束效果有限而且提示词越写越长token成本上去了稳定性反而下来了。1.2 微调到底解决了什么问题痛定思痛我开始认真考虑微调。这里得说清楚一个认知微调不是用来替代RAG的两者解决的是不同层面的问题。RAG解决的是“知识从哪来”微调解决的是“模型怎么用这些知识、怎么说话、怎么推理”。打个比方RAG像是给模型配了一本参考书考试时可以翻微调像是让模型重新上了一学期专业课把知识内化成了本能。具体到我的场景微调要解决三个RAG搞不定的问题。第一是领域推理能力模型需要学会这个领域的思考方式比如先看什么指标、再怎么推导、最后怎么下结论这套逻辑链靠检索是拼不出来的。第二是输出风格包括术语使用、句式结构、甚至标点习惯这些得靠大量领域语料“喂”出来。第三是抗干扰能力RAG检索到噪声片段时模型容易被带偏微调后的模型对领域内外的内容有更强的判别力。当然微调也有代价。训练需要GPU资源数据标注要花时间调参有门槛而且一旦领域知识更新微调模型不会自动跟进。所以我的最终方案是RAG加微调的组合微调负责打底让模型具备领域推理和表达的基本功RAG负责补充最新、最细的事实性知识。两者各司其职效果比单用任何一个都好。1.3 工具选型为什么是LlamaFactory加LoRA确定了微调路线接下来是工具选型。市面上主流的微调框架我基本都试了一遍最后锁定在LlamaFactory加LoRA的组合。先说LoRA它的核心思路是不动原模型参数只在注意力层的权重矩阵旁边挂两个低秩矩阵训练时只更新这两个小矩阵。这样做的好处太明显了显存占用大幅下降训练速度快而且可以针对不同任务训练多个LoRA适配器推理时按需加载。我实测下来7B参数的模型做LoRA微调单张24G显存的卡就能跑起来batch size设到4左右梯度累积几步效果已经能看了。如果用全量微调同样的卡连模型都加载不进去。LoRA的另一个好处是灾难性遗忘风险低因为原模型参数冻结了学到的通用能力不会被覆盖掉。选LlamaFactory是因为它把训练流程封装得足够简单同时又保留了足够的可配置性。配置文件用YAML写数据格式支持Alpaca和ShareGPT两种主流结构训练、评估、导出、合并一条龙。我试过用原生Transformers手写训练循环光是数据整理和分布式配置就折腾了两天换到LlamaFactory之后半天就跑通了第一个实验。对于我这种不是专门做训练工程的人来说这个效率提升是决定性的。2. 数据准备微调成败的八成在这里2.1 数据格式与结构设计微调圈子里有句话数据决定上限算法只是逼近上限。我踩的第一个大坑就是数据。一开始我直接把RAG用的文档切片拿过来当训练数据格式是“问题-答案”对答案就是原文片段。训出来的模型确实能背出一些内容但推理能力几乎没提升而且回答生硬得像在念稿子。后来我才想明白微调数据的核心不是“知识量”而是“示范”。你要示范给模型看面对这类问题应该怎么思考、怎么组织语言、怎么给出结论。所以数据格式得从“问答对”升级成“指令-推理-回答”的三段式。指令部分描述任务推理部分展示思考过程回答部分给出最终输出。这样模型学到的就不只是答案本身而是生成答案的完整路径。具体到我的领域一条典型数据长这样指令是“请分析以下案例中的关键风险点”推理部分是“首先看A指标它反映了……然后对比B数据发现……综合判断风险主要集中在……”回答部分是最终的结构化结论。这种数据构造方式明显更费功夫但训出来的模型推理链条完整得多。2.2 数据量与质量平衡关于数据量我走过两个极端。一开始觉得越多越好凑了五千多条结果里面大量重复和低质样本训练loss降得很快但验证集效果很差典型的过拟合。后来砍到八百条精标数据效果反而上来了。我的经验是对于垂直领域微调一千到三千条高质量数据足够让模型学会领域风格和基本推理模式再多就需要考虑数据多样性而不是单纯堆量。质量把控上我总结了几个硬标准。第一答案必须准确宁可少不可错一条错误样本的负面影响可能需要十条正确样本来抵消。第二推理过程要真实不能为了凑格式硬编模型能识别出“假推理”。第三语言风格要统一如果一半数据用书面语一半用口语模型输出会精神分裂。第四覆盖要均衡不能某类问题占了八成其他类型就几条那样模型会偏科。提示数据清洗时建议用脚本做去重和长度过滤但最终的质量判断一定要人工过一遍。我试过完全依赖自动清洗结果把一些表述不同但实质重复的样本留下了训练时模型对这些内容过度拟合。2.3 数据标注的实操技巧标注这块我踩的坑最多。最开始我自己标标了三百条就发现标准开始漂移前面标的和后面标的风格不一致。后来改成先写一份标注规范把什么算好答案、推理步骤怎么拆、术语怎么用都写清楚然后找领域内的同事一起标标完交叉审核。这样效率虽然低一些但一致性有保障。另一个技巧是“反向标注”。先让基础模型对一批问题生成回答然后人工修改把错的改对、把啰嗦的改简洁、把风格不对的调过来。这样比从零写答案快很多而且修改过程中能发现模型的典型问题反过来指导数据构造。我大概用这种方式处理了六成数据剩下四成是纯人工撰写的高质量样本。还有一点很重要留出验证集。我一开始把所有数据都拿去训练结果完全不知道模型是真的学会了还是背下来了。后来按8比1比1切分训练、验证、测试集验证集用来调超参测试集只在最后评估用。这个习惯救了我好几次有一次训练loss降到0.3但验证集loss开始上升明显过拟合赶紧停了。3. LoRA微调实操从配置到跑通3.1 环境搭建与依赖安装环境这块我建议用conda建独立环境避免和系统Python打架。基础依赖就是PyTorch、Transformers、Datasets、Peft、Accelerate这几件套。LlamaFactory可以直接从源码装它会把依赖都拉齐。GPU驱动和CUDA版本要对上我用的是一张24G显存的卡CUDA 12.1PyTorch 2.1跑7B模型LoRA微调绰绰有余。显存不够的话有几个省显存的招。一是用4bit量化加载基座模型显存直接砍一半多代价是训练速度稍慢、精度略有损失。二是开梯度检查点用时间换空间。三是把batch size降到1靠梯度累积来等效大batch。我试过在16G显存的卡上用4bit加梯度检查点跑7B LoRA能跑但比较勉强建议还是24G起步。conda create -n llm_ft python3.10 conda activate llm_ft pip install torch2.1.0 transformers4.36.0 datasets2.15.0 peft0.7.0 accelerate0.25.0 git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .3.2 LoRA关键参数怎么设LoRA有几个核心参数直接决定训练效果和资源占用。第一个是rank也就是低秩矩阵的维度。rank越大能表达的变化越多但参数量和显存占用也越大。我试过rank从4到64最后发现对于领域风格适配rank设16到32就够了再大提升不明显反而容易过拟合。第二个是alpha一般设成rank的两倍比如rank 16就设alpha 32这个比例比较稳。第三个是target_modules也就是把LoRA挂到哪些层上。最常见的是挂到q_proj和v_proj也就是注意力的查询和值投影。我试过全挂上效果有提升但显存涨了不少。对于大多数场景q_proj加v_proj够用了。第四个是dropout设0.05到0.1之间防止过拟合。学习率我一般用1e-4到2e-4cosine调度warmup设总步数的3%到5%。# LoRA配置示例 lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 target_modules: [q_proj, v_proj] learning_rate: 1.5e-4 num_train_epochs: 3 per_device_train_batch_size: 4 gradient_accumulation_steps: 4 lr_scheduler_type: cosine warmup_ratio: 0.053.3 训练过程监控与调参训练启动后重点盯三个指标训练loss、验证loss、学习率曲线。训练loss稳步下降是正常的但如果降得太快比如两三百步就降到0.5以下大概率是过拟合前兆。验证loss先降后升就是过拟合的典型信号这时候要么减epoch要么加数据要么加dropout。学习率曲线要平滑如果震荡厉害说明学习率偏大。我一般会跑几个小实验来定超参。先用少量数据跑一百步看看loss趋势确认配置没问题再上全量。epoch数从2开始试不够再加。batch size在显存允许范围内尽量大配合梯度累积。训练过程中定期存checkpoint方便回滚到效果最好的那个点。我遇到过训到第三个epoch开始崩的情况幸好有checkpoint能退回去。注意LoRA微调时基座模型参数是冻结的所以训练loss不会降到特别低一般到0.8到1.2之间就差不多了。如果看到loss降到0.3以下别高兴太早大概率是过拟合了。4. 踩过的四个坑与排查实录4.1 坑一数据格式不匹配导致loss不降第一次跑训练loss从2.5开始几乎不降跑了几百步还在2.3左右晃。我以为是学习率太小调大了还是不行。后来检查数据发现LlamaFactory默认用的是Alpaca格式字段名是instruction、input、output而我准备的数据用的是question、answer。字段对不上模板渲染出来的训练文本全是乱的模型根本学不到东西。排查这类问题有个简单办法在训练脚本里加一行打印把tokenizer处理后的第一条样本decode出来看看。正常情况应该能看到完整的指令、推理、回答结构如果看到一堆空字符串或者乱码那就是格式问题。改数据格式或者改模板配置都能解决我选择改数据格式因为Alpaca是主流标准后续换框架也方便。4.2 坑二显存溢出与梯度累积的坑第二个坑是显存溢出。我把batch size设到8想着大batch训练稳结果一跑就OOM。降到4还是OOM降到2勉强能跑但速度慢得感人。后来才搞明白显存占用不只是batch size决定的序列长度影响更大。我的数据里有些样本特别长padding之后整个batch的序列长度被拉到最大显存直接爆掉。解决办法有两个。一是做长度过滤把超过模型最大长度的样本截断或丢弃我设的是2048个token。二是用动态padding让每个batch按实际最长样本padding而不是全局统一长度。这两个改完batch size设到4稳稳的。梯度累积设4等效batch size就是16训练稳定性也够了。4.3 坑三过拟合与灾难性遗忘第三个坑最隐蔽。训练到第二个epoch时训练loss降到0.6验证loss还在1.1我觉得还能再降就继续跑。第三个epoch训练loss到0.4验证loss开始涨到1.3模型在验证集上的回答开始变得奇怪通用能力明显下降问它一些领域外的问题也开始胡言乱语。这就是典型的过拟合加灾难性遗忘。LoRA本身对灾难性遗忘有缓解但不是完全免疫。如果数据量少、训练轮次多、学习率大照样会把基座模型的能力带偏。我的应对策略是epoch不超过3学习率不超过2e-4加dropout早停策略设patience为2。另外保留一个基座模型的副本训练完后对比一下通用能力有没有明显下降如果降太多就减少训练量或者混入一些通用数据一起训。4.4 坑四推理时LoRA权重加载失败训练完导出LoRA权重推理时加载死活不生效模型输出和基座一模一样。查了半天发现两个问题。一是导出时只存了adapter权重但推理时基座模型路径写错了加载的是另一个版本的模型adapter和基座对不上。二是推理框架的LoRA加载配置没开默认只加载基座。排查步骤很简单先确认基座模型路径和训练时一致再确认推理配置里LoRA相关参数打开了最后打印一下模型结构看看LoRA层有没有挂上去。如果用的是vLLM或者TGI这类推理引擎还要确认它们支持LoRA加载并且配置正确。我最后是用LlamaFactory自带的推理接口测通的确认权重没问题后再迁移到生产推理框架。问题现象可能原因排查方法解决方案loss不降数据格式不匹配decode第一条样本统一字段名和模板显存溢出序列过长或batch过大打印序列长度分布长度过滤加动态padding验证loss上升过拟合对比训练验证曲线减epoch加dropout早停LoRA不生效基座路径错或配置未开打印模型结构对齐路径开启LoRA配置5. 微调后的效果评估与RAG协同5.1 怎么判断微调真的有效评估微调效果不能只看loss得从多个维度看。我一般做三组对比基座模型、微调模型、微调加RAG。测试集覆盖领域内问题、领域边界问题、通用问题三类。领域内问题看准确率和推理完整性边界问题看模型会不会硬答通用问题看有没有能力退化。人工评估比自动指标靠谱。我找了三个同事做盲评把三个版本的答案打乱让他们打分从准确性、完整性、风格匹配度三个维度评。微调模型在风格匹配度上提升最明显从基座的2.1分提到4.3分5分制准确率从58%提到79%。加上RAG之后准确率进一步到86%但风格分略降到4.1因为检索片段有时会带进一些不协调的表达。5.2 RAG与微调的分工边界跑通之后我总结了一套分工原则。微调负责“怎么说”和“怎么想”RAG负责“说什么”。具体来说领域术语、表达风格、推理框架这些靠微调内化具体的数据、案例、最新动态靠RAG补充。微调模型作为主模型RAG检索结果作为上下文注入但注入时要控制比例检索内容占比太高会冲淡微调学到的风格。还有一个技巧是让微调模型自己判断要不要用RAG。我在训练数据里混入了一些“无需检索即可回答”的样本模型学会了对这类问题直接回答对需要外部知识的问题才触发检索。这样既省了检索开销又避免了检索噪声干扰。5.3 持续迭代的实用建议微调不是一锤子买卖。领域知识在更新用户问题在变化模型也得跟着迭代。我的做法是建一个反馈闭环线上收集bad case人工修正后加入训练数据每隔一两个月做一次增量微调。增量微调时学习率设小一点epoch少一点避免把之前学到的覆盖掉。LoRA的好处在这里又体现出来了可以基于同一个基座训练多个适配器比如一个通用领域适配器、一个特定任务适配器推理时按需组合。我目前维护了两个适配器一个负责问答风格一个负责报告生成切换成本很低。后续如果领域细分还可以继续加。提示增量微调时建议保留原始训练数据的一部分一起训防止模型只记住新数据而忘了旧数据。我一般按新数据七成、旧数据三成的比例混合。6. 一些个人体会这套流程跑下来最大的感受是微调的门槛在数据不在技术。工具已经足够成熟LlamaFactory加LoRA的组合让训练本身变得很简单真正花时间的是理解领域、构造数据、评估效果。如果让我重新来一遍我会在数据准备上投入更多时间把标注规范写得更细把验证集建得更扎实。另一个体会是不要迷信参数。我见过太多人一上来就调rank、调学习率、调batch size但数据本身有问题的话怎么调都是白搭。先把数据搞对再用小实验快速试参数最后用全量数据跑最终版本这个顺序不能乱。最后说一个实际的小技巧训练日志一定要存好每次实验的配置、数据版本、评估结果都记下来。我一开始没记后来想复现最好的那个版本翻了半天才找到对应的配置。现在我用一个简单的表格管理实验记录每次跑完填一行省了很多回头找的时间。