RAG vs 微调 vs 长上下文：2026 年的成本交叉点

2024 年的默认答案是“一律用 RAG”。2026 年算账变了。24 个月里廉价档 LLM API 价格大约跌了10 倍。上下文窗口达到了 1M 到 2M token。微调成熟而且更便宜了。架构决策不再是“要不要 RAG”，而是三路交叉点。这篇文章列出截至 2026 年中各方案胜出的地方，并给出一个你可以把自己数据代入的具体成本例子。

工程视角，不是厂商推销。参考点来自 Wavect 的 AI 工作，包括 PromptID、Twinsoft AI 和 Quivr。

2024 到 2026 之间变了什么？

三个结构性变化：

• Token 价格崩塌。中端模型输入价格从 2024 年大约每 1M 输入 token EUR 2.50，跌到 2026 年竞争档低于 EUR 0.30。输出价格也跟着跌。
• 上下文窗口变大。1M 输入上下文如今是中端标配，2M 可用。Prompt 缓存把同一上下文在会话中重复读取的有效成本降低 80% 到 90%。
• 微调成熟。LoRA 适配器和 7B 到 30B 区间的小型开源权重模型，让领域适配变便宜。出于数据驻留考虑在欧盟基础设施上自托管，对许多 SaaS 团队现在经济可行。

含义：2024 年的决策树错了。代入 2026 年价格重跑，交叉点已经移了。

2026 年长上下文什么时候打败 RAG？

长上下文胜出的场景：语料能装进 prompt，且工作负载是临时性的：

• 语料文本小于约 10 MB（约 2M token），能塞进一次前沿模型 prompt。
• 临时或低频查询，检索工程开销摊销不下来。
• 跨文档推理重要、切块会破坏上下文的任务。
• prompt 缓存命中率高的会话（在同一份文档集上的多轮助手）。

陷阱：长上下文成本在每次查询上都随语料大小线性扩展，除非缓存生效。在每月 10 万次查询下，开缓存与不开缓存的差别就是“盈利功能”和“毛利灾难”的差别。

微调什么时候打败两者？

微调在三种特征下胜出：

• 风格或人设。你需要模型一致地像你的品牌或遵循精确格式。prompt 工程收益递减，微调能把它固定下来。
• 领域行话。词汇专业（法律、医疗、小众工业），基础模型把你的术语当作多义。微调能重新对齐 embedding。
• 延迟敏感的窄任务。单工作负载上微调的 7B 模型，在成本和延迟上都打败 70B 模型，质量常常可比。

陷阱：微调把数据烤进模型。如果你的知识每天更新，微调到周三就过期。变化的部分请与 RAG 结合。

RAG 还在什么时候胜出？

下列情况 RAG 仍然是对的选择：

• 大或不断更新的语料。超过约 10 MB 相关文本，或日/周刷新，算账偏向检索。
• 引用要求。合规、法律、医疗，或任何需要用户看到答案出处的产品。
• 多租户数据隔离。每位客户有自己的语料且不能交叉污染。RAG 按租户干净分离，长上下文和微调不行。
• 稀疏检索模式。大多数查询只触及语料的一小部分。把整个语料塞进上下文是浪费 token。

常见语料规模下，每次查询成本的交叉点长什么样？

2026 年中、欧盟部署、中端模型代表价（EUR 0.30 每 1M 输入，EUR 1.20 每 1M 输出）、输出 1k token 的示意每查询成本。数字四舍五入便于阅读；请把你厂商的精确价格代入自己的模型。

交叉解读：在 10 MB 以下且缓存命中率高时，长上下文经济上站得住。10 MB 以上，只有 RAG 能保持成本形状。有意思的中间地带是 1 到 10 MB，正确答案更取决于查询模式而不是语料大小。

一个具体的欧盟部署长什么样？

实例：100 MB 技术文档语料、每月 10,000 次查询、有欧盟驻留要求、每次回答都要引用：

1. 架构。RAG + 欧盟托管的向量库 + 欧盟 API 端点的 LLM 提供商，或在欧盟基础设施上自托管开源权重模型。
2. 每次查询成本。检索（约 3k token 输入 + 1k 输出）在 2026 年中端价格下接近 EUR 0.0024 每查询。10k 查询/月，LLM 成本约 每月 EUR 24。
3. 另加基础设施。向量库、embedding 刷新、可观测性、评测脚手架。此规模下现实基础设施区间 每月 EUR 200 到 800。
4. 另加研发。初始实现含数据摄入、评测脚手架、引用 UI、监控，来自 Wavect 在类似范围的项目历史，落在 4 到 10 周区间。

同样工作负载下，长上下文连塞都塞不下。同样工作负载下，微调，你要牺牲引用，且新鲜数据仍需要一条独立检索路径，最后变成 RAG 加微调，而不是替代。

"架构决策跟着价格曲线走，不跟着炒作曲线走。2024 年对的模型，到 2026 年就是错的，即使别的什么都没变。"

混合架构呢？

在生产中，最干净的答案通常是混合：

• RAG 加微调。检索处理变化的语料；微调处理语气、格式和领域词汇。这是我们在品牌声音重要的面向客户的助手中默认拿出来的方案。
• RAG 加长上下文。先检索一个更宽的候选集合，然后让长上下文窗口做跨文档推理。在法律评审和综合任务里有用。
• 小模型加路由器。一个小型快速模型对查询分类并路由到正确后端（RAG、微调或前沿模型）。我们的经验是能砍 3 到 5 倍成本。

对 2026 年的欧盟创始人这意味着什么？

三条来自现场的运营规则：

1. 架构会议之前先跑成本模型。把你真实的查询量、真实的语料大小、真实的厂商价格代入上面的表。正确架构是从数字里出来的，不是从大会演讲里。
2. 不管哪种架构，先把评测脚手架建好。没有评测，你说不清哪种架构真的赢。我们在 agent 那篇文章里写过，这里加倍适用。
3. 每六个月重跑一次分析。token 价格和上下文窗口比你架构评审节奏更快。2025 年的默认到 2027 年就是错的默认。