企业官网建设流程全解析

1. 先把概念摆正：预训练、SFT、RLHF到底解决什么问题

聊选型之前，得先把三个词理清楚。很多人听到"预训练-SFT-RLHF"就觉得是一条完整流水线，做应用之前必须从这头走到那头。这个理解不能说错，但它会让你在绝大多数场景下做无用功。我见过不止一个团队，一上来就布线做RLHF，搞了两个月发现业务效果没比直接用API提示词好多少，还搭进去一个人力。

1.1 预训练：模型"会说人话"，但不一定"答你所问"

预训练阶段做的事情，本质上是让模型从海量文本里学语言的统计规律。这一个阶段产出的基座模型（Base Model），常识储备很丰富，措辞也流利，但它并不理解"你在问我"，也不知道对话的格式长什么样。你跟它说"帮我总结这段会议纪要"，它更可能顺着话头继续编一段文本，而不是规规矩矩给你输出几条要点。

这也是为什么基座模型不能直接面向用户。它不是笨，是压根没有"指令-回答"这个行为模式。所以才有后面的对齐步骤。

1.2 SFT：用少量高质量样本校正行为

SFT（Supervised Fine-Tuning，监督微调）做的，就是拿一批"问题-标准答案"的配对数据，把模型从"会续写"掰成"会回答"。这一步的特点是：数据量不需要特别大，几百到几千条优质样本往往就能看到明显效果。它改变的是模型的行为模式，而不是给它塞新知识——这一点很多人搞混了。

我举个生活化的例子。预训练模型像个知识渊博但不太会聊天的人，SFT就是反复给他看"别人问什么，高手怎么答"的对话录，看多了他自己就学会了这套应答范式。注意，他没学到对话录之外的新东西，只是学会了用这套格式去组织自己已有的知识。

1.3 RLHF：从"会做"到"做得好"

RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是在SFT基础上，用打分信号继续优化输出质量。SFT教会模型"按格式回答"，RLHF教会它"哪些回答人类更喜欢"。

这一步并不是所有项目都需要的。它适合那些对回答质量有极高要求、且对交互的微妙之处敏感的场景，比如通用对话助手要兼顾安全、有帮助、有礼貌。但如果你是在做一个垂直领域的文档问答工具，SFT加一套好的提示词机制通常就够用了，直接上RLHF属于杀鸡用牛刀——成本高、周期长、还容易让模型在某些小场景下表现飘忽。

1.4 澄清一个常见误区

很多人把预训练模型的版本号和效果直接挂钩，觉得"参数越大的基座模型，微调效果一定越好"。实测下来不是这么回事。你微调之后的效果，取决于基座已有的能力和你数据的匹配度。如果基座模型本身在中文场景、代码场景、或者某个专业领域（如法律文书）表现就一般，你花大力气做SFT是补不齐底层短板的。选基座模型的时候，先拿几个和你业务领域相关的测试题跑一遍基座模型的zero-shot表现，再决定要不要在这上面投入微调预算。

2. 为什么说"别一上来微调"：三个真实的翻车现场

标题里那句"别一上来微调"是我最想强调的。因为在实际项目里，微调是最容易让人产生"我正在努力解决问题"幻觉的手段，但它也是沉没成本最高的一条路。我拆三个典型的失败场景给你看，全是真实发生过的事情。

2.1 场景一：知识没进来，微调当搜索用

有个团队做的是企业内部制度问答。他们收集了两百多个常见问题，做了SFT，觉得模型"懂公司制度"了。上线后发现，员工问的问题换个问法，模型就答偏。原因很简单：制度文本细则是动态变化的，两百多个QA样本里根本没覆盖到位。模型不是搜索引擎，它不会因为你微调过就自动去"查资料"，它只是把你给的样本"背"了下来，遇到没背过的就只能编。

后来我们换成了RAG方案，把制度文档切块入库，问题来了先检索再回答。同样的基座模型，效果直接提升了一个量级。这个翻车的根源不是微调本身差，而是把微调错误地当成了知识注入工具。

2.2 场景二：数据量不够，微调后开始"胡言乱语"

另一个团队做的客服意图识别。他们只有三百条左右的标准话术样本，觉得基座模型通用性不行，就直接微调。训练完一测，原本基座模型能答对的几个通用问题反而答错了——这就是经典的灾难性遗忘。模型在学新任务的时候，把之前预训练阶段学到的一部分通用能力覆盖掉了。

你要知道一个残酷的现实：当你的样本量低于某个阈值（不同模型不一样，但几百条对通用基座来说绝对偏少），微调非但不能提升目标场景效果，反而可能把模型原有的稳定性打坏。这种情况下，优先考虑的应该是更精细的Prompt设计，或者小样本学习（few-shot）套路，而不是直接动权重。

2.3 场景三：评测方式没想清楚，微调完"自嗨"

还有一个踩坑率极高的场景：评测。团队费老大劲做了SFT，让标注员对20条测试用例打了分，发现"模型的回答更像人了"，于是宣布微调成功。结果真正放到线上，用户满意度反而下降。为什么？因为那20条测试用例都是训练集里见过的同义改写，模型等于是在"背答案"。

这是最隐蔽的坑：微调评估必须用与训练数据分布有差异的留出集。如果你没有一套正规的离线评测基准，你的微调效果可能只是自嗨。别急着动模型，先把评测流程搞定，这个投入永远值得。

3. Prompt、RAG、SFT 三者的本质差异与适用边界

选型的核心，不在于技术哪个"更高级"，而在于你的问题到底是哪一类。我把这三样东西的本质和边界拆清楚，你对照一下自己的场景。

3.1 Prompt：零成本的"模型原教旨主义"

Prompt工程看似最简单，其实被严重低估。一个写得好的人，能通过在提示词里塞入清晰的指令、边界约束、示例（few-shot），让基座模型在几十个评测问题上和微调版本打平。原因在于，现代大模型的底座能力已经很强大，很多任务它"本来就会做"，只是你需要告诉它从哪个角度回答、按什么格式输出、边界在哪里。

适合纯Prompt解决的典型的信号有：任务变化频繁（今天做摘要、明天做分类），对响应延迟和成本敏感，团队没有算法背景也能维护。很多业务场景做到这一步就够了，后面再考虑更重的方案。

3.2 RAG：把外部知识变成模型的临时参考

RAG（Retrieval-Augmented Generation）解决的是"模型没学过的知识"——尤其是私有知识、实时信息、长尾细节。它的逻辑是：用户提问时，先从向量库里检索出相关片段，拼进上下文，让模型"带着参考书"回答。相当于一场开卷考试。

RAG的优势在于知识可更新（换库就完事）、可溯源（能指出引文段落）、对模型能力要求相对低（甚至不用微调基座）。它特别适合知识库问答、法律/医疗等强事实性场景、企业内部资料检索。代价是你需要维护一套检索链路：文档解析、切片、向量化、重排。其中切片策略和召回质量直接影响效果，比调模型权重更值得花时间。

3.3 SFT：让模型的"行为模式"永久改写

SFT的适用场景其实比很多人想象得窄。它适合三种情况。

第一种是风格与格式的刚性对齐。比如你要模型永远用表格输出结果、永远用特定口吻回答、必须遵循某些合规话术，这些通过Prompt也能做，但如果线上调用量极大，把行为直接写进权重里能省token和时间。

第二种是任务原型的沉淀。比如你反复用同一种模式处理数据（抽取结构化信息、给客服工单打标签），Prompt方案需要带很长的few-shot模板，那么SFT可以把这套模式固化下来，让线上调用更轻。

第三种是对基座模型能力的定向补强。比如基座在代码注释生成上表现一般，你用几千条高质量代码注释对它做SFT，能把这块能力拔高。

SFT最大的优势是稳定性——行为固化后不再受提示词波动影响。最大的劣势也明显：一旦业务调整，你需要重训，灵活性极差。

3.4 三者并不互斥：混用才是常态

这里要破除一个观念：绝不是"用了RAG就不能做SFT，做了SFT就不需要Prompt"。真实生产系统里，大概率是Prompt搭底、RAG供知识、SFT收尾定行为。后面我会专门讲一套可落地的组合套路，这里先记住：选型的输出不是"单选"，而是"以谁为主、以谁为辅"。

4. 选型决策树：从问题出发一步步判断

标题里说"附决策树"，这里我直接给你一套可复现的判断流程。它不是学术框架，是我在项目里反复用、基本不会出大错的套路。你拿着自己的场景按顺序走一遍就行。

4.1 决策第一步：你是"缺知识"还是"缺行为"？

这是我每次做选型问自己和团队的第一个问题，也是最重要的一个问题。

• 如果用户问的问题，答案知识不在基座模型里（比如内部数据、实时资讯），或者知识是动态变化的——这是缺知识，优先走RAG。
• 如果基座模型什么都懂点，但输出形式不对、回答风格不合、总是答非所问——这是缺行为，优先走Prompt精调，不行再上SFT。
• 如果两者都有，那就RAG和Prompt/微调并行建设，先做RAG再调行为，因为知识侧的确定性收益更高。

这个判断决定了你资源投哪里。方向错了，再努力都白搭。我一再强调这个要点，是因为见过太多团队把"缺行为"误判成"缺知识"——比如模型答得不够好，他们本能地觉得"是知识不够，需要给它灌数据"，结果做了大量SFT，效果还是差，因为真正缺的是输出规范。

4.2 决策第二步：数据量和数据质量，配不配得上微调？

如果你手里连一千条高质量对话样本都凑不齐，且团队里没有算法工程师能反复清洗数据，那就不要做SFT。这不是能力问题，是投入产出比问题。微调的下限不是"模型能不能训动"，而是"数据能不能撑住"。

判断标准：

• 500条以下：不要碰SFT，集中精力做Prompt。
• 500到5000条：可以试轻量微调（LoRA等参数高效微调），但前提是数据质量要非常高，且你能接受反复训练调参。
• 5000条以上且任务模式稳定：SFT才是合理选项，可以开始考虑小规模全参或LoRA微调。

数据质量比数量重要得多。我见过有人用两千条"网上爬来的问答"训完，效果反而倒退了。高质量的微调数据要有几个特点：覆盖面足够、答案权威、格式统一、噪声极少。宁可300条精校数据，不要10000条粗制乱造的。

4.3 决策第三步：你养不养得起"持续迭代"链路？

这是很多人忽略的维度。Prompt方案改起来是按分钟计的，RAG换数据是按小时计的，SFT重训按天计，RLHF按周计。你的业务能接受哪种迭代节奏？

比如你身在一个业务规则经常变化的行业（政策变动、产品频繁更新），那知识侧的动态性太高，SFT不可能跟上节奏。你更需要的是一条RAG链路，知识更新直接换文档或者改向量库即可。反过来，如果你的任务模式非常稳定（比如固定的表单信息抽取），每天跑几十万次，那一次性付出SFT成本，把行为固化下来，再合适不过。

这个维度我命名为"迭代适配度"。选型不能只看当下效果，还要看未来半年的维护成本。选了一个技术上最"正确"但迭代周期完全跟不上业务的方案，迟早会推翻重来。

4.4 完整决策树

基于以上三步，我把整条判断流程整理成文字版。不用再画花里胡哨的图，照着读就行。

开始 → 第一步：缺知识还是缺行为？缺知识优先建设RAG；缺行为进入下一步；两者都有则RAG先行； 第二步：数据量与数据质量是否支撑微调？否则优先Prompt精调；是则进入第三步； 第三步：业务迭代速度快不快？快走RAG+Prompt，慢才考虑SFT固化； 最终：如果走SFT且样本充分，再考虑是否值得用RLHF提升输出偏好；否则停在RAG+Prompt组合即可。

5. 三种方案混用的实战套路：知识进RAG、风格进SFT、逻辑进Prompt

选型决策树走完，大概率你会落到"混用"这个出口。这里我给一套我在几个生产项目里验证过的组合方式，你可以直接参考。

5.1 一个典型的组合架构

以企业智能客服为例，它的结构是三层：

第一层，Prompt负责"理解与规划"。用户问题进来后，先通过一个精调的Prompt让基座模型判断意图：这个问题是需要查内部知识库，还是可以直接基于常识回答，或者是闲聊。同时限定回答格式：先给结论、再给依据、最后给补充建议。

第二层，RAG负责"供给事实"。当Prompt识别出需要查知识库时，触发检索召回，把相关文档片段注入上下文。这一层保证回答的事实来源可靠，同时可以把引用出处一并生成，方便溯源。

第三层，SFT负责"收敛风格"。在基座模型上做一轮轻量微调，让它学会这套固定的规范：回答的开头措辞、出现不确定信息时的表达、拒绝回答的边界用语。这样即使RAG偶尔召回质量一般、Prompt又写得不够严谨，最终的输出风格也不会崩。

这套架构的精髓在于：每一层只解决一个问题，互不越权。RAG不负责改风格，SFT不负责注入新知识，Prompt不负责兜底事实错误——各自的职责边界清晰，出问题时的排查范围也小。

5.2 混用时的优先级与注意顺序

有一个最常见的混用错误是：先微调了模型，然后发现效果不好，又在上面堆RAG和Prompt，结果出问题时完全分不清是训练的问题还是检索的问题。正确的做法是：先搭Prompt+RAG的最小可用闭环，跑稳了，再决定要不要加SFT。

为什么？因为Prompt和RAG的调试成本低、见效快。你先用Prompt把行为约束大体定下来，用RAG把知识问题解决掉，这时候系统已经能跑到七十分。你再观察剩余的错误主要集中在哪：是格式问题多，还是风格问题多，还是特定类型的问题答不准？这时候再做SFT，针对性地去修，方向会清晰得多。

反过来如果一上来就SFT，等于把模型的整个行为模式先固化了。之后发现问题，你改Prompt只能微调边界，改RAG只能调召回，模型主体行为已经写死，想要大改就得重训，资源和时间就这样浪费了。

5.3 混用后的回归测试方案

混用方案上线之后，最怕的是系统级回归。我建议直接建立一套可重复的评测集：准备100到300条覆盖各类场景的测试问题，其中至少三分之一不能在你的训练样本或RAG库里出现过（防止"背答案"虚高）。

每次改动任何一层——不管是调了Prompt、换了检索切片策略、还是上了微调权重——都要跑一遍这套评测集，记录三项指标：回答准确率、格式合规率、不相关回答率（幻觉率）。这能帮你在混用体系里快速定位是哪个环节出了问题。反正我自己项目里，视觉格式合规率是最容易通过Prompt解决的，幻觉问题大多数出在RAG召回质量，而不是模型本身。

另外一个经验是做A/B对比时，别只盯着"答得好不好"。在客服场景这种高频交互里，回答的稳定性、上线后的可运维性，比单次回答质量更重要。一个偶尔惊艳但不稳定的系统，永远不如一个稳定在七十分、从不崩的系统。

6. 实践中的坑与我踩过的错误判断

这部分写给自己也写给同行，算是我在多次选型和实施后沉淀下来的几条关键认知。能帮你躲过大多数典型的坑。

6.1 决策时最容易被忽视的成本项

很多人算成本只算"训练一次多少钱"，忽略了两笔隐性账单。

第一笔是数据成本。SFT的数据清洗与标注，消耗的时间和人力远高于训练本身。一条高质量样本，从起草到审核到定稿，可能花掉一个熟练标注员十分钟。两千条样本就是一个人的一周工作量，这还不算返工。RAG方案同样有类似的成本，但文档切块和向量化的成本是一次性的，比数据标注量级低得多。

第二笔是评估成本。上了SFT或者RLHF之后，你必须为每次模型更新准备一套评测流程。没有评测体系的模型更新就是盲飞。那些说"SFT比Prompt贵在训练"的人，多半还没过评估这一关。

6.2 微调效果"时好时坏"的常见根源

如果你做了SFT后发现效果在部分用例上变好、部分变差，大概率不是模型本身的问题，而是你的数据分布有问题：训练集中某类样本过多，模型过度拟合了这类模式，挤压了其他类型回答的空间。我见过某次微调后，模型对技术类问题的回答变专业了，但对情感类问题直接变得生硬而冷漠——因为训练数据里技术问答占了八成。

遇到这种情况，不要急着加更多参数或者调超参，先回头做数据分布分析：统计你的训练样本在意图维度、句式维度、情绪维度上的分布，尽量贴近真实线上流量。如果线上有20%的闲聊问题，训练数据里至少也得有相近的比例。

6.3 什么时候该放弃SFT？

这里提一个"止损"的判断标准：当你已经投入一到两轮完整训练，且效果提升依然不明显、甚至评估指标倒退时，就应该回头检查选型根基，考虑是不是把问题想错了。

我经历过的典型例子：某场景真正的问题在于用户问法太发散、意图覆盖不全，团队却一直在SFT上优化模型对已有意图的拟合度。这就是明显的用错工具——问法发散是检索/意图路由层面的问题，而不是模型拟合层面的问题。这时候与其继续加数据，不如先做主干的意图归一化或查询改写。有时候，放弃一条错误的路线不是坏事。

6.4 最后分享一个我从多次对比测试里得到的体会

在我自己的项目里，有一个很朴素的观察：**能靠Prompt解决的，不要靠RAG；能靠RAG解决的，不要靠SFT；能用SFT解决的，不要急着上RLHF。**这个原则不是我拍脑袋定的，而是从成本、迭代效率、效果确定性三个维度反复权衡后的结论。越靠前的手段，成本越低、周期越短、问题越可控，越靠后的手段越不可逆。RAG和SFT的实际差距，我在不少场景里测过，多数问题RAG和SFT效果持平，但RAG的迭代和维护压力要小得多。

当然这不代表SFT和RLHF没有价值。恰恰相反，在需要固化行为模式、提升交互体验天花板的场景里，它们是不可替代的。只是我见过太多项目，明明可以用更轻的方案解决问题，却因为"微调听起来更有技术含量"或者"领导觉得微调才有深度"，盲目走了重路线，最后不仅周期拉长，效果也没兑现。

选型的本质，是对问题归因的准确度和对成本收益的判断力。技术永远在更新，但"先把问题看清再动手"的这个原则，什么时候都不过时。希望这篇内容能让你在下一次面对"要不要微调"这个问题时，多一分从容，少一次踩坑。