Appearance
Q34 · 有了超长上下文模型，还需要 RAG 吗？
客服要回答：“订单 A123 的耳机已拆封，签收 10 天后有杂音，能退吗？”公司政策库里有许多产品与历史版本。现在某些模型一次能接收很长的输入，开发者会想：把政策全部放进去，让模型自己找答案，是否就不必建设检索系统？
有时可以直接读整份资料；资料规模、查询次数、权限与版本、证据定位要求变化时，RAG 仍有价值。“放得下”只说明接口接受这些文本，不保证模型每次都能找到、正确组合并引用所需条款。反过来，RAG 如果漏检关键例外，也可能不如给模型完整原文。长上下文与 RAG 是两种给模型提供资料的方式，也可以组合使用。Google 的长上下文指南明确提出直接提供相关资料的新可能，同时说明多处信息提取、费用和延迟仍需实测；Li 等人的 EMNLP 2024 研究在其评测设置下观察到长上下文平均效果更好、RAG 成本更低，并提出按问题选择路径。这个结果是特定模型与数据集上的实验，不能当成所有企业任务的固定排名。
术语与本文的计量方式
| 词或记号 | 直白解释 | A123 例子中的对应物 |
|---|---|---|
| 大语言模型 / LLM | 接收本次输入并生成回答的模型 | 阅读订单事实与售后政策后作答 |
| 上下文窗口 | 模型一次调用可处理的文本容量，由所用模型和接口约束 | 本次能放入多少政策、提问、指令和对话历史 |
| Token | 模型计量文本的单位；不能简单等同于汉字或词 | 用同一个计数器比较两条方案送入的文本量 |
| 长上下文 / LC | 使用可接收大量 Token 的模型或调用方式 | 将多份已授权政策一并送入模型 |
| RAG | Retrieval-Augmented Generation，检索增强生成：先找相关资料，再带着资料生成 | 先找 V2 的耳机售后条款，再作答 |
| 块 / 检索 / 召回 | 块是被索引的资料片段；检索找候选块；召回看目标证据是否被找到 | 找到无理由退货、质量检测与拆封例外 |
top-k | 最多取回前 k 个候选块；k 是数量，不是正确率 | 取回的几条政策片段 |
| 有效上下文 | 在实际问题上，模型能可靠利用的输入内容；需要用测试确认 | 三条相关政策是否都被正确使用 |
| 引用 | 答案指向可核对的具体资料位置 | 《耳机售后政策》V2 第 1、2、3 条 |
| 权限过滤 / 版本过滤 | 在资料进入模型前，按登录者权限与适用时间排除不该用的文档 | 只读 u7 可见、A123 适用的 V2 条款 |
| 上下文缓存 | 对重复使用的相同输入前缀复用处理结果的服务能力；规则、费用依供应商而定 | 多个咨询复用同一批稳定政策文本 |
上下文窗口类似一张可放很多纸的桌面，但桌子够大，不代表读者已经翻到正确一页。这个比喻只解释“容量与使用效果”两件事；模型并非人在翻纸，具体效果要用真实问题测试。Lost in the Middle 原论文发现其受测模型在多文档问答中，相关段落放在长输入中间时可能比放在开头或结尾更难被使用。它揭示一种风险，不能据此断言今天每个长上下文模型都有同样幅度的问题。Google 的当前指南也提醒：单一事实的“针在草堆”测试表现，不能直接推断需要同时找多处信息的任务表现。
让两条方案面对同一笔订单与同一组政策
下面所有日期和规则都是虚构教学数据。假设今天是 2026 年 9 月 20 日，已认证用户 u7 有权查看 A123；订单服务核实耳机于 2026 年 9 月 10 日签收，所以已过 10 天；适用《耳机售后政策》V2，V2 从 2026 年 9 月 1 日生效。这里按签收日计算，不把下单日当成起点。V2 的三条相关规则为：
- 第 1 条：无理由退货。 签收后 7 天内且未拆封，可申请无理由退货。
- 第 2 条：质量问题。 签收后 30 天内出现非人为故障，可提交售后检测申请；是否退货或维修，以检测结果和订单信息为准。
- 第 3 条：拆封例外。 已拆封不适用无理由退货，但不因此失去申请质量问题售后的资格。
正确答复是：A123 超过 7 天且已拆封，不符合无理由退货条件；目前仍在 30 天检测申请窗口内，可以申请检测；“有杂音”是否属于非人为故障及最终处理方式，需要检测与订单核实，不能保证退款。这个结论在 Q28：文本切块和 Q31：RAG 接入 Agent里也用同一组假设；这里比较的是资料怎样进入模型。
再假设：应用已按登录者与生效版本筛出 20 份可用的 V2 文档，用同一个 Token 计数器测得合计约 48,000 Token；其中完整的耳机政策约 2,400 Token，与本问题直接相关的三条证据连同标题约 600 Token。这些只是便于对比的教学数，不代表任何模型或真实商城的文档长度。若所选模型本次调用的可用输入空间足够装下 48,000 Token，再给提问、指令、历史和回答留足预算，两个方案在容量上都能执行。
路径一：把已筛选的文档直接放入长上下文
程序先查订单，确认 u7 对 A123 有权限，并确定 V2。然后按权限与版本把 20 份可用文档放进模型输入，保留每份文档的标题、版本和章节。模型收到问题后，在这批资料里寻找“耳机、无理由、质量问题、拆封”的对应条款，再根据第 1、2、3 条回答并附引用。如果它把三条都找对并正确使用，这是一条完全有效的实现路径，不必为了使用 RAG 而额外搭建向量索引。
它适合资料集本来就小、一次需要通读整份长文、问题常跨很多章节，或检索器尚不能稳定找齐证据的场景。长上下文还能保留原文顺序与完整结构，对需要整体对照的任务可能有帮助。Li 等人的对比研究报告在其公开问答数据和模型上、资源充足时长上下文平均优于其比较的 RAG 配置；另一项后续评测进一步指出不同问题类型与检索方法会改变比较结果。选择应以自己的资料和问法为准。
代价与风险也要落到本例：每次为了找约 600 Token 的相关条款而送入约 48,000 Token 文档，可能增加输入成本和首字延迟；同一批政策被频繁提问时，应测上下文缓存能否降低重复成本，而非假设一定没有优化空间。Google 的长上下文指南明确讨论了缓存、多处信息提取和长输入的延迟。即使所有文档都能放下，也要测试模型会不会漏看第 3 条、把“可申请检测”写成“可直接退款”、或引用了别的产品规则。引用并非长上下文做不到：只要输入保留可定位的章节和来源，模型可以生成引用，程序还应校验引用是否真实存在。
图只比较送入模型前的资料选择方式。上排的厚文档代表已完成权限与版本过滤的资料，不代表把全公司的私有和历史文档无条件塞进去；下排的三张纸是检索出的证据，不代表 RAG 一定能找齐。两条路最终都要按 V2 原文核对回答。图中“模型阅读窗口”是示意界面，并非某个真实产品的固定窗口大小。
路径二：先检索相关证据，再交给模型
另一条路径仍先查订单、做同样的 u7 权限和 V2 版本过滤。政策在问答之前被切成带有标题、章节和来源位置的块，并建立索引。运行时程序把问题转成检索词，例如“耳机无理由退货的签收期限、拆封条件”和“耳机质量问题检测的期限与拆封例外”，检索器返回第 1、2、3 条。应用把约 600 Token 的相关证据与订单事实放进模型输入，模型再作答并引用条款。政策更新时要更新索引、失效旧块；RAG 不会因为叫“实时检索”就自动保证最新。Microsoft 的 RAG 说明描述了资料准备、索引、检索与生成，并指出检索质量、引用及权限是独立需要处理的环节。
这条路的优势是输入更聚焦，容易把文档数增长与单次模型输入长度分开处理；若政策库变成几万份，按用户和问题挑几条资料比每次传整个库更实际。返回的文档 ID、版本、章节和原文位置也方便审计。但索引、查询与可能的排序会增加系统维护和检索延迟，错误切块、错误查询或过小的 top-k 都可能漏掉第 3 条。模型若只收到第 1 条，根本没有足够资料判断质量问题售后；应补查或说明无法核实，不能拿一条政策推断所有售后资格。Microsoft 的同一说明也明确列出 RAG 的检索成本、延迟，以及不完整检索导致错误回答的风险。
两条路径的权限边界相同：无权文档不能进入模型输入。长上下文要在组装 20 份文档之前过滤；RAG 要在检索时限制可返回文档。不能把 V1、V2 都给模型后仅说一句“请选择正确版本”，也不能把无权资料检索出来后要求模型保密。模型不是权限系统；这个控制由应用和数据服务负责。Microsoft 的文档级访问控制文档说明了查询时按用户身份过滤结果的具体模式。
在本例里怎样组合两者
一个务实的方案是先按权限和版本检索，找到 V2 第 1、2、3 条；若问题只需判断本例资格，就交给模型这些完整条款。若检索只找到了第 1、2 条，而第 2 条引用了“例外说明”，程序可以沿着同一文档的章节关系补取第 3 条，或把完整的 2,400 Token 耳机政策放入长上下文重新核对。这样用检索缩小文档范围，同时用长上下文保留一份文档内的完整结构。决定补全文档的依据是“需要的证据还没齐”，不应只靠模型一句模糊的“我有信心”。
若完整耳机政策只有 2,400 Token，也可以直接按产品和版本找到这份文件并整份送给模型，不一定需要复杂的向量检索。这同样是一种先选择文档、再用长上下文阅读的组合；选择步骤可以是数据库字段过滤、关键词检索或 RAG 系统。真正要比较的是本任务是否需要对庞大资料库做内容检索、检索是否会漏证、整份阅读的成本和准确率如何，而不是争一个技术名字。
用同一批问题做选择
准备覆盖本例正常与边界的测试集：签收 3 天且未拆封、10 天且已拆封、30 天外、旧版订单、无权订单，以及答案同时依赖三处条款的问题。对每题记录期望证据和正确结论。至少比较三条基线：已授权资料全量长上下文、RAG 只给相关块、先检索再扩展完整文档。让它们使用同一模型、同一订单事实、相同的权限和版本规则，避免把安全过滤差异误判为模型优势。
观察两个层次：资料是否进入了模型（RAG 是否召回三条，长上下文是否正确组装了 V2）；模型是否正确使用资料（结论、例外、引用是否正确）。再记录输入 Token、检索和生成耗时、每题费用、更新政策后的可用时间。若长上下文准确且成本可接受，直接读整份资料就够；若资料多、查询频繁且 RAG 能稳定召回，先筛选通常更省输入；若 RAG 漏掉跨章节证据，补全文档或调整检索。研究论文的平均分只能给设计启发，不能替代这个业务评测。Lost in the Middle提醒检查证据位置影响；EMNLP 2024 的比较展示了准确率与成本可能互相牵制。
面试时怎样回答
可以这样说：“长上下文扩大了一次能交给模型的资料量，所以小而稳定的文档集，或者需要通读完整文档的任务，可以直接提供原文，不必机械地上 RAG。但窗口容量不等于每处证据都能稳定被使用；资料规模、重复输入的成本和延迟、权限与版本过滤、可追溯引用仍要考虑。RAG 先选相关证据，通常能缩短单次输入，也可能因切块或检索漏掉关键条件。我的做法是用同一批问题对比整份长上下文、RAG 和检索后扩展原文：分别量资料是否齐、答案是否正确有据，以及延迟费用。小资料可直接读；大而变化快的资料库通常保留检索；跨章节问题可先检索定位，再让长上下文读完整相关文档。”
如果追问“模型有百万 Token，还需要索引吗”，可以答：是否需要取决于资料库规模、授权范围、问题类型和成本；百万是容量量级，不能代替查询时筛选。若追问“RAG 一定比长上下文便宜吗”，可以答：单次输入通常更短，但要算建索引、检索和维护，也要把长上下文缓存、调用次数与供应商计费一起比较，不能只看输入长度。
资料
- Google AI for Developers：Long context：长上下文能力、缓存、延迟与多处信息提取限制。
- Nelson F. Liu 等，Lost in the Middle: How Language Models Use Long Contexts，TACL 2024：受测模型在长输入中使用不同位置证据的实验。
- Zhuowan Li 等，Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach，EMNLP Industry Track 2024：长上下文、RAG 与组合路径的比较；Xinze Li 等人的后续评测讨论问题类型与检索方法的差异。
- Microsoft Learn：RAG and indexes in Microsoft Foundry；Azure AI Search 文档级访问控制：资料准备、检索与权限过滤。