ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(22, 119, 255);padding: 0px 2px;">
KAG（Knowledge-Aware Graph Generator，ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(22, 119, 255);padding: 0px 2px;">知识感知图谱生成器）应运而生。它旨在充分利用知识图谱和向量检索的优势，为复杂问题提供更准确、更符合上下文的答案。
我们先了解下KAG是什么，如何部署、配置和使用，包括API使用和接入dify（一手实测），最后是RAG和KAG的简单评测。
让你从0到1学会KAG的 What 和 How。
0. 什么是KAG
OpenSPG 是由蚂蚁集团与 OpenKG 社区联合推出的一款基于 SPG（Semantic-enhanced Programmable Graph，语义增强可编程图） 框架的知识图谱引擎。
KAG是基于OpenSPG引擎，用于为垂直领域知识库构建逻辑推理和 Q&A 解决方案。
主要特点
1. 克服传统 RAG 向量相似性计算的复杂性 2. 克服RAG 的不确定性 3. 支持逻辑推理和多跳事实问答
工作原理
如上图所示，KAG架构由三个核心组件组成：
KAG-Builder、KAG-Solver和KAG-Model。•KAG-Builder负责构建离线索引。该模块提出了一个兼容大型语言模型的知识表示框架，并实现了知识结构与文本片段之间的相互索引机制。KAG-Builder相关代码[1] •KAG-Solver引入以逻辑形式为导向的混合推理引擎，融合大型语言模型推理、知识推理和数理逻辑推理，并利用语义推理进行知识对齐，提升KAG-Builder和KAG-Solver在知识表示和检索方面的准确性。KAG-Solver相关代码[2] •KAG-Model基于通用语言模型，并针对各个模块所需的特定能力进行优化，从而提升整体模块性能。
1. 部署 OpenSPG
硬件要求
CPU ≥ 8 cores;
RAM ≥ 32 GB;
Disk ≥ 100 GB;软件要求
•操作系统
macOS 用户：macOS Monterey 12.6 或更新版本
Linux 用户：CentOS 7 / Ubuntu 20.04 或更新版本
Windows 用户：Windows 10 LTSC 2021 或更新版本•应用软件
macOS / Linux 用户：Docker，Docker Compose
Windows 用户：WSL 2 / Hyper-V，Docker，Docker Compose
Docker ≥ 24.0.0 & Docker Compose ≥ v2.26.1.启动服务
# 设置 HOME 环境变量（仅 Windows 用户需要执行）
# set HOME=%USERPROFILE%
# 拉取docker-compose.yaml 文件
$ 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 -ddocker ps能看到
8887、7474这两个关键端口已在运行docker logs 可以显示 openspg 服务端启动成功的标识
dockerlogs-frelease-openspg-server
在浏览器中访问
http://127.0.0.1:8887，使用默认用户名和密码登录（用户名：openspg，密码：openspg@kag）。2. 配置OpenSPG
以下是全局配置，包括通用配置、模型配置和用户配置
2.1 通用配置
通用配置包括图存配置、向量配置、提示词中英文配置
图存储配置
{
"database":"neo4j", # 图存储的数据库名称，固定和知识库英文名称保持一致，且不可修改
"uri":"neo4j://release-openspg-neo4j:7687",
"user":"neo4j", # 默认值为：neo4j
"password":"neo4j@openspg", # 默认值为：neo4j@openspg
}向量配置（硅基流动[3]示例）
{
"type": "openai",
"model": "BAAI/bge-m3",
"base_url": "https://api.siliconflow.cn/v1",
"api_key": "你的硅基流动API-KEY",
}提示词中英文配置
用于模型调用时判断是否使用中文(zh)或英文(en)。
{
"biz_scene":"default",
"language":"zh"
}2.2 模型配置
{
"type": "maas",
"base_url": "https://api.siliconflow.cn/v1",
"api_key": "你的硅基流动API-KEY",
"model": "DeepSeek-ai/DeepSeek-V3",
"stream":"False",
"temperature":0.7
}2.3 知识库配置
2.3.1 新建知识库
配置项：
• 知识库中文名称 • 知识库英文名称 • 图床、向量、提示词中英文配置均在第1步配置过了，默认即可
2.3.2 新建知识
设置最大长度和对话模型
2.3.3 知识解析
解析完成，可以看到日志的6个过程：
1.数据读取（Reader）
从原始数据源（如文本、数据库）加载信息。2.预处理与拆分（Splitter）
对数据进行清洗、分块或结构化处理。3.知识抽取（Extractor）
提取实体、关系、属性等知识要素。4.向量化（Vectorizer）
将知识转换为向量表示（如嵌入模型）。5.对齐与融合（Alignment）
整合多源数据，解决冲突或冗余。6.存储与输出（Writer）
将结果保存到知识库或下游系统。
3. 使用OpenSPG
openspg API参考[4]
3.1 API测试
请求方法：POST
请求地址：https://你的ip+8887端口/v1/chat/completions/
请求参数：3个Headers + 1个Body
【Headers参数】
• content-type: application/json • Accept: text/event-stream • Cookie:
【Body参数】
• sessionId: (Body parameter)知识库问答，当前会话的id，可以通过 1.5 创建• projectId: (Body parameter)知识库的id。• thinking_enabled: (Body parameter)是否开启深度推理，开启true。• prompt: (Body parameter) 问题• type: 支持的类型，目前只支持text • content: 具体问题
YOUR_BROWSER_COOKIES按照以下步骤获取OpenSPG页面 -- F12 -- Network -- Doc -- Name -- Header -- Cookie
sessionId和projectId在推理问答页面的网址中
假设推理问答页面网址：
https://ltzuda-fuwswy-8887.app.cloudstudio.work/#/analysisReasoning?projectId=3&sessionId=4
那么得到：
• sessionId: 4• projectId: 3
可以手动新建会话，也可以通过API创建
详见openspg API参考[5]
3.2 Dify+KAG 问答
Dify接KAG整体工作流如下所示节点1：开始
节点2：请求KAG
•请求方式：POST •请求地址：https://ktzkcq-fcjkdp-8887.app.cloudstudio.work/v1/chat/completions/ • Headers和BODY的配置参照 3.1 中介绍的配置，json格式要严格检查（若出现400错误）
节点3：提前最后一个Answer. 代码如下
defmain(data:str) ->dict:
last_answer =""
# 按行分割数据
forlineindata.split('\n'):
ifline.startswith('data: {'):
try:
# 解析JSON数据
json_data = json.loads(line[6:]) # 去掉"data: "前缀
if'answer'injson_data:
last_answer = json_data['answer']
exceptjson.JSONDecodeError:
return{
"result":"未提取到答案",
}
return{
"Last_answer": last_answer,
}节点4：直接回复
发起一次请求 相当于在会话页面发送了一次对话，返回结果同时也会呈现在OpenSPG会话页面。
完整工作流可以看GitHub链接：GitHub工作流[6]
需要修改两处：请求地址和你的Cookie
注1：sessionId和projectId必须已存在，不能请求回答的同时让它创建
注2：word 和 pdf 解析还存在bug，未解析成功，坐等后续产品的更新。。。
1.wps的.docx 分段时预览不成功
2.wps转的.pdf 分段时预览不成功
3.微软word2021的.docx 分段时预览不成功
4..微软word2021转的.pdf 成功！！！
4.简单评测 RAG 和 KAG
| 评测 | 具体描述 |
| 评测文档 | |
| 评测问题 | |
| 段落长度 | |
| 嵌入模型 | |
| RAG大模型 | |
| KAG大模型 |
（注：评测基于同一份文档和同一问题，结果可复现。）
4.1 RAG效果
提示词
请总结知识库的内容来回答问题，请列举知识库中的数据详细回答。当所有知识库内容都与问题无关时，你的回答必须包括“知识库中未找到您要的答案！”这句话。
4.2 KAG效果
4.3 评测结果
评测维度与结果对比，如下表所示
| 思考深度 | 深层逻辑推理 | |
| 思考时长 | ||
| 总结能力 | 完整人话总结 | |
| 语言自然度 | 说人话 |
关键总结
1.KAG的深度优势
• 在相同文档和问题下，KAG能提取多层语义关系，而RAG仅回答表层信息。 •案例对比： • RAG："LangChain作为上层框架，可集成...通过LangChain的抽象层..." • KAG："LangChain可以通过其框架集成和利用OpenAI的模型"
2.RAG的速度与局限 • 用上DeepSeek-R1的RAG 虽然还是比 KAG更快，但牺牲了逻辑连贯性。• 适合实时性要求高但总结要求低的场景。 3.总结能力的本质差异 • KAG的总结呈现教学式逻辑（问题→方案→价值），而RAG输出知识点罗列。
4.4 评测结论
KAG在语义理解、总结能力和用户体验上显著优于RAG，尤其在需要技术解释的场景中，其"说人话"的能力更符合实际需求。而RAG（含DeepSeek-R1）更适合对实时性敏感的轻量级问答。
写在最后
KAG 框架仍处于初期开发阶段，仍有改进和提升的空间。
期待更多格式的文件类型解析，以提升知识提取和问答的准确性和效率。
实践出真知，与君共勉