如何为企业RAG选择合适的数据存储方式

摘要:

本文讨论了矢量数据库、图数据库和知识图谱在解决信息检索挑战方面的重要性，特别是针对企业规模的检索增强生成（RAG）。

看看海外人工智能企业Writer是如何利用知识图谱增强企业级RAG。

要点概要：

- 矢量数据库高效存储数据，但缺乏上下文和关联信息。

- 图数据库优先考虑数据点之间的关系，受益于关系结构。

- 知识图谱在语义存储方面表现出色，由于其能够编码丰富的上下文信息，使其成为RAG的理想选择。

- 选择正确的数据存储技术对于成功的企业级RAG至关重要。

- 企业级知识检索取决于基础数据库技术的准确性和效率。

- 知识图谱在企业级RAG的搜索和检索任务中胜过矢量数据库和图数据库。

- 知识图谱基础与语言模型的结合显著提升了信息检索的准确性。

来源：https://writer.com/blog/vector-databases-graph-databases-knowledge-graphs/

正文：

根据2023年StackOverflow的调查，近54%的开发者发现等待问题答案常常导致工作中断，并频繁打乱他们的工作流程。与此发现相辅相成的是：近47%的开发者经常发现他们再次回答之前已经回答过的问题。换句话说，这些信息经常存在，但要么被锁在团队成员的脑海中，要么深深埋在其他公司资源中，开发者需要别人的帮助才能找到。

如果听起来像是浪费时间的话，想象一下同样的情况在每个部门中被放大。没有员工能幸免：在某个时刻，每个公司的每个人都会有问题，并需要等待答案。

这个问题并不是未知的。多年来出现了各种解决方案，包括公司内部网、维基和所谓的数字化转型。所有这些都带来了进步，但没有一个解决了这个看似简单但无限复杂的获取答案的问题。

这就是为什么检索增强生成（RAG）通常被视为知识管理的圣杯的原因。

当公司发展到企业级别时，它们很可能会经历多次重新品牌、重组和转型，高管和董事会成员来来去去，数百或数千名员工入职和离职。在这种情况下，甚至对公司的简单问题作答也是一种挑战。

AI - 通过RAG - 有望成为第一个真正的解决方案。借助RAG，员工提出自然语言问题，并使用任务数据库工具检索信息，利用生成式AI将该信息制定成可读、相关的答案。

RAG的初步结果今天很强大，对明天可能出现的情况充满希望，但这些结果也揭示了重大的局限性。没有合适的基础数据库支持，RAG无法发挥其潜力。

- SUMMARIZED BY WRITER

• 向量数据库以向量格式存储数据，使得搜索高效，但缺乏上下文和关系信息。

• 图数据库优先考虑数据点之间的关系，适用于建模密集连接的数据，但对于大规模处理和跨数据库查询效率较低。

• 知识图谱以语义描述存储和连接概念、实体、关系和事件，模拟人类思维，使其成为基于RAG的搜索的理想选择。

• 知识图谱在搜索和检索任务中表现优于向量和图数据库，特别是对于企业级RAG，这是因为它们能够保留语义关系并编码结构信息的能力。

• 选择适合企业级RAG的数据存储技术需要仔细评估数据处理、查询检索和LLM集成能力，知识图谱成为最合适的选择。

什么是向量数据库？

一个向量数据库以向量格式存储和维护数据。当数据准备存储时，它被分成100到200个字符的块。然后，通过一个嵌入模型，这些块被转换为可以存储在向量数据库中的向量嵌入。

向量数据库有很多用例，但从定义上来说，并不是RAG的完整基础。大多数向量数据库并不提供嵌入模型，因此公司通常需要找到并集成一个嵌入模型，才能将向量数据库用作他们的基础。

向量数据库的特性也因所使用的算法而异。向量数据库使用KNN（K最近邻）或ANN（近似最近邻）算法，每种算法对任何搜索和检索特性的最终结果都有不同的影响。

当用户输入查询时，向量数据库将查询转换为一个向量嵌入，然后使用KNN或ANN算法确定哪些数据点最接近查询数据点。正如它们各自的名称所示，这两种算法都很相似，但ANN更为近似，同时速度更快。

向量数据库的优点和缺点

矢量数据库具有各种优点和缺点，但当企业试图使用它们构建RAG功能时，这些缺点往往凸显出来。当企业在企业规模面临这些缺点时，它们往往更具重要性。

优点

向量数据库的主要优势在于公司可以存储不同的数据类型，包括文本和图像。

除了纯粹的存储功能之外，向量数据库还能提供比传统关键字搜索更好的搜索功能。如果用户正在寻找具有语义相似性的数据，即使没有字面上的关键字匹配，向量数据库通常也可以帮助他们找到这些数据点。

缺点

向量数据库的主要弱点源于其处理数据的方式。特别是在企业环境中，信息检索需要具有精确和细致的特点，而这种数据处理的粗糙性可能会显示出压力。当数据被处理为向量存储时，上下文往往会丢失。各个数据点之间的关系上下文尤其容易变得模糊。

与关键词搜索相比，向量数据库的优势在于可以基于近似性（KNN和ANN）来识别数据点之间的相似性。但当与其他数据库相比较时，它也会成为一个弱点。除了纯粹的数值近似性之外，向量数据库无法保留用以说明不同数据点之间关系的上下文。

正如fair hiring platform Fribl的首席人工智能产品官Anthony Alcaraz所写：“问题常常与其所寻找的答案存在间接关系。” 举例来说，考虑对Apple的起源的简单描述：

Apple于1976年4月1日成立，由Steve Wozniak和Steve Jobs共同创办。该公司于1977年注册成立。其第二款计算机Apple II作为首批大规模生产的微型计算机之一销售状况良好。Apple于1983年推出了Lisa，1984年推出了Macintosh，这些计算机是最早使用图形用户界面和鼠标的计算机之一。

如果这些数据存储在向量数据库中，并且用户查询“Apple何时推出第一台Macintosh？”时，正确的数据可能变成了错误的答案。

由于粗糙的分块和KNN算法关注的仅仅是近似性，数据库可能会提取最接近的分块“1983”和“Macintosh”，而不是段落实际上所说明的内容。基于这些错误数据，语言模型会形成一个自信但错误的回答：“第一台Macintosh是在1983年推出的。”

这种上下文的丧失在企业环境中尤为重要，因为在这些环境中，数据往往非常稀疏或者非常密集。在任何情况下，向量搜索往往会难以找到并返回相关或完整的答案，甚至可能失败。在高维环境中，这种弱点会加剧，KNN算法无法找到有意义的模式，这就是所谓的“维度诅咒”的问题。

鉴于语境的缺乏，即使是一款本来有效的LLM也无法得出准确的答案。企业可能会遇到经典的垃圾输入和垃圾输出问题：由于缺乏背景信息和简略的分块处理，返回的数据点可能与查询无关或不准确，从而导致LLM无法成功。一般来说，合成的过程越多，矢量数据库的功能就越差。

矢量数据库在进行RAG时也会遇到可扩展性、性能和成本问题。大型数据集可能会使KNN算法变得低效，例如，由于KNN算法将数据集存储在内存中，处理这些通常较大的数据集会消耗大量的资源。

这种资源的消耗还会迅速增加，因为企业在输入新数据时需要重新运行和更新整个数据集。随着性能和可扩展性问题的出现，成本问题也会随之而来。

什么是图数据库

就像向量数据库一样，图形数据库存储和维护数据，但其数据存储结构是独特的。而向量数据库通常丢失关系上下文，图形数据库通过使用节点和边在数据点之间形成图形来优先考虑关系。

这种以关系为先的独特方法源于关系数据库，这使得图形数据库在RAG中值得考虑。关系数据库将数据存储在表中，并将类似结构的数据紧密组织在一起。然而，关系数据库无法提供定义表之间关系的能力。

正如科技与公民生活中心的数据库经理Kaleb Nyquist所写：“具有讽刺意味的是，图形数据库实际上比关系数据库更加注重关系。”

图形数据库通常适用于对数据进行密集互连建模。由于图形数据库将数据建模类似于面向对象的语言，因此生成的数据库包含对相关数据点的直接指针。

图数据库的优点和缺点

图数据库只有短短几年前才是数据库领域的热门话题，而且在许多情况下，强调关系使它们成为一种有用的工具。但是在这之后的几年里，图形数据库的用户也发现了一些弱点，这使得在没有补充的情况下，图形数据库并不是理想的RAG目的选择。

优点

图数据库，因为它们将关系放在首位，所以在那些数据点之间的关系对于产生意义至关重要的情境中，往往是最有优势的。与关系型数据库不同，图形数据库提供了一种存储关系本身的原生方法，允许开发人员将关系存储为从一个实体到下一个实体的内存指针。

由于能够直接定义关系，开发人员无需担心在数据库模式中对这些关系进行建模。数据工程师菲利普·布伦贝格解释了这些好处：“我们不需要了解外键，也无需编写关于如何存储它们的逻辑。我们定义了实体和关系的模式，系统会自行处理。”

每个关系提供了数据点之间的上下文，但开发人员还可以给形成这些关系的节点和边缘分配标签，从而允许开发人员为每个关系分配权重和方向性。正如布伦贝格所写：“方向赋予了关系以意义；它们可以没有方向，单向或双向。”

图形数据库还更容易为非技术用户理解，因为生成的模型反映了人类思维及其视觉维度。在那些需要检索、建模和展示知识的情境中，这种可视化通常使它们成为首选。

缺点

图数据库有一些弱点，尤其是在效率和功效方面。

当企业使用图数据库处理大量数据时，图数据库经常遇到效率问题。在企业环境中，如果有大量的稀疏数据和密集数据，图数据库的效率尤其容易下降。

当用于在数据库之间运行扩展查询时，图数据库的效果也较差。这些数据库越大，这些查询的效果就越差。

开发人员通常被图数据库吸引，因为它们在建模关系方面非常出色，但这个优点也是有限的。理论上，图数据库可以很好地建模关系，但这并不意味着它们可以创造出更好的关系。如果数据捕获不好，搜索和检索的好处将无法充分实现。

什么是知识图谱

与向量数据库和图数据库不同，知识图谱是一种数据存储技术，而不是一种根本不同的数据库。知识图谱模拟了人类的思维方式-关系和语义，并且远远超越了向量数据库和图数据库的数值关注和关系关注。

知识图谱技术使用每个概念、实体、关系和事件的语义描述来收集和连接。每个描述都有助于形成一个整体网络（或图），意味着每个实体通过语义元数据连接到下一个实体。

这种存储和映射数据的技术尽可能地模拟了人类在语义上下文中的思维方式。这种并行性使它成为RAG搜索的理想基础，因为RAG依赖于通过由主要由语义信息组成的数据库流动的自然语言查询。

特别是，Writer知识图谱集成了RAG，为用户提供：

• 链接不同数据源的数据连接器。

• 一个专门的LLM，可以在企业规模上处理数据，以建立密集和稀疏数据点之间的有意义的语义关系。

• 一种用于数据存储的图结构，可以存储数据点和数据关系，并在添加新数据时动态更新。

• 检索感知的压缩，可以在不丢失准确性的情况下压缩数据和索引元数据。

知识图谱的优点和缺点

基于图数据库构建的知识图谱拥有与图数据库相比的许多优势。然而，在特定的背景下，知识图谱还具有超越图数据库的优势，尤其是在RAG中。

优点

知识图谱和图数据库一样，将数据点及其关系存储在图数据库中。与图和向量数据库一样，知识图谱能够存储各种文件格式，包括视频、音频和文本。

但在向量数据库中，查询被转换为数值格式，往往意味着上下文的丢失。在知识图谱中，查询不需要重新格式化，并且使用这些查询的图结构——因为它保留了语义关系——允许比KNN或ANN算法更准确地检索。

对于 RAG 来说，搜索和检索是至关重要的，而在知识图谱中这一点尤为有效。在企业环境中，有效和无效搜索之间的区别通常在于能否跨多个来源综合数据。知识图谱将主题、语义、时间和实体关系编码到其图结构中，从而使综合成为可能。

然而，关系并不总是线性或单向的。通过知识图谱，开发人员可以编码层次结构和其他结构关系。在给定这些结构关系的情况下，知识图谱可以映射不同来源中不同数据点之间的连接，即使它们引用相同的实体。

阿尔卡拉斯写道：“相比之下，标准向量搜索缺乏这些结构关系的概念。段落被视为孤立的部分，没有任何周围上下文。”

上下文丢失是其他数据库的最常见弱点之一，特别是在 RAG 中使用时。在知识图谱中，上下文信息被保留，因为它被编码在检索到的信息中。

在 Writer Knowledge Graph 中使用的专业 LLMs，使这种优势更加突出。通过构建更丰富的语义关系，公司可以保留更多的上下文，并在多个维度上维持智能的关系定义。

缺点

由于知识图谱强调语义信息，往往需要大量数据压缩，这常常需要大量计算能力来支持它们。有时，对知识图谱进行的操作也可能很昂贵，这种昂贵性使得它们难以扩展。

和图数据库固有的弱点一样，知识图谱也无法很好地进行数据捕获和清理工作。同样，一个有效的知识图谱将受到无法形成可读答案而产生错误认知的LLM的限制。

如何选择合适的数据存储技术以支持企业的 RAG

RAG是一种特定的用例，选择一个通用的数据存储技术，无论声誉如何，都不太可能适用于RAG。如果你让用户接触到RAG，搜索的效率和检索到的信息的准确性对于用户来说必须非常高，才能建立起对它的信任。

本文涵盖了许多不同技术及其细微之处，因此，首先退一步。无论在哪个数据库中获取知识，都需要执行三个基本任务。一种比较这些数据库的方法是评估哪种数据库技术将支持每个任务。

• 首先，数据库必须处理数据。数据库将如何将大量数据拆分为更小的块以存储在数据结构中？

• 其次，数据库必须能够查询信息并检索到它。数据库将如何使用查询来检索相关的数据段，以回答此查询？

• 第三，数据库必须制定数据，以使LLM生成答案。数据库将通过怎样的方式将相关数据发送给LLM以生成答案？

在这些问题中，知识图谱特别突出。对于使用RAG的公司来说，知识图谱尤其有用，但当企业以企业级规模使用RAG时，差异就会扩大。

在一份《知识图谱和LLM准确性基准报告》中，研究人员发现，从基于GPT4和SQL数据库的16%准确率提高到使用同一SQL数据库的知识图谱表示时的54%准确率。

这种准确性差别不仅对RAG很重要，而且常常是成败的关键。当用户有问题时，他们本质上就缺乏答案，所以当一个实现不良的RAG返回不准确的答案或幻觉时，可能会造成困惑。在这样的高压下，只要犯一点错误，用户就会认为一个本来准确的RAG不可靠。

RAG的成功取决于您的基础选择

在许多软件开发环境中，快速交付并进行迭代是最佳方式。

例如，初创公司往往受益于使用最易接触的技术构建产品，并将其运送给潜在用户，然后根据结果确定开发的方向。交付产品；获取对产品及支持其的技术的反馈；迭代；然后再次交付。

然而，企业，尤其是那些依赖用户之间高度信任的功能的企业，不能贸然行动，然后再进行迭代。可靠性、可用性和可持续性对最早、最基本的技术决策依赖很大，因此必须事先进行大量研究。迭代和反馈仍然是必要的，但如果企业构建了错误的基础，迭代最终将涉及迁移或重建，而不是增量改进。

研究挑战与任务的复杂性相匹配。一个企业拥有大量的信息，但它并不像一本书一样布置；一个企业更像是由很多年积累的许多材料构成的沉积岩层。

这种复杂性是逐渐产生的，无论做多少前期工作，都无法使一个企业的信息变得简单易懂、映射和检索起来。相反，如果企业想要构建面向企业的可靠、可用、可维护的技术栈，它们就需要面对这种复杂性，需要使用从头开始构建的工具来处理这种复杂性。