九游会网页登录:

  微软的GraphRAG算得上是最早一批老练的GraphRAG体系，它把索引阶段（抽取实体、联系、构建层级社区并生成摘要）和查询阶段的高档才能整合到了一同。这套计划的长处是，能凭借预先核算好的实体、联系、社区摘要来答复那些微观的、主题性的问题，这恰恰是传统RAG体系依据文档检索难以做到的。

  DRIFT的作业流程是这样的：先经过向量查找树立一个广泛的查询起点，再利用群信息把原始问题拆解成更细粒度的后续查询。然后动态地在常识图谱上游走，抓取实体、联系等部分细节。这种规划在核算功率和答案质量之间找到了一个不错的平衡点。

  首先是HyDE生成，依据一份样例社区陈述结构假定性答案，用来改善查询的向量表明。

  接着社区查找上台，经过向量类似度找出最相关的社区陈述，给查询供给微观上下文。体系会剖析这些成果，输出一个开始的中心答案，一起生成一批后续查询用于深挖。

  这些后续查询会在部分查找阶段并行履行，从常识图谱里捞出文本块、实体、联系、以及更多社区陈述。这样的一个进程能够迭代多轮，每轮都或许会发生新的后续查询。

  终究是答案生成，把进程中堆集的一切中心答案汇总起来，交融社区等级的微观洞悉和部分细节，生成终究呼应。全体思路便是先铺开、再聚集，层层递进。

  本文用的是《爱丽丝梦游仙境》，刘易斯·卡罗尔的经典作品，这部小说人物很多、场景丰厚、事情环环相扣，拿来演示GraphRAG的才能再适宜不过。

  先从文本块里抽取实体和联系，再给节点和联系生成摘要，终究构建层级社区并生成社区摘要。

  摘要做完之后，要给社区和实体都生成向量嵌入，这样才能够支撑类似性检索。社区嵌入的代码长这样：

  DRIFT的检索思路其实很契合简略：先看大图，再挖细节。它不会一上来就在文档或实体层面做准确匹配，而是先去查群的摘要，由于这些摘要是对常识图谱首要主题的高层次归纳。

  拿到相关的高层信息后，DRIFT会智能地派生出后续查询，去准确检索特定实体、联系、源文档。这种两阶段的做法其实很像人类查资料的习气：先大致了解状况再针对性地诘问细节。既有大局查找的覆盖面，又有部分查找的精准度，并且不必把一切社区陈述或文档都过一遍，核算开支操控得不错。

  DRIFT用了HyDE技能来提高向量检索的准确率。不是直接拿用户query做embedding，而是先让模型生成一个假定性的答案，再用这个答案去做类似性查找。道理很简略：假定答案在语义上跟实在的摘要更挨近。

  拿到HyDE query之后，做embedding，然后经过向量类似度捞出top 5的陈述。接着让LLM依据这些陈述生成一个开始答案，一起识别出需求深挖的后续查询。将开始答案存起来接着进行后续查询悉数并行分发到部分查找阶段。

  这便是DRIFT的中心思路，先用HyDE增强的社区查找铺开，再用后续查询往下钻。

  部分查找阶段把后续查询并行跑起来，深化到详细细节。每个查询经过实体向量检索拿到方针上下文，生成中心答案，或许还会产出更多后续查询。

  下一步担任编列迭代深化的进程。用collect_events等一切并行查找跑完，然后判别要不要持续往下挖。假如当时深度还没到上限（这儿设的max depth=2），就把一切成果里的后续查询提取出来，存好中心答案分发下一轮并行查找。

  这样就形成了一个迭代细化的循环，每一层都在前一层的基础上持续深挖。到达最大深度后，触发终究答案生成。

  终究一步把整个DRIFT查找进程中积累的一切中心答案汇总成一个完好的呼应：这儿包含社区查找的开始答案，以及部分查找各轮迭代产出的答案。

  DRIFT查找供给了一个挺有意思的思路，在大局查找的广度和部分查找的精度之间找到了平衡。从社区级上下文切入，经过迭代的后续查询逐层下探，既防止了遍历一切社区陈述的核算担负，又确保了覆盖面。

  这儿还有改善空间，比方现在的完成对一切中心答案天公地道，假如能依据置信度分数做个挑选，终究答案的质量应该会更好，噪声也能降下来。后续查询也能够先按相关性或信息增益排个序，优先追寻最有价值的头绪。

  另一个值得测验的方向是加一个查询精粹过程，用LLM剖析一切生成的后续查询，把类似的归并起来防止重复查找，过滤掉那些大概率没什么收成的查询。这样能大幅度削减部分查找的次数，一起不影响答案质量。