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 张表：账户表和交易表。执行操作如下：
在账户表中找到所有属于 Alice 的账户 (b.owner = Alice)
在交易表中找到所有向 Alice 发起交易的账户 (a.owner = t1.From And t1.To = b.owner)
接着找到 Alice 作为发起者的账户 (t1.To = t2.From)
最后找到这些交易的最终目标账户 (t2.To = c.owner)
尽管本查询只有 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
