这个洞察力如何改变了我正在做的事情？

经常有人问GraphRAG中知识图谱KG如何定义，是否还需要像以前一样构建复杂的知识图谱，实际应用中的确需要平衡投入产出。看了WhyHOW.AI的这篇文章，可以作为参考。

在LLM出现之前，知识图谱主要用于类似数据字典的方式——在不同的数据孤立中强制执行语义结构，并聚合数据集以揭示隐藏的关系或进行关系挖掘。知识图谱用于捕捉概念和关系，这些概念和关系很有意思，尤其是在针对大型非结构化数据存储进行跟踪时。

一个例子是收集大量生物制药学术论文，并将所有这些信息放入知识图谱中，以便能够理解不同论文之间的隐藏关系，尤其是那些需要在多个文档之间建立关系的关系（即，论文1说X = Y，论文2说Y = Z。知识图以揭示X = Z的结果）

随着LLM的先进发展，我们应将知识图谱视为锐化语义焦点的工具，而不仅仅是数据的聚合器。由于LLM带有自己对语义的理解，因此产生的小规模图谱不需要完全完整。这意味着在许多情况下，创建一个完美描述世界的版本并不是必要的。LLM能够将不同的结构化数据片段结合起来，并在其之上添加自己的理解。因此，只有在LLM出现故障的情况下或为了确保防止产生幻觉时，数据的结构化才变得重要。

对于RAG来说，结构化数据的能力和引入这种逻辑是一种注入上下文的形式，将来也对代理编排很有用。

基于这些进展，我们将图谱开发分为三种类型：大型知识图谱、小型知识图谱和混合（大型和小型的组合）知识图谱。

大型知识图谱

大型知识图谱用于存储一个主题的全面信息，使人们能够理解其所有相互关联的细节。
大型知识图谱有助于揭示您的非结构化文档中未知的隐藏洞察力和关系。

小型知识图谱

小型知识图谱对于构建需要更详细组织的特定内容领域非常重要。例如，在标准的 RAG 过程中，LLM 能够准确地检索大多数问题的信息，但对于更复杂的问题需要进行特定干预。创建一个小型知识图谱来补充检索过程有助于提高系统的准确性。我们将文档层次结构、文档结构以及针对问题的迷你知识图谱看作是不同类型的小型知识图谱。
可以按问题生成小型知识图谱，然后形成一个迭代的知识库，不仅反映你拥有的知识库，还反映用户关心的知识库。我们的一些设计合作伙伴希望在合作伙伴和利益相关者之间掌握他们的知识库如何随时间增长的控制权。

小型大型混合知识图谱

混合图模型是多个信息源可能流入一系列小图形，然后最终贡献并与一个大图形对齐的地方。这种情况的主要用例是存在多个数据流贡献到一个大型上下文源的情况。
多个数据流可以是多个数据贡献者（即不同部门），也可以是不同的数据来源（公共与私有），不同的文档来源或真实性守卫者（即不同的人）。
在特定小图/数据源中的信息被采纳为知识库之前，它可以以“小图”形式保留以进行进一步的转换或评估。这可以看作是一个问答过程、一个ECL过程或一个版本控制过程。我们的一些设计伙伴对如何从不同的内部和外部利益相关方提供的数据来源控制他们的知识库随时间增长感兴趣。

经常情况下，我们发现人们在将知识图谱纳入他们的流程中时采取了一种单一的方法，而可能存在更适合的替代方法。
这种单一的方法通常是让一个LLM试图描述他们的整个知识库，对每个节点和关系进行结构化，并进行查询。
对此，我们要问是否绝对有必要这样做。只有在缺乏结构开始压倒LLM时，才可能真正需要图结构。在开始阶段，小型或混合型KG结构可能会有用，以证明数据结构的价值。

这引出了一个问题：

图谱结构可以组织您的数据，但对于我的特定用例，最小可行的图谱是什么？例如，以下内容可以在图谱结构中捕获：

页面
文档结构
文档摘要
与向量块相关联的概念节点

连接到向量块的概念节点示例

文档层次结构的一个示例 "小图谱"

捕捉您的数据的更高层次表示可能对您的用例足够，就像结构化数据的表示不一定需要用于与FAQ Q&A集合进行查询的方式一样，或者更精细的数据表示（例如底层概念的图形表示）可能需要用于更复杂的问题。

捕捉每个概念和关系是否需要解决手头问题的问题。在许多情况下，这可能是必要的，但当我们与设计合作伙伴深入讨论时，情况通常并非如此。