知识图谱Knowledge GraphKG一种用图结构来表示知识的方式由节点表示实体如人、地点、概念和边表示实体之间的关系组成。基本单元通常是SPO三元组即主体Subject、谓词Predicate、客体Object例如张三职业工程师。优势明确的语义实体和关系都有明确的类型和含义结构化知识知识以结构化的方式存储便于机器理解和处理推理能力可基于图谱中的连接进行推理发现隐含的知识减少冗余通过实体规范化将不同表述但指代同一实体的内容统一起来可减少信息冗余查询可使用如SPARQL或SQL等查询语言来精确检索KG中的信息。概念自然语言理解(Natural Language UnderstandingNLU)指机器理解人类语言的能力。KAG论文中提及的NLU任务包括文本分类、命名实体识别识别文本中的人名、地名、组织名等、关系抽取识别实体间的关系、事件抽取等。自然语言推理(Natural Language InferenceNLI)指判断两个文本片段之间是否存在某种逻辑关系如蕴含、矛盾、中立。可用于推断短语间的语义关系如上下位关系isA、部分-整体关系isPartOf等这对于知识对齐非常重要。自然语言生成(Natural Language GenerationNLG)指机器生成自然、流畅、有意义的人类语言文本的能力。SPGSemantic-enhanced Programmable Graph的缩写语义增强可编程框架是蚂蚁知识图谱平台经过多年金融领域业务的支撑沉淀的一套基于属性图的语义表示框架。创造性地融合LPG结构性与RDF语义性既克服RDF/OWL语义复杂无法工业落地的问题又充分继承LPG结构简单与大数据体系兼容的优势。从三个方面来定义和表示知识语义明确定义知识的形式化表示和可编程框架使其可定义、可编程机器可理解和处理实现知识层级间的兼容递进支持工业级场景下非完备数据状态的图谱构建和持续迭代演化有效衔接大数据与AI技术体系支持对海量数据进行高效的知识化转换帮助提高数据价值和应用价值通过SPG框架可更加高效地构建和管理图谱数据同时可更好地支持业务需求和应用场景。框架具有良好的可扩展性和灵活性新的业务场景可以通过扩展领域知识模型及开发新算子快速构建其领域模型和解决方案。参考SPG白皮书。OpenSPG基于SPGSemantic-enhanced Programmable Graph语义增强可编程图框架、由蚂蚁集团与OpenKG合作开发、使用JVM语言包括Java、Scala、Groovy、开源GitHub2.2K Star268 Fork知识图谱开放引擎为领域图谱构建提供明确的语义表示、逻辑规则定义、算子框架( 构建、推理)等能力支持各厂商可插拔的适配基础引擎、算法服务构建自定义的解决方案中文文档语雀文档。OpenSPG核心能力模型包括SPG-Schema语义建模负责属性图语义增强的Schema框架设计如主体模型、演化模型、谓词模型等。SPG-Builder知识构建支持结构化和非结构化知识导入与大数据架构兼容衔接提供知识构建算子框架实现从数据到知识的转换抽象知识加工SDK框架提供实体链指、概念标化和实体归一等算子能力结合NLP和深度学习算法提高单个类型(Class)中不同实例(Instance)的唯一性水平支持领域图谱的持续迭代演化SPG-Reasoner逻辑规则推理抽象KGDSL(Knowledge Graph Domain Specific Language)为逻辑规则提供可编程的符号化表示以机器可理解的符号表示支持下游规则推理、神经/符号融合学习、KG2Prompt联动LLM知识抽取/知识推理等通过谓词语义和逻辑规则来定义知识之间的依赖和传递并且支持对复杂的业务场景的建模和分析可编程框架KNextKNext作为图谱可编程框架提供一套可扩展流程化对用户友好的组件化能力抽象图谱核心能力沉淀为组件化、框架化、引擎内置的能力实现引擎与业务逻辑、领域模型的隔离方便业务快速定义图谱解决方案构建以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/openspgkag登录成功界面有些过于简陋啊创建应用成功后创建知识库时选择【本地】类型需选择向量模型稍加摸索点击页面右上角的图标注意这里是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论文官网开源GitHub9K Star702 Fork。提出KAG (Knowledge Augmented Generation知识增强生成)框架结合KG的结构化知识和向量检索的快速查找能力旨在充分利用KG的优势特别是其结构化和推理能力来弥补RAG在专业领域的不足。RAG痛点相似不等于相关RAG通常靠计算问题和文档片段的文本相似度(向量相似性)来找参考资料。但有时候文本表面上相似逻辑上却不一定是最能回答问题的。尤其在专业领域可能需要更深层次的逻辑关联。对知识逻辑不敏感RAG检索到的可能是一堆文本片段LLM需要自己去理解其中的逻辑关系如数值比较、时间顺序、因果关系、专家规则等。这对于需要严谨逻辑的专业领域来说LLM可能会力不从心导致答案不够精确或缺乏专业性。基于OpenSPG引擎和大型语言模型的逻辑推理问答框架用于构建垂直领域知识库的逻辑推理问答解决方案。KAG可以有效克服传统RAG向量相似度计算的歧义性和OpenIE引入的GraphRAG的噪声问题。KAG支持逻辑推理、多跳事实问答等并且明显优于目前的SOTA方法。目标是在专业领域构建知识增强的LLM服务框架支持逻辑推理、事实问答等充分融合KG的逻辑性和事实性特点其核心功能包括知识与Chunk互索引结构以整合更丰富的上下文文本信息利用概念语义推理进行知识对齐缓解OpenIE引入的噪音问题支持Schema-Constraint知识构建支持领域专家知识的表示与构建逻辑符号引导的混合推理与检索实现逻辑推理和多跳推理问答KAG和OpenSPG关联核心功能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 GraphPG)的方式存储如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 FeedbackAKGF)类似于强化学习中的奖励机制让KG充当裁判评估LLM生成答案的知识正确性并据此优化模型。深入讲解KAG框架的各个模块如信息抽取、问题理解、逻辑形式生成、答案总结等都依赖于强大的LLM能力。KAG也关注如何针对性地提升LLM在三个基础NLP能力上的表现。意义通过专门优化LLM在NLU、NLI、NLG上的能力KAG框架的整体性能得到保障和提升。局限性LLM调用次数多在构建和推理过程中可能需要多次调用LLM带来计算和经济开销复杂问题分解规划能力要求高依赖LLM进行问题分解和规划对于特别复杂问题LLM规划能力仍有待提升知识对齐挑战尽管知识对齐有所改进但从开放信息抽取(Open Information ExtractionOpenIE)中获得的知识的准确性和一致性仍是挑战。