Agent如何在知识图谱中搜索: Graph-RAG

原文链接：https://mp.weixin.qq.com/s/7HTpWnqQWRu67BuVS6In5Q

**检索增强生成（RAG）**2年前就已成为特定场景下企业落地Agent的重要技术。一是因为早先的大模型幻觉严重，需要外置数据库检索信息以增强生成结果，二是满足企业在特定背景下的对Agent的数据需求。

RAG不是改变模型自己的训练参数，而是配置了一个外置数据库供LLM访问，现在市面上多数的RAG项目都利用了向量数据库（Vector Database）,因为文本数据的语义可被一个高维向量表示，相近语义的语块在向量表现上也有更近的关系。

【AI Agent探幽】03| RAG：为什么语言文字实际上是数学向量？

但是向量数据库存在一个局限性，LLM不能通过取出top-k个向量索引就理解出整个知识体系。我们这里举个例子：

我们把一本《红楼梦》分块、嵌入到向量数据库中做成RAG知识库，这样，如果LLM query请求“宝玉与黛玉”，向量数据库通过相似度计算能够得到若干个相关的段落，但是LLM此时依然不能直接找出宝玉和黛玉的关系是什么，只有原文没有关系。

那，有没有什么数据库能够很好地表示出多元关系呢？答案是——Knowledge-Graph知识图谱。

知识图谱的出现不是现代的产物，早在早期的人工智能探索上，人们对于专家系统的知识库构建就采用了知识图谱。关键元素就是节点（node/Entity），和边（edge/relationship），其中节点可以表示为实体，边可以表示为属性关系等。

微软提出了GraphRAG的概念，论文的故事是，VectorDB RAG擅长局部信息检索，但是全局理解较差。所以他们要构建Graph做RAG Database。

https://arxiv.org/pdf/2404.16130
GraphRAG不是像常规知识图谱那样，用一点数据库语句，直接搜索邻接表里面的某个节点连的所有边喂给LLM就行了，而是要赋予Agent操作Graph的能力。我们下面来详细讨论：

如何建图？

对于GraphRAG,传统的文本切分方法依然有效：比如按段落切分，按固定tokens数量切分，代码类的按格式（json等）切分。

GraphRAG里，LLM要能通过特定的prompt自己从文本中抽取关系建图，保证数据库的动态性。例如：

1 2	`OpenAI 发布 GPT-4，微软将其整合到 Azure AI 服务。`

LLM抽取实体和关系，最终形成如下图的关系：

`OpenAI（实体）
   | develop(关系)
 GPT-4（实体）
   | 
Azure AI（实体）
   | integrate（关系）
Microsoft（实体）`

在GraphRAG中，实体依然以嵌入向量的形式存入到图中，不同于传统的向量数据库，但他们由更显式的关系边连接和社区机制。

Community

微软发现，应用Graph RAG时，内部图可能存在千万个节点和关系边，直接遍历还是很慢，但是一部分节点能够生成一个个带有主题的 ,等级不同的社区（Communities）。微软的论文里面，Community是在构建图的过程中，一步一步通过Leiden community detection 方法生成,且每个社区要生成summary，这是微软的GraphRAG最有特色的部分。

原论文的community示意图
事实上，你可以由自己的算法生成自己定义的Community，比如在图论中，你可以简单的定义Community为连通块，不连通就分开；当然也可定义一个Community是强连通分量，这是你自己决定的，在不同的场景下，community的定义方法有着不同的意义。

那它能做什么呢？首先，毋庸置疑的面对总结性质的全局问题，快速生成结果。其次，Community能够更好的展示更大尺度的分离和包含关系，有助于加强检索效率。在下文的Agentic GraphRAG中，如果构建了Community，可以设计相应的工具供Agent剪枝，加速搜索，有点类似于跳表。

Agentic GraphRAG

事实上，由微软的RAG方案，不是图数据库有特色，而是图数据库怎么进行Agentic操作。

还是从传统的向量数据库RAG说，对于单独的检索操作，LLM可选的是，query内容和参数，比如定义一个json,可以像下面这样。

`{
 "query_content" = " ",
 "top-k" = " ",
}`

那图数据库的query应该可以怎么做呢。我们可以利用图论算法来进行相当多的操作。

比如对于一个医疗场景图，以疾病类别，药物类别，症状等待内容为节点的图，怎么进行Agentic操作呢。

对于一些简单的问题，类似“高血压的治疗药物”，很明显，我们可以通过直接遍历“高血压”节点的所有症状关系边，就可以得到所有的症状节点。

知识图谱也可以利用图论算法进行复杂操作，比如之前著名的“历史人物找关系”功能，就是对两个节点做最短路，只要图是联通的即可。

但是，更复杂的问题呢，比如：“我同时患有高血压，糖尿病疾病，我有头晕、乏力的症状，我长期服用降压药，我…..请问，我应该怎么办？”

但是传统的硬编码规则系统，无法解决复杂的推理问题，这时，我们便要引入Agentic RAG。具体怎么做呢？

但就检索来说，我们可以定义以下工具：

`def kth_shortest_path(node_1,node_2,k):
 # 判断两个节点的第k个最短路
 return path = [path_1,path_2...,path_k]
 
def traverse(node,attribute):
 # 遍历一个节点的某一属性
 return nodes = [node_1,node_2...]

def dfs(node,max_depth)：
 # 针对某一节点，进行深度优先搜索，层数不超过max_depth
 return [[depth_1,node_1],[depth_1,node_2]...[depth_max,node_n]]`

这些工具，留给LLM使用，当用户问出上面的这种问题时：

“我同时患有高血压，糖尿病疾病，我有头晕、乏力的症状，我长期服用降压药，我…..请问，我应该怎么办？”

Agent进入循环，借助Graph Tool进行检索，简单的思考过程可能如下：

`$ User: 我有高血压、糖尿病，最近头晕、乏力，还长期服用降压药，怎么办？

[Agent] Entities: 高血压 | 糖尿病 | 头晕 | 乏力 | 降压药

Plan:
1. 查询疾病关联
2. 分析症状原因
3. 检查药物影响

[Tool]kth_shortest_path("高血压","糖尿病",3)
[Result]高血压 → 代谢综合征 → 糖尿病 | 高血压 → 心血管风险 → 糖尿病

[Tool] traverse("头晕","related_conditions")
[Result]头晕 ← 低血压 / 血糖异常 / 药物副作用

[Tool]kth_shortest_path("降压药","头晕",3)
[Result]降压药 → 血压下降 → 头晕 | 降压药 → 电解质变化 → 乏力

[Agent]
Evidence:
- 高血压+糖尿病 → 心血管风险增加
- 降压药 → 可能导致低血压症状
- 糖尿病 → 可能造成血糖波动

[Generate]
综合 Graph Evidence，生成建议：
监测血压和血糖，与医生确认药物方案，关注异常症状。`

事实上，用户提出的问题，可能是更复杂宏观的的。考虑以下场景：

你拥有一个股份关系图谱，里面有公司、股东、机构、基金等众多节点，有股份持有比例、控制、共属同一集团等多个关系。

问题是：“帮我分析 A 公司背后的实际控制人，以及它是否存在潜在关联企业。”

这是一个更为复杂的问题，除了A公司这一节点外没有任何实体，如果没有Agent协助检索，在以往，除了人自己分析之外没有什么有效的办法解决。

Agentic Graph-RAG会具备以下能力：

问题建模，自我尝试生成出开始搜索的入口节点。
关系探索，对着某一个节点无目标的泛泛探索，尝试用bfs,dfs等办法进行遍历，试图获取有用的信息。
多跳推理，不只是一步一步遍历，而是有所取舍的，根据推理内容进行跳跃。
异常判断：Agent可以根据图发现异常或者被隐藏起来的一些关系。比如, 自然人 -> SPV公司 -> 基金 -> 上市公司,我们可能根本无法直观判断上市公司被此自然人控制，但是Agent能弄漫长的关系网中推理出来。

Hybrid Strategy

事实上，VectorDatabase和Graph Database是不应该相离的，微软的论文也说明了这点。为什么？

如果你认真思考过GraphRAG的检索办法，不难发现，如何精准定位节点和减少无用探索是两个核心问题。

在实际场景中，Agent很可能会出现“迷路”的状况，一是因为开始节点就找错了，用户要它分析机构，Agent从某个同名公司开始搜索；二是进行过多的无用探索，没有剪枝，造成效率低下，用户让它分析持股人，结果它把所有边都探索一遍。

Agent的图搜索算法可以被向量数据库检索指导，甚至可以理解为一个A-star算法,啥意思？

这时候可以设计函数：

定义

g(n)：已经走过的路径成本
h(n)：距离目标的估计成本g(n) = Graph traversal cost（距离搜索原点的距离）``h(n) = Embedding similarity(query,node)（嵌入向量相似度得分）加权算出最终得分

我们把图中某个节点的位置插入向量数据库，把节点本身嵌入进嵌入表。这样我们可以更精准的定义出关系更好的节点的位置，然后进行剪枝。

到这里会发现，Agent实际上就是一个广义的决策对象，它自己本身就可以作为A-star算法中的估计成本函数，不过我们让这个估计成本函数变得可以在内部进行推理。

相较于VectorDB，GraphDB更符合人脑的结构，关系探索就是人类的联想能力。但是相较于向量数据库，Graph需要更优设计的图搜索算法和Agent引擎，否则会成为一个浪费时间和tokens的陷阱。

本文转载自微信公众号，如有侵权请联系删除。