RAG失效后如何微调大模型？完整LoRA实战与踩坑记录

先说结论：RAG不是万能的，当你发现检索增强生成（RAG）的答案开始“一本正经地胡说八道”，或者召回的片段怎么也拼不成一句人话时，那就该考虑走模型微调这条路了。

我这次微调自己模型的起因很直接——在做垂直领域的知识问答时，RAG的表现让我越用越难受。检索回来的文档片段不是不够精准，就是和用户的问题句式对不上号。最典型的一种情况是：用户问“甲产品的退款政策是啥”，RAG搜回来的内容里偏偏只含“乙产品的退款流程”，嵌入向量的语义相似度在这个场景下根本区分不开这种细粒度差异。连续调了两周的提示词和切分策略，效果不升反降，我彻底放弃了在RAG里继续死磕，转而把目光投向微调。

如果你现在也在RAG的边缘反复试探，内心大概会有类似疑问：到底是数据切得不够细，还是嵌入模型不够好？说实话，这两个问题放在以前，确实能通过调参解决大部分，但当你的领域知识有强逻辑依赖、需要按固定格式输出、或者需要复刻特定说话风格时，RAG的能力边界就非常明显地暴露出来了。这篇不是纯理论科普，更像是我个人的“踩坑记录”加“完整落地复盘”，里面包含了方案选型、数据准备、训练细节以及大量调参心得。

这篇内容适合有两三个月大模型调用经验的开发者，也适合被RAG折磨得想骂人、正在纠结是否转向微调的产品和技术同学。只要你手里有几十条靠谱的领域问答数据，跟着这套流程走完，完全可以训出一个能用的垂直小模型。

1. 为什么RAG撑不住的时候，该换微调了

1.1 先搞清楚RAG失效的真正原因

RAG的核心工作流程不复杂：把用户的问题变成向量，去知识库里检索Top-K相关片段，把片段塞进提示词上下文，让大模型基于这些片段生成答案。这听起来很合理，但一到真实业务场景，问题就接踵而至。

第一个问题是检索精度不够。向量检索本质上是近似搜索，它衡量的是“语义相似”，但语义相似不等于“逻辑正确”。比如用户问“服务器内存条插槽有几个”，知识库里有“该型号服务器有24个内存插槽，支持DDR5 ECC内存”这段描述。理论上这应该能匹配上，但如果知识库里同时存在大量类似服务器的规格文档，检索出来的结果往往是好几个型号混在一起，模型看到上下文里一堆相近但不完全一致的信息，最终靠猜拼出一个答案，出错率自然高。

第二个问题是格式和风格的强约束。RAG只能保证“内容被带进上下文”，它没法保证“回答结构和风格可控”。比如你要求客服机器人先道歉、再给方案、最后给补偿措施，RAG模式下这些话术很可能随机排列，因为基础模型不知道你的业务场景有固定的回复话术要求。让一个通用模型每轮都被提示词摁着头输出固定格式，这个方式的稳定性极其依赖提示词工程，稍微偏离一点就乱套。

第三个问题，也是很多人忽视的：知识密集型的交互场景，RAG在推理效果上并不占优。像政策解读、法条比对、产品配置推荐这些场景，问题的正确答案往往并不直接存在于某一篇文档中，而需要综合多篇文档的信息，经过逻辑推理才能得到。RAG把相关片段堆给模型，模型还得自我消化融合——说实话，这一步经常掉链子，因为它本质上是在要求一个泛化模型在毫无领域训练的情况下做多跳推理，这已经不完全是检索问题了。

1.2 RAG和微调到底是什么分工

我得说清楚一个观点：RAG和微调不是敌对关系，它们是配合关系。RAG擅长解决“知识时效性”和“知识扩展性”的问题——知识库更新快、领域宽泛，适合用检索补充。而微调擅长解决的是“风格迁移”和“能力塑造”的问题——让模型学会特定任务的行为模式、输出格式和思维链条。

用个生活化的类比：RAG相当于给一个什么都懂一点但什么都不精的实习生配了一个搜索引擎，他需要什么就去查什么；而微调相当于把这个实习生送到专门的岗位培训学校，出来之后他不仅会查资料，更知道查到的资料该怎么组织成一篇像样的汇报。

所以在真实项目里，微调和RAG完全可以共存。你可以先微调出一个懂行业术语、知道回答话术的底座模型，再给它挂上RAG知识库用于实时查询最新信息。这也是目前企业和开发者落地大模型应用最成熟的方式。但如果你像我一样，主要痛点是“输出格式乱、术语不透彻、逻辑链条不稳定”，那么先微调，大概率能解决80%的问题。

1.3 什么信号出现，说明你该微调了

我在项目里总结了几个非常明显的信号，你对照看看中了几条：

• 提示词已经写了一千多字，但回答依然频繁偏离主题。
• 检索回来的片段“每个字都对”，但拼成答案后逻辑是碎的。
• 同一类问题一天回答得很好，第二天就翻车，结果高度不稳定。
• 领域内高频出现的固定说法、专业术语在回答中被普通词汇替代。
• 你发现自己不是在调模型，而是在无限循环调提示词。

当这些信号出现时，就别再头铁试“换个切分策略”或者“换个Embedding模型”了。RAG在这个阶段更多是掩盖问题，而不是解决问题。我个人的经验是：与其在检索链路里打补丁，不如直接花时间训一个真正“长在领域里”的模型。

2. 微调前绕不开的4个坑

2.1 坑一：忽略了基座模型该不该换这件事

很多人一上来就拿着ChatGLM或者Qwen做微调，但模型的基础能力和你任务的匹配度，直接决定了微调的上限。这里有个经常被忽略的基本原则：基座模型必须已经具备你领域的基础能力，微调是激发和聚焦，不是从零凭空捏造。

举个例子，你想要一个能写法律文书的模型，但基座模型本身在法言法语上的积累就一般，那你微调出来的模型大概率只是学会了你的数据格式，并不具备真正的法律逻辑能力。反过来，如果基座模型在一些公开的行业基准上已经表现不错，那么你只需要用高质量数据去引导它在你的场景里稳定发挥，效果会好得多。

我踩的第一个坑就在这里：一开始贪图参数小、部署方便，选了个较小的基座模型，结果微调完后发现它在复杂逻辑推理上根本练不出来。后来换成同一系列中更大的模型，数据量不变，效果却有明显提升。所以我现在的建议是：如果要微调，尽量选择7B级别以上的基座，能力上限完全不同。

另一个很容易踩的隐藏点：必须搞清楚你选的基座是不是支持长上下文。如果你的领域任务常涉及长文档、多轮对话历史，基座模型的上下文窗口长度不够，微调时数据一旦超长，截断后训练出来的效果会稀疏得令人崩溃。

2.2 坑二：只做指令微调，忽略了领域数据的结构化

指令微调（Instruction Tuning）是现在最主流的微调方式，思路简单——给模型一批“指令+回答”对，让它学会按指令输出。但很多人忽略了对领域数据的结构化处理，直接把一整段杂乱的FAQ丢进去训练，结果模型学会了“背诵”而不是“能力”。

我第二次踩坑就在这里。最初一批数据是从历史客服记录里剖出来的原始问答，有些问题是复合问句，有些答案是有三四层嵌套的表格结构，直接拿去微调后，模型遇到类似但不完全相同的问题，答得磕磕绊绊。后来我把数据重新整理成了分步骤的指令格式，把“类似问题”和“标准答案”之间的对应关系拆细，效果才真正提升。

现在做微调，一定要对数据进行清洗和重构——这不是可选步骤，而是必修课。结构化的领域数据不仅是喂给模型的原料，它本质上是在给模型建立“遇到某个任务时该走什么流程”的思维范式。

2.3 坑三：忽视数据的规模和质量之间的平衡

很多人第一次接触微调，会觉得数据量越大越好，恨不得一次性塞几万条训练数据进去。实际情况是——几千条结构清晰、数据干净的高质量样本，效果大概率吊打几万条参差不齐的数据。

模型微调的本质是在约束模型的输出分布，而不是让它从头学习世界知识。所以在微调阶段，数据质量扮演的角色远比数量重要。我当时最开始用了大约三千条不干净的客服记录，怎么训loss都降不动；后来把数据清洗到六百条高质量样本，效果反而显著提升。

数据质量的核心体现在三个方面：

• 正确性：答案本身必须专业无误。
• 多样性：问题要覆盖多种问法、多种表达方式。
• 一致性：答案的风格、结构、详略程度要统一。

在做数据时，我强烈建议把三种典型数据混合使用：一部分是高频业务问答，一部分是带有推理过程的多步问答，还有一部分是特定输出格式的示例。这样模型既不会丢失通用能力，又能针对业务场景做专门适配。

2.4 坑四：没有给微调留出充足的验证数据

这个坑最为致命，也最容易被新手忽略。很多人训完模型一看训练loss降得很低就急着欢天喜地部署，结果一到真实业务场景里立刻翻车。

原因很简单：微调是最容易发生过拟合的环节之一，特别是你数据量不大、训练轮次又多的时候。模型可能把训练数据里的表述背了下来，但对变体问法和上下文微调毫无泛化能力。

我在做微调的时候，特意从全部数据里抽出了20%作为验证集，剩下的80%作为训练集。而且验证集不是随机抽样，而是特意把每个业务场景的典型问法都留了一点放进去。这样训完以后，我可以用验证集快速检验模型在全新数据上的表现。如果验证loss和训练loss差距太大，那大概率是过拟合了，需要立刻减少训练轮次或加大数据量。

这一步看上去不起眼，却是保证你的模型“能干活”和“只会背卷子”之间最关键的分水岭。

3. 微调方案选型与工具准备

3.1 全参微调还是LoRA（大语言模型低秩适配微调）？

微调模型目前有两条主流路线：全参微调（Full Fine-tuning）和LoRA微调。全参微调很好理解，就是调整模型所有的权重参数。LoRA则完全不同，它冻结了模型原有的权重参数，只训练一小部分低秩矩阵，通过这种方式以极低的成本实现接近全参微调的效果。

LoRA这个名字现在在社区里几乎成了微调的代名词，原因很简单：性价比太高了。以一个7B参数的模型为例，全参微调在消费级显卡上基本不可能完成，但使用LoRA，你只需要训练大约0.1%到1%的参数量，显存占用可以成倍降低。

下面是我个人常用来做方案决策的一张对照表：

这次的项目我毫不犹豫选了LoRA实践。整个微调过程是在一张24GB显存的消费级显卡上完成的，这也让“训自己的模型”这件事真正变得接地气可复现。

关于消费级显卡的显存选择，再补一句：如果你想在24GB甚至更低显存上做微调，建议优先考虑模型的量化版本加LoRA的组合。QLoRA的技术方案把基座模型量化到4bit，训练层仍然保持较高的数值精度，效果退化在可接受的范围内，但显存和速度的优势非常明显。

3.2 微调工具链选择：从Unsloth到Hugging Face全家桶

工具选型是我觉得微调流程里提升幸福感最大的一项。早期我用的是Hugging Face的Transformers库加PEFT库自己写训练循环，能做是能做，但很多工程细节比如注意力机制的显存优化、断点续训、混合精度处理，都得自己动手处理，效率不高。

后来换成Unsloth之后，整个体验完全变了。Unsloth的核心优势在于它对LoRA训练做了大量的底层优化，在训练速度上比原生Transformers加PEFT的组合能快出2到5倍，并且显存占用降低了不少。我实测训练7B模型时，上下文长度为2048、Batch Size为4的情况下，24GB显存完全没有压力。

如果你是第一次上手，我建议直接选Unsloth，省下的折腾时间足够你多试几轮超参了。如果你更看重生态兼容性，或者后续需要做复杂的模型定制结构，那还是老老实实用Hugging Face Transformers + PEFT，虽然繁琐但完全可控，生态里出了任何工程问题也都能找到解决方案。

3.3 准备一个能跑的Python环境

微调前最重要的准备工作是搭环境。这里给出一个我常用的依赖清单，按顺序装完基本不会出问题：

pip install unsloth pip install --upgrade transformers pip install datasets pip install trl pip install accelerate pip install bitsandbytes

如果你用的是Unsloth，确认CUDA版本和PyTorch版本匹配尤为重要。我建议直接去Unsloth的官方仓库看它的环境要求说明，它针对不同CUDA版本提供了对应的安装选项，避免了大量自己排查环境问题的无用功。

装好环境以后，建议先跑一段简单推理确认环境没问题，再进入正式训练流程。这个检查步骤看起来多余，实际能帮你节省好几个小时的排障时间。

4. 数据准备与训练实操全流程

4.1 数据格式设计：不同框架的通用结构

无论选什么框架，LoRA微调的数据格式都有一个最通用的基准——对话结构。现在主流微调框架都支持把数据组织成“系统提示词、用户输入、模型输出”的三段式结构。

下面是我在微调时经常用的数据格式示例：

{ "messages": [ {"role": "system", "content": "你是一个熟悉智能客服业务的专家，回答用户问题时必须简洁、准确，并以步骤列表给出操作建议。"}, {"role": "user", "content": "用户提交了退款申请，但超过了七天，怎么办？"}, {"role": "assistant", "content": "1. 首先确认用户的订单是否在售后保护期内；2. 若已超过七天，引导用户补充商品异常照片；3. 等待平台审核，一般在1-3个工作日内处理；4. 审核未通过时，主动建议用户发起人工客服复核。"} ] }

这样的数据结构最大的好处是：它很好地向模型示范了在特定业务场景里“怎么组织一段回答”。你甚至可以通过精心设计系统提示词，在微调过程中一并把模型的回答风格固定住。

当训练数据量少时，这种基于对话格式的样本输出效果极好，因为模型学习的不是回答内容本身，而是“遇到这类输入，输出这类结构”的行为模式。

4.2 数据清洗与增强全流程细节

数据清洗这事，我建议用半自动化的方式处理。先用脚本做一轮硬规则过滤，比如去重、剔除过短回答、过滤违规字符等，然后人工对剩余的关键数据进行逐条审阅。硬规则过滤能快速缩减工作量，人工审阅才能保证每条数据的业务准确性。

数据增强方面，我用过一个很实用的小技巧：对高频问题做近义改写。比如“退款多久能到账”改成“申请退款后资金什么时候退回”，让模型见过更多样的问法，泛化能力自然变强。这一步成本低，但对微调效果的提升非常显著。

再提醒一个高频踩坑点：训练数据中千万别出现答案和问题不对应的情况。有时候从历史工单里抽出来的问答，问题属于A场景，答案却包含了B场景的处理逻辑，这种脏数据一旦混进训练集，模型会越训越混乱。数据清洗的核心不是追求“多”，而是尽量追求“准”。

4.3 实操训练：写一段能直接跑起来的LoRA训练代码

这个环节直接上代码。下面这段是以Unsloth为基础，配合Hugging Face生态完成的LoRA训练流程，代码结构和参数比较完整，照着复制、替换掉数据集路径就能跑通自己的第一次微调。

import torch from unsloth import FastLanguageModel from datasets import load_dataset from trl import SFTTrainer from transformers import TrainingArguments # 第一步：加载4bit量化的基座模型（消费级显卡的性价比选择） max_seq_length = 2048 dtype = None load_in_4bit = True model, tokenizer = FastLanguageModel.from_pretrained( model_name="unsloth/Qwen2.5-7B-bnb-4bit", max_seq_length=max_seq_length, dtype=dtype, load_in_4bit=load_in_4bit, ) # 第二步：给模型添加LoRA适配层，目标是只训练少量参数 model = FastLanguageModel.get_peft_model( model, r=16, # 秩的大小，常见范围是8到32 target_modules=[ "q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj", ], lora_alpha=16, # LoRA缩放系数，一般与r保持一致或为其2倍 lora_dropout=0, # 实测dropout设0反而稳定 bias="none", use_gradient_checkpointing="unsloth", # 省显存的关键参数 random_state=42, ) # 第三步：加载训练数据，字段映射成messages格式 dataset = load_dataset("json", data_files="train_data.jsonl", split="train") def formatting_func(example): return [{"role": "system", "content": example["system"]}, {"role": "user", "content": example["user"]}, {"role": "assistant", "content": example["assistant"]}] # 第四步：设置训练参数并启动训练 training_args = TrainingArguments( per_device_train_batch_size=2, gradient_accumulation_steps=4, # 等效batch size为8 warmup_steps=20, max_steps=300, # 也可以按epoch数设置 learning_rate=2e-4, fp16=True, # 根据显卡选择混合精度方案 logging_steps=10, optim="adamw_8bit", weight_decay=0.01, lr_scheduler_type="linear", seed=42, output_dir="outputs", ) trainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, formatting_func=formatting_func, args=training_args, max_seq_length=max_seq_length, ) trainer.train() # 第五步：保存LoRA权重并合并导出（这一步很重要） model.save_pretrained("lora_model") model.save_pretrained_merged("merged_model", tokenizer, save_method="merged_16bit")

这段代码是我实际跑通后精简出来的版本，各步骤都有必要注释，特别适合第一次接触微调的同学。有几个参数在后面做解读，拉练过程中你可能会反复调整它们。

4.4 关键参数怎么定：rank、学习率与训练轮次

如果你以前没接触过LoRA，第一个疑问肯定是“r=16是啥意思”。从原理上讲，LoRA用两个低秩矩阵A和B的乘积来模拟权重更新量，r就是这两个矩阵的秩。r越大，可训练参数越多，模型对数据的拟合能力越强，但也更容易过拟合；r太小，可学习容量不够，效果出不来。

常用的经验值：8到32之间。如果你的数据量不大，或者担心过拟合，选8；数据量充足、任务较复杂，选16或32。这次我用了16，属于最稳妥的中位数。当然，如果你在某个任务上怎么调都达不到预期，把r翻倍试一次也是很快的验证手段。

学习率是另一个敏感参数。LoRA训练一般把学习率设在1e-4到3e-4之间，常用2e-4。学习率设置过大，训练会震荡；过小，训练速度慢，而且容易收敛到比较差的局部最优。如果你发现训练过程中loss一直跳来跳去，把学习率降一半再试。

训练轮次的话，我建议从1到3轮开始。很多经验帖会把epoch调到10甚至20轮，实际效果通常不太好，因为模型很容易把训练数据死记硬背下来。我更喜欢用“步数”而不是“轮次”来控制训练，这样可以更细粒度地观察验证集的变化，找到那个“再训一步就开始过拟合”的临界点。

关于Batch Size的抉择，有条件的话尽量用大一点的Batch。Batch Size太小时，梯度估计的噪声大，训练不稳定。显存不够时，优先开梯度累积，让等效Batch Size保持在8左右即可。

5. 训练过程诊断与效果评估

5.1 如何判断训练有没有“训进去”

训练不是跑完脚本就算成功。你需要一边训练一边观察loss曲线，并学会分辨“正常下降”和“异常波动”。

正常情况下，训练loss应该在前面几十步快速下降，随后进入平滑收敛区间。如果loss在某个阶段突然猛跌然后一直低位徘徊，先别高兴，要警惕过拟合的可能——训练数据背熟了，但泛化能力到底如何要另外看。如果loss一直居高不下，反复震荡，大概率是学习率太大或者数据本身存在脏标签。

更准确的做法是切出验证集，训练过程中每若干步对验证集做一次快速评测。验证loss不降反升时，就是过拟合信号出现的时刻，这时候立刻停止训练，回到之前那个验证loss最低的检查点。

我当时设置的max_steps是300，在训练到大约240步时验证loss开始反弹，于是果断回滚到230步的检查点作为最终模型。这比硬着头皮把300步全部跑完要明智很多。

5.2 构造一套面向业务场景的评测集

这是评估环节最容易被省掉、也最不该省掉的一步。模型训完以后，当然要去跑各种评测基准，但更重要的是构建一套属于自己业务场景的评测集。

评测集不需要大，30到50条有代表性的问题就够了。关键在于覆盖面——每个主要业务场景都要有几条，每条都要配一个参考答案。评测的时候不看什么精确匹配率，直接用肉眼逐条看生成结果，重点关注三个维度：术语是否准确、格式是否符合要求、语义逻辑是否严谨。

我把三类典型问题写进评测集：

• 业务高频问题，相似问法至少两种。
• 需要多步骤推理的复杂问题。
• 容易混淆的政策条款对比问题。

评估时用“通过/不通过”来打分比用分数更直观有效。通过率超过90%，基本可以灰度上线；低于70%，说明数据或训练参数还有优化空间，得回头重新调。

5.3 微调完之后，还要做一轮通用能力评测

微调最让人担心的后遗症之一是“灾难性遗忘”——模型在垂直领域变强了，但常识问答、基础数学、逻辑推理等通用能力退化严重。这在大模型应用场景里是绝对要避免的。

我通常会在微调前后各跑一组通用能力题目，做一个AB对比。比如让模型做几道数学题、复述一段常识、写一段简单的文案，再看看有没有明显退化。如果退化明显，我的处理办法是往训练数据里掺一些保留通用能力的通用语料，或者降低LoRA的秩和学习率。微调应该是给模型“加装技能”，而不是“推倒重建”。

6. 常见问题与排查技巧实录

6.1 显存不够怎么办

显存问题是新手微调的“第一大拦路虎”。除了换成更小尺寸的模型或者用量化版本，我最常用的招数还有三个。开启梯度检查点，这是最立竿见影的省显存手段，用训练时间换显存空间，非常值得；降低Batch Size并增加梯度累积步数，等效Batch不变，显存直接下降；把序列长度从2048降到1024，如果业务上没有超长依赖需求，这个调整几乎没有副作用。

如果这些都不够，就用QLoRA方案，也就是加载4bit基座模型再做LoRA。这个方案已然无比成熟，实测下来效果接近标准LoRA，但显存需求进一步大幅降低。

6.2 训练loss乱跳是怎么回事

训练过程中loss乱跳，优先检查数据。常见原因是训练数据里有异常长的样本、包含特殊符号的样本，或者有两条内容互相矛盾的样本。把这些数据先挑出来单独跑一轮，问题往往就暴露了。

如果数据干净但loss仍然乱跳，那就是学习率的问题。把学习率从2e-4降到1e-4再试，多半能稳住。另外，warmup步数别设得太短，给模型一点适应数据分布的时间。

6.3 微调后效果还不如基座模型？

遇到这种问题，先冷静排查几个方向。检查评测数据本身是否有问题，比如评测的参考答案本身就标注得不够严谨；检查是否过拟合，减少训练步数或增加数据多样性是优先尝试的方案；检查数据格式是否太单一，导致模型只在特定模板下才会输出好答案。

排除了这些因素后，如果效果还是不行，就得回头看看基座模型的选择了。你要做的任务和基座模型擅长领域的匹配度，往往决定了最终微调效果的上限。

6.4 LoRA合并后去哪了

LoRA训练完出来的是两个小矩阵文件，它们本身不改变原模型，真正用起来时得先合并再部署。用merge_and_unload方法把LoRA权重融合进基座模型，或者用save_pretrained_merged直接导出合并后的模型文件。这一步一旦省略，直接部署LoRA模型文件，推理时会发现模型行为和基座模型完全一样，白训一场。

合并时还有一个细节，尽量用float16格式导出。如果导出格式不对，部署时可能遇到数值精度问题，效果会打折扣。

7. 从模型训练到落地部署的最后一公里

7.1 在本地快速验证合并后的效果

合并完模型后，先用最简单的推理脚本来一轮验证。加载合并后的模型，把你的评测集逐条测一遍，看看输出是否正常。这一步要人工做，别急着上服务，也别急着写API。

验证时我习惯把基座模型、LoRA微调模型、合并模型三者对比输出，这样能直观感受微调带来的差异。如果合并模型的输出和纯LoRA加载结果一致，说明合并没有问题；如果出现了微妙的偏差，多半是量化或数据类型不一致导致的。

7.2 用Transformers加载并启动一个快速推理服务

本地验证通过后，最快的部署方式就是直接用Transformers写一个轻量接口。下面这段代码是最小可用的推理服务骨架：

import torch from transformers import AutoTokenizer, AutoModelForCausalLM model_path = "./merged_model" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype=torch.float16, device_map="auto", ) def generate_answer(prompt): messages = [ {"role": "system", "content": "你是一个熟悉智能客服业务的专家，回答问题时必须简洁、准确。"}, {"role": "user", "content": prompt} ] text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) inputs = tokenizer([text], return_tensors="pt").to("cuda") outputs = model.generate( **inputs, max_new_tokens=512, temperature=0.7, top_p=0.9, do_sample=True, ) response = tokenizer.decode(outputs[0], skip_special_tokens=True) return response print(generate_answer("用户提交了退款申请，但超过了七天，怎么办？"))

这里最值得注意的就是apply_chat_template这一步——它确保输入格式和训练时的格式保持一致。很多人部署时效果不对，就是因为推理时的输入模板和微调时的不一样，导致模型行为完全变味。

7.3 作为垂直领域基座接入RAG与Agent框架

模型部署好了并不意味着一定要把RAG抛弃。如果你面临的问题既有“格式混乱”又有“知识更新”，更合理的架构是：用微调模型当作垂直领域底座，专门负责回答的组织逻辑和话术风格，再在系统外层挂上RAG做实时的知识补充。微调决定了你“怎么说”，RAG决定了它“查什么”，两者互补能覆盖更完整的生产链路。

如果你有Agent框架的接入需求，微调模型完全可以作为大模型接入层的可替换模型来使用，只需把模型服务的接口做成标准OpenAI兼容格式。这样智能体框架里只需修改模型服务地址，就能无缝切换。实测下来，垂直微调过的模型在Agent任务里的工具调用动作明显更精准了——这是我在纯RAG配置中完全做不到的。

8. 微调之后的一些真实体会

整个流程走下来最大的感受是：微调并没有想象中那么神秘，但每一个环节都卡得比较严，数据质量尤其决定了最终效果的上限。之前用RAG时，总觉得每次调切分策略或嵌入模型都是“隔靴搔痒”，问题好像解决了，但又没完全解决。微调之后，模型终于能说出符合业务逻辑和风格的话了，这种差异非常直观。

我个人在实操里的一个小习惯：每次微调实验都完整记录数据版本、参数设置、评估结果。看似麻烦的操作，在后续多轮迭代时能帮你节省大量重新摸索的时间。LoRA权重文件的迭代速度非常快，一个项目一天内跑十几个版本都是常态，没有记录的话基本全靠早起晚睡的记忆来凑。

最后再分享一个经验：不要轻易放弃LoRA去追求全参微调。绝大多数业务场景下，LoRA的表现完全够用，全参微调的资源消耗和部署复杂度高得多，换来那一点效果提升往往不值得。学会把LoRA的秩、学习率和数据质量这三个变量调明白，能解决掉日常开发中碰到的大部分微调需求。希望这篇文章能帮你少踩几个坑，快速跨过微调入门这道坎。