AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


除了混合搜索,RAG 还需要哪些基础设施能力?
发布日期:2024-12-24 08:10:05 浏览次数: 1559 来源:InfiniFlow


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

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

GraphRAG

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

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


SELECT a.owner, c.ownerFROM Accounts a, b, c, Transactions t1, t2WHERE 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 



53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询