当前位置： 首页 > article >正文

除了混合搜索，RAG 还需要哪些基础设施能力

article 2024/11/28 15:54:58

Infinity 是一款专门为 RAG 设计的，在功能和性能上全面领先的数据库，针对向量，稀疏向量，还有文本类数据，分别提供高性能的向量搜索、稀疏向量搜索以及全文搜索，并且提供这些数据之上的高性能范围过滤，除此之外，还提供了基于 Tensor 的重排序，这使得数据库内置不亚于 Cross Encoder 的排序能力成为可能，并且还是多模态 RAG （还有个流行的说法叫做 VisualRAG）的强力助推器。因此，如下图所示，Infinity 本质上是一款针对各种数据的全索引数据库。

这些能力，已经在工程和学术上形成共识，是 RAG 的必备能力，那么除此之外，还有哪些能力是现在，还有未来的 RAG 所必备的呢？

GraphRAG

首先来看看 GraphRAG。在这里，GraphRAG 并不单指微软开源的工作，而是指以知识图谱自动构建为基础，辅助 RAG 召回，从而解决问答中较为难处理的“语义鸿沟问题”（根据问题搜不到答案）的一类方法论集合。

既然涉及到知识图谱，就不可避免涉及到图数据库这一个单独品类。图数据库是应对复杂图结构查询的一类数据库。例如以下查询：返回由用户 Alice 完成的所有 2 跳汇款的全部来源账户和目标账户。用 SQL 表达如下：

SELECT a.owner, c.owner
FROM Accounts a, b, c, Transactions t1, t2
WHERE b.owner = Alice AND a.owner=t1.From AND t1.To=b.owner AND t1.To=t2.From AND t2.to=c.owner

这需要有 2 张表：账户表和交易表。执行操作如下：

  1. 在账户表中找到所有属于 Alice 的账户 (b.owner = Alice)

  2. 在交易表中找到所有向 Alice 发起交易的账户 (a.owner = t1 From And t1.To = b.owner)

  3. 接着找到 Alice 作为发起者的账户 (t1.To = t2.From)

  4. 最后找到这些交易的最终目标账户 (t2.To = c.owner)

因此可以看到，这类查询有 3 个特点：

  1. 尽管本查询只有 2 张表，但查询需要涉及非常多的多表 Join。

  2. 用关系型数据库建模非常别扭。

  3. 采用关系型数据库查询效率非常低下，因为这些多表 Join ，都需要做表的非顺序扫描，但是每个操作只需要返回几条记录，这么多的 Join，在做查询计划时，非常困难，传统的关系型数据库实现很容易导致中间结果的过度膨胀出现 OOM 。

因此，图数据库的特点包含：

  1. 为规避表的非顺序扫描，引入索引，尤其是倒排索引。所谓倒排索引，其实就是：把节点和边，分别按列保存，然后针对边来构建倒排索引，索引的内容就是节点 ID。

  2. 优化多表 Join ，一些 SOTA 的系统会引入多路 Join 实现如因子化——Worst Case Optimal Join 【参考 1】。

回到知识图谱，我们需要以上复杂的图查询么？ 先不考虑 GraphRAG，一个标准的知识图谱，我们最需要的查询是，根据实体，获取它的图谱上的邻居，复杂一些，需要提供一些子图遍历，就是根据若干实体，获取它们的邻居，以及多跳邻居，这些都可以比较方便地通过索引来实现，因此，对知识图谱的支持，可以算是一种相对简化的图数据库需求。

回到 GraphRAG ，我们以 LightRAG【参考 2】为例来看 GraphRAG 都会涉及到哪些查询。之所以采用 LightRAG，是因为它对于 GraphRAG 查询的总结更加全面和体系化，如下图所示。

这里需要的查询有：

  1. 根据关键词向量找到 Top 最接近的实体

  2. 根据这些实体在知识图谱中找到它们连接的关系

  3. 根据关键词向量找到 Top 最接近的关系（边）

  4. 根据这些关系在知识图谱中找到它们连接的实体

可以看到，GraphRAG 对知识图谱查询的需求相当简单。在 GraphRAG 中，对于知识图谱的抽象和定义是一种简化，实体之间的关系只被简化成为一种。 这是因为 LLM 对于实体以及关系的定义并不够准确，因此构建的知识图谱，通常是作为 RAG 的补充而提供辅助召回使用。近期，蚂蚁也公开了自己在 GraphRAG 方面的布局 KAG 【参考 3】，它对于知识图谱的定义更加完整，对实体之间的关系扩展到了 6 种，并引入了逻辑 reasoning 框架，但落实到对数据的检索本身，并没有发生显著变化。因此，一种朴素的想法，服务当下以及未来的 GraphRAG，是否把一个裁剪后的图数据库移植过来，就可以满足要求？

最近，来自滑铁卢大学的资深搜索引擎研究员 Clarke 提出了一种新型索引 Annotative Indexing【参考 4】，目的是希望统一列存，全文搜索，以及图数据库。这里所谓的 Annotative，其实就是在倒排索引的结构上进行调整，通过引入注释，可以让倒排索引以更加灵活的方式来创建。基于这些观察，我们来看看，作为一个全索引数据库，Infinity 是否已经可以满足当下及未来 GraphRAG 的要求。

如下图所示，我们可以很容易的对知识图谱的实体，边进行建模。在 GraphRAG 中，知识图谱的实体、边，这些都是文字描述，此外还有根据实体之间聚类得到的社区以及由此生成的总结。因此，这些文本都可以用全文索引来创建关联。Infinity 的全文索引提供了非常全面和强大的语法，除了进行相似度得分计算，还可以基于关键词提供过滤能力。因此，对边的<源实体名，目标实体名>字段建立全文索引提供关键词过滤，既可很方便的进行基于边和实体的子图检索。除此之外，全文索引和向量索引，在 Infinity 内部是无缝衔接的，因此，基于这种数据建模，可以非常方便的提供针对 GraphRAG 的混合搜索，所有边，实体，乃至社区，它们的描述都被纳入全文搜索的范畴，连同向量一起，就提供了基于 GraphRAG 的 2 路混合召回。 并且，从以下的 Schema 也可以看出，这些数据，只需要再增加一个类型字段，就可以连同原始的文本 Chunk 一起保存在一张表，这就是把 GraphRAG 和 RAG 结合的 HybridRAG 【参考5】。显然，采用一个具备丰富索引能力的数据库，可以极大降低让这些复杂逻辑落地的工程难度。

因此，可以得出结论，当下的 Infinity，已经满足了 GraphRAG 当前以及未来的存储需求。在未来，Infinity 会围绕计算层添加更多的执行逻辑，使得部分在应用层的代码可以下沉到数据库内，提升性能和易用性，比如：

  1. 有一类 GraphRAG 是直接把 Text Chunk 当作图的节点，Chunk 之间的相似度（基于各种选项）决定了它的边。这显然也可以采用倒排索引建模。那么把创建这类索引的工作，可以实现为 Infinity 的一个后台任务。

  2. GraphRAG 需要跟模型紧密交互，未来不可避免地会引入一些图计算的能力：例如基于一个子图的遍历结构，生成Graph Embedding，这种任务，也可以实现为 Infinity 的一个后台任务。

等等诸如此类，都可以通过后台任务或者函数来完成，但是，它们都只需要采用 Infinity 当前的引擎架构即可完成而无需大的调整。这显然也符合 Infinity 自身不断随着 RAG 发展和演进的需求。

Long-term Memory

接下来看看记忆管理。记忆管理和 Agent 密切相关，可以说是 Agent 必备组件。在 RAGFlow 中，已经提供了 Agent 框架。 当前的 Agent ，大多数场景是跟工作流紧密挂钩的，例如通过工作流实现 RAG 跟外部系统之间的交互，通过工作流实现 Agentic RAG 等等。然而，Agent 的未来是以 Multi-Agent 为代表的更加智能的系统，它们将用来辅助 LLM 共同提供 Reasoning 能力。Multi-Agent 跟 RAG 的交互会更加频繁，下图是一个典型的架构【参考 6】：

在这些架构中，Agent 需要管理自己的记忆，例如用户的对话 Session，用户的个性化信息，等等。有很多 Agent 框架会采用短期记忆模块来管理这些数据，区分于长期记忆。前者主要用一些内存临时数据来完成，随着 Agent 使用量增多，由于所有的用户信息都要保存，因此比较可靠的方式，是直接采用长期记忆组件来管理所有记忆，也就是用数据库，来保存所有用户的上述信息，信息的格式，既包含文本，也包含向量。对于记忆管理来说，它所需要的接口，其实核心就 2 类：

  1. 过滤。根据用户 ID，以及 Agent ID 和时间范围，来获取特定 Agent 和用户的记忆信息。

  2. 搜索。根据上下文信息（包括文本和向量），来查询用户记忆模块中相关的信息。

由于Agent对于记忆的获取，是实时性非常高的行为，因此，长期记忆管理的数据库，除了必须支持以上 2 类需求，还必须保证实时性：数据必须插入即可见，因此，这本质上是一种 Streaming Search 的需求—— 在 Infinity 内部，所有索引，都满足这个要求。对于向量来说，索引的构建是一个非常耗时的工作，因此，Infinity 在内部，对于刚插入的数据是直接采用 Brute Force 扫描，来提供实时查询。因此，即使是应对即将到来的 Multi Agent 系统，Infinity 也已经做好了准备。

Infinity 作为一款专门服务于 RAG 而设计的数据库，经过一路演进，已经具备了完整的服务能力。在 RAGFlow 最新发布的 0.14 版本中， Infinity 终于被集成到了 RAGFlow ，作为 Elasticsearch 的备选。经过充分测试和验证后，Infinity 将作为 RAGFlow 的首选，从那时起，许多更加高级的功能，将逐步被释放出来。欢迎持续关注 Infinity 和 RAGFlow ：

https://github.com/infiniflow/infinity

https://github.com/infiniflow/ragflow

参考文献

  1. https://github.com/kuzudb/kuzu

  2. https://github.com/HKUDS/LightRAG

  3. https://github.com/OpenSPG/KAG

  4. Annotative Indexing, arXiv preprint arXiv:2411.06256

  5. HybridRAG: Integrating Knowledge Graphs and Vector Retrieval Augmented Generation for Efficient Information Extraction, Proceedings of the 5th ACM International Conference on AI in Finance, 2024

  6. TCAF: a Multi-Agent Approach of Thought Chain for Retrieval Augmented Generation, 2024 KDD Cup Workshop for Retrieval Augmented Generation


http://www.kler.cn/a/412959.html

相关文章：

  • 『VUE』elementUI dialog的子组件created生命周期不刷新（详细图文注释）
  • 如何搭建一个小程序：从零开始的详细指南
  • MySQL中的like模糊查询
  • DB2数据库
  • 集合Queue、Deque、LinkedList、ArrayDeque、PriorityQueue详解
  • Leetcode437. 路径总和 III(HOT100)
  • 【小白学机器学习37】用numpy计算协方差cov(x,y) 和 皮尔逊相关系数 r(x,y)
  • 微信小程序蓝牙writeBLECharacteristicValue写入数据返回成功后，实际硬件内信息查询未存储？
  • EXISTS 和 IN 的使用方法、特性及查询效率比较
  • 开发中使用UML的流程_05 PIM-1：分析系统流程
  • QChart数据可视化
  • Vue 3 Teleport 教程
  • Epipolar-Free 3D Gaussian Splatting for Generalizable Novel View Synthesis 论文解读
  • 【接口封装】——7、连接并使用 MySQL 数据库
  • 统计词频
  • 深入解析：用Scala验证身份证号码的合法性
  • C++ 中的函数对象
  • API安全
  • Ubuntu EFI分区扩容
  • C# 索引器 详解（含对照例子）
  • “harmony”整合不同平台的单细胞数据之旅
  • RabbitMQ 集群
  • Qt中QSpinBox valueChanged 信号触发两次
  • EtherCAT Coe对象创建与通信
  • 爬取的数据如何有效进行数据分析？
  • 49-基于单片机的湿度和光照监测