企业官网建设流程全解析

前言

很多同学在面试中遇到“垂直领域项目到底选 RAG 还是微调”时，经常会陷入二选一的纠结。其实工业界落地往往是两者结合，微调负责教会模型领域内的思考逻辑与行话风格，RAG 负责提供最新、精准的事实依据。

一、面试常问的二选一，本质是个伪命题

去大模型相关岗位面试，面试官只要看到你简历上写了垂直领域项目，十有八九会抛出这个问题：“你们当时为什么选 RAG 而不是微调？如果要把两者结合起来，你在架构上打算怎么做？”

很多初学者容易掉进陷阱，张口就是“微调成本太高所以选 RAG”，或者“微调效果更好所以以后要全换成微调”。这种回答在面试官眼里基本就暴露了工程经验不足。因为在实际生产环境里，RAG 和微调根本不是非此即彼的对立关系。

我刚开始做垂直领域项目的时候也吃过亏，总想着把几万页行业规范和历史案例全塞进模型做全量微调。结果训出来的模型不仅容易把具体的数字、条款编号记串，产生严重的幻觉，而且一旦法规更新或者业务政策调整，模型就必须重新训练一遍。

在垂直领域中，纯微调与纯 RAG 都有无法绕开的硬伤：

1. 纯微调的硬伤：模型确实学会了行业黑话，说话像个专家。但是在面对具体的条款、最新的药物医保报销比例、上周刚修改的规章制度时，模型极容易胡说八道。你很难通过调整权重让参数准确记住一条随时可能变动的事实数据，更别提微调还会带来灾难性遗忘的风险。
2. 纯 RAG 的硬伤：外挂检索确实能把最新、最权威的文件原文找出来。但通用大模型没有学过领域内的推理范式，当遇到复杂的专业名词组合时，模型哪怕拿着查出来的法条或医学病理切片，也可能给出完全错误的逻辑推论。

两者的职责分工非常清晰：微调改变的是认知模型与思考方式，RAG 补充的是动态细节与事实依据。

在工程落地时，我们通常遵循一个明确的先后节奏：优先做 RAG，当通用基座模型在理解领域逻辑和行话表达出现瓶颈时，再引入轻量微调进行深度配合。

二、离线准备，用微调为知识库铺路

想要把 RAG 和微调结合好，第一步并不在在线问答的瞬间，而是在离线的数据处理与模型适配阶段。

很多团队一听到微调，就忙着去抓取用户病历或者具体的裁判文书，把每个具体的案件细节做成问答对去硬喂模型。这种做法极易引起过拟合，模型把具体的“张三李四”记住了，真正的通用诊断逻辑反而退化了。

在离线微调模型时，我们要牢牢守住一条红线：微调只学习领域通用的判断规则与思考流程，坚决不记具体的业务数据。

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 的知识库构建：

1. 结构化语义分块：普通的 LangChain 或通用分块工具按 512 字符或标点硬切，经常把一条完整的法律法规或药理禁忌切成两半。微调后的模型能识别出“总则、分则、例外条款”的语义边界，实现按语义完整单元来切分。
2. 专业向量与重排优化：通用 Embedding 模型很难理解冷门缩写或组合概念。我们可以使用微调过程中整理的高质量领域样本，去微调专用的 Embedding 模型或者 BGE-Reranker，使得行业专有名词在向量表征上真正聚拢。

三、在线推理，检索事实与领域逻辑如何融合

到了在线问答阶段，RAG 与微调模型的协同进入核心执行链路。这里的核心逻辑是：用户输入后先做领域化改写，由 RAG 检索精准事实，再将事实交给微调模型进行专业推理与交叉校验。

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.domainExpertClient=domainExpertClient;}publicStringgenerateVerifiedAnswer(StringuserQuery,List<String>retrievedDocs){StringBuildercontextBuilder=newStringBuilder();for(inti=0;i<retrievedDocs.size();i++){contextBuilder.append(String.format("[参考条款 %d]: %s\n",i+1,retrievedDocs.get(i)));}StringuserPrompt=String.format(""" 【咨询问题】: %s 【检索到的法律条文与判例依据】: %s 【分析要求】: 1. 调取你内化的劳动法理逻辑，结合上述检索到的参考条文进行严密推导； 2. 若检索条文与普遍法理结论出现冲突，以本次检索到的最新条文与判例为准； 3. 指明每一个定性结论所依据的具体条款编号，拒绝泛泛而谈。 """,userQuery,contextBuilder.toString());returndomainExpertClient.prompt().user(userPrompt).call().content();}}

微调模型拿到这段输入后，开始做推导。它知道调岗通常属于合同内容的重大变更，需要双方协商一致；如果属于企业自主经营权下的合理调动，还要考察工作地点距离变化、薪资福利是否降低、是否具有侮辱惩罚性。这种多层级的排查逻辑是通用模型往往会遗漏的。

同时，由于它手里有刚才 RAG 检索出来的确凿法规与判例数据，回答时就能准确引用条款，既有专家的严谨逻辑，又有真实条文的数据支撑。

四、线上闭环，如何让 RAG 反哺模型迭代

把 RAG 和微调结合起来之后，整套系统并不是一成不变的，而是可以通过线上交互数据形成自我进化的闭环。

在日常运行中，系统日志会记录下大量高频的查询问题和检索结果：

1. 高频知识内化为参数：某些基础概念（比如“什么是抢劫罪的构成要件”、“高血压的经典临床表现”）在知识库中被成千上万次检索。对于这类高度稳态、几乎不会变动的通用定义，我们完全可以把这些问答对整理进微调样本库，进行二次微调。让模型直接通过参数回答这些通用概念，在线上就可以跳过耗时的检索链路，直接降低检索延迟与算力开销。
2. 防范知识库与模型权重冲突：微调模型与 RAG 合作时，最忌讳的是“知识打架”。比如模型在微调时记住了旧法规的赔偿上限是 3 倍，而 RAG 检索出了最新修订的 5 倍赔偿条款。在系统架构层面，必须在 Prompt 中确立最高优先级仲裁规则：当微调权重与 RAG 检索到的外部事实冲突时，永远强制以 RAG 提供的最新上下文为准。
3. 保持微调的克制：永远不要为了追求短期指标过度训练。过拟合不仅会让模型丧失对用户多样化口语表达的理解力，甚至还会破坏原本通用的指令遵循能力。

五、写在最后

在垂直领域大模型落地的过程中，RAG 与微调绝对不是针锋相对的技术路线，而是各司其职的双引擎。

记住这个核心判断：微调决定了模型像不像这个行业的专家，RAG 决定了专家说出来的每一句话准不准。在面试被问到方案设计时，从“先 RAG 摸清瓶颈，再用微调补强领域推理，最后用事实检索约束模型输出”这条链路回答，逻辑清晰且非常符合一线工程的真实演进路径。

如果你正在准备大模型与 RAG 方向的面试，欢迎点个关注。本专栏会持续拆解更多高频大模型面试题与实战落地架构，我们下期见！