5个知识图谱KG和RAG系统的误解 — 构建和使用RAG原生图谱
在本文中，我们想要解决GraphRAG系统中的一些常见误解。我们特别关注理解知识图谱构建技术和我们称之为“RAG-Native Graphs”所带来的细微差别。
这些误解包括：
常见误解＃A：需要一个大图谱
当人们考虑知识图谱时，他们有时会产生这样一个观念，即知识图谱是一种庞大的单体数据结构，需要花费大量时间和精力来创建，跨越数年和数百万美元。
从历史上看，对于知识图谱被用于LLM之前的特定用例，例如大规模欺诈检测或生物医药知识发现，这种说法是正确的。
有了LLM，一些知识图谱的用例发生了变化，LLM也用于自动化大量知识图谱构建工作，将以前需要数年完成的工作缩短到几秒钟。
此外，有了LLM系统，小图谱的机会出现了，进一步降低了创建有价值图谱的激活能量。
在LLM出现之前，知识图谱在很大程度上被用作数据字典，是一种强制在不同数据孤岛之间执行语义结构的手段，并聚合数据集以揭示隐藏的关系，或者进行关系挖掘。知识图谱被用于捕捉可能有趣的概念和关系，特别是在大型非结构化数据存储中追踪，举例来说，收集大型生物制药学术论文，并将所有信息放入知识图谱中，以便理解不同论文之间的概念之间的隐藏关系，特别是需要在多个文档之间紧密联系关系的关系（即，论文1说X=Y，论文2说Y=Z。知识图可以揭示出X=Z）。
随着LLM的先进发展，我们应将知识图谱视为用于增强语义焦点和结构基础而非仅仅作为数据的聚合者的工具。由此产生的小图不需要完全完整，因为LLM带来了自身对语义的理解。这意味着，在许多情况下，不需要创建一个对世界进行完美描述的版本。
常见误解＃B：知识图谱只对网络类型数据，如支付或社交媒体数据，有效。
知识图谱在历史上已经被广泛用于网络类型数据。这类数据包括付款或社交媒体类型的网络数据。
一个常见的误解是知识图谱只与基于网络的数据相关，因为传统上使用KG的重点是网络数据。
发生变化的是非结构化数据的普及。就像在使用嵌入式进行非结构化数据搜索时，向量数据库真正流行起来一样，非结构化数据存储和搜索的新范式也存在于不同类型的知识图谱中，这在历史上并不常见。
除了网络类型数据外，来自非结构化数据的分层数据类型也非常适合知识图谱。我在本文中更详细地讨论了这种分层数据类型，以及给出了一个分层知识图谱的例子，代表苹果季度财务报告的形式。
Source: https://medium.com/enterprise-rag/understanding-the-knowledge-graph-rag-opportunity-694b61261a9c
在这个由 Neo4J 制作的图谱中，它涵盖了图结构中可以表示的信息范围的非详尽选择。这反映了图结构对非结构化数据可能相关的许多用例。
一个关于非基于网络的数据以图形结构表示用于信息检索的具体实例可以在LinkedIn构建的这个客户服务系统中看到。
这里，知识图谱用于表示一系列客户支持工单的不同要素，包括优先级状态、根本原因、描述要素和摘要。这是一种基本的客户支持工单要素的分层表示，用于帮助分类查询（“问题查询”）并检索工单的特定要素（“HAS_STEPS_TO_REPRODUCE”）。
这种分层的非网络数据结构允许根据存储在预定义模式中的信息非常精确地检索特定信息。我们还可以看到关于一个大图的误解A存在重叠，因为并非所有客户支持工单中可能的实体和关系都在图中表示，LinkedIn关心的只是工单的特定方面被表示为边缘和节点。Linkedin的GraphRAG客服问答系统实践
Source: https://arxiv.org/html/2404.17723v1
我们可以在外面看到许多其他GraphRAG系统的例子，包括这个关于患者数据的案例，其中不追求多跳检索，而是确定性和更完整的信息检索。
常见误解 #C：聚类 / 图分析和GraphRAG之间存在重叠
创建知识图谱的过程在历史上涉及一系列方法，包括聚类。根据我们在构建KG RAG方法论的经验，我们发现聚类并不特别相关于RAG。这是因为聚类更多地关于对基础数据的高层次理解，而RAG则更多地关乎有针对性的信息检索，而聚类所提供的粒度水平并不足以获得精确结果。
聚类大致指的是模型在非结构化数据上执行一系列分类，并将它们分类为模型被微调以识别的若干类别（即“有关人员信息”，“有关工作信息”，“有关公司信息”等）。这些类别构成架构的基础，基于此架构将底层信息放入图中。聚类仅是用于图分析的技术的子集。关于为什么这与RAG相关的一些提议的论点之一是，这是一种可以帮助自动发现潜在要使用的架构的技术。
这种技术在您试图获得对非结构化文本的高层次理解，并了解文本的不同主题如何相互关联时尤其有帮助和有用。这里的很大价值在于底层数据的性质分析。
然而，正如您可能想象的那样，有一些明显的原因说明为什么这并不适合 RAG 过程。RAG 并不是关于对您的非结构化数据进行高水平分析，而是关于以粒度和准确性代表您的数据，以便对数据提出准确问题能获得准确结果。对数据进行高水平分类，虽然可能有用，但并不能比简单的 Vector RAG 搜索创建更准确的检索过程。尤其是因为目前 RAG 的问题并不是一般检索的缺失，而是克服与相关信息更精确和确定性检索相关的问题。
虽然聚类可能是一个潜在的方法，可以得到一个高层次的架构来开始工作，但目前尚不清楚它如何能够胜过简单地要求LLM根据基础数据给出一个高层次的架构，或者任何其他用于生成架构的技术。根据我们为客户构建KG RAG的经验，我们经常观察到，构建一个符合用户业务需求和所提问题类型的图形架构会在粒度水平上获得相当不错的性能，这通常可以看到在RAG中。
这并不是说聚类和图分析不重要。在许多情况下，您可以对特定类型的数据执行RAG和图分析，特别是网络数据。例如，可能希望在特定粒度级别上创建知识图，以进行RAG和精细信息检索，然后随后执行聚类分析，以获得对基础信息的更高级分析。
常见误解＃D：KG-RAG 只对多跳查询和检索有用
与图分析类似，知识图谱历史上一直被用于理解不同数据孤立体之间的隐藏关系。这一发现过程可以通过多跳检索来完成，这使得通过多个推理步骤轻松检索信息。
一个核心误解是，知识图谱仅对多跳检索有用。图结构有助于强化关系并表示层次信息，正如我们在错误观念＃B中讨论的那样。有时，这些关系采取多跳检索的形式。然而，在RAG中，在许多情况下，多跳检索并不是所面临的压倒性问题。
许多KG＆RAG论文讨论了KG作为RAG系统特别相关的原因，因为涉及到多跳查询。这使人们忽视了结构化知识表达的核心价值主张。我们可以看到，许多这些论文使用各种扭曲的方式来强调这一特定的价值主张，相对不自然地提出问题并与基准进行对比。
很多作为多跳查询示例的这些查询往往并不真实地反映人们通常会如何提出问题。
我们可以看到这种观点在实际应用中的知识图谱和RAG系统中得到了体现，就像上面的 LinkedIn 示例。诸如 LinkedIn 示例之类的实际用例更加强调确定性检索和关联的需求，而不是多跳推理，这更加代表了企业中 RAG 应用用例的典型定义。
即便如此，有许多类型的多跳查询，多跳推理在知识图谱和 RAG 系统中确实发挥着重要作用。多跳查询会在不同系统中出现，应被视为一种有价值的附加益处，但并非核心益处。过分强调多跳查询的作用将会分散知识图谱和 RAG 系统的核心价值。
KG & RAG系统的价值应该在可解释性、确定性和完整性。下面文章介绍了我们讨论的这几方面的价值主张:
- 可解释性/确定性：
https://medium.com/enterprise-rag/understanding-the-knowledge-graph-rag-opportunity-694b61261a9c [万字长文]GraphRAG技术栈及样例全面解析
- 完整性:
https://medium.com/neo4j/graph-vs-vector-rag-benchmarking-optimization-levers-and-a-financial-analysis-example-001587219683 KG RAG vs. Vector RAG：基准测试、优化杠杆和财务分析示例 - WhyHow.AI实践
常见误解＃E：处理成本降低和更长的上下文窗口减少了对KG RAG的需求，因为错误边际很大
KG RAG 不仅仅是为了减少与 RAG 无关的信息量。我们遇到的最大问题是能否将相关但在语义上不相似的信息引入上下文窗口。
LinkedIn 的例子也是一个很好的例子。没有知识图谱，将很难将 (“HAS_STEPS_TO_REPRODUCE”) 中的信息关联起来并将其返回到上下文窗口中，因为这些词本身并不出现在答案中。Linkedin的GraphRAG客服问答系统实践
相反，知识图谱非常适合于在实际重现问题的步骤之间建立关系，并与关系 (“HAS_STEPS_TO_REPRODUCE”) 相关联。换句话说，知识图谱非常适合于引入相关但在语义上不相似的信息。知识图谱不应被视为减少 RAG 成本的方式，而应被视为一种将无法通过矢量搜索检索的信息引入的方法，从而增加所提供答案的确定性、准确性和完整性。