文章目录【100.PythonAI】图数据库向量数据库知识图谱增强的RAGGraph RAG导入语1 ~ 短板剖析Chunk化让关系消失2 ~ 知识图谱给RAG补上关系2.1 三元组关系的最小表达2.2 图谱从哪来两条构建路径3 ~ Neo4j向量索引一个库里的两种检索3.1 为什么不用两个数据库3.2 建索引与融合查询3.3 整体架构4 ~ 多跳推理的完整链路4.1 与微软GraphRAG方案的区别5 ~ 投入产出什么场景值得上图谱思考 总结结尾【100.PythonAI】图数据库向量数据库知识图谱增强的RAGGraph RAG文章简介本文系统讲解Graph RAG的原理与落地解决传统向量RAG在多跳关系推理上的结构性短板。文章从一个向量RAG注定答错的查询切入——“A公司供应商的母公司去年营收多少”剖析其根因文档被切成孤立Chunk后实体间的关系信息丢失而答案恰恰藏在关系链里讲解知识图谱如何以实体-关系-实体三元组为RAG补上关系维度以及图谱构建的两条路径人工建模vs大模型自动抽取实体关系深入Neo4j的向量索引能力——一个数据库内同时完成图遍历与向量检索的混合架构附Cypher向量检索的融合查询示例详解多跳推理的实现——从向量检索找到入口实体到沿关系边逐跳扩展再到子图上下文喂给LLM的完整链路以及Graph RAG相对微软GraphRAG社区摘要方案的选型讨论最后给出什么场景值得上图谱的投入产出决策清单。配以Mermaid流程图展示Graph RAG的完整架构适合RAG检索遇到关系类问题瓶颈的开发者阅读参考。 个人主页源码骑士❄专栏传送门《Android开发基础》《python基础课程》⭐️热衷从源码视角拆解技术底层原理将复杂架构讲得通俗易懂 源码骑士的简介5年Android Framework系统开发经验曾主导多项系统级性能优化专项技术栈覆盖Android系统全链路Binder/Handler/AMS/WMS/启动流程及Java后端全家桶Spring MyBatis Redis Oracle累计产出原创技术文章100篇文章以流程图为特色被读者评价为看一篇胜过啃一周源码导入语你的RAG系统已经很能打了语义检索、混合搜索、Rerank精排常规问答准确率九成以上。然后业务方抛来一个看似普通的查询“给我们供货的那家芯片公司它的母公司去年营收多少”系统沉默了。向量库里明明有三份相关文档一份写着XX科技是我们的芯片供应商一份写着XX科技是YY集团的全资子公司还有一份是YY集团年度财报。每份文档单独看都和查询沾边但任何一份都装不下答案——答案必须顺着供应商→母公司→财报这条关系链走两跳才能拼出来。这就是向量RAG的结构性短板文档被切成Chunk的那一刻实体之间的关系就丢了。向量检索擅长找到相似的段落但段落是孤岛它不会顺藤摸瓜。Graph RAG——用知识图谱给RAG补上关系维度——就是为这类问题而生的。1 ~ 短板剖析Chunk化让关系消失向量RAG的信息处理流程 原始文档 → 切Chunk → 各自Embedding → 存向量库 ↑ 关系就死在这一步 Chunk AXX科技是我们的芯片供应商→ 向量α Chunk BXX科技是YY集团的全资子公司→ 向量β Chunk CYY集团去年营收850亿→ 向量γ 查询供应商母公司的营收的向量 → 和α、β、γ各自都有点像 但没有任何一个Chunk单独携带完整答案 → 检索只能召回碎片LLM拿着碎片强行作答 → 幻觉问题的本质向量空间编码的是内容相似性不编码实体关联性。哪怕三个Chunk全部召回模型也未必能意识到它们讲的是同一条链上的事——尤其当三个Chunk被切在不同文档、不同章节里时。一句话记住向量RAG回答关于X是什么的问题Graph RAG回答X和Y通过什么关联的问题。后者需要的不只是文本而是文本背后的关系结构。2 ~ 知识图谱给RAG补上关系2.1 三元组关系的最小表达知识图谱把信息存成实体-关系-实体的三元组(XX科技)—[是供应商]→(我们公司)(XX科技)—[是子公司]→(YY集团)(YY集团)—[发布于2024]→(年报: 营收850亿)同样的三句话进了图谱就不再是三座孤岛而是一张可以走的网从我们公司出发沿供应商边走到XX科技再沿子公司边走到YY集团最后取到财报节点——这就是多跳推理的物理基础。2.2 图谱从哪来两条构建路径路径做法成本适合人工/规则建模业务专家定义SchemaETL从结构化数据导入高但质量可控已有CRM/ERP等结构化数据的企业LLM自动抽取大模型读文档输出三元组自动入库低需质检从非结构化文档冷启动LLM自动抽取是近两年的主流冷启动方式核心就一段PromptEXTRACT_PROMPT从以下文本中抽取实体和关系输出JSON {entities: [{name: ..., type: 公司|人物|产品|概念}], relations: [{subject: ..., predicate: ..., object: ...}]} 要求实体名规范化XX科技和XX科技有限公司统一 关系动词从预定义清单选择。 文本{chunk}质检提示LLM抽取的准确率大约七八成宁可少存不可错存——错的关系比缺的关系危害大得多。抽完入库前让另一个LLM做一轮这条三元组是否有原文依据的校验忠实度检查第53篇的RAGAS思路。3 ~ Neo4j向量索引一个库里的两种检索3.1 为什么不用两个数据库直觉方案是Neo4j存图、Milvus存向量、应用层缝合——能work但两份数据要保持同步、查询要跨库拼装工程复杂度翻倍。Neo4j 5.x的向量索引给出了更优雅的答案图节点上直接挂向量图遍历和语义检索在同一个库里、同一条查询语句里完成。3.2 建索引与融合查询-- 1. 给文档节点建向量索引 CREATE VECTOR INDEX doc_embedding FOR (d:Document) ON d.embedding OPTIONS {indexConfig: {vector.dimensions: 768, vector.similarity_function: cosine}}; -- 2. 混合查询先向量找入口再图遍历扩展 CALL db.index.vector.queryNodes(doc_embedding, 5, $queryVector) YIELD node AS doc, score MATCH (doc)-[:MENTIONS]-(entity:Entity) // 文档提到哪些实体 MATCH path (entity)-[*1..2]-(related:Entity) // 沿关系走1~2跳 RETURN doc, entity, related, path, score;这条查询一条语句干完了两件事向量检索负责从语义找到入口图遍历负责从入口顺藤摸瓜——两者在一个事务里完成没有跨库缝合。3.3 整体架构用户查询: 供应商母公司营收?查询向量化Neo4j向量索引找到最相关的文档/实体入口图遍历: 沿关系边1~2跳扩展子图子图结构化实体关系关联文档原文组装上下文子图信息相关ChunkLLM生成基于完整关系链作答答案附关系路径可解释、可溯源文档入库LLM抽取三元组实体/关系入图Chunk向量入向量索引注意最后那个输出特性答案可以附上推理路径“XX科技→子公司→YY集团→财报”这是纯向量RAG给不了的可解释性——企业场景里答案从哪来和答案是什么同样重要。4 ~ 多跳推理的完整链路把上一节的架构拆成逐步动作一个两跳查询的完整生命周期Step1入口定位查询向量 → 向量索引 → 命中供应商相关实体XX科技 Step2图扩展 XX科技 --子公司--YY集团 --发布--年报节点 Step3上下文组装 - 子图三元组(XX科技,子公司,YY集团),(YY集团,发布,2024年报)- 关联Chunk年报中营收850亿原文段落 Step4生成LLM基于结构化子图原文给出带推理路径的答案和纯向量RAG的本质差异在Step 2向量RAG的上下文是检索出来的一堆段落Graph RAG的上下文是遍历出来的一张小网——网里的每个节点都带着和其他节点的关系标注LLM不需要猜段落间的联系联系就写在上下文里。4.1 与微软GraphRAG方案的区别市面上还有一个常被混淆的方案微软开源的GraphRAG。两者思路不同别混用本文方案检索时遍历微软GraphRAG离线摘要图谱用途查询时实时遍历找关系离线时做社区聚类摘要擅长实体关系明确的多跳问题这个数据集整体讲什么的全局概览问题成本查询时开销略增离线构建开销大全库LLM摘要组合建议中小企业首选见效直接数据量大且有全局问答需求时叠加5 ~ 投入产出什么场景值得上图谱Graph RAG不是免费午餐——图谱构建和维护是实打实的成本。决策清单值得上图谱的信号中两条再动手 □ 查询里大量出现A和B是什么关系X的上游/下游是谁 □ 答案经常横跨多份文档单文档装不下 □ 业务本身是关系密集型的供应链、股权结构、 医药相互作用、社交网络、风控关联 □ 对答案的可解释性/可溯源有硬性要求合规审计 反之文档以独立知识点为主FAQ、规章制度、产品说明 → 纯向量混合搜索足够图谱是过度设计务实的落地节奏先纯向量RAG上线 → 收集badcase → 发现关系类问题占比超过两成 → 再引入图谱。用真实数据驱动架构升级而不是被概念热度推着走。思考 总结向量RAG的结构性短板Chunk化切断了实体关系顺着关系链找答案的多跳问题检索碎片再多也拼不出完整答案。三元组补上关系维度实体-关系-实体让文档从孤岛连成网多跳推理有了物理基础LLM自动抽取忠实度校验是冷启动的现实路径。Neo4j向量索引一库两检索向量找入口、图遍历做扩展一条Cypher完成免去双库同步的缝合成本。两种Graph RAG别混淆检索时遍历本文擅长明确关系的多跳问题微软GraphRAG离线社区摘要擅长全局概览问题。上图谱要算投入产出关系类badcase占比超两成再动手纯知识点文档用向量混合搜索就够警惕为概念买单。到这里向量数据库与语义搜索板块也接近尾声。下一篇我们换一个视角聊聊向量库的性能压榨从100 QPS到10000 QPS索引、硬件、缓存、分区的全链路调优路径。结尾各位小伙伴本文的内容到这里就全部结束了源码骑士在这里再次感谢您的阅读源码骑士 — Android Framework 全栈开发关注跟博主一起从源码视角深耕底层原理见证每一次成长❤️点赞让优质内容被更多人看见让知识传递更有力量⭐收藏把核心知识点存好在需要时随时查、随时用评论分享你的经验或疑问评论区一起交流避坑一键四连不要忘记给博主一键四连哦️寄语技术之路难免有困惑但同行的人会让前进更有方向结语文本承载知识关系承载智慧——向量RAG教会机器读懂每一页Graph RAG教会机器看清页与页之间的线。两条技术路线的交汇点正是下一代知识系统的起点。不要忘记给博主一键四连哦 100-图数据库加向量数据库-Neo4j向量索引-多跳推理-Graph-RAG原理
文章目录【100.PythonAI】图数据库向量数据库知识图谱增强的RAGGraph RAG导入语1 ~ 短板剖析Chunk化让关系消失2 ~ 知识图谱给RAG补上关系2.1 三元组关系的最小表达2.2 图谱从哪来两条构建路径3 ~ Neo4j向量索引一个库里的两种检索3.1 为什么不用两个数据库3.2 建索引与融合查询3.3 整体架构4 ~ 多跳推理的完整链路4.1 与微软GraphRAG方案的区别5 ~ 投入产出什么场景值得上图谱思考 总结结尾【100.PythonAI】图数据库向量数据库知识图谱增强的RAGGraph RAG文章简介本文系统讲解Graph RAG的原理与落地解决传统向量RAG在多跳关系推理上的结构性短板。文章从一个向量RAG注定答错的查询切入——“A公司供应商的母公司去年营收多少”剖析其根因文档被切成孤立Chunk后实体间的关系信息丢失而答案恰恰藏在关系链里讲解知识图谱如何以实体-关系-实体三元组为RAG补上关系维度以及图谱构建的两条路径人工建模vs大模型自动抽取实体关系深入Neo4j的向量索引能力——一个数据库内同时完成图遍历与向量检索的混合架构附Cypher向量检索的融合查询示例详解多跳推理的实现——从向量检索找到入口实体到沿关系边逐跳扩展再到子图上下文喂给LLM的完整链路以及Graph RAG相对微软GraphRAG社区摘要方案的选型讨论最后给出什么场景值得上图谱的投入产出决策清单。配以Mermaid流程图展示Graph RAG的完整架构适合RAG检索遇到关系类问题瓶颈的开发者阅读参考。 个人主页源码骑士❄专栏传送门《Android开发基础》《python基础课程》⭐️热衷从源码视角拆解技术底层原理将复杂架构讲得通俗易懂 源码骑士的简介5年Android Framework系统开发经验曾主导多项系统级性能优化专项技术栈覆盖Android系统全链路Binder/Handler/AMS/WMS/启动流程及Java后端全家桶Spring MyBatis Redis Oracle累计产出原创技术文章100篇文章以流程图为特色被读者评价为看一篇胜过啃一周源码导入语你的RAG系统已经很能打了语义检索、混合搜索、Rerank精排常规问答准确率九成以上。然后业务方抛来一个看似普通的查询“给我们供货的那家芯片公司它的母公司去年营收多少”系统沉默了。向量库里明明有三份相关文档一份写着XX科技是我们的芯片供应商一份写着XX科技是YY集团的全资子公司还有一份是YY集团年度财报。每份文档单独看都和查询沾边但任何一份都装不下答案——答案必须顺着供应商→母公司→财报这条关系链走两跳才能拼出来。这就是向量RAG的结构性短板文档被切成Chunk的那一刻实体之间的关系就丢了。向量检索擅长找到相似的段落但段落是孤岛它不会顺藤摸瓜。Graph RAG——用知识图谱给RAG补上关系维度——就是为这类问题而生的。1 ~ 短板剖析Chunk化让关系消失向量RAG的信息处理流程 原始文档 → 切Chunk → 各自Embedding → 存向量库 ↑ 关系就死在这一步 Chunk AXX科技是我们的芯片供应商→ 向量α Chunk BXX科技是YY集团的全资子公司→ 向量β Chunk CYY集团去年营收850亿→ 向量γ 查询供应商母公司的营收的向量 → 和α、β、γ各自都有点像 但没有任何一个Chunk单独携带完整答案 → 检索只能召回碎片LLM拿着碎片强行作答 → 幻觉问题的本质向量空间编码的是内容相似性不编码实体关联性。哪怕三个Chunk全部召回模型也未必能意识到它们讲的是同一条链上的事——尤其当三个Chunk被切在不同文档、不同章节里时。一句话记住向量RAG回答关于X是什么的问题Graph RAG回答X和Y通过什么关联的问题。后者需要的不只是文本而是文本背后的关系结构。2 ~ 知识图谱给RAG补上关系2.1 三元组关系的最小表达知识图谱把信息存成实体-关系-实体的三元组(XX科技)—[是供应商]→(我们公司)(XX科技)—[是子公司]→(YY集团)(YY集团)—[发布于2024]→(年报: 营收850亿)同样的三句话进了图谱就不再是三座孤岛而是一张可以走的网从我们公司出发沿供应商边走到XX科技再沿子公司边走到YY集团最后取到财报节点——这就是多跳推理的物理基础。2.2 图谱从哪来两条构建路径路径做法成本适合人工/规则建模业务专家定义SchemaETL从结构化数据导入高但质量可控已有CRM/ERP等结构化数据的企业LLM自动抽取大模型读文档输出三元组自动入库低需质检从非结构化文档冷启动LLM自动抽取是近两年的主流冷启动方式核心就一段PromptEXTRACT_PROMPT从以下文本中抽取实体和关系输出JSON {entities: [{name: ..., type: 公司|人物|产品|概念}], relations: [{subject: ..., predicate: ..., object: ...}]} 要求实体名规范化XX科技和XX科技有限公司统一 关系动词从预定义清单选择。 文本{chunk}质检提示LLM抽取的准确率大约七八成宁可少存不可错存——错的关系比缺的关系危害大得多。抽完入库前让另一个LLM做一轮这条三元组是否有原文依据的校验忠实度检查第53篇的RAGAS思路。3 ~ Neo4j向量索引一个库里的两种检索3.1 为什么不用两个数据库直觉方案是Neo4j存图、Milvus存向量、应用层缝合——能work但两份数据要保持同步、查询要跨库拼装工程复杂度翻倍。Neo4j 5.x的向量索引给出了更优雅的答案图节点上直接挂向量图遍历和语义检索在同一个库里、同一条查询语句里完成。3.2 建索引与融合查询-- 1. 给文档节点建向量索引 CREATE VECTOR INDEX doc_embedding FOR (d:Document) ON d.embedding OPTIONS {indexConfig: {vector.dimensions: 768, vector.similarity_function: cosine}}; -- 2. 混合查询先向量找入口再图遍历扩展 CALL db.index.vector.queryNodes(doc_embedding, 5, $queryVector) YIELD node AS doc, score MATCH (doc)-[:MENTIONS]-(entity:Entity) // 文档提到哪些实体 MATCH path (entity)-[*1..2]-(related:Entity) // 沿关系走1~2跳 RETURN doc, entity, related, path, score;这条查询一条语句干完了两件事向量检索负责从语义找到入口图遍历负责从入口顺藤摸瓜——两者在一个事务里完成没有跨库缝合。3.3 整体架构用户查询: 供应商母公司营收?查询向量化Neo4j向量索引找到最相关的文档/实体入口图遍历: 沿关系边1~2跳扩展子图子图结构化实体关系关联文档原文组装上下文子图信息相关ChunkLLM生成基于完整关系链作答答案附关系路径可解释、可溯源文档入库LLM抽取三元组实体/关系入图Chunk向量入向量索引注意最后那个输出特性答案可以附上推理路径“XX科技→子公司→YY集团→财报”这是纯向量RAG给不了的可解释性——企业场景里答案从哪来和答案是什么同样重要。4 ~ 多跳推理的完整链路把上一节的架构拆成逐步动作一个两跳查询的完整生命周期Step1入口定位查询向量 → 向量索引 → 命中供应商相关实体XX科技 Step2图扩展 XX科技 --子公司--YY集团 --发布--年报节点 Step3上下文组装 - 子图三元组(XX科技,子公司,YY集团),(YY集团,发布,2024年报)- 关联Chunk年报中营收850亿原文段落 Step4生成LLM基于结构化子图原文给出带推理路径的答案和纯向量RAG的本质差异在Step 2向量RAG的上下文是检索出来的一堆段落Graph RAG的上下文是遍历出来的一张小网——网里的每个节点都带着和其他节点的关系标注LLM不需要猜段落间的联系联系就写在上下文里。4.1 与微软GraphRAG方案的区别市面上还有一个常被混淆的方案微软开源的GraphRAG。两者思路不同别混用本文方案检索时遍历微软GraphRAG离线摘要图谱用途查询时实时遍历找关系离线时做社区聚类摘要擅长实体关系明确的多跳问题这个数据集整体讲什么的全局概览问题成本查询时开销略增离线构建开销大全库LLM摘要组合建议中小企业首选见效直接数据量大且有全局问答需求时叠加5 ~ 投入产出什么场景值得上图谱Graph RAG不是免费午餐——图谱构建和维护是实打实的成本。决策清单值得上图谱的信号中两条再动手 □ 查询里大量出现A和B是什么关系X的上游/下游是谁 □ 答案经常横跨多份文档单文档装不下 □ 业务本身是关系密集型的供应链、股权结构、 医药相互作用、社交网络、风控关联 □ 对答案的可解释性/可溯源有硬性要求合规审计 反之文档以独立知识点为主FAQ、规章制度、产品说明 → 纯向量混合搜索足够图谱是过度设计务实的落地节奏先纯向量RAG上线 → 收集badcase → 发现关系类问题占比超过两成 → 再引入图谱。用真实数据驱动架构升级而不是被概念热度推着走。思考 总结向量RAG的结构性短板Chunk化切断了实体关系顺着关系链找答案的多跳问题检索碎片再多也拼不出完整答案。三元组补上关系维度实体-关系-实体让文档从孤岛连成网多跳推理有了物理基础LLM自动抽取忠实度校验是冷启动的现实路径。Neo4j向量索引一库两检索向量找入口、图遍历做扩展一条Cypher完成免去双库同步的缝合成本。两种Graph RAG别混淆检索时遍历本文擅长明确关系的多跳问题微软GraphRAG离线社区摘要擅长全局概览问题。上图谱要算投入产出关系类badcase占比超两成再动手纯知识点文档用向量混合搜索就够警惕为概念买单。到这里向量数据库与语义搜索板块也接近尾声。下一篇我们换一个视角聊聊向量库的性能压榨从100 QPS到10000 QPS索引、硬件、缓存、分区的全链路调优路径。结尾各位小伙伴本文的内容到这里就全部结束了源码骑士在这里再次感谢您的阅读源码骑士 — Android Framework 全栈开发关注跟博主一起从源码视角深耕底层原理见证每一次成长❤️点赞让优质内容被更多人看见让知识传递更有力量⭐收藏把核心知识点存好在需要时随时查、随时用评论分享你的经验或疑问评论区一起交流避坑一键四连不要忘记给博主一键四连哦️寄语技术之路难免有困惑但同行的人会让前进更有方向结语文本承载知识关系承载智慧——向量RAG教会机器读懂每一页Graph RAG教会机器看清页与页之间的线。两条技术路线的交汇点正是下一代知识系统的起点。不要忘记给博主一键四连哦