Infinity 数据库自诞生之初，便专为 RAG 场景量身打造。它在向量、稀疏向量与文本数据方面，实现了高性能搜索、稀疏向量检索与全文搜索的全面领先。此外，Infinity 还支持基于这些数据类型的高效范围过滤，并内置了基于张量的重排序机制——这使得数据库具备了媲美 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

这里涉及两张表：账户表与交易表。执行流程大致如下：

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）

1. 尽管仅涉及两张表，却需要大量多表 Join 操作。
2. 使用关系型数据库进行建模极为不便。
3. 查询效率极低，因为所有多表 Join 都需要进行非顺序扫描，而每次操作仅返回少量记录。面对众多 Join，查询计划制定极为困难，传统关系型数据库极易导致中间结果膨胀，甚至发生 OOM。

1. 为避免表的非顺序扫描，引入索引，特别是倒排索引。所谓倒排索引，即将节点和边分别按列存储，然后针对边构建倒排索引，索引内容为节点 ID。

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

回到知识图谱，我们是否真的需要如此复杂的图查询？暂且不考虑 GraphRAG，一个标准的知识图谱最常用的操作是根据实体获取其在图谱上的邻居。复杂一些，则是提供子图遍历——根据若干实体获取其邻居及多跳邻居。这些通过索引便可较为方便地实现。因此，对知识图谱的支持，可视为一种相对简化的图数据库需求。

再回到 GraphRAG，以 LightRAG【参考 2】为例，看看它涉及哪些查询。选择 LightRAG 是因为它对 GraphRAG 查询的总结更加全面、系统，如下图所示：

1. 根据关键词向量找到 Top 最接近的实体。
2. 根据这些实体在知识图谱中找到它们连接的关系。

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

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

由此可见，GraphRAG 对知识图谱的查询需求其实相当简单。在 GraphRAG 中，知识图谱的抽象与定义被简化，实体之间的关系仅简化为一种。这是因为 LLM 对实体和关系的定义尚不够精准，因此构建的知识图谱通常仅作为 RAG 的补充，提供辅助召回。近期蚂蚁集团也公开了其在 GraphRAG 方面的布局 KAG 【参考 3】，它对知识图谱的定义更加完整，实体之间的关系扩展到六种，并引入了逻辑推理框架。但在数据检索本身并未发生显著变化。因此，一个朴素的想法是：为当前及未来的 GraphRAG 服务，是否移植一个裁剪后的图数据库就足够了？

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

如下图所示，我们可以轻松地对知识图谱的实体和边进行建模。在 GraphRAG 中，知识图谱的实体和边均为文字描述，此外还有根据实体间聚类得到的社区及其生成的总结。这些文本均可通过全文索引创建关联。Infinity 的全文索引提供了非常全面且强大的语法，除了计算相似度得分，还能基于关键词提供过滤能力。因此，对边的<源实体名，目标实体名>字段建立全文索引，并提供关键词过滤，就能非常方便地实现基于边和实体的子图检索。更重要的是，全文索引与向量索引在 Infinity 内部无缝衔接。基于这种数据建模，可以轻松提供针对 GraphRAG 的混合搜索——所有边、实体乃至社区的描述都被纳入全文搜索范围，连同向量一起，就能实现基于 GraphRAG 的两路混合召回。从下面的 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 共同提供推理能力。Multi-Agent 与 RAG 的交互会更加频繁，下图展示了一个典型架构【参考 6】：

在这些架构中，Agent 需要管理自己的记忆，例如用户的对话 Session、用户的个性化信息等。许多 Agent 框架会使用短期记忆模块来管理这些数据，以区别于长期记忆。短期记忆主要依赖内存临时数据实现，但随着 Agent 使用量的增加，所有用户信息都需要保存，较为可靠的方式是直接使用长期记忆组件——即数据库——来保存所有用户的上述信息。信息的格式既包含文本，也包含向量。对于记忆管理而言，其所需的核心接口主要有两类：

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

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

由于 Agent 对记忆的获取实时性要求很高，长期记忆管理的数据库除了必须满足上述两类需求，还必须确保实时性：数据插入后即刻可见。这本质上是一种 Streaming Search 的需求——而在 Infinity 内部，所有索引均满足这一要求。向量索引的构建非常耗时，Infinity 在内部对刚插入的数据会直接采用 Brute Force 扫描，从而提供实时查询。因此，即使面对即将到来的 Multi-Agent 系统，Infinity 也已经做好了准备。

Infinity 作为一款专门服务于 RAG 的数据库，一路演进至今，已经具备了完整的服务能力。在 RAGFlow 最新发布的 0.14 版本中，Infinity 被集成到了 RAGFlow，作为 Elasticsearch 的备选引擎。经过充分测试与验证后，Infinity 将逐步成为 RAGFlow 的首选方案，届时更多高级功能也将逐步释放出来。