Writer.com基于图的RAG向量检索替代方案

Writer 首席执行官 May Habib 说,其语义图形化方法是使用向量数据库对 RAG 进行区块划分过程的替代方案。

译自 Writer.com's Graph-Based RAG Alternative to Vector Retrieval,作者 Richard MacManus。

检索增强生成 (RAG ) 是将预训练的大语言模型 (LLM) 与外部数据源集成的最常见方法;这是创建企业 AI 应用程序的一个重要因素。毕竟,如果一个组织无法利用其自己独特的(且可能是专有的)数据集,那么使用 LLM 的意义何在?

RAG 也是向量数据库在 AI 工程中变得如此流行的一个原因。在许多情况下,应用程序将使用 RAG 来执行向量检索和其他 LLM 优化,而这些优化最适合使用向量数据库来实现。

然而,有一家公司正在推销 RAG 的另一种用法——一种不涉及向量数据库的用法。Writer.com 是“基于图”RAG 的支持者,这意味着构建知识图谱并使用图数据库而不是向量数据库。

“知识图谱,我们的基于图的检索增强生成 (RAG),比使用向量检索的传统 RAG 方法实现了更高的准确性,”Writer 在其主页上宣称。

为了更多地了解 Writer 的基于图的 RAG 方法,我采访了其首席执行官 May Habib

我首先询问 Writer 如何定义“知识图谱”,因为该术语在知识管理领域有着相当悠久的历史。传统上,知识图谱一直是表示不同数据片段之间的关系和联系的一种方式。最近,Neo4j 和类似的图数据库 公司采用了该术语(“使用知识图谱为您的应用程序提供支持”,Neo4j 在其主页上宣称)。

“因此,人们往往会将知识图谱与图数据库混淆,”Habib 回答道,并补充说“我们并不是 Neo4j 的替代品”。然后她解释说,Writer 拥有一个专门的 LLM,可以绘制数据点之间的语义关系——这就是该公司所说的“知识图谱”。

不再分块

Habib 解释说,Writer 的语义图谱方法是 RAG 在与向量数据库一起使用时的“分块”过程的替代方法。

“这种方法(使用向量数据库的 RAG)的问题在于,实际上,当您执行数据预处理的第一步以对数据进行分块时,会丢失很多上下文。人们在工程和 NLP 周期中花费大量时间来进行上下文和分层分块,然后尝试将块重新嵌入到它们来自的上下文中,等等。许多此类用例都是高度复杂、动态的企业用例,[其中] 这些方法往往非常脆弱,并且不是一种可扩展的方法——当您考虑需要更新多少数据以及每次更改时都需要进行这种重新嵌入时。”

据 Habib 称,Writer 在数据预处理阶段使用其“小而强大”的 LLM——它们范围从 1.2 亿个参数到 200 亿个参数——添加“一组新的元数据层”。或者正如她在最近的 LinkedIn 帖子中所说的,“我们在执行任何其他操作之前使用 LLM 构建您数据的 AI 知识图谱”。

后续帖子 中,Habib 认为向量数据库 RAG 方法并不像看起来那么语义化。“嵌入捕获了您的数据和查询之间的语义相似性,但不会存储或连接上述多维空间中数据之间的关系,”她写道。

Writer 的方法是在开始时使用其自己的模型收集更多元数据,然后使用图数据库而不是向量数据库来管理数据。

“图数据库旨在存储实际信息——那些是节点——[以及] 实体之间的关系——那些是边。因此,它们也确实非常成功地扩展了规模。”

这是新的知识管理吗?

在知识管理 (KM) 领域,通常会创建“本体”来捕获组织内的含义。万维网联盟 (W3C) 有两种官方本体语言:RDFS(资源描述框架模式)和 OWL(Web 本体语言)。我很好奇 LLM 如何影响这一点,所以我问 Habib 企业内的 KM 实践者是否正在使用 Writer,或者它的工具是否有效地取代了组织中的该角色?

她回答说:“如果您已经构建了本体系统并投资了图表,生成式 AI 将是一个令人难以置信的补充。”然而,她补充说,“我们在数据之上构建的图表很大程度上是为了机器使用,而不是人。”

她似乎暗示的是,KM 实践者不必花费太多时间来创建新的本体,因为 Writer 可以为他们完成这项工作。

“那么有人会使用 Writer 来帮助技术作者想出那种馈送知识图表的本体吗?[是的] 我很确定。但我认为该角色不会消失——我认为完成这项工作的方式可能会发生改变。”

我注意到对 LLM 的一个常见批评,尤其是在组织环境中,是“输入垃圾,输出垃圾”的问题。我建议仍然需要技术作者和其他 KM 实践者来捕获企业中的核心知识。

Habib 承认这是一个问题,有时有人必须“过滤掉所有噪音 […] 才能想出黄金文档集”。但她说,Writer 的 LLM 在构建其知识图谱时确实会考虑“质量标准是什么?”

使用案例

在企业用例方面,Habib 说它为其目标垂直领域(保险、财富管理、CPG [消费品包装商品] 和零售)提供了“解决方案地图”。她说,它的目标是简化这些行业的流程。她以 CPG 和零售为例——“它是数字货架,是企业职能中的客户和用户参与,是财务、供应链和 RFP [征求建议书]。”

她补充说,Writer 是一个“全栈平台”,包括一个应用程序工作室。她不会详细说明应用程序开发工具,因为它尚未公开发布——但她表示“我们最大的客户已经在使用它了”。

总之,Writer 的知识图谱方法是否能够获得与具有向量数据库的“传统”RAG 相同的发展势头还有待观察。但这肯定是一个让 Writer 与众不同的机会,也许也是一个让图数据库公司探索的机会。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注