RAG 与 REFRAG 的对比

RAG vs REFRAG

在 RAG 方案中，我们检索到的大部分内容其实对 LLM 并没有真正的帮助。

正如之前讨论过的，在经典的 RAG 中，当一条查询到来时：

• 把它编码成一个向量。
• 从向量数据库（vector DB）中取出相似的分块（chunk）。
• 把检索到的上下文一股脑地塞给 LLM。

这种做法通常是有效的，但代价高昂：

• 大部分分块都包含不相关的文本。
• LLM 需要处理多得多的 token。
• 你要为算力、延迟和上下文（context）付出代价。

这正是 Meta AI 的新方法 REFRAG 所要解决的问题。

它从根本上重新思考了「检索」这件事，下图说明了它的工作原理。

本质上，REFRAG 不再把每一个分块、每一个 token 都喂给 LLM，而是在向量层面对上下文进行压缩和过滤：

• 分块压缩（Chunk compression）：每个分块都被编码成一个单一的压缩嵌入（embedding），而不是成百上千个 token 级别的嵌入。
• 相关性策略（Relevance policy）：一个轻量级的、经过 RL 训练的策略模型会对这些压缩嵌入进行评估，只保留最相关的分块。
• 选择性展开（Selective expansion）：只有被 RL 策略选中的分块，才会被还原成完整的嵌入，并传给 LLM。

这样一来，模型只处理真正重要的内容，其余的则被忽略。

下面是逐步的详细说明：

第 1-2 步）对文档进行编码，并将其存入向量数据库。

第 3-5 步）对完整的用户查询进行编码，并找到相关的分块；同时计算查询（第 7 步）和匹配分块各自的 token 级别嵌入。

第 6 步）使用一个（经 RL 训练的）相关性策略来挑选需要保留的分块。

第 8 步）将输入查询的 token 级别表示，与所选分块的 token 级别嵌入、以及被淘汰分块的压缩单向量表示拼接（concatenate）在一起。

第 9-10 步）把这一切都发送给 LLM。

正是这一步 RL，让 REFRAG 成为一套更懂得判断「相关性」的 RAG 流程。

根据相关研究论文，这种方法：

• 首 token 生成时间（time-to-first-token）快 30.85 倍（比此前的 SOTA 快 3.75 倍）
• 上下文窗口（context window）扩大了 16 倍
• 在 16 个 RAG 基准测试上超越了 LLaMA，同时使用的解码器 token 数量减少了 2–4 倍。
• 在 RAG、摘要以及多轮对话任务上都没有精度损失

这意味着，你可以在保持相同精度的前提下，以 30 倍的速度处理多达 16 倍的上下文。