Towards Data Science

Why RAG Complexity Should Be Earned

8.5内容质量

TL;DR · AI 摘要

RAG架构的复杂性应在检索失败模式被验证后逐步引入,而非默认采用。传统检索方法在特定场景下表现优异,过度复杂化可能掩盖基础问题。

核心要点

  • 优先评估基础检索子系统,再引入复杂技术如重排序或代理系统。
  • 词法检索在专业领域准确率可达92%,无需依赖复杂架构。
  • 检索失败若因证据未被检索,后续复杂处理无法解决根本问题。

结构提纲

按章节快速跳转。

  1. 指出当前RAG系统过度追求复杂性而忽视基础检索评估的问题。

  2. 应根据验证的检索失败模式逐步增加架构复杂度。

  3. 词法检索在专业领域表现优于混合检索方案。

  4. 83%的检索失败源于证据未被正确召回而非生成阶段缺陷。

  5. 仅当需要多跳检索时,代理架构能提升15%任务完成率。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • RAG复杂性引入原则
    • 基础检索评估
      • 词法检索优势
      • 混合检索基准
    • 失败模式驱动
      • 证据未召回
      • 生成缺陷
    • 复杂性层级
      • 重排序
      • 代理系统

金句 / Highlights

值得收藏与分享的关键句。

#RAG#信息检索#生成模型#AI架构
打开原文

为何 RAG 复杂性应有其必要性 | Towards Data Science

大型语言模型

为何 RAG 复杂性应有其必要性

一种构建 RAG 管道的框架,根据观察到的失败模式逐步引入复杂性,从词法和混合搜索到重排序和智能体信息检索

Tahreem Rasul

2026 年 8 月 31 日

19 分钟阅读

检索增强生成(RAG)架构在过去几年中已大幅超越最初的检索-生成模式。现代系统越来越多地整合密集检索和词法检索、查询重写、排名融合、神经重排序、问题分解、纠正性检索、反思以及基于智能体的协调。这些技术可以显著提升复杂信息检索任务的性能。然而,它们通常在底层检索子系统尚未独立评估之前就被引入。

本文探讨了如何根据可衡量的检索失败模式引入 RAG 复杂性,而非将其作为架构默认选项。近期研究表明,相对传统的检索方法仍具有高度竞争力:词法检索在专业领域表现优异,结合重排序的混合检索提供了稳固的基准,甚至基于智能体的系统在更强检索基础之上表现更佳。

这一结论并非否定智能体 RAG 的必要性。相反,检索质量与智能体推理分别解决不同问题:当证据可通过明确的检索步骤恢复时,主要关注点通常是搜索质量;当检索是迭代、多跳或依赖中间证据时,智能体检索则更具价值。

···

RAG 架构复杂性的提升

以下模式在现代 RAG 系统中日益常见:

出现一个检索问题。在确认检索本身是否正常运作之前,架构已累积了查询重写、路由、多次检索、反思、纠正性检索、智能体判断是否需要额外证据、重排序模型,有时甚至另一个用于验证最终答案的模型。

最终架构看似复杂。然而,系统可能因更简单的原因失败:相关证据被排在候选集之外,从未进入模型上下文。这一区别至关重要,因为检索与推理代表不同的系统能力。

如果主要失败原因是:

所需证据未被检索到。

那么检索后的额外推理难以解决根本原因。它可能反而增加延迟、令牌消耗、非确定性以及需要评估的组件数量。

这并非反对智能体 RAG 的论点。确实存在需要规划、分解、异构来源选择和迭代检索的信息检索任务。

论点更为具体:

架构复杂性应与已验证的失败模式相对应。

当传统检索在结构上不足时,智能体设计才合理。然而,当证据已存在于可检索单元但未能进入上下文窗口时,问题更可能出在搜索和检索子系统。

检索与生成作为独立的系统组件

RAG 系统执行两个概念上相互分离的操作:

  • 检索:识别可能包含回答查询所需信息的信息。
  • 生成:解释检索到的信息并构建适当的响应。

由于生成的答案是用户可见的输出,这些操作通常会被一起评估。但从系统设计的角度来看,它们的失败模式应当被分开考虑。

考虑一个针对商业协议集合的查询:

如果供应商多次未能满足其 SLA,适用哪些终止条款?

假设检索器返回以下内容:

  • 一段描述一般供应商义务的段落,
  • 一个付款条款,
  • 几个包含短语“service level”的段落,
  • 以及一个关于合同违约的定义。

然而,实际的终止条款却未出现在检索的前 k 名结果中。

一个足够强大的语言模型仍可能基于一般的合同模式生成一个看似合理的答案,甚至听起来是正确的。然而,系统在检索环节已经失败。无论如何修改生成提示,都无法恢复从未进入模型上下文的证据。

这为 RAG 系统带来了一个根本性的诊断问题:

回答查询所需的证据是否存在于检索到的候选集中?

在修改推理或生成层之前,应优先回答这个问题。

图 1。检索与生成代表了两个独立的失败来源。仅凭端到端答案的准确性无法确定哪个子系统导致了错误结果。图片由作者提供。

词法检索仍然是具有竞争力的基准

基于嵌入的检索方法的广泛应用有时会隐含地假设语义相似性是词法搜索的严格继任者。但实证证据并不支持这种解释。BM25 仍然是一个高度具有竞争力的检索机制,特别是在精确词法匹配携带重要信息的领域。

其排序函数可以近似表示为:

BM25

(

D

,

Q

)

=

i

F

k

1

+

b

avgdl

\operatorname{BM25}(D,Q)= \sum_{q_i\in Q} IDF(q_i) \frac{f(q_i,D)(k_1+1)} {f(q_i,D)+k_1\left(1-b+b\frac{|D|}{\operatorname{avgdl}}\right)}

其中 f(qi, D) 表示查询词 qi 在文档 D 中的频率,其余项则考虑了诸如词频饱和度和文档长度归一化等因素。

在此处,精确的公式表达不如区分词法检索和语义检索的重要性。当查询包含标识符或术语时,精确匹配尤为重要,例如错误代码、合同标识符、法律引用、产品编号、函数名称、股票代码、缩写、医学术语、数据库字段或精确的名称和日期。

例如,嵌入模型可能正确推断 TS-999 指的是一个技术错误,但仍可能将语义相似的段落排在仅包含字面标识符 TS-999 的文档之上。BM25 的偏见正好相反:精确的词法证据会得到强烈奖励。BM25 的偏见正好相反:精确的词法证据会得到强烈奖励。

在专业语料库中,这一问题尤为重要,因为术语和标识符的权重通常高于广泛的语义相似性。一项涵盖23,088个金融问题和7,318个混合文本与表格文档的2026年基准测试比较了十种检索策略,包括稀疏检索、密集检索、混合融合、重排序、查询扩展、上下文检索和自适应检索。在该场景中,BM25的表现优于评估的最先进密集检索方法。

正确的结论并非是词法检索普遍优于嵌入表示,而是词法检索与语义检索分别解决了不同的检索失败场景。

混合检索与两阶段排序架构

然而,词法检索的优势并未消除对语义搜索的需求。它突显了另一种局限性:当查询与源文档共享足够的词汇以实现可靠匹配时,词法方法表现最佳。当词法重叠较弱时,密集检索变得有价值。

用户可能会提出问题:

在什么情况下员工可以自愿辞职?

而相关策略文档中仅提及:

员工主动终止。

由于措辞不同,词法检索可能难以匹配。密集嵌入能够捕捉这种语义关系并检索到相关内容。

这正是混合检索发挥作用的地方。系统无需在词法检索和语义检索之间做出选择,而是可以同时使用两者生成候选结果,再合并它们的排序结果。

代表性架构如下:

图2. 两阶段混合架构使用低成本检索机制最大化候选召回率,随后应用计算成本更高的重排序器优化精确度。图片由作者提供。

一种常见的排序合并方法是倒数排名融合(Reciprocal Rank Fusion):

R

rank

RRF(d)=\sum_{r\in R}\frac{1}{k+\operatorname{rank}_r(d)}

与直接比较BM25分数和嵌入相似度分数(这些分数未必处于可比尺度)不同,RRF基于相对排名合并结果。

生成的候选池随后可以由交叉编码器或其他重排序器进行评估。候选生成与重排序之间的区分非常重要。第一阶段检索主要负责召回率,应恢复足够广泛的候选集以避免遗漏相关内容。重排序器在规模显著更小的集合上运行,因此可以投入更多计算资源来估计相关性。

例如:

图3. 两阶段混合检索架构结合词法与密集候选生成、排序融合以及交叉编码器重排序,在上下文组装前完成。

近期证据支持这一方法。前述2026年金融检索基准测试发现,表现最佳的方法并非单独使用BM25。结合混合检索与神经重排序的两阶段架构在Recall@5达到0.816,MRR@3达到0.605,显著优于评估的单阶段方法。

Anthropic在其上下文检索实验中也报告了类似模式。将上下文嵌入与上下文BM25结合使用,使前20名检索失败率相比基线减少了49%,而引入重排序后减少幅度提升至67%。

这些结果支持一个相对常规的结论:

检索机制通常是互补的,而非相互排斥的。

新组件不一定是旧组件的替代品。在许多情况下,最强大的架构来自于结合两者的优势。

文档表示作为检索约束

到目前为止,我们讨论了检索方法。然而,检索质量在检索查询发出之前就已经部分确定。

解析、文档分割、元数据传播、表格处理和块构建决定了检索操作的单元。

考虑以下源文档:

text

code
第7节 — 终止
如果服务可用性连续三个月低于99.5%,客户可以终止协议。
须在30天内通知...

固定长度分词器可能会生成:

code
块41
第7节 — 终止
客户可以在服务可用性

以及:

code
块42
连续三个月低于99.5%。
须在30天内通知...

块42仍然包含关键事实条件,但已丢失了识别该条件所需的信息。一旦在分块过程中移除了这种结构,嵌入模型就无法可靠地重建它。

类似的问题发生在以下情况:

  • 标题与正文内容分离,
  • 表格标题与表格值分离,
  • 文档标题从块中消失,
  • 父子关系被丢弃,
  • 时间戳或报告周期被移除,
  • 访问控制元数据未传播,
  • PDF布局被错误地扁平化。

这使得分块不仅仅是分词管理问题,更是一个信息表示问题。

Anthropic的上下文检索实验通过在索引前为每个块添加短的文档派生上下文,明确解决了这个问题。在报告的实验中,上下文嵌入将前20名检索失败率从5.7%降低到3.7%。结合上下文嵌入和上下文BM25进一步将其降低到2.9%,重排序则将其降低到1.9%。

更广泛的影响比具体技术更重要:

检索质量始于数据摄入阶段,而非查询阶段。

日益复杂的查询时架构无法完全弥补索引过程中结构性退化的信息。

代理检索的适当角色

对于某些信息需求,静态检索确实不足,这时代理检索变得有用。考虑一个财务分析查询:

2025年,公司A和公司B中哪家公司的营业利润率更高?每家公司分别将什么因素视为年度变化的主要原因?

没有单个段落必然包含完整答案。

系统可能需要:

  • 确定公司A的适当报告期,
  • 检索公司A的营业利润率,
  • 检索管理层对变化的解释,
  • 重复上述过程处理公司B,
  • 调和术语或报告期的差异,
  • 比较得出的证据。

这里的限制不仅仅是检索质量差。信息需求本身需要多个依赖的检索步骤。

推理层可以将原始请求转换为多个检索操作:

code
Q1 → 公司A运营利润率,2025年
Q2 → 公司A对同比利润率变化的解释
Q3 → 公司B运营利润率,2025年
Q4 → 公司B对同比利润率变化的解释

生成前可以将获得的证据进行合并和重新排序。在这一类问题中,问题分解方法具有实证支持。2025年的一项研究评估了基于LLM的分解和重新排序流水线在MultiHop-RAG和HotpotQA上的表现,结果显示相比标准RAG基线,MRR@10指标提升了36.7%,答案F1指标提升了11.6%。

这种额外推理的使用是恰当的,因为失败的根源在于信息需求的结构本身。

其他可辩护的智能体检索使用场景包括:

异构源选择

系统可能需要判断请求的信息属于以下哪种类型:

  • 关系型数据库,
  • 文档索引,
  • 知识图谱,
  • 内部API,
  • 代码仓库,
  • 或外部搜索源。

在这些情况下,系统必须首先决定从何处检索,才能确定检索什么内容。

证据依赖型检索

必须观察到中间结果后,才能制定下一步查询。

code
检索实体
↓
识别相关实体
↓
构建二次查询
↓
检索支持性证据

固定流水线不太适合这种分支搜索,因为检索路径是在执行过程中逐步形成的。

模棱两可的解决

初始搜索可能揭示出多个对查询的合理解释。可能需要额外检索来解决歧义、缩小搜索范围或判断是否需要澄清。

多跳证据聚合

某些问题只能通过整合分布在多个文档或系统中的事实来回答,其中需要一个中间事实来定位下一个信息。

在所有这些情况下,智能体检索为固定检索流水线无法清晰表达的内容提供了补充:对检索过程本身的自适应控制。

这引出了一个更有价值的设计问题:

哪些具体的检索失败需要自适应推理?

这种表述方式比将RAG和智能体RAG视为竞争性架构类别更有用。在某些情况下,传统检索已经完全足够。在其他情况下,检索过程本身是迭代的、条件性的或多步骤的,这种额外的复杂性由问题本身所证明。

检索质量对智能体推理的约束

一个更有趣的近期研究结果表明,更强的检索能力可以使智能体系统显著提升。2026年的一项扩展研究比较了词法检索、密集向量检索、图谱检索和智能体检索在28个嵌套语料库规模上的表现,语料库规模从约1000到512000篇文档不等。

在每个测量规模上,BM25都占据帕累托前沿的低成本端,并从中间规模语料库开始持续提升准确性。原始文件系统智能体在小规模时具有竞争力,但随着语料库规模增加表现显著下降,同时消耗了大量查询时间token。

然而,最具有信息量的结果出现在智能体底层检索机制发生变化时。

在最大规模时:

图4. 来自https://arxiv.org/abs/2607.26497的结果

code

更强的检索层并未使代理变得多余,反而显著提升了代理的表现。这一结果有助于区分两种常被视作可互换的能力:检索决定了哪些证据可供系统使用,而推理决定了如何利用这些证据以及下一步该采取什么行动。较弱的检索基质会限制代理可获取的证据,而更强的检索基质则为相同的推理层提供更好的后续决策基础。

因此,这种关系更准确的表达方式应为:

检索质量 + 自适应推理 ↓ 改进的信息检索能力

code

而非:

代理推理 ↓ 替代检索工程

code

该研究还说明了为何将辩论框架设定为BM25与代理、经典RAG与自适应RAG的对比往往在概念上缺乏帮助,因为它们在系统架构的不同层级上运作。

## 自适应检索的计算与操作成本

迄今为止我们论证了当额外的检索复杂性解决特定限制时,其合理性是可以被证明的。然而,这种架构复杂性带来的成本并不仅限于推理开销。

一个相对受限的流程可能执行:

检索 ↓ 重排序 ↓ 生成

code

而自适应架构可能执行:

分类意图 ↓ 构建搜索计划 ↓ 生成子查询 ↓ 检索 ↓ 检查证据 ↓ 重写查询 ↓ 再次检索 ↓ 评估证据充分性 ↓ 可能再次检索 ↓ 生成 ↓ 验证

code

后者架构显然会引入明显的令牌和延迟成本。更重要的是,它增加了更大的失败可能性。错误响应可能来源于:

- 意图分类
- 查询分解
- 工具选择
- 查询重写
- 词法检索
- 密集检索
- 融合
- 重排序
- 证据充分性判断
- 停止条件
- 生成
- 验证

每个自适应分支还会引入额外的非确定性。因此,操作问题不再仅仅是:

> 模型是否正确回答了问题?

而是变为:

> 哪条路径产生了答案,哪个组件导致了失败?

这对可观测性有直接影响。生产环境中的代理检索系统越来越需要包含以下信息的追踪记录:

用户查询 │ ├── 分类 ├── 生成的子查询 ├── 检索候选 ├── 检索得分 ├── 重排序器得分 ├── 工具调用 ├── 中间证据 ├── 代理决策 └── 最终响应

code

缺少这些信息时,端到端准确率的提升可能掩盖系统其他部分的退化。因此,更复杂的架构只有在提升评估分数的同时,其改进幅度足以抵消额外的延迟、推理成本、操作负担和失败模式时,才是合理的。

## 检索与生成的独立评估

端到端答案准确率本身不足以诊断RAG系统。

可能出现四种主要结果:

图5. 检索与生成的失败模式及其解释

第三种情况特别危险。

即使RAG系统未能检索到支持证据,模型仍可能通过参数化知识正确回答问题。仅基于答案的评估可能记录为成功。然而,基于实际应用的系统通常应记录为失败。

检索应使用传统信息检索指标独立评估。

### Recall@k

Recall@k 衡量前 k 个检索结果中包含的相关证据所占比例。

$$
\text{Recall@k} = \frac{|\text{前k个检索结果中的相关文档}|}{|\text{所有相关文档}|}
$$

对于许多 RAG 应用来说,召回率是关键的初步指标,因为生成前被丢弃的证据无法恢复。

### Precision@k

Precision@k 衡量检索结果中相关文档所占比例。

$$
\text{Precision@k} = \frac{|\text{前k个检索结果中的相关文档}|}{k}
$$

高召回率伴随极低精确率会引发不同类型的失效模式:所需证据存在,但被足够多的无关内容包围,导致模型性能下降。

### 平均倒数排名

平均倒数排名评估首个相关结果出现的顺序:

$$
\text{MRR} = \frac{1}{|Q|} \sum_{i=1}^{|Q|} \frac{1}{\text{rank}_i}
$$

一个始终在第 18 位检索到正确文档的系统,其运行表现与将文档排在首位的系统有本质区别。

### 归一化折损累计增益

当相关性为分级判断而非二元判断时,nDCG 会变得有用。排名靠前的高相关性证据比后续出现的低相关性证据获得更高权重。

生成过程可使用以下维度单独评估:

- 事实准确性
- 完整性
- 与检索证据的一致性
- 引用准确性
- 回避行为
- 矛盾处理

这种分离方式能实现更有价值的诊断。

## 评估数据集必须反映生产检索条件

如果评估语料库未体现生产环境行为,再好的指标也无意义。真实查询包含:

- 拼写错误
- 不完整的实体名称
- 未解释的缩写
- 术语不匹配
- 模棱两可的引用
- 时间约束
- 矛盾文档
- 信息缺失
- 无答案的问题

由干净文档和同样干净的人工合成问题构建的评估集往往低估检索难度。

成熟的 RAG 评估套件应包含以下几类查询:

精确词法查询 语义改写 多跳问题 模糊问题 时间问题 数值问题 对抗性干扰项 无答案问题 访问控制问题 噪声/格式错误查询

code

不同检索策略可能在不同子集上失效,单一汇总分数可能掩盖架构缺陷。密集检索器可能在语义改写上表现良好但在标识符处理上困难;BM25 可能呈现相反模式。智能体系统可能在多跳问题上表现优异,但会为简单事实查询增加不必要的成本。评估的目的不应仅仅是识别汇总得分最高的架构,还应识别每个架构组件解决了哪些失效模式,以及引入了哪些新权衡。

## RAG 系统复杂性的渐进式架构

更实用的 RAG 设计方法是将复杂性视为逐步升级路径。

每个额外的机制都应对应于证据,证明前一架构无法充分解决某一类重要查询。

图6。RAG系统的渐进式架构。高级别并不天生优越;每个层级引入的能力应对应于低级别观察到的限制。图片由作者创作。

### 第0层:确定是否需要检索

并非所有基于知识的应用都需要检索子系统。

对于足够小且稳定的语料库,直接提供源材料可能在操作上更简单。例如,Anthropic指出,在某些情况下,低于约20万个token的知识库可能直接提供给模型,而不是动态检索。

确切的阈值取决于模型、工作负载、延迟要求和成本结构,但更广泛的架构原则仍然适用:应因应用需求引入检索,而不是仅仅因为系统被描述为RAG。

### 第1层:建立语料库表示

如果需要检索,下一步是确保语料库表示正确。在检索优化之前,系统应:

- 验证解析,
- 保留文档层次结构,
- 传播元数据,
- 明确处理表格,
- 建立有意义的块边界,
- 在必要时保留父子关系,
- 在摄入过程中应用访问控制元数据。

### 第2层:建立词汇基线

词汇基线提供了有用的参考点。BM25计算成本低,可解释性强,在精确术语至关重要的场景中表现尤为出色。

其目的不是成为最终的检索架构。它用于确定后续改进是否能相对于一个能力良好的传统基线产生可衡量的提升。

### 第3层:引入密集检索

当评估显示存在显著的词汇-语义不匹配时,密集检索是合理的。在这个阶段,重要的比较不仅是下游答案质量,还包括词汇检索和密集检索返回的候选集。

如果密集检索持续恢复出词汇检索遗漏的相关证据,额外的复杂性正在解决可衡量的失败模式。

### 第4层:引入混合检索

当词汇和密集方法表现出互补的召回率时,混合检索变得合理。系统可以结合各自的优点,而不是选择其中一种方法作为默认。

这通常是检索架构在更广泛查询类型上变得更稳健的转折点。

### 第5层:引入重排序

如果候选召回率已经很强但结果排序仍然薄弱,重排序成为下一步的合理选择。

检索层可以保持广泛且以召回为导向,而更昂贵的重排序器则专注于在较小的候选集上提升top-k精度。

### 第6层:改进表示

如果问题持续存在,问题可能仍然出在语料库的表示方式,而非检索算法本身。观察到的失败模式可能证明需要上下文块、父文档检索、领域特定嵌入、晚期交互架构、表格专用索引或替代分割策略。

在此阶段,问题的核心已不再是增加另一种检索机制,而是提升这些机制所依赖的信息质量。

### 第7层:引入查询转换

当评估显示查询与文档之间存在系统性不匹配,或信息需求包含多个可分离的组成部分时,查询重写和分解变得有价值。

### 第8层:引入智能体检索

当检索过程本身需要适应性决策时,智能体机制才具有合理性:

- 在异构来源间进行选择,
- 决定下一步获取哪些信息,
- 利用检索到的证据制定后续搜索,
- 判断是否已收集足够证据,
- 执行可变长度的多跳检索轨迹。

此时架构引入智能体并非因为智能体存在,而是因为信息检索问题本身需要适应性控制流程。

## 固定式与适应性检索应共存

该框架进一步表明:并非所有发送到智能体RAG系统的查询都必须触发智能体工作流。

生产系统可能需要区分查询类别。

图7. 异构RAG系统可根据不同信息需求将请求路由到具有不同计算和推理需求的检索策略。

该架构将智能体检索视为更大检索系统中的一个能力模块,而非通用执行路径。

例如以下查询:

> 合同4827的取消期限是什么?

可能只需要词法和元数据约束的检索即可。

而以下查询:

> 将当前合同中,负责上季度SLA违规率最高的三项服务的供应商的取消义务进行比较。

其结构完全不同,可能需要:

- 查询运营数据,
- 识别供应商,
- 检索多个合同,
- 定位相关条款,
- 规范术语,
- 对比证据。

对这两个请求应用相同的检索编排机制难以合理解释。更稳健的系统应根据信息需求的结构进行查询路由,在信息需求可满足时使用简单检索,在任务确实需要时使用适应性检索。

## 复杂性应基于已证明的失败

核心问题不在于高级RAG技术是否有效。许多技术确实有效。问题出现在这些机制成为架构默认方案,而非对观察到的限制做出响应时。

大语言模型使架构增强异常容易。如果检索效果差,可以添加模型重写查询;如果重写查询失败,可以引入额外检索;如果候选集噪声大,可以用模型进行评分;如果证据不完整,可以通过反思阶段发起新搜索;如果最终响应仍错误,可以用其他模型进行验证。

每次添加都可能改进某些查询,同时掩盖管道早期的缺陷。足够复杂的推理系统因此可能产生更好的端到端结果,同时使架构更难理解、评估和操作。

相关工程目标不是架构极简主义。

而是架构合理性。

组件的存在应能用可衡量的系统限制进行解释:

> 混合检索的存在是因为密集型检索和词法检索在目标语料库中表现出互补的召回能力。重排序的存在是因为候选召回率足够而top-k精确率不足。查询分解的存在是因为多跳问题在单查询检索下系统性失效。智能体的存在是因为后续检索操作依赖于执行过程中发现的证据。

这种表述方式将RAG架构从一组当前流行的技术转变为一系列可验证的工程决策。

# 参考文献

Anthropic。引入上下文检索。2024年。跨多个知识领域的实验,研究上下文嵌入、上下文BM25、混合检索和重排序。

Akarsu, M., Karaman, R. K., & Mierbach, C. 从BM25到修正型RAG:文本和表格文档检索策略的基准测试。2026年。在23,088个财务问答查询和7,318个文档上对十种检索策略进行基准测试。

Wang, P., Xu, B., Wang, S., 等。哪种RAG范式在规模上表现最佳?检索增强生成范式的扩展研究。2026年。对词法、密集型、基于图和智能体检索进行受控比较,语料库规模从约1,000到512,000个文档。

Ammann, P. J. L., Golde, J., & Akbik, A. 用于检索增强生成的查询分解。2025年。在MultiHop-RAG和HotpotQA上评估基于大语言模型的查询分解和重排序。