Infinity 是一个专门为检索增强生成（RAG）设计的数据库，在功能和性能方面表现出色。它为密集和稀疏向量搜索以及全文搜索提供了高性能能力，同时对这些数据类型进行高效的范围过滤。此外，它还具备基于张量的重新排序功能，能够实现强大的多模态 RAG，并集成与 Cross Encoders 相当的排序能力。
如下图所示，Infinity 本质上是一个用于多种数据类型的综合索引数据库。
这些能力已被工程界和学术界公认为检索增强生成（RAG）所必需的。当前和未来的RAG系统还需要哪些额外的能力？
GraphRAG
首先，让我们看看GraphRAG。这里，GraphRAG不仅指微软的开源项目，还指一种利用自动构建的知识图谱来辅助RAG检索的方法论。这种方法解决了问答中的“语义鸿沟”问题，即无法根据提出的问题找到答案。
由于涉及知识图谱，不可避免地要讨论图数据库的类别。图数据库旨在处理复杂的图结构查询。例如，考虑以下查询：返回用户Alice完成的所有两跳转账的源账户和目标账户。这可以用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
这需要两个表：一个账户表和一个交易表。操作如下：
- 在账户表中查找属于Alice的所有账户 (b.owner = 'Alice')。
- 在交易表中定位所有向Alice发起交易的账户（a.owner = t1.From 且 t1.To = b.owner）。
- 识别Alice是发起者的账户（t1.To = t2.From）。
- 最后，找到这些交易的最终目标账户（t2.To = c.owner）。
因此，我们可以观察到这种类型查询的三个特征：
- 尽管这个查询只涉及两个表，但它需要多次多表连接。
- 使用关系数据库进行建模相当繁琐。
- 由于需要对多个表进行非顺序扫描，关系数据库的查询效率非常低。每个操作通常只返回少量记录，这使得创建有效的查询计划变得具有挑战性。传统的关系数据库很容易导致中间结果过大，从而导致内存不足（OOM）错误。
因此，图数据库的特点包括：
- 为了避免对表进行非顺序扫描，他们引入了索引，特别是倒排索引。倒排索引按列分别存储节点和边，并根据边构建索引，索引内容为节点ID。
- 他们优化多表连接；一些最先进的系统实现了多路连接，以实现最坏情况下的最优连接 [参考1]。
回到知识图谱，我们是否需要如此复杂的图查询？除了GraphRAG之外，典型的知识图谱需要查询以根据给定实体检索相邻实体。更复杂的查询可能涉及子图遍历，以获取多个实体的邻居和多跳邻居。这些需求可以方便地使用索引来实现。因此，对知识图谱的支持是图数据库的一个相对简化的需求。
回到GraphRAG，让我们以LightRAG [参考2]为例，检查涉及的查询。选择LightRAG是因为它提供了更全面和系统的GraphRAG查询总结，如下图所示。
所需的查询如下：
- 找到最接近关键词向量的顶级实体。
- 识别知识图谱中连接这些实体的关系。
- 找到与关键词向量最接近的顶级关系（边）。
- 识别知识图谱中通过这些关系连接的实体。
显而易见，GraphRAG 中对知识图谱查询的要求相当简单。在 GraphRAG 中，知识图谱的抽象和定义被简化，实体之间的关系被简化为单一类型。这种简化源于大型语言模型（LLMs）通常缺乏对实体和关系的精确定义，导致知识图谱通常作为检索增强生成（RAG）的辅助工具。最近，蚂蚁集团也公布了其使用 KAG 的 GraphRAG 方法 [参考 3]，该方法提供了更全面的知识图谱定义，将实体之间的关系扩展到六种类型，并引入了推理框架。然而，数据检索本身并没有发生重大变化。因此，一个简单的想法出现了：移植一个精简的图数据库是否能够满足 GraphRAG 当前和未来的需求？
最近，来自滑铁卢大学的高级搜索引擎研究员Charles L. A. Clarke提出了一种新颖的索引方法，称为注释索引[参考文献4]。其目的是统一列式存储、全文搜索和图数据库。术语“注释”指的是对倒排索引结构的调整；通过引入注释，可以以更灵活的方式创建倒排索引。基于这些观察，我们将探讨Infinity作为一个完全索引的数据库，是否能够满足GraphRAG当前和未来的需求。
如图所示，我们可以轻松地建模知识图谱的实体和边。在GraphRAG中，知识图谱的实体和边被表示为文本描述，以及从这些实体及其摘要中聚类得出的社区。因此，所有这些文本都可以通过全文索引进行关联。Infinity的全文索引提供了全面而强大的语法，不仅支持相似性评分，还支持基于关键字的过滤。因此，在<源实体名称，目标实体名称>字段上建立全文索引可以方便地进行关键字过滤，从而促进基于边和实体的子图检索。此外，在Infinity中，全文索引和向量索引无缝集成，允许为GraphRAG量身定制高效的混合搜索。所有边、实体甚至社区都与向量一起包含在全文搜索的范围内，从而实现基于GraphRAG的双向混合召回。此外，如下图所示，只需在原始文本块旁边添加一个类型字段，就可以将这些数据存储在单个表中，从而有效地将GraphRAG和RAG结合为HybridRAG。显然，使用具有丰富索引功能的数据库可以显著减少实现这些复杂逻辑的工程挑战。
因此，可以得出结论，Infinity目前满足GraphRAG的存储需求，无论是现在还是将来。展望未来，Infinity将在计算层周围添加更多的执行逻辑，允许一些应用级代码集成到数据库中，从而提高性能和可用性。例如：
- 一种类型的GraphRAG直接将文本块视为图中的节点，块之间的相似性（基于各种选项）决定边。这也可以使用倒排索引进行建模。创建此类索引的任务可以作为Infinity中的后台作业实现。
- GraphRAG 需要与模型紧密交互，未来不可避免地会引入一些图计算能力。例如，基于子图遍历结构生成图嵌入也可以作为 Infinity 中的后台任务执行。
这些任务可以通过后台作业或函数来完成，所有这些都可以使用Infinity当前的引擎架构执行，而无需进行重大调整。这显然与Infinity随着RAG的发展而持续演进相一致。
长期记忆
接下来，让我们检查内存管理，它与代理密切相关，可以被视为一个基本组件。在RAGFlow中，已经提供了一个代理框架。目前，大多数代理与工作流紧密相连，促进了RAG与外部系统之间的交互，或者通过工作流实现代理式RAG。然而，代理的未来在于以多代理架构为代表的更智能系统，这些系统将帮助大型语言模型（LLMs）提供推理能力。多代理与RAG之间的交互将变得更加频繁，如下图所示。
在这些架构中，代理需要管理自己的内存，例如用户对话会话和个性化信息。许多代理框架使用短期内存模块来处理这些数据，将其与长期内存区分开来。前者依赖于临时内存数据；然而，随着代理使用量的增加，所有用户信息都需要保留，更可靠的方法是使用长期内存组件，特别是数据库，以文本和向量格式存储所有上述用户信息。对于内存管理，所需的接口基本上分为两类：
- 过滤：根据用户ID、代理ID和时间范围，检索特定代理和用户的特定内存信息。
- 搜索：根据上下文信息（包括文本和向量）在用户记忆模块中查询相关信息。
由于代理需要实时访问内存，长期内存管理的数据库不仅需要支持上述两种类型的要求，还必须确保实时性能：数据在插入后必须立即可见。这本质上需要一种流式搜索能力——在Infinity内，所有索引都满足这一要求。
对于向量，索引构建是一个耗时的过程；因此，Infinity 对新插入的数据采用暴力扫描，以促进实时查询。因此，Infinity 已经为即将到来的多代理系统做好了充分准备。
Infinity，一个专门为检索增强生成（RAG）设计的数据库，已经发展出全面的服务能力。在最新发布的RAGFlow版本0.14中，Infinity已被集成作为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
- 注释索引，arXiv 预印本 arXiv:2411.06256
- HybridRAG: 集成知识图谱和向量检索增强生成以实现高效信息提取，第五届ACM国际金融人工智能会议论文集，2024
- TCAF: 一种用于检索增强生成的多代理思维链方法，2024年KDD杯检索增强生成研讨会