REFRAG：Make RAG Great Again

Meta 超级智能实验室（Superintelligence Labs）招了那么多牛人，第一篇论文有点出人意料——他们选择先来优化一下我们已经很熟悉的 RAG（检索增强生成）。

最近 RAG 风评不佳，速度慢，检索精度不高，尤其是现在 Agent 势头正猛，很多人都觉得 RAG 已死，而 REFRAG 则给人以“Make RAG Great Again”的感觉。

先看数据：
- 首次生成延迟（Time-to-First-Token）缩短了整整 30.85 倍（远超之前最先进方法 3.75 倍）
- 能够处理的上下文长度增加了 16 倍
- 在16项主流RAG任务上，全面超越 LLaMA 等之前的明星模型。
- token 使用数量降低了2-4倍，意味着算力消耗更低。
- 在摘要、多轮对话、检索问答等场景下，没有任何精度损失。

我本来以为技术很高深，但学习了一下发现原理我也能懂。看完不得不感叹：有时候你以为理所当然的事，结果牛人就是能提出一个更好的方案，让你一拍大腿：“原来还能这样。”

传统的 RAG 方案很多人已经不陌生了：
预处理：文本分块 -> 向量化(Embedding) -> 存向量数据库（通常还会存 Meta 信息，方便找到原始文本和位置）
检索：用户输入 -> 向量化 -> 向量数据库检索 -> 返回 Top-K 相关文本
生成：将 Top-K 相关文本和用户输入一起拼接成 Prompt -> LLM 生成 -> 返回结果

这样做，确实能解决不少问题，但也存在一些问题：
- 绝大部分检索出来的内容其实和用户的问题并不相关。
- LLM 被迫要处理大量无用的文本。
- 计算成本高，速度慢，延迟长，上下文空间还被浪费了。

那么 REFRAG 是怎么优化的呢？

它的做法很巧妙，就是检索的时候，返回的结果不是文本块，而是文本块的向量，只有少量重要的文本块的向量会返回原始的文本内容，其他的文本块只返回向量。这样既节约了上下文空间，也让 LLM 能够专注于处理重要的文本。

这可能有点不好理解，来打个比方：
> 我们有一个百科全书，我们把每一页纸生成一张缩略图（向量），然后把这些缩略图和对应的百科全书页码存到数据库里。现在用户来问问题，我们先把用户的问题也生成一张缩略图，然后在数据库里找出和用户问题缩略图最相似的前 K 张缩略图。假设我们找到了 10 张缩略图，其中有 2 张是非常相关的，我们就把这 2 张缩略图对应的百科全书页码和内容都返回给 LLM，其他 8 张只返回缩略图和页码，不返回内容。这样 LLM 就能专注于处理这 2 页重要内容，而不是被其他 8 页无关内容干扰。而且内容少了，上下文不容易被占满，而且有其他内容的缩略图也可以帮助更好的理解上下文，必要的话还可以二次请求获取更多详细信息。

就好比过去我们逼着模型“看整本书”。而现在让模型先“看缩略图墙”，只在关键处“点开原文”。

这就解决了三个痛点：
- 首字节很慢 → 少传大量 token，更快开始说话。
- 显存/KV 压力大 → 输入更短，占用更小，同卡跑更多并发。
- 吞吐不稳 → 注意力计算随 token 增长很快；压成向量后，每次算得更轻。

在哪些场景有用呢？

- 客服问答、知识搜索、长文总结、垂直智能体：资料多但不需要句句逐字引用。
- 多轮对话/很长上下文：能把中间那些“参考资料”大部分用缩略图带着走。

但可能不适合的场景：
- 严格引用/逐字精确（法律、医学、合同条款等）：需要更高“点开原文”的预算，甚至干脆多给 token。
- 知识库更新很频繁：要有快速重算向量的管线，否则可能“新知识不新”。比如像代码库，还不如用 Greg 更简单方便。
- 团队工程能力有限：要训练/对齐“缩略图制作器”和“点开什么”的策略，落地不等于即插即用。

其实这还有一个启发，也许以后模型内部的通信，真的不需要用人类的语言了。模型之间可以直接交换“向量”+“元信息”，而不是“文本”，这样效率会更高。

论文链接：http://t.cn/AXPY7k6t http://t.cn/AXzEcjEP