这是 2026 年做过几轮项目后,业内基本形成的共识。但凡你想让一个通用大模型「答对你自己的事」——公司的产品文档、内部规章、某个客户的历史订单——你大概率会在三条路里纠结:RAG(检索增强)、微调、长上下文(直接把材料塞进 prompt)。

这三条路经常被拿来对比,但很多对比都在装中立,列个表说「各有优劣,看场景」。这篇不装。它们不是平级的选项,它们解决的根本不是同一个问题。选错那条,代价不是「效果差一点」,而是要么每个月烧掉本不该烧的钱,要么半年后你的数据全过期、整个系统没人敢碰。

它们到底各自在解决什么

把这件事想清楚,后面就不纠结了。

• RAG:模型不知道答案,你临时把答案找出来递给它。模型本身不变,变的是每次喂给它的上下文。
• 微调:你改的是模型本身的权重。让它换一种说话方式、固定输出某种格式、养成某种行为习惯。
• 长上下文:你不做检索、不做训练,直接把所有相关材料一次性塞进 prompt,让模型自己在里面找。

注意区别:RAG 和长上下文都是在「给模型补知识」,区别只是补的方式——一个精挑细选地补,一个一股脑全塞。而微调压根不是在补知识,它在补能力和行为。这是最常见的认知错位:有人想让模型「记住公司有 300 条规章」,跑去微调,结果训完发现模型还是答不准,因为微调不是用来塞事实的。

一句话记牢:知识用 RAG,行为用微调,长上下文是知识量小到不值得搭管道时的偷懒办法。

RAG:知识会变、要溯源,就选它

RAG 是 2026 年绝大多数团队的默认起点,理由很硬:它便宜、上线快,而且能干那件最常见的事——让模型回答关于你自家数据的问题。

它的真正杀手锏是另外两个:

知识能随时更新。 产品改了价、规章出了新版,你只要更新向量库里那几条,模型下一秒就用新的了。不用重训、不用重新部署。对任何一个数据会变的业务,这一条几乎是决定性的。

答案能溯源。 模型说「退款政策是 7 天」,你能指着它后面挂的那条文档说「依据在这」。金融、医疗、法律这类场景,「答得对」还不够,你得能证明它为什么这么答。微调和长上下文都给不了这种可追溯性——微调把知识熬进了权重里,你根本说不清它从哪学的。

但 RAG 不是免费午餐,2026 年的现实是:当 RAG 出错,73% 的锅在检索,不在生成。 模型没胡说,是你压根没把对的文档捞给它。所以现代 RAG 早就不是「embedding + 余弦相似度」那么简单了,一条能上生产的管道长这样:

flowchart LR
  A[文档] --> B[语义切块]
  B --> C[向量库]
  D[用户提问] --> E[混合检索
向量 + BM25]
  C --> E
  E --> F[Rerank
取 Top 5-10]
  F --> G[LLM 生成]

几个关键点,踩过坑的都懂:

• 切块是默默崩掉 RAG 的地方。 切得太碎,一个 chunk 答不全一个问题;切得太大,塞进去全是噪音。语义切块(按 embedding 相似度找话题边界)比固定字数切块靠谱得多。
• 混合检索基本是标配了。 纯语义检索会漏掉「精确匹配」——比如某个型号编号、某个专有名词。把向量检索和 BM25(关键词)拼起来,准确率明显更稳。
• Rerank 是那勺秘制酱。 先用混合检索捞 100 条候选,再用一个 cross-encoder 重排序模型(Cohere Rerank、BGE-Reranker 这类)精筛出 5-10 条真正喂给大模型。这一步加上,系统会从「有时有用」变成「能上生产」。

代价是:你得维护一整套数据管道——切块、embedding、向量库、rerank,每一环都能出问题。RAG 上线快,但养着它不轻松。

微调:改的是行为,不是知识

如果你的痛点是这些,那才轮到微调:

• 模型语气不对——你要它像个严谨的客服,它偏要活泼。
• 输出格式不稳——你要它每次都吐严格的 JSON,它三次里有一次加段废话。
• 某种固定行为——特定领域的术语习惯、固定的处理流程、某类问题的标准应对。

这些 RAG 救不了。 你没法靠「检索」让模型改性格。微调改的是模型权重本身,它学的是「怎么说」「按什么格式说」「遇到这类输入该怎么反应」,不是「记住哪些事实」。

2026 年微调内部其实分三种,选哪种取决于你要改多深:

LoRA / QLoRA 是 2026 年的事实默认。 LoRA 只训练总参数量的 0.1%–1%,却能拿回全量微调 90%–95% 的效果。QLoRA 再加上 4-bit 量化,显存需求砍掉约 75%——一张 A100 80GB,大概 6 小时、十几美元,就能在 5 万条样本上微调完一个 8B 模型。这个成本低到,微调不再是大厂专属了。

全量微调 2026 年反而成了少数派选择。除非你的改动深到 LoRA 那层适配器装不下,而且你手里有海量高质量数据,否则没必要——花十倍的钱,换那 5%–10% 的边际效果,多数时候不划算。

DPO 已经基本取代了传统 RLHF 来做对齐。它更便宜、更稳定,效果相当。典型用法是「微调之后的精修」:先用 LoRA 把基本能力训出来,再用 DPO 拿成对偏好数据校一遍「这种答法好、那种不好」。

微调最反直觉的一条:数据质量碾压数据数量。1000 条手工精挑的样本,经常打得过 10 万条带噪声的。 学习率给个参考——普通 LoRA/QLoRA 从 2e-4 起步,DPO 这类强化学习类的要小得多,5e-6 左右。

微调真正的代价不在训练那几个小时,在之后:基座模型升级了,你的适配器要不要跟着重训?业务行为变了,数据要重新标、模型要重新跑。微调是一笔持续的维护承诺,不是训完就完事。

长上下文:知识量不大时,最省事的那条

2026 年的上下文窗口已经大得有点离谱了:

• Gemini 3 Pro 标准 1M–2M token,实验档摸到了 10M。
• GPT-5.2 支持到 400K。
• Claude Sonnet 4 给到 tier 4 的组织开了 1M beta(标准档 200K)。
• Llama 4 Scout 标称 10M。

窗口大到这份上,一个很自然的想法冒出来:还要 RAG 干嘛?把所有文档一股脑塞进去不就完了?

知识量真的小,这招确实成立。你只有一份 50 页的产品手册,与其搭一整套切块、向量库、rerank 的管道,不如直接把整份手册塞进 prompt。零维护、零基建,模型还能看到全局上下文,不会因为「检索只捞了相关那几段」而丢掉跨章节的关联。原型阶段,长上下文几乎永远是最快的验证方式。

但它有两个绕不过去的硬伤:

第一,标称窗口 ≠ 可用窗口。 这是最大的误区。一个模型标 200K,不代表它在 200K 上还好用。RULER 这类基准反复验证:模型的有效容量通常只有标称值的 60%–70%。还有那个老问题「迷失在中间」(lost in the middle)——材料放在 prompt 开头和结尾时模型找得最准,夹在中间 10%–50% 深度的内容,准确率明显塌方。2026 年各家表现也不一样:Claude Sonnet 4 在 200K 全程的衰减能压在 5% 以内,GPT-5.2 在 256K 内保持接近满分的检索,而 Gemini 3 Pro 一过 128K 在多目标检索上就掉得挺快。你塞进 1M token,别真指望它每个角落都看得清。

第二,贵。而且是规模化之后致命地贵。 你每问一个问题,那一大坨上下文就要重新算一遍 token 钱。在规模上,长上下文比 RAG 或微调贵 20–24 倍。更糟的是计费门槛:OpenAI 超过 272K token 之后单价翻倍,Gemini 超过 200K 翻倍。原型阶段长上下文很香,生产高并发场景它会把你账单点着。

所以长上下文的定位很清楚:知识量小、又不想搭基建,就用它;一旦知识量大起来、或者要扛量,老老实实回去做 RAG。

别再二选一了:2026 年是分层

把这三条路当成单选题,是最常见的错。

2026 年那些真正做出好产品的团队,没有谁在「选一个」。他们在分层叠加:RAG 负责事实,微调负责风格、策略和决策行为。 一个典型的成熟架构是——一个不算大的基座模型,挂一层薄薄的 LoRA 适配器把语气和格式调到位,再配一套 RAG 管道实时喂事实。微调和检索不是互相替代,是各管一段。

落地的推进顺序也有共识,别跳步:

Prompt → RAG → 微调 → 蒸馏

先把 prompt 写好,不行再上 RAG,RAG 解决了知识、但行为还不对再上微调,最后量大到一定程度、想把成本压到底,才考虑蒸馏成小模型。绝大多数团队走到第二步就够了,根本不需要碰微调。

成本上还有一条值得记:低并发场景 RAG 赢,因为没有前期训练投入;高并发场景(每天 10 万+ 次查询)微调过的小模型赢,因为单次推理便宜。 量,是决定天平往哪边倒的关键变量。

一张图替你决策

不想读上面那一大堆,看这张图就够了:

flowchart TD
  Start[你想让模型答对自己的事] --> Q1{需要补充的是
知识还是行为?}
  Q1 -->|行为/风格/格式| FT[微调
默认 LoRA/QLoRA
再用 DPO 精修]
  Q1 -->|知识| Q2{知识量大不大?
会不会变?}
  Q2 -->|量小 + 基本不变| LC[长上下文
直接塞进 prompt]
  Q2 -->|量大 / 会变 / 要溯源| RAG[RAG
混合检索 + Rerank]
  FT --> Hybrid[多数生产系统:
RAG 管事实 + 微调管行为]
  RAG --> Hybrid
  LC -.量涨上来.-> RAG

最后留一句话,这是这篇唯一想让你记住的:先问自己「我缺的是知识还是行为」。 想清楚这一个问题,三条路自己就排好队了。剩下的纠结,多半是因为这个问题没问清。

参考资料:

• LLM Context Window 2026 — TokenMix
• Context Length Comparison: Leading AI Models in 2026 — elvex
• Fine Tuning AI Models in 2026 — Kumar Gauraw
• LLM Fine-Tuning Best Practices 2026 — hjLabs
• RAG vs Fine-Tuning for LLMs (2026): What Actually Works in Production — DEV
• RAG vs Fine-tuning vs Long Context — Preksha Dewoolkar, Medium
• Building Production RAG: Architecture, Chunking, Evaluation & Monitoring (2026) — PremAI
• RULER: Benchmark for Long-Context Modeling

但你有没有验证过——它引用的那段需求,是真的从文档第 40 万字的位置取出来的,还是它顺着上下文的语气编了一段听起来很对的话?

这是 2026 年长上下文最尴尬的地方:“放得进"是确定的,“用得好"是不确定的,而大多数人只测了前者。 模型厂商标 1M、2M,你看到的是窗口大小;你真正需要的是这个窗口里有多少 token 是"模型会认真看"的。这两个数字,差得比你想的大。

标称上下文 vs 有效上下文

先把两个概念分清楚。

标称上下文(advertised context)是模型 API 允许你塞进去的最大 token 数,超了就报错。有效上下文(effective context)是模型在性能开始明显掉档之前,真正能可靠利用的 token 数。

RULER 这个 benchmark 当年就是为了量化这件事造出来的。它的结论很扎心:很多号称 32K+ 的模型,在 32K 长度下能维持及格表现的,只有一半。到了 2026 年,百万级窗口普及之后,这个差距并没有消失——多份独立测试给出的经验值是,有效上下文通常只有标称值的 60%~70%,而且性能下滑的方式,简单的 token 计数根本看不出来:漏检的内容、编造的细节、断掉的推理链。

把 2026 年几个主流模型的标称窗口和实测召回放在一起看:

注意 Gemini 1.5 Pro 这一行:它标 2M,是表里窗口最大的,但 1M 长度下的召回反而排在后面。窗口大小和有效质量,不是同一个排行榜。 标称 10M 的 Llama 4 Scout 也一样,过了 1M 之后衰减得很明显,适合做的是"检索式"任务,不是"全局理解"任务。

所以下次看到发布会上"业界最长 2M 上下文"的字样,你心里应该自动换算:能放 2M,能用好的可能就 1.2M 上下。剩下那 80 万 token,是放进去给你心理安慰的。

Lost in the middle:模型其实在"跳读”

为什么有效上下文会缩水?最经典的一个原因叫 lost in the middle。

2023 年那篇同名论文做了个很干净的实验:把同一条关键信息(needle)放在长文档的不同位置,看模型能不能答对。结果画出来是一条 U 形曲线——信息放在开头或结尾,模型答得很好;放在中间,准确率断崖式下跌。

说人话就是:模型读长文档的方式,和一个赶时间的人翻书很像——认真看了前言和结论,中间几百页基本是扫过去的。

这背后是注意力的问题。有研究把它归因为"注意力稀释”:context 越长,softmax 要把有限的注意力权重摊到越多的 token 上,每个 token 分到的"关注"就越薄。再叠加位置编码带来的偏置,中间段就成了被冷落的区域。有些极端的测量甚至说,某些前沿模型的有效注意力区间,比标称窗口短了高达 99%。

要补充一句公平话:这事在 2026 年比 2023 年好了不少。 像 Gemini 2.5 Flash 这种,做简单的事实型问答(needle-in-a-haystack)时,不管 needle 放在哪个位置,基本都能答对——简单检索上的 lost in the middle 已经被很大程度上修掉了。

但别高兴太早。needle 测试本身有个大问题:它太简单了。最近的研究(《Lost in the Haystack》)发现,needle 越小、越像"一行字",越好找;一旦你要找的"目标内容"本身是一大段、需要跨段落拼起来的,定位难度立刻上去。 真实业务里,你要模型做的从来不是"找一句话",而是"把分散在第 3、19、56 章的三处约束综合起来判断"。这种多跳、聚合类的任务,才是中间段塌方的重灾区。needle 测试绿灯,不代表你的任务绿灯。

成本和延迟:长上下文是按复利收费的

就算质量没问题,还有一笔账要算:钱和时间。

标准 self-attention 是 O(n²) 的。这个 n 是 token 数,平方意味着——prompt 翻一倍,attention 的计算量翻四倍。把 1M token 喂进一个标准 Transformer,光 attention 就是 1M × 1M 量级的矩阵运算,接近一万亿次操作。这笔账不是线性涨的,是带复利的。

最直接的体感是 TTFT(首 token 延迟)。模型要先把你的整个 prompt “读"一遍(prefill 阶段),才能吐第一个字。prefill 的耗时随上下文长度加速增长:从 4K 涨到 32K 你可能没什么感觉,从 32K 涨到 128K 就开始难受,而按观测到的幂律曲线(指数约 1.24)外推到 1M,第一个字出来可能要等 60~90 秒。

flowchart LR
  A[4K prompt
TTFT ~1s] --> B[32K prompt
TTFT 数秒]
  B --> C[128K prompt
TTFT 十几秒]
  C --> D[1M prompt
TTFT 60-90s]
  style C fill:#fde7c2,stroke:#e8b23c
  style D fill:#f5b7b1,stroke:#c0392b

对任何交互式产品,这都是致命的。我之前写语音 Agent 的延迟预算时讲过,用户回应超过 800ms 就觉得别扭——你拿一个 prefill 要等一分钟的长上下文方案去做对话,等于直接出局。长上下文是离线批处理的工具,不是实时对话的工具。

钱也一样。虽然到 2026 年部分厂商(比如 Anthropic 的 Opus 4.6 / Sonnet 4.6)取消了长上下文的 2 倍溢价,1M 窗口按标准价 GA,但每次调用你都为整个 prompt 的所有 token 付费。一个 80 万 token 的上下文,你每问一句,这 80 万 token 就重新计一次费。一天问一百次,就是八千万 input token。多轮对话场景下,这个数字会失控。

更隐蔽的是 GPU 内存。多百万 token 的输入,KV cache 能吃掉 80%~90% 的显存。这意味着同样的硬件,长上下文请求能并发的数量大幅下降,单位成本进一步被推高——这部分不一定体现在 API 标价里,但会体现在你自建推理时的账单上。

什么任务真的需要超长上下文

讲了这么多问题,不是说长上下文没用。是说它被滥用了。

很多人把长上下文当成 RAG 的"平替”——“既然能塞进去,我干嘛还搭检索系统”。这个判断在大多数场景是错的。把无关内容大量塞进 context,不只是浪费钱,还会主动加重注意力稀释,把真正相关的那几千 token 淹掉。给模型的信息越精准,它表现越好;喂得越多越杂,反而越差。

那什么任务是长上下文真正不可替代的?我的判断是,符合下面特征的:

• 需要全局视野,且无法预先切片检索。 比如让模型审一份 60 万字的合同,找出所有相互矛盾的条款。你没法提前知道哪两条会冲突,RAG 切片检索这时候帮不上忙——它本质上是个 N×N 的全局比对。
• 跨度大、上下文强耦合的代码理解。 让模型理解一个几十万行的代码库的某个改动会牵连到哪里。调用关系是网状的,切片会切断它。
• 长链多跳推理。 一份侦探小说式的材料,线索分散在几十处,需要全部在场才能推出结论。检索 top-k 很容易漏掉那个"看起来不相关但其实是关键"的片段。
• 多模态长素材。 一段两小时的视频、一本带大量图表的书,本身就是一个不可切分的整体。

发现规律没有?这些都是"信息之间有强关联、无法干净切分“的任务。反过来,如果你的任务是"从一堆文档里找出和问题相关的那部分再回答”——那是检索任务,老老实实用 RAG,又快又便宜又准。长上下文和 RAG 不是谁取代谁,是分工:能切就检索,不能切才全塞。

怎么实测一个模型的长上下文质量

最后给点能落地的。别信发布会,自己测。一个最小可行的验证流程:

flowchart TD
  A[用你自己的真实长文档] --> B[在不同深度埋入可验证事实]
  B --> C[深度: 10% / 30% / 50% / 70% / 90%]
  C --> D[长度档: 32K / 128K / 256K / 1M]
  D --> E[每格跑多次取准确率]
  E --> F[画热力图: 深度 x 长度]
  F --> G{中间段是否塌方?}
  G -->|是| H[砍到有效长度内使用]
  G -->|否| I[再上多跳/聚合任务复测]

几个关键点:

第一,用你自己的文档,别用公开 benchmark 的语料。 主流模型很可能在训练时见过 RULER、LongBench 这些数据,刷分会虚高。拿你业务里真实的合同、文档、代码去埋点,测出来的才作数。

第二,测两类任务,别只测 needle。 needle 检索(找一句话)和多跳聚合(综合好几处信息推结论)要分开测。前者现在大多数模型都能过,后者才是真正区分模型的地方。只测 needle 你会得到一个过于乐观的结论。

第三,把"深度 × 长度"做成热力图。 横轴是上下文总长度,纵轴是关键信息埋入的相对位置(10%、30%、50%、70%、90%)。每个格子跑十几次取准确率。这张图一画出来,模型在哪个长度档开始掉、中间段塌不塌,一目了然。你的"有效上下文"就是这张图上还保持绿色的那个区间。

第四,把延迟和成本一起记进表。 不只记准不准,把每个长度档的 TTFT 和单次调用费用也记下来。很多时候你会发现,128K 档的质量和 1M 档差不了几个百分点,但延迟和成本差了一个数量级——那 1M 就没有用的必要。

我的总结很简单:百万级上下文是个真实的能力,但它的有效区间,要靠你自己量出来,而不是读厂商的标称值。 把整本书塞进去之前,先问自己两件事——这个任务真的不能切片吗?我验证过模型在这个长度下中间段不塌方吗?这两个问题答不上来,那个 1M 窗口,大概率只是个让你安心的数字。

参考资料:

• RULER: What’s the Real Context Size of Your Long-Context Language Models?
• Lost in the Middle: How Language Models Use Long Contexts
• Lost in the Haystack: Smaller Needles are More Difficult for LLMs to Find
• 1M Token Context Reality Check 2026: Gemini vs Claude Latency
• Long-Context Inference at Scale: The Hidden Infrastructure Cost
• The Prefill Bottleneck Problem