长上下文 LLM vs RAG：长文档问答怎么选（2026 版）

引言：「1M context」让 RAG 成了争议话题

2026 年的立项会上，这个争论几乎每场都有：客户拍着桌子说”模型都支持 1M token 了，把 500 页合同直接塞进去就行，搞什么知识库”；RAG 工程师回怼”塞得下不等于找得到，你们上次演示翻车不就是因为这个”。

两边都有道理，也都不完整。长上下文和 RAG 不是替代关系，是成本、延迟、可靠性三个维度上的不同解法——选哪个取决于文档长度、调用频率、任务是否需要全局视角。这篇文章给一套可以直接带进立项会的决策框架：长上下文的三个硬约束、NIAH 与真实精度的落差、整篇塞入 vs RAG 的量化对比、四步选型决策树，以及生产环境真正在用的三层混合架构。

---

一、长上下文的三个硬约束

1.1 注意力衰减：「塞得下」≠「找得到」

“Lost in the Middle” 效应是长上下文最核心的工程风险：同一个问题，答案放在文档开头或结尾时模型答得对，放在中间时答错的概率显著上升。这不是某个模型训练没练好——transformer 的注意力权重在长序列上天然向首尾倾斜，位置在中间的信息获得的注意力质量系统性偏低。2026 年的主流长上下文模型（128K-1M）都有改善，但只收窄了降幅，没有消除现象。

关键认知：NIAH 测试会系统性高估长上下文的真实能力。

测试场景	理想化程度	典型精度
大海捞针（NIAH）：随机编码、唯一答案、纯噪声干草堆	极高	90-100%
合成多跳问答：答案跨 2-3 段、需简单推理	中	70-85%
真实业务文档 QA：噪声表格/脚注、相似条款、模糊指代	低	60-80%
真实业务文档 + 多文档交叉推理	最低	50-70%

厂商宣传页上的 NIAH 100%，到真实合同库、病历库、代码库里要打个七折甚至五折。所以选型时 NIAH 分数只能用来”排除最差的”，不能用来”保证生产精度”——必须用自己业务的真实文档建金标集做回归（50-100 条，每条标注标准答案 + 答案位置）。

工程上缓解位置偏差的三个手段：

1. 三明治结构：系统提示放最前、用户最新问题放最后，检索内容放中间；
2. RAG 注入排序：重排序后最相关的 chunk 放上下文首尾位置，别全部堆在正中间；
3. 关键事实预提取：金额、日期、条款号、实体名这些”必须 100% 找对”的信息，用程序或轻量模型预提取成结构化字段，不依赖模型从 10 万字里翻。

1.2 成本：平方级计算 + 线性计费

长上下文的成本问题有两层：

第一层，推理成本。 attention 计算随序列长度近似平方增长，prefill 阶段（处理输入）的耗时和算力消耗随输入长度快速上升。塞 10 万 token 输入的 prefill 成本远高于塞 2 万——不只是 token 数 5 倍的线性关系。

第二层，token 计费。 云端 API 按 token 计费，输入也计费。这里给一笔可复算的账（以主流云端模型输入价约 ¥0.004/1K token 量级估算）：

方案	单次输入	单次输入成本	月调用 1 万次	月成本
整篇塞入（10 万字 ≈ 80K token）	80K token	≈ ¥0.32	8 亿 token	≈ ¥3,200
RAG 检索注入（top-10 chunk ≈ 2 万字 ≈ 16K token）	16K token	≈ ¥0.064	1.6 亿 token	≈ ¥640
混合（锚点 2K + 检索 16K）	18K token	≈ ¥0.072	1.8 亿 token	≈ ¥720

差距是 5-10 倍量级，而且调用频率越高差距越大——月调用 1 万次和 100 万次的场景，整篇塞入和 RAG 的月成本差从几千块拉到几十万。低频场景（内部工具、单次报告生成）这个差距可以忽略，高频场景（客服、在线问答）这个差距就是项目生死线。

私有化部署同理：长输入吃 prefill 算力，直接压缩并发上限。同样一张卡，8K 输入的 QPS 可以是 100K 输入的 5-10 倍。

1.3 延迟：TTFT 被 prefill 吃掉

首字延迟（TTFT）= prefill 耗时 + 网络开销。输入 100K token 时 prefill 是秒级到十秒级（取决于硬件和模型），用户感知是”点了发送半天没反应”。在线交互场景（客服、助手）通常要求 TTFT < 3 秒，这条线一画，10 万字整篇塞入直接出局；离线场景（批量报告、夜间批处理）延迟不敏感，长上下文才是合理选择。

---

二、整篇塞入 vs RAG：量化对比

把三个硬约束摊开，两个方案的完整画像：

维度	整篇塞入	纯 RAG	混合（RAG + 长上下文精读）
全局信息（跨章节推理）	✅ 天然完整	❌ top-k 之外看不见	⚠️ 靠锚点层补
检索精度（长文档）	⚠️ 受 lost in the middle 影响	✅ 召回可控	✅ 最好
单次成本	❌ 随文档长度线性涨	✅ 固定（top-k 大小）	✅ 低且可控
TTFT	❌ 随长度恶化	✅ 快	✅ 快
信息完整性（chunk 截断风险）	✅ 无截断	❌ 答案跨 chunk 时易断	✅ chunk 保原文整段
建设成本	✅ 零（不用建管线）	❌ embedding 管线 + 索引 + 调优	⚠️ 中
文档更新	✅ 直接用新文件	❌ 需重建索引	⚠️ 锚点层需重生成
可审计性（答案出处）	⚠️ 要模型自己报页码	✅ chunk 自带来源	✅ 来源精确
适用文档规模	≤ 10 万字	10 万字 - GB 级	1-100 万字

三个结论：

1. 整篇塞入不是”土办法”，小规模下它是正确答案。 文档 < 10 万字、月调用 < 1 千次、任务需要全局视角——建 RAG 管线的花钱（工程 + 运维 + 效果调优）大概率超过 token 账单的差距。RAG 的价值是规模化的，不是普适的。
2. 纯 RAG 的两个死穴：跨 chunk 的长段落答案会被截断（top-5 × 500 字喂不进去完整推理），以及全局类问题（“这份合同里有哪些违约金条款？“）top-k 根本召回不全。
3. 混合架构是 2026 年生产环境的主流形态：用 RAG 解决”找得到”，用长上下文解决”读得完”——检索后保留原文整段（2-4K 字/块）塞给模型精读，而不是截成单句。

---

三、选型决策树

四步走，带进立项会直接用：

Q1: 文档长度占模型上下文窗口多少？
├─ ≤ 30%
│   Q2: 任务需要全局视角吗（整份审查/跨章节一致性/全文改写）？
│   ├─ 是 → 【整篇塞入】，完事
│   └─ 否 → 仍可整篇塞入（短文档检索没有收益），但建议加结构化预提取
├─ 30% - 100%（中间地带）
│   Q3: 月调用量？
│   ├─ < 1 千次（低频/离线）→ 【整篇塞入】，token 账单可接受，省掉 RAG 运维
│   └─ ≥ 1 千次（高频/在线）→ 【混合架构】，RAG 召回 + 长上下文精读
└─ > 100%（超出窗口）
    【必须 RAG】，且考虑混合架构（检索命中后整段注入）

一句话口诀：短文档塞全文，长文档必检索，中间地带算调用量。

决策树之外还有两个一票否决项：

• 合规一票否决：数据不能出私有化环境 → 长上下文的窗口受本地卡显存限制（7B-70B 模型实际可用 32K-128K），超窗口就 RAG；
• 更新频率一票否决：文档每天变（新闻、工单、日志）→ 整篇塞入每次都要重读全文，RAG 增量更新索引的成本优势明显。

---

四、生产级三层上下文架构

中间地带和高频场景的最终形态：锚点层 + 检索层 + 明细层。三层各管一件事，缺任何一层都会翻车。

4.1 锚点层：给模型一张地图

文档预处理时生成结构化摘要，常驻上下文：

# 锚点层示例（合同文档）
doc_id: contract-2026-0142
title: 《XX 项目技术开发合同》
outline:
  - 第1章 项目范围（第1-3页）
  - 第2章 交付与验收（第4-6页）
  - 第3章 价款与支付（第7-9页）
  - 第4章 违约责任（第10-12页）
key_facts:
  合同金额: 860 万元
  违约金: 合同金额 20%
  验收期限: 交付后 30 日
  付款节点: 30% / 40% / 30%
entities:
  甲方: XX 科技有限公司
  乙方: XX 软件股份有限公司

要点：

• 锚点层只在文档变更时重生成，成本一次性均摊，每次问答只多 1-2K token；
• key_facts 是预提取的结构化事实，“金额/日期/违约金”这类必须 100% 准确的字段不靠模型现场翻；
• 过期锚点比没有锚点更害人——文档改版后锚点没更新，模型会基于过期地图检索，答案错得理直气壮。文档变更必须触发锚点重生成。

4.2 检索层：混合检索 + 重排序

用户 query 进来后：

1. 锚点定位：先用 query 匹配锚点的 outline/key_facts，把候选范围从全文缩到 2-3 个章节（粗排，成本极低）；
2. 混合检索：对候选章节原文做 向量检索 + BM25 关键词检索，各取 top-10 合并去重。法律/财务/技术文档里，精确词（条款号 “4.2.1”、金额 “860 万”、合同名）是向量检索的盲区——语义相近的文本向量距离近，但”4.2.1 条”和”违约金”的向量距离很远，必须 BM25 兜住；
3. 重排序：用 cross-encoder reranker 对合并后的 20 个候选精排，取 top-8~12。

生产参数（按文档规模调）：

参数	推荐值	说明
向量召回 top-k	10	宁多勿少，交给 reranker 筛
BM25 召回 top-k	10	关键词精确匹配
合并后 rerank	top-8 ~ 12	注入上下文的最终数量
相似度阈值	cosine ≥ 0.75 才注入	低于阈值宁可不注入（配合拒答）

混合 + rerank 相对纯向量 top-5 的召回率提升通常在 15-30%，是 RAG 效果调优里性价比最高的一步（比换更好的 embedding 模型便宜得多）。

4.3 明细层：整段注入，别截断

命中的 chunk 注入上下文时：

• 每个 chunk 保留原文整段（2-4K 字），不截成单句、不压缩成摘要——模型需要段落内的完整逻辑链才能做推理，“第 4.2.1 条约定违约金为合同金额 20%，但 4.3 条约定不可抗力除外”这种跨句的限定关系，截成单句就废了；
• 重排序后的最相关 chunk 放上下文首尾，缓解 lost in the middle；
• 每个 chunk 带来源标注（文档名 + 章节 + 页码/行号），回答要求引用来源，可审计；
• 注入总预算控制在上下文窗口的 50-70%，留空间给系统提示、锚点层和生成。

4.4 三层架构的完整调用链

用户 query
  → ① 锚点定位（候选章节粗筛，~0 成本，查本地 YAML/DB）
  → ② 混合检索（向量 + BM25 各 top-10）
  → ③ rerank（top-8~12，cross-encoder ~50-100ms）
  → ④ 组装上下文：系统提示 → 锚点层 → 命中 chunk（最相关放首尾）→ 用户问题
  → ⑤ LLM 生成（要求引用 chunk 来源编号）
  → ⑥ 校验：引用编号必须落在本次注入的 chunk 里（防幻觉引用）

整条检索链（①-③）在 200ms 内，延迟大头仍在 LLM 生成——混合架构的 TTFT 和纯 RAG 一个量级，远好于整篇塞入。

---

五、成本账：一笔能复算的账

以”企业合同库问答”场景复算（1000 份合同，平均 8 万字，月调用 2 万次，在线场景）：

项	整篇塞入（80K token）	混合架构（锚点 1.5K + 检索 16K）
单次输入 token	80K	17.5K
单次输入成本（¥0.004/1K）	¥0.32	¥0.07
月输入成本	¥6,400	¥1,400
月生成成本（输出 500 token/次）	¥400	¥400
月总 token 成本	¥6,800	¥1,800
RAG 管线一次性建设	0	约 2-4 周工程
RAG 管线月运维（embedding API + reranker）	0	约 ¥200-500
年总成本	¥81,600	¥46,800 + 一次性建设

结论：

• 月调用 2 万次级别，混合架构年省 ¥3.5 万+，3-4 个月回本管线建设成本；
• 月调用 500 次级别，token 账单差距只有 ¥250/月，别建 RAG——整篇塞入 + 结构化预提取足够；
• 私有化部署把 token 成本换成算力占用：同样一张推理卡，17.5K 输入比 80K 输入多支撑 4-5 倍并发，扩容费也是钱——这笔账要算进成本对比。

---

六、上线前自检表

#	检查项	通过标准
1	文档规模盘点	每篇文档 token 数实测（不是估算），标注占上下文窗口比例
2	任务视角分类	全局类 / 检索类 / 混合类，三类占比清楚
3	金标集	真实业务文档 50-100 条，标注标准答案 + 位置，覆盖三类任务
4	基线对比	整篇塞入 vs RAG vs 混合，三方案在金标集上精度实测（不是看 NIAH）
5	成本复算	按真实月调用量算三方案年成本，含私有化算力口径
6	TTFT 实测	在线场景 P95 TTFT < 3s（含检索链）
7	位置结构	系统提示在最前、用户问题在最后、最相关 chunk 在首尾
8	检索混合	向量 + BM25 双路召回 + rerank，纯向量 top-5 视为不合格
9	chunk 完整性	注入 chunk 保留原文整段（2-4K 字），无单句截断
10	来源可审计	每个 chunk 带文档 + 章节 + 位置标注，回答引用编号受程序校验
11	拒答兜底	相似度低于阈值时拒答（“知识库中未找到”），不硬答
12	索引一致性	文档变更触发重建（锚点 + 向量 + BM25 索引三者同步）

---

长上下文让 RAG 变了，但没让它消失

2023 年大家争论的是”要不要 RAG”，2026 年争论的是”RAG 怎么和长上下文配合”。长上下文模型带来的最大变化不是”取代检索”，而是抬高了检索的精度上限——以前 RAG 只能用 top-5 × 500 字（窗口小，塞不下更多），现在可以检索 top-12 × 2K 字整段注入，模型读得完、读得懂。RAG 管”找得到”，长上下文管”读得完”，锚点层管”看得全”——三者拼起来才是生产级的长文档问答。

我们交付的合同问答、病历问答、代码库问答项目，全部采用这套三层架构，金标集精度稳定在 85% 以上（纯向量 top-5 朴素 RAG 的基线通常在 65-70%）。如果你正在做长文档 AI 项目、被”塞得下还是检索”卡住，或者已经上了朴素 RAG 但精度不达标，欢迎带着你的文档和金标集来聊——先帮做一次精度归因（检索层丢的 vs 生成层丢的），再谈架构调整。

---

延伸阅读：

• 企业私有知识库 RAG 落地实战 — RAG 完整落地管线与切分/嵌入参数
• RAG 知识库权限管理实战 — 多租户下 RAG 的权限隔离
• LLM 模型选型与路由实战 — 长上下文能力差异与路由策略
• LLM 成本管理实战 — token 账单到单位经济学
• 向量数据库选型指南 — 检索层的向量库选型

需要长文档问答方案、RAG 精度调优或私有化部署评估？联系我们 获取免费评估。