We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode #113: Why you need Knowledge Graphs for your AI chatbot | ft. Aniket Mitra

#113: Why you need Knowledge Graphs for your AI chatbot | ft. Aniket Mitra

2025/2/5
logo of podcast Real World Serverless with theburningmonk

Real World Serverless with theburningmonk

AI Deep Dive AI Chapters Transcript
People
A
Aniket Mitra
Topics
Aniket Mitra: 我是Saveway公司的创始人,我们专注于AI、ML和数据工程项目,尤其擅长构建企业级知识图谱。我曾为地图和零售领域的客户构建知识图谱,目前正在进行一些结合知识图谱和LLM的项目。知识图谱通过赋予数据语义意义,将信息转化为知识,其结构天然呈图状。这得益于本体论的概念,本体论定义了属性的语义,使知识图谱能够推断出未明确记录的信息。图数据库(如Neo4j)优于关系数据库,因为它能建模语义,捕获隐含信息,并支持属性和关系属性的查询;但知识图谱不应是万能的,应与其他系统(如Elasticsearch)结合使用。结合向量数据库和图数据库可以更好地利用LLM:向量数据库捕捉基于位置的关联,图数据库捕捉语义相似性,两者结合可以获得更佳效果,甚至可以结合图神经网络生成嵌入。在LLM增强检索中,图数据库和向量数据库协同工作:图数据库用于处理实体关系和语义关系,向量数据库用于处理语义相似性;可以采用多Agent系统或结合两种嵌入的方式来整合信息。LLM的出现正在解决知识图谱构建中的两个核心问题:一是利用LLM实现本体论的半自动化管理,二是利用LLM改进查询解释,减少对人工干预的依赖。知识图谱可以用于改进RAG,特别是针对特定领域:它可以帮助选择用于微调过程的文档和信息,并通过结构化信息来减少上下文长度的限制,从而提高微调效率。这形成了一个闭环:微调后的LLM可以更好地将非结构化数据转换为结构化数据,从而改进知识图谱。我的团队正在研究如何利用LLM更高效地构建和使用知识图谱,欢迎感兴趣的人联系我合作。 Jan: (问题和引导性发言,未形成核心论点)

Deep Dive

Chapters
This chapter introduces knowledge graphs, their history, and their resurgence in the age of AI and LLMs. It explains how knowledge graphs organize data semantically, adding meaning beyond traditional relational databases, and forming a graph structure that facilitates knowledge representation.
  • Knowledge graphs organize data semantically, adding meaning beyond traditional relational databases.
  • The structure of knowledge in a knowledge graph is in the form of a graph.
  • Ontologies assign meaning to attributes in the metadata space, transforming information into knowledge.

Shownotes Transcript

您好,欢迎回到另一期《真实世界无服务器》节目。今天我们邀请到了 Aniket Dmitra,他是 SaveA 的创始人,这是一家专注于 AI、ML 和数据工程的软件公司。他一直在围绕知识图谱和大型语言模型做一些非常有趣的工作。Aniket,欢迎来到节目。谢谢 Jan,我很高兴来到这里。

是的,我通过我们共同的朋友 Daniel Lu 了解到你的工作,最近我也遇到了一些人谈论将知识图谱与大型语言模型结合使用。这是你投入大量时间研究的东西。我想让你来节目中谈谈它是什么,什么是知识图谱,以及它如何帮助我们现在正在使用的 AI 和大型语言模型。在……

在我们开始之前,你想花点时间谈谈你在 SaveA 的工作,以及你的历史和背景吗?

是的,当然。正如你所说,我现在是 Saveway 的创始人。我们在 Saveway 做的事情基本上是执行那些计算科学密集型的项目。这就是我们的想法。但是,你知道,更具体地说,是在 AI、ML、数据工程和数据科学等分支领域。

基本上,你知道,我的背景长期以来一直是在 YAML 的数据科学领域。更具体地说是在知识图谱方面,因为在过去的几年里,我主要参与为企业客户构建企业知识图谱,这些客户来自,你知道,地图空间的客户,

基本上是基于位置的服务。目前,我正在执行需要再次为大型零售客户构建知识图谱的项目,例如。

好的,明白了。是的,谈到知识图谱,我知道它们已经存在相当一段时间了。我记得上次它们进入主流意识的时候是 Web 2.0 和整个语义网出现的时候。我和一个人谈过,我现在忘了他的名字了,他非常重视这个镜像世界的想法,你基本上构建了一个元宇宙,好吧,

不是元宇宙,而是像现实世界属性等的映射,建筑物、位置,这样你就可以开始查询关于现实世界中发生的事情的信息并将它们连接起来,基本上衡量一项活动对另一项活动的影响。我们已经看到一些软件具有这样的功能,

我想像 Palantir 这样的公司正在为国防等领域构建,但也许在像你我这样的人每天使用的普通意义上并非如此。所以是的,知识图谱,告诉我们它是什么。它的历史背景是什么?今天发生了什么?

是的,当然。而且,你知道,正如你提到的那样,知识图谱已经存在很长时间了,或者至少知识图谱的想法已经存在很长时间了。因为在某个时候,它的起源或核心思想是能够组织数据,例如。有人可能会说,好吧,当我们,你知道,以我们知道的方式组织数据时,好吧,每条记录都是属性的集合,例如,或与属性关联的值,当你以表格行的形式表示它时,这就是,你知道,事实上的传统组织形式,但这通常不允许你能够添加

添加语义含义,例如。所以这通常意味着,如果我正在记录教室里学生的相关信息,并且我有关于他们成绩的信息,你知道,他们所上的课程,这些都是属性。但是

现实世界中“成绩”是什么意思?所以你接下来想要做的本质上是将含义与“成绩”这个属性关联起来。所以成绩是一个值,或者成绩是与课程相关的属性,例如。

现在,课程是一个无形的项目,它也是事物的子类,例如。所以成绩也与课程相关,但课程也有名称,名称也与某些东西相关。它可能是与某个其他类相关的名称,该类又是事物的子类。所以本质上,当你开始绘制出来,或者如果你花点时间开始思考它,你会看到它的演变方式是图的形式,对吧?所以你会看到,你知道,多条路径从一个概念产生,然后它们在某个时候在更高层次上再次连接。所以当你向上

向上移动属性空间,并开始为该属性空间赋予意义时,它的自然形式或自然结构就是图的形式。这就是语义概念发挥作用的地方。我们在知识图谱空间中所说的概念是本体的概念。所以当你看到这种组织方式时,你也能

不仅能够附加记录内容的含义,还能够附加未明确记录内容的含义,例如。这就是你逐渐将信息转化为知识的地方。这就是这两件事发挥作用的地方:你现在能够以知识的形式组织信息,而这种知识的结构是图的形式,本质上就是这样。这就是你得到知识图谱概念的原因。

好的。是的,本体,这是我很久没听到的词了。你能提醒我一下它是什么意思吗?

是的。所以每当我们谈论语义,通常情况下,以及关联含义的整个想法,例如,对吧?所以这被定义为词汇表。词汇表就像,好吧,当你提到“成绩”时,成绩是什么意思?以及成绩,你知道,在现实世界中,它的等级组织结构,例如。这就是本体所定义的。本体也可以是通用的,例如 schema.org,但它们也可以是非常特定于领域的。例如,你在医学领域有本体,你在零售领域有本体。但核心思想是能够评估

分配或关联元数据空间中的含义,例如。这就是本体的概念。它允许你赋予“成绩”的概念、例如“名称”的概念、例如“人”的概念以意义。通常,如果你查看本体,本体,因为它试图赋予意义,它采用图的形式。

在 Excel 中。好的,明白了。当谈到图时,显然我认为你之前暗示过,以关系表的形式表示数据和关系的传统方式并不够用。这就是我认为图数据库发挥作用的地方,并且

图数据库,我很喜欢它们。我过去使用过像 Neo4j 这样的图数据库,并且我很喜欢你可以做的事情,你可以运行的查询类型。这简直令人难以置信。你可以对你的整个图进行模式匹配,并找到具有特定关系的事物。而且,就像你说的那样,我认为你不仅能够在实体本身上添加属性,还能够在实体之间的关系上添加属性。这是……

是的。

变得非常强大。我认为你提到了它。你可以标记无形的事物,例如关系以及它们如何连接到两个不同的实体。你可以在该关系本身上拥有属性,你实际上可以根据关系上的这些属性以及实体进行查询。告诉我们一些关于图数据库的信息,你在使用知识图谱方面使用它们的经验是什么?

它们与关系数据库有何不同?是的,当然,而且,你知道,图数据库,当你查看图数据库时,存在一个子分类,因为创建知识图谱的传统形式通常总是在资源描述框架的类别下,本质上是 RDF,例如,对吧?任何本体,如果你拿起任何本体,它都存在。大多数这些本体基本上都属于 RDF 的类别。RDF 是通过

以三元组的形式组织概念,对吧?你有一个主体,你有一个对象,你还有一个主体和对象之间的关系,它以谓词的形式存在,例如,并且有一些图数据库支持这种 RDF 格式,例如,但是问题是你自然会看到,当你开始组织这些东西时,你知道,以三元组的形式,突然你需要开始建模的节点和关系的数量

只是激增,变得难以管理,例如。因此,对于非常简单的数据集,例如,数量级为几千个,你将获得的节点和关系的数量将达到百万数量级,例如。这就是你将看到的比例激增。

所以,你知道,作为后续,像 Neo4j 这样的图数据库所做的是,他们说,好吧,你需要将所有内容都表示为单独的节点吗,例如,对吧?例如,说一下课堂上的学生概念,其中,你知道,学生有姓名,学生有成绩等等。是否必须将它们中的每一个都表示为单独的节点,或者可以将这些信息折叠到一个单一节点中?

或一组节点,例如。这就是标签属性图的概念的来源,其中它们允许你附加,你知道,

节点本身的属性或标签,其中你知道每个标签或属性到节点的映射并非总是 1:1,所以一个节点可以映射到多个属性,例如,而且正如你所强调的那样,好吧,你也可以开始拥有关系属性,例如关系,对吧?所以这增加了另一层好处,因为检索变得更容易,例如,所以

Neo4j 实际上允许我们在图数据库领域进一步优化此模型,以实现更有效的表示以及检索。当然,它与众不同之处在于,你现在能够

建模语义,当你能够建模语义与关系数据库形成对比时,你也能捕获未明确提及的事物,例如。但同样重要的是要知道,当你开始在大型规模、企业范围内构建知识图谱时,

将知识图谱视为一站式解决方案通常是一个坏主意。它擅长做一些事情,但它并不应该擅长做所有事情,例如。例如,如果你想进行快速文本搜索,你仍然会使用像 Elasticsearch 这样的东西,它非常擅长做这种工作。所以整个想法是,当你查看时

整体系统架构,你将知识图谱视为整体架构中的一个组件,它与其他组件一起支持一系列用例,而不是,你知道,作为……

所有事物的实际替代品,因为从某种意义上说,这是一种设计失误。因为你会看到,如果你想做,比如说非常高级的文本搜索,也许图数据库不是你想要的,因为性能问题。

对,是的。我认为你正在谈论图数据库与大型语言模型的用例。但在我们讨论这个之前,我记得当向量数据库成为 RAC 等事物出现时,

它解决的一个问题是最近邻问题。这是一个遍历问题,在其他类型的数据库中通常很难实现。但我清楚地记得,当我第一次发现图数据库时,这是经典示例之一,好吧,

这类问题使用图数据库很容易实现,因为你从中心点开始查找最近邻,它只是遍历图。

它实际上是下一步,然后是下一步,然后直到你找到一个匹配你条件的节点。在 Neo4j 的 Cypher 中,他们实际上有一个示例向你展示,好吧,一个节点与一些,我想,我忘了语法,基本上表示这两个节点之间的任意数量的节点,只要这两个节点具有他们正在寻找的正确属性,例如学生和班级,那么你就可以找到一个

匹配该语法的图的一部分,这基本上解决了你的最近邻遍历问题。所以当数据库成为一个事物时,哦,是的,人们一直在谈论的事情是它非常擅长查找最近邻,我在想,是的,但图数据库也是如此,为什么没有人使用它们?所以……

你谈到了在大型语言模型方面如何使遍历更容易,但也谈到了在原始数据方面如何捕获更多上下文。那么,你能告诉我们你是如何将图数据库和知识图谱与大型语言模型一起使用的,以及它如何融入整个生态系统吗?

是的,当然。而且,你知道,只是为了继续你提到的那个思路链,那就是,你知道,如果……

因为知识图谱甚至在我们拥有嵌入概念之前就已经存在了。正如你提到的那样,Jan,最近邻仍然会完成,但这将是事物如何在数据库中组织的函数,而不是通常在高维向量空间中的语义相似性。

但发生的情况是,如果我们将此视为两个极端,其中我们说我们只根据基于嵌入的表示进行语义相似性,

仍然会缺少某些东西,因为这些东西很容易作为图形式中事物的自然组织的一部分来完成,例如。如果你采用另一个极端,例如,当你这样说,“我永远不会使用基于嵌入的系统,我只会使用基于图的系统”,你将能够找到相似性,这是图中连接性的函数,例如。但是,基于图节点上的属性的相似性呢,例如?

对。因为这不是你仅基于连接性就能建模的东西,例如。所以发生的一件非常好的事情是,由于嵌入的出现,或者基于向量的相似性搜索,我们越来越多地看到这两个领域走到一起。对。并且一个能够从另一个中获益。

当你尝试时,当你实际开始在该空间工作时,当你使用嵌入来查找属性值的相似性时,例如,并且你还使用知识图谱来增强基于图拓扑的最近邻搜索,基于图的连接性,你开始看到非常好的结果,例如。所以它基本上是两者的结合。是的。

- 是的。- 好的,让我消化一下,看看我是否可以用我自己的话说清楚。你所说的意思是,对于向量数据库,对于大型语言模型查看数据的方式,它会看到,我想,更多的是相关性。如果两个词通常彼此相邻出现,那么在向量空间中,它们被认为彼此接近。

因此,当你进行嵌入并进行回归时,你知道,你正在查看数据并创建数据的向量空间,不同数据点之间的关系是基于它们在源数据中出现的形式。但这并不一定代表两个节点之间的语义距离,它们可能不会一起出现,你知道,在 JSON 格式中。

训练数据中的位置,但从语义上讲,它们是相似的。因此,你可以使用图数据库捕获这种语义相似性

但你无法捕获,我想,图数据库中训练集相似性方面的标记在数据中出现的顺序。这是正确的吗?理解?绝对正确。看看你是如何组合它们的。

也可能你说得对。我可以,因为图神经网络的概念已经存在相当一段时间了,对吧?所以当你根据图的结构生成嵌入时,例如,对吧?所以你可以考虑再次在嵌入空间中组合它们,对吧?你根据值本身获取嵌入,你还获取基于结构本身的嵌入,然后你将它们组合起来。但在某种程度上,这种组合对于你试图解决的问题是必要的,以产生或提取最大收益。因为否则,如果你查看任一极端,每一侧都只能让你走这么远。

对,对。好的,很有趣。好的,在这种情况下,你能带我们了解一个示例问题以及你如何将它与大型语言模型一起应用,作为,我想,作为增强检索的一部分吗?在处理用户查询或处理数据时,图数据库在哪个步骤中出现?向量数据库在哪个步骤中出现?

是的,当然。所以,你知道,我会以,你知道,位置领域或我在之前工作中构建知识图谱的领域的例子为例。所以想象一下,你知道,你正在收集某个城市餐馆的信息,例如,对吧?现在你有了关于这些餐馆的信息。例如,餐馆的类别是什么,从某种意义上说,你知道,它提供哪种类型的菜肴,例如。

这家餐馆的评价是什么?你知道,这家餐馆的文字描述是什么,例如,对吧?此外,这家餐馆是如何与其他兴趣点(POI)相邻的?例如,附近是否有停车场?它离主要高速公路有多远,对吧?所以当你开始查看所有这些信息时,有些事情,你知道,例如餐馆的描述,纯粹是文本数据,例如,对吧?比如说,这家餐馆菜单上有什么,这也是文本信息,例如,所以通常能够找到

例如,两家餐馆在菜单上提供的食物之间的语义相似性。也许你可以通过更好的数据库来做到这一点,对吧?所以当你分别为两者创建嵌入时,例如,并且你试图查看两者之间的相似性。

但事实是,好吧,比如说,你知道,如果两家餐馆属于同一菜系子类别,例如,对吧?那么还有餐馆的类别层次结构,对吧?例如,菜系。餐馆与停车场的距离。这是一种关系,这是停车场和餐馆之间的语义关系。并且

最好始终以图的形式建模,在知识图谱中,例如。现在,当你建模了这一点,并且有人从最终用户的角度提出这个问题时,我正在寻找一家提供,我不知道,也许是三明治的餐馆,例如,但我可以在餐馆附近停车。

所以能够在餐馆附近找到停车位,例如,这种信息,两个实体之间的语义关系,将来自知识图谱。

你正在寻找三明治,例如,这将来自基于向量的语义相似性搜索。然后能够将两者结合起来。所以这基本上是你开始尝试建模并查看什么适合什么的信息,本质上就是这样。对,好的。所以,在这种情况下,当你构建提示时……

作为回归的一部分。所以你首先查询图数据库,了解应该作为查询一部分包含的不同实体,然后作为问题的一部分,你包含从你检索到的向量数据库中获取的文档并将其发送给大型语言模型。它是这样工作的吗?这些是步骤吗?

好吧,现在我们已经讨论了组织。现在让我们谈谈,你知道,通常当查询进来时,有一个非常重要的部分,那就是查询解释,对吧?大型语言模型在这方面发挥着非常重要的作用。这也与我们开始讨论的观点相关,那就是发生了什么变化,你知道,知识图谱已经存在这么久了,但在过去的几年里,我们看到人们对知识图谱越来越感兴趣,例如,知识图谱的一个更大的问题,

挑战始终是,好吧,当你能够并且当你这样说时,我已经将信息转化为知识,其中一个自然的延伸是,你想开始

你知道,与该系统进行对话,你想问它更多上下文问题,而不是,你知道,基于文本的搜索,例如,对吧?所以这通常是你通常会在信息检索中做的下一步,但能够在信息检索方面做得很好,不仅仅是组织数据的问题,还在于能够理解用户在寻找什么

所以用户查询中隐藏的上下文是什么?所以这是一个查询解释层,例如,对吧?所以接下来变得也很重要,并且从今天开始正在发生的事情是,这一层大型语言模型实际上能否理解,第一步能否理解用户在寻找什么。在我们的例子中,用户正在寻找靠近停车位的场所。

用户正在寻找特定类型的,你知道,食物,例如三明治。现在可能是不同菜系的不同种类的三明治,例如,但这另当别论。然后一旦你完成了这种解释,这通常意味着你已经将你的查询分解成结构化形式。

然后你将有一组代理,基本上,或者可能是一个代理,它实际上充当某种调度程序。这就是为什么你今天看到这个多代理系统的整个主题,对吧?当你将该查询调度到一个时,基本上你进行查询解释,你将其发送给一个代理,然后该代理知道它应该根据什么调度查询,或者应该从查询的哪个部分获取最佳信息。

因为你知道这种路由信息是该代理的一部分,本质上就是这样,所以它现在会知道,靠近停车场,它最好从知识系统中检索该信息,你知道,关于,你知道,例如,什么最接近……

语义上类似的食物或三明治的表示,它会转到向量数据库,从两者中提取信息,将它们组合在一起,然后给你结果,例如,这是一种方法,还有其他方法,其中我们说,看,我们不需要,你知道,调度机制,但我们有一个共同的

共同的,比如说,从两者生成的嵌入,一个是从组织或你知道事物的连接性生成的,一个是事物的语义表示,例如,然后你将它们组合成一个共同的嵌入,然后你只需点击该嵌入并从中获取信息,所以这变成了第二个,你知道……

典型的 RAD,例如,它结合了这两者。嵌入是两者的组合或函数。第一个是作为下一步,本质上,其中你实际上使用多代理系统从专门的信息源获取信息。

好的,好的。我仍然难以想象所有事情发生的实际流程。所以想象一下,我要……好的,我使用的一个例子是我去谷歌地图搜索。我想吃一些……

比如说,中国糕点,例如。去谷歌地图并输入“中国糕点”。它会显示很多或多或少相关的项目。有些完全不相关。那么,我们如何在你的地图示例中结合使用向量数据库和图数据库——当用户输入,比如说,“中国糕点”时,我们如何结合使用两者?

到你的聊天机器人中,是的,所以,比如说,中国糕点可能是一个基本的例子,因为这是你想要……比如说,当你想要使用这种系统时,作为用户,这是一个正在进行的活跃研究领域,那就是你如何帮助用户过渡到一种状态,在这种状态下,他们可以提出更多

更多对话式的问题,例如。所以与其问“中国糕点”,不如说“周五晚上的中国糕点”,例如,对吧?所以你需要,系统需要理解两件事。当然,中国糕点,哪些餐馆在周五晚上营业,以及这些餐馆在周五晚上的入住率是多少,例如。所以解码必须发生

成一种形式,你知道,所有这些信息,首先,这些信息的解释,然后是这些信息的提取。所以现在,比如说,你知道,让我们从中国糕点开始,例如。所以当你到谷歌地图上搜索中国糕点时,例如,一件简单的事情就是,你知道,只是进行传统的文本搜索,例如,对吧?这意味着,好吧,你正在寻找中国糕点。你会进行基于文本的匹配,然后它会给你一些东西,无论它是否存在。

但是有了更语义化的搜索,你也能弄清楚与中国糕点类似的其他东西是什么,例如。也许是包子,例如,或者其他东西。但也许是在中国菜中,例如。中国糕点的特定项目。

是的,但是现在的问题是,当你进行语义搜索时,你是否应该只获取与糕点语义上相似但在中国菜系中的结果,或者你是否也应该显示糕点,比如说法国糕点,例如。

现在,如果你真的想这么做,当然可以,你可能可以在嵌入式生成的过程中添加约束条件,并对其进行建模。但你也可以简化它,说,你看,我能够识别出“中国菜”是一种食物类别,对吧?所以我将使用知识图谱只查找属于中国菜类别的食物信息。

而Piece Tree是我将在其上进行语义搜索的东西。所以你会做的是,你会使用向量搜索找到语义上相似的结果。但在这种情况下,你将使用知识系统或知识图谱在其之上构建约束条件,并开始过滤信息,而不是例如处理层。

好的。好的。明白了。是的。因为这是我一直在使用诸如在谷歌地图上搜索特定食物菜系时遇到的问题之一。我认为他们没有设置约束条件。所以你只会得到,好的。糕点或中餐馆。他们从未真正理解查询的上下文,即我正在寻找一种特定的菜系。

一种特定类型的菜系内的食物。所以它没有使用,就像我说的,使用中国菜类别来限制返回的结果。所以我想在这种情况下,你会说知识图谱与LLMs目前的最新技术是什么?我们还能在这方面走多远?

是的,许多核心问题也正在得到解决,或者至少我们设想它将会得到解决。一件事是,当你构建知识图谱时,有两个部分。一个是能够将信息导入知识图谱。这总是很不容易的。这就是知识图谱作为主流系统被采用的原因。

例如,之所以很棘手,是因为你如何确保首先,你可以持续不断地添加信息,例如,其次,还要保持信息的完整性。所以这些通常是两件事。

随着LLMs的出现,开始发生的事情是本体论,通常情况下。因为如果你正在构建一些非常通用的东西,例如,你可以使用通用的本体论。但如果你想为一个非常专业的领域构建一些东西,例如,比如说在医疗领域,或者甚至在位置空间,例如,

本体论必须专门针对该领域进行专门化

而本体论的专门化,这是一项前期耗时的工作。例如,没有很多自动化的方法可以做到这一点。当,比如说,额外的信息开始出现,例如,在医疗领域,如果某个疫苗或药物的某个试验有新的出版物,例如,你如何引入这些信息?

并且仍然能够在您可能需要扩展本体论的约束条件下将该信息引入知识图谱,因为你知道本体论本身并不是有限的,对吧,所以本体论也会随着时间的推移而增长,这取决于信息是如何传入的,所以

传统上,这很大一部分是通过大量人工干预来完成的。现在随着NLMs的出现,你可以开始做的是,因为你可以倒退一步说,好吧,我可以使用本体论对输入数据源进行某种类型的rag吗?或者说,你看,我有本体论。这就是我组织事物的方式。

这是源信息,将两者都提供给LLM,并告诉LLM现在将输入源中的信息结构化为这种形式。

这就是,你知道的,当然,它会完全自动化吗?不会,因为你仍然需要护栏。例如,你仍然需要监督。但是很多前期的手工工作将开始消失,这样你就可以开始,你知道的,以更半自动化的方式管理本体论,例如。所以这是一个,你知道的,利基部分,我认为,我们正在关注的,其中我们可以,或者我们正在关注的最新技术是,你如何开始构建

例如,更半自动化的本体论管理与LLMs。这是一个。另一方面是典型的查询解释,对吧?

即使几年前,如果你有一个LLM,例如,构建查询解释层并非易事。你必须付出很多努力来构建查询解释层。并从复杂性方面考虑一下,如果你必须进行多语言处理,如果你必须进行多脚本处理,例如。所以它增加了这些复杂性层。

现在,很多这样的努力。所以如果你实际上正在构建一个知识图谱,通常你的努力分配将是,在早期,比如说50%,我会说50%到60%的知识,构建知识图谱本身。但其余的50%或40%也将用于查询解释系统。

在构建实际识别、理解“中国糕点”查询并将其分解为结构化形式的查询解释系统中。

今天,这个等式正在发生变化,例如,因为现在发生的事情是,你可以更多地关注构建知识图谱的部分,真正将其设计成一个合适的系统。查询解释部分,你可以将很多工作卸载到LLM上,并说,好吧,因为LLM具有能够理解“中国空间树”是什么意思的知识,例如。

如果它仍然没有,你仍然可以进行一个小小的转换或采取一个小的迭代步骤,并说,好吧,我会提示LLM。

根据我目前拥有的信息。我有关于糕点的类别信息,这些糕点出现在哪些不同类型的菜系中,然后将其作为提示提供给LLM,然后我们实际上看到LLM仍然能够很好地解释查询,并将其分解成两个子部分,说中国是一个食物类别

糕点是一种特殊类型的食物,例如。正在发生的事情是,用户正在寻找中国菜类别的糕点。这通常是LLM能够做到的事情。

但是,在某些情况下,你又需要非常专业的知识,例如,LLM必须经过微调。你不能仅仅通过提示工程的迭代步骤或依赖于专业或通用LLM来做到这一点。因此,你必须开始根据该领域的知识对LLM进行微调。

那么,你如何微调LLM以更好地进行,例如,查询解释呢?所以这些是,你知道的,我认为是其中的一些研究课题或方向,至少业界正在向前发展。是的。是的。

是的,你描述的是,我当时只是在想,因为你谈到了本体论,你谈到了知识图谱,我认为这些都是非常特定于领域的,你知道的,问题,并且

而RAG通常是,好吧,我想RAG可能不是针对特定领域的。它可能对使用一些额外的信息数据扩展LLM很有用。但是如果你想要一些真正针对特定领域的东西,你确实需要微调。在这种情况下,你是否看到了一些使用RAG的例子

人们是否也使用微调来做这件事?这是否是使用知识图谱来识别哪些文档以及哪些信息进入微调过程的情况,这样你就不会过度调整,不会将过多的数据放入微调过程?

- 这是一个非常好的问题,因为这也是我们一直在关注的事情。看,你遇到的任何这些LLMs中非常重要的一件事是上下文长度的问题,例如,对吧?如果你试图使用大型文本文档来提示工程或微调LLM,你就会遇到上下文长度的问题。但是想象一下,如果你能够将文本文档或文本

形式的文档分解成更结构化的形式。

分解成主语、宾语和谓语的简单组织,你已经在很大程度上减少了上下文长度的要求,因为你已经能够压缩这些信息,因为你已经能够对其进行组织。然后你能够向LLM提供更多压缩的信息,例如,这也对LLM的微调速度或效率有多快或多高有影响,例如,所以这也会在那里产生影响,因为现在不是传递它,呃,你知道,句子可能是

我不知道,一千个字符长,你正在向LLM发送信息或提供信息,它非常小,可以认为是小短语。所以,你知道的,如果我们必须做一个思想实验,如果你能够用短语而不是句子或一系列句子来微调LLM,那么基于短语的微调显然会更有效。

在某种程度上是有效的,对吧?由于所有这些原因。所以是的,绝对的。这又是原因之一,或者你可能我们所有人都会看到的一件事,也可能是知识图谱在过去变得如此流行的原因,每个人都在谈论它,那就是你可以通过简单的组织来绕过微调的约束。

好的。而且你提到的,你可以使用LLMs将输入数据组织成知识图谱,并使其更容易以更好、更自动化的方式处理输入数据。感觉这就像一个

递归效应,你可以拥有更好的LLMs来将输入数据组织成知识图谱,然后使用知识图谱使微调更有效,并产生更好的微调模型。然后你可以再次使用它来更好地将源信息组织成知识图谱。

我想,我的意思是,这可能需要迭代微调模型的成本,但这感觉就像是你可能导致逐步提高微调模型质量的路径。是的。

是的,绝对的。但问题是,这需要弄清楚的是,成本方面的比较是什么?所以用大型文档微调模型到底需要多少成本,而用这种形式组织的更结构化的信息微调模型需要多少成本?你得到的抵消,

它是否足够好,以至于你仍然能够承担这种开销,或者能够再次使用LLM并进行这个递归过程或迭代过程,其中你回到源头,使用LLM再次以结构化形式提取信息,将其带入并找出你知道什么地方错了,然后再次将其提供给LLM,例如,但你说的很对,这

有一个闭环,对吧?你实际上根据知识图谱的信息进行微调的LLM,该LLM实际上再次用于提取信息,以非结构化数据的形式、不同类型的文档以及所有信息的形式出现的信息,从中提取结构化形式的信息,并将其带入知识图谱,这又将进入LLM进行微调。是的。

谢谢你,Aniket。这真的,真的很有趣。我还没有,我想我还没有听到太多关于人们如何将知识图谱用于LLMs的信息。首先,一些,你知道的,顶级,高级LLMs

提到了这一点,但从未像详细介绍它可能是什么样子那样,但是,非常感谢你的时间,在我们离开之前,你有什么想与我们分享的吗?任何即将开展的工作,也许你在我们开始录音之前提到了

你正在寻求扩展你的业务。你有什么想在方面提到的吗?你知道的,如果有人想与LLMs一起研究知识图谱,他们如何联系你,也许加入你的公司?

是的,绝对的。因此,我们正在积极地处理许多这样的问题。例如,能够使用本体论从源系统中提取信息,当源信息以文本文档的形式出现时,那么你如何对其进行结构化?例如,你如何更好地进行查询解释?

这些是我们目前正在积极开展的工作产品。因此,如果你的听众中有任何人感兴趣,如果他们想合作,我们将非常乐意与他们合作。好的。那么人们在哪里可以找到你,并了解更多关于你正在做的事情的信息呢?

是的。所以我想目前最好通过我的电子邮件ID联系我。根据这个,你知道的,我们可以看看接下来的步骤是如何发展的。是的。

好的。好的。我会将这些信息包含在节目说明中,因此任何感兴趣的人都可以联系你,并讨论你们如何一起合作。所以,Enneket,再次非常感谢你,我希望你一切顺利,我希望下次再见到你。谢谢你。非常感谢,Ian。感谢你邀请我参加节目。不用客气。还有其他人,下次再见。好的。再见。

这就是另一集《真实世界无服务器》的全部内容。要访问节目说明,请访问realworldserverless.com。如果你想学习如何构建可用于生产的无服务器应用程序,请查看我在productionreadyserverless.com上即将推出的课程。下次再见。