告别传统 RAG,迎接 GraphRAG:知识图谱+本体=更强 AI

发布于 2025-9-17 00:01
浏览
0收藏

现代 AI 聊天机器人常常依赖 Retrieval-Augmented Generation (RAG),也就是检索增强生成技术。这种技术让机器人能从外部数据中提取真实信息来支撑回答。如果你用过“与你的文档聊天”之类的工具,你就见过 RAG 的实际应用:系统会从文档中找到相关片段,喂给大语言模型(LLM),让它能用准确的信息回答你的问题。

RAG 大大提升了 LLM 回答的事实准确性。不过,传统 RAG 系统大多把知识看成一堆互不关联的文本片段。LLM 拿到几段相关内容后,得自己把它们拼凑起来回答。这种方式对简单问题还行,但遇到需要跨多个来源串联信息的复杂查询,效果就不理想了。

这篇文章会深入浅出地解释两个能让聊天机器人更上一层楼的概念:ontologies(本体论) 和 knowledge graphs(知识图谱),以及它们如何与 RAG 结合,形成 GraphRAG(基于图的检索增强生成)。我们会用简单的语言说明它们是什么,为什么重要。

为什么这很重要?你可能会问。因为 GraphRAG 能让聊天机器人的回答更准确、更贴合上下文、更有洞察力,比传统 RAG 强多了。企业在探索 AI 解决方案时很看重这些特质——一个真正理解上下文、避免错误、能处理复杂问题的 AI 可以彻底改变游戏规则。(不过,这需要完美的实现,实际中往往没那么理想。)

通过把非结构化文本和结构化的知识图谱结合起来,GraphRAG 系统能提供感觉上更“有学问”的回答。把知识图谱和 LLM 结合起来,是让 AI 不仅能检索信息,还能真正理解信息的关键一步。

什么是 RAG?

Retrieval-Augmented Generation,简称 RAG,是一种通过外部知识来增强语言模型回答的技术。RAG 系统不是仅靠模型记忆里的东西(可能过时或不完整)来回答,而是会从外部来源(比如文档、数据库或网络)抓取相关信息,喂给模型来帮助生成答案。

简单来说,RAG = LLM + 搜索引擎:模型先检索支持数据,增强对主题的理解,然后结合内置知识和检索到的信息生成回答。

告别传统 RAG,迎接 GraphRAG:知识图谱+本体=更强 AI-AI.x社区


如上图所示,典型的 RAG 流程包含几个步骤,就像一个智能查找过程:

1.索引知识:系统先把知识来源(比如一堆文档)分成小块文本,为每块生成vector embeddings(向量嵌入)。这些嵌入是文本含义的数字表示,存进一个向量数据库或索引中。

2.查询嵌入:用户提出问题时,查询也会用同样的技术转成向量嵌入。

3.相似性搜索:系统把查询向量和存储的向量对比,找出与问题最“相似”或相关的文本块。

4.结合上下文生成:最后,语言模型拿到用户问题和检索到的文本片段作为上下文,生成包含这些信息的回答。

RAG 让 LLM 在现实场景中变得更实用。像 Bing Chat 或各种文档问答机器人就是靠 RAG 提供最新、具体的答案,还能附上参考资料。通过用检索到的文本来“锚定”回答,RAG 减少了 hallucinations(模型瞎编),还能访问超出 AI 训练截止日期的信息。不过,传统 RAG 也有一些明显的局限:

  • • 它把检索到的文档基本上当作独立的、非结构化的文本块。如果回答需要综合多个文档的信息或理解它们之间的关系,模型得在生成时自己完成这个重活。
  • • RAG 的检索通常基于semantic similarity(语义相似性)。它能找到相关段落,但不一定理解内容的真正含义,或者一个事实如何与另一个事实关联。
  • • 没有内置机制来推理或确保检索数据的一致性;LLM 只是拿到一堆文本,尽力把它们串起来。

在实际中,对于简单的事实查询,比如“这家公司什么时候成立的?”,传统 RAG 表现很好。但对于复杂问题,比如“比较第一季度销售和营销支出的趋势,并找出相关性”,传统 RAG 就可能掉链子。它可能返回一段关于销售的文本,另一段关于营销的,但逻辑整合得靠 LLM 自己来,可能不一定能连贯成功。

这些局限性指向一个机会。如果我们不只是给 AI 一堆文档,而是再给它一个 knowledge graph(知识图谱),也就是实体和它们关系的网络,作为推理的框架呢?如果 RAG 检索不只是基于相似性返回文本,而是返回一组相互关联的事实,AI 就能顺着这些联系生成更有洞察力的回答。

GraphRAG 就是把基于图的知识整合进 RAG 流程。通过这样做,我们希望解决上面提到的多来源、歧义和推理问题。

在深入 GraphRAG 的工作原理之前,我们先搞清楚 knowledge graphs(知识图谱) 和 ontologies(本体论) 是什么——它们是这种方法的基础。

知识图谱(Knowledge Graphs)

知识图谱 是一种对现实世界知识的网络化表示,图中的每个 node(节点) 代表一个实体,每条 edge(边) 代表实体间的关系。

告别传统 RAG,迎接 GraphRAG:知识图谱+本体=更强 AI-AI.x社区


如上图所示,知识图谱以图的形式组织数据,而不是表格或孤立的文档。这意味着信息天然就捕捉了联系。一些关键特点:

  • 灵活性:你可以随时添加新的关系类型或实体的属性,不会搞乱整个系统。图可以轻松扩展以适应新知识。
  • 语义化:每条边都有含义,这让沿着图遍历并提取有意义的推理链成为可能。图不仅能表示内容,还能表示上下文。
  • 支持多跳查询:如果你想知道两个实体如何关联,图数据库可以遍历邻居、邻居的邻居,依此类推。

知识图谱通常存储在专门的 graph databases(图数据库) 或 triplestores(三元存储) 中。这些系统专为存储节点和边、运行图查询而优化。

知识图谱的结构对 AI 系统(尤其在 RAG 场景中)是个大加分项。因为事实是相互关联的,LLM 能拿到一整个相关信息的网络,而不是孤立的片段。这意味着:

• AI 系统能更好地消除歧义。比如,如果问题提到“Jaguar”,图可以通过关系明确是汽车还是动物,提供文本单独无法给出的上下文。

• AI 系统可以通过“连接”或遍历收集相关事实。图查询可以提供一个全相关的子图,而不是零散的段落,为模型提供一个预先拼好的拼图,而不是单个碎片。

• 知识图谱保证一致性。比如,如果图知道产品 X 包含部件 A 和 B,它就能可靠地只列出这些部件,不像文本模型可能会瞎编或漏掉信息。图的结构化特性让事实的聚合更完整、更准确。

• 图通过追踪推理链的节点和边提供explainability(可解释性),让推理过程清晰,增加答案的可信度。

总结来说,知识图谱为 AI 的上下文注入了意义。它不是把数据当一堆词袋处理,而是当作一个知识网络。这正是我们希望 AI 在回答复杂问题时拥有的:一个可以导航的、丰富的关联上下文,而不是每次都要硬解析一堆文档。

现在我们了解了知识图谱是什么,以及它如何助力 AI 系统,接下来看看 ontologies(本体论) 是什么,以及它们如何帮助构建更好的知识图谱。

本体论(Ontologies)

在知识系统的语境中,ontology(本体论) 是一个特定领域的知识的正式规范。它定义了该领域中存在的实体(或概念)以及这些实体之间的关系。

告别传统 RAG,迎接 GraphRAG:知识图谱+本体=更强 AI-AI.x社区

本体论通常将概念组织成层级或分类体系,但也可能包含逻辑约束或规则。比如,可以声明“每个订单必须至少包含一个产品项目”。

为什么本体论重要?你可能会问。本体论为一个领域提供了共享的理解,这在整合多个来源的数据或构建需要推理该领域的 AI 系统时特别有用。通过定义一组通用的实体类型和关系,本体论确保不同团队或系统用一致的方式指代事物。比如,如果一个数据集把人叫“Client”,另一个叫“Customer”,通过映射到同一个本体论类(比如 Customer 作为 Person 的子类),就能无缝合并这些数据。

在 AI 和 GraphRAG 的语境中,本体论是知识图谱的蓝图——它决定了图中会有哪些节点和链接。这对复杂推理至关重要。如果你的聊天机器人知道在你的应用中“Amazon”是一个 Company(公司)(而不是河流),而 Company 在本体论中有定义(包含 headquarters、CEO 等属性,以及 hasSubsidiary 等关系),它就能更精确地锚定答案。

现在我们了解了知识图谱和本体论,来看看如何把它们整合进类似 RAG 的流程中。

GraphRAG

GraphRAG 是传统 RAG 的进化版,它明确将知识图谱纳入检索过程。在 GraphRAG 中,用户提问时,系统不只是对文本做向量相似性搜索,还会查询知识图谱中相关的实体和关系。

告别传统 RAG,迎接 GraphRAG:知识图谱+本体=更强 AI-AI.x社区


我们来高层次地走一遍典型的 GraphRAG 流程:

1.索引知识:输入包括结构化数据(比如数据库、CSV 文件)和非结构化数据(比如文档)。结构化数据通过数据转换,将表格行转为三元组。非结构化数据被拆成可管理的文本块,从中提取实体和关系,同时计算embeddings(嵌入),生成带嵌入的三元组。

2.问题分析与嵌入:分析用户查询,识别关键术语或实体,用相同的嵌入模型将这些元素转为嵌入。

3.图搜索:系统查询知识图谱,找到与关键术语相关的节点,不只是检索语义相似的项目,还利用关系。

4.结合图上下文生成:生成模型使用用户查询和检索到的图增强上下文生成答案。

在底层,GraphRAG 可以用多种策略整合图查询。系统可能先做常规的语义搜索,找 top-K 文本块,然后遍历这些块的图邻居以收集额外上下文,再生成答案。这确保了即使相关信息分散在不同文档中,图也能把它们拉到一起。在实际中,GraphRAG 可能涉及额外步骤,比如 entity disambiguation(实体消歧)(确保问题中的“Apple”链接到正确的节点,可能是公司或水果)和图遍历算法来扩展上下文。但总体思路如上:搜索 + 图查询,而不只是搜索。

对非技术读者来说,你可以把 GraphRAG 想象成给 AI 增加了一个“类脑”知识网络,除了文档库之外。AI 不再孤立地读每本书(文档),而是有一本事实及其关联的百科全书。对技术读者来说,你可以想象一个架构,里面既有向量索引又有图数据库,两者协同工作——一个检索原始段落,另一个检索结构化事实,都喂进 LLM 的上下文窗口。

构建用于 RAG 的知识图谱:方法

构建支持 GraphRAG 系统的知识图谱有两种主要方法:Top-Down(自上而下) 和 Bottom-Up(自下而上)。它们不完全互斥(通常会混用),但区分它们有助于理解。

方法 1:自上而下(优先本体论)

自上而下的方法从定义领域的本体论开始,由领域专家或行业标准建立类、关系和规则。这个模式加载到图数据库中作为空的框架,指导数据提取和组织,相当于一个蓝图。

一旦本体论(模式)就位,接下来是用真实数据填充它。有几种子方法:

使用结构化来源:如果你有现有的结构化数据库或 CSV 文件,就把它们映射到本体论。如果映射简单,可以通过自动化ETL 工具将 SQL 表转为图数据。

通过本体论从文本提取:对于非结构化数据(比如文档、PDF),你会用NLP 技术,但以本体论为指导。这通常涉及编写提取规则或用 LLM 配合引用本体论术语的提示。

手动或半手动整理:在关键领域,可能需要人工验证每个提取的三元组,或手动输入一些数据到图中,特别是一次性设置的关键知识。比如,公司可能手动输入组织架构或产品层级到图中,因为这些数据相对静态且非常重要。

关键在于,自上而下的方法中,本体论在每一步都起到指导作用。它告诉提取算法要找什么,确保输入的数据符合一个连贯的模型。

使用正式本体论的一大优势是你可以利用 reasoners(推理器) 和 validators(验证器) 保持知识图谱一致性。本体论推理器可以自动推断新事实或检查逻辑矛盾,而像 SHACL 这样的工具可以强制执行数据形状规则(类似更丰富的数据库模式)。这些检查能防止矛盾事实,并通过自动推导关系丰富图。在 GraphRAG 中,这意味着即使多跳连接不明确,本体论也能帮助推导出来。

方法 2:自下而上(数据优先)

自下而上的方法直接从数据生成知识图谱,不依赖预定义的模式。NLP 和 LLM 的进步让从非结构化文本中提取结构化三元组成为可能,这些三元组随后被输入图数据库,实体成为节点,关系成为边。

在底层,自下而上的提取可以结合传统 NLP 和现代 LLM:

Named Entity Recognition (NER,命名实体识别):识别文本中的人名、组织、地点等。

Relation Extraction (RE,关系提取):识别这些实体之间是否有提到的关系。

Coreference Resolution(共指消解):弄清楚段落中代词的指代对象,以便三元组使用完整名称。

有像 spaCy 或 Flair 这样的传统方法库,也有整合 LLM 调用的新库用于 IE(信息提取)。另外,像 ChatGPT 插件 或 LangChain 代理 这样的技术可以设置来填充图:代理可以逐个读取文档,找到事实时调用“图插入”工具。另一个有趣的策略是用 LLM 通过读取文档样本建议模式(这有点像本体论生成,但自下而上)。

自下而上提取的一个大问题是,LLM 可能不完美,甚至会“创造性”输出。它们可能瞎编一个不存在的关系,或错误标记一个实体。因此,验证很重要:

• 对关键事实与源文本交叉检查。

• 使用多轮提取:比如第一轮提取实体,第二轮验证和填充关系。

• 人工抽查:让人审阅一部分提取的三元组,尤其是那些影响大的。

这个过程通常是迭代的。你运行提取,找到错误或缺失,调整提示或过滤器,再运行一次。久而久之,这能大幅提高知识图谱的质量。好消息是,即使有些错误,知识图谱对很多查询仍然有用——你可以优先清理对用例最重要的部分。

最后,记住,发送文本进行提取会将你的数据暴露给 LLM/服务,所以要确保符合隐私和保留要求。

GraphRAG 生态中的工具和框架

构建 GraphRAG 系统听起来可能有点复杂,你得管理向量数据库、图数据库、运行 LLM 提取流程等。好消息是,社区正在开发工具让这事变得更简单。我们来简单提一些工具和框架,以及它们的作用。

图存储

首先,你需要一个地方存储和查询知识图谱。传统的图数据库如 Neo4jAmazon NeptuneTigerGraph 或 RDF triplestores(如 GraphDB 或 Stardog)是常见选择。

这些数据库专为我们讨论的操作优化:

• 遍历关系

• 查找邻居

• 执行图查询

在 GraphRAG 设置中,检索流程可以用这些查询来获取相关的子图。一些向量数据库(像 Milvus 或带 Graph 插件的 Elasticsearch)也开始整合类图查询,但通常专用图数据库提供最丰富的功能。重要的是,你的图存储要能高效检索直接邻居和多跳邻居,因为复杂问题可能需要抓取整个事实网络。

新兴工具

一些新工具正在将图与 LLM 结合:

Cognee:一个开源的“AI 记忆引擎”,为 LLM 构建和使用知识图谱。它作为代理或聊天机器人的语义记忆层,将非结构化数据转为结构化的概念和关系图。LLM 能查询这些图以获得精确答案。Cognee 隐藏了图的复杂性:开发者只需提供数据,它就生成可查询的图。它与图数据库整合,提供数据摄取、图构建和 LLM 查询的流程。

Graphiti(由 Zep AI 提供):一个为需要实时、动态记忆的 AI 代理设计的框架。与许多静态数据的 RAG 系统不同,Graphiti 能在新信息到达时增量更新知识图谱。它存储事实及其时间上下文,使用Neo4j存储,提供面向代理的 API。与早期基于批处理的 GraphRAG 系统不同,Graphiti 能高效处理流式数据,适合持续学习的长期运行代理,确保答案始终反映最新数据。

其他框架:像LlamaIndexHaystack这样的工具添加了图模块,尽管不是以图优先。LlamaIndex 能从文档提取三元组并支持基于图的查询。Haystack 实验了整合图数据库来扩展问答功能,超越向量搜索。云服务商也在增加图功能:AWS Bedrock Knowledge Bases支持 GraphRAG,通过托管摄取到NeptuneAzure Cognitive Search也与图整合。生态系统发展很快。

无需从头开始

重点是,如果你想尝试 GraphRAG,不用从零开始。你可以:

• 用Cognee处理知识提取和图构建,省去自己写提示和解析逻辑的麻烦。

• 如果需要即插即用的记忆图,尤其是对话或时间相关数据的代理,用Graphiti

• 用LlamaIndex或其他工具,只需几行代码就能获得基本的知识图谱提取功能。

• 依靠成熟的图数据库,省去写自定义图遍历引擎的麻烦。

总之,虽然 GraphRAG 处于前沿,但周边生态正在快速成长。你可以利用这些库和服务快速搭建原型,然后迭代优化知识图谱和提示。

结论

传统 RAG 适合简单的事实查询,但在需要深入推理、准确性或多步回答的查询上会吃力。这时 GraphRAG 就大显身手了。通过结合文档和知识图谱,它用结构化事实锚定回答,减少 hallucinations(瞎编),支持多跳推理,让 AI 能以标准 RAG 无法做到的方式连接和综合信息。

当然,这种能力也有代价。构建和维护知识图谱需要模式设计、提取、更新和基础设施开销。对于简单用例,传统 RAG 仍是更简单高效的选择。但当需要更丰富的回答、一致性或 explainability(可解释性) 时,GraphRAG 的优势显而易见。

展望未来,知识增强的 AI 正在快速发展。未来平台可能直接从文档自动生成图,LLM 直接在图上推理。对于像 GoodData 这样的公司,GraphRAG 将 AI 与分析结合,带来超越“发生了什么”到“为什么发生”的洞察。

最终,GraphRAG 让我们更接近于不仅能检索事实,还能真正理解和推理事实的 AI,就像人类分析师,但规模和速度更大。虽然这条路有复杂性,但目标(更准确、可解释、更有洞察力的 AI)绝对值得投资。关键不仅在于收集事实,而在于连接它们。

本文转载自​PyTorch研习社​,作者:AI研究生

已于2025-9-17 00:01:42修改
收藏
回复
举报
回复
相关推荐