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

本文会简单的介绍一下 KAG 的概念和构建流程，然后尝试在本地启动 KAG 简单探索一下。它的问题规划非常有意思，请随我一起探索。

1. KAG 简介 

KAG 可以有效克服传统 RAG 向量相似度计算的歧义性和 OpenIE 引入的 GraphRAG 的噪声问题，支持逻辑推理、多跳事实问答等。

OpenIE: 神经开放域信息抽取(Open Information Extraction)，也被称为开放信息抽取，是一种从非结构化文本中提取信息的强大技术。 不同于传统的信息抽取方法，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 直接启动所有服务，它安装了以下 3 个服务

• 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 默认配置的 Emebdding 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 节所述，他需要先规划问题生成逻辑形式推导，之后再推理检索生成。所以他是需要等待第一轮 LLM 规划生成后，才能去检索然后输出。我们看一下它的推理过程，非常的有意思的。

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

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

总结 

本篇分享就到这里了，有需要的同学可以自己参考官方进行复现测试。其他部分需要同学们自己深入研究了，KAG 的概念会相对多一点，相对没那么直观。