这两年做企业AI落地，被问得最多的问题之一就是：先吃透RAG还是先训自己的模型？说真的，每次听到这个问题我都有点恍惚。因为它本质上不是一道选择题，而是一个被市场情绪包装成选择题的陷阱。很多技术负责人一上来就拍板：我们是不是该微调一个行业大模型？团队里同时会有人反驳：先别急着训练，检索增强生成（RAG）不是见效更快吗？两边吵到最后，项目组卡在方案评审上，连第一份语料都没整理完。
我写这篇东西的目标很明确：把"先吃透RAG还是先训自己的模型"这个纠结拆开，讲清楚两者到底在解决什么问题、各自的成本边界在哪、什么样的业务场景必须上微调、什么样的场景上了微调就是浪费钱。如果你是技术负责人、算法工程师，或者是正被业务部门追着问"我们的模型什么时候能上线"的项目经理，这篇内容应该能帮你少开三次无效评审会。
1. 这个选择题是伪命题：先搞清RAG和微调分别改的是哪一层
1.1 用"参考书"和"答题习惯"理解本质区别
我习惯用一个考试类比来讲两者的差别。
RAG做的事情，是考试时允许学生带一本参考书进去。学生原有的知识水平不变，但你给他配置了一本随时可以翻阅的资料库。每次答题前，他会先查资料，把相关资料翻出来，边看边写。所以你改变的是"答题时的信息来源"，而不是学生本人的记忆和习惯。
微调做的事情，是让这个学生在考前进行大量的专项训练，通过反复刷题改变他回答问题的倾向、风格、语气和思维方式。训练完之后，哪怕不给他参考书，他的答题水平也已经不一样了。你改变的是模型参数本身。
从这个角度看，RAG和微调根本不在同一个层面上，二选一从逻辑上就不成立。一个改的是推理时的上下文输入，一个改的是模型内部的权重参数。
但企业项目里，这两个词被拿到了同一张方案PPT里做对比，好像选了A就不能选B。实际上，我在过往项目里见过最多的组合恰恰是：微调改变模型的表达习惯，RAG负责提供事实依据，两者各干各的，最后拼成一个完整系统。
1.2 企业里最常见的三个错误预期
把选择题做成伪命题的，往往是这三类错误预期。
第一种，以为微调之后模型就"什么都会了"。很多业务方认为，微调等于把行业知识灌进模型脑子里，训练完就是一个行业专家。但模型参数里能学到的知识非常有限，特别是高频更新的业务知识。今天训完的知识点，下个月业务规则一改，模型一点反应都没有，除非重新训练。知识的保持和更新，从来不是微调的优势项。
第二种，以为RAG只是过渡方案，最终还得微调。这种预期会导致团队在RAG上草草落地，凑个Demo给领导看，然后就急着启动微调。结果RAG的文档切分、检索质量、召回链路全是半成品，上线后效果惨淡，只能回头重新打磨，返工成本高得离谱。
第三种，以为企业需要"训一个自己的大模型"。绝大多数企业根本没有从零训练基座模型的条件，也没有必要。你真正需要的，是在一个通用基座之上做轻量级的适配。所谓"训自己的模型"，通常指的就是微调，而且是最轻量级的LoRA或QLoRA。但这个词在汇报PPT里被无限拔高，最后连团队自己都搞不清到底要干什么。
1.3 一个先微调后返工的真实样本
去年我遇到过一家做客服知识库的中型企业，技术负责人是个很有冲劲的年轻人，上来就要微调。理由是领导在行业大会上听了别人的分享，觉得没有自研模型就没有技术壁垒。团队花了大三周时间，用爬来的历史对话整理成训练集，在开源基座上做了一轮LoRA微调。
上线后发现一个问题：模型回答的语气像模像样，但只要业务资料一更新，回答就必然出错。因为训练集里的知识是三个月前的，而知识库每天都在变。最后实在没办法，还是补了一套RAG链路，用向量库挂接最新的业务文档，再让微调模型基于检索结果做回答。前后多花了五周，才勉强上线。
这个项目的失败不在技术上，而在起点就把问题定义错了。他们真正的痛点是"知识更新太快，答案跟不上"，而不是"模型说话不像客服"。前者是RAG的主场，后者才需要微调。
2. 为什么我建议企业先吃透RAG：时间、底牌与成本的三笔账
2.1 一周跑通最小闭环的完整链路
先吃透RAG的第一个理由，是它能以极短的时间跑通一个真正能用的系统。我在多个项目里验证过，只要语料质量不是特别离谱，一个最小闭环一周内可以完成。
这个最小闭环包括以下环节：
第一步，收集与清洗文档。把业务里的操作手册、FAQ、制度文件、历史工单汇总，去重、去噪、转成统一格式。这里最耗时的不是技术，而是业务部门愿不愿意把文档交出来。
第二步，文档切分。按固定长度切分是最省事的起点，但会遇到段落被拦腰截断的问题。我更推荐按语义结构分段，优先保留标题、列表、段落这些边界，再配合适当的overlap。常见的起步参数是chunk大小为256到512个token，overlap在16到64之间。这个值需要根据你的文档密集程度试，没有放之四海皆准的答案。
第三步，向量化。用现成的embedding模型把切好的文档块转成向量，存入向量库。这一步的投入主要是调用费用和少量工程时间。对十万条文档级别的知识库，向量化过程的成本通常可以控制在很低的水平。
第四步，检索。线上收到用户问题时，先把问题向量化，再到向量库中找出最相关的Top N个文档块。如果专业名词特别多，纯向量检索效果容易崩塌，建议加上BM25这类关键词检索，做混合召回，再用RRF之类的算法融合排序。
第五步，重排与生成。把召回的文档块用重排模型精排，选出最相关的三四块，连同用户问题一起塞进Prompt，交给大模型生成答案。Prompt模板我通常这么写：
你是某企业的智能客服，请严格根据参考资料回答问题。 如果参考资料中没有答案，请直接回复"资料库中未找到相关内容"，不要编造。 参考资料： {context} 用户问题： {question}这套链路跑通之后，业务人员当场就能体验。比起微调动辄几周的培训周期，RAG在"让老板尽快看到东西"这件事上有绝对优势。
2.2 数据与权限的双重底牌
第二个理由是数据底牌。企业数据有三怕：怕泄露、怕更新、怕说不清来源。
RAG在这三方面天然占优。数据不需要进入训练集，也就不存在训练后参数记忆导致的泄露风险。知识更新时，不需要重新训练模型，只要替换向量库里的文档即可，索引重新生成就能生效。更重要的是，RAG的每次回答都能附上引用来源，业务部门可以点开看到是哪一份文档、哪一个段落支撑了这个答案。这种可解释性，对合规审计来说是硬性要求。
微调做不到这几件事。参数里的知识一旦沉淀进去，你很难定位某条回答到底是基于哪条训练数据学出来的。这倒不是微调的过错，而是它天生如此。所以但凡项目涉及敏感数据或强审计要求，RAG几乎都是必选项。
2.3 训练和调用，成本不是一个量级
第三个理由是成本账。我把两者在真实项目里的投入拆开算给你看。
RAG的成本主要由三块组成：模型调用费、embedding费用、向量库存储费用。模型调用费按token计费，一次普通问答通常消耗几百到上千个token，成本在几分钱量级。embedding费用很低，十万篇文档的向量化消耗可能只有几十到几百元。向量库存储更是便宜。
微调的成本则完全不同。以常见的7B到14B参数规模开源基座为例，即便用LoRA这类参数高效微调方法，也需要几十到几百GPU时，取决于数据量和上下文长度。如果团队没有现成GPU资源，云上租用算力也是一笔不小的支出。更隐蔽的成本是数据标注。训练指令数据需要人工编写或清洗，几百条还能凑合，几千上万条就需要投入大量人天。业务方一旦发现微调还要他们配合标注数据，热情通常会下降一半。
一个大致对照如下：
| 项目 | RAG | 微调（LoRA/QLoRA为主） |
|---|---|---|
| 首次上线时间 | 1周左右 | 2到6周 |
| 主要成本项 | API调用、向量化 | GPU算力、数据标注 |
| 知识更新 | 替换文档即可 | 需重新训练 |
| 可解释性 | 可附引用来源 | 难以归因 |
| 数据泄露风险 | 低 | 相对更高 |
当然，RAG不是没有成本。当调用量大到一定程度，token费用也会变成可观的数字。但和微调动辄几十人天、上百GPU时的前置投入相比，RAG的前期门槛仍然低得多。
2.4 RAG解决不了"不会、不想、不该"
把RAG说成万能解药同样不客观。它有明显的天花板。在我看来，RAG处理不了三类问题。
"不会"的问题。模型本身的能力边界限制了它理解复杂指令的水平。你给它的参考文档再全，它也可能读不懂文档里的隐含逻辑，更不会像资深员工那样结合上下文做出专业判断。检索得到的是材料，能不能用好材料是模型的底子决定的。
"不想"的问题。业务往往对输出风格有强烈要求：客服要亲切耐心，法律意见书要严谨克制，营销文案要有网感。这些风格偏好是模型的行为倾向，不是资料内容。RAG可以把风格要求写进Prompt，但Prompt对这种隐性偏好的约束力很有限，尤其在输出长度较长、格式复杂的场景。
"不该"的问题。安全底线、合规边界、话题回避。这些规则需要模型在深层层面形成稳定的行为模式，RAG加Prompt的方式面对对抗性输入时会显得很脆。
当业务瓶颈恰好落在这三"不"上，微调就从一个可选项变成了必选项。
3. 别把微调当万能药：从业务场景倒推哪些问题它绕不开
3.1 行为约束型任务：风格、格式、结构偏好
我在大量项目里总结出一个判断维度：这个任务究竟是知识约束型，还是行为约束型？
知识约束型任务，答案取决于"知不知道某个信息"。比如产品参数、退换货政策、行业法规。这类任务直接选择RAG，知识从检索中来，准确且可追溯。
行为约束型任务，答案取决于"用什么方式把话说出来"。比如客服回答的开场白和收尾语、合同风险提示的措辞、代码审查意见的格式。这类任务即使你把规则写进Prompt，模型也可能在长上下文中遗忘，或者在不同问法下表现不稳定。微调的优势恰恰在于：把行为偏好固化到参数里，让它成为一种"本能反应"。
举个真实的业务卡片。我服务过的某物流企业，需要让模型把客服回答控制在一百五十字以内，并且必须包含三部分：致歉、原因、解决方案建议。这个要求用Prompt也能描述，但那段时间测试下来，模型经常漏掉第三部分。后来他们从历史工单里抽出两百条典型对话做微调，漏格式的问题很快缓解了。
3.2 领域语言模型：术语、黑话、行话
每个行业都有自己的"方言"：金融领域的各种缩写、法律条款里的长难句结构、制造业设备维护手册里的专业名词。通用模型对这些内容的理解经常跑偏。
RAG能缓解这个问题。你可以把术语解释文档放进知识库，让模型随时查。但这里面有个隐藏麻烦：术语表通常很简短，不适合作为独立文档块参与检索。短文本的召回效果普遍不稳，很多干脆在检索阶段就漏掉了。而术语又是贯通上下文的，几乎每段回答都要用到，每次检索都依赖外部插入显然不稳定。
这时候微调的价值就出来了。把企业内部的高频术语解释、惯用句式塞进训练数据，让模型在参数层面记住这些表达习惯。用行业术语说，这叫提升模型对特定领域文本分布的拟合能力。
但这里我要强调：领域词表、术语表、内部黑话这几样东西，不需要太多数据就能学会。几百到一千条精心构造的语料就足够让模型"开窍"。真正困难的是让模型像资深员工一样处理复杂推理，那才是数据量喂不出来的能力。
3.3 幻觉到底能不能靠微调根治
很多人寄希望于用微调解决幻觉问题。我的看法比较直接：微调可以降低幻觉的出现率，但根治不了。
先说为什么能降低。微调相当于反复强化训练模型在特定场景下的回答模式。如果训练数据里反复出现"不知道就直说不知道"的示例，模型确实会更倾向于拒答或承认自己不知道。对于高频业务问题，微调可以显著降低模型瞎编的概率。
再说为什么根治不了。幻觉的大头来自推理时的外推和归纳偏差。模型在生成阶段碰到不熟悉的表达时，会本能地"脑补"。微调只是让模型在某些领域内更谨慎，但一旦超出训练分布，它照样会编。更麻烦的是，微调引入的大量新知识，有时会提高模型在训练分布内的流畅度，同时增加它在边界问题上的"自信幻觉"。
所以我的实操建议是：生产系统里，微调模型之后依然要挂RAG做事实校验。微调负责风格和表达，RAG负责兜底事实。两者配合之后，整体的幻觉水平才能压到业务可接受的范围。
3.4 微调技术选型：从全参到LoRA、QLoRA
如果走到必须微调这一步，技术选型同样有讲究。当前企业场景下，我几乎不推荐全参微调。原因很简单：全参微调需要更新的参数太多，显存开销大，数据量要求高，而且非常容易破坏基座模型的通用能力。对大多数企业需求来说，这是典型的杀鸡用牛刀。
LoRA是目前性价比最高的起点。它只训练一小部分低秩适配参数，显存占用大幅下降，数据需求也友好很多。做下游任务适配、风格改造、格式约束，LoRA的效果和全参微调已经非常接近。
QLoRA则进一步引入量化，把基座模型压到4bit精度训练。它的最大价值在于，单卡甚至消费级显卡都能跑起来。这对没有GPU集群的中小团队来说意义重大。我见过有人用两张卡跑通13B模型的LoRA微调，速度慢一点，但流程完全可行。
选择时可以参考这个简表：
| 方法 | 参数量更新 | 显存需求 | 数据量需求 | 适合场景 |
|---|---|---|---|---|
| 全参微调 | 全部参数 | 高 | 大 | 极少，企业场景基本不推荐 |
| LoRA | 0.1%-1% | 中 | 中 | 大多数企业的默认选择 |
| QLoRA | 同LoRA | 低 | 中 | 资源受限或快速验证 |
我反复跟团队说一句话：微调手段越轻越好，能用几千条数据解决的，绝不上万条；能用单卡解决的，绝不上集群。
4. 四张表定路线：判断"先做谁"的决策框架
4.1 第一张表：知识密度与行为约束的二维判断
我项目里用的第一张决策表，是看业务任务的属性。横轴是知识密度，纵轴是行为约束。
知识密度高，意味着答案大部分内容来自外部资料，比如产品说明书、政策法规、历史案例。行为约束高，意味着答案的句式、格式、语气、结构有强要求，比如法律意见书、客服标准话术、工单分类描述。
不同组合的结论完全不同。
| 业务特点 | 纵轴行为约束低 | 纵轴行为约束高 |
|---|---|---|
| 横轴知识密度高 | 优先RAG，微调基本不用 | RAG先打底，用微调解决格式问题 |
| 横轴知识密度低 | 两者都不需要，优化Prompt即可 | 优先微调，RAG只做补充 |
拿这个表去过一遍项目需求，大部分团队的纠结能立刻消掉一半。
4.2 第二张表：成本与时效的预算判断
第二张表是看业务方的耐心和预算。
如果业务方要求两周内看到可体验的Demo，那就不要在微调上浪费时间。RAG是最稳妥的交付物。反过来，如果项目周期是按季度算的，且业务方明确表示可接受GPU算力和标注人力的投入，那微调的空间就大多了。
这张表里，除了钱和算力，还要把"业务方配合度"算进去。微调数据的整理需要业务专家介入，如果业务方连每周两次评审都不愿参加，微调基本做不成。
| 项目周期 | 两到三周 | 一到三个月 |
|---|---|---|
| 推荐方案 | RAG为主 | RAG打底，同步规划微调 |
| 前置投入 | 语料整理 | 标注人天与算力申请 |
| 风险点 | 知识更新频繁时体验下降 | 业务配合度不足导致延期 |
4.3 第三张表：评估指标倒逼初始决策
第三张表，是用评估结果倒逼路线。我建议所有项目在动手前就准备一套一百到三百条真实业务问题的评估集。不一定是标准答案，但要有明确的"好答案"和"坏答案"判断标准。
先用通用模型加RAG在这个评估集上跑一轮，然后按错误类型归类。
| 错误类型 | 表现 | 指向 |
|---|---|---|
| 检索失败 | 资料库里有，但没召回 | 优化RAG切分和检索 |
| 召回成功但答错 | 相关文书在上下文中，模型没用对 | 考虑微调或Prompt重构 |
| 格式不符 | 内容对，但语气、结构不对 | 微调是优先选项 |
| 知识不存在 | 资料库里确实没有答案 | 先补文档，别急着训模型 |
这一步做完，路线往往是自动显形的。如果评估集上大量是检索失败，你却跑去微调，那就是拿大炮打蚊子。如果大量是格式不符、风格不对，那RAG再优化也无济于事，微调的窗口才真正打开。
4.4 第四张表：团队能力模型
第四张表最简单，但最容易被忽视。我正在看的团队里有没有能啃训练代码的人？
RAG系统涉及的技能栈相对工程化：Python脚本、常见向量库、调用模型API，这些在大多数技术团队里都能找到人。微调则不同，涉及数据构造、训练参数调整、显存管理、过拟合判断等。没有相关经验的团队，光是理解loss曲线和验证集性能的关系，就要耗掉一周。
| 团队情况 | 推荐路线 |
|---|---|
| 纯业务/工程团队，无算法背景 | 先建立RAG基线，微调列为长期投入 |
| 有1至2名算法工程师 | RAG基线通过后，启动LoRA微调 |
| 高要求业务，成熟算法团队 | 直接做RAG+微调混合架构 |
这不是说没有算法团队就不能微调，而是说要在正确的时间点启动。先用RAG把业务跑熟、把数据积淀下来，等算法能力补充到位，微调就是顺水推舟。
4.5 综合决策流程
四张表看完，实际操作时我建议按这样的顺序过一遍。
先拿业务需求按第一张表划象限。若落在"高知识密度+低行为约束"，RAG直接开干；落在"低知识密度+高行为约束"，直接规划微调；落在"高知识高约束"，先启动RAG，把微调列入二期。再看第二张表确认时间窗口和预算，匹配第三张表的评估集准备，最后用第四张表确认团队的启动能力。
这套流程我用了很久，它最大的价值不是让人"选对"，而是让团队在争论时有了同一套语言。所有分歧最后都会收敛到"我们的业务到底属于哪一类"这个问题上。
5. 渐进路线：RAG验证需求、微调补齐短板、混合架构收尾
5.1 第一阶段：把RAG做到"能懂业务"而不是"能跑通"
如果一个项目采纳了我的建议，从RAG起步，那我的要求通常是：别满足于Demo能出答案，要做就把检索质量做到位。
这一步的交付物不只是"能回答问题的系统"，还包括三样东西。第一，清洗后的语料库管理规范。文档从哪来、多久更新、谁负责审核，都要有明确答案。第二，检索评估集。把高频问题和难题各抽几百条，标注"预期答出哪些知识点"，用来量化召回效果。第三，badcase沉淀库。每次测试发现答错的样本，按检索问题、召回问题、生成问题归类。
这三样东西做完，RAG系统不只是一个功能，而是一套持续改进的机制。很多团队之所以在RAG上得不到好效果，不是技术没到位，而是连"什么叫做得好"都定义不出来。
5.2 第二阶段：用badcase驱动微调数据构建
RAG上线跑一段时间后，你会积累一批典型的badcase。这些样本有一个共性：参考文档已经给到了上下文里，模型还是答得不对。可能是格式不对、语气不对、融合信息的方式不对，也可能是对文档里的冲突信息选择了错误的解读方式。
这批样本，就是微调最好的种子数据。
我常用的做法是：从badcase里挑出最常出现的几类行为问题，编写对应的标准答案，构建一份微调数据集。每条样本都保留原问题、检索到的上下文、人工修正后的标准答案。数据量不一定要大，五百条高质量样本，往往就能在行为约束类任务上看到明显改善。
这里有个关键动作：微调数据里要刻意混入一部分"上下文中没有答案"的样本，标准答案是"资料库中未找到相关内容"。这能抑制模型在RAG漏召回时强行编答案的老毛病。
5.3 第三阶段：混合架构，让分工清晰
当微调模型训练完成，最忌讳的做法是整个系统彻底切到微调模型，从此不RAG。我在前面已经说过，只要知识还在持续变化，RAG就不可缺席。最终形态是混合架构。
这套架构里的分工非常清晰：
微调模型负责"怎么答"：控制语气、格式、结构、拒答方式。RAG负责"答什么"：提供最新的知识依据。系统每次推理时，先走检索链路拿到候选文档块，再把文档块交给微调模型做最终生成。如果检索为空，微调模型按训练时的动作输出"未找到相关内容"。
工程上还要注意版本治理。模型文件、知识库索引、Prompt模板三个版本要分开记录。我看到很多团队在混合架构上线后，分不清某次效果变差到底是模型更新造成的，还是知识库索引更新造成的。为此，一套简单的实验记录表就能避免大量内耗。
5.4 演进路线中的评测和回归
无论是RAG阶段还是微调阶段，评测集都要保持稳定。我每次微调前都会先跑一遍基线评测，微调后再跑同样的评测集，看行为约束类指标是否上升、知识回答类指标是否回退。微调最常见的副作用是灾难性遗忘：模型学会新风格的同时，丢掉了部分通用能力。评测回归就是为了拦住这种情况。
上线之后，还应安排小流量灰度，把真实用户反馈回流到badcase库。这样每轮迭代都有真实数据支撑，而不是靠建模的人拍脑袋。
6. 实操中反复踩过的坑：检索、数据与评测的细节
6.1 检索阶段偷懒，后面所有优化都白做
我见过不少项目把精力全花在生成侧：Prompt写得极其花哨，微调数据一轮接一轮。但检索召回质量一塌糊涂，答案自然漏洞百出。
检索阶段最典型的问题有三个。
第一个是切分不合理。chunk过大，塞进上下文的内容太多，噪声淹没关键信息；chunk过小，语义断掉，召回不完整。我建议起步时切512左右，然后拿实际文档做命中测试，而不是闭着眼睛抄参数。
第二个是只用向量检索。企业文档里大量专业缩写和编号，这类文本向量化后很容易跑偏。混合检索，也就是向量检索加BM25关键词检索融合，效果通常稳定得多。
第三个是不做重排。向量召回TopN里经常混着一些语义接近但其实无关的碎片。如果不加粗排，生成模型很容易被噪声带偏。单独接一个重排环节，哪怕只是简单规则过滤，也能明显提高答案质量。
6.2 微调数据污染，模型学会"抄参考答案"
另一个坑，是训练数据里包含标准答案文本。
某一次项目里，团队成员为了让模型学会回答公司政策问题，把政策原文档直接当成了训练数据。结果模型在推理时，只要输入里有一丁点相关词语，就直接背诵大段原文，而不是结合检索上下文作答。这就是数据污染带来的"抄参考答案"倾向，模型没有学会理解问题，只学会了条件反射。
避免方法很直接：训练集和检索知识库必须隔离。微调数据里不要把知识原文大量整段放入。如果确实要让模型熟悉某个风格，应该用改写后的问答对，而不是原文。
6.3 评测自我欺骗：拿同一个模型生成的badcase再训同一个模型
最后说评测。这是我最想提醒的一点：不要拿微调前模型的badcase，直接作为微调后的验收样本。这样做会产生严重的幸存者偏差。
道理不难懂。微调本质上是让模型在这批badcase上反向优化，所以它当然能在这些样本上表现变好，但这证明不了它对更广范围问题的泛化能力。真正的验收样本，应该从线上真实流量、业务专家新提出的问题中随机抽取，并且和训练集严格区分。
我当时踩过一次坑：用一套旧badcase验证新模型，跑分漂亮得惊人，上线后实际体验却只提升了一点。后来发现，评估集和训练集的样本高度重叠，等于自己出题自己考。从那之后，我坚持每个月人工抽取一批新样本进入评测集，并对旧样本做洗牌替换。
另外，自动评估指标可以辅助，但不要迷信。回答的语义相似度再高，也可能掩盖了"没用到检索文档里的关键数字"这类事实性错误。关键业务场景一定要有人工抽检，比例不低于百分之十到二十，否则指标会撒谎。
6.4 更新与版本治理：长期维护的最后一环
系统上线不是终点。知识会更新，业务规则会变化，模型基座也会换新版本。没有版本治理的AI系统，三个月后就变成一团谁也说不清的毛线。
我的做法是，每次知识库索引重建、每次大模型版本升级、每次Prompt大改，都记录一条实验日志：修改内容、预期效果、实测效果、回滚方式。RAG方案里知识库可以快速回滚，微调模型也有单独的版本号，这样出了问题能够迅速定位。
这块工作不产生炫酷的Demo，却决定了系统能不能长期稳定运行。企业做AI项目，最怕的不是合作方一开始效果不好，而是效果不稳定、出了问题没人说得清原因。版本治理就是对抗混乱的底线工程。
最后再分享一条这几年攒下来的经验：微调不是"技术先进性"的证明，更不是企业AI能力建设的必经仪式。我的默认路线从来都是先RAG后微调，而判断要不要启动微调的唯一标准，是评估集和线上badcase里是不是大量出现"检索到位了但模型输出不对"的行为问题。如果是，那就果断上微调。顺便说一句，微调的种子数据直接来自RAG阶段的badcase库，配合人工改写，比凭空造数据靠谱得多。
