这里讨论的OpenSPG—KAG是知识增强生成的一个特例,是一个基于 OpenSPG 引擎和大型语言模型的逻辑推理和问答框架,用于为垂直领域知识库构建逻辑推理和问答解决方案。KAG 能有效克服传统 RAG 矢量相似度计算的模糊性和 GraphRAG 的噪声问题,支持逻辑推理和多跳事实问答等,明显优于目前的RAG方法。
OpenSPG-KAG 的目标是在专业领域建立一个知识增强的 LLM 服务框架,充分结合了知识图谱的逻辑和事实特点。其核心特征包括:
在私有知识库的背景下,非结构化数据、结构化信息和业务专家经验常常共存。OpenSPG-KAG 引用 DIKW 层次结构将 SPG 升级到对 LLM友好的版本。
对于新闻、事件、日志和书籍等非结构化数据,以及交易、统计和批准等结构化数据,还有业务经验和领域知识规则,OpenSPG-KAG 采用布局分析、知识提取、属性标准化和语义对齐等技术,将原始业务数据和专家规则整合到一个统一的业务知识图谱中。
这使得它能够兼容同一知识类型 (如实体类型、事件类型) 上的信息抽取和图约束的专业知识构造,并支持图结构和原始文本块之间的交叉索引表示。
这种互索引表示有助于构建基于图结构的倒排索引,促进逻辑形式的统一表示和推理。
OpenSPG-KAG 提出了一个逻辑上正式的引导混合解决方案和推理机制。该引擎包括三种类型的操作符: 规划、推理和检索,它们将自然语言问题转换为结合语言和符号的问题解决过程。
在该过程中,每个步骤可以使用不同的算子,如精确匹配检索、文本检索、数值计算或语义推理,从而实现检索、知识图谱推理、语言推理和数值计算 4 个不同问题求解过程的融合。
OpenSPG-KAG 框架包括三个部分: Kg-builder、 kg-solver和 KAG 模型。这个版本只涉及前两个部分,kag-model 目前尚未开源发布。
Kg-builder 实现了大模型友好的知识表示。信息技术基于 DIKW 的层次结构,提升了 SPG 的知识表示能力,能够兼容无模式约束的信息抽取和对同一知识类型 (如实体类型和事件类型) 具有模式约束的专业知识建构,并支持图结构与原始文本块之间的互索引表示,支持推理问答阶段的高效检索。
Kg-solver 使用逻辑符号引导的混合求解和推理引擎,包括规划、推理和检索三类算子,将自然语言问题转化为语言和符号相结合的问题求解过程。在该过程中,每个步骤可以使用不同的算子,如精确匹配检索、文本检索、数值计算或语义推理,从而实现检索、知识图谱推理、语言推理和数值计算 4 个不同问题求解过程的融合。
操作系统:
软件要求:
使用以下命令下载 Docker-Compose. yml 文件,并使用 Docker Compose 启动服务。
# set the HOME environment variable (only Windows users need to execute this command)
# set HOME=%USERPROFILE%
curl -sSL https://raw.githubusercontent.com/OpenSPG/openspg/refs/heads/master/dev/release/docker-compose-west.yml -o docker-compose-west.yml
docker compose -f docker-compose-west.yml up -d使用浏览器导航到 OpenSPG-KAG 的默认 url: http://127.0.0.1:8887。
对开发者而言,可以:
# Create conda env: conda create -n kag-demo python=3.10 && conda activate kag-demo
# Clone code: git clone https://github.com/OpenSPG/KAG.git
# Install KAG: cd KAG && pip install -e .
# 安装 KAG: cd KAG & & pip Install-e。OpenSPG-KAG 提供了一个可视化界面,支持用户在页面上构建、询问和管理私有领域知识库。同时,可以直观地看到建模结果。在生产模式下使用时,OpenSPG-KAG 包 python 包被构建到 openspg 容器中,提供默认的构建和推理问答功能。在知识抽取和图推理阶段对生成模型和表示模型的调用都是从 openspg 服务器容器环境中发起的。
用户可以自定义数据库、矢量模型和通用提示词。
数据库配置,默认情况下,可以填充本地 openspg-neo4j 图形存储数据库:
{
“database”:”neo4j”, # default datahbase name, which will be replaced by namespace of knowledge base
“uri”:”neo4j://release-openspg-neo4j:7687", # neo4j server address, which can be replaced by customized neo4j server which is accessbile
“user”:”neo4j”, # neo4j username, default to neo4j
“password”:”neo4j@openspg”, # neo4j password, default to neo4j@openspg
}向量模型配置:
{
“type”:”openai”, # KAG supports openai compatible interface of embedding service
“model”:”BAAI/bge-m3", # model name of embedding service
“base_url”:”https://api.siliconflow.cn/v1", # url of embedding service
“api_key”:”your api key”
}提示词必要参数。用于确定在调用模型时使用中文还是英文:
{
“biz_scene”:”default”, # biz_scene for kag template
“language”:”en”, # en for english and zh for chinese
}OpenSPG-KAG 支持 Open-AI 兼容的生成模型 API(chatgpt,deepseek,qwen2 等) ,并提供 vllm,ollama 和其他运行方式。
{
“model”: “deepseek-chat”,
“base_url”: “https://api.deepseek.com",
“api_key”: “deepseek api key”
}帐户管理可以在用户配置中完成,包括创建 / 删除用户,修改密码等。用户可以使用全局配置为特定的知识库,或自定义一个新的配置。可以使用默认配置,默认数据库名称由知识库名称代替,默认配置是在全局配置中设置的。
特别注意: 不同表示模型生成的嵌入向量即使维数相同也不能混合,因此在知识库配置中,与表示模型相关的配置一旦设定就不能修改。
在私有领域知识库背景下,图构建和基于推理问答的有效性与模式设计、知识抽取提示、表示模型选择、问题规划提示、图检索算法和答案生成密切相关。这些定制还没有在产品端公开,需要用户利用 OpenSPG-KAG 开发人员模式来实现他们的定制。
当使用开发人员模式时,用户在本地环境中执行 KAG Python 包代码。OpenSPG 服务器只提供模式管理、推理执行和图形数据库适配等功能。在知识提取和图推理阶段,对生成模型和表示模型的调用是从本地环境中发起的。
在创建一个项目之后,一个与项目配置中的命名空间字段同名的目录 (例如,示例中的 TwoWikiTest) 将在 KAG/examples 目录下创建,KAG 项目代码框架将被初始化。
kg-builder 的示例:
$ vim ./builder/indexer.py
import os
import logging
from kag.common.registry import import_modules_from_path
from kag.builder.runner import BuilderChainRunner
logger = logging.getLogger(__name__)
def buildKB(file_path):
from kag.common.conf import KAG_CONFIG
runner = BuilderChainRunner.from_config(KAG_CONFIG.all_config[“kag_builder_pipeline”])
runner.invoke(file_path)
logger.info(f”\n\nbuildKB successfully for {file_path}\n\n”)
if __name__ == “__main__”:
import_modules_from_path(“.”)
dir_path = os.path.dirname(__file__)
# Set the `file_path` to the path of the previously prepared corpus file.
file_path = os.path.join(dir_path, “data/2wiki_sub_corpus.json”)项目的目录结构如下:
builder ├── ckpt │ ├── chain │ ├── extractor │ ├── kagcheckpoint01.ckpt │ ├── postprocessor │ ├── reader │ └── splitter ├── data │ ├── 2wikisub_corpus.json ├── indexer.py
kg-solver的示例:
$ vim ./solver/qa.py
Paste the following content into qa.py.
import json
import logging
import os
import time
from concurrent.futures import ThreadPoolExecutor, as_completed
from tqdm import tqdm
from kag.common.benchmarks.evaluate import Evaluate
from kag.solver.logic.solver_pipeline import SolverPipeline
from kag.common.conf import KAG_CONFIG
from kag.common.registry import import_modules_from_path
from kag.common.checkpointer import CheckpointerManager
logger = logging.getLogger(__name__)
class EvaFor2wiki:
“””
init for kag client
“””
def __init__(self):
pass
“””
qa from knowledge base,
“””
def qa(self, query):
resp = SolverPipeline.from_config(KAG_CONFIG.all_config[“kag_solver_pipeline”])
answer, traceLog = resp.run(query)
logger.info(f”\n\nso the answer for ‘{query}’ is: {answer}\n\n”)
return answer, traceLog
if __name__ == “__main__”:
import_modules_from_path(“./prompt”)
evalObj = EvaFor2wiki()
evalObj.qa(“Which Stanford University professor works on Alzheimer’s?”)用户可以修改以下一个或多个文件,以定制特定于业务的知识图谱构造和基于推理的问答。注意:由于不同表示模型的使用方式不同,建议在创建项目后不要更新向量配置。如果需要更新向量配置,建议创建一个新的项目。
$ vim ./kag_config.yaml$vim./kg_config.yaml运行项目
$ knext project update — proj_path ./$next 项目更新 - proj_path./语料于 examples/2wiki/builder/data/2wiki_corpus.json, 其中包含 6119 个文档和 1000 个问答对。为了快速运行整个过程,目录中还有一个 2wiki_sub_corpus.json 文件,其中只包含 3 个文档。
KAG 代表了生成性人工智能的一个范式转换,解决了 RAG 在推理和检索方面留下的关键差距。通过将结构化知识与 LLM 能力相结合,OpenSPG-KAG 提供了准确的、可解释的和领域特定的解决方案。