前言
大语言模型的兴起极大提升了机器对自然语言的理解能力，相关AI应用也随之蓬勃发展。对于企业而言，构建企业级知识库尤为重要。企业在日常运营中积累了大量的内部文档，如何有效地利用这些文档，将其转化为可用知识，是一个长期存在的挑战。
RAG（检索增强生成）技术的出现为这一问题提供了新的解决思路，使对海量文本的自动处理与理解成为可能，进而将文档活化为企业的私有知识库。然而，传统RAG技术在处理复杂知识关系方面仍存在不足。GraphRAG通过引入图谱结构，更高效地组织和关联知识，显著提高了RAG回答的质量。
尽管GraphRAG在理论上具备优势，但在数据质量、时效性保障，以及降低开发门槛方面仍有较大的提升空间。本文将介绍一种基于Oracle融合数据库的GraphRAG实现方案，结合Oracle 23ai的新特性与开源框架LightRAG，旨在简化开发与部署成本，同时在数据治理、数据质量和实时性方面提供显著优势。
RAG vs. GraphRAG
传统RAG系统依赖向量相似性检索，从知识库中找到与用户查询相关的文档，并基于这些文档生成答案。与传统的关键词搜索或基于规则的方法相比，RAG更适合处理自然语言查询，能够提供更准确和全面的答案。
然而，在面对包含复杂关系的文档数据时，传统RAG常常显得力不从心。例如，当某个概念在不同段落中多次提及时，传统RAG难以捕捉这些段落之间的关系，导致语义丢失。
GraphRAG的出现正是为了解决这些不足。
GraphRAG利用图数据结构表示知识，将知识之间的关系通过节点和边的形式直观地展现出来。这种图结构更擅长捕捉知识间的复杂关系，如因果关系、共现关系等。此外，图结构还支持多跳推理——即根据多个事实进行逻辑推导，以得出最终答案。这是传统RAG系统难以有效处理的问题。
GraphRAG在复杂关系处理、多类型数据整合方面表现出显著优势。例如，在医疗领域，GraphRAG可以分析疾病、症状和药物之间的复杂关系，提供精准的诊断和治疗建议；在金融领域，它可以揭示企业、个人实体之间的关联，帮助识别潜在风险。
构建GraphRAG面临的挑战
基于知识图谱的GraphRAG为知识检索提供了强有力的方法支撑，但是要从概念落地到实际应用，需要克服诸多挑战，尤其是在高质量知识图谱的构建和维护方面。
1. 多模数据整合
GraphRAG系统需要整合多种数据类型：
文本数据：用于向大语言模型传递原文。
关系数据：用于存储文本、段落等文档元素之间的引用关系。
向量数据：存储文本转换的向量数据，用于自然语言的相似检索。
图数据：用于存储知识图谱的节点与边关系。
如何高效整合这些不同格式的数据，是GraphRAG构建的核心挑战。
2. 知识图谱的动态更新与维护
知识图谱的构建涉及节点、边、关系类型的定义，以及实体之间关系的确定。此外，图谱的维护需要确保实时性和准确性，动态更新机制的设计同样至关重要。
3. 跨领域技术整合
GraphRAG涉及数据库、图计算、自然语言处理和机器学习等多个技术领域，这对开发团队提出了较高的技术要求。此外，系统的架构设计、容错性、可扩展性和安全性也是成功落地的关键因素。
基于Oracle 23ai和开源框架的解决方案
LightRAG是一个开源的检索增强生成框架，涵盖从文档处理、知识图谱构建到RAG问答的完整流程。结合Oracle 23ai的能力，可以为GraphRAG系统的构建提供更加简便和高效的实现。该方案旨在解决多模态数据整合、知识图谱构建与维护、图计算性能、检索策略以及答案生成等方面的难题，最终实现一个高效、易用且强大的GraphRAG系统。
1. 数据整合
我们的方案核心在于充分利用Oracle 23ai作为融合数据库的强大的多模数据处理能力。
Oracle融合数据库统一了关系型数据、向量数据、图数据、JSON数据，能够在一条SQL查询中实现跨模式的数据整合。这极大简化了数据存储和查询的复杂性，提升了开发效率。在下图所示的架构中，以往需要多个数据库完成的存储、查询任务，使用Oracle 23ai可以一步到位，在一条SQL中实现关系、向量、图的关联查询。
2. 知识图谱构建与维护
Oracle 23ai的Graph新特性支持直接在关系型表上创建Graph视图。结合LightRAG的增量更新算法，系统能够高效地集成新数据，确保数据的实时性与准确性，避免繁琐的图谱维护工作。
由于23ai在关系-图数据上的统一，可以直接对关系型表进行增、删、改的维护工作，这些变化会直接反映在图查询的结果中，无需对Graph进行修改和维护。这样就极大地减少了开发和维护上的复杂性，数据的实时性也能得到保证。
3. 高效检索与生成
我们集成LightRAG开源框架，使用SQL语句高效完成数据提取的任务。LightRAG的双层检索系统结合向量检索、图查询和键值查找，在原有系统中通过3种不同的数据库分别完成。
在Oracle数据库中，这些操作均可通过SQL完成，确保高效、稳定的检索与生成过程：向量检索可以通过Vector Search函数完成，图查询通过GRAPH_TABLE语法完成，键值查找则直接从关系型表或JSON数据中完成，并且以上这些过程都可以在一条SQL语句中关联查询。
以上这些能力都是Oracle Database的完全集成特性，继承了安全性、可扩展性和高性能功能，能够稳定、高效地处理大规模GraphRAG数据。
应用场景和案例演示
在实际场景中，当文档包含丰富的实体和关系时，向量检索往往无法捕捉跨段落的复杂关系。而GraphRAG可以通过图谱结构，清晰地展现实体与关系间的联系。
在LightRAG中定义Oracle数据库的连接方式，就可以将Oracle作为存储和查询的引擎。调用insert过程，就可以开启文档读取—长文本切片—实体和关系提取—文本总结—向量化—数据存储等一系列过程。执行完成后，通过可视化程序查看知识图谱。
下面的演示中，我们以一个文本文档作为数据源，通过调用LightRAG将文本转换为知识图谱。
这篇文档是关于数学家埃尔德什·帕尔的生平简介，从下面的可视化效果中可以看到一个以埃尔德什为核心的关系网络，在这个网络中包括了与他相关的人、地点、机构等等，爱因斯坦、冯·诺伊曼等人都和他有过交集。每一个元素和边关系都可以追溯到在原文中出现的位置。
埃尔德什是一位十分高产的学者，为了纪念他在图论方面的贡献，人们定义了“埃尔德什数”。“埃尔德什数”是描述数学论文中一个作者与埃尔德什的“合作距离”的一种方式，埃尔德什本人是0，与其合写论文的埃数是1，多1个中间人就加1。这篇文档中添加了一些我的个人信息，以此来验证回答的质量。
使用LightRAG的“向量检索”和“实体-关系混合检索”2种模式来回答同一个问题：“我和埃尔德什有什么联系？我的埃尔德什数是多少？”得到了2个截然不同的答案。
对于“向量检索”，AI的回复是“……你没有提供足够的信息来确定你自己的埃尔德什数……”。
但是基于知识图谱的“实体-关系混合检索”给出了明确的答案——我的埃尔德什数是5，并详细说明了推导路径。
这个数比预期中小得多，说明我和埃尔德什的关系并不远。AI也准确地推导出了我是如何与埃尔德什产生联系的，通过下面的可视化图可以验证这个结论是正确的。
从这个例子中可以非常直观地看到，对于文档中的复杂关系，向量检索无法胜任，而基于知识图谱的GraphRAG就能给出非常理想的结果。
