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 张表:账户表和交易表。执行操作如下:
-
在账户表中找到所有属于 Alice 的账户 (b.owner = Alice)
-
在交易表中找到所有向 Alice 发起交易的账户 (a.owner = t1 From And t1.To = b.owner)
-
接着找到 Alice 作为发起者的账户 (t1.To = t2.From)
-
最后找到这些交易的最终目标账户 (t2.To = c.owner)
因此可以看到,这类查询有 3 个特点:
-
尽管本查询只有 2 张表,但查询需要涉及非常多的多表 Join。
-
用关系型数据库建模非常别扭。
-
采用关系型数据库查询效率非常低下,因为这些多表 Join ,都需要做表的非顺序扫描,但是每个操作只需要返回几条记录,这么多的 Join,在做查询计划时,非常困难,传统的关系型数据库实现很容易导致中间结果的过度膨胀出现 OOM 。
因此,图数据库的特点包含:
-
为规避表的非顺序扫描,引入索引,尤其是倒排索引。所谓倒排索引,其实就是:把节点和边,分别按列保存,然后针对边来构建倒排索引,索引的内容就是节点 ID。
-
优化多表 Join ,一些 SOTA 的系统会引入多路 Join 实现如因子化——Worst Case Optimal Join 【参考 1】。
回到知识图谱,我们需要以上复杂的图查询么? 先不考虑 GraphRAG,一个标准的知识图谱,我们最需要的查询是,根据实体,获取它的图谱上的邻居,复杂一些,需要提供一些子图遍历,就是根据若干实体,获取它们的邻居,以及多跳邻居,这些都可以比较方便地通过索引来实现,因此,对知识图谱的支持,可以算是一种相对简化的图数据库需求。
回到 GraphRAG ,我们以 LightRAG【参考 2】为例来看 GraphRAG 都会涉及到哪些查询。之所以采用 LightRAG,是因为它对于 GraphRAG 查询的总结更加全面和体系化,如下图所示。
这里需要的查询有:
-
根据关键词向量找到 Top 最接近的实体
-
根据这些实体在知识图谱中找到它们连接的关系
-
根据关键词向量找到 Top 最接近的关系(边)
-
根据这些关系在知识图谱中找到它们连接的实体
可以看到,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 会围绕计算层添加更多的执行逻辑,使得部分在应用层的代码可以下沉到数据库内,提升性能和易用性,比如:
-
有一类 GraphRAG 是直接把 Text Chunk 当作图的节点,Chunk 之间的相似度(基于各种选项)决定了它的边。这显然也可以采用倒排索引建模。那么把创建这类索引的工作,可以实现为 Infinity 的一个后台任务。
-
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 类:
-
过滤。根据用户 ID,以及 Agent ID 和时间范围,来获取特定 Agent 和用户的记忆信息。
-
搜索。根据上下文信息(包括文本和向量),来查询用户记忆模块中相关的信息。
由于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
参考文献
-
https://github.com/kuzudb/kuzu
-
https://github.com/HKUDS/LightRAG
-
https://github.com/OpenSPG/KAG
-
Annotative Indexing, arXiv preprint arXiv:2411.06256
-
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
-
TCAF: a Multi-Agent Approach of Thought Chain for Retrieval Augmented Generation, 2024 KDD Cup Workshop for Retrieval Augmented Generation