中科数睿的实践：如何落地 GraphRAG 国产化？

导读

GraphRAG 如何选择图数据库？不同的 GraphRAG 实现方案有哪些优劣势？如何结合大模型与图数据库实现 GraphRAG 的完全国产化？别再让 AI “胡说八道”给答案了～从真实的企业级 GraphRAG 探索历程中，获取最精华的经验总结！

作者张哲源，从事多年人工智能行业，目前在中科数睿从事大模型开发与应用。

本人是多个图数据库的认证专家，相对来说，评判会公正客观。本人不偏袒任何一个图数据库，所有观点代表个人在使用中的想法。

同时看完我们的完整探索过程也能理解：为什么我在 NebulaGraph 北京 nMeetUp 中，对 NebulaGraph 和 TuGraph 使用相同算法，却走了两条路径。

一、我所使用过的国产图数据库

NebulaGraph

分布式原生图数据库，强调“千亿节点、万亿边”水平扩展与毫秒级查询；自研 nGQL（兼容部分 Cypher 风格），支持属性图、索引、图算法组件；有企业版与云服务形态。

HugeGraph

实现 Apache TinkerPop3 / Gremlin，支持多种后端存储（HBase、Cassandra、RocksDB 等）与多类索引，定位“分析型+快速关联查询”，支持与 Hadoop/Spark 集成及图算法库。

TuGraph

面向高性能、分布式事务 + 图分析场景，应用于支付风控等业务；公开材料强调在多项国际基准中表现及万亿级业务实践锤炼。

GES

面向百亿节点/千亿边规模实时多跳查询、风控/推荐/反欺诈等；提供可视化分析界面。

KonisGraph

KonisGraph（TencentDB for KonisGraph）是一种云端图数据库服务，基于腾讯在海量图数据上的实践经验，提供一站式海量图数据存储、管理、实时查询、计算、可视化分析能力；KonisGraph 支持属性图模型和 TinkerPop Gremlin 查询语言，能够帮助用户快速完成对图数据的建模、查询和可视化分析。

二、不同 GraphRAG 方案的探索

基于 NebulaGraph 的探索阶段

NebulaGraph 在 2023 年 8 月与 LlamaIndex 首次提出并实现 GraphRAG.

GraphRAG vs DeepSearch？GraphRAG 提出者给你答案

我们早在 2023 年年初就有业务痛点。

需要一个机制在确保权限边界与敏感最小暴露的前提下，快速回答“某监管条款在哪些现行合同条款体现并与竞品 X 定价/功能差异是什么”这类跨域多跳问题。

目标是：

• 提升合规核查与条款比对效率，减少误用过期条款或未授权资料；

• 支持监管→合同→内部政策→风险指标或竞品功能差异的可追溯路径；

• 对频繁修订保持低成本增量更新与“最新有效”识别；

• 通过最小必要敏感上下文与回答引用路径满足审计与风险控制。

我们尝试了早期的 RAG 方案、微调方案、提示词挂 RAG 通过召回不同提示词来检索不同知识块等。但都难以解决这个需求，一直被压着。

我们看到了 NebulaGraph 给出的 GraphRAG 方案后，做出了尝试。我们跑了几个简单的文档，发现了一些问题，但勉强可用。

• 如果出现本文档这类信息，那么很多文档都会被当作一个文档实体。

• 有概率出现中英文混杂。

• 丢失文档细节。 我们做了文档清洗、提示词工程、NER 模型训练等虽然缓解了原生框架的问题。

基于微软 GraphRAG 的探索阶段（想国产化实现）

2024 年 7 月， 微软公布开源代码 GraphRAG，由于之前我们改良了 GraphRAG，那么测试这个开源框架我们就有了明确的目标：

验证 Microsoft GraphRAG 的“实体/关系抽取 + 社区聚类 + 层级摘要 +Local/Global 双检索”在 全局综述类问题（宏观趋势、风险主题汇总、合同修订焦点）与跨文档主题归纳上，相比现有自研 NebulaGraph GraphRAG（偏 fine‑grained clause / entity 精准定位）是否带来：

• 全局主题覆盖增益；

• 引用多样性提升；

• 可解释聚合摘要能力；

• 同时评估成本、延迟与权限/敏感改造可行性。

我们采用了与 NebulaGraph 几乎一样的预处理方案，但有几个问题：

• 构建与查询成本（指时间成本相对于原方案高了20%，但精度确实提高了不少）

• 增量更新与重建代价（早期缺乏高效增量 → 后续版本提供但仍需复杂逻辑）

• 全局模式的 Token 膨胀与 Prompt 长度风险

• 实体 / 社区质量与稳定性（聚类与摘要噪声扩散）

• 幻觉与摘要偏差（仍依赖 LLM 生成，新增风险向量）

我们也尝试了更换图数据库（这里指国产的几大图数据库，但没有 Tugraph，因为我当时还不知道这个图数据库）、更换模型（qwen、glm 等国产模型）但并没有实际上的提升。

基于 DB-GPT 的 GraphRAG 探索

随后，我们注意到了蚂蚁开源的 GraphRAG 同时也第一次接触到了 TuGraph.

• 尽管 DB-GPT 已相对优化微软 GraphRAG 的 token 与延迟，社区摘要 / Global 查询仍包含多轮 LLM 生成与汇总：当查询是“精确定位 / 简答 / 条款或字段点查 / 结构化参数问答”时，走社区全局合并会引入不必要成本与延迟；

• 在我们所处的金融 / 合同 / 竞品场景里，大量日常问题（例如“条款 7.3 的违约责任是什么？”、“竞品 A 的实时告警支持延迟阈值？”）需要的是高精度局部片段 + 少量相邻上下文，原生框架并不支持这些，而且也只对 TuGraph做了支持。想改进起来，开发成本可能有点高，而且上述问题也未必可以缓解。

KAG 的探索

2024 年 10 月，我们又注意到了新星 KAG.我们在浏览技术论坛时看到：

• 纯向量 RAG 容易受限于“语义相似 ≠ 知识推理相关性”，对数值、时间、规则、逻辑链条敏感度不足；

• GraphRAG 通过图 + 摘要改善跨文档综合与主题覆盖，但其基于抽取的社区摘要仍可能受噪声与逻辑形式缺失影响；

• 因此 KAG 旨在让 LLM 与知识图双向增强，显式支持多跳逻辑、结构约束与可验证推理路径，以提升专业领域（政务、医疗等）问答的专业性与可解释性。

于是，我们尝试了新的方法 KAG. 我看完多个技术文章以及论文，为了方便理解我简单说一下 RAG 到 KAG 的进阶：

• RAG 核心是检索相关片段 → 拼接上下文 → 生成，优点是可更新、降低幻觉但对逻辑链条与结构化约束弱；

• GraphRAG（微软） 在 RAG 之上加入 LLM 生成知识图 + 社区发现与多级摘要，强化全局主题探索与长文档信息组织；

• KAG 则进一步把逻辑形式（类似“查询计划”）与双向互索引引入推理流程，强调结构与文本之间的往返映射、可验证推理路径与多种算子融合，以减小“相似但不推理相关”与摘要层噪声对结果的影响。

但是，KAG 仍需：

• 高质量、领域覆盖充分的知识建模（图谱与逻辑形式）与互索引维护;

• 对多样化复杂知识的抽取与建模精度;

• 合理的逻辑规划与算子库扩展（否则会退化成普通 RAG）；

• 额外构建与调度成本权衡（在简单 FAQ / 单跳问答上可能不如轻量 RAG）

三、GraphRAG 的完全国产化

DeepSeek 之前

由于尝试了各类开源框架并未解决我们的问题，我们走了站在巨人肩膀的道路。同时在走自己的路的同时，也没有忘记看看新的技术。比如 DB-GPT 的 0.72 我们也做了尝试和调研。

最初我们的想法是融合 RAG+GraphRAG 技术。GraphRAG 相对微软的我把实体的描述信息、实体长度>50字符的信息、摘要大于 200 字符拆分后放到 RAG, 最后把两边的信息拼接起来做个文本摘要当作已知信息，与用户的问题拼接后当作 input 给大模型，最后生成答案。但实际的效果在 3K 的样本中并没有超越其他技术方案。

经过这次的实验我想，有 NL2SQL 为什么不尝试 NL2Cypher 呢？这样是不是可以一定程度上让大模型自己找到需要的实体关系从而避免生成一些无关摘要以及减少提示词的长度呢？

同时社区算法我们只要社区不要摘要，总结让模型自己完成。例如，将“芒果”、“香蕉”、“菠萝”直接归类于“水果”社区。当处理全局查询（如“水果有哪些？”）时，只需从“水果”社区向下遍历其子成员即可获得结果。

经过这次的调整，我们也仅仅减少了构建和检索时间，精度没有提升，反而丢失了很多信息。同时，发现模型居然有些数字进入图谱中是错的。不自己看将难以发现。同时，所有的国产图数据库都不完全兼容 Neo4j 的语法，而很多大模型的语句都是生成的 Neo4j 可以运行的语句，可能还要额外的微调。

DeepSeek 之后

在这个时候，DeepSeekR1 横空出世。我们初步评测后发现，DeepSeek 在知识抽取以及 Cyper 生成上可以进行诱导。于是乎，我们采取了两个技术并行的思路。

微调 DeepSeek 并让他生成占位符，同时根据问题复杂度控制思考长度。

尝试 MySQL 进行数值存储以增加数值信息的查询，以及修改解决新发现的模型生成错误数字的问题。

这个是我们微调的结果，并且可以在 ollama上、vllm 等框架上运行。也生成了占位符。当然目前微调效果最好的是 NebulaGraph （支持的语句可能更多还是其他原因，我们暂时没有发现，但是我们模型生成的语句成功执行的概率大于其他数据库），但是从多图检索的效果上看却是 TuGraph 更快。

因此我们出于成本的考虑我们采用了 NebulaGraph+TuGraph 两种方案并行的路线，但是并不代表其他图数据库不行，可能随着数据量增大确实效果会好转，但我们的人力物力不支持我们同时跑这么多图数据库。

结合 MCP+客户反馈

在经过公司内部的研究、MCP 的出现以及我们卖给产品的客户反馈，因此微调方案变更为了：

同时，也明确了：

• 充分发挥各数据库优势。NebulaGraph 走微调的道路，TuGraph 图谱管理上下文信息（含可能用到的语句）、其他数据库后续开发（客户可能有偏好，同时我们发现其他的数据库随着数据量的增多确实有所提升）

• 放弃图社区改用子图融合和类别下钻的方式合并查找类别信息（类似上文提到的水果的列子）

核心流程

系统把原始文本按块流式送入大模型抽取三元组 → 迭代补全与指代消解 → 图/指标分层落库 → 查询时按问题复杂度选择图 / 向量 / API → 用占位符生成草稿 → 并行回填得到可解释答案，从而降低幻觉并保证数值与结构准确。

注意：NebulaGraph 要进行微调，TuGraph 要设计图谱管理上下文信息。

四、实现方法拆解

离线 / 在线一体的流式解析阶段

• 文本分块 & 第一轮抽取：固定大小的文本块进入 LLM，输出等长数组组成 (实体1, 关系, 实体2) 三元组，实现初始结构化抽取（输入：原始分块；输出：三元组数组）。

• 不完整句检测：检测块尾是否截断或含代词，若是则把最近 k 个三元组与后续文本拼接以形成更完整上下文（缓解切分导致的语义断裂）。

• 第二轮解析（补充上下文）：在扩展后的上下文里执行指代消解与再抽取，对第一次结果去重与合并，提高实体、关系完整度与正确归属。

• 流式循环：写库后立即清空暂存数组、复位索引，继续下一个文本块，实现准实时的解析流水线（降低峰值内存）。

分层存储与数据治理

• 结构性的实体节点、关系、维度属性写入图数据库；

• 易变 / 指标类数值落到 MySQL，解决“指标集中修改困难”问题（图保持关系语义，数值在行存中灵活更新）。

查询时动态检索与规划

动态检索：用户提问进入 LLM 前置分析“复杂度 / 类型”，在图数据库中探测相关实体是否存在，进而决定调用：仅图查询、图 + 向量补充、或外部函数 / API（多通道检索策略）等。

占位符生成与并行回填

• 占位符输出：模型在推理草稿里用 §GRAPH§ / §FUNC§ / §MYSQL§ 等标记尚未获取的真实结果，避免臆测并把 I/O 与生成并行化。

• 回填呈现：前端或中间层并行执行实际查询（图遍历、SQL、外部接口），按占位符映射替换，得到最终答案及其来源，提升可解释与数值准确率

• 备注：因为执行查询程序就能判断是否正确，如果错误，开个 subtask（本身整个程序也有个监工 AI）重新生成。因此，占位符生成错误这一问题可很大程度缓解。

五、大模型与 NebulaGraph 结合的知识库

效果展示

我们的思考过程：

我们的回答：

优劣势及未来展望

• 优势：减少幻觉（仅回答已存在实体 + 占位符后填）、检索并行加速、图多跳增强复杂推理、指标准确率接近 100%、模块解耦可独立迭代。

• 局限：趋势 / 创意生成受限（因偏结构填充）、长篇连续指代有内存与上下文风险、前期微调 & 建库成本高、运维面（LLM + NebulaGraph + MySQL）复杂、占位符流程需要精细脱敏与权限控制。

• 未来：支持其他图数据库，优化方案解决上下文风险以及趋势分析问题。