HaS论文调研

论文：HaS: Accelerating RAG through Homology-Aware Speculative Retrieval

版本：arXiv:2604.20452v1, 2026-04-22

1. 背景

HaS讨论的是RAG系统里的检索延迟问题。

很多LLM推理优化关注prefill、decode、KV cache和attention kernel，但在真实RAG系统里，检索本身也可能成为端到端延迟瓶颈。论文解析中提到，在一个600万条目的知识库上，常规检索平均耗时约0.62秒，已经超过裸LLM的TTFT。

Agentic RAG会进一步放大这个问题。复杂问题被拆成多个子查询，每个子查询都可能触发一次检索，所以检索延迟会随着推理轮数线性甚至更糟地累积。

2. 现有方法的问题

已有检索加速大致有两类：

1. ANNS方法，例如IVF、ScaNN。它们通过只搜索部分索引分区来降低延迟，但会牺牲召回和精度。
2. 结果复用方法，例如Proximity、SafeRadius、MinCache。它们缓存历史查询结果，如果新查询和旧查询足够相似，就直接复用结果。

结果复用的问题是，真实查询很少完全同义。两个查询可能围绕同一个实体，但问的是不同属性。例如一个查询问某个人的出生地，另一个查询问他的职业；它们不完全同义，但可能共享一批能够支持回答的文档。

HaS的核心观察就是：RAG查询不一定需要full homology，很多时候只要同源，也有机会复用或推测出足够好的候选文档。

3. 核心思想

HaS全称是Homology-Aware Speculative Retrieval，可以理解成“同源性感知的推测性检索”。

它借鉴了LLM speculative decoding的思路：先用一个便宜方法生成draft，如果验证通过，就跳过昂贵方法；如果验证失败，再fallback到完整检索。

在RAG检索里对应为：

1. 先用轻量通道快速构造候选文档draft。
2. 验证这个draft是否大概率包含回答当前查询所需的golden document。
3. 如果验证通过，直接使用draft，绕过全库检索。
4. 如果验证失败，再执行完整数据库检索。

这使HaS保持了一个重要性质：它不是无条件近似检索，而是带有验证和fallback路径的推测式加速。

4. Homology概念

论文区分了几个概念。

Golden document指能够支持查询事实性回答的文档。理想情况下，它需要满足：

1. 文档对应的实体和查询实体一致。
2. 文档覆盖查询需要的属性。

Full homology表示两个查询指向同一实体、同一属性，几乎可以看成语义等价。

HaS关注更宽松的homology：两个查询只要指向同一实体，就认为同源，属性可以不同。形式上可以理解为：

$$H(q_1, q_2) = \mathbb{I}\left[E(q_1) = E(q_2)\right]$$

这背后的经验假设是：同一实体相关的文档通常覆盖多个属性，检索器也有实体对齐偏好。因此，同源查询虽然不完全相同，但很可能共享部分golden document。

5. 方法

HaS由两个快速通道组成。

5.1 Cache Channel

Cache Channel保存历史查询的全库检索结果。

当新查询到来时，HaS不会直接复用某个历史查询的结果，而是用缓存结果作为候选知识空间，尝试判断当前查询是否和某个历史查询同源。

为了高效验证，HaS维护文档到历史查询的倒排索引：draft里的每个文档都可以反查它曾经出现在哪些缓存查询的结果中。

然后用检索结果重叠来计算同源性分数：

$$s(q_1, q_2) = \frac{|D_1 \cap D_2|}{k}$$

如果某个缓存查询的重叠分数超过阈值$\tau$，就认为当前draft可信。

5.2 Fuzzy Channel

只靠Cache Channel有两个问题：

1. 缓存覆盖有限，可能缺少当前查询所需的细粒度属性文档。
2. 当相关文档不足k个时，top-k结果会被噪声文档填充，导致错误重叠分数偏高。

Fuzzy Channel使用更激进的ANNS配置，只检索很少的分区，例如从8192个分区里只取64个。它不追求完整召回，而是作为便宜的补充信号。

Cache Channel提供历史知识覆盖，Fuzzy Channel补充当前查询附近的模糊候选，两者合并后再进行竞争重排和验证。

6. 实验结果

论文解析中给出的主实验使用Qwen3-8B和增广数据集，核心指标是平均延迟AvgL和回答准确率RA。

在Granola-EQ和PopQA上：

1. HaS相对Full-Database检索分别降低约23.74%和36.99%的延迟。
2. 精度下降约1%左右，明显小于多数简单复用方法。
3. 使用LLM验证的CRAG虽然能做更强判断，但验证开销太大，端到端延迟反而上升。

HaS还能和ANNS组合：

1. 在IVF基础上继续降低约15%到29%的延迟。
2. 在ScaNN基础上继续降低约8%到18%的延迟。

这说明HaS不是ANNS的替代品，而是可以叠在ANNS前面的推测式bypass机制。

7. Agentic RAG

HaS在Agentic RAG场景里的收益更明显。

原因是多跳问题会产生多个相关子查询，这些子查询常常围绕相同实体或相邻实体展开，同源性模式更频繁。论文解析中提到，接入Auto-RAG处理2-hop复杂查询时，平均检索延迟降低约69.4%，精度下降约3.72%。

这说明HaS最适合“查询之间存在实体聚集”的工作负载，而不是完全随机、互不相关的检索请求。

8. 局限

HaS依赖实体中心假设。对于实体边界不清晰、开放式、抽象推理类查询，同源性可能难以可靠识别。

它也依赖历史查询缓存。如果系统冷启动，或者查询分布非常分散，Cache Channel提供的信息有限，draft接受率会下降。

Fuzzy Channel虽然可以压缩到只加载全库索引的一小部分，但仍然需要维护额外索引和验证逻辑。对于极低延迟系统，这部分工程复杂度需要权衡。

9. 总结

HaS的贡献是把RAG检索加速从“复用相同查询”扩展到“利用同源查询做推测检索”。

它的流程可以概括为：

1. 用Cache Channel从历史全库检索结果里找到可能同源的知识。
2. 用Fuzzy Channel快速补充当前查询附近的候选文档。
3. 通过检索结果重叠估计同源性分数。
4. 验证通过则跳过全库检索，验证失败则fallback。

一句话概括：HaS利用真实RAG查询围绕实体聚集的特点，把同一实体相关查询当成可验证的推测机会，从而在基本保持精度的同时降低检索延迟。