@_avichawla: 面向AI工程师的8种RAG架构:(用法说明)1)Naive RAG——纯粹基于向量相似度检索文档…

X AI KOLs Timeline 新闻

摘要

一个推文串,解释了8种不同的RAG架构(Naive、Multimodal、HyDE、Corrective、Graph、Hybrid、Adaptive、Agentic)及其使用场景,并暗示了一种改进的索引技术。

8种面向AI工程师的RAG架构: (用法说明) 1) Naive RAG - 纯粹基于查询嵌入与存储嵌入之间的向量相似度来检索文档。 - 最适合简单、基于事实的查询,直接语义匹配即可满足需求。 2) Multimodal RAG - 处理多种数据类型(文本、图像、音频等),通过跨模态嵌入和检索。 - 适用于跨模态检索任务,例如用文本查询同时返回文本和图像上下文。 3) HyDE(假设性文档嵌入) - 查询与文档在语义上并不相似。 - 该技术在检索前根据查询生成一个假设性的答案文档。 - 使用该生成文档的嵌入来寻找更相关的真实文档。 4) Corrective RAG - 通过与可信来源(例如网络搜索)对比来验证检索结果。 - 确保信息的准确性和时效性,在将内容传递给LLM之前过滤或修正检索到的内容。 5) Graph RAG - 将检索到的内容转换为知识图谱,以捕捉关系和实体。 - 通过提供结构化上下文与原始文本一起给LLM,增强推理能力。 6) Hybrid RAG - 在单一流程中结合密集向量检索和基于图的检索。 - 当任务需要同时使用非结构化文本和结构化关系数据以获得更丰富的答案时非常有用。 7) Adaptive RAG - 动态判断查询需要简单的直接检索还是多步推理链。 - 将复杂查询拆分为更小的子查询,以提高覆盖率和准确性。 8) Agentic RAG - 使用具有规划、推理(ReAct、CoT)和记忆能力的AI代理来编排从多个来源的检索。 - 最适合需要工具使用、外部API或组合多种RAG技术的复杂工作流。 上述大多数架构都涉及某种形式的检索时决策。但它们都运行在已经索引好的数据之上。 如果索引步骤输出的片段杂乱无章,那么每种架构都会继承这些缺陷。改进索引是独立于上述8种架构之外的另一个问题。 我的联合创始人写了一篇关于索引步骤更好单元的文章。该技术: - 将语料库大小缩减40倍。 - 每次查询减少3倍的token数。 - 将向量搜索相关性提升2.3倍。 而且它不会改变检索算法、重排序器或嵌入模型。 详见下方。
查看原文
查看缓存全文

缓存时间: 2026/06/22 05:38

8 种面向 AI 工程师的 RAG 架构:

(附用法说明)

  1. 朴素 RAG
  • 完全基于查询嵌入与存储嵌入之间的向量相似度来检索文档。
  • 最适合简单、基于事实的查询,直接语义匹配即可满足需求。
  1. 多模态 RAG
  • 处理多种数据类型(文本、图像、音频等),通过跨模态嵌入和检索来工作。
  • 适用于跨模态检索任务,例如用文本查询同时获取文本和图像上下文。
  1. HyDE(假设文档嵌入)
  • 查询与文档在语义上并不相似。
  • 该技术会在检索前根据查询生成一个假设的答案文档。
  • 使用这个生成文档的嵌入来找到更相关的真实文档。
  1. 纠正型 RAG
  • 通过将检索结果与可信来源(如网络搜索)进行对比来验证。
  • 确保信息的时效性和准确性,在将内容传递给 LLM 之前过滤或纠正检索到的内容。
  1. 图 RAG
  • 将检索到的内容转换为知识图谱,以捕捉关系和实体。
  • 通过向 LLM 提供结构化上下文和原始文本,增强推理能力。
  1. 混合 RAG
  • 在同一管道中结合稠密向量检索与基于图的检索。
  • 当任务同时需要非结构化文本和结构化关系数据来生成更丰富的答案时尤其有用。
  1. 自适应 RAG
  • 动态判断查询是需要简单的直接检索,还是需要多步推理链。
  • 将复杂查询拆分为更小的子查询,以获得更好的覆盖率和准确性。
  1. 智能体 RAG
  • 使用具有规划、推理(ReAct、CoT)和记忆能力的 AI 智能体,协调来自多个来源的检索。
  • 最适合需要工具使用、外部 API,或结合多种 RAG 技术的复杂工作流。

以上大多数架构都涉及某种检索时的决策。但它们都运行在已经索引好的内容之上。

如果索引步骤输出了混乱的文本块,那么每个架构都会继承这些问题。改进索引本身是与上述 8 种架构无关的独立问题。

我的联合创始人写了一篇关于索引步骤中更优单元的文章。该技术:

  • 将语料库大小削减了 40 倍。
  • 将每次查询的 token 数减少了 3 倍。
  • 将向量搜索相关性提升了 2.3 倍。

而且它不改变检索算法、重排序器或嵌入模型。

查看下方内容。

向量搜索并不总是答案。

一个已有 30 年历史的算法,无需训练、无需嵌入、无需微调,至今仍然为 Elasticsearch、OpenSearch 以及大多数生产级搜索系统提供动力。

它就是 BM25,值得理解为什么它至今依然重要。

假设你在一个机器学习论文库中搜索 “transformer attention mechanism”。

BM25 使用三个核心思想对文档打分:

  1. 单词的稀有性比频率更重要
    每篇论文都包含 “the” 和 “is”,因此这些词不携带任何信号。
    但 “transformer” 是具体且信息量大的词,所以 BM25 给它的权重高得多。在公式中,这由 IDF(qi) 体现。

  2. 重复有帮助,但收益递减
    如果 “attention” 在一篇论文中出现 10 次,这是很强的相关性信号。但从 10 次增加到 100 次几乎不会提高分数。
    BM25 应用了一条由 f(qi, D) 和参数 k1 控制的饱和曲线,防止关键词堆砌操纵结果。

  3. 文档长度被归一化
    一篇 50 页的论文自然比一篇 5 页的论文包含更多关键词命中。
    BM25 使用 |D|/avgdl 进行调整,由参数 b 控制,这样较长的文档不会仅仅因为文本更多而主导排名。

三个想法。没有神经网络。没有训练数据。只有经得起时间考验的优雅数学。

以下是大多数人忽略的部分:BM25 擅长精确关键词匹配,而这正是嵌入真正难以做到的。

当用户搜索 “error code 5012” 时,向量搜索可能会返回语义相似的错误码。而 BM25 每次都会显示精确匹配。

这正是混合搜索成为顶级 RAG 系统默认方案的原因。

将 BM25 与向量搜索结合,你可以在同一个管道中获得语义理解和精确关键词匹配。

因此,在把 GPU 扔向每个搜索问题之前,请考虑一下 BM25 是否已经能解决它,或者至少通过结合两者能让你的语义搜索变得更好。

不过,当你这样做时,一个经常出问题的地方是展示结果为何匹配。

对于 BM25,匹配的 token 就是查询词,所以你可以直接高亮那些得分项。

但向量部分是基于嵌入相似度排名的,没有词汇重叠,因此段落中没有可标记的查询 token。

退而求其次地高亮整个检索块并不理想,因为一个块可能有数千个 token,而只有几个句子回答了查询。

这一点很难做到,但却是不可让步的,尤其是在医疗、法律和金融等领域,用户必须看到某个主张所源自的确切句子,而不是整页或整个块。

我的联合创始人写了一篇关于一种强大技术的文章,该技术能获取查询和段落,并返回实际驱动语义匹配的文本片段。

查看下方内容。

相似文章

RAG-Anything:全能型 RAG 框架

Papers with Code Trending

RAG-Anything 是一个全新的开源框架,通过整合跨模态关系和语义匹配来增强多模态知识检索,在复杂的基准测试中表现优于现有方法。