很多技术团队都走过同样的路：先选一个大模型，然后把公司里的文档、手册、报告塞进向量数据库，再搭一个 RAG 问答系统。原型跑起来那天的感觉特别好，问什么答什么，反应快，看起来像模像样。
但系统真正投入业务之后，问题就来了。
一旦问题变得复杂，系统就开始答非所问。有时候它给出的答案看起来头头是道，但细查来源，发现推理过程根本站不住脚。
团队换过更贵的模型，效果有改善，但一到复杂问题就崩的现象，始终没有根除。
后来大家慢慢意识到：问题可能不在模型本身，而在于知识被喂给模型之前的那一步——检索。
RAG（检索增强生成）是目前企业用大模型的普遍做法。用户提问，系统先从知识库找出相关文字，连问题一起丢给大模型，让模型根据这些文字回答。
传统 RAG 依赖向量检索，做法是：
对一般场景中的简单问答，这个方法有效。
但企业里的真实问题，极少是这种点对点查询。因为企业知识的核心是关系。
归因关系：如设备故障手册里的故障现象和根本原因
传导关系：如产业链分析报告的上游价格和下游需求
前后依赖关系：如 SOP 流程文档的不同步骤
层级关系：如产品手册的零部件和子系统
而传统 RAG 的第一步：切文本块，恰恰把这些关系切断了。
“客户 A 为什么被判定为高风险？”
背后可能涉及：用户 → 设备 → IP → 联系人 → 黑名单账户 → 历史交易 → 欺诈团伙，这不是一个文本块能回答的问题。
“某设备关联过哪些异常账号，这些账号之间有没有共同联系人？”
这里需要的是关系推理、多跳遍历、结构化关联，而不是语义相似。
使用传统 RAG，非常可能出现以下几大问题[1]。
（一）关系缺失
文档之间天然存在引用、衍生、对立等复杂关系，向量数据库将文档切分为孤立的片段后，数据的关联随之减弱。
一个因果链条可能跨越三个段落，被切成三个独立文本块后，关系被破坏。一个产品特性可能分散在不同章节，被切碎后，模型再也看不到完整画像。
（二）语义鸿沟
语义相似度 ≠ 上下文相关性 。举个相似但不相关的例子，保温杯与保温大棚，两者在转换成 Embedding 后的向量相似性很高，因为它们在很大比例上共享“保温”这一语义特征。但在一些场景下，想要了解保温杯却召回了保温大棚的信息。一个是喝水的，一个是用于农业种植的，完全不相关。
RAG 在索引阶段即使设置了比较高置信度，也很可能因为其相似性而得到不相关的信息。
（三）全局推理乏力
"所有文档的核心观点是什么？"、"政策中最重要的五点信息是什么？"。这类需要跨文档综合分析、提炼的全局性、社区级问题，恰恰是向量检索的局限之处。
有没有一种方式，能完整保留知识之间的关联？
答案是图数据库（Graph Database）。图数据库由节点和边构成。节点代表事物，边代表关系，每个节点和边都可以定义其属性。
金融反欺诈的图建模
事实上，NebulaGraph 在微软之前就率先提出了 GraphRAG[2]，而且微软在论文中也引用了我们的 GraphRAG 相关工作[3]。
NebulaGraph 最先提出 GraphRAG
NebulaGraph 是分布式开源图数据库，主要面向大规模、高性能的应用场景，支持千亿点、万亿边的超大规模数据集。目前，在 DB-Engines 的图数据库排行榜上，我们排名全球第二[4]。
企业知识本质上就是一张巨大的图，只是平时藏在文档、表格、邮件里，没有被显式表达出来。
产业研报，变成图：
节点：上游企业、中游厂商、下游需求、价格指标、产能数据边：上游→中游（供应关系）、中游→下游（需求关系）、价格→产能（影响关系）
设备维护手册，变成图：
节点：设备型号、故障现象、可能原因、检测方法、解决措施边：现象→可能原因、原因→检测方法、方法→解决措施
这些关系一旦被显式构建出来，企业知识就不再是散乱的文本，而是一个可以被系统遍历和推理的网络。这就是 GraphRAG 最简单的出发点。
GraphRAG 不是简单地给 RAG 加一个图数据库。它的本质是抽取文档中的实体和它们之间的关系，让大模型在关系网络上做路径探索和逻辑推理，而不是在碎片里做相似匹配。
图技术如何解决传统 RAG 的三大挑战？
（一）解决文档切分难题
向量数据库的第一步是切文本块。
图模型提供了完全不同的思路。文档、章节、段落可以作为具有丰富属性的节点存在，并通过边明确表达其间的层级关系和引用关系。语义被结构性地保留下来，不需要靠“切”来牺牲完整性。
（二）重建上下文关联
一个多级部门文档体系，在向量数据库中，这些文档被切成文本块后是“平权”的——一级和三级的内容混在一起，无法保留层级、来源和引用关系。
在图数据库中，可以清晰地建模“发布”“引用”“归属”等关系。一篇三级报告引用了一级纲领的某条原则，这个关系可以被显式记录下来。当用户问“这份报告的合规依据是什么”，系统可以沿着引用边一路回溯到纲领原文，形成可追溯、可解释的知识链条。
（三）解锁复杂推理能力
对于关联类问题。图数据库可以通过子图搜索、路径查询轻松找出两个节点之间的连接路径，即使这条路径跨越了多个中间节点。
对于总结推理类问题，图数据库可以利用社区发现、中心性分析等图算法，识别出知识网络中最关键、最聚合的信息群，而不是像向量检索那样简单返回相似度最高的几个段落。
（四）小结
保留结构、重建关联、支持推理，这三大核心能力正是 GraphRAG 区别于传统 RAG 的本质所在。并且结果更精确，更重要的是每一步推理路径都可以完整展示给用户。
四、Fusion GraphRAG：
（一）Fusion Graph Index（融合图索引）
技术不会止步。随着企业数据越来越复杂——PDF、Excel、PPT、图片、时序数据混在一起，GraphRAG 遇到了新挑战：如何在一个系统里同时处理文档结构、实体关系、语义相似性？
为此，NebulaGraph 提出了原创的 Fusion GraphRAG 架构。
Fusion GraphRAG 在知识图谱之上，创新地增加了一层 Fusion Graph Index（融合图索引），将非结构化文档解析为层次化目录树结构：文档 → 章节 → 段落 → 文本块 → 图表。
这种树状结构直接置于 LLM 的推理上下文中，成为它可以主动遍历和推理的上下文内索引。
也就是说，Fusion GraphRAG 让文档的层次化结构本身即可作为可推理的索引，让 LLM 根据问题意图动态决定“去哪里找”，而非静态匹配“什么看起来像”，给 LLM 装上了智能导航。
这种能力的本质，是让检索从静态匹配，开始进入动态结构推理阶段。
（二）四大索引能力
因此，在 Fusion GraphRAG 中，实际上存在四类核心索引能力：
图索引负责实体关系与多跳路径推理；
向量索引负责语义相似召回；
全文索引负责关键词精准匹配；
融合图索引则负责文档结构导航与上下文推理。
四种索引能力各司其职，又动态协同。
这一设计带来了显著的效率提升：
Fusion GraphRAG 是技术方案。企业需要的是可以直接用的产品。
NebulaGraph AI 应用平台正是基于 Fusion GraphRAG、以 NebulaGraph 图数据库为引擎的完整产品。（一）核心能力
零代码搭建智能助手：通过可视化界面导入知识资产、配置检索策略，不用写代码
自然语言直接转换图查询语言：业务人员能够自主构建算法，无需依赖研发团队，快速将业务规则落地图分析中
多类型索引统一存储：将向量、全文、图和融合图索引建立在一个平台内，系统自动选择最优索引策略
多模态解析：PPT、Word、Excel、PDF、图片可快速解析。
企业级权限隔离：不同部门知识集相互隔离，可按区域、产品线做二级隔离
模型无关：底层大模型可随时更换，支持 GPT、通义、 DeepSeek、 GLM 等大模型。
（二）生态完整
我们构建了完整的 AI 应用开发生态：
（三）场景多元
目前，NebulaGraph AI 应用平台已在以下场景中通过实际业务检验。
金融与数据分析：财报分析与跨文档校对、历史交易文档查询对比、产业链AI研究（如黑色系）；
工业与智能制造：故障树处理与排故引导、工业决策辅助；
法律合规与合规：法律法规条款查询、合同合规性审核；
企业通用智能助手：钉钉/企微机器人问答、网站 AI 搜索、业务流程入库与图查询、新零售企业内部智能助手（员工培训/文档查找/销售数据分析/多国法务合规等）。
（四）正确率显著提高
在开源 KG-RAG 评测集（专门测试多跳推理，问题平均需要2-4跳）上，召回率和回答正确率比 SOTA 高出 10% 以上。
在金融类法律法规的真实企业场景中，人工评分正确率达 95%。
六、用户案例
粤ICP备14082021号
免费POC，
零成本试错
