LoRA vs fine-tuning vs RAG:哪个解哪个问题

默认 LLM 不做你要的事时,你有三个真实选项:RAG(在 runtime 给它相关 context)、加例子的 prompt engineering(prompt 里更好指令)、或 fine-tuning(改模型权重)。LoRA 是 fine-tuning 的特定种类,比完整 fine-tuning 便宜很多。大部分团队在 RAG 才是对的答案时伸手 fine-tuning。大部分团队在 LoRA 已经够时伸手完整 fine-tuning。

三个方法概览

RAG(Retrieval-Augmented Generation) — runtime 捞相关文件、放 prompt 里、模型根据它们回答。模型本身不变。好给:知识问题、动态信息、引用来源。

Fine-tuning(完整或 LoRA) — 调模型权重让它行为不同。模型行为永久改变。好给:风格、格式、特定任务 pattern。

Prompt engineering — prompt 里更好指令跟例子。没权重改变、没检索。好给:大部分东西,意外地。

各解什么问题

「模型不知我公司产品」 → RAG。runtime 捞产品文件;模型用它们回答。

「模型用正式语言;我要轻松」 → 先 prompt engineering。「用轻松友好语气回应」大部分时候 work。Prompt-only 到不了再 fine-tune。

「模型不跟我精确 JSON schema」 → 先带例子的 prompt engineering。大部分现代模型 schema 指令做得好。需要 99% 可靠性而 prompt-only 给你 95% 才 fine-tune。

「模型不知专业医疗术语」 → RAG 配医疗来源。除非很大规模运作,fine-tuning 杀鸡用牛刀。

「模型对我们用途太慢」 → 较小模型 + fine-tune 让它在你具体任务上配对较大模型品质。这是真实 fine-tuning 用途。

「模型讲我们不要它讲的话」 → 先 prompt engineering 跟输出过滤。产品高量的话 fine-tune 内化品牌 voice 跟政策。

LoRA 是什么

LoRA(Low-Rank Adaptation)是 fine-tuning 技术,只更新少量参数,透过插入可训练「adapter」矩阵到模型。产生小文件(~10-100MB),套用时修改基底模型的行为。

比完整 fine-tuning 的优势:

• 训练便宜 10-100 倍
• 训练快很多(几小时 vs 几天)
• 较小 artifact(MB vs GB)
• 多个 LoRA 能在同基底模型上换进换出
• 较不可能灾难性忘记原能力

劣势:

• 略不如完整 fine-tuning 强大
• 需要基底模型可用(不能只 ship LoRA)
• 有时抓不到深行为改变

2026 年 90% fine-tuning 需求,LoRA 是对选择。

RAG 赢 fine-tuning 的时候

• 信息在你已有或能搜集的文件里
• 信息会变(时事、价格、政策随时间更新)
• 你需要引用 / 可验证性
• 你需要不重训加新信息
• 你没几千训练例子

RAG 也建得快(几天、不是几周)又较容易更新。

Fine-tuning 赢 RAG 的时候

• 你需要一致输出格式(永远严格 JSON、永远带这些 tag)
• 你需要 prompt 里难描述的特定风格或 voice
• 你需要从多例子内化隐性知识
• 延迟重要而加 RAG context 太慢
• 成本重要而系统 prompt + 捞到 chunk 每 query 太贵

经典 fine-tuning 用途:品牌的语气配对。「像 Apple 营销文案那样写」 — RAG 能供例子,但 fine-tuning 把风格烤进去。

你实际需要两者的时候

很多 production 系统两者都用。例子:为你品牌 voice fine-tune 的客服 agent + 对你 help docs 的 RAG。Fine-tuning 确保一致 voice;RAG 确保新鲜准确信息。

经典错误

团队听到「fine-tune」立刻想做。Fine-tuning 听起来技术又厉害。现实:

• 80% 尝试 fine-tuning 的团队本可用更好 prompt 跟 RAG 解决问题
• 15% 真的需要 fine-tuning 但该用 LoRA
• 5% 需要完整 fine-tuning

Fine-tune 前问:我真的耗尽 prompt engineering 了吗?我试过 RAG 吗?我有几百个高品质训练例子吗(没的话,你不能好好 fine-tune)?

成本实况

• RAG:建便宜(几天)。推论成本是 API + 检索(通常每 1k query $5 以下)。
• LoRA fine-tuning:一次性训练 run $100-1000。自架的话推论便宜很多。
• 完整 fine-tuning:有意义模型上每训练 run $5,000-50,000+。加服务基础设施。
• Prompt engineering:免费。

大部分产品,prompt engineering 然后 RAG 涵盖需求。Fine-tuning 留给替代品明显不够的证实场景。

什么时候不要用 fine-tuning

• 你没评估资料显示 prompt + RAG 不够
• 你有 500 个高品质例子以下(不够好好 fine-tune)
• 你要模型知的信息定期变
• 你没工程能力维护 fine-tune 模型
• 你 provider 6 个月内会发比你 fine-tune 还好的新基底模型

什么时候不要用 RAG

• 信息小到适合放 context(总共 < 10 万 token)
• 信息不变、能放系统 prompt
• 检索会加太多延迟
• 你实际需要模型改行为,不只是有新信息

决策树

• 新信息 / 动态数据:RAG
• 新风格 / 行为 / 格式:先 prompt engineering、需要的话 fine-tune
• 风格 + 特定格式 + 规模:LoRA fine-tuning
• 需要常更新知识库:RAG
• 高量产品的品牌 voice:LoRA fine-tuning + RAG 给事实
• 合规 / 特定术语:RAG 配策展来源

下一步

• 识别你实际问题:缺信息、错风格、不一致格式?
• 先试 prompt engineering;量到哪
• 信息问题,建基本 RAG;量改进
• 行为问题,只在 prompt + RAG 不够时 fine-tune
• Fine-tune 的话,从 LoRA 开始;只把完整 fine-tuning 当升级考虑