KAG 技术与实践分享｜基于 KAG 框架自主完成领域图谱构建和知识问答

本文来自社区用户的投稿，如果你也在使用 KAG，欢迎参与社区的有奖征文活动。

作者：章彦博，
现任暗物智能科技（广州）有限公司资深 NLP 算法研究员。拥有 6 年以上的自然语言处理算法工作经验，长期从事智能对话系统、语音助手和可信智能
体技术的算法研发工作。曾主导王二狗群聊机器人算法研发，传音手机语音助手的自然语言理解（NLU）及对话系统算法研发与系统设计。目前主要专注于可信对齐模型算法研发以及 AgenticRAG、GraphRAG 等可信智能体算法研发与创新应用。

简介

检索增强生成（RAG）技术推动了领域应用与大模型结合。然而，RAG 存在着向量相似度与知识推理相关性差距大、对知识逻辑（如数值、时间关系、专家规则等）不敏感等问题，这些都阻碍了专业知识服务的落地。10 月 24 日，OpenSPG 发布 V0.5 版本，正式发布了知识增强生成（KAG）的专业领域知识服务框架。KAG 旨在充分利用知识图谱和向量检索的优势，并通过四个方面双向增强大型语言模型和知识图谱，以解决 RAG 挑战：

(1) 对 LLM 友好的知识表示

(2) 知识图谱与原文片段之间的互索引

(3) 逻辑符号引导的混合推理引擎

(4) 基于语义推理的知识对齐KAG 在多跳问答任务中显著优于 NaiveRAG、HippoRAG 等方法，在 hotpotQA 上的 F1 分数相对提高了 19.6%，在 2wiki 上的 F1 分数相对提高了33.5%。

我们已成功将 KAG 应用于蚂蚁集团的两个专业知识问答任务，包括电子政务问答和电子健康问答，与 RAG 方法相比，专业性有了显著提高。用户可以基于开源的 KAG 编程框架可以自助基于私域知识库完成领域图谱的构建和知识问答。

KAG框架介绍

在熟悉 KAG 框架之前要先熟悉一下整体的 OpenSPG 知识图谱引擎，KAG 框架是该引擎的重要组成部分。

KAG 框架包括 kg-builder、kg-solver、kag-model 三部分。本次发布只涉及前两部分，kag-model 将在后续逐步开源发布。

kg-builder 实现了一种对大型语言模型（LLM）友好的知识表示，在 DIKW（数据、信息、知识和智慧）的层次结构基础上，升级 SPG 知识表示能力，在同一知识类型（如实体类型、事件类型）上兼容无 schema 约束的信息提取和有 schema 约束的专业知识构建，并支持图结构与原始文本块之间的互索引表示，为推理问答阶段的高效检索提供支持。

kg-solver 采用逻辑形式引导的混合求解和推理引擎，该引擎包括三种类型的运算符：规划、推理和检索，将自然语言问题转化为结合语言和符号的问题求解过程。在这个过程中，每一步都可以利用不同的运算符，如精确匹配检索、文本检索、数值计算或语义推理，从而实现四种不同问题求解过程的集成：检索、知识图谱推理、语言推理和数值计算。

KAG知识索引

私域知识库场景，非结构化数据、结构化信息、业务专家经验 往往三者共存，KAG 参考了 DIKW 层次结构，将 SPG 升级为对 LLM 友好的版本。针对新闻、事件、日志、书籍等非结构化数据，交易、统计、审批等结构化数据，业务经验、领域知识等规则，KAG 采用版面分析、知识抽取、属性标化、语义对齐等技术，将原始的业务数据&专家规则融合到统一的业务知识图谱中。这使得它能够在同一知识类型（如实体类型、事件类型）上兼容无 schema 约束的信息提取和有 schema 约束的专业知识构建，并支持图结构与原始文本块之间的互索引表示。这种互索引表示有助于基于图结构的倒排索引的构建，并促进了逻辑形式的统一表示、推理。

知识索引构建(KAG-Builder)

结构化信息获取：KAG 使用信息抽取技术（如 OpenIE）来从文本中提取实体、事件、概念和关系，从而构建初步的知识图（KG）。这些信息分为片段存储在 KG 中，确保了数据的结构化和可检索性。

知识语义对齐：通过语义对齐，将不同粒度的知识对齐，以减少噪声和提高图的连接性。KAG 通过概念语义图对齐知识，实现了 KG 与文本片段的双向索引。这个过程包括实例分类、概念的超/下位词关系预测、语义关系补全和去歧义等步骤，使得知识图具备更高的语义区分性和节点的连通性。

图存储写入：最终将构建的知识图写入存储系统中。这一部分使用 KG 存储（例如 Neo4j）和向量存储（例如 Milvus）来分别存储图数据和向量信息，确保图结构和原始文本的有效融合。用于知识索引构建的大模型 prompt 如下：

KAG知识查询

逻辑形式引导的混合推理(KAG-QA)

KAG 提出了一种逻辑形式引导的混合求解和推理引擎。该引擎包括三种类型的运算符：规划、推理和检索，将自然语言问题转化为结合语言和符号的问题求解过程。在这个过程中，每一步都可以利用不同的运算符，如精确匹配检索、文本检索、数值计算或语义推理，从而实现四种不同问题求解过程的集成：检索、知识图谱推理、语言推理和数值计算。官方有个例子如下：

LFPlanner剖析

我们直接看代码比较清楚一些，官方定义了问题求解的prompt指令方法，总共有6个函数，分别是：get_spo， count，sum，sort，compare，get 如下所示：

"instruction": "",
    "function_description": "functionName为算子名;基本格式为 functionName(arg_name1=arg_value1,[args_name2=arg_value2, args_name3=arg_value3]),括号中为参数，被[]包含的参数为可选参数，未被[]包含的为必选参数",
    "function": [
      {
          "functionName": "get_spo",
          "function_declaration": "get_spo(s=s_alias:entity_type[entity_name], p=p_alias:edge_type, o=o_alias:entity_type[entity_name], p.edge_type=value)",
          "description": "查找spo信息，s代表主体，o代表客体，表示为变量名:实体类型[实体名称]，实体名称作为可选参数，当有明确的查询实体时需要给出；p代表谓词，即关系或属性，表示为变量名:边类型或属性类型；这里为每个变量都分配一个变量名，作为后续提及时的指代；注意，s、p、o不能在同一表达式中反复多次出现；当变量为前文指代的变量名是，变量名必须和指代的变量名一致，且只需给出变量名，实体类型仅在首次引入时给定"
      },
      {
          "functionName": "count",
          "function_declaration": "count_alias=count(alias)",
          "description": "统计节点个数，参数为指定待统计的节点集合，只能是get_spo中出现的变量名；count_alias作为变量名表示计算结果，只能是int类型，变量名可作为下文的指代"
      },
      {
          "functionName": "sum",
          "function_declaration": "sum(alias, num1, num2, ...)->sum_alias",
          "description": "数据求和，参数为指定待求和的集合，可以是数字也可以是前文中出现的变量名，其内容只能是数值类型；sum_alias作为变量名表示计算结果，只能是数值类型，变量名可作为下文的指代"
      },
      {
          "functionName": "sort",
          "function_declaration": "sort(set=alias, orderby=o_alias or count_alias or sum_alias, direction=min or max, limit=N)",
          "description": "对节点集合排序，set指定待排序的节点集合，只能是get_spo中出现的变量名；orderby指定排序的依据，为节点的关系或属性名称，若是前文提及过的，则用别名指代；direction指定排序的方向，只能是min(正序)或max(倒序)排列；limit为输出个数限制，为int类型；可作为最后的输出结果"
      },
      {
          "functionName": "get",
          "function_decl:aration": "get(alias)",
          "description": "返回指定的别名代表的信息，可以是实体、关系路径或get_spo中获取到的属性值；可作为最后的输出结果"
      }
    ],

跟传统不同的是传统的查询模版抽取通常只能通过字面意思用小模型做实体抽取和实体链接，然后借助路径搜索算法进行启发式配置查询模版，而这里采用了大模型自动分步骤规划（字儿里面看出字儿来）做实体抽取和模版生成的方法。除了增加了规划能力和总结能力，其它 pipeline 流程跟传统开放域 KBQA（注意我说的是开放域 KBQA,垂域 KBQA 的 pipeline 流程一般更简单粗暴）是很相似的。另外传统开放域知识图谱问答在定义模版方面可谓煞费苦心，定义的宽泛可能导致召回信息冗余度较高，定义的窄又不足以覆盖更多的问题类型。这里KAG 官方定义了上面6类，我相信也是经过深思熟虑的结果，理论上来说还可以再细分一些模版场景。

KAG框架本地实践

我们按官方教程上手实践。

KAG图谱后端服务安装

KAG图谱后端服务基于OpenSPG知识图谱构建框架，该框架我们之前有调研过，是大模型时代为数不多的利用大模型能力增强图谱构建的开源框架。首先按照OpenSPG-Server服务端官方说明文档搭建图谱服务端服务，我直接采用的是镜像安装方法：

cd yourpath
git clone [e-mail]:OpenSPG/openspg.git
cd yourpath/openspg/dev/release
# 修改docker-compose.yml的端口为："6008:8887"，然后执行下面命令
docker compose -f docker-compose.yml up -d

安装后可通过http://183.220.37.57:6008链接查看，如图所示：

KAG开发环境搭建

紧接着我们按照KAG安装说明文档安装KAG开发环境。如下：

# 安装python 虚拟环境：
conda create -n kag-demo python=3.10 && conda activate kag-demo

# 代码clone：
git clone https://github.com/OpenSPG/KAG.git 

# 进入项目根目录即./KAG，进行KAG安装: 
cd ./KAG && pip install -e .

# 验证是否安装成功
knext --version
knext --help 

KAG 开发环境搭建完毕，我们就可以实践 KAG 提供的官方示例，接下来我们这里探索几个典型的应用场景。

KAG 项目案例实践 -hotpotqa（无实体类型关系知识图谱 schema）

hotpotqa 官方教程写的非常清楚，一步步参考搭建即可。

# setp1:进入案例目录
cd kag/examples/hotpotqa/
# sStep2：项目初始化
knext project restore --host_addr http://127.0.0.1:6008 --proj_path .
# Step3：知识建模(注意这一步结束后就可以在前端http://127.0.0.1:6008查看schema效果)
knext schema commit
# Step4：知识抽取构建(注意这一步结束后就可以在前端http://127.0.0.1:6008查看不同知识类型的抽样效果)
python ./builder/indexer.py
# step5: 执行QA任务
python ./solver/evaForHotpotqa.py

构建完成后，打开http://183.220.37.57:6008，查看schema，效果如下：

注意：KAG 的图谱显示只有 schema 类型以及类型之间的关系或属性。具体实体值与实体类型，事件类型等关系并不直观在页面显示，这跟目前主流的知识图谱可视化工具有所不同，这块儿可以对比我之前调研的其它知识图谱平台：graphrag实践-交科所场景 （一）进一步查看知识抽样效果如下：

问答效果如下：

KAG 项目案例实践-医疗图谱（有实体类型关系知识图谱 schema）

医疗图谱官方教程写的非常清楚，一步步参考搭建即可。

# setp1:进入案例目录
cd kag/examples/medicine/
# sStep2：项目初始化
knext project restore --host_addr http://127.0.0.1:6008 --proj_path .
# Step3：知识建模(注意这一步结束后就可以在前端http://127.0.0.1:6008查看schema效果)
knext schema commit
# Step4：知识抽取构建(注意这一步结束后就可以在前端http://127.0.0.1:6008查看不同知识类型的抽样效果)
python ./builder/indexer.py
# step5: 执行QA任务
python ./solver/evaForMedicine.py

构建完成后，打开http://183.220.37.57:6008，查看 schema，效果如下：

进一步查看知识抽样效果如下：

问答效果如下：

KAG 项目案例实践-黑产挖掘（事件图谱 schema）

黑产挖掘官方教程写的非常清楚，一步步参考搭建即可。

# setp1:进入案例目录
cd kag/examples/riskmining/
# sStep2：项目初始化
knext project restore --host_addr http://127.0.0.1:6008 --proj_path .
# Step3：知识建模(注意这一步结束后就可以在前端http://127.0.0.1:6008查看schema效果)
knext schema commit
# Step4：知识抽取构建(注意这一步结束后就可以在前端http://127.0.0.1:6008查看不同知识类型的抽样效果)
python ./builder/indexer.py
# step5: 执行QA任务
python ./solver/qa.py

构建完成后，打开http://183.220.37.57:6008，查看 schema，效果如下：

进一步查看知识抽样效果如下：

问答效果如下：

KAG-QA VS Mindsearch

KAG-QA 和 Mindsearch 都引入了规划器，不同的是前者检索的是本地知识库和知识图谱，后者检索的网页。同样按两步分解，我们以大模型视角画一下流程图（每个模块都是个大模型节点）做一下对比分析：

解读：

1. 我们可以看到同样都具有规划器，且都有循环流程，直观感受 Mindsearch 更简洁，其驱动循环结束条件是其自己，而 KAG-QA 其驱动循环结束需要外在条件( Judge 模块)。这两种方式在业内都有应用案例，下面分析下各自的特征：

1.1 带判决条件的循环通常更灵活，一旦无法解决问题还可以回溯到最开始的地方重新规划，这种是典型的多智能体架构，典型的比如：Self-RAG 范式。

1.2 不带判决条件的循环，实际上并没有循环回溯机制，可以理解为不走回头路的意思，其完全依赖大模型的规划整合能力（通常需要对该能力进行特定微调，一般来说可以将迭代轮次控制在 2-3 轮以内）。如果不考虑独立出来的检索大模型能力，其类似单智能体架构，典型的比如：React 范式。

1.3 从系统复杂度上来看肯定 KAG-QA 更为复杂，从智能体技术的发展趋势多智能体架构也会应用越来越广泛，然而现阶段来说真实落地的场景不多，我们可以看早期 chatgpt 有类似的做法，但现在能体验到需要二次回溯迭代的情况不多。实际上我们更关心的是一次命中成功率，而非多次循环迭代后的命中成功率。因此在目前的实际应用中 Mindsearch 的方案更具可落地空间，而且真实落地的时候一般都做了特定优化，比如最简单的一步规划一步总结，或者将规划控制在 2-3 轮以内。

2. 抛开 KAG-QA 和 Mindsearch 规划循环迭代的差异，检索器各自也有很大的差异，KAG-QA 明显更为复杂，Mindsearch 直接检索 web 信息。KAG-QA 的检索pipeline 跟传统开放域知识问答流程很像，只不过用大模型做了升级。需要提一点的是 KAG 的检索还把知识图谱检索和文本向量检索做了整合，这个跟目前业内图谱RAG的理念比较一致，应该来说这方面也有其先进的一面。

3. 此外，不管是 KAG-QA 还是 Mindsearch 都比较耗费大模型资源，实测二步规划的场景，KAG-QA 要调用 12 次（参见附录），而 Mindsearch 则需要 9 步。这比传统的 NaiveRAG 多了很多倍，我相信这些框架在设计之初一定也是知道整体耗时会显著增加，但还是超这个方向去了，这让我想起 o1 技术，慢思考相比gpt4-o 的快思考确实给人体验上慢了许多，但还是一往无前的去了。我想这里面可能存在 2 个关键因素，一方面确实慢了之后效果上确实有显著提升，另外一方面从技术路线上看这种慢是值得的，短期内可能确实存在耗时问题，但未来天花板很高，而且很可能是通往 AGI 的正确道路（毕竟人也有快思考和慢思考之分）。

建议后续优化点

• BUG点：

Reflection 部分有bug，目前已提工单

https://github.com/OpenSPG/KAG/issues/70。

• BUG优化点

1.个人认为第一步规划的结果可以做个预处理，当并行规划结果的时候可以像 mindsearch 那样做个并行执行（比如：Are Christopher Nolan and Sathish Kalathil both film directors?），如果是串行规划结果则还保持原先方法。这样提升流程效率。

2.实体链接的部分感觉可以做个优化，甚至小模型来做。

3.个人感觉规划的部分的6个函数还可以根据 badcase 进一步分析整合优化。

4.KAG 的规划不仅可以用于多跳推理，也可以做全局问答（类似微软得 graphrag），但全局性可能不强，因为有一些全局性的问题并不能很好的分解成子问题，这块儿可以具体整个全局性评测集评估一下，如果能跟 graphrag 的全局性问答的优点做整合，个人认为是个不错的思路。

5.高质量的图索引构建比较重要。现阶段大家都关注在图查询，但对于高质量的图索引关注度比较少，这块儿如果能建立个 benchmark，进而通过 prompt 提示工程甚至模型微调，我认为可以进一步提升 graphrag 的效果天花板。

附录 KAG-QA prompt示例

KAG 共建

目前 KAG 还处于早期阶段，诚邀对知识服务和知识图谱技术感兴趣的用户和开发者加入我们，共建新一代 AI 引擎框架。

GitHub

OpenSPG 是一个语义增强的可编程知识图谱：

https://github.com/OpenSPG/openspg

KAG 是一个知识增强生成的专业领域知识服务框架，KAG 依赖 OpenSPG 提供的引擎依赖适配、逻辑推理执行等能力：

https://github.com/OpenSPG/KAG

欢迎大家 Star 关注~