本文将探一探蚂蚁开源的另一套知识增强生成框架 KAG（Knowledge Augmented Generation），一套专门用于构建垂直领域知识库的逻辑推理问答框架。论文中提到，在电子政务场景下，KAG 达到了 91.6% 的准确率，在电子医疗等领域的问答表现同样不俗。

文章会先简要介绍 KAG 的概念和构建流程，然后在本地启动 KAG 做一次简单探索。它的问题规划机制非常有意思，值得一起看看。

1. KAG 简介

KAG 能有效克服传统 RAG 在向量相似度计算中的歧义问题，也能降低 OpenIE 引入的 GraphRAG 噪声。它支持逻辑推理、多跳事实问答等复杂场景。

OpenIE（神经开放域信息抽取）是一种从非结构化文本中提取信息的强大技术，不依赖预定义的领域知识或本体模式，适用范围更广。

KAG 的核心功能包括：

• 知识与 Chunk 互索引结构，整合更丰富的上下文文本信息
• 利用概念语义推理进行知识对齐，缓解 OpenIE 引入的噪声问题
• 支持 Schema-Constraint 知识构建，让领域专家知识能够被有效表示与构建
• 逻辑符号引导的混合推理与检索，实现逻辑推理和多跳推理问答

KAG 之所以强调专为垂直领域开发，就在于它采用 Schema 来约束知识图谱的构建。GraphRAG 只能根据自定义实体进行提取，而 KAG 允许用户自定义知识图谱的层次关系，并自动进行知识对齐。

2. 核心功能

2.1 LLM 友好的语义化知识管理

在私域知识库场景中，非结构化数据、结构化信息和业务专家经验往往同时存在。KAG 提出了一种对大型语言模型（LLM）友好的知识表示框架，基于 DIKW（数据、信息、知识、智慧）层次结构进行融合。这样一来，它能在同一知识类型（如实体类型、事件类型）上兼容无 Schema 约束的信息提取和有 Schema 约束的专业知识构建，同时支持图结构与原始文本块之间的互索引表示。

这种互索引表示有助于构建基于图结构的倒排索引，同时也能促进逻辑形式的统一表示、推理与检索。再通过知识理解、语义对齐等手段，进一步降低信息抽取的噪声，提升知识的准确率和一致性。

可以看到，数据被分块后，经过信息提取，形成了对齐的知识。

2.2 逻辑符号引导的混合推理引擎

KAG 提出了一种逻辑符号引导的混合求解和推理引擎。引擎包含三种运算符：规划、推理和检索。它将自然语言问题转化为结合语言和符号的问题求解过程，每一步都可以使用不同的运算符——精确匹配检索、文本检索、数值计算或语义推理——从而实现四种问题求解过程的集成：图谱推理、逻辑计算、Chunk 检索和 LLM 推理。具体流程如下图右侧所示。

从图中可以看到，问题经过规划生成了逻辑形式的推理步骤，然后检索并汇总各个子问题的结果，最终生成答案。稍后在代码中就能看到问题是怎样规划的。

3. 安装

KAG 开源地址：

• https://github.com/OpenSPG/KAG

整体代码结构分为 Builder 和 Solver 两部分，分别对应构建器和解决器。具体的构建流程或索引流程前文已有图示，此处不再赘述。

其实还有一个 kag-model 模块，但由于没有开源，这里就忽略了。

3.1 简单安装

简单安装是指通过 Docker Compose 直接启动所有服务，它会安装以下三个服务：

• openspg-server
• openspg-neo4j
• mysql

curl -sSL https://raw.githubusercontent.com/OpenSPG/openspg/refs/heads/master/dev/release/docker-compose.yml -o docker-compose.yml
docker compose -f docker-compose.yml up -d

然后打开网页 http://localhost:8887，参考官方文档 https://openspg.yuque.com/ndx6g9/0.5/nbb1bn3wegwue6yo#R4iWY 创建知识库。

需要配置以下几项：

配置完成后，在索引阶段会持续报错“向量批处理超过默认的 64”。使用的免费硅基流动 Embedding，看起来是 Docker 默认配置的 Embedding Batch 过大，而配置中无法修改 batch size，只能转向开发者模式。

3.2 开发者模式

即使是开发者模式，仍然需要安装刚才的 Docker Compose，它启动了一些依赖服务。KAG 框架本身并不包含前端或服务端代码。

• 创建虚拟环境

conda create -n kag-demo python=3.10 && conda activate kag-demo

• 克隆代码

git clone https://github.com/OpenSPG/KAG.git

• 安装依赖

cd ./KAG && pip install -e .

• 验证

knext --version

• 创建 Demo

cd kag/examples
vim ./example.cfg

编辑该文件，写入自己的 API KEY：

[project]
namespace = KagDemo
host_addr = http://localhost:8887
id = 1

[vectorizer]
vectorizer = kag.common.vectorizer.OpenAIVectorizer
model = BAAI/bge-m3
api_key = xxxx
base_url = https://api.siliconflow.cn/v1
vector_dimensions = 1024

[llm]
client_type = maas
base_url = https://open.bigmodel.cn/api/paas/v4
api_key = xxxx
model = glm-4-flash

[prompt]
biz_scene = default
language = en

[log]
level = INFO

使用如下命令创建项目，它会在 kag/examples 下创建 KagDemo 项目，并初始化一整套代码。但距离使用还需要提供数据并改写两个文件。

knext project create --config_path ./example.cfg

• 导入要索引的文件

导入四篇论文 graphrag.pdf、hipporag.pdf、hybridrag.pdf 和 lightrag.pdf 到 kag/examples/KagDemo/builder/data 目录下。

• 提交 Schema 到服务端

这一步用于自定义实体类型约束，这里暂不定义，走无 Schema 约束。需要回到 KagDemo 目录执行以下命令：

knext schema commit

• 编写 Builder 客户端代码

需要参考官方文档索引^[1]学习如何调用 SDK 编写 builder。写好的文件放在 KagDemo/builder/indexer.py，最后执行 python ./builder/indexer.py 启动构建。

• 编写 Solver 客户端代码

同样需要参考官方文档 Solver^[2] 编写 Solver，然后执行 python ./solver/evalForKagDemo.py。

4. 测试

测试的问题如下，它要求大模型获取两个知识后才能总结出答案。经过大约 42 秒，一次性输出了所有答案。

为什么会这么慢？按照 1.2 节所述，KAG 需要先规划问题、生成逻辑形式推导，之后再推理检索生成。也就是说，它需要等待第一轮 LLM 规划生成后，才能去检索并输出。来看一下它的推理过程，非常有意思：

这个推理过程似乎并不是每次都能生成，依赖 LLM 本身的能力，可能与使用的免费 glm-4-flash 测试有关。

根据源码，KAG 采用 CoA（Chain of Abstraction，抽象推理链）来生成问题推导步骤。CoA 出自论文 Efficient Tool Use with Chain-of-Abstraction Reasoning^[3]。

总结

本次分享就到这里。有需要的同学可以自己参考官方文档进行复现测试。其他部分就需要大家深入研究了。KAG 的概念相对较多，没有想象中那么直观，但值得花时间琢磨。