当所有上下文都重要：RAG失灵之后，他为什么选择“扩展缓存生成”

如果我告诉你：在某些场景下，向量检索和知识图谱都不是最优解，你会信吗？Luis Romero-Sevilla 在这场演讲中抛出一个反直觉结论——当“所有文档都相关、而且还在高速变化”时，真正的突破点不在检索，而在上下文本身。

最反直觉的前提：不是“找不到”，而是“全都重要”

大多数 RAG 方案默认一个前提：在一堆文档里，总有一小部分最相关。但 Luis 一上来就否定了这个假设。

他描述的场景非常极端，也非常现实：一整批文档共同描述同一个事件或系统；用户的问题需要“全局视角”才能回答；更麻烦的是，这批文档更新极快，几乎是整批被替换。

在这种情况下，问题不再是“我能不能检索到相关内容”，而是——我根本无法丢掉任何内容。因为每一份文档，都是拼图的一角。

这也是整场演讲最重要的伏笔：当“筛选”本身就是错误动作时，传统 RAG 的思路，从根上就走歪了。

简单 RAG 的天花板：不是慢，而是逻辑不成立

Luis 并没有否定 RAG 的价值，反而非常冷静地把它拆开。

标准流程我们都很熟：Embedding → 向量数据库 → 相似度检索 → 丢给 LLM。优点也很明显：快、便宜、文档更新成本低。

但在他这个“所有文档都相关”的场景下，RAG 碰到了硬伤：

• 相似度阈值失效：因为问题本身是全局性的
• Top-K 检索失去意义：你根本不知道该丢掉哪一部分
• 把所有文档塞进上下文？——直接爆窗

他一句话点破问题本质：RAG 的优势在于压缩信息，但这里恰恰不能压缩。

这也是为什么，RAG 在这个场景下不是“效果不好”，而是“逻辑上不成立”。

GraphRAG 看起来很美，但更新成本让人崩溃

既然问题是“全局关系”，那自然会想到知识图谱。

GraphRAG 的思路很诱人：让 LLM 通读所有文档，抽实体、建关系，形成一个知识网络；用户提问时，在图中游走，综合所有节点给出答案。

Luis 也承认：如果你的数据相对稳定，GraphRAG 非常强。

但问题又来了——他的数据不是稳定的，而是“经常被整体替换”。

在这种情况下，GraphRAG 的最大痛点被无限放大：
- 每次更新都要重新跑 LLM 抽取
- 构建知识图谱的计算成本极高
- 延迟无法接受

结论很残酷：GraphRAG 解决了关系问题，却被更新频率拖死了。

真正的转折点：把“上下文”当成一等公民

接下来，Luis 给出了全场最有冲击力的方案。

他说：既然不管是 RAG 还是 GraphRAG，每份文档最终都要过一遍 LLM，那我为什么不——直接把文档放进上下文？

这就是 Cache Augmented Generation（CAG）：
- 使用超大上下文窗口模型
- 将一批文档直接加载进上下文
- 缓存模型的 KV Cache，复用“已读知识”

当然，单个上下文窗口还是有限的。于是他做了一个关键升级：

并行多个 CAG，把文档分散到多个“上下文桶”里。

每个桶都能独立回答与自身内容相关的问题；上层再用一个更聪明的“监督模型”，去询问不同桶、追问细节、最后综合答案。

一个看似反常识的设计也随之出现：文档不按领域分桶，而是随机分布。原因很简单——当文档关系极其密集时，领域标签反而会误导模型忽略“看起来不相关”的桶。

结果是：
- 所有缓存并行加载，速度极快
- 全局理解能力强于 RAG
- 更新成本远低于 GraphRAG

代价？KV Cache 很贵。但 Luis 的态度很清醒：这是一个用成本换“正确性”的选择。

总结

这场演讲真正打动人的地方，不是某个具体技巧，而是一个判断标准的转变：当你的问题需要“全局理解”，当你的数据变化快到无法精雕细琢索引结构时，继续执着于检索，本身就是一种路径依赖。

对 AI 从业者来说，Extended CAG 给了一个重要启发：上下文不只是输入限制，而是一种可以被架构化、被并行化的资源。下一次你发现 RAG 怎么调都不对，也许该问的不是“检索哪里出了问题”，而是——这个问题，真的适合被检索吗？

关键词： 检索增强生成， Cache Augmented Generation， 上下文窗口， GraphRAG， 大语言模型

事实核查备注： 需要核查：演讲者姓名 Luis Romero-Sevilla；其职务表述（VP of AI at Orbifold operation）；视频发布时间 2026-06-28；CAG 与 GraphRAG 的描述是否完全对应原视频表述