很多技术团队都走过同样的路：先选一个大模型，然后把公司里的文档、手册、报告塞进向量数据库，再搭一个 RAG 问答系统。原型跑起来那天的感觉特别好，问什么答什么，反应快，看起来像模像样。
但系统真正投入业务之后，问题就来了。
一旦问题变得复杂，系统就开始答非所问。有时候它给出的答案看起来头头是道，但细查来源，发现推理过程根本站不住脚。
团队换过更贵的模型，效果有改善，但一到复杂问题就崩的现象，始终没有根除。
后来大家慢慢意识到：问题可能不在模型本身，而在于知识被喂给模型之前的那一步——检索。
一、传统 RAG 正在把企业知识切碎
RAG（检索增强生成）是目前企业用大模型的普遍做法。用户提问，系统先从知识库找出相关文字，连问题一起丢给大模型，让模型根据这些文字回答。
传统 RAG 依赖向量检索，做法是：
把每篇文档切成文本块（chunk），比如每块 500 字
把每个块转化成高维向量
用户提问时，把问题也转化成向量，去库里找语义最相似的块
对一般场景中的简单问答，这个方法有效。
但企业里的真实问题，极少是这种点对点查询。因为企业知识的核心是关系。
归因关系：如设备故障手册里的故障现象和根本原因
传导关系：如产业链分析报告的上游价格和下游需求
前后依赖关系：如 SOP 流程文档的不同步骤
层级关系：如产品手册的零部件和子系统
而传统 RAG 的第一步：切文本块，恰恰把这些关系切断了。
“客户 A 为什么被判定为高风险？”
背后可能涉及：用户 → 设备 → IP → 联系人 → 黑名单账户 → 历史交易 → 欺诈团伙，这不是一个文本块能回答的问题。
“某设备关联过哪些异常账号，这些账号之间有没有共同联系人？”
这里需要的是关系推理、多跳遍历、结构化关联，而不是语义相似。
使用传统 RAG，非常可能出现以下几大问题[1]。
（一）关系缺失
文档之间天然存在引用、衍生、对立等复杂关系，向量数据库将文档切分为孤立的片段后，数据的关联随之减弱。
一个因果链条可能跨越三个段落，被切成三个独立文本块后，关系被破坏。一个产品特性可能分散在不同章节，被切碎后，模型再也看不到完整画像。
（二）语义鸿沟
语义相似度 ≠ 上下文相关性 。举个相似但不相关的例子，保温杯与保温大棚，两者在转换成 Embedding 后的向量相似性很高，因为它们在很大比例上共享“保温”这一语义特征。但在一些场景下，想要了解保温杯却召回了保温大棚的信息。一个是喝水的，一个是用于农业种植的，完全不相关。
RAG 在索引阶段即使设置了比较高置信度，也很可能因为其相似性而得到不相关的信息。
（三）全局推理乏力
"所有文档的核心观点是什么？"、"政策中最重要的五点信息是什么？"。这类需要跨文档综合分析、提炼的全局性、社区级问题，恰恰是向量检索的局限之处。
二、企业知识天然就是一张图
有没有一种方式，能完整保留知识之间的关联？
答案是图数据库（Graph Database）。图数据库由节点和边构成。节点代表事物，边代表关系，每个节点和边都可以定义其属性。
金融反欺诈的图建模
事实上，NebulaGraph 在微软之前就率先提出了 GraphRAG[2]，而且微软在论文中也引用了我们的 GraphRAG 相关工作[3]。
NebulaGraph 最先提出 GraphRAG
NebulaGraph 是分布式开源图数据库，主要面向大规模、高性能的应用场景，支持千亿点、万亿边的超大规模数据集。目前，在 DB-Engines 的图数据库排行榜上，我们排名全球第二[4]。
企业知识本质上就是一张巨大的图，只是平时藏在文档、表格、邮件里，没有被显式表达出来。
产业研报，变成图：
节点：上游企业、中游厂商、下游需求、价格指标、产能数据边：上游→中游（供应关系）、中游→下游（需求关系）、价格→产能（影响关系）
设备维护手册，变成图：
节点：设备型号、故障现象、可能原因、检测方法、解决措施边：现象→可能原因、原因→检测方法、方法→解决措施
这些关系一旦被显式构建出来，企业知识就不再是散乱的文本，而是一个可以被系统遍历和推理的网络。这就是 GraphRAG 最简单的出发点。
GraphRAG 不是简单地给 RAG 加一个图数据库。它的本质是抽取文档中的实体和它们之间的关系，让大模型在关系网络上做路径探索和逻辑推理，而不是在碎片里做相似匹配。
三、GraphRAG：
从“找相似的”到“找相关的”
图技术如何解决传统 RAG 的三大挑战？
（一）解决文档切分难题
向量数据库的第一步是切文本块。
图模型提供了完全不同的思路。文档、章节、段落可以作为具有丰富属性的节点存在，并通过边明确表达其间的层级关系和引用关系。语义被结构性地保留下来，不需要靠“切”来牺牲完整性。
（二）重建上下文关联
一个多级部门文档体系，在向量数据库中，这些文档被切成文本块后是“平权”的——一级和三级的内容混在一起，无法保留层级、来源和引用关系。
在图数据库中，可以清晰地建模“发布”“引用”“归属”等关系。一篇三级报告引用了一级纲领的某条原则，这个关系可以被显式记录下来。当用户问“这份报告的合规依据是什么”，系统可以沿着引用边一路回溯到纲领原文，形成可追溯、可解释的知识链条。
（三）解锁复杂推理能力
对于关联类问题。图数据库可以通过子图搜索、路径查询轻松找出两个节点之间的连接路径，即使这条路径跨越了多个中间节点。
对于总结推理类问题，图数据库可以利用社区发现、中心性分析等图算法，识别出知识网络中最关键、最聚合的信息群，而不是像向量检索那样简单返回相似度最高的几个段落。
（四）小结
保留结构、重建关联、支持推理，这三大核心能力正是 GraphRAG 区别于传统 RAG 的本质所在。并且结果更精确，更重要的是每一步推理路径都可以完整展示给用户。
四、Fusion GraphRAG：
NebulaGraph 的自我超越
（一）Fusion Graph Index（融合图索引）
技术不会止步。随着企业数据越来越复杂——PDF、Excel、PPT、图片、时序数据混在一起，GraphRAG 遇到了新挑战：如何在一个系统里同时处理文档结构、实体关系、语义相似性？
为此，NebulaGraph 提出了原创的 Fusion GraphRAG 架构。
Fusion GraphRAG 在知识图谱之上，创新地增加了一层 Fusion Graph Index（融合图索引），将非结构化文档解析为层次化目录树结构：文档 → 章节 → 段落 → 文本块 → 图表。
这种树状结构直接置于 LLM 的推理上下文中，成为它可以主动遍历和推理的上下文内索引。
也就是说，Fusion GraphRAG 让文档的层次化结构本身即可作为可推理的索引，让 LLM 根据问题意图动态决定“去哪里找”，而非静态匹配“什么看起来像”，给 LLM 装上了智能导航。
这种能力的本质，是让检索从静态匹配，开始进入动态结构推理阶段。
（二）四大索引能力
因此，在 Fusion GraphRAG 中，实际上存在四类核心索引能力：
图索引负责实体关系与多跳路径推理；
向量索引负责语义相似召回；
全文索引负责关键词精准匹配；
融合图索引则负责文档结构导航与上下文推理。
四种索引能力各司其职，又动态协同。
简单 FAQ 场景下，向量检索可以快速返回结果；
复杂关系分析则更多依赖图路径推理；
专业术语与法规查询适合全文检索；
长文档、多章节、跨引用场景，则由融合图索引主导结构导航。
这一设计带来了显著的效率提升：
相比使用大模型抽取知识图谱，索引构建速度提升约 10 倍；
在与微软 GraphRAG 的对比中，索引阶段更是快了近 20 倍，同时问答准确率更高。
五、NebulaGraph AI 应用平台
Fusion GraphRAG 是技术方案。企业需要的是可以直接用的产品。
（一）核心能力
零代码搭建智能助手：通过可视化界面导入知识资产、配置检索策略，不用写代码
自然语言直接转换图查询语言：业务人员能够自主构建算法，无需依赖研发团队，快速将业务规则落地图分析中
多类型索引统一存储：将向量、全文、图和融合图索引建立在一个平台内，系统自动选择最优索引策略
多模态解析：PPT、Word、Excel、PDF、图片可快速解析。
企业级权限隔离：不同部门知识集相互隔离，可按区域、产品线做二级隔离
模型无关：底层大模型可随时更换，支持 GPT、通义、 DeepSeek、 GLM 等大模型。
（二）生态完整
我们构建了完整的 AI 应用开发生态：
Nebula AI Application SDK：为开发者提供灵活调用的工具包。
Nebula AI 应用平台：零代码开箱即用的端到端平台，用户只需选择知识库，即可创建专属 AI 应用。
（三）场景多元
目前，NebulaGraph AI 应用平台已在以下场景中通过实际业务检验。
金融与数据分析：财报分析与跨文档校对、历史交易文档查询对比、产业链AI研究（如黑色系）；
工业与智能制造：故障树处理与排故引导、工业决策辅助；
法律合规与合规：法律法规条款查询、合同合规性审核；
企业通用智能助手：钉钉/企微机器人问答、网站 AI 搜索、业务流程入库与图查询、新零售企业内部智能助手（员工培训/文档查找/销售数据分析/多国法务合规等）。
（四）正确率显著提高
在开源 KG-RAG 评测集（专门测试多跳推理，问题平均需要2-4跳）上，召回率和回答正确率比 SOTA 高出 10% 以上。
在金融类法律法规的真实企业场景中，人工评分正确率达 95%。
六、用户案例
（一）中国船舶集团第七O八研究所：故障树处理与引导排故
1. 挑战
客户有大量的非结构化文档， 文档内有故障树描述（树状描述， 或者文字描述）、
FDE006127d25" style='margin: 8px 0px 16px;padding: 0px;max-width: 100%;box-sizing: inherit;clear: both;min-height: 1em;color: rgba(0, 0, 0, 0.9);font-family: "JetBrains Mono", "LXGW WenKai Screen", -apple-system, system-ui, Helvetica, Arial, sans-serif;font-size: 17.6px;font-style: normal;font-variant-ligatures: none;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-align: justify;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;background-color: rgb(255, 255, 255);text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;overflow-wrap: break-word !important;'>2. 成效
故障平均排查时间大幅缩短。同时，每次成功排故后，工程师的查询路径被系统记录下来，数千个故障场景的推理路径沉淀为企业可复用的数字资产。新工程师遇到类似问题时，系统可以直接推荐历史成功路径。
这是行业首个船舶生成式人工智能驱动的实际应用场景通过实现图驱动的检索增强智能体，优化了信息检索的准确性和速度，提高了系统的灵活性和适应性。
（二）某期货企业：产业链 AI 研究助手
某期货企业的研究员每天要跟踪黑色系产业链。上游焦煤、焦炭、铁矿石的价格和库存，影响中游钢厂的产能决策，再传导到下游建筑、制造、出口的需求。研究员同时盯着十几个数据源，外加大量历史研报和实时资讯，导致一份日报需要耗时 4-6h。
2. 成效
显著减少人工分析时间，单份日评制作时间降低至 30min 以内，自动化生成专业、及时、准确的黑色系期货日评报告。
七、重新定义 AI 如何理解知识
回到开头的困惑，为什么接了模型、建了向量库，复杂问题还是答不好？答案已经清晰了。
你给大模型看的，是被切碎的、断了关系的文字碎片，却指望它能理解那些依赖复杂关系才能回答的问题。
传统 RAG、GraphRAG 与 Fusion GraphRAG 代表了检索增强生成技术从简单语义匹配，到全局结构理解，再到动态推理导航的演进路径。
在这条路上，NebulaGraph 从未缺席。从率先提出 GraphRAG 方案，到推出原创的 Fusion GraphRAG 架构，再到今天的 NebulaGraph AI 应用平台，我们一直在做同一件事：重新定义 AI 如何理解知识。
