前言随着大型语言模型LLMs在各种应用中的广泛使用如何提升其回答的准确性和相关性成为一个关键问题。检索增强生成RAG技术通过整合外部知识库为 LLMs 提供了额外的背景信息有效地改善了模型的幻觉、领域知识不足等问题。然而仅依靠简单的 RAG 范式存在一定的局限性尤其在处理复杂的实体关系和多跳问题时模型往往难以提供准确的回答。将知识图谱KG引入 RAG 系统为解决这一问题提供了新的路径。知识图谱通过结构化的方式呈现实体及其关系能够在检索过程中提供更为精细的上下文信息。通过利用 KG 的丰富关系性数据RAG 不仅能够更精准地定位相关知识还能更好地处理复杂的问答场景如对比实体间的关系或回答多跳问题。Comparision between Direct LLM, RAG, and GraphRAG.https://arxiv.org/pdf/2408.08921然而当前的 KG-RAG 还处在早期的探索阶段行业对相关技术路线还未达成统一共识。比如如何有效检索知识图谱中的相关 entities 和 relationships如何将向量相似性搜索和图结构结合起来目前没有形成统一的范式。比如微软的 From Local to Global 使用大量的 LLM 访问将子图结构以汇总成社区摘要但这一过程消耗大量的 LLM tokens使这一方法昂贵且不切实际。HippoRAG 使用 Personalized PageRank 重新更新图节点的权重以找到重要的 entities但这种以 entity 为中心的方法很容易受到 NER 遗漏的影响而忽略了上下文中的其它信息。IRCoT 使用多步 LLM 请求来逐步推理得到最终的回答但这种方法将 LLM 引入多跳查找过程导致回答问题的时间过长很难实际应用。我们发现实际上用一个简单的多路召回然后 rerank 的 RAG 范式就能够很好的处理复杂的多跳 KG-RAG 场景而并不需要过多的 LLM 开销和任何图算法。Our simple pipeline is not much different from the common multi-way retrieval and rerank architecture, but it can achieve the SoTA performance in the multihop graph RAG scenario.尽管使用很简单的架构但我们的方法显著超过目前 state-of-the-art 的解决方案比如 HippoRAG并且仅仅需要用到向量存储和少量的 LLM 开销。我们首先引入我们方法的理论基础然后介绍具体方法过程。理 论我们观察到在实际的 KG-RAG 场景中存在跳数有限性假设在 KG-based RAG 中实际问的 query 问题的查询路由只需要在知识图谱中进行有限的且很少的跳数如少于 4 跳的查询而并不需要在其中进行非常多次跳数。我们的跳数有限性假设基于两点很重要的观察1. query 复杂度有限性 2.“捷径”的局部 dense 结构。query 复杂度有限性用户的一个提问 query不太可能涉及到非常多的 entities或者引入复杂的 relationships。否则这个问题会显得非常奇怪和不切实际。Normal query vs. Weird query这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】正常的query“爱因斯坦获得诺贝尔奖的时间是哪一年”In which year did Einstein win the Nobel Prize?知识图谱中的查询路径找到节点“爱因斯坦”。跳转到与“爱因斯坦”相关的“诺贝尔奖”节点。返回奖项颁发的年份信息。跳数2 跳说明这是一个常见的用户问题用户想要知道的是与某个具体实体直接相关的单一事实。知识图谱在这种情况下只需要进行少量跳数的查询即可完成任务因为所有相关信息都直接与爱因斯坦这个中心节点关联。这种查询在实际应用中非常普遍例如查询名人背景信息、奖项历史、事件时间等。古怪的query“相对论的发现者获得诺贝尔奖的年份与他们在一个以银行保密法和阿尔卑斯山壮丽风景而闻名的国家发明的专利数量之间有什么关系”What is the relationship between the year the discoverer of the theory of relativity received the Nobel Prize and the number of patents they invented in a country famous for its bank secrecy laws and the magnificent scenery of the Alps?知识图谱中的查询路径找到“相对论”的“发明者”是“爱因斯坦”。跳转到与“爱因斯坦”相关的“诺贝尔奖”节点。查找“诺贝尔奖”获奖年份。通过“银行保密法和阿尔卑斯山”找到“瑞士”跳转到与“爱因斯坦”相关的“专利”节点。查找与瑞士期间相关的专利信息。比较专利数量和获奖年份之间的关系。跳数7跳说明这个问题较为复杂要求不仅仅是查询单一的事实还涉及多个节点之间的复杂关联。这种问题在实际场景中不太常见因为用户一般不倾向于在一次查询中寻求如此复杂的信息交叉。通常这类问题会被分解为多个简单查询以便逐步获取信息。“捷径”的局部 dense 结构知识图谱中是一个存在一些局部 dense 结构对于有些 query有一些“捷径”可以从一个 entity 通过捷径快速连接到多跳之外的 entity。“Shortcuts” structure假设我们有一个家庭关系的知识图谱包含以下实体和关系Alex是Brian的孩子 (Alex - child_of - Brian)Cole嫁给了Brian(Cole - married_to - Brian)Daniel是Cole的哥哥 (Daniel - brother_of - Cole)Daniel是Alex的舅舅 (Daniel - uncle_of - Alex)这是一个包含冗余信息的密集型的知识图谱。显然可以通过前三条 relationships 推导出最后一条 relationship。但知识图谱中往往存在一些这种冗余信息的捷径。这些捷径可以减少一些 entities 之间的跳数。基于这两点观察我们发现有限次数的在知识图谱内的路由查找过程只涉及到局部的知识图谱信息。因此将 query 进行知识图谱内信息检索的过程可以用下面这两步来实现路由的起点可以通过向量相似性查找来完成。可以涉及到 query 与 entities 或 query 与 relationships 的相似度关系查找。从起点找到其它信息的路由过程可以用一个 LLM 来代替完成。将这些备选信息放进 prompt 里依托 LLM 强大的自注意力机制来挑选有价值的路由。由于 prompt 长度有限所以只能将局部知识图谱的信息放入比如起点附近限定跳数内的知识图谱信息这一点是正好可以由跳数有限性来保证。整个过程不需要其任何它的 KG 存储和复杂的 KG 查询语句只需要使用 vector database 和一次 LLM 的访问。而 vector retrieval LLM rerank 才是这个 pipeline 中最关键的部分这也就解释了我们只用一个传统的两路召回架构就可以达到远超基于图理论的方法如 HippoRAG 的表现。这也说明了实际上不需要复杂的图算法我们只需要将图结构的逻辑关系存储在向量数据库里用一个传统的架构就可以进行逻辑上的子图路由而现代 LLM 强大的能力帮助做到了这一点。方法概览我们的方法只涉及在 RAG 流程中检索 passages 的阶段不涉及 chunking 或 LLM response generation 的创新和优化。我们假设已经得到了一组 corpus 的三元组信息它包含一系列的 entities 和 relationships 信息。这些信息可以表示一个知识图谱的信息。我们将 entities, relationships 信息分别进行向量化并存储在向量存储里这样存储了一个逻辑上的知识图谱。当进行 query 查询时会先把相关的 entities 和 relationships 检索出来。通过这些 entities 和 relationships我们在图结构上进行有限的拓展。将这些 relationships 与 query 问题组装进 prompt 内使用 LLM 的能力对这些 relationships 进行 reranking。最后得到 topK 个重要的 relationships在他们的 metadata 信息内获得与他们相关的 passages作为最终的 retrieved passages。Overall pipeline of our method方法详解4.1. 向量入库我们准备两个向量存储 collections一个是 entity collection另一个是 relationship collection。将一系列的 unique entities 信息和 relationships 信息使用 embedding 模型转换成向量存储在向量存储中。对于 entities 信息直接将他们的字符描述转换成 embedding。对于 relationships 的原始数据形式它的结构是一个三元组(Subject, Predicate, Object)我们启发性地直接将它们合并成一个句子“Subject Predicate Object”比如(Alex, child of, Brian) - “Alex child of Brian”(Cole, married to, Brian) - “Cole married to Bria”然后直接将这个句子转换成 embedding然后存储在向量数据库里。这种做法方便且直接虽然这样做可能存在少量的语法问题但这不影响句子含义的表达也不影响它在向量空间中的分布。当然我们同样也鼓励在前期抽取三元组的时候直接使用 LLM 生成简短的句子描述。4.2. 向量相似搜索对于输入的 Query我们遵循常见的 GraphRAG 中的范式如 HippoRAGMS GraphRAG将 query 提取 entities对于每个 query entity转换成 embedding分别对 entity collection 进行 vector similarity search。然后将所有 query entities 搜索得到的结果进行合并。对于 relationship 的向量搜索我们直接将 query string转换成 embedding对 relationship collection 进行 vector similarity search。4.3. 扩展子图Expanding subgraph from two retrieved ways, then merged them together我们以搜索到的 entities 和 relationships 为知识图谱里的起始往外扩大一定的范围。对于起始 entities我们往外扩大一定的跳数后取它们邻接的 relationships记为对于起始 relationships我们往外扩大一定跳数得到我们将两个 set 取并集基于跳数有限性我们仅需要扩大较小的度数如 12 等就能涵盖大部分可能有助回答的 relationships。请注意这一步扩展的度数的概念和回答问题总共需要的跳度的概念不同。比如如果回答一个 query 问题涉及两个相差 n 跳的 entities那么实际上往往只需要扩展 ⌈n / 2⌉ 度就可以因为这两个 entities 是被向量相似召回后的两个起始端点。如图向量召回到了两个红色的 entities只需要从它们开始相向扩展 2 度就能覆盖到 4 度的跳数这足以回答涉及到这两个 entities 的 4 跳问题。In fact, to answer the question with 4 degree hops, you only need to expand it by 2 degrees from both end points in the setting.4.4. LLM Rerank这一步中我们使用 LLM 强大的自注意力机制完成对 relationships 候选集的进一步筛选。我们使用 one-shot prompt将 query 和 relationships 候选集放入 prompt 里要求 LLM 从中选择出可能对回答这个 query 有帮助的 relationships。考虑到有些 query 可能存在一定的复杂性我们采用 Chain-of-Thought 的思想让 LLM 的回答里写下思考过程我们观察到这一方法对一些偏弱的模型有一些帮助。我们规定 LLM 的返回为 json 格式以便于解析格式。具体的 prompt 参考如下One shot input promptI will provide you with a list of relationship descriptions. Your task is to select 3 relationships that may be useful to answer the given question. Please return a JSON object containing your thought process and a list of the selected relationships in order of their relevance. **Question:**When was the mother of the leader of the Third Crusade born? **Relationship descriptions:**[1] Eleanor was born in 1122.[2] Eleanor married King Louis VII of France.[3] Eleanor was the Duchess of Aquitaine.[4] Eleanor participated in the Second Crusade.[5] Eleanor had eight children.[6] Eleanor was married to Henry II of England.[7] Eleanor was the mother of Richard the Lionheart.[8] Richard the Lionheart was the King of England.[9] Henry II was the father of Richard the Lionheart.[10] Henry II was the King of England.[11] Richard the Lionheart led the Third Crusade.One shot input prompt { thought_process: To answer the question about the birth of the mother of the leader of the Third Crusade, I first need to identify who led the Third Crusade and then determine who his mother was. After identifying his mother, I can look for the relationship that mentions her birth., useful_relationships: [ [11] Richard the Lionheart led the Third Crusade, [7] Eleanor was the mother of Richard the Lionheart, [1] Eleanor was born in 1122 ]}这个 prompt 是一个展示的参考实际上如何把 relationships 中的三元组转成一个通顺的短句是一个棘手的问题。但是你完全可以用上文提到的启发性的方法把三元组直接拼在一起。如(Eleanor, born in, 1122) 可以直接转成 Eleanor born in 1122这种方式有时会带来一定的语法问题但它是最快最直接的方式也不会对 LLM 带来误解。4.5. 获得最终 passages对于上面的例子实际上可以在 LLM rerank 这个阶段直接返回最终的回答比如在 One shot output prompt 的 json 字段里加上比如 “final answer”的字段。但是这一步的 prompt 里只有 relationship 的信息不一定所有问题都可以在这个阶段返回最终答案所以其它具体的信息应该要在原始的 passsage 里获得。LLM 返回精确排序后的 relationships。我们只需要取出先前在存储中的对应 relationship 信息从中获取相应的 metadata在那里有对应的 passage ids。这些 passages 信息就是最终被 retrieved 到的 passages。后续生成回答的过程和 naive RAG 一样就是将它们放入 prompt 的 context 中让 LLM 给出最后的回答。结 果我们使用与 HippoRAG 中一致的 dense embeddingfacebook/contriever来作为我们的 embedding 模型可以看到在三个 multi-hop 的数据集上结果比较上我们的方法大幅超过 naive RAG 和 HippoRAG 的结果。所有的方法使用相同的 embedding 模型设置。我们使用 Recall2 作为我们的衡量指标它表示Recall召回率 检索到的相关文档总数 / 数据存储中相关文档总数On the multi-hop datasets, our method outperforms naive RAG and HippoRAG in all datasets, all of them are compared using the same facebook/contriever embedding model.这一结果说明了即使是最简单的多路召回然后 rerank 的 RAG 范式应用在 graph RAG 的场景上也能得到 state-of-the-art 的 performance。这一结果也说明了合理的向量召回和 LLM 设置是应用在 multi-hop QA 场景中的关键。回顾我们的方法把 entities 和 relationships 转成向量并进行搜索的作用就是寻找子图的起点它像是破解刑侦案件中的现场发现的“线索”。而后面扩展子图和 LLM rerank 的过程像是具体通过这些“线索”进行分析的过程LLM 拥有“上帝视角”可以在一众的候选 relationships 中聪明地选择对破案有用的 relationships。这两个阶段回归本质也就是对应朴素的 vector retrieval LLM reranking 范式。在实践中我们推荐大家使用开源 Milvus或它的全托管版本 Zilliz Cloud来存储并搜索 graph 结构中大量的 entities 和 relationships。而 LLM 可以选择开源模型如 Llama-3.1-70B 或闭源的 GPT-4o mini中等以上规模的模型都能胜任这些任务。你也可以参考我们的 notebook 代码示例https://milvus.io/docs/graph_rag_with_milvus.md以获得更多实现的细节。0基础怎么学习AI大模型我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】第一阶段从大模型系统设计入手讲解大模型的主要方法第二阶段在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用第三阶段大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统第四阶段大模型知识库应用开发以LangChain框架为例构建物流行业咨询智能问答系统第五阶段大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型第六阶段以SD多模态大模型为主搭建了文生图小程序案例第七阶段以大模型平台应用与开发为主通过星火大模型文心大模型等成熟大模型构建大模型行业应用。学会后的收获• 基于大模型全栈工程实现前端、后端、产品经理、设计、数据分析等通过这门课可获得不同能力• 能够利用大模型解决相关实际项目需求 大数据时代越来越多的企业和机构需要处理海量数据利用大模型技术可以更好地处理这些数据提高数据分析和决策的准确性。因此掌握大模型应用开发技能可以让程序员更好地应对实际项目需求• 基于大模型和企业数据AI应用开发实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能 学会Fine-tuning垂直训练大模型数据准备、数据蒸馏、大模型部署一站式掌握• 能够完成时下热门大模型垂直领域模型训练能力提高程序员的编码能力 大模型应用开发需要掌握机器学习算法、深度学习框架等技术这些技术的掌握可以提高程序员的编码能力和分析能力让程序员更加熟练地编写高质量的代码。1.AI大模型学习路线图2.100套AI大模型商业化落地方案3.100集大模型视频教程4.200本大模型PDF书籍5.LLM面试题合集6.AI产品经理资源合集获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】 
长河君 · 2026/8/27 14:10:52 · 阅读 1.2k 【AI大模型】知识图谱融入向量数据库，带来 RAG 效果飞升！
前言随着大型语言模型LLMs在各种应用中的广泛使用如何提升其回答的准确性和相关性成为一个关键问题。检索增强生成RAG技术通过整合外部知识库为 LLMs 提供了额外的背景信息有效地改善了模型的幻觉、领域知识不足等问题。然而仅依靠简单的 RAG 范式存在一定的局限性尤其在处理复杂的实体关系和多跳问题时模型往往难以提供准确的回答。将知识图谱KG引入 RAG 系统为解决这一问题提供了新的路径。知识图谱通过结构化的方式呈现实体及其关系能够在检索过程中提供更为精细的上下文信息。通过利用 KG 的丰富关系性数据RAG 不仅能够更精准地定位相关知识还能更好地处理复杂的问答场景如对比实体间的关系或回答多跳问题。Comparision between Direct LLM, RAG, and GraphRAG.https://arxiv.org/pdf/2408.08921然而当前的 KG-RAG 还处在早期的探索阶段行业对相关技术路线还未达成统一共识。比如如何有效检索知识图谱中的相关 entities 和 relationships如何将向量相似性搜索和图结构结合起来目前没有形成统一的范式。比如微软的 From Local to Global 使用大量的 LLM 访问将子图结构以汇总成社区摘要但这一过程消耗大量的 LLM tokens使这一方法昂贵且不切实际。HippoRAG 使用 Personalized PageRank 重新更新图节点的权重以找到重要的 entities但这种以 entity 为中心的方法很容易受到 NER 遗漏的影响而忽略了上下文中的其它信息。IRCoT 使用多步 LLM 请求来逐步推理得到最终的回答但这种方法将 LLM 引入多跳查找过程导致回答问题的时间过长很难实际应用。我们发现实际上用一个简单的多路召回然后 rerank 的 RAG 范式就能够很好的处理复杂的多跳 KG-RAG 场景而并不需要过多的 LLM 开销和任何图算法。Our simple pipeline is not much different from the common multi-way retrieval and rerank architecture, but it can achieve the SoTA performance in the multihop graph RAG scenario.尽管使用很简单的架构但我们的方法显著超过目前 state-of-the-art 的解决方案比如 HippoRAG并且仅仅需要用到向量存储和少量的 LLM 开销。我们首先引入我们方法的理论基础然后介绍具体方法过程。理 论我们观察到在实际的 KG-RAG 场景中存在跳数有限性假设在 KG-based RAG 中实际问的 query 问题的查询路由只需要在知识图谱中进行有限的且很少的跳数如少于 4 跳的查询而并不需要在其中进行非常多次跳数。我们的跳数有限性假设基于两点很重要的观察1. query 复杂度有限性 2.“捷径”的局部 dense 结构。query 复杂度有限性用户的一个提问 query不太可能涉及到非常多的 entities或者引入复杂的 relationships。否则这个问题会显得非常奇怪和不切实际。Normal query vs. Weird query这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】正常的query“爱因斯坦获得诺贝尔奖的时间是哪一年”In which year did Einstein win the Nobel Prize?知识图谱中的查询路径找到节点“爱因斯坦”。跳转到与“爱因斯坦”相关的“诺贝尔奖”节点。返回奖项颁发的年份信息。跳数2 跳说明这是一个常见的用户问题用户想要知道的是与某个具体实体直接相关的单一事实。知识图谱在这种情况下只需要进行少量跳数的查询即可完成任务因为所有相关信息都直接与爱因斯坦这个中心节点关联。这种查询在实际应用中非常普遍例如查询名人背景信息、奖项历史、事件时间等。古怪的query“相对论的发现者获得诺贝尔奖的年份与他们在一个以银行保密法和阿尔卑斯山壮丽风景而闻名的国家发明的专利数量之间有什么关系”What is the relationship between the year the discoverer of the theory of relativity received the Nobel Prize and the number of patents they invented in a country famous for its bank secrecy laws and the magnificent scenery of the Alps?知识图谱中的查询路径找到“相对论”的“发明者”是“爱因斯坦”。跳转到与“爱因斯坦”相关的“诺贝尔奖”节点。查找“诺贝尔奖”获奖年份。通过“银行保密法和阿尔卑斯山”找到“瑞士”跳转到与“爱因斯坦”相关的“专利”节点。查找与瑞士期间相关的专利信息。比较专利数量和获奖年份之间的关系。跳数7跳说明这个问题较为复杂要求不仅仅是查询单一的事实还涉及多个节点之间的复杂关联。这种问题在实际场景中不太常见因为用户一般不倾向于在一次查询中寻求如此复杂的信息交叉。通常这类问题会被分解为多个简单查询以便逐步获取信息。“捷径”的局部 dense 结构知识图谱中是一个存在一些局部 dense 结构对于有些 query有一些“捷径”可以从一个 entity 通过捷径快速连接到多跳之外的 entity。“Shortcuts” structure假设我们有一个家庭关系的知识图谱包含以下实体和关系Alex是Brian的孩子 (Alex - child_of - Brian)Cole嫁给了Brian(Cole - married_to - Brian)Daniel是Cole的哥哥 (Daniel - brother_of - Cole)Daniel是Alex的舅舅 (Daniel - uncle_of - Alex)这是一个包含冗余信息的密集型的知识图谱。显然可以通过前三条 relationships 推导出最后一条 relationship。但知识图谱中往往存在一些这种冗余信息的捷径。这些捷径可以减少一些 entities 之间的跳数。基于这两点观察我们发现有限次数的在知识图谱内的路由查找过程只涉及到局部的知识图谱信息。因此将 query 进行知识图谱内信息检索的过程可以用下面这两步来实现路由的起点可以通过向量相似性查找来完成。可以涉及到 query 与 entities 或 query 与 relationships 的相似度关系查找。从起点找到其它信息的路由过程可以用一个 LLM 来代替完成。将这些备选信息放进 prompt 里依托 LLM 强大的自注意力机制来挑选有价值的路由。由于 prompt 长度有限所以只能将局部知识图谱的信息放入比如起点附近限定跳数内的知识图谱信息这一点是正好可以由跳数有限性来保证。整个过程不需要其任何它的 KG 存储和复杂的 KG 查询语句只需要使用 vector database 和一次 LLM 的访问。而 vector retrieval LLM rerank 才是这个 pipeline 中最关键的部分这也就解释了我们只用一个传统的两路召回架构就可以达到远超基于图理论的方法如 HippoRAG 的表现。这也说明了实际上不需要复杂的图算法我们只需要将图结构的逻辑关系存储在向量数据库里用一个传统的架构就可以进行逻辑上的子图路由而现代 LLM 强大的能力帮助做到了这一点。方法概览我们的方法只涉及在 RAG 流程中检索 passages 的阶段不涉及 chunking 或 LLM response generation 的创新和优化。我们假设已经得到了一组 corpus 的三元组信息它包含一系列的 entities 和 relationships 信息。这些信息可以表示一个知识图谱的信息。我们将 entities, relationships 信息分别进行向量化并存储在向量存储里这样存储了一个逻辑上的知识图谱。当进行 query 查询时会先把相关的 entities 和 relationships 检索出来。通过这些 entities 和 relationships我们在图结构上进行有限的拓展。将这些 relationships 与 query 问题组装进 prompt 内使用 LLM 的能力对这些 relationships 进行 reranking。最后得到 topK 个重要的 relationships在他们的 metadata 信息内获得与他们相关的 passages作为最终的 retrieved passages。Overall pipeline of our method方法详解4.1. 向量入库我们准备两个向量存储 collections一个是 entity collection另一个是 relationship collection。将一系列的 unique entities 信息和 relationships 信息使用 embedding 模型转换成向量存储在向量存储中。对于 entities 信息直接将他们的字符描述转换成 embedding。对于 relationships 的原始数据形式它的结构是一个三元组(Subject, Predicate, Object)我们启发性地直接将它们合并成一个句子“Subject Predicate Object”比如(Alex, child of, Brian) - “Alex child of Brian”(Cole, married to, Brian) - “Cole married to Bria”然后直接将这个句子转换成 embedding然后存储在向量数据库里。这种做法方便且直接虽然这样做可能存在少量的语法问题但这不影响句子含义的表达也不影响它在向量空间中的分布。当然我们同样也鼓励在前期抽取三元组的时候直接使用 LLM 生成简短的句子描述。4.2. 向量相似搜索对于输入的 Query我们遵循常见的 GraphRAG 中的范式如 HippoRAGMS GraphRAG将 query 提取 entities对于每个 query entity转换成 embedding分别对 entity collection 进行 vector similarity search。然后将所有 query entities 搜索得到的结果进行合并。对于 relationship 的向量搜索我们直接将 query string转换成 embedding对 relationship collection 进行 vector similarity search。4.3. 扩展子图Expanding subgraph from two retrieved ways, then merged them together我们以搜索到的 entities 和 relationships 为知识图谱里的起始往外扩大一定的范围。对于起始 entities我们往外扩大一定的跳数后取它们邻接的 relationships记为对于起始 relationships我们往外扩大一定跳数得到我们将两个 set 取并集基于跳数有限性我们仅需要扩大较小的度数如 12 等就能涵盖大部分可能有助回答的 relationships。请注意这一步扩展的度数的概念和回答问题总共需要的跳度的概念不同。比如如果回答一个 query 问题涉及两个相差 n 跳的 entities那么实际上往往只需要扩展 ⌈n / 2⌉ 度就可以因为这两个 entities 是被向量相似召回后的两个起始端点。如图向量召回到了两个红色的 entities只需要从它们开始相向扩展 2 度就能覆盖到 4 度的跳数这足以回答涉及到这两个 entities 的 4 跳问题。In fact, to answer the question with 4 degree hops, you only need to expand it by 2 degrees from both end points in the setting.4.4. LLM Rerank这一步中我们使用 LLM 强大的自注意力机制完成对 relationships 候选集的进一步筛选。我们使用 one-shot prompt将 query 和 relationships 候选集放入 prompt 里要求 LLM 从中选择出可能对回答这个 query 有帮助的 relationships。考虑到有些 query 可能存在一定的复杂性我们采用 Chain-of-Thought 的思想让 LLM 的回答里写下思考过程我们观察到这一方法对一些偏弱的模型有一些帮助。我们规定 LLM 的返回为 json 格式以便于解析格式。具体的 prompt 参考如下One shot input promptI will provide you with a list of relationship descriptions. Your task is to select 3 relationships that may be useful to answer the given question. Please return a JSON object containing your thought process and a list of the selected relationships in order of their relevance. **Question:**When was the mother of the leader of the Third Crusade born? **Relationship descriptions:**[1] Eleanor was born in 1122.[2] Eleanor married King Louis VII of France.[3] Eleanor was the Duchess of Aquitaine.[4] Eleanor participated in the Second Crusade.[5] Eleanor had eight children.[6] Eleanor was married to Henry II of England.[7] Eleanor was the mother of Richard the Lionheart.[8] Richard the Lionheart was the King of England.[9] Henry II was the father of Richard the Lionheart.[10] Henry II was the King of England.[11] Richard the Lionheart led the Third Crusade.One shot input prompt { thought_process: To answer the question about the birth of the mother of the leader of the Third Crusade, I first need to identify who led the Third Crusade and then determine who his mother was. After identifying his mother, I can look for the relationship that mentions her birth., useful_relationships: [ [11] Richard the Lionheart led the Third Crusade, [7] Eleanor was the mother of Richard the Lionheart, [1] Eleanor was born in 1122 ]}这个 prompt 是一个展示的参考实际上如何把 relationships 中的三元组转成一个通顺的短句是一个棘手的问题。但是你完全可以用上文提到的启发性的方法把三元组直接拼在一起。如(Eleanor, born in, 1122) 可以直接转成 Eleanor born in 1122这种方式有时会带来一定的语法问题但它是最快最直接的方式也不会对 LLM 带来误解。4.5. 获得最终 passages对于上面的例子实际上可以在 LLM rerank 这个阶段直接返回最终的回答比如在 One shot output prompt 的 json 字段里加上比如 “final answer”的字段。但是这一步的 prompt 里只有 relationship 的信息不一定所有问题都可以在这个阶段返回最终答案所以其它具体的信息应该要在原始的 passsage 里获得。LLM 返回精确排序后的 relationships。我们只需要取出先前在存储中的对应 relationship 信息从中获取相应的 metadata在那里有对应的 passage ids。这些 passages 信息就是最终被 retrieved 到的 passages。后续生成回答的过程和 naive RAG 一样就是将它们放入 prompt 的 context 中让 LLM 给出最后的回答。结 果我们使用与 HippoRAG 中一致的 dense embeddingfacebook/contriever来作为我们的 embedding 模型可以看到在三个 multi-hop 的数据集上结果比较上我们的方法大幅超过 naive RAG 和 HippoRAG 的结果。所有的方法使用相同的 embedding 模型设置。我们使用 Recall2 作为我们的衡量指标它表示Recall召回率 检索到的相关文档总数 / 数据存储中相关文档总数On the multi-hop datasets, our method outperforms naive RAG and HippoRAG in all datasets, all of them are compared using the same facebook/contriever embedding model.这一结果说明了即使是最简单的多路召回然后 rerank 的 RAG 范式应用在 graph RAG 的场景上也能得到 state-of-the-art 的 performance。这一结果也说明了合理的向量召回和 LLM 设置是应用在 multi-hop QA 场景中的关键。回顾我们的方法把 entities 和 relationships 转成向量并进行搜索的作用就是寻找子图的起点它像是破解刑侦案件中的现场发现的“线索”。而后面扩展子图和 LLM rerank 的过程像是具体通过这些“线索”进行分析的过程LLM 拥有“上帝视角”可以在一众的候选 relationships 中聪明地选择对破案有用的 relationships。这两个阶段回归本质也就是对应朴素的 vector retrieval LLM reranking 范式。在实践中我们推荐大家使用开源 Milvus或它的全托管版本 Zilliz Cloud来存储并搜索 graph 结构中大量的 entities 和 relationships。而 LLM 可以选择开源模型如 Llama-3.1-70B 或闭源的 GPT-4o mini中等以上规模的模型都能胜任这些任务。你也可以参考我们的 notebook 代码示例https://milvus.io/docs/graph_rag_with_milvus.md以获得更多实现的细节。0基础怎么学习AI大模型我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】第一阶段从大模型系统设计入手讲解大模型的主要方法第二阶段在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用第三阶段大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统第四阶段大模型知识库应用开发以LangChain框架为例构建物流行业咨询智能问答系统第五阶段大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型第六阶段以SD多模态大模型为主搭建了文生图小程序案例第七阶段以大模型平台应用与开发为主通过星火大模型文心大模型等成熟大模型构建大模型行业应用。学会后的收获• 基于大模型全栈工程实现前端、后端、产品经理、设计、数据分析等通过这门课可获得不同能力• 能够利用大模型解决相关实际项目需求 大数据时代越来越多的企业和机构需要处理海量数据利用大模型技术可以更好地处理这些数据提高数据分析和决策的准确性。因此掌握大模型应用开发技能可以让程序员更好地应对实际项目需求• 基于大模型和企业数据AI应用开发实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能 学会Fine-tuning垂直训练大模型数据准备、数据蒸馏、大模型部署一站式掌握• 能够完成时下热门大模型垂直领域模型训练能力提高程序员的编码能力 大模型应用开发需要掌握机器学习算法、深度学习框架等技术这些技术的掌握可以提高程序员的编码能力和分析能力让程序员更加熟练地编写高质量的代码。1.AI大模型学习路线图2.100套AI大模型商业化落地方案3.100集大模型视频教程4.200本大模型PDF书籍5.LLM面试题合集6.AI产品经理资源合集获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】