这不是“用不用 RAG”，而是“RAG 能不能解决这个问题”
在过去一年里，几乎所有团队在遇到生成效果问题时，都会下意识问一句：
“是不是该加个 RAG？”
RAG 已经成为一种工程直觉：
只要模型答得不好，就怀疑是“没看到资料”。
但春节祝福这个场景非常残酷地揭示了一件事：
有些问题，
模型不是“不知道”，
而是“知道了也不该这么说”。
这正是微调和 RAG 分道扬镳的地方。
这篇文章，不是要否定 RAG，而是借「码上拜年」这个案例，认真回答一个工程问题：
在强风格、强分寸、强一致性的生成任务中，
微调和 RAG，各自到底解决什么，又解决不了什么？
一、先把任务说清楚：春节祝福到底“难”在哪里
在讨论技术方案之前，必须先明确任务本身的性质。
春节祝福这个任务，看起来很轻，但它有几个非常明确的特征：
- 模型本来就会写祝福
- 不涉及事实查证
- 不依赖外部知识库
- 但用户对“语气是否合适”极其敏感
真正的难点在于：
- 你对谁说
- 在什么关系下说
- 用什么风格说
- 说到什么程度才不越界
这不是一个“信息不足”的问题，而是一个表达偏好和默认选择的问题。
换句话说：
模型的知识是够的，
但它的“默认说法”不对。
这是后面所有技术选择的前提。
二、RAG 天然擅长什么，又天然不擅长什么
要公平讨论，必须先承认：RAG 是一个非常成功、非常重要的工程范式。
RAG 擅长解决的问题是：
- 信息确实存在，但模型不知道
- 需要引用外部文档
- 需要“查 → 用 → 解释”
- 正确性比风格更重要
在这些场景里，RAG 的价值非常明确：
它改变的是“模型能看到什么”。
但春节祝福这种任务，恰恰不在这个集合里。
三、把 RAG 硬套进祝福生成，会发生什么
很多团队其实都会尝试一种直觉方案：
“我们是不是可以把‘好祝福语’放进知识库，
让模型参考着写？”
这听起来合理，但实际效果往往很快暴露问题。
1）RAG 解决不了“默认语气”
即使你检索到了一段非常好的祝福语，模型也不会自动学会：
- 什么时候该轻松
- 什么时候该克制
- 什么时候不该玩梗
它只会把检索结果，当成可用素材。
而素材 ≠ 偏好。
于是你会看到：
- 有时像在“拼贴”祝福
- 有时风格前后不一致
- 有时突然变回通用模型语气
这不是实现问题，而是机制问题。
RAG 拼贴式生成示意
2）RAG 会放大风格不一致的问题
春节祝福非常强调整体语气的一致性。
但 RAG 的天然行为是：
- 多段文本拼接
- 多来源风格混合
- TopK 召回本身就可能不一致
你会发现一个很常见的现象：
前两句很自然，
后一句突然变得像公文。
这不是模型“失误”，而是 RAG 的工作方式本来就不保证风格统一。
3）RAG 无法定义“什么是更值得被说的”
RAG 能告诉模型：
- 有哪些内容可以用
但它无法告诉模型：
- 哪些表达更值得被优先选出来
而春节祝福恰恰是一个“优先级问题”：
- 哪些细节值得被提
- 哪些词更自然
- 哪些表达更有“人味”
这些判断，不存在于任何文档中。
四、微调改变的是什么层面的东西
相比之下，微调做的是一件完全不同的事。
如果用一句话概括：
RAG 在扩展“可用信息空间”，
微调在重排“表达选择的概率分布”。
在春节祝福这个场景里，微调并没有教模型新知识，而是：
- 把“合适的表达方式”整体抬高概率
- 把“套话式、安全但疏离的表达”压低
- 让某种风格成为默认，而不是偶发
这正是强风格生成最需要的能力。
RAG vs 微调——作用层面对比
五、为什么“风格一致性”是关键分水岭
在强风格生成任务中，有一个指标比“内容对不对”更重要：
整体风格是否稳定。
春节祝福如果出现以下情况，用户感知会非常强烈：
- 前后语气不统一
- 情绪突然跳变
- 玩笑和正式混杂
而风格一致性，正是 RAG 最难保证、却是微调最容易做到的。
原因很简单：
- RAG 是“事后拼接”
- 微调是“事前塑形”
微调是在模型决定怎么说之前，就已经改变了它的倾向。
六、从「码上拜年」的选型，看一次真实的工程判断
回到具体案例。
在「码上拜年」这个项目中，技术选型并不是“先有微调，再找场景”，而是反过来的：
- 任务明确是表达型
- 不需要外部知识
- 用户输入高度结构化
- 风格一致性是第一优先级
在这样的前提下，RAG 的价值非常有限：
- 它解决不了默认语气问题
- 反而可能引入风格噪声
而微调的优势则非常集中：
- 数据可以严格控制风格
- LoRA 成本低、可快速验证
- 30 分钟就能看到明显体验差异
这不是“微调更高级”，而是更匹配任务本身。
七、可控性：工程上谁更容易“稳住”
从工程视角看，还有一个非常现实的问题：
哪个方案，更容易长期维护？
在祝福生成这种场景中：
- RAG 的可控性来自于“文档质量”
- 微调的可控性来自于“数据风格一致性”
而祝福这种内容：
- 不存在权威文档
- 很难定义“标准答案”
反而更适合：
- 用一小批高质量样本
- 明确告诉模型“什么是我们想要的表达”
从长期维护角度看，这比维护一个“祝福语知识库”要简单得多。
八、什么时候这个结论会反过来？
必须说清楚的是：这不是一个普适结论。
如果任务发生变化，比如：
- 祝福里必须引用最新政策
- 祝福需要根据企业公告自动生成
- 内容正确性高于情绪价值
那么 RAG 立刻会重新变得有价值。
这也是一个很重要的工程判断能力：
不是“我们更擅长用什么技术”，
而是“这个问题，到底缺的是什么”。
九、一个非常实用的判断问题（强烈建议）
在你面对“微调 vs RAG”的选择时，可以问自己一句话：
模型现在的问题，是
“没看到该看的东西”，
还是
“看到之后，还是不知道该怎么说”？
- 前者 → 优先考虑 RAG
- 后者 → 微调往往更直接
春节祝福这个场景，答案非常明显。
在「码上拜年」这样的强风格生成任务中，微调的价值在于快速验证“表达偏好是否真的被模型学会”。像LLaMA-Factory Online这样支持快速 LoRA 微调的平台，更适合用来做这种技术抉择：先跑通、先对比，再决定是否值得进一步投入，而不是一开始就押注复杂架构。
总结：技术选择，本质上是对问题的尊重
我用一句话收住全文：
微调还是 RAG，
不是技术信仰之争，
而是你是否真正理解了问题本身。
春节祝福这个案例之所以有价值，正是因为它足够具体，也足够“反直觉”：
- 模型并不缺知识
- 系统并不缺信息
- 缺的是一种稳定、默认、合适的表达方式
而微调，恰好擅长解决这一类问题。
