告别人工智障！Dify+KAG：秒变「AI推理大师」。蚂蚁OpenSPG部署全解（含实测）

RAG (Retrieval-Augmented Generation，检索增强生成)——你一定不陌生吧！

答不对、搜不到，是 "非结构化文档" 问答中常见的两大痛点。

因为RAG存在向量相似度与知识推理相关性差距较大、对知识逻辑（如数值、时间关系、专家规则等）不敏感，严重降低了使用体验。

于是，
KAG（Knowledge-Aware Graph Generator，知识感知图谱生成器）应运而生。

它旨在充分利用知识图谱和向量检索的优势，为复杂问题提供更准确、更符合上下文的答案。

我们先了解下 KAG 是什么，如何部署、配置和使用，包括API使用 和 接入dify（一手实测），最后是RAG和KAG的简单评测。

让你从0到1学会 KAG 的 What 和 How。

0. 什么是KAG

OpenSPG 是由蚂蚁集团与 OpenKG 社区联合推出的一款基于 SPG（Semantic-enhanced Programmable Graph，语义增强可编程图） 框架的知识图谱引擎。

KAG 是基于OpenSPG引擎，用于为垂直领域知识库构建逻辑推理和 Q&A 解决方案。

主要特点

1. 1. 克服传统 RAG 向量相似性计算的复杂性
2. 2. 克服RAG 的不确定性
3. 3. 支持逻辑推理和多跳事实问答

工作原理

• • 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 -d

docker logs 可以显示 openspg 服务端启动成功的标识

docker logs -f release-openspg-server

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. 1. 数据读取（Reader）
   从原始数据源（如文本、数据库）加载信息。
2. 2. 预处理与拆分（Splitter）
   对数据进行清洗、分块或结构化处理。
3. 3. 知识抽取（Extractor）
   提取实体、关系、属性等知识要素。
4. 4. 向量化（Vectorizer）
   将知识转换为向量表示（如嵌入模型）。
5. 5. 对齐与融合（Alignment）
   整合多源数据，解决冲突或冗余。
6. 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: 具体问题
  

  

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 问答

节点1：开始
节点2：请求KAG

• • 请求方式：POST
• • 请求地址：https://ktzkcq-fcjkdp-8887.app.cloudstudio.work/v1/chat/completions/
• • Headers和BODY的配置参照 3.1 中介绍的配置，json格式要严格检查（若出现400错误）
  节点3：提前最后一个Answer. 代码如下

def main(data: str) -> dict:

    last_answer = ""

    # 按行分割数据
    for line in data.split('\n'):
        if line.startswith('data: {'):
            try:
                # 解析JSON数据
                json_data = json.loads(line[6:])  # 去掉"data: "前缀
                if'answer'in json_data:
                    last_answer = json_data['answer']
            except json.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

（注：评测基于同一份文档和同一问题，结果可复现。）

4.1 RAG效果

提示词

请总结知识库的内容来回答问题，请列举知识库中的数据详细回答。当所有知识库内容都与问题无关时，你的回答必须包括“知识库中未找到您要的答案！”这句话。

4.2 KAG效果

4.3 评测结果

评测维度与结果对比，如下表所示

关键总结

1. 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 框架仍处于初期开发阶段，仍有改进和提升的空间。
期待更多格式的文件类型解析，以提升知识提取和问答的准确性和效率。

---

实践出真知，与君共勉