Qwen3.5 的模型热度一起来最常被问到的问题基本是三件事怎么微调、怎么接 RAG、怎么接 Agent。我也在一台显存不算宽裕的机器上完整跑过一轮基于 Qwen3.5 的大模型微调实战把指令数据、LoRA 训练、效果验证、Ollama 部署再到 RAG 和 Agent 的整个链路都走了一遍。这里我把这套流程拆成一份可复现的操作清单每一步都写清楚前置条件、参数含义和判断标准。如果你打算三天内把微调、RAG、Agent 这条线跑通按这个顺序走会比自己到处拼教程省力很多。先说一个核心判断微调、RAG、Agent 是三种不同层级的工程手段不是同一个东西的三种叫法。很多人把这些概念混在一起结果微调出来的模型既不会读本地文档也不会调用外部工具最后全怪在模型头上。实际上微调改变的是模型的行为习惯RAG 解决的是动态知识获取Agent 解决的是多步任务拆解和工具调用。搞清楚边界后面的每一步才不会被带偏。1. 先把目标拆清楚微调、RAG、Agent 解决的是不同问题1.1 微调解决的是能力定制不是知识注入微调的核心目的是让模型更适配你的任务格式、语气、输出结构和交互方式。比如你希望模型回答问题先给出结论再分三点解释并且遇到不确定的信息明确说“我不确定”这种风格层面的调整用微调最直接。很多人误以为微调可以把新知识灌进模型参数里让模型像一个无限大的私有知识库。这个理解不太对。微调确实能学进一部分训练语料里的知识但效率低、更新难、还容易过拟合。对于一个三天速通的项目更合适的微调目标是让模型“学会怎么按你的要求工作”而不是把一万篇企业文档硬背进去。基座模型选 Qwen3.5 系列时先确认你需要的参数量级。如果只是跑通流程小参数模型足够如果要做效果展示再根据硬件条件选更大的模型。流程本身是一致的变的只是显存占用和训练时间。1.2 RAG 解决的是动态知识获取RAG 的思路简单说就是外部先检索模型再回答。你要把文档切块、向量化、存进向量数据库用户提问时先检索出最相关的片段再把片段拼到 prompt 里让模型基于这些材料生成答案。它和微调的互补关系非常明显。微调改行为RAG 提供事实。私域知识、动态数据、实时更新内容都应该走 RAG 而不是重新微调。尤其当你的文档经常变化比如产品手册按月更新RAG 只要替换文档重新向量化就可以微调则要重新训练一轮成本完全不是一个量级。RAG 的难点不在概念而在切块策略和检索质量。切块过小会导致上下文碎片化切块过大会混入大量无关内容模型容易被噪声带偏。这块后面单独展开。1.3 Agent 解决的是多步任务和工具调用Agent 和前两者又不一样。它面向的是“需要分步骤完成的任务”比如查天气、查数据库、调内部 API、综合多步结果再回答。模型本身不能直接操作外部系统Agent 的任务是把用户指令拆解成动作序列再决定调用哪个工具、传入什么参数、如何读取返回结果并继续推理。ReAct 是这套机制里最常用的一种实现思路。模型输出推理过程和动作观察工具返回结果再形成下一步推理。你可以用 LangGraph 这类框架来搭也可以自己写一个简单的 prompt 循环。没有标准答案关键看你的工具数量和执行链路的复杂度。1.4 三天速通路线怎么排按照输入材料的节奏三天可以这样分配第一天环境准备、模型权重确认、数据整理。第二天LoRA 微调、模型验证、导出部署格式。第三天RAG 接入、Agent 扩展、问题排查。每一段都预留出至少一个小时的缓冲时间。微调这个东西如果中途遇到环境问题或者数据格式问题时间消耗会远远超出预期。2. 第一天上午环境准备与模型确认2.1 硬件条件先看显存和内存跑大模型微调第一道槛永远是显存。很多人问能不能用自己的机器跑答案取决于你的模型参数规模、量化方式、训练方法和序列长度。如果单独说模型推理一个 7B 到 9B 级别的模型用 4bit 量化加载大概需要 6GB 到 8GB 显存用 FP16 加载则需要更接近 18GB。但微调不是只有一个权重文件在里面还要额外算优化器状态、梯度、激活值。LoRA 之所以流行就是因为它只训练很小一部分附加参数显著缩减优化器状态占用的空间。如果要用 LoRA 微调一个 7B 到 9B 级别的模型我的建议是训练端显存尽量不低于 12GB最好有 16GB 以上。内存 32GB 左右比较舒服。序列长度不要一开始就拉满先用 512 到 1024 验证流程。如果机器配置明显低于这个水平也不要直接放弃。你可以把上下文长度调短、batch size 降到 1、开启梯度检查点。能跑通流程但训练速度和稳定性要大打折扣。2.2 软件依赖和运行框架微调最常用的组合是 PyTorch 加 transformers配合 PEFT、trl 或 llama-factory 这类工具。这里的细节是版本匹配问题不要用最新版不管一切。transformers、peft、bitsandbytes 这几个库之间经常出现接口变动最好是先看官方文档里写的兼容版本再固定一套可复现的虚拟环境。我的习惯是用 conda 单独建一个环境。先装 PyTorch根据你的 CUDA 版本选择对应安装命令。再装 transformers、peft、trl、accelerate、bitsandbytes。最后确认模型能够正常加载和推理。不要直接在一台 Python 环境特别乱的机器上开始训练。微调报错有很大一部分不是模型问题是依赖冲突问题。2.3 模型权重下载与验证Qwen3.5 的权重可以从模型仓库下载具体仓库名和命名方式以模型发布页为准。下载之后先做一件事用加载脚本验证模型能不能正常推理一个简单问题。验证步骤可以这样加载模型和 tokenizer。输入一句普通文本比如“请介绍一下你自己”。确认模型能生成完整回复。查看模型文件路径和 tokenizer 文件是否都在同一个目录。很多人在下载模型这一步就踩坑比如只下载了部分权重文件或者 tokenizer 文件缺失。这类问题在训练阶段才会暴露排查成本高。第一天上午宁可多花二十分钟把基础推理跑通也不要把隐患留到训练阶段。3. 第一天下午数据准备是微调的关键前置3.1 指令数据的标准格式数据是微调效果的分水岭。同一个模型同一套参数数据质量不同结果可能差好几个档次。微调数据最常用的格式是问答对结构每条数据包含指令、输入、输出三个字段。如果只是通用问答指令字段可以写“请回答下面的问题”输入字段写用户问题输出字段写标准答案。如果是带上下文的对话可以把多轮对话整理成系统提示和用户轮次、助手轮次交替的结构。不要忽略 system prompt 这一层。数据里带 system prompt 和不带 system prompt训练出来的模型行为差异很大。你希望模型在推理时遵循什么规则训练数据里就要有对应的 system prompt 片段。3.2 清洗、去重和采样拿到原始数据后先做几轮机械检查是否有空文本和超长文本。是否有重复数据尤其是完全相同的问答对。是否有答案明显不完整或质量很差的样本。是否有编码异常、乱码、HTML 标签残留。去重最简单的方法是直接对所有文本做哈希哈希相同的样本保留一条。如果数据规模大可以用文本向量去重但三天速通项目通常不需要做到这步。采样时要尽量保持场景均衡。比如你准备微调模型让它偏向客服风格那么客服语料应该占多数但也要留一部分通用问答数据避免模型在普通对话场景下仍然保持僵硬的口吻。3.3 训练集与验证集拆分数据不能全部拿去训练。至少留出 5% 到 10% 作为验证集用来观察模型在训练过程中是否过拟合。拆分的标准是场景分布一致不能把这部分全是售后问答那部分全是普通闲聊。拆分后记录验证集数量训练过程中如果训练 loss 持续下降验证 loss 不降反升基本可以判断过拟合。对于首次跑通项目几百条高质量数据就足够验证流程。数据量不是越大越好在数据集质量没有明显提升的情况下堆数据只会增加训练时长和调参成本。4. 第二天LoRA 微调实战4.1 加载基座模型和量化方式LoRA 微调的第一步是加载基座模型。如果你显存吃紧可以用 4bit 量化加载这样可以大幅减少模型权重占用的显存。训练时虽然整体精度会有一定折损但对指令微调来说通常可以接受。加载模型时要注意设置正确的数据类型和设备映射。不要把模型全塞到 CPU 上训练速度会非常难受。也要注意模型是否支持当前 transformers 版本老模型配新库或者新模型配老库经常会出现加载失败或输出乱码的问题。实际跑微调时我一般先用一个很小的样本子集跑通代码比如 50 条数据。确认 loss 能正常下降、生成结果不是乱码再用完整数据开训。这一步能帮你快速排除代码和环境问题。4.2 LoRA 参数怎么配LoRA 的核心参数包括 rank、alpha 和 target_modules。rank 决定低秩矩阵的大小。rank 越大可学习的参数量越多模型能拟合的复杂度也越高但显存占用和过拟合风险都会增加。入门可以先设 8 或 16效果不够再往上加。alpha 是缩放系数一般设为 rank 的两倍比如 rank 16 时 alpha 设为 32。这个比例不是绝对但作为起点比较稳妥。target_modules 决定在哪些模块上注入 LoRA 适配器。比较常见的做法是作用于 Q 和 V 注意力层进阶做法是对所有线性层生效。先跑通流程时Q 和 V 就够用如果发现效果不好再尝试扩展到全部线性层。4.3 训练超参怎么定训练超参的关键是学习率、batch size、epoch 和序列长度。学习率LoRA 微调通常使用 1e-4 到 2e-5 这个范围可以先从 1e-4 开始。batch size显存不够时降到 1配合梯度累积实现更大的有效 batch size。epoch200 到 1000 条数据时从 3 到 5 轮开始验证。序列长度根据数据最长样本裁剪但不要一开始就设 4096。一个比较常见的错误是直接照搬别人的超参但自己的数据长度和 batch size 完全不同。训练时记录 loss如果第一轮 loss 就不降优先检查数据是否加载正确再考虑调学习率。4.4 保存、合并与导出训练完成后LoRA 只保存了一份很小的适配器权重不是完整模型。直接用这个适配器推理需要先加载基座模型再加载 adapter。如果想把模型部署到 Ollama需要先把 LoRA 权重合并回基座模型再导出为 GGUF 格式。合并时要注意基座模型的路径和 LoRA adapter 的路径必须对应正确。合并完成后简单推理确认效果正常再考虑导出。导出的细节取决于你用的工具。llama.cpp 提供了转换脚本把合并后的模型转换为 GGUF。这一步最容易出问题的不是转换命令而是合并后的模型路径有中文、空格或者基座模型的 tokenizer 文件缺失。# 示例合并 LoRA 权重通用思路具体命令以工具版本为准 python scripts/merge_adapter.py \ --base_model /path/to/Qwen3.5 \ --adapter /path/to/lora_checkpoint \ --output /path/to/merged_model这里不是让你原样复制而是提醒你合并脚本的输入输出路径、文件命名一定要单独确认。5. 第二天晚上到第三天上午验证与部署5.1 单条推理验证训练完成后先不要急着部署先做一轮单条推理测试。测试时注意输入输出是否稳定是不是只有第一次正常第二次开始乱编。我一般会准备五到十条测试问题覆盖目标场景、边界场景和普通问答。比如你微调客服模型就准备几个典型售后问题、几个意料之外的刁钻问题、几个单纯闲聊问题。观察模型是否都保持了目标语气和回答结构。如果输出中出现重复句子、符号爆炸、乱码优先检查 tokenizer 是否加载正确再检查训练数据里的特殊 token 是否处理正确。不要一上来就调整训练参数。5.2 用评估工具看效果单条推理只是初步验证更靠谱的方法是使用评估工具跑一组固定的评测样本。输入材料里提到的 Harness 类工具主要作用就是统一加载模型、批量跑测试、计算指标。评估对比要有一个明确的基线。把基座模型和微调后的模型放在同一组评测样本上跑对比输出结果。这样才能看出微调到底带来了哪些变化而不是凭感觉说“好像变聪明了”。评估时要注意评测样本不能和训练样本重复。输出指标只是参考关键看回答是否满足你的任务要求。不要只看平均分要分场景看。如果没有明显提升先检查训练数据质量不要急着调 LoRA 参数。5.3 Ollama 部署和接口调用模型验证没问题后就可以通过 Ollama 部署本地服务。Ollama 的好处是把模型加载、服务启动、OpenAI 兼容接口都打包好了适合快速给上层应用用。部署流程大概是准备好 GGUF 格式的模型文件。写一个 Modelfile指定模型路径和上下文长度。执行模型创建命令。启动服务并调用接口。# 示例 Modelfile实际路径以你的文件为准 FROM ./qwen3.5.gguf PARAMETER temperature 0.7 PARAMETER num_ctx 2048创建完成之后用一条 curl 请求验证接口是否正常。curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3.5, messages: [{role: user, content: 你好请介绍一下你自己}] }如果接口正常返回说明本地服务已经跑通。接下来可以把 RAG 和 Agent 接到这个接口上。6. 第三天下午RAG 与 Agent 扩展6.1 先判断该不该上 RAGRAG 不是所有场景都需要。如果你只是想让模型按照固定格式输出微调就够了如果你的知识库定期更新、内容量很大、用户问题涉及具体事实RAG 比较合适。上 RAG 前先把文档处理链路想清楚文档是什么格式怎么解析文本怎么切块怎么向量化用哪个向量数据库检索回来怎么拼到 prompt 里。很多 RAG 项目失败不是模型不行而是文档解析出来根本是乱的。PDF 扫描件、复杂表格、多层目录这些都需要单独清理。第一天数据准备阶段可以先放一放但在第三天要把文档处理加入排期。6.2 切块策略和向量化切块策略直接决定检索质量。常用参数是 chunk_size 和 chunk_overlap。chunk_size 控制每块文本长度。太短语义不完整太长无关信息太多。如果我用标准中文文本通常会先试 500 到 800 字左右再根据具体文档调整。chunk_overlap 控制相邻块的重叠部分目的是避免一句话被切断到两个块里。向量化的关键是选一个稳定的 embedding 模型。同一个项目里检索向量和 query 向量必须来自同一个模型否则维度对不上或语义空间不一致检索结果会很离谱。向量数据库选择上Chroma 适合快速实验Milvus 或 Qdrant 适合数据量更大、需要运维的场景。三天项目可以直接用轻量方案。6.3 如何把 RAG 结果交给模型RAG 的完整链路是用户提问先检索相关片段把片段放到 prompt 里再交给微调后的模型生成答案。这里有两个容易忽略的点prompt 中要明确告诉模型“只基于以下资料回答”否则模型会自作主张补充外部知识。检索结果不能太长否则超过上下文限制。请仅根据下面的资料回答问题。 资料... 问题... 回答如果检索结果为空不要让模型硬编而是让它直接告诉用户“没有找到相关答案”。这一步能把幻觉率降下来不少。6.4 ReAct 模式与 Agent 框架Agent 的本质是让模型循环完成“推理、调用工具、观察结果”的过程。ReAct 是这种循环的一种实现格式。你不需要任何复杂框架就能跑通一个最小 Agent在 prompt 里定义工具列表和输出格式让模型决定调用哪个工具你负责执行函数并把结果返回给模型。可用工具 1. calculator计算数学表达式 2. search_news搜索新闻 输出格式 Action: 工具名 Action Input: 参数 Observation: 工具返回结果 Thought: 下一步思考模型输出 Action 后你的代码去执行对应函数再把 Observation 拼回对话里让模型继续。这个循环一直持续到模型输出最终答案。如果你想用现成框架LangGraph、LangChain 都能做。但我建议先手写一个最小循环理解机制之后再上框架否则出了问题不知道是该调试模型还是调试框架。6.5 微调、RAG 和 Agent 怎么配合一个比较成熟的结构是用微调后的 Qwen3.5 作为底座让它熟悉你的术语和回答格式。用 RAG 解决事实获取问题答案里的数据来自检索资料。用 Agent 处理多步任务例如先查数据库再计算结果再给出报告。这个组合的好处是各层职责清晰。微调负责“说话方式”RAG 负责“回答依据”Agent 负责“行动流程”。以后哪一个环节出问题都能单独排查不需要把所有逻辑重写一遍。7. 常见问题排查这些坑我基本都踩过7.1 显存溢出显存溢出是最常见的训练报错。出现后不要急着换机器先按顺序排查减 batch size 到 1。开启梯度检查点。缩短序列长度。确认模型是否以 4bit 加载。关掉其他占显存的程序。如果都无效再考虑换更小的模型。很多项目的需求其实用小参数模型就能满足没必要一开始就追求大模型。7.2 训练不收敛训练不收敛的表现有很多种loss 震荡、loss 完全不变、loss 降得很慢。排查顺序是先看数据集里有没有空输出或错位样本。确认数据加载时 fields 是否一一对应。降低学习率一个数量级再试。减少 epoch 数量防止过拟合。确认 base_model 不是已经被合并过 LoRA 的模型。有些“不收敛”其实是数据里混了大量完全相同的文本模型一直在一个小范围里反复学自然出现 loss 不下降或者验证 loss 异常的现象。7.3 模型导入或推理异常Ollama 部署后如果出现加载失败、响应乱码、模型名找不到优先看三处GGUF 文件路径是否正确。Modelfile 里的模型名是否和调用时一致。tokenizer 文件是否完整。乱码往往不是模型问题而是分词器配置错误或模型与对话模板不匹配。解决方法是换用官方默认的模板先把基础对话跑通再自定义 system prompt。7.4 RAG 检索结果不理想RAG 效果差的时候先检查是“检索到了但模型不按资料回答”还是“根本没检索到相关内容”。如果是前者调整 prompt把“请严格根据资料回答”写得更明确。如果是后者看查询向量和文档切块是否来自同一个 embedding 模型看看 chunk_size 是不是太小看看 top_k 取值是不是太低。我见过很多 RAG 项目最后发现罪魁祸首是文档解析时把表格全部拆碎了。文本连续性没了检索结果自然不靠谱。所以在做向量化之前先人工抽查几个切块片段确认语义完整。7.5 第一天遇到的问题最多不要慌整个流程跑完你会发现最难的不是微调参数而是环境、数据和前后链条的衔接。第一天把环境调通、数据清理完后面两天会顺畅很多。如果第一天就卡在版本兼容或者数据处理上别硬撑。把问题记下来按“先看日志再查路径最后改代码”的顺序走大多数问题都能在半小时内解决。真正做进生产环境时还要把日志记录、输出目录、任务队列、失败重试和版本管理提前做好。微调、RAG、Agent 的组合可以拆成多个模块独立部署每一层单独验证。这样即使某个环节出错也不会把整条链路拖垮。