你的知识库是"文档堆"还是"知识网"？图数据库让 RAG 从搜索走向推理

某券商研究所的分析师在用内部 RAG 系统做行业研究时遇到一个典型困境。他问系统："宁德时代的上游供应商中，哪些同时是比亚迪的供应商，且这些供应商在 2025 年三季度的净利润环比下降超过 20%？"系统返回了三段文档——一段宁德时代 2024 年年报中提到"上游供应商包括赣锋锂业、天赐材料等"，一段比亚迪的招股说明书中列出"主要原材料供应商包括天赐材料、多氟多等"，还有一段某财经媒体关于天赐材料三季度利润下滑的报道。三段文档都是相关的，但系统没有把它们关联起来——它不知道"天赐材料"在第一段和第二段中是同一个实体，更没有能力把"供应商交集"和"利润下滑"这两个条件组合推理。分析师最终自己花了 40 分钟翻完六份报告，手工拼出了答案：天赐材料和多氟多两家同时供应宁德时代和比亚迪，且三季度净利润环比分别下降 23% 和 31%。这不是 RAG 系统不够努力，而是它的数据模型决定了它的天花板——传统的 RAG 是在"文档堆"里做关键词和向量匹配，而企业真正需要的是在"知识网"里做关系推理。两者的差距，不是搜索精度的差距，是数据结构的代差。

一、"文档堆"式 RAG 的三层天花板

当前绝大多数企业部署的 RAG 系统，底层架构是"文档→分块→向量化→检索→拼接→生成"的线性流水线。这条流水线在"找文档"场景下表现尚可，但在"推理型问题"面前存在三层结构性天花板。

第一层：分块切断了实体关系。 文档分块（chunking）是 RAG 的标准前置步骤——把长文档切成 512 或 1024 个 token 的片段，每个片段独立向量化。问题在于，企业知识中的实体关系天然是跨文档的：宁德时代的供应商列表在年报 A 里，比亚迪的供应商列表在招股书 B 里，供应商的财务数据在财报 C 里——这三个信息片段分散在三个文档的不同分块中。向量检索只能基于语义相似度逐个召回片段，它没有"实体"的概念，不知道"天赐材料"在不同文档里指的是同一家公司，更不会主动去把三个片段关联起来做交集运算。分块越多，实体被切断得越碎，关联就越难建立。

第二层：向量相似度无法表达关系语义。 向量检索的核心是"语义距离"——两段文本在向量空间中越近，相似度越高。但企业问题的核心不是"相似"，而是"关联"。问"宁德时代和比亚迪的共同供应商"——这不是在问"哪段文档和这个问题最相似"，而是在问"两家公司的供应商集合的交集是什么"。这是一个集合运算，需要先分别检索两家公司的供应商列表，再做交集。向量检索的模型里没有"集合"和"交集"的概念，它只能返回"和这个问题语义最接近的文档片段"——于是返回了三段各包含部分信息的片段，至于怎么组合、怎么推理，全靠大模型在 prompt 里临场发挥。大模型的推理能力在上下文窗口有限、实体消歧不完整的情况下，准确率大打折扣。

第三层：检索结果缺少推理路径。 传统 RAG 返回的是"top-K 相关文档片段"——用户看到的是五段文本，但不知道这五段文本之间是什么关系、为什么被一起召回、它们如何推导出最终答案。在简单的事实查找场景中这不是问题——"公司年报里写的营收是多少"只需要一段文档。但在多跳推理场景中，可解释性至关重要——分析师需要知道"系统是怎么得出'天赐材料是共同供应商'这个结论的"，需要验证"天赐材料在三份文档中确实是同一家公司"。传统 RAG 的返回结果是一个黑盒——给了答案，但给不出推理过程。

二、从"文档堆"到"知识网"：数据模型的根本转变

GraphRAG 的核心不是在传统 RAG 上叠加一个图数据库，而是从数据模型层面重建知识库的底层结构——把"文档"分解为"实体"和"关系"，把"分块检索"升级为"图遍历推理"。

实体提取与图谱构建。 知识网的第一步是把文档中的信息提取为结构化的实体和关系。大模型负责从非结构化文档中识别实体——"宁德时代"是公司实体、"天赐材料"是公司实体、"供应商"是关系类型。提取出的实体和关系写入图数据库，形成知识图谱的节点和边。每条边携带元数据：关系来源（哪份文档的哪一段）、关系时效（起始日期）、置信度（大模型提取的把握程度）。这意味着图数据库中的每一条关系都可追溯到原始文档——不是"大模型凭空编出来的"，而是"有据可查的结构化事实"。

实体消歧：同一实体自动合并。 当大模型从三份不同文档中分别提取出"天赐材料""广州天赐高新材料股份有限公司""天赐"时，图数据库通过实体消歧算法识别它们指向同一家公司——基于工商注册号、统一社会信用代码、简称别名表等规则做精确匹配，再用名称相似度和关系上下文做模糊补充。三个实体节点合并为一个，三份文档中的供应商关系边都指向同一个节点——"天赐材料是宁德时代的供应商"和"天赐材料是比亚迪的供应商"这两条边现在挂在同一个节点上，交集运算自然成立。

图遍历替代向量匹配。 知识网建好后，用户提问的检索方式从"向量找最相似的片段"变成"图遍历走关系路径"。以"宁德时代和比亚迪的共同供应商中三季度利润下滑超过 20% 的有哪些"为例：第一步，从"宁德时代"节点出发，沿"供应商"边遍历到所有供应商节点——得到集合 A（赣锋锂业、天赐材料、华友钴业等 12 家）；第二步，从"比亚迪"节点出发，沿"供应商"边遍历到所有供应商节点——得到集合 B（天赐材料、多氟多、融捷股份等 9 家）；第三步，计算 A ∩ B 的交集——得到共同供应商集合 C（天赐材料、多氟多）；第四步，对集合 C 中每个节点沿"财务数据"边遍历到三季度财报节点，筛选净利润环比降幅 > 20% 的——得到最终答案：天赐材料（-23%）、多氟多（-31%）。四步图遍历，200 毫秒完成，每一步都有明确的关系类型和方向。传统 RAG 用向量检索+大模型推理做了 40 分钟还没做对的事，GraphRAG 在不到 1 秒内精确完成。

三、大模型在 GraphRAG 中的新角色

从"文档堆"到"知识网"的升级中，大模型不是被边缘化了，而是从"万能但不可靠的推理引擎"变成了"精准且可追溯的知识提取器"。大模型在 GraphRAG 中承担三个新角色。

角色一：知识提取引擎。 大模型的核心能力是语义理解——从非结构化文档中精准提取实体、关系和属性。这一步在图谱构建阶段至关重要——不是简单的命名实体识别（NER），而是深度语义提取：从一段财报中提取"天赐材料向宁德时代供应电解液，2025 年上半年供应额 8.2 亿元，占总采购额的 12%"——这条信息包含实体（天赐材料、宁德时代）、关系（供应电解液）、属性（供应额 8.2 亿、占比 12%、时间 2025 上半年）。大模型把这些信息结构化为图数据库中的节点和边，原始文档中的非结构化知识从此变为可遍历、可计算的结构化资产。

角色二：意图解析与查询路由。 用户用自然语言提问时，大模型负责理解意图并路由到正确的检索策略。简单事实型问题（"宁德时代的注册资本是多少"）路由到属性查找；关系型问题（"宁德时代的供应商有哪些"）路由到单跳图遍历；推理型问题（"宁德时代和比亚迪的共同供应商中利润下滑的有哪些"）路由到多跳图遍历+集合运算。大模型同时做实体识别和消歧——从问题中提取"宁德时代""比亚迪""共同供应商""利润下滑"等关键概念，映射到图数据库中的节点和边类型，自动生成 nGQL 查询语句。这个能力就是 Text2nGQL——用户不需要学图查询语言，大模型替他们写。

角色三：推理结果的自然语言组装。 图遍历返回的是结构化结果——节点列表、关系路径、属性值。大模型把这些结构化数据"翻译"成用户能理解的自然语言答案——"宁德时代和比亚迪的共同供应商中，天赐材料三季度净利润环比下降 23%，多氟多下降 31%。两家供应商均面临上游原材料价格波动压力，建议关注其四季度盈利恢复情况。"大模型同时利用图遍历返回的关系路径做推理增强——沿着"天赐材料→原材料→碳酸锂→价格走势"这条边发现碳酸锂价格在三季度下跌 18%，补充解释"利润下滑的主因是下游压价而非成本上升"。这种"图遍历提供骨架、大模型提供血肉"的协同，让答案既有事实精度又有分析深度。

四、GraphRAG 的三大企业实战场景

场景一：金融研报的关联推理。 券商分析师的核心工作是发现市场中的关联性——某行业的政策变化如何影响上下游产业链、某公司的业绩波动如何传导到其供应商和客户。传统研报 RAG 只能做"找相关研报"的检索，GraphRAG 能做"推理产业链传导路径"的分析。问"如果碳酸锂价格继续下跌 15%，哪些上市公司受影响最大"，GraphRAG 从"碳酸锂"节点出发，沿"下游产品"边找到"电解液""正极材料"，沿"生产商"边找到天赐材料、多氟多等公司，再沿"客户"边找到宁德时代、比亚迪，最后沿"营收占比"边计算每家公司的碳酸锂成本敏感度——一次遍历输出完整的传导链路和量化影响排序。

场景二：企业内部知识管理的精准问答。 大型企业的内部知识库包含技术文档、产品手册、SOP、培训材料、项目复盘报告等数千份文档。员工问"我们上次处理类似客户数据泄露事件的流程是什么、涉及哪些部门、花了多长时间"，传统 RAG 返回所有包含"数据泄露"关键词的文档列表。GraphRAG 从"数据泄露事件"节点出发，沿"处理流程"边找到 SOP 节点，沿"负责部门"边找到信息安全部和法务部，沿"处理时长"属性找到"从发现到关闭耗时 72 小时"——直接返回结构化答案而非文档列表。员工不需要再打开文档自己找，一步到位。

场景三：医疗临床决策支持。 医院的知识库包含病历、诊疗指南、药物说明书、临床研究论文等。医生问"这位患者同时服用了华法林和某抗生素，有没有相互作用风险、应该怎么调整剂量"，GraphRAG 从"华法林"节点出发，沿"药物相互作用"边找到该抗生素，沿"相互作用机制"边找到"CYP2C9 酶抑制"，沿"临床建议"边找到"建议华法林剂量减少 30%、监测 INR 值"——一次遍历给出完整的药物相互作用链路和剂量调整建议，每一步都有临床指南和文献来源可追溯。

五、悦数图数据库的核心支撑

GraphRAG 对底层图数据库提出了五项硬性要求，悦数在每一项上有明确的工程支撑。

原生 GraphRAG 引擎层耦合。 GraphRAG 的技术核心是"图遍历+大模型推理"的协同。悦数不是在应用层用 API 把图数据库和大模型"拼"在一起，而是在引擎层面做深度耦合——图遍历的中间结果直接流过大模型推理管线，中间步骤不需要跨进程通信，端到端延迟降低 60% 以上。引擎层耦合还保证了推理可追溯性——大模型生成的每一个结论都能回溯到具体的图遍历路径和实体属性，杜绝"大模型编造关系"的风险。

亿级多跳百毫秒查询。 大型企业的知识图谱规模可达数千万到数亿个实体——产品、人员、客户、供应商、文档、工单，加上关系边总规模轻松突破十亿级。GraphRAG 的核心操作是多跳遍历——从锚定实体出发走 3-7 跳找到答案路径。悦数的分布式存储和并行查询引擎在亿级图规模下保持 5 跳遍历百毫秒级响应，确保推理体验的实时性——用户提问后答案在感知不到延迟的情况下返回。

Text2nGQL 自然语言接口。 GraphRAG 的交互方式不应该是"用户学 nGQL 写查询语句"，而应该是"用户用自然语言提问，系统自动翻译"。Text2nGQL 将用户的自然语言问题自动转化为 nGQL 图查询语句——"帮我查一下宁德时代和比亚迪的共同供应商"自动翻译为多跳遍历查询语句。这让 GraphRAG 的使用门槛从"需要数据工程师"降到"任何人都能用"。

动态 Schema 知识持续生长。 企业知识结构不是静态的——新业务线、新产品、新供应商、新员工随时加入。悦数动态 Schema 允许在不停机的情况下新增节点类型和边类型——知识图谱随业务持续生长，而不是"建一次用三年，三年后推倒重建"。新增的文档通过大模型自动提取实体和关系写入图谱，知识网越用越密、越用越准。

Studio 可视化推理路径调试。 GraphRAG 的推理路径对开发者和业务人员都有价值——开发者需要调试"为什么查出来的答案不对""哪一跳的过滤条件有问题"，业务人员需要理解"答案是怎么推出来的"。悦数 Studio 提供交互式图谱可视化界面，推理结果附带完整的关系路径子图——节点大小反映关联强度，边颜色反映关系类型，高亮标注遍历路径。业务人员可在可视化界面上交互探索——展开某个实体的完整关系网络、切换不同跳数、对比不同时间段的图谱变化。

知识库的本质不是存了多少文档，而是文档之间的关联有多深。"文档堆"解决的是"信息存储"问题，"知识网"解决的是"知识推理"问题。当 RAG 从"搜索"走向"推理"，企业知识库才真正从"成本中心"变成"智能引擎"。