很多人第一次接触大模型的应用开发时都会被这几个术语绕晕知识蒸馏、RAG检索增强、微调Fine-tuning。乍一看都是“让模型变聪明”的手段真到选型的时候才发现它们解决问题的层次完全不同——有的改模型本身有的改输入方式有的改输出约束。作为踩过不少坑的从业者我想用一篇完整的拆解把这三者的区别讲透包括它们各自适合什么场景、为什么这么选、以及怎么组合使用。这篇文章面向的是刚入门的算法工程师、正在做技术选型的开发者以及对大模型落地有需求的业务方。我会尽量把原理讲得接地气同时给出可以直接参考的实操建议。读完你应该能明确回答一个问题手里的项目到底该用蒸馏、RAG还是微调。1. 先把三件事放在同一张桌上对比在深入原理之前我们先把这三件事的定义摆清楚。因为它们经常出现在同一篇技术文章里很容易被误认为是同一类技术的不同变体。知识蒸馏Knowledge Distillation是一种模型压缩技术。核心思路是让一个小模型学生模型去学习一个大模型教师模型的输出行为把大模型的“知识”迁移到小模型里。它解决的核心问题是模型太大、推理太慢、部署成本太高但还想保留大模型的能力。RAGRetrieval-Augmented Generation检索增强生成是一种架构设计模式。核心思路是在生成回答之前先从一个外部知识库中检索相关内容把检索结果拼接进提示词Prompt里再交给大模型生成答案。它解决的核心问题是模型不知道最新信息、不知道私有知识、容易产生幻觉。它不改变模型的权重只改变模型的输入。微调Fine-tuning是在预训练模型的基础上用特定数据集继续训练模型更新部分或全部模型参数。它解决的核心问题是让模型适配特定任务格式、特定领域风格或者特定的输出约束。它改变的是模型本身的参数。从改变对象的角度看蒸馏改变的是模型的“替身”RAG改变的是模型的“输入”微调改变的是模型的“本体”。这是三者最本质的差别。一张简表帮助建立第一印象维度知识蒸馏RAG检索增强微调改变内容模型结构压缩模型输入增强上下文模型参数适配任务核心目的推理加速、部署降本引入外部知识、减少幻觉适配格式、风格、任务是否需要额外数据不需要用教师模型的输出需要构建知识库和索引需要构建训练数据集是否需要重新训练需要训练学生模型不需要训练的是检索器或嵌入模型需要训练模型参数对模型权重的影响生成新模型学生不改变原模型权重改变原模型权重典型适用场景端侧部署、高并发推理客服问答、私有知识库、实时信息查询指令遵循、格式对齐、风格迁移先记住这张表后面每一行的含义都会详细拆开讲。2. 知识蒸馏把大象装进冰箱的艺术2.1 蒸馏到底在蒸馏什么知识蒸馏的关键不在“让小模型模仿大模型的答案”而在于模仿大模型的“行为分布”。如果我们只拿硬标签比如分类任务里的“猫”或“狗”去训练小模型小模型学到的是一个确定的答案。但大模型在预测时其实会输出一个概率分布比如“猫0.7狗0.2兔子0.1”。这个分布里包含了丰富的信息——狗和兔子虽然都不对但狗和猫更像所以它的概率比兔子更高。这种“模糊的正确”就是知识。蒸馏的过程就是用大模型输出的软标签Soft Label去训练小模型让学生的输出分布尽量接近教师的输出分布。这里通常会引入一个温度参数T把原始的logits除以T再进行Softmax得到更平滑的概率分布。温度越高分布越平滑小模型能看到的“暗知识”就越多。举个例子一个识别动物的大模型看到一张猫的图片输出的原始分数可能是猫100、狗20、兔子5。经过温度T3平滑后变成了猫98、狗7、兔子2.8。小模型在训练时不只学“这是猫”还顺带学到了“猫和狗在特征上有相似性”。这种信息在硬标签训练里是学不到的。2.2 蒸馏的常见方式实际操作中蒸馏大体分三类响应蒸馏是最基础的形式只让小模型学习教师模型的最终输出。中间特征蒸馏如FitNet让学生的中间层特征去逼近教师的中间层特征希望学生不止学结果还学推理过程中的表征。关系蒸馏则更进一步把样本之间的关系比如两张图是否相似、两个句子是否语义接近作为蒸馏目标。后两种更适合CV和跨模态场景在纯文本大模型里响应蒸馏仍然是主流。对大语言模型来说现在的蒸馏实践往往并不直接解耦三层做精细化设计而是直接让学生模型去学习教师模型的生成文本。这更像是“弱化版的微调”但数据来源是教师模型生成的而不是人工标注的。2.3 什么时候该用蒸馏蒸馏最大的优势是推理速度的提升和部署成本的下降。一个7B的模型蒸馏成1.5B推理延迟可能降低3到5倍显存占用也大幅下降。如果你的场景是移动端、边缘设备、或者高并发的在线服务蒸馏几乎是必经之路。需要注意的是蒸馏之后的模型能力一定有损耗。哪怕蒸馏技术再成熟小模型也不可能完全复现大模型的能力。它适合的是“能力要求没那么极限、但性能和成本要求很敏感”的场景。如果你的业务本来就是调用云端大模型API蒸馏对你没有意义——因为你替换不了服务端的模型。还有一个容易忽略的点蒸馏需要先有一个“教师模型”。这个教师模型可以是开源的也可以是你自己微调过的模型。如果你有私有数据场景先微调一个大模型再蒸馏成小模型是端侧部署的标准路径。先用大模型表现优秀的私有能力然后用蒸馏把这种能力迁移到轻量模型上。注意蒸馏的训练数据不需要人工标注但需要大量高质量的“教师模型输出”。要避免教师模型在数据上“瞎编”否则会把错误知识一并蒸馏给学生。实际工程中最好对教师输出做一轮自动过滤筛掉低置信度的生成结果。3. RAG检索增强给模型开卷考试3.1 为什么模型会“一本正经地胡说八道”大语言模型的知识来源于训练语料这些语料有极强的时效性和覆盖范围限制。模型不知道2024年之后发生的新闻不知道你们公司内部的产品文档不知道某个私有数据库里的记录。如果强行询问模型只能用泛化能力“编造”一个看似合理的答案这就是幻觉。RAG的核心假设很朴素不指望模型记住所有知识而是让它学会“查资料”。我们在模型生成前先从知识库中检索出与问题最相关的内容片段把这些片段放到提示词里让模型基于这些内容作答。相当于把闭卷考试变成了开卷考试模型不需要记住答案只需要具备阅读理解能力。3.2 RAG的完整工作链条一个完整的RAG系统包含几个核心环节文档加载与解析、文本分块Chunking、向量化嵌入Embedding、向量索引构建、检索相似度计算、重排序Rerank、提示词组装、生成。每个环节都有决定成败的细节。文本分块是最容易被低估的环节。块太大检索出来的内容冗余浪费上下文窗口还可能引入无关信息块太小语义信息不完整检索的精准度反而下降。通用做法是按段落或固定Token数比如每块256到512个Token切分同时设置重叠Overlap区间避免句子在切分处被截断导致语义断裂。向量化是指将文本转换成高维向量语义相近的文本在向量空间中距离更近。这一步需要选择一个Embedding模型像开源的BGE、M3E系列或者商业API服务。嵌入模型的选择要跟检索语言、专业领域匹配否则相似度计算的结果会很离谱。向量索引的构建决定了检索的速度。小规模数据几万条用暴力扫描还行大规模数据必须使用近似最近邻索引比如Faiss、Milvus这类方案支持的HNSW索引。重排序是为了提升检索质量。向量检索的Top几结果通常不够精确尤其在专业知识库里需要用一个交叉编码器Cross-Encoder模型对初筛结果进行精细排序把真正相关的文档排在前面。我见过不少项目忽略了这一步检索结果的准确率差了一截加上一个重排序模型后效果立刻提升。最后一步是把检索到的内容填充进提示词让模型只依据给定材料回答。这里可以加一条限制指令“如果给定材料中没有相关信息请直接说明不知道不要编造。”实验证明这一句简单的系统提示能显著降低幻觉率。3.3 RAG的七十二变RAG不是只能做问答。基于RAG的架构可以演化出很多变体摘要式RAG针对全文检索结果做摘要适用于报告生成、会议纪要等场景。多跳RAG把用户的复杂问题拆解成多个子问题分步检索再综合回答适合知识图谱和复杂推理场景。智能体式RAG模型自主决定检索几次、检索什么内容、何时停止检索适合工具调用和自主任务执行场景。混合检索RAG结合向量检索和关键词检索BM25的召回结果再做融合排序能同时兼顾语义相关性和字面匹配。还有一个容易忽略的趋势RAG已经从“只是检索文本片段”进化到可以检索表格、数据库记录、JSON结构化数据以及代码片段。结构化数据检索通常需要额外的解析与格式化过程但能显著提升回答的准确性。3.4 什么时候该用RAG当你遇到以下情况中的任何一种应该优先考虑RAG知识需要频繁更新今天录入的内容明天就要能被回答出来。知识高度私域比如企业内部的规章制度、产品手册、客服话术。需要模型提供可追溯、可验证的回答依据。幻觉是业务无法接受的比如金融、医疗、法务等高风险场景。RAG最大的优势是不需要训练模型因此周期短、成本低、更新快。你不需要GPU训练集群只需要一个向量数据库和几个开源模型组件就能搭建一个效果不错的RAG系统。RAG也有自己的局限性它对检索质量极其依赖检索结果不好生成答案必然受影响多个知识源之间可能有互相矛盾的表述模型不知道该信哪个处理极长文档时检索完整覆盖困难。提醒RAG项目的成败往往在“文本分块”和“重排序”这两个不起眼的步骤上。很多团队花大精力调提示词却忽视了知识库本身的构建质量最后效果不好就甩锅给“大模型能力不行”。实际上问题多半出在检索侧。4. 微调把通才打磨成专才4.1 微调解决的是什么问题预训练大模型像一个接受过通识教育的毕业生什么都知道一点但不精通任何具体业务的处理规范。你让它帮你写工作日报它能写但格式跟你公司的模板完全不一样你让它按特定的JSON结构输出结果它时好时坏你让它模仿某位作者的文章风格它模仿得四不像。这时候靠提示词已经很难解决了需要微调。微调的本质是用一批“输入-期望输出”样本让模型学习业务数据的分布规律。训练过程会更新模型的权重参数让模型的输出行为向你的数据集偏好靠拢。这种改变是持久化的——模型被训练之后它默认就会按你教的格式和风格回答不需要每次都在提示词里重复要求。4.2 微调的核心方法与策略全参微调Full Fine-tuning会更新模型全部参数。效果通常最好但显存开销巨大7B模型就需要多张高显存GPU训练成本高。实际应用里更多人用的是参数高效微调PEFT。参数高效微调的代表技术是LoRALow-Rank Adaptation低秩适配。它不直接更新原始权重而是给每个线性层并联一个低秩矩阵。训练时只更新这个低秩矩阵的参数原始权重保持不变。LoRA的可训练参数通常只占模型总量的0.1%到1%显存需求大幅下降训练速度明显提升。训练完成后只需要保存一个几十MB的适配器文件推理时动态加载部署非常灵活。另一个常用技术是QLoRA先对模型做4-bit量化再使用LoRA方法微调。这就把微调门槛进一步降低了消费级显卡比如24G显存也能微调7B到13B的模型。在微调的类型选择上指令微调Instruction Tuning是最基础的让模型学会遵循指令完成任务对话微调让模型具备多轮对话能力领域适应微调让模型熟悉特定领域术语和风格。如果你的模型基础能力已经不错只是需要适配某种输出格式或语气风格用少量数据进行高效微调即可无需追求全量微调。4.3 数据质量决定微调上限微调的成败全靠数据。数据数量不需要特别多但质量必须足够高。几百条精心整理的高质量样例效果往往超过几万条粗糙的自动生成数据。实际项目里常见的数据问题有这么几类指令模糊期望模型做什么都没说清楚模型自然学不到要求。答案错误数据里有错误答案模型把错误当成了惯例。分布单一只有一种任务模板模型见到新的句式就不知所措。过长的输入样例太长导致训练慢、显存占用高、过拟合。我在项目里常用的做法是先人工写20到30条“模板种子样例”然后用大模型批量扩展生成更多变体再人工抽查过滤。这类半自动方式既能控制数量规模也能保证质量下限。4.4 什么时候该用微调遇到下面这些情况微调往往是更合适的选择输出格式有严格规范比如必须按特定JSON Schema输出或者必须遵循某种固定话术模板。需要模仿人的特定写作风格、语气或表达习惯。任务本身需要强指令遵循能力比如工具调用、多步推理。提示词和RAG都已尝试过且效果不理想确认是模型“能力边界”问题。微调不是万能的。它不能给模型注入全新的知识——哪怕你在数据集里放了大量新知识模型也很难记住每一处细节而且容易产生“死记硬背”的伪记忆。真正的事实性知识注入还是应该交给RAG。重要微调会改变模型的行为但也可能损伤模型的通用能力。尤其是只拿单一任务数据微调可能会导致灾难性遗忘Catastrophic Forgetting模型忘了原本学会的其他能力。缓解办法是在微调数据里混入一定比例的通用数据或者使用LoRA这类参数高效方法降低对原始权重的破坏。5. 三者的关系不是替代而是组合很多人纠结“这三个我该选哪个”实际上这从来不是一个单选题。在一套真实系统里三者往往会同时出现各司其职。拿一个典型的智能客服项目举例原始需求是用企业私有文档回答客户问题。架构师拆解后很可能这样组合——底层用RAG搭建知识库问答解决私有知识的问题基于上一阶段的效果反馈对模型做一次指令微调让它在客服话术上更规范最后为了降低线上推理成本把微调后的模型蒸馏成一个小模型部署到生产环境。这条链路清晰地展示了三者如何配合RAG负责“实时查资料”微调负责“规范说话方式”蒸馏负责“把模型装进更小的容器”。它们解决的问题不同但最终都在为一个目标服务让AI在业务场景里更可靠、更便宜地工作。还有另一种组合思路用蒸馏获得小模型之后在小模型上做RAG或微调。比如先蒸馏出一个7B模型用于端侧预研再在这个轻量模型上微调任务能力。这时候蒸馏在前微调在后顺序也很自然。从落地成本来看三者也有清晰的梯度RAG最快一两周即可上线微调居中需要构建数据集和训练资源蒸馏最重需要先有教师模型、训练学生模型、再做评估和部署转换。项目初期可以先用RAG验证效果发现问题需要模型能力本身改变时再上微调最后再评估是否值得做蒸馏。6. 一张选型决策表与实操避坑清单为了照顾到正在做架构选型的读者我整理了一张更直接的决策表列出不同业务诉求下的首选方案业务诉求首选方案备选方案理由回答私有知识库问题RAG微调效果差很多知识更新快RAG可随时加数据高速、低成本的端侧模型蒸馏量化不换模型蒸馏能获得更小模型结构严格格式化的结构化输出微调RAG几乎无效格式问题是模型能力边界降低幻觉和编造RAG微调提示约束给模型“材料依据”最有效模仿特定作者文风微调RAG可参考风格但不可靠风格是内化能力系统上线后再更新知识RAG蒸馏蒸馏重新训练代价太大高并发在线推理降本蒸馏LoRA微调量化蒸馏量化叠加效果最佳让模型学会调用外部工具微调提示词不稳定工具调用需要结构化指令遵循接下来是实操避坑清单每一条都是我或团队在实际项目中踩过或围观过的做蒸馏时先确认教师模型本身的准确率。教师模型能力不够蒸馏出来的学生模型只会更差。做RAG时不要省略重排序这个环节。精简的向量召回会导致关键信息埋没在噪声里。做微调时设置合适的评估集。很多项目只关注训练损失下降却不做真实场景的评测最终上线效果一言难尽。不要混用不匹配的检索维度。比如用通用中文嵌入模型去检索代码库或者用英文模型检索中文文档效果都难以保证。蒸馏小模型的数据量不是越多越好关键是多样性。如果数据只有一种任务模式学生模型的泛化能力会很弱。微调后的模型一定要跟基础模型做“回退对比”。我有一次微调一个模型用于合同信息抽取结果发现它把所有中文都理解成合同条款格式通用能力大幅退化幸好保留了一份微调前的备份才能及时回滚。7. 组合实践一个知识问答系统的完整链路配置为了让你更直观地理解三者如何协同我简单描述一个已上线的知识问答系统链路这个链路被我拆解过很多次也分享给过不少同行参考。第一步原始文档经过解析和分块构建成向量知识库。项目使用了开源的文本切分器块大小设置为384 Token重叠区间64 Token嵌入模型选择中文领域表现稳定的开源模型。向量索引部署在社区版向量数据库上支持百万级规模检索延迟控制在10毫秒内。第二步在检索链路里加入了一个重排序模型。重排序模型接收检索到的Top 100条候选逐条计算与用户问题的语义相关度输出Top 5作为最终生成上下文。这一步让最终答案的准确率提升了约15个百分点值得投入。第三步对生成模型做了指令微调用的就是LoRA方法。训练数据来自业务侧整理的1200条客服对话样本任务目标是让模型遵循特定的开场白、转换句和结束语模板。训练过程在单台消费级GPU上完成耗时约3小时适配器文件只有约80MB部署时与基础模型合并加载。第四步对微调后的模型做蒸馏。教师模型就是微调后的7B模型学生模型目标是1.5B参数量的小模型。蒸馏数据由教师模型在20000条抽样问题上生成经过规则过滤后保留了约13000条高质量输出。训练完成后学生模型在评测集上相对教师模型的准确率保留了约90%推理速度提升约4倍。整个链路从构建知识库到蒸馏部署前后花了约三周。核心经验是不要一开始就追求全链路最优先让RAG转起来再逐步叠加微调和蒸馏每一步都有明确的评测指标来验证收益。这种渐进式方案既控制了风险也让每一分投入都有了可量化的回报。我自己在实际操作中的一个体会是很多项目失败不是因为技术没选对而是因为不知道在什么阶段该停下来。RAG已经能满足需求时就不要因为“想用新技术”而强行上微调微调已经解决了格式问题就没必要再追求更大的模型。技术只是手段最终目标是让用户觉得好用、让系统稳定。希望在读完这篇文章后你再面对“用蒸馏、RAG还是微调”这个问题时能少一些犹豫多一些判断的依据。 
长河君 · 2026/10/17 6:55:44 · 阅读 1.2k 知识蒸馏、RAG与微调：大模型应用落地的三种核心技术对比
很多人第一次接触大模型的应用开发时都会被这几个术语绕晕知识蒸馏、RAG检索增强、微调Fine-tuning。乍一看都是“让模型变聪明”的手段真到选型的时候才发现它们解决问题的层次完全不同——有的改模型本身有的改输入方式有的改输出约束。作为踩过不少坑的从业者我想用一篇完整的拆解把这三者的区别讲透包括它们各自适合什么场景、为什么这么选、以及怎么组合使用。这篇文章面向的是刚入门的算法工程师、正在做技术选型的开发者以及对大模型落地有需求的业务方。我会尽量把原理讲得接地气同时给出可以直接参考的实操建议。读完你应该能明确回答一个问题手里的项目到底该用蒸馏、RAG还是微调。1. 先把三件事放在同一张桌上对比在深入原理之前我们先把这三件事的定义摆清楚。因为它们经常出现在同一篇技术文章里很容易被误认为是同一类技术的不同变体。知识蒸馏Knowledge Distillation是一种模型压缩技术。核心思路是让一个小模型学生模型去学习一个大模型教师模型的输出行为把大模型的“知识”迁移到小模型里。它解决的核心问题是模型太大、推理太慢、部署成本太高但还想保留大模型的能力。RAGRetrieval-Augmented Generation检索增强生成是一种架构设计模式。核心思路是在生成回答之前先从一个外部知识库中检索相关内容把检索结果拼接进提示词Prompt里再交给大模型生成答案。它解决的核心问题是模型不知道最新信息、不知道私有知识、容易产生幻觉。它不改变模型的权重只改变模型的输入。微调Fine-tuning是在预训练模型的基础上用特定数据集继续训练模型更新部分或全部模型参数。它解决的核心问题是让模型适配特定任务格式、特定领域风格或者特定的输出约束。它改变的是模型本身的参数。从改变对象的角度看蒸馏改变的是模型的“替身”RAG改变的是模型的“输入”微调改变的是模型的“本体”。这是三者最本质的差别。一张简表帮助建立第一印象维度知识蒸馏RAG检索增强微调改变内容模型结构压缩模型输入增强上下文模型参数适配任务核心目的推理加速、部署降本引入外部知识、减少幻觉适配格式、风格、任务是否需要额外数据不需要用教师模型的输出需要构建知识库和索引需要构建训练数据集是否需要重新训练需要训练学生模型不需要训练的是检索器或嵌入模型需要训练模型参数对模型权重的影响生成新模型学生不改变原模型权重改变原模型权重典型适用场景端侧部署、高并发推理客服问答、私有知识库、实时信息查询指令遵循、格式对齐、风格迁移先记住这张表后面每一行的含义都会详细拆开讲。2. 知识蒸馏把大象装进冰箱的艺术2.1 蒸馏到底在蒸馏什么知识蒸馏的关键不在“让小模型模仿大模型的答案”而在于模仿大模型的“行为分布”。如果我们只拿硬标签比如分类任务里的“猫”或“狗”去训练小模型小模型学到的是一个确定的答案。但大模型在预测时其实会输出一个概率分布比如“猫0.7狗0.2兔子0.1”。这个分布里包含了丰富的信息——狗和兔子虽然都不对但狗和猫更像所以它的概率比兔子更高。这种“模糊的正确”就是知识。蒸馏的过程就是用大模型输出的软标签Soft Label去训练小模型让学生的输出分布尽量接近教师的输出分布。这里通常会引入一个温度参数T把原始的logits除以T再进行Softmax得到更平滑的概率分布。温度越高分布越平滑小模型能看到的“暗知识”就越多。举个例子一个识别动物的大模型看到一张猫的图片输出的原始分数可能是猫100、狗20、兔子5。经过温度T3平滑后变成了猫98、狗7、兔子2.8。小模型在训练时不只学“这是猫”还顺带学到了“猫和狗在特征上有相似性”。这种信息在硬标签训练里是学不到的。2.2 蒸馏的常见方式实际操作中蒸馏大体分三类响应蒸馏是最基础的形式只让小模型学习教师模型的最终输出。中间特征蒸馏如FitNet让学生的中间层特征去逼近教师的中间层特征希望学生不止学结果还学推理过程中的表征。关系蒸馏则更进一步把样本之间的关系比如两张图是否相似、两个句子是否语义接近作为蒸馏目标。后两种更适合CV和跨模态场景在纯文本大模型里响应蒸馏仍然是主流。对大语言模型来说现在的蒸馏实践往往并不直接解耦三层做精细化设计而是直接让学生模型去学习教师模型的生成文本。这更像是“弱化版的微调”但数据来源是教师模型生成的而不是人工标注的。2.3 什么时候该用蒸馏蒸馏最大的优势是推理速度的提升和部署成本的下降。一个7B的模型蒸馏成1.5B推理延迟可能降低3到5倍显存占用也大幅下降。如果你的场景是移动端、边缘设备、或者高并发的在线服务蒸馏几乎是必经之路。需要注意的是蒸馏之后的模型能力一定有损耗。哪怕蒸馏技术再成熟小模型也不可能完全复现大模型的能力。它适合的是“能力要求没那么极限、但性能和成本要求很敏感”的场景。如果你的业务本来就是调用云端大模型API蒸馏对你没有意义——因为你替换不了服务端的模型。还有一个容易忽略的点蒸馏需要先有一个“教师模型”。这个教师模型可以是开源的也可以是你自己微调过的模型。如果你有私有数据场景先微调一个大模型再蒸馏成小模型是端侧部署的标准路径。先用大模型表现优秀的私有能力然后用蒸馏把这种能力迁移到轻量模型上。注意蒸馏的训练数据不需要人工标注但需要大量高质量的“教师模型输出”。要避免教师模型在数据上“瞎编”否则会把错误知识一并蒸馏给学生。实际工程中最好对教师输出做一轮自动过滤筛掉低置信度的生成结果。3. RAG检索增强给模型开卷考试3.1 为什么模型会“一本正经地胡说八道”大语言模型的知识来源于训练语料这些语料有极强的时效性和覆盖范围限制。模型不知道2024年之后发生的新闻不知道你们公司内部的产品文档不知道某个私有数据库里的记录。如果强行询问模型只能用泛化能力“编造”一个看似合理的答案这就是幻觉。RAG的核心假设很朴素不指望模型记住所有知识而是让它学会“查资料”。我们在模型生成前先从知识库中检索出与问题最相关的内容片段把这些片段放到提示词里让模型基于这些内容作答。相当于把闭卷考试变成了开卷考试模型不需要记住答案只需要具备阅读理解能力。3.2 RAG的完整工作链条一个完整的RAG系统包含几个核心环节文档加载与解析、文本分块Chunking、向量化嵌入Embedding、向量索引构建、检索相似度计算、重排序Rerank、提示词组装、生成。每个环节都有决定成败的细节。文本分块是最容易被低估的环节。块太大检索出来的内容冗余浪费上下文窗口还可能引入无关信息块太小语义信息不完整检索的精准度反而下降。通用做法是按段落或固定Token数比如每块256到512个Token切分同时设置重叠Overlap区间避免句子在切分处被截断导致语义断裂。向量化是指将文本转换成高维向量语义相近的文本在向量空间中距离更近。这一步需要选择一个Embedding模型像开源的BGE、M3E系列或者商业API服务。嵌入模型的选择要跟检索语言、专业领域匹配否则相似度计算的结果会很离谱。向量索引的构建决定了检索的速度。小规模数据几万条用暴力扫描还行大规模数据必须使用近似最近邻索引比如Faiss、Milvus这类方案支持的HNSW索引。重排序是为了提升检索质量。向量检索的Top几结果通常不够精确尤其在专业知识库里需要用一个交叉编码器Cross-Encoder模型对初筛结果进行精细排序把真正相关的文档排在前面。我见过不少项目忽略了这一步检索结果的准确率差了一截加上一个重排序模型后效果立刻提升。最后一步是把检索到的内容填充进提示词让模型只依据给定材料回答。这里可以加一条限制指令“如果给定材料中没有相关信息请直接说明不知道不要编造。”实验证明这一句简单的系统提示能显著降低幻觉率。3.3 RAG的七十二变RAG不是只能做问答。基于RAG的架构可以演化出很多变体摘要式RAG针对全文检索结果做摘要适用于报告生成、会议纪要等场景。多跳RAG把用户的复杂问题拆解成多个子问题分步检索再综合回答适合知识图谱和复杂推理场景。智能体式RAG模型自主决定检索几次、检索什么内容、何时停止检索适合工具调用和自主任务执行场景。混合检索RAG结合向量检索和关键词检索BM25的召回结果再做融合排序能同时兼顾语义相关性和字面匹配。还有一个容易忽略的趋势RAG已经从“只是检索文本片段”进化到可以检索表格、数据库记录、JSON结构化数据以及代码片段。结构化数据检索通常需要额外的解析与格式化过程但能显著提升回答的准确性。3.4 什么时候该用RAG当你遇到以下情况中的任何一种应该优先考虑RAG知识需要频繁更新今天录入的内容明天就要能被回答出来。知识高度私域比如企业内部的规章制度、产品手册、客服话术。需要模型提供可追溯、可验证的回答依据。幻觉是业务无法接受的比如金融、医疗、法务等高风险场景。RAG最大的优势是不需要训练模型因此周期短、成本低、更新快。你不需要GPU训练集群只需要一个向量数据库和几个开源模型组件就能搭建一个效果不错的RAG系统。RAG也有自己的局限性它对检索质量极其依赖检索结果不好生成答案必然受影响多个知识源之间可能有互相矛盾的表述模型不知道该信哪个处理极长文档时检索完整覆盖困难。提醒RAG项目的成败往往在“文本分块”和“重排序”这两个不起眼的步骤上。很多团队花大精力调提示词却忽视了知识库本身的构建质量最后效果不好就甩锅给“大模型能力不行”。实际上问题多半出在检索侧。4. 微调把通才打磨成专才4.1 微调解决的是什么问题预训练大模型像一个接受过通识教育的毕业生什么都知道一点但不精通任何具体业务的处理规范。你让它帮你写工作日报它能写但格式跟你公司的模板完全不一样你让它按特定的JSON结构输出结果它时好时坏你让它模仿某位作者的文章风格它模仿得四不像。这时候靠提示词已经很难解决了需要微调。微调的本质是用一批“输入-期望输出”样本让模型学习业务数据的分布规律。训练过程会更新模型的权重参数让模型的输出行为向你的数据集偏好靠拢。这种改变是持久化的——模型被训练之后它默认就会按你教的格式和风格回答不需要每次都在提示词里重复要求。4.2 微调的核心方法与策略全参微调Full Fine-tuning会更新模型全部参数。效果通常最好但显存开销巨大7B模型就需要多张高显存GPU训练成本高。实际应用里更多人用的是参数高效微调PEFT。参数高效微调的代表技术是LoRALow-Rank Adaptation低秩适配。它不直接更新原始权重而是给每个线性层并联一个低秩矩阵。训练时只更新这个低秩矩阵的参数原始权重保持不变。LoRA的可训练参数通常只占模型总量的0.1%到1%显存需求大幅下降训练速度明显提升。训练完成后只需要保存一个几十MB的适配器文件推理时动态加载部署非常灵活。另一个常用技术是QLoRA先对模型做4-bit量化再使用LoRA方法微调。这就把微调门槛进一步降低了消费级显卡比如24G显存也能微调7B到13B的模型。在微调的类型选择上指令微调Instruction Tuning是最基础的让模型学会遵循指令完成任务对话微调让模型具备多轮对话能力领域适应微调让模型熟悉特定领域术语和风格。如果你的模型基础能力已经不错只是需要适配某种输出格式或语气风格用少量数据进行高效微调即可无需追求全量微调。4.3 数据质量决定微调上限微调的成败全靠数据。数据数量不需要特别多但质量必须足够高。几百条精心整理的高质量样例效果往往超过几万条粗糙的自动生成数据。实际项目里常见的数据问题有这么几类指令模糊期望模型做什么都没说清楚模型自然学不到要求。答案错误数据里有错误答案模型把错误当成了惯例。分布单一只有一种任务模板模型见到新的句式就不知所措。过长的输入样例太长导致训练慢、显存占用高、过拟合。我在项目里常用的做法是先人工写20到30条“模板种子样例”然后用大模型批量扩展生成更多变体再人工抽查过滤。这类半自动方式既能控制数量规模也能保证质量下限。4.4 什么时候该用微调遇到下面这些情况微调往往是更合适的选择输出格式有严格规范比如必须按特定JSON Schema输出或者必须遵循某种固定话术模板。需要模仿人的特定写作风格、语气或表达习惯。任务本身需要强指令遵循能力比如工具调用、多步推理。提示词和RAG都已尝试过且效果不理想确认是模型“能力边界”问题。微调不是万能的。它不能给模型注入全新的知识——哪怕你在数据集里放了大量新知识模型也很难记住每一处细节而且容易产生“死记硬背”的伪记忆。真正的事实性知识注入还是应该交给RAG。重要微调会改变模型的行为但也可能损伤模型的通用能力。尤其是只拿单一任务数据微调可能会导致灾难性遗忘Catastrophic Forgetting模型忘了原本学会的其他能力。缓解办法是在微调数据里混入一定比例的通用数据或者使用LoRA这类参数高效方法降低对原始权重的破坏。5. 三者的关系不是替代而是组合很多人纠结“这三个我该选哪个”实际上这从来不是一个单选题。在一套真实系统里三者往往会同时出现各司其职。拿一个典型的智能客服项目举例原始需求是用企业私有文档回答客户问题。架构师拆解后很可能这样组合——底层用RAG搭建知识库问答解决私有知识的问题基于上一阶段的效果反馈对模型做一次指令微调让它在客服话术上更规范最后为了降低线上推理成本把微调后的模型蒸馏成一个小模型部署到生产环境。这条链路清晰地展示了三者如何配合RAG负责“实时查资料”微调负责“规范说话方式”蒸馏负责“把模型装进更小的容器”。它们解决的问题不同但最终都在为一个目标服务让AI在业务场景里更可靠、更便宜地工作。还有另一种组合思路用蒸馏获得小模型之后在小模型上做RAG或微调。比如先蒸馏出一个7B模型用于端侧预研再在这个轻量模型上微调任务能力。这时候蒸馏在前微调在后顺序也很自然。从落地成本来看三者也有清晰的梯度RAG最快一两周即可上线微调居中需要构建数据集和训练资源蒸馏最重需要先有教师模型、训练学生模型、再做评估和部署转换。项目初期可以先用RAG验证效果发现问题需要模型能力本身改变时再上微调最后再评估是否值得做蒸馏。6. 一张选型决策表与实操避坑清单为了照顾到正在做架构选型的读者我整理了一张更直接的决策表列出不同业务诉求下的首选方案业务诉求首选方案备选方案理由回答私有知识库问题RAG微调效果差很多知识更新快RAG可随时加数据高速、低成本的端侧模型蒸馏量化不换模型蒸馏能获得更小模型结构严格格式化的结构化输出微调RAG几乎无效格式问题是模型能力边界降低幻觉和编造RAG微调提示约束给模型“材料依据”最有效模仿特定作者文风微调RAG可参考风格但不可靠风格是内化能力系统上线后再更新知识RAG蒸馏蒸馏重新训练代价太大高并发在线推理降本蒸馏LoRA微调量化蒸馏量化叠加效果最佳让模型学会调用外部工具微调提示词不稳定工具调用需要结构化指令遵循接下来是实操避坑清单每一条都是我或团队在实际项目中踩过或围观过的做蒸馏时先确认教师模型本身的准确率。教师模型能力不够蒸馏出来的学生模型只会更差。做RAG时不要省略重排序这个环节。精简的向量召回会导致关键信息埋没在噪声里。做微调时设置合适的评估集。很多项目只关注训练损失下降却不做真实场景的评测最终上线效果一言难尽。不要混用不匹配的检索维度。比如用通用中文嵌入模型去检索代码库或者用英文模型检索中文文档效果都难以保证。蒸馏小模型的数据量不是越多越好关键是多样性。如果数据只有一种任务模式学生模型的泛化能力会很弱。微调后的模型一定要跟基础模型做“回退对比”。我有一次微调一个模型用于合同信息抽取结果发现它把所有中文都理解成合同条款格式通用能力大幅退化幸好保留了一份微调前的备份才能及时回滚。7. 组合实践一个知识问答系统的完整链路配置为了让你更直观地理解三者如何协同我简单描述一个已上线的知识问答系统链路这个链路被我拆解过很多次也分享给过不少同行参考。第一步原始文档经过解析和分块构建成向量知识库。项目使用了开源的文本切分器块大小设置为384 Token重叠区间64 Token嵌入模型选择中文领域表现稳定的开源模型。向量索引部署在社区版向量数据库上支持百万级规模检索延迟控制在10毫秒内。第二步在检索链路里加入了一个重排序模型。重排序模型接收检索到的Top 100条候选逐条计算与用户问题的语义相关度输出Top 5作为最终生成上下文。这一步让最终答案的准确率提升了约15个百分点值得投入。第三步对生成模型做了指令微调用的就是LoRA方法。训练数据来自业务侧整理的1200条客服对话样本任务目标是让模型遵循特定的开场白、转换句和结束语模板。训练过程在单台消费级GPU上完成耗时约3小时适配器文件只有约80MB部署时与基础模型合并加载。第四步对微调后的模型做蒸馏。教师模型就是微调后的7B模型学生模型目标是1.5B参数量的小模型。蒸馏数据由教师模型在20000条抽样问题上生成经过规则过滤后保留了约13000条高质量输出。训练完成后学生模型在评测集上相对教师模型的准确率保留了约90%推理速度提升约4倍。整个链路从构建知识库到蒸馏部署前后花了约三周。核心经验是不要一开始就追求全链路最优先让RAG转起来再逐步叠加微调和蒸馏每一步都有明确的评测指标来验证收益。这种渐进式方案既控制了风险也让每一分投入都有了可量化的回报。我自己在实际操作中的一个体会是很多项目失败不是因为技术没选对而是因为不知道在什么阶段该停下来。RAG已经能满足需求时就不要因为“想用新技术”而强行上微调微调已经解决了格式问题就没必要再追求更大的模型。技术只是手段最终目标是让用户觉得好用、让系统稳定。希望在读完这篇文章后你再面对“用蒸馏、RAG还是微调”这个问题时能少一些犹豫多一些判断的依据。