知识图谱，Knowledge Graph，KG，一种用图结构来表示知识的方式，由节点（表示实体，如人、地点、概念）和边（表示实体之间的关系）组成。

• 基本单元：通常是SPO三元组，即主体（Subject）、谓词（Predicate）、客体（Object），例如（张三，职业，工程师）。
• 优势：
  • 明确的语义：实体和关系都有明确的类型和含义
  • 结构化知识：知识以结构化的方式存储，便于机器理解和处理
  • 推理能力：可基于图谱中的连接进行推理，发现隐含的知识
  • 减少冗余：通过实体规范化（将不同表述但指代同一实体的内容统一起来）可减少信息冗余
• 查询：可使用如SPARQL或SQL等查询语言来精确检索KG中的信息。

概念

• 自然语言理解(Natural Language Understanding，NLU)：指机器理解人类语言的能力。KAG论文中提及的NLU任务包括文本分类、命名实体识别（识别文本中的人名、地名、组织名等）、关系抽取（识别实体间的关系）、事件抽取等。
• 自然语言推理(Natural Language Inference，NLI)：指判断两个文本片段之间是否存在某种逻辑关系（如蕴含、矛盾、中立）。可用于推断短语间的语义关系，如上下位关系（isA）、部分-整体关系（isPartOf）等，这对于知识对齐非常重要。
• 自然语言生成(Natural Language Generation，NLG)：指机器生成自然、流畅、有意义的人类语言文本的能力。

SPG

Semantic-enhanced Programmable Graph的缩写，语义增强可编程框架，是蚂蚁知识图谱平台经过多年金融领域业务的支撑，沉淀的一套基于属性图的语义表示框架。创造性地融合LPG结构性与RDF语义性，既克服RDF/OWL语义复杂无法工业落地的问题，又充分继承LPG结构简单与大数据体系兼容的优势。

从三个方面来定义和表示知识语义：

• 明确定义知识的形式化表示和可编程框架，使其可定义、可编程，机器可理解和处理
• 实现知识层级间的兼容递进，支持工业级场景下非完备数据状态的图谱构建和持续迭代演化
• 有效衔接大数据与AI技术体系，支持对海量数据进行高效的知识化转换，帮助提高数据价值和应用价值

通过SPG框架，可更加高效地构建和管理图谱数据，同时可更好地支持业务需求和应用场景。框架具有良好的可扩展性和灵活性，新的业务场景可以通过扩展领域知识模型及开发新算子，快速构建其领域模型和解决方案。

参考SPG白皮书。

OpenSPG

基于SPG（Semantic-enhanced Programmable Graph，语义增强可编程图）框架、由蚂蚁集团与OpenKG合作开发、使用JVM语言（包括Java、Scala、Groovy）、开源（GitHub，2.2K Star，268 Fork）知识图谱开放引擎，为领域图谱构建提供明确的语义表示、逻辑规则定义、算子框架( 构建、推理)等能力，支持各厂商可插拔的适配基础引擎、算法服务，构建自定义的解决方案，中文文档，语雀文档。

OpenSPG核心能力模型包括：

• SPG-Schema语义建模：负责属性图语义增强的Schema框架设计，如主体模型、演化模型、谓词模型等。
• SPG-Builder知识构建
  • 支持结构化和非结构化知识导入
  • 与大数据架构兼容衔接，提供知识构建算子框架，实现从数据到知识的转换
  • 抽象知识加工SDK框架，提供实体链指、概念标化和实体归一等算子能力，结合NLP和深度学习算法，提高单个类型(Class)中不同实例(Instance)的唯一性水平，支持领域图谱的持续迭代演化
• SPG-Reasoner逻辑规则推理
  • 抽象KGDSL(Knowledge Graph Domain Specific Language)，为逻辑规则提供可编程的符号化表示
  • 以机器可理解的符号表示支持下游规则推理、神经/符号融合学习、KG2Prompt联动LLM知识抽取/知识推理等
  • 通过谓词语义和逻辑规则来定义知识之间的依赖和传递，并且支持对复杂的业务场景的建模和分析
• 可编程框架KNext
  • KNext作为图谱可编程框架，提供一套可扩展，流程化，对用户友好的组件化能力；
  • 抽象图谱核心能力，沉淀为组件化、框架化、引擎内置的能力；
  • 实现引擎与业务逻辑、领域模型的隔离，方便业务快速定义图谱解决方案；
  • 构建以OpenSPG引擎为基础，知识驱动的可控AI技术栈，链接LLM、GraphLearning等深度学习能力。
• 云适配层Cloudext
  • 业务系统通过SDK对接开放引擎，构建自身特色的业务前端
  • 可扩展/适配自定义的图存储/图计算引擎
  • 可扩展/适配适合自身业务特点的机器学习框架

实战

基于Docker Compose本地部署：

curl-sSLhttps://raw.githubusercontent.com/OpenSPG/openspg/refs/heads/master/dev/release/docker-compose.yml-odocker-compose.ymldockercompose-fdocker-compose.yml up-d

没什么难的，启动4个容器，占用6个端口，其中本地已经MySQL服务，于是修改端口为3307。当然也可考虑让docker-compose.yml文件使用本地已经部署成功的MySQL服务：

部署成功后，浏览器输入http://127.0.0.1:8887，开始体验。

输入默认用户名密码：openspg/openspg@kag，登录成功，界面有些过于简陋啊

创建应用成功后

创建知识库时，选择【本地】类型，需选择向量模型

稍加摸索，点击页面右上角的图标（注意这里是2个图标，一个跳转到GitHub主页，右边的是配置入口）

模型支持

注意到上面给7个模型设置的标签有2种：LLM（推理）、Text Embedding（嵌入）。在创建知识库时必须配置嵌入模型。这里添加阿里云百炼text-embedding-v4‌

遇到的小问题，添加text-embedding-v4‌时报错，重试成功。

创建成功的知识库

进入详情页

点击新增【任务】，偏要犟，上传PDF文档

第二步

注意到：索引类型是多选的；点击任一选项，右侧将出现说明：

看起来有点像是提示词。右侧下方则是【知识模型】，不是很懂干啥用的

点击下一步之前，支持【预览抽取结果】，方便得知与分析（组合或单选的）索引方式是否合适：

第三步，选择抽取模型（LLM）

配置成功后，跳转到任务列表

点击【详情】

点击【执行日志】

很可惜，执行失败

看起来失败后会一直重试，没有找到【停止任务】入口。花了将近10元钱

报错日志：

Caused by: pemja.core.PythonException: <class 'TypeError'>: 'NoneType' object is not iterable at /home/admin/miniconda3/lib/python3.10/site-packages/kag/bridge/spg_server_bridge.run_component(spg_server_bridge.py:116) at /home/admin/miniconda3/lib/python3.10/site-packages/kag/bridge/spg_server_bridge.run_component(spg_server_bridge.py:108) at /home/admin/miniconda3/lib/python3.10/site-packages/kag/interface/builder/base.invoke(base.py:167) at /home/admin/miniconda3/lib/python3.10/site-packages/kag/builder/component/vectorizer/batch_vectorizer._invoke(batch_vectorizer.py:482) at /home/admin/miniconda3/lib/python3.10/site-packages/tenacity/__init__.wrapped_f(__init__.py:338) at /home/admin/miniconda3/lib/python3.10/site-packages/tenacity/__init__.__call__(__init__.py:477) at /home/admin/miniconda3/lib/python3.10/site-packages/tenacity/__init__.iter(__init__.py:378) at /home/admin/miniconda3/lib/python3.10/site-packages/tenacity/__init__.exc_check(__init__.py:420) at /home/admin/miniconda3/lib/python3.10/site-packages/tenacity/__init__.reraise(__init__.py:187) at /home/admin/miniconda3/lib/python3.10/concurrent/futures/_base.result(_base.py:451) at /home/admin/miniconda3/lib/python3.10/concurrent/futures/_base.__get_result(_base.py:403) at /home/admin/miniconda3/lib/python3.10/site-packages/tenacity/__init__.__call__(__init__.py:480) at /home/admin/miniconda3/lib/python3.10/site-packages/kag/builder/component/vectorizer/batch_vectorizer._generate_embedding_vectors(batch_vectorizer.py:425) at /home/admin/miniconda3/lib/python3.10/site-packages/kag/builder/component/vectorizer/batch_vectorizer.batch_generate(batch_vectorizer.py:292) at /home/admin/miniconda3/lib/python3.10/site-packages/kag/builder/component/vectorizer/batch_vectorizer.batch_generate_dense(batch_vectorizer.py:221) at /home/admin/miniconda3/lib/python3.10/site-packages/kag/builder/component/vectorizer/batch_vectorizer._generate_dense_vectors(batch_vectorizer.py:129) at pemja.core.PythonInterpreter.invokeMethod(Native Method) at pemja.core.PythonInterpreter.invokeMethod(PythonInterpreter.java:118) at com.antgroup.openspg.common.util.pemja.PemjaUtils.lambda$null$0(PemjaUtils.java:74) at com.antgroup.openspg.common.util.TraceCallableWrapper$1.doCall(TraceCallableWrapper.java:50) at com.antgroup.openspg.common.util.TraceCallableWrapper.call(TraceCallableWrapper.java:36)

真要命。

执行成功后，【召回测试】

KAG

论文，官网，开源（GitHub，9K Star，702 Fork）。

提出KAG (Knowledge Augmented Generation，知识增强生成)框架，结合KG的结构化知识和向量检索的快速查找能力，旨在充分利用KG的优势，特别是其结构化和推理能力，来弥补RAG在专业领域的不足。

RAG痛点：

1. 相似不等于相关：RAG通常靠计算问题和文档片段的文本相似度(向量相似性)来找参考资料。但有时候，文本表面上相似，逻辑上却不一定是最能回答问题的。尤其在专业领域，可能需要更深层次的逻辑关联。
2. 对知识逻辑不敏感：RAG检索到的可能是一堆文本片段，LLM需要自己去理解其中的逻辑关系，如数值比较、时间顺序、因果关系、专家规则等。这对于需要严谨逻辑的专业领域来说，LLM可能会力不从心，导致答案不够精确或缺乏专业性。

基于OpenSPG引擎和大型语言模型的逻辑推理问答框架，用于构建垂直领域知识库的逻辑推理问答解决方案。KAG可以有效克服传统RAG向量相似度计算的歧义性和OpenIE引入的GraphRAG的噪声问题。KAG支持逻辑推理、多跳事实问答等，并且明显优于目前的SOTA方法。

目标是在专业领域构建知识增强的LLM服务框架，支持逻辑推理、事实问答等；充分融合KG的逻辑性和事实性特点，其核心功能包括：

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

KAG和OpenSPG关联

核心功能

1. LLM友好的语义化知识管理

私域知识库场景，非结构化数据、结构化信息、业务专家经验 往往三者共存，提出一种对LLM友好的知识表示框架，在DIKW（数据、信息、知识和智慧）的层次结构基础上，将SPG升级为对LLM友好的版本，命名为LLMFriSPG。

这使得它能够在同一知识类型（如实体类型、事件类型）上兼容无schema约束的信息提取和有schema约束的专业知识构建，并支持图结构与原始文本块之间的互索引表示。

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

提出一种逻辑符号引导的混合求解和推理引擎，包括三种类型的运算符：规划、推理和检索，将自然语言问题转化为结合语言和符号的问题求解过程。

在这个过程中，每一步都可利用不同的运算符，如精确匹配检索、文本检索、数值计算或语义推理，从而实现四种不同问题求解过程的集成：图谱推理、逻辑计算、Chunk检索和LLM推理。

五个要素

• LLM友好的知识表示：
  • 分层思想(DIKW)：借鉴数据(Data)->信息(Information)->知识(Knowledge)->智慧(Wisdom)的金字塔模型(见论文图3)。将KG中的内容分为不同层次：
  • 动态与静态属性：允许实体类型同时拥有预先定义的静态属性(来自专家知识，如KGcs)和临时添加的动态属性(来自文本抽取，如KGfr)。这样既能保证专业决策的严谨性，又能兼顾信息检索的灵活性。
  • 与文本上下文的深度感知：实体和关系都带有更丰富的文本描述信息(如description、summary)，帮助LLM更好地理解其含义。
  • RC(Raw Chunks)：原始的文本块、摘要、描述。这是最基础的，完整性高，但专业性可能较低。
  • KGfr(Graph Information Layer)：通过信息抽取技术从文本中提取出的实体、关系等图结构数据。这层是信息层，可半结构化或无结构化。
  • KGcs(Knowledge Layer)：经过领域专家定义、符合严格模式约束、并经过整合评估的结构化知识。这层专业性、准确性和严谨性最高，但构建成本也高。
  • 深入讲解：KAG提出LLMFriSPG知识表示框架。KG通常用一种叫做属性图(Property Graph，PG)的方式存储，如SPG(Standard for Property Graphs)。但传统的属性图可能不太方便LLM直接理解和使用，LLMFriSPG对SPG进行升级，使其更亲近LLM。
  • 意义：这种表示方法让LLM更容易理解和利用KG中的结构化信息，并能将这些信息与原始文本联系起来。
• KG与原始文本块的相互索引：
  • 构建过程(KAG-Builder的一部分)深入讲解：目标是在KG的结构化信息(实体、关系)和它们来源的原始文本块(chunks)之间建立双向链接。KG中的一个实体某公司，它不仅有自己的属性和关系，还能直接链接到提到这个公司的所有原始文档段落
  • 意义：使得图谱中的每个节点或关系都有据可查，可追溯到原始文本上下文。反过来，也可通过文本块快速定位到相关的图谱结构。这为后续的混合推理提供基础
  • 语义分块(Semantic Chunking)：将原始文档按照语义和长度约束切分成有意义的文本块
  • 信息抽取(Information Extraction)：利用LLM从文本块中抽取实体、事件、关系等，构建初步的KGfr。同时为抽取的实体生成描述、摘要等。
  • 知识对齐：利用概念图谱等对抽取出的实体进行标准化、消歧（如苹果公司和Apple Inc.指向同一个实体），并补充实体间的语义关系。
  • 存储：将图结构存入图数据库，文本和向量存入向量数据库。
• 逻辑形式引导的混合推理引擎：
  • 灵感来源：KG问答(KGQA)技术，常将自然语言问题转换为逻辑查询语句。
  • 工作流程：
    图谱检索(GraphRetrieval)：直接在KG(KGcs或KGfr)中进行结构化查询。
    混合检索(HybridRetrieval)：结合图谱信息和文本向量检索(RC)，或当图谱中没有直接答案时，进行更广泛的文本搜索。
    数值计算、逻辑运算等。
  • 深入讲解：KAG的大脑，负责理解用户问题并找到答案。传统RAG中，LLM与检索器的交互通常基于自然语言，这可能导致歧义。KAG引入逻辑形式(Logical Form)——一种更精确、结构化的方式来表达问题和推理步骤。
    逻辑形式的函数(论文表1)：KAG定义一些逻辑函数，如Retrieval(检索SPO)、Sort(排序)、Math(数学运算)、Deduce(推断关系如蕴含、大于、等于)、Output(输出结果)。
    意义：使得问题分解和推理过程更严谨、可解释，并且能够灵活地结合KG的精确查询和传统RAG的文本检索。
    规划(Planning)：LLM(LFPlanner)将用户的自然语言问题分解成一个或多个子问题，并为每个子问题生成一个逻辑形式的表示。这个逻辑形式可能包含检索操作、数学计算、逻辑推断等。
    推理与检索：Reasoner模块根据逻辑形式执行操作。这可能是：
    生成(Generation)：Generator(通常是LLM)根据推理和检索的结果，生成最终答案。
    多轮反思：如果一轮下来问题没解决或信息不足，系统会反思已有的结果，可能会重新规划问题(生成补充问题)，进入下一轮迭代，直到找到满意答案或达到最大迭代次数。
• 基于语义推理的知识对齐：
  • 核心工具：概念图谱和语义关系。
  • 应用阶段：
  • 概念图谱包含领域内的核心概念及其层级关系。
  • 语义关系包括：同义词(synonym)、上下位(isA)、整体部分(isPartOf/contains)、实例归属(belongTo)、因果(causes)等。
  • 离线索引增强(Enhance Indexing - KAG-Builder)阶段：
  • 在线检索增强(Enhance Retrieval - KAG-Solver)阶段：当用户查询中的词语或类型在知识库中没有精确匹配时，可通过语义关系进行扩展。
  • 深入讲解：即使从文本中抽取实体和关系，它们也可能存在语义模糊、粒度不一致、缺乏关联等问题。知识对齐就是要把这些零散的知识点通过语义关系串联起来，形成一个更规范、更互联的知识网络。
  • 意义：提高知识的标准化程度和连通性，使得检索更精准，推理路径更符合逻辑：
    • 实例消歧与融合：识别并合并指向同一真实世界实体的不同表述。
    • 实例与概念链接：将抽取到的实体链接到概念图谱中的概念节点上。
    • 概念间关系补全：自动补全概念之间的层级关系等。
• KAG的模型能力增强：
  • NLU：通过在多种NLU数据集上进行指令微调，使用标签分桶(label bucketing)、灵活多样的输入输出格式、带任务指南的指令等策略，让LLM更准确地识别实体、关系、意图
  • NLI：收集高质量的概念知识库和本体，构建包含多种概念推理指令的训练集，增强LLM对语义关系(如isA、isPartOf)的判断能力
  • 自然语言生成(NLG)：
  • OneGen(One-pass Unified Generation and Retrieval)：论文还提到一种更高效的模式，试图将检索和生成统一到一个模型的前向传播过程中，减少多模型串联的复杂性和损耗。

K-LoRA：将从文本中提取知识的过程反过来，训练LLM从知识三元组生成符合领域风格的文本。

基于KG反馈的对齐(Alignment with KG Feedback，AKGF)：类似于强化学习中的奖励机制，让KG充当裁判，评估LLM生成答案的知识正确性，并据此优化模型。
深入讲解：KAG框架的各个模块（如信息抽取、问题理解、逻辑形式生成、答案总结等）都依赖于强大的LLM能力。KAG也关注如何针对性地提升LLM在三个基础NLP能力上的表现。
意义：通过专门优化LLM在NLU、NLI、NLG上的能力，KAG框架的整体性能得到保障和提升。

局限性：

1. LLM调用次数多：在构建和推理过程中可能需要多次调用LLM，带来计算和经济开销；
2. 复杂问题分解规划能力要求高：依赖LLM进行问题分解和规划，对于特别复杂问题，LLM规划能力仍有待提升；
3. 知识对齐挑战：尽管知识对齐有所改进，但从开放信息抽取(Open Information Extraction，OpenIE)中获得的知识的准确性和一致性仍是挑战。