Infinity，AI 原生数据库，于2023年冬至前开源，短短三周多时间，就得到了开源社区的积极反馈，积累了800+星。大多数反馈集中于以下问题：
- “Infinity 只是另一个矢量数据库吗？既然已经有很多可用的矢量数据库，为什么还要从头开始创建另一个数据库呢？”
- “传统数据库可以轻松整合矢量搜索功能，那为什么还要重新发明轮子呢？”
- “Elasticsearch 已经对您所说的多重召回提供了良好的支持。那么，是什么让 Infinity 与众不同呢？”
今天，我们将尝试解决这些疑问，并深入探讨为什么大型模型时代需要全新的 AI 原生数据库。
Infinity 被定义为 AI 原生数据库，主要是因为它旨在支持检索增强生成 (RAG) 应用程序。起初，RAG 并不广为人知，并被称为“知识库插件”，这似乎是一个临时解决方案。人们认为大型语言模型（LLM）的进步，例如通过提供更高的代币限制，将使此类解决方案变得不必要。然而，最近，RAG这个词重新流行起来，甚至有人预测2024年将是“RAG年”。我们来探讨一下RAG是否经得起时间的考验，还是只是随着大型模型不断改进的一个临时解决方案。
- 大型语言模型（LLM）再强大，也只能替代人类的学习和推理能力，而不能替代数据存储和数据访问的功能。即使拥有大量的参数，法学硕士也无法仅通过通用数据的训练来准确表示组织内庞大且多样化的数据，而处理此类数据对于企业和私人场景至关重要。
- 无论LLM如何发展，在企业场景中，它都必须访问各种企业数据源，包括文档、日志和数据库，并面临与访问这些数据相关的挑战，例如权限、数据清洗、数据存储、跨数据源查询。值得注意的是，这些挑战无法仅靠法学硕士来应对。
正是这些事实让我们得出这样的结论：RAG将长期存在，而赋能RAG的核心数据库系统也必须不断升级和迭代，以跟上RAG的发展步伐。正是因为这个原因，我们发起了无穷大。
RAG 的架构
<图名称=“b9f2”>
</图>
我们相信 RAG 将围绕 AI 原生数据库构建，如下架构图所示：
在此架构图中：
- 可以有效表示为向量的数据将被转换为向量。
- 无法转换为向量的数据（例如各种结构化和半结构化数据）将以其原始格式存储。
- 查询不会仅限于使用单个向量来检索相似向量。相反，单个查询将包含多个搜索条件，包括向量搜索（查询中包含多个向量）、全文搜索、结构化数据查询以及各种查询的多次召回。
因此，RAG需要一个具有上述功能的灵活数据库，而不是一个只能搜索向量的数据库。这让我们回到了之前的问题：当我们只能向现有数据库添加矢量搜索功能时，为什么还要开发新数据库？
RAG 的核心要求
在 RAG 重新流行之后，出现了大量讨论如何提高其性能的文章。是的，提供更好的问答响应的能力可能是从事 RAG 项目的任何人主要关心的问题。这些文章中提到的大多数技术都围绕使用开源矢量数据库或具有内置矢量功能的传统数据库以及 Langchain 和 LLMOps 等中间件工具来构建简单的 RAG 系统。虽然这些“快速设置”在许多场景中可能只能充当玩具或原型演示，但我们仍然可以观察到所有这些技术都旨在满足 RAG 的三个基本要求：
- 通过精细的嵌入模型获得更好的向量：在将文本输入数据库之前需要对文本进行充分的预处理，并且正确的文本分割对于确保获得的向量合适也至关重要。
- 多次召回：事实上，多次召回对于 RAG 的重要性怎么强调都不为过。
- 排名（交叉注意力重新排名）：术语“交叉注意力”是指多重召回。多次召回的结果还需要有效的重新排名（融合排名），以便为法学硕士提供最合适的输入。
RAG 中未解决的挑战：多次召回和排序
RAG的三个主要需求中，除了前面提到的向量变换之外，剩下的两个都可以在数据库内部完成。因此，为什么不利用具有矢量功能的数据库呢？原因是有效执行这两项任务一直被证明具有挑战性。尽管搜索引擎已经存在了二十多年，但没有一家公司仅仅依靠数据库来构建互联网搜索引擎、2C领域的垂直搜索引擎或2B领域的企业搜索引擎。为了在 RAG 中取得成功，组织必须拥有构建搜索引擎的核心能力，因为 RAG 本质上是搜索引擎的演变。让我们看几个例子：
维斯帕
具有悠久历史的开源搜索引擎。 Vespa 的根源可以追溯到 20 世纪 90 年代，其前身是雅虎于 2003 年收购的搜索引擎 Overture。2023 年 10 月，Vespa 从雅虎获得独立，并从 Blossom 获得了 3100 万美元的资金。其著名的融资项目涉及一个大型 RAG，该 RAG 利用互联网数据向最终用户提供可靠的问答服务。
百川
最近，百川推出了基于 RAG 构建的 Turbo API。其后端采用了增强RAG有效性的技术，包括查询扩展、多重召回、排名等，这些都体现了其在搜索引擎开发方面的技术实力。作为著名互联网搜索引擎搜狗的继承者，百川向提供 RAG 服务的转变似乎是一个自然的过程。
perplexity.ai
对于最终用户来说最成功的 RAG 应用程序之一。它也是搜索引擎的演变，但通过执行以下操作超越了传统搜索引擎的范围：
- 利用语言模型 (LLM) 更好地理解用户问题并将其解析为更清晰的搜索查询。
- perplexity.ai 利用 Google 和 Bing 等搜索引擎的 API 创建了自己的特定域索引，确保了搜索质量。
- 采用专有的排名算法对所有搜索结果重新排名并过滤掉多个质量良好的网页。
- 利用 LLM 阅读排序的网页并生成与给定问题相关的答案。
综上所述，传统数据库由于缺乏搜索引擎所需的必备组件，无法有效满足RAG的需求。这些组件包括：
- 高效的全文索引。
- 多样化的排名方式。
- 无处不在的自然语言处理。
这些正是 Infinity 从一开始就瞄准并努力解决的问题。与上述迎合互联网搜索场景的大型RAG系统不同，Infinity是专门针对企业场景设计的。正如互联网搜索或垂直搜索将转变为上述应用一样，企业搜索也将不可避免地演变为企业RAG的一种形式。这是传统数据库结合矢量搜索功能无法解决的挑战。
Infinity 与 Elasticsearch
最后一个问题：Elasticsearch 现在广泛应用于企业搜索，能够进行矢量搜索和多重召回。 Infinity 与 Elasticsearch 有何不同？
在回答这个问题之前，我们先解决另一个问题：Elasticsearch 能否满足上述 RAG 应用程序的需求？这个问题与十年前提出的一个问题相呼应：“Elasticsearch 能否满足垂直搜索的要求？”毫无疑问，答案是肯定的；但是，以基本能力。搜索引擎时代的名言“相关性就是收入”在 RAG 领域仍然适用。为了满足业务需求，需要进行大量的查询扩展和排名调整，仅依靠 Elasticsearch 无法满足这些要求。
由于排名主要围绕 TF/IDF 等规则进行，因此传统企业搜索中文档排名的可能性有限：与网页的 PageRank 不同，企业内部的文档排名没有权重；没有可用的用户反馈来持续改进搜索排名结果。然而，除了 TF/IDF 之外，当前的 RAG 应用程序还可以利用各种嵌入模型来提高召回率和排名。因此，企业 RAG 应用程序现在与 Internet 用户使用的 RAG 应用程序更加紧密地结合在一起。两者之间的差异不再像过去传统企业搜索和互联网搜索之间的差异那么明显。
一个精心设计的RAG系统需要核心数据库和辅助AI工具，特别是针对垂直行业和企业量身定制的融合排名模型，以确保获得令人满意的结果。 Infinity从设计阶段就优先考虑了DB4AI，随着数据库核心能力的提升，一系列支持RAG应用的AI特性也将随之而来。
其次，Infinity是按照全面的数据库架构开发的，重点关注三个核心能力：矢量搜索、全文搜索、结构化数据查询及其相应的融合排名。相比之下，Elasticsearch 在十多年前就作为企业搜索引擎出现了。两者之间的一个显着技术区别是 Infinity 集成了执行引擎：当接收到查询请求时，执行引擎将其编译为计算 DAG（有向无环图），请求在管道中流过该图。引擎根据可用资源动态确定图中每个节点的并行度。另一方面，像 Elasticsearch 这样的搜索引擎没有执行引擎。它们使用倒排索引直接检索数据，并在排序后返回结果，所有这些都在单个线程内进行。
缺乏执行引擎意味着无法服务于多样化、精准信息检索的企业场景。一种常见的场景是带权限访问，需要访问权限表、业务表、维度表，还需要多次调用。如果无法提供对结构化数据的一般查询，即使是最简单的知识库也需要额外的权限数据库来进行联合查询。甚至可能需要通过ETL（Extract Transform Load）转换成宽表来供应用。但在高并发、在线场景下，引入宽表是没有必要的，也是不可接受的。因此，Infinity 并不是作为搜索引擎开发的，而是作为成熟的数据库开发的。虽然对于 2C 领域的 RAG 应用程序来说不是必需的，但对于企业 RAG 应用程序来说它是必不可少的。
此外，我们必须强调性能的重要性。作为使用 C++20 标准开发的数据库，Infinity 从一开始就将性能作为首要任务。它不会受到使用垃圾收集 (GC) 编程语言构建 Infras 所带来的各种波动和内存问题的影响。在矢量搜索方面，Infinity 的开源版本目前优于所有已知的开源矢量数据库。
最后，Infinity 将在 2024 年引入云原生架构，这也将使其与 Elasticsearch 显着区别。
这是我们对为什么选择为 RAG 开发新数据库的回应。欢迎感兴趣的读者关注我们的项目。