三天速通大模型微调：从LoRA到RAG、Agent与Harness实践

如果你正打算学大模型微调先别急着跑训练脚本。很多人的第一周是这样浪费的收藏了一堆教程下载了模型权重配置好环境结果训练到一半显存爆炸改完参数又发现数据集格式不对好不容易跑完模型答非所问加上 RAG 之后检索到的内容根本不是想要的想让模型调用工具又陷入死循环。问题往往不是“不努力”而是缺少一条最小可用的工程闭环。这篇博客基于 Qwen3.5讲一条三天之内可以走通的实战路线第一天准备环境与数据第二天跑通指令微调和 Prompt 调优第三天接入 RAG 和 Agent并用 Harness 做基础评测。我的核心判断是所谓“速通”不是把所有概念都背下来而是把“模型、数据、知识、工具、评测”这五层打通。读完你会得到一套可复制的微调流程三种让模型更“可控”的手段以及一份来自实践侧的避坑清单。本文会覆盖 Prompt、ReAct、RAG、Agent、QAT、Harness但不会停留在名词解释。你会看到它们如何在真实项目中相互配合也会看到每一步真正容易出错的地方在哪里。1. 先想清楚“三天速通”到底要通什么如果只看课程目录你会觉得要学的东西太多了注意力机制、Transformer、训练技巧、强化学习、量化部署……但“三天速通”的定位不是学术研究而是工程落地。建议把目标收敛成三件事拿到一个开源模型在本地跑通指令微调。让模型能在业务场景下稳定输出而不是只会聊天。把外部知识、工具调用和自动化评测接进来形成一个可用的应用系统。我建议的三天节奏是第 1 天搭建环境准备干净的数据集。第 2 天跑通 LoRA 微调合并权重再做 Prompt 调优。第 3 天接入 RAG 知识库、写一个最小 Agent 示例最后用 Harness 跑一轮评测。这里有一个关键认知微调不负责注入新知识它只负责对齐模型的行为。如果你想更新领域事实应该用 RAG 把外部知识挂载上去如果你想让模型能自主完成任务应该用 ReAct/Agent 方案如果你想知道模型改完到底有没有变好必须用 Harness 做评测。把这五层关系想清楚三天时间才够用。2. 概念框架Prompt、ReAct、RAG、Agent、QAT、Harness 如何配合很多人把上面这些名词当成并列的技术路线其实它们处于不同层面。先看一张简表概念核心作用和微调的关系Prompt控制模型输入引导输出格式和内容微调改变模型权重Prompt 改变模型“现场表现”ReAct让模型在“思考-行动-观察”循环中完成任务微调可以强化模型的工具调用能力但 ReAct 是运行机制RAG检索外部知识减少幻觉补充微调无法覆盖的实时领域知识Agent以大模型为核心自动调度工具和流程依赖模型能力也需要清晰的 Prompt 与工具定义QAT量化感知训练降低推理成本和显存在微调阶段模拟量化误差让模型更适应低比特部署Harness统一评测框架量化模型版本效果微调是否成功不能靠“感觉”要靠评测指标从工程视角看它们是一层层叠上去的。Prompt 是最便宜的“对齐手段”RAG 是最有效的“知识挂载方式”ReAct/Agent 解决“让模型动手做”QAT 解决“低成本部署”Harness 解决“怎么验收”。这就是为什么我会建议你从微调切入但不要只学微调。一个业务系统真正上线时Prompt、RAG、Agent、评测缺一不可。理解了这个框架后续每一步都不会再是孤立操作。3. 为什么是 Qwen3.5开源模型微调的选型判断以 Qwen3.5 为例做微调背后有清晰的工程考量。首先是可控性闭源 API 虽然调用方便但数据要传到第三方服务很多企业内部场景不允许这么做。开源模型可以私有化部署数据不出域这是合规层面的刚需。其次是成本。对于 9B 级别的模型单张 24GB 显存的 GPU 已经可以做 LoRA 微调如果使用 QLoRA 或者其他量化训练方案显存门槛还能更低。相比从头预训练指令微调的数据量也小得多通常几千条高质量样本就能看到明显效果。但选型时必须想清楚微调不是万能的。如果只是做一个客服助手先用 Prompt 加 RAG 往往成本更低。如果要求模型按固定 JSON 格式输出、或者需要模仿某种语气风格微调会更有价值。如果想让模型“记住”具体业务术语优先考虑 RAG如果想让模型“习惯”某种回答风格才需要微调。所以我的建议是先跑几个 Prompt 模板测试再决定要不要微调。真正上手后你会发现很多问题用 RAG 就能解决微调做得越多反而越容易把模型训“坏”。4. 环境准备与数据准备4.1 基础环境搭建我建议在 Linux 环境下操作兼容性最好。核心依赖是 Python、PyTorch 和 GPU 驱动。以下命令是通用流程具体版本以官方文档为准conda create -n llm python3.10 -y conda activate llm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121安装完成后先确认 GPU 是否可用nvidia-smi python -c import torch; print(torch.cuda.is_available())如果输出的是True说明 PyTorch 已经能够访问 GPU。这里真正容易踩坑的地方是 CUDA 版本和 PyTorch 版本不匹配。如果你发现torch.cuda.is_available()返回 False第一步不是重装而是先看nvidia-smi驱动版本和 PyTorch 编译时的 CUDA 版本是否兼容。为了减少重复造轮子我建议直接使用开源微调框架比如 LLaMA-Factory。它可以管理数据集、训练参数、LoRA 权重合并适合快速跑通流程pip install llama-factory[torch]再次强调不要盲目追求最新版本先确认框架 README 中支持的模型格式再决定下载哪个 checkpoint。4.2 准备指令微调数据集指令微调的数据集并不复杂最常见的是 Alpaca 格式包含三个字段instruction指令、input输入、output输出。下面这段脚本可以帮你生成一个最小的训练数据文件# 文件路径build_dataset.py import json samples [ { instruction: 你是一名电商客服请根据用户问题给出简洁回复。, input: 我买的东西还没发货想退款怎么办, output: 您可以先查看订单状态如果未发货可以在订单页面直接申请退款我们会在24小时内审核。 }, { instruction: 请将下面的句子改写得更礼貌。, input: 快点处理我的订单。, output: 您好我的订单遇到了一些问题请问可以尽快帮我处理一下吗谢谢 } ] with open(train_data.json, w, encodingutf-8) as f: json.dump(samples, f, ensure_asciiFalse, indent2) print(f已生成 {len(samples)} 条样本)这里的关键不是“代码能跑”而是数据质量。建议至少准备几百条覆盖真实业务场景的样本数量少没关系但要保证每条输出都准确、稳定。常见错误是把知识问答数据当成微调数据比如“中国的首都是什么”这类数据应该交给 RAG 或模型已有能力去处理而不是硬训进参数里。5. 微调实战用 LoRA 跑通最小闭环5.1 LoRA 微调配置LoRA 的核心思想是冻结原模型大部分参数只训练一部分低秩矩阵从而大幅降低显存占用。对于 Qwen3.5 这类大模型在消费级 GPU 上也可以尝试。下面是一份典型的训练配置# 文件路径train_qwen35.yaml model_name_or_path: Qwen/Qwen3.5-9B-Chat stage: sft finetuning_type: lora dataset: train_data.json template: qwen num_train_epochs: 3.0 learning_rate: 5.0e-5 per_device_train_batch_size: 2 gradient_accumulation_steps: 4 max_seq_length: 2048 output_dir: outputs/qwen3.5-sft logging_steps: 10 save_steps: 500 lora_rank: 16 lora_alpha: 32然后执行llamafactory-cli train train_qwen35.yaml这里需要解释几个关键参数per_device_train_batch_size单卡 batch size。显存不够时优先调低这个值。gradient_accumulation_steps相当于把多个小 batch 累积成大 batch间接提高稳定性。learning_rateLoRA 微调常见的学习率范围是 1e-5 到 5e-5过大会让模型“失忆”。max_seq_length训练时最大序列长度。超过这个长度的文本会被截断影响模型学习长上下文。训练过程中建议盯着日志里的loss值。如果 loss 一直不下降先检查数据集是否为空、样本是否重复而不是盲目加大学习率。5.2 合并 LoRA 权重LoRA 训练结束后产出的不是完整模型而是一套增量权重。推理时需要把它合并回原模型llamafactory-cli export \ --model_name_or_path Qwen/Qwen3.5-9B-Chat \ --adapter_name_or_path outputs/qwen3.5-sft \ --template qwen \ --finetuning_type lora \ --export_dir merged_qwen3.5-sft合并后的模型才能直接用于后续 Prompt、RAG、Agent 的实验。这一步经常被新手忽略直接用 adapter 目录推理结果发现行为没有变化。5.3 如何判断微调成功不要只看训练 loss 降下来了还要在验证集上跑几轮人工评测。准备几条和训练数据不重复的测试问题对比微调前后的回答。关注三个点输出是否格式稳定。是否出现复读、胡编等退化现象。在通用能力上是否明显变差。如果模型变“笨”了大概率是训练轮次过多或学习率过大。这也是为什么后面一定要接 Harness 做系统评测。6. Prompt 工程与内容安全微调完成后模型的行为基线发生了变化但真正直面用户的是 Prompt。很多场景下改 Prompt 比重新微调更快、更省钱。一个实用的 Prompt 模板是这样的你是{角色}负责{任务}。 要求 1. 回答必须简洁不超过200字。 2. 如果信息不足明确说“我不知道”不要编造。 3. 只基于提供的资料回答。 4. 使用JSON格式输出字段为{answer: 你的回答, source: 参考来源}。 以下是相关资料 {context} 用户问题{question}这个模板做到了三件事定义角色、限定输出格式、约束信息来源。实际项目中你会发现模型输出的稳定性很大程度来自这些“硬性约束”而不是模型本身的智商。调 Prompt 时可以按三步走先给一个空白模板观察模型的默认行为。逐步加入约束条件比如“只基于资料回答”“分点输出”。用少数 few-shot 示例锁定格式减少随机性。还有一种常见问题调用模型接口时提示invalid prompt: your prompt was flagged as potentially violating our usage policy。这通常是提示词里包含服务商认为违规的内容或者措辞容易触发审核策略。此时不要想着强行绕过限制而是先检查是否包含暴力、仇恨、违法或敏感词是否在测试“诱导模型输出不安全内容”是否在公开 API 上尝试了本地模型更容易接受的内容。如果你确实需要自由的实验环境更稳妥的方案是部署开源模型到本地自己控制安全策略和审核逻辑而不是依赖第三方接口。7. RAG 知识库落地指南RAGRetrieval-Augmented Generation是目前减少幻觉、补充实时知识最有效的手段。它的流程看起来简单文档切块、向量化、建索引、检索、拼 Prompt、生成。但每个环节都有坑。先看一个极简的检索示例用于理解“向量检索”这一步from sentence_transformers import SentenceTransformer import faiss import numpy as np embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) documents [ 订单退款规则未发货订单可直接申请全额退款。, 配送范围目前仅支持国内大部分城市。, 售后服务商品签收后7天内可申请换货。 ] embeddings embedder.encode(documents) index faiss.IndexFlatIP(embeddings.shape[1]) index.add(np.asarray(embeddings)) def rag_search(query, top_k1): vec embedder.encode([query]) scores, idx index.search(np.asarray(vec), top_k) return [documents[i] for i in idx[0]] print(rag_search(没发货能退款吗))这个示例虽然简单但它揭示了 RAG 的关键检索质量决定最终回答质量。如果向量检索返回的相关文档不对后面 Prompt 写得再好也没用。切块策略是 RAG 项目里最容易被低估的环节。块太大会导致语义混入无关内容块太小又会丢失上下文。实践经验是按段落切块每块控制在 300-500 token 左右。相邻块之间保留 50 token 的重叠避免切在关键句中间。对结构化文档优先按标题、表格、章节切分而不是固定长度硬切。还有一个进阶方向是 agentic RAG即让 Agent 自主决定什么时候检索、检索什么、是否需要多轮检索。它的价值在于处理复杂问题时不只做一次“查一下再回答”而是像人一样先拆解问题再分别检索。这也是 RAG 和 Agent 结合的代表性趋势。8. 从 ReAct 到 Agent让模型学会调用工具ReAct 是 Reasoning Acting 的组合。模型不再只是“回答问题”而是先生成推理再决定调用什么工具根据工具结果继续推理直到完成任务。这种循环模式是 Agent 的基础。下面是一个最小 Agent 循环的伪代码方便你理解整体结构import json def search_tool(query: str) - str: # 这里可以替换成真正的搜索 API 或数据库查询 return f关于{query}的实时数据暂无 def call_llm(messages): # 这里替换成 Qwen3.5 的推理接口 pass def run_agent(question): messages [{role: user, content: question}] for step in range(3): response call_llm(messages) messages.append({role: assistant, content: response}) if action_call in response: try: action json.loads(response)[action_call] except json.JSONDecodeError: return Agent 输出解析失败请检查 JSON 格式 tool_result search_tool(action[query]) messages.append({role: tool, content: tool_result}) else: return response return 达到最大步骤数未能完成任务这个示例的关键有两点一是让模型在需要外部信息时输出一个结构化的action_call二是把工具返回结果放回上下文让模型继续推理。实际项目中Agent 频繁报错很多都出在这个环节比如材料里提到的agent terminated due to error。遇到这类错误优先排查以下三类问题模型是否输出了非法 JSON。对策是限定“只输出 JSON”并在代码里做容错解析。工具返回格式不符合预期。对策是统一工具输入输出 schema避免模型理解混乱。循环步数设置过少或过多。太少会让复杂任务完不成太多会放大错误需要根据场景调整。还有一个值得关注的概念Skill。你可以把它理解为“高级版 Prompt 工具封装”。同一个 Agent 可以挂多个 Skill每个 Skill 负责一项专门能力比如查天气、查库存、写邮件。微调是让模型理解新 Skill 的必要性Prompt 则是每次调用时让模型清楚“当前 Skill 的使用说明”。9. 评测与生产化Harness、QAT 与常见问题9.1 用 Harness 做统一评测许多开发者在微调后只会做几轮人工对话凭感觉判断“变好了”。这种感觉在单一案例上有效但无法支撑模型迭代。Harness 的核心价值是提供一批可重复的评测任务让模型和模型之间、版本和版本之间可以直接对比。以 lm-evaluation-harness 为例一个典型的评测命令如下lm_eval --model hf \ --model_args pretrainedmerged_qwen3.5-sft \ --tasks ceval-valid,cmmlu \ --batch_size auto \ --output_path eval_result注意任务名称和参数以官方文档为准这里展示的是通用思路。评测时建议至少覆盖两类指标一类是通用能力比如 C-Eval、CMMLU另一类是业务场景自建集比如 50 条客服问答观察准确率和格式符合率。评测结果应该作为是否上线微调模型的依据而不是 train loss 或个人观感。9.2 QAT量化感知训练QAT 和 PTQ 是两种常见模型压缩方案。PTQ 是训练后量化直接把模型权重从 FP16 转成 INT8速度快但可能掉点QAT 是在训练阶段模拟量化误差让模型权重适应低比特表示精度损失更小但训练成本更高。在 Qwen3.5 微调项目中如果你最终要部署到边缘设备或低成本 GPU建议提前想清楚推理精度要求。如果只是本地演示可以先用 PTQ 快速压缩如果要长期稳定上线QAT 更值得投入。QAT 和 LoRA 并不冲突你可以在 LoRA 微调后的模型基础上做量化感知训练也可以直接训练量化模拟版本。9.3 常见问题与排查思路问题现象可能原因排查方式解决方案训练时显存溢出batch size 太大 / 序列太长查看nvidia-smi显存占用调低 batch size、缩短 max_seq_length或使用 QLoRAloss 不下降数据集格式错误 / 学习率过低检查 train_data.json 字段看日志 loss修正数据格式适当调大学习率微调后模型复读训练轮次过多 / 学习率过大对比验证集输出减少 epoch降低学习率混入通用数据Prompt 被内容策略拦截包含违规词或触发审核逻辑检查提示词词条调整措辞减少争议内容或本地部署模型RAG 检索不到相关文档切块策略不当 / Embedding 不匹配打印检索得分和前 top_k 结果调整切块大小更换领域 Embedding 模型Agent 反复报错或死循环工具输出解析失败 / 循环步数过多打印中间 messages限定 JSON 输出、增加解析容错、减少最大步数9.4 工程建议结合前面的实战过程这里给几条可以直接落地的工程建议小步快跑。先拿几十条样本跑通全流程再批量扩展到几千条避免一开始就融资级投入。数据与代码分开管理。训练数据属于高价值资产要纳入 Git 和版本管理每次微调都要能回溯。敏感数据脱敏。凡是进入训练集和知识库的内容先做 PII 清洗避免把手机号、身份证号训进模型。上线前做灰度。即使 Harness 评测通过也要先让模型处理小流量真实请求记录异常输出。保留通用能力。微调数据集里建议混入一定比例的通用指令数据防止模型只适应业务格式失去泛化能力。权限最小化。Agent 调用外部工具时只授最小权限比如只读、限定范围防止一次错误调用造成不可控影响。最后再说一句大模型项目里真正的难点不是“跑通一个 demo”而是“让这个 demo 稳定运行一个月”。微调只是入口Prompt、RAG、Agent、评测这些配套能力才是决定项目能否落地的关键。希望这篇基于 Qwen3.5 的实战梳理能帮你少走几步弯路。建议先把文中的最小闭环跑通再逐步扩展业务场景遇到问题时回到“数据、模型、知识、工具、评测”这五层里去定位。