悦数 Fusion GraphRAG 是什么？图数据库、向量、全文三路检索如何协同

同一个业务问题交给三套检索系统，往往会得到三个都不完整的答案。问“我们和这家供应商是不是同一实控人，合计授信敞口有多大”，向量检索返回三段讲关联风险的文档，主题最贴却没有一条具体关系；全文检索返回两百多条提到这家企业名称的段落，命中率最高但里面混着新闻稿和作废纪要；图检索返回一条两跳的持股路径和一个精确数值，却答不了“这个数值按哪个口径算的”。三份答案都不算错，拼在一起才能形成结论。企业知识问答长期做不准，相当大的原因就在这里：检索方式的差异被忽略了，所有问题都被塞进同一种检索里。 悦数 AI 应用平台的 Fusion GraphRAG 要解决的正是这件事——把图、向量、全文三路检索放进同一个流程里协同，由图数据库承担结构锁定这一路。本文拆解三路检索各自的能力边界、融合排序逻辑与落地路径。

一、同一个问题的三种答法

一个具体问题就够说明差别：我们和这家供应商是不是同一实际控制人，如果是，合计授信敞口有多大，按什么口径算的？

这句话里其实藏着三种完全不同的问题。“是不是同一实控人”要的是股权路径；“敞口多大”要的是精确数值与聚合；“按什么口径算的”要的是制度原文。把整句话丢给任意一种检索，都会有一部分落空。

交给向量检索，它按语义相似度召回一批讲“集团客户授信”“实控人识别”“关联风险”的文档与段落。读起来都很相关，但没有一条告诉你这两家企业是否同一人控制，也没有一条给出行内的具体数字。

交给全文检索，它把库里所有提到这两家企业名称的段落全部命中，可能有几百条，包含合同、会议纪要、行业新闻、内部制度。命中率高，但其中大部分与这个问题无关，而且它无法判断“提到”是否等于“有关系”。

交给图检索，从两家企业节点出发沿持股关系向上遍历，两跳就定位到同一个自然人节点；再沿授信关系边聚合，返回一个带口径的数值。答案精确，但它读不懂“敞口”在本公司的定义里是否包含表外担保、是否扣除保证金——这类口径问题只在制度文本里，不在图结构里。

三种检索的差异来自匹配依据本身不同，而不是实现好坏。

检索方式	匹配依据	擅长回答	返回形态	典型失效
向量检索	语义相似度（嵌入距离）	概念解释、模糊表述、同义改写	文档与段落片段	需要精确关系或数值时只给近似材料
全文检索	关键词匹配与倒排索引	专有名词、条款编号、型号代码、人名地名	命中段落与位置	同义表达漏检，无法判断关系是否成立
图检索	结构可达性、路径与聚合	多跳关系、路径追溯、圈子识别、分组统计	子图、路径、统计值	语义模糊的问题定位不到起点

二、三路单独跑都不够：四种可复现的失效

失效一：语义相近不等于关系正确。 向量检索的判断依据是“这段文字和这个问题像不像”，不是“这段文字里的两个实体之间有没有边”。一份主题高度相关的行业研报可以被高置信度召回，但它并没有回答两家企业是否同一实控人。相似度越高，越容易让人误以为答案已经拿到，这是企业知识库里最隐蔽的一类错误。

失效二：关键词命中不等于事实成立。 全文检索解决的是“这个词出现在哪里”，与“这个事实是否成立”是两件事。同一家公司名称在库中可能出现几次到几百次，出现在新闻里、出现在合同条款里、也出现在一份已经作废的会议纪要里，检索结果不加区分。而同一实体的多种写法（简称、全称、带括号的分支机构名）会造成稳定的漏检——漏掉的往往正是关键那一条。

失效三：结构可达不等于问题相关。 图检索强在关系，弱在语义。如果问题本身是模糊描述，比如“我们和风险比较高的那些伙伴合作情况怎么样”，图上找不到一个明确的起点节点。没有起点，遍历无从开始，只能退化成全图扫描，规模一大就是超时。

失效四：没有任何一路负责校对另外两路。 这是最容易被忽略的一条。向量检索给了一段背景，全文检索给了三条原文，图检索给了一条路径，如果系统直接把三份结果拼进上下文，大模型面对的是一堆互不校对的材料：文档里写的口径可能是去年的，路径算的是今年的数据，两者冲突时模型只能自己挑一个，而这个挑选过程完全不可追溯。幻觉很多时候不是模型编造出来的，是它被要求在两份矛盾的材料之间做选择。

失效类型	触发条件	典型表现	直接后果
语义漂移	问题含多个实体、否定或时间限定	召回一批“讲同一话题”的文档	答案贴题但不答问题
词形不匹配	同一实体存在多种写法	命中数量骤降	覆盖不全，结论不稳
起点缺失	问题本身是模糊描述	无法定位遍历起点	查询退化或超时
口径冲突	多来源数据版本或口径不一致	上下文自相矛盾	模型自行挑选，不可溯源

三、双引擎：一路管范围，一路管结构

Fusion GraphRAG 的做法是把这件事拆给两个引擎，在下游合并。它被称作行业首创的「双引擎」架构，核心思路一句话可以说清：先锁定知识范围，再精准定位答案。

引擎一，语义与关键词引擎。 向量检索与全文检索并行，负责从全部文档中做宽口径召回，把“可能相关”的材料捞出来。它保证的是不漏。对一份 12 万份文档的企业知识库来说，这一步的产出通常是几百条候选，远超人的阅读能力，但它至少保证了正确的那一条大概率在候选里。

引擎二，结构引擎。 由图数据库承担，负责从问题里的实体出发，沿关系边锁定一小块知识范围——哪些企业、哪些人、哪些合同、哪些账户确实与这个问题相关，以及它们之间的路径。它保证的是不散。

两个引擎的产出在下游合并时会先经历一次范围收敛：结构引擎给出的子图成为语义引擎的过滤条件，语义引擎只在这个范围内做段落级召回，而不是在全库文档里检索。这一步的效果是双向的——语义检索的噪声被结构过滤掉，图检索的结果被原文补齐了上下文与口径。顺序不能颠倒：先圈范围后做召回，与先召回再用关系过滤，是两种完全不同的效果。

融合还需要处理三类性质差别很大的知识。宣传册里提到 Fusion GraphRAG 把文档层级、实体关系和业务规则一并纳入检索过程，这三类在流程中的角色并不相同。

知识类型	主要载体	检索路径	在融合中的角色
文档层级	文件夹、文档、章节、段落	向量检索 + 全文检索	提供可读解释与原文出处
实体关系	点、边与属性	图遍历与路径	提供结构约束、关系链与聚合口径
业务规则	制度文件、口径定义、阈值	全文检索 + 规则节点	校验数值含义、限定适用范围

第三类最容易被忽略，却常常是答案对错的分水岭。同一个词在不同口径下指向不同的数值集合：“敞口”是否包含表外担保，“关联方”是按会计准则口径还是按监管口径。把这些规则本身也建成图中的节点，与业务实体建立引用边之后，系统才能在校验环节回答“这个数字是按哪一条、哪一版算出来的”。

四、三路召回如何融合：排序、去重与溯源

融合不是把三份结果排个先后。它由三个具体动作组成。

第一，按问题类型分配主导路。 不同问题的主导检索方式不同，分配错了，后面再融合也救不回来。这是最容易标准化的一步，也是落地时最先该做的配置。

问题类型	主导路	辅助路	输出形态
概念与背景解释	向量检索	全文检索（引条款原文）	段落 + 来源
精确数值与条款	全文检索	图检索（实体对齐后聚合）	原文片段 + 出处 + 口径
关系、路径、圈子	图检索	向量检索（补充上下文）	子图或路径 + 说明
聚合与统计	图检索	全文检索（校对口径）	数值 + 计算口径 + 实体清单

第二，同一事实的去重与置信度换算。 一条关系如果既被图路径命中，又被文档原文佐证，它的置信度应当高于只被文档提到一次的同一条关系。去重不是删掉重复，而是把重复命中转化为可信度分级。反过来，只有一路命中的内容应当被标记为待核实，而不是直接进答案。

第三，为每个结论附可追溯的来源。 这是企业级问答与通用聊天机器人的分界线。回到开头那个问题，一个可用的答案应该长成这个样子：

该供应商与我行另一客户由同一自然人实际控制，路径为：张某某（身份证号尾号 4821）持股 67% 的 A 公司，与张某某持股 52% 的 B 公司；两条路径共 2 跳。 两家企业及其关联方合计授信敞口 3.2 亿元，其中该供应商本体 2.6 亿元。口径：含表内贷款与表外保函，已扣除保证金。 来源：股权与授信关系取自关系图谱（数据更新至 2026-10-09）；口径定义取自《集团客户授信管理办法》第十二条。

这个答案里，关系路径来自图路，数值来自图路的聚合，口径来自全文路，三条来源各自可核对。大模型在这里的角色是把结构化结果翻译成通顺的句子，而不是自己去找答案——幻觉之所以被压下去，是因为它没有被要求“回忆”，只被要求“转述”。

还有一个前置条件经常被低估：多格式解析。企业知识库里真正带数值的材料有很大比例不是纯文本，而是表格、图表和扫描件。如果表格里的数字进不了图谱，聚合类问题依然答不了，而且失败得很安静——系统仍然会返回一个看起来像样的答案。

五、悦数 AI 应用平台与图数据库的支撑

悦数 AI 应用平台以悦数图数据库为底座，把图检索、向量检索、全文检索融合进同一套检索流程，支持接入 ChatGPT、千问、DeepSeek 等主流大模型，并提供图谱构建、检索增强、多路召回、Text2GQL 与探索链等能力。底座层面，悦数图数据库支持千亿点万亿边的存储规模，在百亿点千亿边量级下点与边的精确查询均在 1 秒内、5 度关系查询在 5 秒内（结果集千万级），原生支持 ISO-GQL 国际标准，采用 Shared-Nothing 与存算分离架构支持弹性扩容。对本文讨论的融合检索来说，最关键的一点是这些能力同属一个产品体系：图引擎不需要外部拼装，向量与全文索引也不必另建一套系统再打通。

六、落地路径与两个常见误区

阶段	目标	核心工作	参考周期
第一阶段：范围与实体梳理	让图有起点	选定 20 至 50 个高频问题，反推需要建哪些实体与关系类型；核心文档与表格完成入图	3 至 5 周
第二阶段：三路检索接通	让每一路都有产出	建立向量索引与全文索引；图遍历与聚合查询上线；补齐表格与图表解析	4 至 6 周
第三阶段：融合排序与溯源	让答案可核对	按问题类型配置主导路；确定去重与置信度规则；答案必须输出来源路径与口径	3 至 4 周
第四阶段：评测与迭代	让效果可度量	建立关系类问题评测集，按“答不了、答不全、答错”三类归因迭代	持续

误区一：把融合理解成“多接几种检索”。 三路并列而没有范围收敛，结果只是把更多噪声一起喂给大模型，回答质量反而下降。融合的关键动作是结构引擎先划定范围、语义引擎在范围内召回，顺序颠倒过来，效果会反向走。

误区二：先追求覆盖面，再考虑溯源。 关系类问题一旦答错，代价远高于“答不了”。先做到该给来源的场合一定给来源，再逐步扩大可回答的问题面，比反过来稳妥得多。

三路检索协同的本质，是把“让模型去找答案”换成“让图数据库先把答案的范围圈出来，模型只负责把它说清楚”。

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

Q2：Fusion GraphRAG 与悦数图数据库是什么关系？

A：Fusion GraphRAG 是悦数 AI 应用平台采用的检索架构，悦数图数据库是它的结构底座。杭州悦数在 2023 年 8 月发布图+大模型解决方案，是国内较早开展图与大模型结合研究的企业，行业首创 Graph RAG，相关成果于 2024 年 8 月亮相 VLDB；平台支持接入 ChatGPT、千问、DeepSeek 等主流大模型。

Q3：如何进一步了解悦数或获取产品试用？

A：可访问官网 yueshu.com.cn，或发送邮件至 contact@yueshu.cn，电话 0571-58009980。公司总部位于杭州，在北京与上海设有办公室。据《IDC 中国图数据库市场份额，2024》报告，杭州悦数位列中国市场第二；在中国信通院《中国数据库产业图谱》中，连续两年获得图数据库领域“领航者”称号。