前言很多同学在面试中遇到“垂直领域项目到底选 RAG 还是微调”时经常会陷入二选一的纠结。其实工业界落地往往是两者结合微调负责教会模型领域内的思考逻辑与行话风格RAG 负责提供最新、精准的事实依据。文章目录前言一、面试常问的二选一本质是个伪命题二、离线准备用微调为知识库铺路2.1 轻量微调建立认知基准2.2 用微调模型反哺 RAG 预处理三、在线推理检索事实与领域逻辑如何融合3.1 领域化查询改写与事实检索3.2 事实依据注入与交叉推理四、线上闭环如何让 RAG 反哺模型迭代五、写在最后一、面试常问的二选一本质是个伪命题去大模型相关岗位面试面试官只要看到你简历上写了垂直领域项目十有八九会抛出这个问题“你们当时为什么选 RAG 而不是微调如果要把两者结合起来你在架构上打算怎么做”很多初学者容易掉进陷阱张口就是“微调成本太高所以选 RAG”或者“微调效果更好所以以后要全换成微调”。这种回答在面试官眼里基本就暴露了工程经验不足。因为在实际生产环境里RAG 和微调根本不是非此即彼的对立关系。我刚开始做垂直领域项目的时候也吃过亏总想着把几万页行业规范和历史案例全塞进模型做全量微调。结果训出来的模型不仅容易把具体的数字、条款编号记串产生严重的幻觉而且一旦法规更新或者业务政策调整模型就必须重新训练一遍。在垂直领域中纯微调与纯 RAG 都有无法绕开的硬伤纯微调的硬伤模型确实学会了行业黑话说话像个专家。但是在面对具体的条款、最新的药物医保报销比例、上周刚修改的规章制度时模型极容易胡说八道。你很难通过调整权重让参数准确记住一条随时可能变动的事实数据更别提微调还会带来灾难性遗忘的风险。纯 RAG 的硬伤外挂检索确实能把最新、最权威的文件原文找出来。但通用大模型没有学过领域内的推理范式当遇到复杂的专业名词组合时模型哪怕拿着查出来的法条或医学病理切片也可能给出完全错误的逻辑推论。两者的职责分工非常清晰微调改变的是认知模型与思考方式RAG 补充的是动态细节与事实依据。核心能力互补微调 Fine-Tuning负责思考逻辑与表达规范检索增强 RAG负责事实证据与最新动态掌握行业行话与复合术语含义理解领域特有推理路径与诊断流程固定输出格式与结构化约束动态补充最新条款与政策文件提供精准事实数字与原文溯源毫秒级知识更新与秒级删除纠错高准确率垂直领域智能体在工程落地时我们通常遵循一个明确的先后节奏优先做 RAG当通用基座模型在理解领域逻辑和行话表达出现瓶颈时再引入轻量微调进行深度配合。二、离线准备用微调为知识库铺路想要把 RAG 和微调结合好第一步并不在在线问答的瞬间而是在离线的数据处理与模型适配阶段。很多团队一听到微调就忙着去抓取用户病历或者具体的裁判文书把每个具体的案件细节做成问答对去硬喂模型。这种做法极易引起过拟合模型把具体的“张三李四”记住了真正的通用诊断逻辑反而退化了。在离线微调模型时我们要牢牢守住一条红线微调只学习领域通用的判断规则与思考流程坚决不记具体的业务数据。知识库增强阶段离线微调阶段行业教材 / 诊断指南 / 办案规范LoRA 轻量微调学习推理范式与专业术语领域基准模型原始专业文档领域感知智能分块领域微调 Embedding向量数据库 / 知识库2.1 轻量微调建立认知基准在构建垂直领域的基座能力时我们尽量采用 LoRA 等轻量微调方式。以医疗场景为例我们应当拿《内科学》、临床诊断指南、分级诊疗规范去微调模型让它掌握高血压的分级标准是依据血压数值与危险因素来综合评估的理解糖尿病各种并发症的病理机制。它必须烂熟于心的是“诊断与鉴别诊断的步骤”而不是“某个医院昨天的病房住了几个病人”。在 Java 后端体系中我们可以通过配置调用微调好的大模型接口统一注入系统级领域设定。下面是一个典型的领域模型客户端配置封装packagecom.crayontech.rag.config;importorg.springframework.context.annotation.Bean;importorg.springframework.context.annotation.Configuration;importorg.springframework.ai.chat.client.ChatClient;importorg.springframework.ai.openai.OpenAiChatModel;ConfigurationpublicclassDomainModelConfig{/** * 注册经过领域微调的专家模型客户端 */BeanpublicChatClientdomainExpertClient(OpenAiChatModelchatModel){returnChatClient.builder(chatModel).defaultSystem( 你是一名经过专业法律与合规领域训练的专家助手。 在分析问题时必须严格遵守以下规范 1. 遵循法律三段论推理先列出大前提法规逻辑再结合小前提具体事实最后给出结论 2. 仅依据给定的事实上下文进行定性不得臆造未说明的客观证据 3. 如果检索依据不足以得出唯一确定结论必须明确提示法律风险与取证要点。 ).build();}}2.2 用微调模型反哺 RAG 预处理经过领域微调的模型对垂直行业的文本结构理解更深。我们可以直接用它来优化 RAG 的知识库构建结构化语义分块普通的 LangChain 或通用分块工具按 512 字符或标点硬切经常把一条完整的法律法规或药理禁忌切成两半。微调后的模型能识别出“总则、分则、例外条款”的语义边界实现按语义完整单元来切分。专业向量与重排优化通用 Embedding 模型很难理解冷门缩写或组合概念。我们可以使用微调过程中整理的高质量领域样本去微调专用的 Embedding 模型或者 BGE-Reranker使得行业专有名词在向量表征上真正聚拢。三、在线推理检索事实与领域逻辑如何融合到了在线问答阶段RAG 与微调模型的协同进入核心执行链路。这里的核心逻辑是用户输入后先做领域化改写由 RAG 检索精准事实再将事实交给微调模型进行专业推理与交叉校验。RAG 检索器微调领域模型服务层RAG 检索器微调领域模型服务层结合领域推理逻辑与真实事实进行三段论推导用户输入口语问题1请求领域术语改写2返回包含标准法条/医学术语的专业 Query3检索匹配事实条款与相似案例4返回 Top-K 权威片段5输入 [改写问题 检索事实依据]6输出严谨答案并标注引用来源7呈现最终答案8用户3.1 领域化查询改写与事实检索普通用户的提问往往充斥着口语大白话比如“老板突然叫我明天去外地分公司上班不去就扣工资这合法吗”如果直接拿这句话去法律法规库里检索向量很难精准匹配到《劳动合同法》第 35 条、第 40 条。此时我们先让微调过的领域模型做一次 Query 改写。因为微调模型懂得行业行话它能敏锐识别出这里的核心法律概念是“用人单位单方变更劳动合同约定的工作地点”并提取出“用人单位调岗”、“单方变更劳动合同”、“劳动争议类似判例”等专业检索词。通过 RAG 模块检索器从知识库中检索出两类关键材料最新法规条款当前的法定劳动合同变更条件与违约赔偿标准。历史真实判例近两地法院对于“合理调岗”与“恶意逼退”的裁量界限。3.2 事实依据注入与交叉推理拿到检索到的事实依据后服务层将用户原始问题、检索到的文档片段打包进 Prompt提交给微调模型。这里的 Prompt 设计非常关键必须明确要求模型把“微调内化的领域逻辑”与“检索出来的客观事实”结合起来packagecom.crayontech.rag.service;importorg.springframework.ai.chat.client.ChatClient;importorg.springframework.stereotype.Service;importjava.util.List;ServicepublicclassDomainRagService{privatefinalChatClientdomainExpertClient;publicDomainRagService(ChatClientdomainExpertClient){this.domainExpertClientdomainExpertClient;}publicStringgenerateVerifiedAnswer(StringuserQuery,ListStringretrievedDocs){StringBuildercontextBuildernewStringBuilder();for(inti0;iretrievedDocs.size();i){contextBuilder.append(String.format([参考条款 %d]: %s\n,i1,retrievedDocs.get(i)));}StringuserPromptString.format( 【咨询问题】: %s 【检索到的法律条文与判例依据】: %s 【分析要求】: 1. 调取你内化的劳动法理逻辑结合上述检索到的参考条文进行严密推导 2. 若检索条文与普遍法理结论出现冲突以本次检索到的最新条文与判例为准 3. 指明每一个定性结论所依据的具体条款编号拒绝泛泛而谈。 ,userQuery,contextBuilder.toString());returndomainExpertClient.prompt().user(userPrompt).call().content();}}微调模型拿到这段输入后开始做推导。它知道调岗通常属于合同内容的重大变更需要双方协商一致如果属于企业自主经营权下的合理调动还要考察工作地点距离变化、薪资福利是否降低、是否具有侮辱惩罚性。这种多层级的排查逻辑是通用模型往往会遗漏的。同时由于它手里有刚才 RAG 检索出来的确凿法规与判例数据回答时就能准确引用条款既有专家的严谨逻辑又有真实条文的数据支撑。四、线上闭环如何让 RAG 反哺模型迭代把 RAG 和微调结合起来之后整套系统并不是一成不变的而是可以通过线上交互数据形成自我进化的闭环。离线迭代飞轮线上服务收集线上 RAG 问答与检索日志高频优质问答与专家纠偏数据构建精调样本对 (Instruction Tuning)二次微调 LoRA 权重高频通用认知内化为权重参数减少在线 RAG 向量链路压力与 Token 消耗在日常运行中系统日志会记录下大量高频的查询问题和检索结果高频知识内化为参数某些基础概念比如“什么是抢劫罪的构成要件”、“高血压的经典临床表现”在知识库中被成千上万次检索。对于这类高度稳态、几乎不会变动的通用定义我们完全可以把这些问答对整理进微调样本库进行二次微调。让模型直接通过参数回答这些通用概念在线上就可以跳过耗时的检索链路直接降低检索延迟与算力开销。防范知识库与模型权重冲突微调模型与 RAG 合作时最忌讳的是“知识打架”。比如模型在微调时记住了旧法规的赔偿上限是 3 倍而 RAG 检索出了最新修订的 5 倍赔偿条款。在系统架构层面必须在 Prompt 中确立最高优先级仲裁规则当微调权重与 RAG 检索到的外部事实冲突时永远强制以 RAG 提供的最新上下文为准。保持微调的克制永远不要为了追求短期指标过度训练。过拟合不仅会让模型丧失对用户多样化口语表达的理解力甚至还会破坏原本通用的指令遵循能力。五、写在最后在垂直领域大模型落地的过程中RAG 与微调绝对不是针锋相对的技术路线而是各司其职的双引擎。记住这个核心判断微调决定了模型像不像这个行业的专家RAG 决定了专家说出来的每一句话准不准。在面试被问到方案设计时从“先 RAG 摸清瓶颈再用微调补强领域推理最后用事实检索约束模型输出”这条链路回答逻辑清晰且非常符合一线工程的真实演进路径。如果你正在准备大模型与 RAG 方向的面试欢迎点个关注。本专栏会持续拆解更多高频大模型面试题与实战落地架构我们下期见