长上下文与 RAG：何时通读，何时先检索

根据机器转写整理，未经原音、画面或独立实验核对。以下是讲者提出的选型思路，实际模型能力和任务效果需要验证。

容量与资料选择是两个问题

长上下文窗口决定一次请求可以容纳多少输入与输出；RAG 则是在回答前先找出相关资料，再把证据交给模型。它们可以组合使用：先从大量资料中筛选，再让模型阅读较完整的文档或较长片段。

如果资料范围明确、总体能放入窗口，而且任务需要通读和比较，直接提供完整材料可能省去切片、建索引与召回步骤。检索切片可能只找回规则而漏掉例外；整体阅读有机会让模型同时看到两者，但并不保证模型一定理解正确。

什么时候先检索更合适

讲者用持续更新的企业资料举例：资料总量可能超过窗口，不同用户的访问范围也不同，单次问题往往只涉及某产品或版本。系统可以先按当前用户权限和业务条件过滤，再用关键词与语义检索找候选、按需重排，最后把有关资料送给模型。检索没有找到必要证据时，扩大模型窗口也无法补回缺失的资料。

请求发生时查资料有助于获取当前版本，但前提是数据源及索引也及时维护；不能把使用 RAG 等同于答案一定最新。权限应在资料进入模型上下文之前由系统执行，不能依赖模型自行忽略无权内容。

比较两种方案的实际代价

一次性输入大量资料可能增加 Token 成本和等待时间；重复上下文缓存又可能改变成本关系，因此应按真实请求频次、模型计费和缓存行为比较。讲者提到长内容中间的信息有时更难被利用，这是一类需要在目标模型和任务上验证的现象，不能推断所有模型都一样。

试验时可分别比较证据覆盖、条件与例外是否保留、答案能否回查、权限过滤、延迟和费用。先判断任务是否需要检索，再判断使用数据库查询、搜索引擎、业务接口、向量检索或其他方式；向量数据库只是可选实现之一。