第一章 GraphRAG 理论部分1. 与传统 RAG 相比的优劣势1.1 传统 RAG 的痛点先立靶分块割裂、局部检索、无多跳普通 RAG 的流程大家都熟文档 → 分块Chunking→ 向量化 → 检索 Top-K → 拼进上下文 → LLM 生成。它的三个结构性痛点正是 GraphRAG 存在的理由分块割裂RAG 的核心检索单元是文本块。业界已有多种分块策略——固定大小、递归字符分块、基于文档结构标题/段落分块、语义分块按 embedding 相似度切等它们确实能把块切得更语义完整。但注意这些策略优化的是块内完整性解决不了块间关系——一个完整事实的各个侧面“小米发布了 SU7” / “SU7 定位高端纯电” / “SU7 对标 Model 3”被分到不同块后它们之间的关联就丢失了检索时命中任何一块都只拿到一个侧面。分块策略再精妙都绕不开一个事实块是检索的原子块与块之间的结构关系在范式层面就被丢弃了。这才是分块割裂的实质——不是切得不够好而是以块为单元的范式本身没有关系通道。局部检索向量相似度检索的本质是在语义空间里找最像的文本片段它只给你局部命中不会主动跨文档做关联。问这份资料里所有的合作伙伴都有谁没有任何一个块能回答因为答案分布在整个语料库里。无多跳关系链 A→B→C比如华为→海思→麒麟芯片散落在不同位置向量检索无法显式利用这条关系路径只能靠 LLM 内部知识盲猜补全中间环节——猜对了是运气猜错了就是幻觉。1.2 图带来的能力增量及理论根源把文档建成图之后上面三个痛点各自有了结构性解法。关键不是多了个数据结构而是信息组织方式的改变显式关系编码 → 多跳推理在图里关系是一等公民A→B→C 是一条可遍历的路径。多跳问题从让 LLM 在隐空间里硬推变成在图上沿着边走路每一步都有据可依可解释、可验证。实体为中心 → 跨文档关联同一个实体比如OpenAI出现在十篇文档里在图上会汇聚成同一个节点。所有与它相关的信息天然挂在这一个节点上跨文档聚合不再需要碰运气式的相似度检索。社区层次摘要 → 全局覆盖这是 GraphRAG 最独特的部分。整个大图被切成社区、逐层生成摘要最终得到整个语料库的一页纸。全局性问题“语料库的主要主题是什么”在这层被回答——这是向量 RAG 根本做不到的。理论根源一句话向量是连续语义空间里的近似匹配擅长找相似的片段图是离散结构里的精确路径 聚合视图擅长关系的推导和全局的归纳。两者解决的是不同类型的问题不是同一问题的两种实现。1.3 代价构建成本、复杂度、动态更新难图带来的能力不是免费的三笔账必须算清构建成本高索引阶段要对每个文本块做 LLM 抽取生成实体和关系还要对每个社区生成摘要Token 消耗远超普通 RAG 的分块向量化。语料越大这部分成本越显著。Pipeline 复杂度高抽取 → 消解 → 建图 → 社区检测 → 摘要每个环节都可能出错且错误会向下游累积。抽取漏了一个关系摘要就少一段信息最终影响查询质量。动态更新难图是全局构建的。新增文档不仅要重新抽取、合并进已有图还可能改变社区结构需要重跑社区检测和摘要。相比普通 RAG加个块就能用GraphRAG 的增量更新重得多。摘要天然有损社区摘要是对信息的压缩压缩必然丢细节。全局查询拿到的是概括如果需要精确细节还得回退到局部检索。2. 离线索引阶段索引阶段的目标把非结构化文档变成图 摘要的结构化资产。整个离线流程是一条长 Pipeline文本分块 → 三元组抽取 → 实体消解 → 图构建 → 社区检测 → 社区摘要生成。2.1 三元组抽取方法把文档切成文本块让 LLM 对每个块抽取主体, 关系, 客体三元组并给每条三元组配一段简短描述。通过 Schema 约束比如 JSON 输出格式、限定的关系类型列表让抽取结果可以直接落成结构化数据。为什么要用 LLM 而不是传统 NER因为识别实体和抽取关系是两个不同的任务而 NER 根本不做后者。NER命名实体识别是序列标注任务输出是每个词属于什么类型的实体人名/组织/地点/时间……它只能告诉你这里有哪些实体给不出实体之间是什么关系——能给你图上的节点给不了边。真正对应抽边的任务叫关系抽取Relation Extraction, RE而传统监督式 RE 有两个致命限制一是封闭关系集合关系类型必须预先枚举如 NYT 数据集预定义的二十几种关系但真实世界的关系是开放、不可穷举的“发布了”“收购了”“是竞品”“出生于”……换一个领域就是一批新关系预定义列表永远覆盖不全二是依赖标注数据每个关系类型都要大量人工标注样本新领域 重新标注 高成本。学术界的开放式关系抽取OpenRE不限定关系集合但传统实现依赖句法模板和规则质量粗糙、对复杂句式容易崩。而 LLM 走的是另一条路生成式模型的输出空间不受预定义集合约束配合指令和 SchemaJSON约束能直接生成任意关系的三元组Few-shot 甚至零样本就能换领域——封闭集合和标注成本这两堵墙都被绕开了。所以 GraphRAG 的抽取环节必须用 LLM。粒度与 Schema 设计抽取粒度过粗会混入大量无关三元组噪音过细则把一句话拆得支离破碎。约束关系类型集合能显著降低噪音但也要小心约束过死导致漏掉有价值的关系——这是一个需要权衡的设计点。三类误差漏抽该抽的没抽、误抽抽出了不属于语料的、幻觉LLM 编造了文档里不存在的关系。抽取质量是整个图质量的上限——后面所有环节都在这个图上工作源头脏了下游再优化也救不回来。2.2 图谱构建与实体消解建图实体 → 节点关系 → 边描述 → 节点/边属性。同时保留双重表示图结构本身 实体的向量索引两者在查询阶段配合使用图上遍历找邻居、向量找语义相似实体。为什么要实体消解同一实体在语料里有各种写法——“OpenAI”、“Open AI”、“OpenAI公司”。如果不合并图会被同一个真实实体分裂成多个节点关系和社区都会被搅乱。方法基于实体描述的 embedding 相似度做聚类相似度超过阈值的归为一簇合并时保留最完整的描述。这是可并行的、可扩展的做法。理论点消解错误分两类——“错误合并”把两个不同实体并成一个污染信息和漏合并图碎片化同一实体散落多处。两者都会直接劣化后续社区检测的结果属于做不好就全盘崩的关键环节。2.3 社区检测动机图构建完成后规模可能达到几万甚至几百万节点。直接对着全图做全局分析不现实需要先把图分块——社区就是图的自然分块。模块度Modularity衡量一个社区划分质量的指标核心思想是社区内部的连接密度应当显著高于随机图的期望。模块度越高划分越像是真的聚成了团而不是随机分布的。理论点社区的语义解释——在以文档建图的场景里一个社区通常对应一个主题聚簇围绕同一批实体和关系抱团的知识单元。社区就是后续摘要的天然组织单位。2.4 社区摘要生成动机社区是结构单元一堆节点和边但 LLM 没法直接读图。要把图变成 LLM 能消费的东西必须把社区转写成自然语言摘要。方法对每个社区把社区内的实体、关系、描述聚合成一份材料用 LLM 生成一段社区摘要。更进一步社区是有层级的——叶子社区的摘要向上聚合生成父社区的摘要逐层到根得到一棵社区摘要树。Map-Reduce 聚合的理论意义这是 GraphRAG 回答全局问题的根基。摘要逐层压缩越往上粒度越粗根节点最终是整个语料库的一页纸。全局问题“语料库的主要主题是什么”不需要看任何原始块只需要在这棵摘要树上做聚合推理。把不可计算的大图压缩成可计算的全局视图——这就是它区别于一切局部检索范式的本质。与向量 RAG 的根本区别向量 RAG 只能看到与问题相关的块它的视野是局部的GraphRAG 的社区摘要让模型能看到相关的主题以及这个主题在整体中的位置。一个给细节一个给格局。成本提醒摘要生成是索引阶段 Token 消耗的大头社区越多、层次越深成本越高这也是 GraphRAG 落地时最需要规划的地方。3. 在线查询Local Search Global Search索引阶段产出了两套资产精确的图结构用于局部检索和压缩的社区摘要树用于全局检索。查询阶段按问题的信息需求类型分流到两套机制。3.1 Local Search流程问题 → 实体匹配 → 图上定位 → 邻域扩展 → 聚合上下文 → LLM 生成。实体匹配把问题里提到的实体与图中的节点对齐靠向量相似度 字符串匹配把自然语言问题锚定到图上的具体节点。邻域扩展锚定到节点后沿边走扩展邻居。先用 Personalized PageRank 对邻居节点打分排序PPR 衡量从起点出发哪些节点最容易被随机游走走到即谁和问题最相关取 Top-K 作为候选。聚合上下文把候选节点的描述、关联边、所在社区的摘要、以及节点对应的原始文本片段一起拼进上下文交给 LLM 生成带引用的答案。适合事实型问题、围绕特定实体的问题“X 公司的 CEO 是谁”、“X 和 Y 是什么关系”需要精确证据和细节时。3.2 Global Search流程问题 → Map 阶段对相关社区摘要逐份独立问答→ Reduce 阶段聚合生成最终答案。Map 阶段选出与问题最相关的社区摘要按层级和相关性筛选对每一份摘要独立地问同一个问题得到一堆部分答案。Reduce 阶段把所有部分答案聚合起来去重、按相关性评分、合并冲突生成一份覆盖全局的最终答案。适合全局性问题——“这份语料库覆盖了哪些主要主题”、“整体来看有哪些趋势”、“所有提到 X 的地方它们之间有什么共性与关联”。这类问题没有任何单一文本块能回答只有社区摘要层面才有答案。3.3 为什么按问题类型分流两种信息需求一类是精确型需求要具体证据、要细节、要能引用出处一类是覆盖型需求要全貌、要归纳、要跨文档的宏观结论。两者对检索单元的要求截然相反。局部检索给细节但缺覆盖Local 拉的是节点和邻域细节丰富但视野只在一跳两跳之内回答不了整体是什么。全局检索给覆盖但缺细节Global 看到的是摘要层覆盖全语料但拿不到具体到原文的细节过度概括时还可能引入摘要噪音。分流本质用问题的信息粒度和范围决定检索单元。问题问的是一个点用图问的是一整片用摘要树。两套机制是互补的不是二选一的替代品。3.4 适用场景与边界Local 失效的场景问题没有锚定到任何具体实体“总结一下所有客户投诉”——没有实体可定位Local 无从下手。Global 过重的场景简单事实问题用 Global 是浪费成本而且摘要层的概括反而可能引入与事实不符的偏差——问某公司 CEO 是谁就该用 Local精确且便宜。实践上的混合很多系统先对问题做分类路由或两条通道同时跑、结果再融合。分类路由省成本双通道融合更稳但更贵需要按场景取舍。边界提醒Global 的答案质量受社区摘要质量的上限约束。如果社区划分不好或摘要写得空泛全局回答就会大而空——这是 GraphRAG 的隐含天花板。4. GraphRAG vs 普通 RAG vs LLM 直塞上下文把三种范式放在同一张桌上对比本质是看它们如何组织信息、检索什么、能回答什么问题。4.1 三维对比表维度LLM 直塞上下文普通 RAGGraphRAG信息组织原始全文语义分块实体-关系图 社区摘要树检索单元全部内容文本片段节点/路径Local/社区摘要Global多跳推理弱依赖模型隐知识弱强显式关系可遍历全局性问题可以但成本极高几乎不行强社区摘要聚合细节与引用最好无损好命中块内好Local/一般Global 有损上下文成本O(全文)随文档线性爆炸低查询低但索引成本高构建成本无低高抽取 摘要 Token 大头动态更新即时快慢、重可解释性低中高能看到图上的关系路径4.2 理论根源信息组织方式的差异LLM 直塞原文即上下文信息无损、保真度最高。但受上下文窗口限制成本随文档规模线性增长语料一大就不可行——它是把检索问题消解成内存问题内存不够就崩。普通 RAG把检索问题消解成语义近似匹配用分块 向量换来可扩展和低成本。代价是丢掉了结构块与块之间的关联和全局视野——它优化的是局部命中率天生不擅长全局归纳。GraphRAG把检索问题消解成结构 聚合。用图保留关系解决多跳用社区摘要压缩全局解决全局问题。代价是构建阶段的高成本——它用离线重投入换在线强能力。一句话收束三者不是同一个问题的三个答案而是三种信息组织方式各自锁定了擅长的问题类型。选型不是哪个更好而是我的问题属于哪类、我的语料有多大、我能承受多少构建成本。4.3 各自的最佳适用场景 / 结论LLM 直塞文档小到一次能装下、需要最高保真度的场景单篇长文问答、代码库局部理解。别为了上 RAG而上 RAG能塞得下就没必要。普通 RAG大语料 事实型/局部查询 预算敏感客服知识库、产品文档问答。它是性价比之王绝大多数场景的默认选择。GraphRAG大语料 需要全局理解或多跳推理 能承受构建成本企业知识图谱、研究报告库、需要通读全局后总结的场景。它的价值在全局问题和关系推理上这两类问题普通 RAG 无解。结论GraphRAG 不是普通 RAG 的替代品而是能力边界的外扩。工业界的现实形态往往是混合架构——便宜快速的向量检索处理大部分局部问题GraphRAG 处理需要全局视野和关系推理的少数高价值问题两者按问题类型路由。第二章 Graph agent 理论部分5. Graph Agent 是什么5.1 定义以知识图谱为记忆与推理底座的 Agent 系统Graph Agent 不是能查图的聊天机器人而是以知识图谱为核心知识底座、能自主进行检索、推理、规划、甚至更新图谱的 Agent 系统。要理解它先看图在 Agent 里扮演什么角色。普通 Agent 的知识来自两个地方模型参数里固化的知识会过时、会幻觉、不可追溯以及临时挂上去的检索工具一般是向量 RAG只能给局部文本块。Graph Agent 多了一个层次——图作为外置大脑记忆存图里对话和事实的长期记忆以实体-关系的形式落图而不是堆在上下文里推理走图上多跳问题沿着关系路径遍历而不是靠模型隐式猜测答案可追溯每个结论都能回溯到图上的节点、边、以及背后的原始文档Graph Agent 的本质是把图从第一章里的检索数据源升级为Agent 的认知基础设施。5.2 为什么需要单 Agent 的边界 → 图能补什么先看单 Agent哪怕挂了向量 RAG的三个结构性边界记忆边界上下文窗口有限大语料塞不进去长对话里早期信息会丢。向量 RAG 缓解了塞不下但每次检索都像重新翻档案没有积累、没有结构。知识边界参数化知识过时且不可追溯向量 RAG 只能召回相似的文本块给不了实体之间的关系全貌。推理边界多跳关系推理依赖模型的隐式能力链条一长就容易断而且推理过程不可解释——错了你不知道错在哪一环。图恰好补齐这三块单 Agent 的边界图能补什么记忆有限图是长期、结构化、可增量更新的记忆Agent 只按需加载局部知识不可追溯每个实体/关系都有来源文档答案可回溯到证据多跳推理弱且不可解释关系路径显式可遍历推理链每一步都看得见无全局视野社区摘要回扣第一章提供超越局部块的整体理解5.3 与 GraphRAG、普通 Agent 的定位差异三者容易混淆用一张表说清GraphRAG普通 RAG AgentGraph Agent有没有 Agent无固定 Pipeline有能规划/调工具有能规划/调工具知识底座图静态只读文本块向量索引图可读可写、可演进检索方式固定双通道Local/Global向量相似度图遍历 检索 规划按需组合是否自主否一次查询走完流程是自主决定步骤是且能决定何时查图、怎么查、查完是否更新图多跳推理靠图结构但无决策弱强图上遍历 可解释一句话定位GraphRAG 是一种检索范式回答图怎么被查询Agent 是一种决策主体回答谁来决定怎么做而 Graph Agent 是两者的合体——让决策主体把图当作认知底座来使用、维护和演化。GraphRAG 的图是建好就不动的资产Graph Agent 的图是Agent 一边用、一边还在维护的生命体。6. 多 Agent 编排Graph Agent 的图不是天上掉下来的它要被人或 Agent 自己建出来。而建图 用图这件事天然适合拆成多个 Agent 来做——这就是多 Agent 编排。6.1 为什么建图/用图天然适合拆成多 Agent建一条高质量知识图谱的流程每个环节是彼此独立的认知任务输入、输出、失败模式完全不同抽取读文档块、产出三元组上下文是文本——失败模式是漏抽、误抽、幻觉消解判断跨文档的实体是否同一个上下文是实体及描述——失败模式是错并、漏并摘要对社区做归纳上下文是子图结构——失败模式是概括失真、丢细节质检校验整体质量上下文是图 规则——失败模式是误报、漏报如果把这些硬塞进一个 Agent 会怎样抽取的文档和消解的实体混在一个上下文里互相干扰上下文污染某一步出错无法定位是哪个环节错误不可溯源所有步骤串行无法并行没有吞吐。拆成多个 Agent 之后上下文隔离每个 Agent 只看到自己需要的输入注意力不被无关内容稀释独立质检每步产出可以单独校验错误在源头就被拦下可并行文档可以同时交给多个抽取 AgentMap吞吐翻倍可替换某个环节模型选型不合适只换那一个 Agent不动整条链路6.2 Agent 分工抽取 / 消解 / 摘要 / 质检Agent输入输出关键失败模式缓解手段抽取 Agent文本块 Schema 契约三元组实体/关系/属性漏抽、误抽、关系幻觉Schema 约束、分块并行、抽后抽查消解 Agent跨文档实体及描述归一化后的实体合并/去重错误合并污染、漏合并碎片化相似度预筛 判断、阈值校准摘要 Agent社区子图社区检测结果层次化社区摘要概括失真、关键信息丢失摘要粒度分层、抽检与原文比对质检 Agent图 规则 基准质量报告 / 修正建议误报、漏报规则 抽样人工 关键指标门槛注意最后一行质检 Agent 不是可有可无的验收员它是整条编排能自我纠错的前提——没有质检反馈前面的抽取/消解错误会一路放大到检索质量。6.3 编排模式与工程要点三种典型编排模式串行流水线抽取 → 消解 → 建图 → 摘要 → 质检前一环的输出是后一环的输入。流程清晰、依赖强但错误会沿流水线传导放大——所以质检不能只放在最后消解这种关键环节后也要设卡。Map-Reduce 并行文档并行分给多个抽取 AgentMap产出汇合后再统一做消解合并Reduce。大语料场景吞吐高是建图主流程的标配。反馈回路质检 Agent 发现问题后回灌给对应 Agent 重做比如消解合并错了 → 送回消解 Agent 重新判断。这是多 Agent 相比单流水线的关键优势——系统可以自己纠错而不是建完就完。工程上四个要点决定了编排能不能落地Schema 契约Schema 是所有 Agent 之间的接口协议。抽取 Agent 按 Schema 输出消解/建图 Agent 才能消费。Schema 不统一图根本建不起来——它是多 Agent 协作的通信语言。上下文隔离每个 Agent 只看自己该看的输入。既保护注意力也省 token——这是多 Agent 编排最大的隐性收益。成本平衡LLM 调用次数 × token 单价成本随 Agent 数量线性涨。实践上做分级便宜模型做高吞吐的粗抽取贵模型做低吞吐的消解判断和质检把预算花在判断而不是搬运上。错误传导控制抽取的错会放大到下游所有环节所以便宜 快的前提是关键处有闸门——用抽查、规则校验、基准集在关键环节拦住系统性错误。第二章 实战部分7. neo4j 简单使用7.1 图数据库与 Cypher 核心概念Neo4j 是图数据库数据以节点和关系存储查询语言叫Cypher可以理解成图的 SQL。四个核心概念概念含义对应 GraphRAG节点Node一个实体画成圆点三元组里的实体标签Label节点的类型如:Person实体的类型关系Relationship实体之间的边有方向三元组里的关系属性Property节点/关系上的键值对实体的属性/描述在 Neo4j 里建图本质就是把 GraphRAG 抽取的三元组实体, 关系, 实体翻译成节点和边。7.2 创建节点这里我用的数据库版本是neo4j-community-4.4.8jdk用的14。用CREATE创建节点标签用冒号前缀属性用花括号// 创建 2 个 Person 节点、2 个 Company 节点CREATE(a:Person {name:张三,age:30})CREATE(b:Person {name:李四,age:28})CREATE(c:Company {name:小米,city:北京})CREATE(d:Company {name:华为,city:深圳})7.3 创建关系关系用-[:关系类型]-表示方向从左指向右。先MATCH定位已有节点再CREATE连线// 张三 工作于 小米关系也能带属性MATCH(a:Person {name:张三}),(c:Company {name:小米})CREATE(a)-[:WORK_AT {since:2020}]-(c)// 李四 工作于 华为MATCH(b:Person {name:李四}),(d:Company {name:华为})CREATE(b)-[:WORK_AT]-(d)// 小米 与 华为 有合作关系MATCH(c:Company {name:小米}),(d:Company {name:华为})CREATE(c)-[:COOPERATE_WITH]-(d)7.4 查询与可视化全量查看—— 图上直接画出所有节点和关系MATCH(n)RETURNn条件过滤// 查出所有年龄大于 28 的人MATCH(n:Person)WHEREn.age28RETURNn多跳遍历—— 这是图数据库相对关系型数据库的核心优势对应 GraphRAG 的 “多跳推理”。一条语句沿着边连跳两层从 “小米” 出发找到合作的 “华为”再找到 “华为” 里工作的人MATCH(me:Company {name:小米})-[:COOPERATE_WITH]-(partner:Company)-[:WORK_AT]-(person:Person)RETURNme,partner,person(me:小米) -合作- (partner) -工作- (person) 起点 向右合作 中间点 向左工作 终点7.5 更新与删除更新属性用SETMATCH(n:Person {name:张三})SETn.age31RETURNn删除节点用DELETE。注意有关系的节点必须用DETACH DELETE连关系一起删否则报错// 删除李四这个节点及其所有关系MATCH(n:Person {name:李四})DETACHDELETEn7.6 清理清空数据库删光所有节点和关系让数据库回到干净状态// 危险操作删除全部数据演示完再用MATCH(n)DETACHDELETEn8. 简易财报知识图谱问答系统8.1 抽取三元组先设计三元组格式实体类型、关系类型、字段约束。然后写一段规则提示词让 llm 去抽取。提示词参考SYSTEM_PROMPT 你是金融领域知识图谱构建助手。请阅读给定的上市公司年报片段从中提炼可用于建图的三元组记录。 【一、允许的实体类别】严格限定为以下 7 类不得超出 - Company上市公司主体 - Person董事、监事、高管、实际控制人、股东等自然人 - Subsidiary子公司或参股公司 - Product公司主要产品 - Indicator财务类指标如营业收入、净利润、研发投入取值须携带数值与单位 - Segment业务板块或投资项目 - Region经营或业务所涉地区 【二、允许的关系类别】严格限定为以下 8 类不得超出 - REPORTS主体公司 → 财务指标对象须带数值与单位。示例贵州茅台 REPORTS 营业收入1240亿元 - SERVES_AS自然人 → 公司表示任职关系对象固定为公司需在 role 字段注明职务。示例丁雄军 SERVES_AS 贵州茅台role董事长 - CONTROLS自然人/公司 → 公司表示实际控制或控股关系 - HAS_SUBSIDIARY公司 → 子公司需在 ratio 字段注明持股比例。示例宁德时代 HAS_SUBSIDIARY 宁德新能源科技 - PRODUCES公司 → 产品 - OPERATES_IN公司 → 地区 - INVESTS_IN公司 → 业务板块/项目一般表示研发或投资方向 - RELATED_TO关系不明确时的兜底项非必要不使用 【三、输出格式要求】 仅输出一段合法的 JSON不要输出 markdown 代码块或任何解释文字。结构如下 { triples: [ {subject: ..., subject_type: ..., predicate: ..., object: ..., object_type: ..., year: ..., role: null, ratio: null} ] } 字段说明 - subject/object实体名称subject_type/object_type对应上述实体类别 - year信息所属年份 - role仅任职类关系使用其余置 null - ratio仅持股类关系使用其余置 null 【四、抽取守则】 1. 只提取原文明确记载的事实禁止臆测或补充 2. 数字与单位保持原文亿元/万元/元尽量精确 3. 实体名称采用市场通用简称例如贵州茅台酒股份有限公司应写为贵州茅台 4. 若片段中无可提取信息返回 {triples: []} 5. 单个片段一般输出 1~6 条遵循少而准原则8.2 建图在财报知识图谱入库阶段采用 MERGE 幂等写入策略完成节点与关系的导入。节点层面设计唯一标识uid生成规则为实体类型:规范化实体名(小写)并为所有Entity节点建立 uid 唯一约束以此杜绝重复实体同时执行实体规范化对上市公司全称、简称等多种别名映射到统一规范名称防止同一实体被拆分为多个节点。公司节点额外挂载股票代码属性便于精准检索。关系边写入时由于抽取得到的全部财报三元组均携带年份信息因此将年份纳入边的唯一性判定条件。当主体、客体、关系类型一致但年份不同时会生成多条独立的关系边以此保存企业历年动态变化的数据避免历史信息被覆盖。对于角色、持股比例等附加属性采用非空更新策略空字段不会修改边上已有的属性值。节点采用双标签设计统一打上顶层标签Entity再追加对应的实体类型标签Company / Person / Product 等方便按类型筛选实体。defmerge_edge_cypher(pred:str)-str:return(fMATCH (a:Entity {{uid: $src_uid}}), (b:Entity {{uid: $dst_uid}}) fMERGE (a)-[r:{pred} {{year: $year}}]-(b) fSET r.role CASE WHEN $role IS NOT NULL THEN $role ELSE r.role END, f r.ratio CASE WHEN $ratio IS NOT NULL THEN $ratio ELSE r.ratio END)这样就把图建好了如果有连任情况在图中就是有多条边每条边表示一个年份。MATCH(n:Entity{name:马明哲})-[r]-(m)RETURNn,r,mMATCH(n:Person{name:马明哲})-[r]-(m)RETURNn,r,m8.3 社区检测将图谱加载至内存后使用 Leiden 算法完成社区聚类社区编号回写到 Neo4j 节点属性上各个社区的 LLM 摘要单独保存为 JSON 文件用于后续全局检索。跑了社区检测后每个节点上加上了community属性打开本地文件可以看出llm对各个聚类的小结比如3号社区的小结是8.4 检索 Local GlobalLocal‑Search 和 Global‑Search 均使用向量相似度检索但检索目标完全不同。Local Search查询向量与实体名称向量匹配召回最相似实体再从这些实体出发在知识图谱上进行 BFS 多跳扩展抽取局部子图事实交由大模型回答。Global Search查询向量与预先生成的社区摘要向量匹配召回相关性最高的主题社区仅使用社区摘要和少量核心实体列表通过 Map‑Reduce 方式分社区产出要点再聚合全程不读取社区内部完整图谱细节。图数据库的Local search是希望能实现多跳搜索第一种方法是bfs硬搜缺点是节点多时数量爆炸第二种方法是用agent loop的方法每次只搜一跳再发给llm去搜下一跳。我使用的是第二种方法。造一个case来验证当前的graph agent实现了多跳搜索“谢治平任职的公司的23年的总经理是谁”global search 的效果中国平安有哪些高管 知识图谱：从 GraphRAG 到 Graph agent 的落地实践
第一章 GraphRAG 理论部分1. 与传统 RAG 相比的优劣势1.1 传统 RAG 的痛点先立靶分块割裂、局部检索、无多跳普通 RAG 的流程大家都熟文档 → 分块Chunking→ 向量化 → 检索 Top-K → 拼进上下文 → LLM 生成。它的三个结构性痛点正是 GraphRAG 存在的理由分块割裂RAG 的核心检索单元是文本块。业界已有多种分块策略——固定大小、递归字符分块、基于文档结构标题/段落分块、语义分块按 embedding 相似度切等它们确实能把块切得更语义完整。但注意这些策略优化的是块内完整性解决不了块间关系——一个完整事实的各个侧面“小米发布了 SU7” / “SU7 定位高端纯电” / “SU7 对标 Model 3”被分到不同块后它们之间的关联就丢失了检索时命中任何一块都只拿到一个侧面。分块策略再精妙都绕不开一个事实块是检索的原子块与块之间的结构关系在范式层面就被丢弃了。这才是分块割裂的实质——不是切得不够好而是以块为单元的范式本身没有关系通道。局部检索向量相似度检索的本质是在语义空间里找最像的文本片段它只给你局部命中不会主动跨文档做关联。问这份资料里所有的合作伙伴都有谁没有任何一个块能回答因为答案分布在整个语料库里。无多跳关系链 A→B→C比如华为→海思→麒麟芯片散落在不同位置向量检索无法显式利用这条关系路径只能靠 LLM 内部知识盲猜补全中间环节——猜对了是运气猜错了就是幻觉。1.2 图带来的能力增量及理论根源把文档建成图之后上面三个痛点各自有了结构性解法。关键不是多了个数据结构而是信息组织方式的改变显式关系编码 → 多跳推理在图里关系是一等公民A→B→C 是一条可遍历的路径。多跳问题从让 LLM 在隐空间里硬推变成在图上沿着边走路每一步都有据可依可解释、可验证。实体为中心 → 跨文档关联同一个实体比如OpenAI出现在十篇文档里在图上会汇聚成同一个节点。所有与它相关的信息天然挂在这一个节点上跨文档聚合不再需要碰运气式的相似度检索。社区层次摘要 → 全局覆盖这是 GraphRAG 最独特的部分。整个大图被切成社区、逐层生成摘要最终得到整个语料库的一页纸。全局性问题“语料库的主要主题是什么”在这层被回答——这是向量 RAG 根本做不到的。理论根源一句话向量是连续语义空间里的近似匹配擅长找相似的片段图是离散结构里的精确路径 聚合视图擅长关系的推导和全局的归纳。两者解决的是不同类型的问题不是同一问题的两种实现。1.3 代价构建成本、复杂度、动态更新难图带来的能力不是免费的三笔账必须算清构建成本高索引阶段要对每个文本块做 LLM 抽取生成实体和关系还要对每个社区生成摘要Token 消耗远超普通 RAG 的分块向量化。语料越大这部分成本越显著。Pipeline 复杂度高抽取 → 消解 → 建图 → 社区检测 → 摘要每个环节都可能出错且错误会向下游累积。抽取漏了一个关系摘要就少一段信息最终影响查询质量。动态更新难图是全局构建的。新增文档不仅要重新抽取、合并进已有图还可能改变社区结构需要重跑社区检测和摘要。相比普通 RAG加个块就能用GraphRAG 的增量更新重得多。摘要天然有损社区摘要是对信息的压缩压缩必然丢细节。全局查询拿到的是概括如果需要精确细节还得回退到局部检索。2. 离线索引阶段索引阶段的目标把非结构化文档变成图 摘要的结构化资产。整个离线流程是一条长 Pipeline文本分块 → 三元组抽取 → 实体消解 → 图构建 → 社区检测 → 社区摘要生成。2.1 三元组抽取方法把文档切成文本块让 LLM 对每个块抽取主体, 关系, 客体三元组并给每条三元组配一段简短描述。通过 Schema 约束比如 JSON 输出格式、限定的关系类型列表让抽取结果可以直接落成结构化数据。为什么要用 LLM 而不是传统 NER因为识别实体和抽取关系是两个不同的任务而 NER 根本不做后者。NER命名实体识别是序列标注任务输出是每个词属于什么类型的实体人名/组织/地点/时间……它只能告诉你这里有哪些实体给不出实体之间是什么关系——能给你图上的节点给不了边。真正对应抽边的任务叫关系抽取Relation Extraction, RE而传统监督式 RE 有两个致命限制一是封闭关系集合关系类型必须预先枚举如 NYT 数据集预定义的二十几种关系但真实世界的关系是开放、不可穷举的“发布了”“收购了”“是竞品”“出生于”……换一个领域就是一批新关系预定义列表永远覆盖不全二是依赖标注数据每个关系类型都要大量人工标注样本新领域 重新标注 高成本。学术界的开放式关系抽取OpenRE不限定关系集合但传统实现依赖句法模板和规则质量粗糙、对复杂句式容易崩。而 LLM 走的是另一条路生成式模型的输出空间不受预定义集合约束配合指令和 SchemaJSON约束能直接生成任意关系的三元组Few-shot 甚至零样本就能换领域——封闭集合和标注成本这两堵墙都被绕开了。所以 GraphRAG 的抽取环节必须用 LLM。粒度与 Schema 设计抽取粒度过粗会混入大量无关三元组噪音过细则把一句话拆得支离破碎。约束关系类型集合能显著降低噪音但也要小心约束过死导致漏掉有价值的关系——这是一个需要权衡的设计点。三类误差漏抽该抽的没抽、误抽抽出了不属于语料的、幻觉LLM 编造了文档里不存在的关系。抽取质量是整个图质量的上限——后面所有环节都在这个图上工作源头脏了下游再优化也救不回来。2.2 图谱构建与实体消解建图实体 → 节点关系 → 边描述 → 节点/边属性。同时保留双重表示图结构本身 实体的向量索引两者在查询阶段配合使用图上遍历找邻居、向量找语义相似实体。为什么要实体消解同一实体在语料里有各种写法——“OpenAI”、“Open AI”、“OpenAI公司”。如果不合并图会被同一个真实实体分裂成多个节点关系和社区都会被搅乱。方法基于实体描述的 embedding 相似度做聚类相似度超过阈值的归为一簇合并时保留最完整的描述。这是可并行的、可扩展的做法。理论点消解错误分两类——“错误合并”把两个不同实体并成一个污染信息和漏合并图碎片化同一实体散落多处。两者都会直接劣化后续社区检测的结果属于做不好就全盘崩的关键环节。2.3 社区检测动机图构建完成后规模可能达到几万甚至几百万节点。直接对着全图做全局分析不现实需要先把图分块——社区就是图的自然分块。模块度Modularity衡量一个社区划分质量的指标核心思想是社区内部的连接密度应当显著高于随机图的期望。模块度越高划分越像是真的聚成了团而不是随机分布的。理论点社区的语义解释——在以文档建图的场景里一个社区通常对应一个主题聚簇围绕同一批实体和关系抱团的知识单元。社区就是后续摘要的天然组织单位。2.4 社区摘要生成动机社区是结构单元一堆节点和边但 LLM 没法直接读图。要把图变成 LLM 能消费的东西必须把社区转写成自然语言摘要。方法对每个社区把社区内的实体、关系、描述聚合成一份材料用 LLM 生成一段社区摘要。更进一步社区是有层级的——叶子社区的摘要向上聚合生成父社区的摘要逐层到根得到一棵社区摘要树。Map-Reduce 聚合的理论意义这是 GraphRAG 回答全局问题的根基。摘要逐层压缩越往上粒度越粗根节点最终是整个语料库的一页纸。全局问题“语料库的主要主题是什么”不需要看任何原始块只需要在这棵摘要树上做聚合推理。把不可计算的大图压缩成可计算的全局视图——这就是它区别于一切局部检索范式的本质。与向量 RAG 的根本区别向量 RAG 只能看到与问题相关的块它的视野是局部的GraphRAG 的社区摘要让模型能看到相关的主题以及这个主题在整体中的位置。一个给细节一个给格局。成本提醒摘要生成是索引阶段 Token 消耗的大头社区越多、层次越深成本越高这也是 GraphRAG 落地时最需要规划的地方。3. 在线查询Local Search Global Search索引阶段产出了两套资产精确的图结构用于局部检索和压缩的社区摘要树用于全局检索。查询阶段按问题的信息需求类型分流到两套机制。3.1 Local Search流程问题 → 实体匹配 → 图上定位 → 邻域扩展 → 聚合上下文 → LLM 生成。实体匹配把问题里提到的实体与图中的节点对齐靠向量相似度 字符串匹配把自然语言问题锚定到图上的具体节点。邻域扩展锚定到节点后沿边走扩展邻居。先用 Personalized PageRank 对邻居节点打分排序PPR 衡量从起点出发哪些节点最容易被随机游走走到即谁和问题最相关取 Top-K 作为候选。聚合上下文把候选节点的描述、关联边、所在社区的摘要、以及节点对应的原始文本片段一起拼进上下文交给 LLM 生成带引用的答案。适合事实型问题、围绕特定实体的问题“X 公司的 CEO 是谁”、“X 和 Y 是什么关系”需要精确证据和细节时。3.2 Global Search流程问题 → Map 阶段对相关社区摘要逐份独立问答→ Reduce 阶段聚合生成最终答案。Map 阶段选出与问题最相关的社区摘要按层级和相关性筛选对每一份摘要独立地问同一个问题得到一堆部分答案。Reduce 阶段把所有部分答案聚合起来去重、按相关性评分、合并冲突生成一份覆盖全局的最终答案。适合全局性问题——“这份语料库覆盖了哪些主要主题”、“整体来看有哪些趋势”、“所有提到 X 的地方它们之间有什么共性与关联”。这类问题没有任何单一文本块能回答只有社区摘要层面才有答案。3.3 为什么按问题类型分流两种信息需求一类是精确型需求要具体证据、要细节、要能引用出处一类是覆盖型需求要全貌、要归纳、要跨文档的宏观结论。两者对检索单元的要求截然相反。局部检索给细节但缺覆盖Local 拉的是节点和邻域细节丰富但视野只在一跳两跳之内回答不了整体是什么。全局检索给覆盖但缺细节Global 看到的是摘要层覆盖全语料但拿不到具体到原文的细节过度概括时还可能引入摘要噪音。分流本质用问题的信息粒度和范围决定检索单元。问题问的是一个点用图问的是一整片用摘要树。两套机制是互补的不是二选一的替代品。3.4 适用场景与边界Local 失效的场景问题没有锚定到任何具体实体“总结一下所有客户投诉”——没有实体可定位Local 无从下手。Global 过重的场景简单事实问题用 Global 是浪费成本而且摘要层的概括反而可能引入与事实不符的偏差——问某公司 CEO 是谁就该用 Local精确且便宜。实践上的混合很多系统先对问题做分类路由或两条通道同时跑、结果再融合。分类路由省成本双通道融合更稳但更贵需要按场景取舍。边界提醒Global 的答案质量受社区摘要质量的上限约束。如果社区划分不好或摘要写得空泛全局回答就会大而空——这是 GraphRAG 的隐含天花板。4. GraphRAG vs 普通 RAG vs LLM 直塞上下文把三种范式放在同一张桌上对比本质是看它们如何组织信息、检索什么、能回答什么问题。4.1 三维对比表维度LLM 直塞上下文普通 RAGGraphRAG信息组织原始全文语义分块实体-关系图 社区摘要树检索单元全部内容文本片段节点/路径Local/社区摘要Global多跳推理弱依赖模型隐知识弱强显式关系可遍历全局性问题可以但成本极高几乎不行强社区摘要聚合细节与引用最好无损好命中块内好Local/一般Global 有损上下文成本O(全文)随文档线性爆炸低查询低但索引成本高构建成本无低高抽取 摘要 Token 大头动态更新即时快慢、重可解释性低中高能看到图上的关系路径4.2 理论根源信息组织方式的差异LLM 直塞原文即上下文信息无损、保真度最高。但受上下文窗口限制成本随文档规模线性增长语料一大就不可行——它是把检索问题消解成内存问题内存不够就崩。普通 RAG把检索问题消解成语义近似匹配用分块 向量换来可扩展和低成本。代价是丢掉了结构块与块之间的关联和全局视野——它优化的是局部命中率天生不擅长全局归纳。GraphRAG把检索问题消解成结构 聚合。用图保留关系解决多跳用社区摘要压缩全局解决全局问题。代价是构建阶段的高成本——它用离线重投入换在线强能力。一句话收束三者不是同一个问题的三个答案而是三种信息组织方式各自锁定了擅长的问题类型。选型不是哪个更好而是我的问题属于哪类、我的语料有多大、我能承受多少构建成本。4.3 各自的最佳适用场景 / 结论LLM 直塞文档小到一次能装下、需要最高保真度的场景单篇长文问答、代码库局部理解。别为了上 RAG而上 RAG能塞得下就没必要。普通 RAG大语料 事实型/局部查询 预算敏感客服知识库、产品文档问答。它是性价比之王绝大多数场景的默认选择。GraphRAG大语料 需要全局理解或多跳推理 能承受构建成本企业知识图谱、研究报告库、需要通读全局后总结的场景。它的价值在全局问题和关系推理上这两类问题普通 RAG 无解。结论GraphRAG 不是普通 RAG 的替代品而是能力边界的外扩。工业界的现实形态往往是混合架构——便宜快速的向量检索处理大部分局部问题GraphRAG 处理需要全局视野和关系推理的少数高价值问题两者按问题类型路由。第二章 Graph agent 理论部分5. Graph Agent 是什么5.1 定义以知识图谱为记忆与推理底座的 Agent 系统Graph Agent 不是能查图的聊天机器人而是以知识图谱为核心知识底座、能自主进行检索、推理、规划、甚至更新图谱的 Agent 系统。要理解它先看图在 Agent 里扮演什么角色。普通 Agent 的知识来自两个地方模型参数里固化的知识会过时、会幻觉、不可追溯以及临时挂上去的检索工具一般是向量 RAG只能给局部文本块。Graph Agent 多了一个层次——图作为外置大脑记忆存图里对话和事实的长期记忆以实体-关系的形式落图而不是堆在上下文里推理走图上多跳问题沿着关系路径遍历而不是靠模型隐式猜测答案可追溯每个结论都能回溯到图上的节点、边、以及背后的原始文档Graph Agent 的本质是把图从第一章里的检索数据源升级为Agent 的认知基础设施。5.2 为什么需要单 Agent 的边界 → 图能补什么先看单 Agent哪怕挂了向量 RAG的三个结构性边界记忆边界上下文窗口有限大语料塞不进去长对话里早期信息会丢。向量 RAG 缓解了塞不下但每次检索都像重新翻档案没有积累、没有结构。知识边界参数化知识过时且不可追溯向量 RAG 只能召回相似的文本块给不了实体之间的关系全貌。推理边界多跳关系推理依赖模型的隐式能力链条一长就容易断而且推理过程不可解释——错了你不知道错在哪一环。图恰好补齐这三块单 Agent 的边界图能补什么记忆有限图是长期、结构化、可增量更新的记忆Agent 只按需加载局部知识不可追溯每个实体/关系都有来源文档答案可回溯到证据多跳推理弱且不可解释关系路径显式可遍历推理链每一步都看得见无全局视野社区摘要回扣第一章提供超越局部块的整体理解5.3 与 GraphRAG、普通 Agent 的定位差异三者容易混淆用一张表说清GraphRAG普通 RAG AgentGraph Agent有没有 Agent无固定 Pipeline有能规划/调工具有能规划/调工具知识底座图静态只读文本块向量索引图可读可写、可演进检索方式固定双通道Local/Global向量相似度图遍历 检索 规划按需组合是否自主否一次查询走完流程是自主决定步骤是且能决定何时查图、怎么查、查完是否更新图多跳推理靠图结构但无决策弱强图上遍历 可解释一句话定位GraphRAG 是一种检索范式回答图怎么被查询Agent 是一种决策主体回答谁来决定怎么做而 Graph Agent 是两者的合体——让决策主体把图当作认知底座来使用、维护和演化。GraphRAG 的图是建好就不动的资产Graph Agent 的图是Agent 一边用、一边还在维护的生命体。6. 多 Agent 编排Graph Agent 的图不是天上掉下来的它要被人或 Agent 自己建出来。而建图 用图这件事天然适合拆成多个 Agent 来做——这就是多 Agent 编排。6.1 为什么建图/用图天然适合拆成多 Agent建一条高质量知识图谱的流程每个环节是彼此独立的认知任务输入、输出、失败模式完全不同抽取读文档块、产出三元组上下文是文本——失败模式是漏抽、误抽、幻觉消解判断跨文档的实体是否同一个上下文是实体及描述——失败模式是错并、漏并摘要对社区做归纳上下文是子图结构——失败模式是概括失真、丢细节质检校验整体质量上下文是图 规则——失败模式是误报、漏报如果把这些硬塞进一个 Agent 会怎样抽取的文档和消解的实体混在一个上下文里互相干扰上下文污染某一步出错无法定位是哪个环节错误不可溯源所有步骤串行无法并行没有吞吐。拆成多个 Agent 之后上下文隔离每个 Agent 只看到自己需要的输入注意力不被无关内容稀释独立质检每步产出可以单独校验错误在源头就被拦下可并行文档可以同时交给多个抽取 AgentMap吞吐翻倍可替换某个环节模型选型不合适只换那一个 Agent不动整条链路6.2 Agent 分工抽取 / 消解 / 摘要 / 质检Agent输入输出关键失败模式缓解手段抽取 Agent文本块 Schema 契约三元组实体/关系/属性漏抽、误抽、关系幻觉Schema 约束、分块并行、抽后抽查消解 Agent跨文档实体及描述归一化后的实体合并/去重错误合并污染、漏合并碎片化相似度预筛 判断、阈值校准摘要 Agent社区子图社区检测结果层次化社区摘要概括失真、关键信息丢失摘要粒度分层、抽检与原文比对质检 Agent图 规则 基准质量报告 / 修正建议误报、漏报规则 抽样人工 关键指标门槛注意最后一行质检 Agent 不是可有可无的验收员它是整条编排能自我纠错的前提——没有质检反馈前面的抽取/消解错误会一路放大到检索质量。6.3 编排模式与工程要点三种典型编排模式串行流水线抽取 → 消解 → 建图 → 摘要 → 质检前一环的输出是后一环的输入。流程清晰、依赖强但错误会沿流水线传导放大——所以质检不能只放在最后消解这种关键环节后也要设卡。Map-Reduce 并行文档并行分给多个抽取 AgentMap产出汇合后再统一做消解合并Reduce。大语料场景吞吐高是建图主流程的标配。反馈回路质检 Agent 发现问题后回灌给对应 Agent 重做比如消解合并错了 → 送回消解 Agent 重新判断。这是多 Agent 相比单流水线的关键优势——系统可以自己纠错而不是建完就完。工程上四个要点决定了编排能不能落地Schema 契约Schema 是所有 Agent 之间的接口协议。抽取 Agent 按 Schema 输出消解/建图 Agent 才能消费。Schema 不统一图根本建不起来——它是多 Agent 协作的通信语言。上下文隔离每个 Agent 只看自己该看的输入。既保护注意力也省 token——这是多 Agent 编排最大的隐性收益。成本平衡LLM 调用次数 × token 单价成本随 Agent 数量线性涨。实践上做分级便宜模型做高吞吐的粗抽取贵模型做低吞吐的消解判断和质检把预算花在判断而不是搬运上。错误传导控制抽取的错会放大到下游所有环节所以便宜 快的前提是关键处有闸门——用抽查、规则校验、基准集在关键环节拦住系统性错误。第二章 实战部分7. neo4j 简单使用7.1 图数据库与 Cypher 核心概念Neo4j 是图数据库数据以节点和关系存储查询语言叫Cypher可以理解成图的 SQL。四个核心概念概念含义对应 GraphRAG节点Node一个实体画成圆点三元组里的实体标签Label节点的类型如:Person实体的类型关系Relationship实体之间的边有方向三元组里的关系属性Property节点/关系上的键值对实体的属性/描述在 Neo4j 里建图本质就是把 GraphRAG 抽取的三元组实体, 关系, 实体翻译成节点和边。7.2 创建节点这里我用的数据库版本是neo4j-community-4.4.8jdk用的14。用CREATE创建节点标签用冒号前缀属性用花括号// 创建 2 个 Person 节点、2 个 Company 节点CREATE(a:Person {name:张三,age:30})CREATE(b:Person {name:李四,age:28})CREATE(c:Company {name:小米,city:北京})CREATE(d:Company {name:华为,city:深圳})7.3 创建关系关系用-[:关系类型]-表示方向从左指向右。先MATCH定位已有节点再CREATE连线// 张三 工作于 小米关系也能带属性MATCH(a:Person {name:张三}),(c:Company {name:小米})CREATE(a)-[:WORK_AT {since:2020}]-(c)// 李四 工作于 华为MATCH(b:Person {name:李四}),(d:Company {name:华为})CREATE(b)-[:WORK_AT]-(d)// 小米 与 华为 有合作关系MATCH(c:Company {name:小米}),(d:Company {name:华为})CREATE(c)-[:COOPERATE_WITH]-(d)7.4 查询与可视化全量查看—— 图上直接画出所有节点和关系MATCH(n)RETURNn条件过滤// 查出所有年龄大于 28 的人MATCH(n:Person)WHEREn.age28RETURNn多跳遍历—— 这是图数据库相对关系型数据库的核心优势对应 GraphRAG 的 “多跳推理”。一条语句沿着边连跳两层从 “小米” 出发找到合作的 “华为”再找到 “华为” 里工作的人MATCH(me:Company {name:小米})-[:COOPERATE_WITH]-(partner:Company)-[:WORK_AT]-(person:Person)RETURNme,partner,person(me:小米) -合作- (partner) -工作- (person) 起点 向右合作 中间点 向左工作 终点7.5 更新与删除更新属性用SETMATCH(n:Person {name:张三})SETn.age31RETURNn删除节点用DELETE。注意有关系的节点必须用DETACH DELETE连关系一起删否则报错// 删除李四这个节点及其所有关系MATCH(n:Person {name:李四})DETACHDELETEn7.6 清理清空数据库删光所有节点和关系让数据库回到干净状态// 危险操作删除全部数据演示完再用MATCH(n)DETACHDELETEn8. 简易财报知识图谱问答系统8.1 抽取三元组先设计三元组格式实体类型、关系类型、字段约束。然后写一段规则提示词让 llm 去抽取。提示词参考SYSTEM_PROMPT 你是金融领域知识图谱构建助手。请阅读给定的上市公司年报片段从中提炼可用于建图的三元组记录。 【一、允许的实体类别】严格限定为以下 7 类不得超出 - Company上市公司主体 - Person董事、监事、高管、实际控制人、股东等自然人 - Subsidiary子公司或参股公司 - Product公司主要产品 - Indicator财务类指标如营业收入、净利润、研发投入取值须携带数值与单位 - Segment业务板块或投资项目 - Region经营或业务所涉地区 【二、允许的关系类别】严格限定为以下 8 类不得超出 - REPORTS主体公司 → 财务指标对象须带数值与单位。示例贵州茅台 REPORTS 营业收入1240亿元 - SERVES_AS自然人 → 公司表示任职关系对象固定为公司需在 role 字段注明职务。示例丁雄军 SERVES_AS 贵州茅台role董事长 - CONTROLS自然人/公司 → 公司表示实际控制或控股关系 - HAS_SUBSIDIARY公司 → 子公司需在 ratio 字段注明持股比例。示例宁德时代 HAS_SUBSIDIARY 宁德新能源科技 - PRODUCES公司 → 产品 - OPERATES_IN公司 → 地区 - INVESTS_IN公司 → 业务板块/项目一般表示研发或投资方向 - RELATED_TO关系不明确时的兜底项非必要不使用 【三、输出格式要求】 仅输出一段合法的 JSON不要输出 markdown 代码块或任何解释文字。结构如下 { triples: [ {subject: ..., subject_type: ..., predicate: ..., object: ..., object_type: ..., year: ..., role: null, ratio: null} ] } 字段说明 - subject/object实体名称subject_type/object_type对应上述实体类别 - year信息所属年份 - role仅任职类关系使用其余置 null - ratio仅持股类关系使用其余置 null 【四、抽取守则】 1. 只提取原文明确记载的事实禁止臆测或补充 2. 数字与单位保持原文亿元/万元/元尽量精确 3. 实体名称采用市场通用简称例如贵州茅台酒股份有限公司应写为贵州茅台 4. 若片段中无可提取信息返回 {triples: []} 5. 单个片段一般输出 1~6 条遵循少而准原则8.2 建图在财报知识图谱入库阶段采用 MERGE 幂等写入策略完成节点与关系的导入。节点层面设计唯一标识uid生成规则为实体类型:规范化实体名(小写)并为所有Entity节点建立 uid 唯一约束以此杜绝重复实体同时执行实体规范化对上市公司全称、简称等多种别名映射到统一规范名称防止同一实体被拆分为多个节点。公司节点额外挂载股票代码属性便于精准检索。关系边写入时由于抽取得到的全部财报三元组均携带年份信息因此将年份纳入边的唯一性判定条件。当主体、客体、关系类型一致但年份不同时会生成多条独立的关系边以此保存企业历年动态变化的数据避免历史信息被覆盖。对于角色、持股比例等附加属性采用非空更新策略空字段不会修改边上已有的属性值。节点采用双标签设计统一打上顶层标签Entity再追加对应的实体类型标签Company / Person / Product 等方便按类型筛选实体。defmerge_edge_cypher(pred:str)-str:return(fMATCH (a:Entity {{uid: $src_uid}}), (b:Entity {{uid: $dst_uid}}) fMERGE (a)-[r:{pred} {{year: $year}}]-(b) fSET r.role CASE WHEN $role IS NOT NULL THEN $role ELSE r.role END, f r.ratio CASE WHEN $ratio IS NOT NULL THEN $ratio ELSE r.ratio END)这样就把图建好了如果有连任情况在图中就是有多条边每条边表示一个年份。MATCH(n:Entity{name:马明哲})-[r]-(m)RETURNn,r,mMATCH(n:Person{name:马明哲})-[r]-(m)RETURNn,r,m8.3 社区检测将图谱加载至内存后使用 Leiden 算法完成社区聚类社区编号回写到 Neo4j 节点属性上各个社区的 LLM 摘要单独保存为 JSON 文件用于后续全局检索。跑了社区检测后每个节点上加上了community属性打开本地文件可以看出llm对各个聚类的小结比如3号社区的小结是8.4 检索 Local GlobalLocal‑Search 和 Global‑Search 均使用向量相似度检索但检索目标完全不同。Local Search查询向量与实体名称向量匹配召回最相似实体再从这些实体出发在知识图谱上进行 BFS 多跳扩展抽取局部子图事实交由大模型回答。Global Search查询向量与预先生成的社区摘要向量匹配召回相关性最高的主题社区仅使用社区摘要和少量核心实体列表通过 Map‑Reduce 方式分社区产出要点再聚合全程不读取社区内部完整图谱细节。图数据库的Local search是希望能实现多跳搜索第一种方法是bfs硬搜缺点是节点多时数量爆炸第二种方法是用agent loop的方法每次只搜一跳再发给llm去搜下一跳。我使用的是第二种方法。造一个case来验证当前的graph agent实现了多跳搜索“谢治平任职的公司的23年的总经理是谁”global search 的效果中国平安有哪些高管