微调（Fine-tuning）与 RAG：如何根据应用场景选择？ ?

#为何此问题反复出现

您已安装 Ollama，选择了 7B 或 14B 模型，现在希望让模型“了解”您的领域：内部文档、业务术语、判例裁判文书、支持工单。您有两条路径可选——微调或 RAG——而社区经常把它们当作可以互换的方案来讨论。实际上，它们并不能互换。

陷阱在于：微调（fine-tuning）带着“真正的 AI”的光环，让人想象模型会成为专家。RAG 则显得像是临时拼凑的方案，是自动化的“复制粘贴”。实际产业应用中的情况恰恰相反——RAG 已成为 80% 企业应用场景的标准方案，而微调只用于特定问题，在这些问题上，它能提供 RAG 无法提供的能力。

#用 1 分钟了解两种方法

#RAG（检索增强生成）

RAG 会将您的文档（PDF、Markdown、数据库、代码）索引到向量数据库（Chroma、Qdrant、Weaviate）中。当提出问题时，系统通过语义相似性查找相关段落，将其注入提示中，再由 LLM 基于这些内容生成回答。模型本身仍然是通用的，变得专业化的是上下文。

这会带来哪些变化

模型可以引用您的数据，为回答注明来源，并获取训练时尚不具备的知识。

不变之处

回答的风格、语气、在特定格式下进行推理的能力、高度专业化的技术术语。

添加文档的边际成本

几秒钟：只需为新文档建立索引，就这么简单。

#微调（LoRA / QLoRA / 全量）

微调会重新训练模型（或通过LoRA方式训练其部分权重）以适应输入-输出配对数据集，该数据集能代表您希望模型实现的功能。模型的知识和行为会融入其权重中。

这会带来哪些变化

默认行为：风格、输出格式、惯例、深入的行业专业词汇、隐含推理。

它无法有效改变的方面

获取最新事实信息的能力——一个在三月用您的流程进行微调的模型，不会知道四月编写的流程。

添加文档的边际成本

数据集每次发生重大更新，都需要重新进行一轮完整训练。

#决策矩阵

与其只说“这要看情况”，不如逐项列出真正能帮助您做出选择的标准。

经常变化的事实性知识

选择 RAG。数据集一更新，微调得到的模型就已过时。产品文档、工单库、常见问题解答和判例都属于这一类。

特定的风格、语气和输出格式

微调。要让模型稳定遵循严格的 JSON 格式、企业风格的语气或报告结构，无论在提示词中放入多少示例，都无法替代 500 对精心构建的训练样本。

极其专业的行业术语词汇

微调，尤其是在预训练对相关语言覆盖不足时（法语法律用语、医学用语、方言）。如果模型一开始就不理解这些术语，仅靠 RAG 是不够的。

可追溯性及来源引用

RAG。您可以显示“根据文档X，第Y段”。使用微调模型，无法验证某项断言的来源。

高度机密的数据，绝不放入共享 RAM

采用微调，权重存储在本地。RAG 需要在每次请求时将相关段落注入上下文——在共享基础设施上，这可能带来问题。

在 200 毫秒内快速响应（聊天机器人、内联智能体）

微调。RAG 会增加 100–500 毫秒的检索时间，还需要处理更长的上下文。在对实时性要求严苛的场景中，这会造成负担。

知识体量巨大（>10 万页）

RAG。用 10 万份文档进行微调并不现实——即使您这样做了，模型仍会在细节上产生幻觉。

高质量训练数据集可用

如果您没有至少 500–1000 对经过清洗的输入/输出样本，微调带来的主要结果会是模型性能下降。先从 RAG 开始。

#5个典型应用场景

#1. 基于产品文档的客服聊天机器人

结论

毫无疑问，选 RAG。

为什么

文档经常变动（新功能、修复、弃用）。微调在 3 周内就会过时，而客户希望得到有出处的回答（“参见手册第 X 节”），而不是不透明的断言。

典型技术栈

Ollama（选择 Qwen 3.5 9B 以适配 8 GB，或在 16 GB 下使用 Mistral Small 24B，以获得更讲究的法语表达）+ Qdrant/Chroma + nomic-embed-text + Open WebUI 或 AnythingLLM。

#2. 结构化信息提取器（发票、简历、合同）

结论

微调，或结合 JSON 模式的高级提示词设计。

为什么

输出格式必须每次严格一致（相同字段、相同类型、相同默认值）。即使提示词写得再好，仍有 5% 的情况会偏离，导致流程中断。使用 800 个标注示例的 LoRA 可彻底解决此问题。

典型技术栈

使用 Unsloth 或 Axolotl 训练，导出为 GGUF 格式，再通过 Ollama 部署。如果关于文档类型的“知识”库发生变化，可以结合轻量级 RAG 使用。

#3. 基于法国判例法的法律助手

结论

混合方案——先使用 RAG，如果词汇掌握仍然不足，再进行微调。

为什么

判例库规模庞大且每月更新（必须使用RAG获取最新判决信息）。但大多数开源模型对法语法律术语覆盖不足，通过轻量级微调（在2至3000个法律问答样本上使用LoRA）可显著提升对法律术语的理解，从而在RAG介入前实现更准确的语义解析。

典型技术栈

以 Légifrance/Doctrine 为数据源 → Qdrant + BGE 重排序器 → 使用法语法律术语进行 LoRA 微调的 14B LLM。

#4. 适配内部代码库的代码生成器

结论

RAG（仓库文件读取），仅在极特殊情况下进行微调。

为什么

代码库每天都在演进。每次迭代后，微调都会变得过时。最好的代码助手（Continue.dev、Aider）通过在AST或代码嵌入上执行RAG动态读取相关文件。

典型技术栈

Continue.dev + Qwen3-Coder 30B-A3B（qwen3-coder:30b，MoE，256k 上下文，激活参数为 3B，因此速度快），或通过 Ollama 使用 Devstral 24B；检索功能集成在插件中。

#5. 公司编辑风格（新闻简报、报告、产品说明）

结论

纯微调。

为什么

每次生成的内容都是全新的（没有什么需要“检索”的），但语气、结构、句子节奏、“您”的使用以及小标题的使用都必须完全一致。这正是微调能够很好地编码到模型中的特征。

典型技术栈

200–500 篇写作质量良好的文章 → Alpaca 或 ChatML 格式 → 使用 Unsloth 对 Qwen 3.5 9B 进行 QLoRA 微调 → 导出 GGUF，配置带有补充系统提示词的 Ollama Modelfile。

#两种方法的隐藏成本

公开对比往往只讨论“一块 GPU 进行 4 小时训练的费用”。实际上，两种方案在实际运行中面临的挑战都更严峻。

#RAG的隐藏成本

分块质量

文档分块决定了所有结果。分块不当，检索会返回脱离上下文的片段，LLM 产生幻觉，且无人能理解原因。这很少只是‘把 PDF 放到 Chroma’就能解决：通常需要按章节分块，有时还需对扫描件进行 OCR 预处理。

累积延迟

查询嵌入 + 向量检索 +（可选）重排序器 + 提供给 LLM 的更长上下文。在优化不佳的配置下，延迟可能从 400 毫秒（仅 LLM）增加到 2–3 秒（完整 RAG）。设计之初就应将这些开销计入延迟预算。

知识库维护

文档被删除或更新时，需要将其移除或重新索引。对于外部来源（网页、API），应安排刷新任务。技术栈持续运行和变化，维护工作也会随之增加。

嵌入模型质量

对于法语场景，默认嵌入模型（如text-embedding-ada类）表现平庸。nomic-embed-text、BGE-M3或Solon能带来显著提升——但这也意味着需要了解相关选项。

#微调的隐性成本

数据集准备

这是 80% 的工作量。收集、清洗、格式化为指令/响应对、去重、平衡类别。在一个四周的微调项目中，请预留三周用于数据准备，一周用于训练。

退化风险

调整不当的微调会削弱模型的通用能力（即“灾难性遗忘”）。模型会变得擅长您的任务，却在其他方面表现很差。必须在微调前后使用通用基准进行测试。

每次更新均进行重新训练

数据集会随着时间不断丰富。每次发布新版本，都需要重新运行 2 至 12 小时的 GPU 计算，再次验证并重新部署。因此，必须对数据集和检查点进行版本管理。

训练硬件

推理一个7B模型Q4版本需要5GB显存，但训练（即使使用QLoRA）至少需要12-16GB。微调的硬件门槛高于推理。

#混合方法：RAG + 微调

最高效的架构不会只选一种方案，而是将两者结合起来。微调决定模型如何谈论您的专业领域，RAG 则让模型能够获取当时需要知道的信息。

针对风格和格式进行微调

200–1000 个示例，用于确立语气（企业风格、技术风格、法律风格）、回答格式（JSON、结构化 Markdown）以及应对原则（始终引用来源，绝不编造）。

基于事实知识的 RAG

文档、工单知识库、判例、代码库——所有可能变化且需可检索、可引用的内容。

系统提示词中的防护措施

系统提示会提醒模型在 RAG 上下文为空或矛盾时拒绝回答，对于减少幻觉至关重要

#3个问题快速决策

1. 01
   问题1 — 您的数据每月变更次数是否超过一次？

   如果是：必须使用 RAG。微调要跟上这一更新节奏，就会带来如噩梦般的运维负担。
2. 02
   问题 2——您是否拥有至少 500 对经人工验证的高质量输入/输出数据？

   如果没有：先从 RAG 开始。用 100 个粗制滥造的样例进行微调会降低模型性能。如果您打算逐步积累样例，请先搭建 RAG，并利用其日志构建数据集。
3. 03
   问题 3 — 问题是‘知道某事’，还是‘以某种方式回答’？

   知识 → RAG。以特定方式作答 → 微调。两者结合 → 混合方案。这是最简单的框架，且成功率高达9/10。

#需要避免的常见陷阱

"微调以学习事实"

这是最常见的错误。微调后的模型并不是知识库——它会根据见过的示例进行插值，但在具体细节（数字、日期、参考资料）上产生幻觉的情况远多于 RAG。

在超过 1 万个文本块的语料库上使用“不带重排序器的 RAG”

仅靠向量检索可以召回大量内容，但这些内容不一定相关。用交叉编码器重排序器（BGE、mxbai）对前 20 个结果进行重排序，可以显著改善质量，额外耗时为 50–100 ms。

混淆RAG与长上下文

"我只需要把整个文档放进提示中"。当有效token超过8k时，质量会急剧下降（中间部分丢失，"lost in the middle"）。经过良好分块的RAG在达到一定体量后，其效果优于基于简单长上下文的方案。

使用未对齐的数据集对已对齐的模型进行微调

如果用提示词结构与模型原有结构不同的示例来微调一个“instruct”模型，就会破坏对齐，使模型行为异常。始终遵循模型的模板（ChatML、Alpaca、Mistral、Llama-3 chat）。

想依据公开基准测试来做决定

任何通用基准测试都无法判断，对于您的具体使用场景，RAG 和微调哪个效果更好。请建立内部评估，使用 30–50 个有代表性的问题，并在规模化应用之前进行测量。

#深入了解

一旦做出决策，相应的指南将涵盖具体的实施过程，包括常见陷阱和优化方法。

无需编码实现 RAG

使用 Open WebUI 或 AnythingLLM，可以在几小时内搭建基于文档的 RAG 系统，无需编写 Python 代码——适合在规模化部署前验证这一方案。

本地微调 LoRA / QLoRA

专题指南涵盖 Unsloth、数据集格式、LoRA 与 QLoRA 的选择，以及供 Ollama 使用的 GGUF 导出。对于 7B 模型，一张 RTX 3090 就足够。

优化现有的 RAG 系统

重排序器、BM25与向量检索相结合的混合检索、分块策略——这三种方法能将一个“能用”的RAG提升为可用于生产环境的RAG。