RAG知识图谱简介

RAG知识图谱简介全文链接RAG知识图谱简介一、什么是知识图谱1.1 基本定义知识图谱Knowledge Graph是一种以图结构表示知识的方法通过实体Entity- 关系Relation- 属性Attribute三元组形式将现实世界的对象及其关联关系进行结构化建模。1.2 核心特征结构化表达以实体-关系-属性 (ERA) 结构化建模而非纯文本段落多跳关联天然支持沿关系路径进行多跳推理和查询语义约束通过类型、关系约束进行精准过滤减少语义偏移可追溯性节点/边挂接来源信息支持审计与回滚多跳关联示例用户问华为发布的操作系统在哪一年推出 → 图上可沿路径 (华为) -[发布]- (鸿蒙系统) -[发布时间]- (2020年)无需长文本检索即可直接拼接答案线索。文档引用示例业务文档中常见“详见附件××”的表述可在图中建模为 (文档) -[包含/引用]- (附件)当查询“附件××的要求是什么”时可沿此关系直接定位到附件节点及其内容而不必全文检索。语义约束示例查询位于上海的证券交易所时图查询可限定节点类型“组织机构”、位置属性包含上海减少文本相似度误匹配如把证券交易所误解为交易软件。二、知识图谱的基本组成扩展史上最大规模1.4亿中文知识图谱-github.com/ownthink/KnowledgeGraphData-知识图谱数据结构2.1 节点实体定义现实世界的对象人/机构/产品/事件等通常包含类型与属性。类型在本体/模式中声明实体类型如组织机构、人工制品、位置、概念、方法、自然物品、事件、内容、数据、人物角色、未知等可用于可视化着色与查询过滤属性描述实体的键值对如成立时间“注册地”“版本号”识别方式NER 实体链接EL利用别名词典、embedding 相似度、规则校验创建过程抽取后生成节点写入图数据库并绑定来源文档/段落 ID 以便回溯2.2 关系边定义实体间的语义联系如隶属“采购”“依赖”“作用于”可携带方向与属性时间、权重、置信度等。识别方式关系抽取RE、事件抽取或规则/模板匹配大模型可辅助生成候选再做置信度过滤创建过程对齐起点/终点实体后生成边附带来源、时间戳、置信度必要时人工校验2.3 属性定义描述实体或关系的键值对如成立时间“注册地”“版本号”“发生时间”。识别方式从结构化字段或信息抽取中提取做类型校验日期/数值/枚举创建过程在写入节点/边时填充保存来源与校验状态2.4 本体/模式定义领域内的类型体系与约束集合是图谱的一致性蓝图。设计步骤梳理业务实体/关系清单 → 定义字段与约束 → 约定命名、主键与别名策略 → 版本化管理作用指导抽取、存储、校验与查询也是多团队协作的契约2.5 来源与溯源节点/边需挂接来源文档、段落或页面 URL便于审计与回滚。2.6 质量与消歧通过别名表、唯一键、embedding 相似度 规则阈值 人工抽检持续治理。三、如何从文本构建知识图谱扩展医疗知识图谱构建-github.com/liuhuanyong/QASystemOnMedicalKG-业务驱动的知识图谱构建框架3.1 构建流程典型流水线原始文档/数据 → 预处理清洗、分段、去噪、分句 → 实体识别NER命名实体识别找出人名/机构/地点/产品等 → 实体链接/消歧EL实体链接alias 词表 embedding 相似度 规则阈值 人工抽检将文本片段对齐到具体实体节点 → 关系抽取/事件抽取RE/EE关系/事件抽取识别谁-与-谁-以何种关系/事件相连可用模型/LLM/模板 → 本体校验类型约束、必填属性、基数检查 → 置信度过滤与人工审阅可选边界样本人工确认 → 入图写入节点/边附来源文档/段落/时间戳/置信度 → 索引构建图索引 向量索引 关键词倒排 → 监控与回滚质量指标、版本/备份、审计溯源3.2 是否使用大模型大模型并非必需但在中文/开放域抽取、长尾别名、复杂关系识别上LLM 能显著提升召回与质量同时会带来成本与一致性挑战轻量方案传统 NER/RE 规则 词表/alias embedding 消歧适合结构化/半结构化、高一致性场景混合方案LLM 生成候选 规则/embedding 复核 人工抽检适合开放域、弱结构、多别名场景四、核心技术原理详解扩展知识图谱-概念与技术 复旦大学 肖仰华-github.com/tywee/knowledge-graph-关系抽取概述4.1 NERNamed Entity Recognition命名实体识别定义从文本中标注实体片段及类型。常用技术序列标注BiLSTM-CRF、BERT-CRF、LLM 提示抽取、规则/词典示例“上海证券交易所位于浦东” → 抽出 “上海证券交易所/组织机构”“浦东/位置”4.2 ELEntity Linking实体链接/消歧定义将已识别的实体片段对齐到知识库中的具体实体节点。常用技术候选生成别名/倒排/向量召回→ 候选打分embedding 相似度 规则/特征→ 选最优必要时人工抽检示例“苹果” → 根据上下文判断是 “Apple Inc.”公司而不是 “苹果/水果”4.3 RERelation Extraction关系抽取定义识别实体之间的语义关系产出三元组 (头实体, 关系, 尾实体)。常用技术依存/句法特征 深度模型LLM 结构化输出模板/规则在高精场景使用示例“华为发布了鸿蒙系统” → (华为, 发布, 鸿蒙系统)4.4 EEEvent Extraction事件抽取定义识别事件及其论元/角色主体、客体、时间、地点等。常用技术触发词识别 论元填充可用模型、LLM 或规则模板示例“2020年华为发布鸿蒙系统” → 事件发布论元时间2020年主体华为对象鸿蒙系统4.5 辅助组件分词工具如结巴分词 jieba将中文文本切分成词语序列是NER/RE等任务的前置预处理步骤。结巴分词本身不做实体/关系抽取但为后续任务提供词语边界和词性标注POS等基础信息。例如“上海证券交易所位于浦东” → 分词为 [“上海”, “证券”, “交易所”, “位于”, “浦东”]NER模型在此基础上识别出完整实体上海证券交易所/组织机构别名/词表支撑候选生成与消歧Embedding 相似度长尾匹配、别名发现、候选排序规则/模板硬约束类型/格式/时间数值校验与高精句式置信度与审阅低置信度样本进入人工审核闭环五、知识图谱 vs 普通知识库扩展GraphRAG DeepSearch 实现与问答系统Agent构建-github.com/1517005260/graph-rag-agent-更复杂的产品化效果-包含轨迹追踪图谱推理过程5.1 普通知识库的特点以文档/段落为基本单位偏段落检索 大模型生成关系弱结构化程度低召回常依赖向量相似度5.2 知识图谱的特点以实体-关系-属性 (ERA) 结构化建模天然支持多跳关联和语义约束可与文本片段双索引图索引 向量索引协同工作5.3 对比分析优势结构化表达关系明确可表达复杂语义和路径检索可解释性节点/边及路径可视化便于溯源精准检索实体、关系过滤结合向量召回提升精度复杂查询天然支持图查询语言Cypher/Gremlin和多跳问答劣势构建成本高实体抽取、关系抽取、对齐、清洗、版本管理需要额外流程维护复杂别名/消歧、数据漂移、模式演进需要持续运维覆盖度权衡低噪高质 vs 覆盖面需要取舍过度结构化可能丢失细节5.4 普通知识库实现多跳查询的方案普通知识库虽然缺乏知识图谱的结构化优势但可以通过以下方案实现类似的多跳查询能力1. 数据治理方案文档结构增强在详见、“参照”、参考等文档跳转关键词后面增加章节链接锚点建立文档间的显式引用关系。例如“详见附件A” → 自动添加锚点链接到附件A章节。章节语义增强在跳转的附件章节中修改章节名称增强语义描述。例如将附件A改为附件A数据安全管理办法提升向量检索的匹配精度。局限性需要大量人工标注和文档处理工作耗费工时对于已有大量文档的场景改造成本较高。2. 工作流节点额外抽取多轮迭代检索在获取第一阶段检索结果后增加额外处理节点提取检索结果中的详见、“参考”、依据等关键字及其关联内容。关联内容检索根据提取的关键字再次在知识库中查找被引用的文档或章节并将结果拼接到工作流回复中。递归深度控制设置最大递归深度如2-3跳避免无限循环和性能问题。局限性需要适配开发工作流节点增加系统复杂度在海量文本中关键字提取可能不精准导致误召回或漏召回。3. 提示工程增强在 LLM 的 prompt 中明确要求进行多跳推理引导模型识别文档间的引用关系并主动查找相关内容。局限性不可控受限于大模型本身的理解能力。六、适用场景与决策指南6.1 典型适用场景实体/关系密集领域金融、医疗、法律、供应链、政企知识库需要多跳逻辑的问答合规审查、风控溯源、因果/依赖分析需要可解释与可追溯审计、合规、决策支持需要消歧/别名管理人名地名产品名混淆场景6.2 不适合或性价比低的场景需求以简单 FAQ/关键词检索为主数据规模小且关系简单更新极端频繁且对一致性要求低的临时知识团队缺少长期图谱运维能力6.3 何时不必使用图数据规模小、关系简单、主要是纯文本 FAQ构建/运维资源有限或对可解释性需求不高更新频率极高且容错成本低的临时知识七、LightRAG 查询模式详解LightRAG 提供了多种查询模式用户可以通过在查询前添加前缀来选择不同的检索和生成策略。默认模式为hybrid混合模式。7.1 核心查询模式/local本地模式作用基于查询中的实体在知识图谱中构建局部子图Local Graph仅检索与查询实体直接相关的节点和关系。特点聚焦于查询相关的局部区域检索范围较小适合精确查询响应速度快可能遗漏间接相关的信息适用场景查询目标明确需要快速获取直接相关的实体和关系信息/global全局模式作用基于查询语义在全局知识图谱中进行检索考虑所有可能的实体和关系路径。特点检索范围广可能发现间接关联适合复杂推理和多跳查询计算成本较高可能引入噪声适用场景需要多跳推理、发现间接关联、探索性查询/hybrid混合模式默认作用结合本地模式和全局模式的优势先进行局部检索再基于结果进行全局扩展。特点平衡精度和召回率兼顾直接关联和间接关联是大多数场景的推荐模式适用场景通用查询场景需要平衡准确性和完整性/naive朴素模式作用不使用知识图谱结构仅基于向量相似度进行文本检索类似传统 RAG。特点不利用图结构信息依赖纯语义相似度匹配计算简单但可能缺乏结构化推理能力适用场景知识图谱未构建或质量较低时作为降级方案/mix混合策略模式作用采用混合检索策略可能结合多种检索方法图检索 向量检索 关键词检索。特点综合利用多种检索手段提升召回率和鲁棒性计算复杂度较高适用场景对召回率要求高需要多种检索手段互补的场景7.2 特殊模式/bypass绕过模式作用完全绕过 LightRAG 的检索流程直接将查询和聊天历史传递给底层 LLM不进行任何知识库检索。特点不进行知识库检索仅依赖 LLM 的预训练知识可用于测试 LLM 能力或处理非知识库相关的问题适用场景测试 LLM 能力、处理通用对话、不需要知识库检索的场景注意如果使用 Open WebUI 作为前端可以直接切换到普通 LLM 模型无需使用此前缀/context上下文模式作用不生成最终答案仅返回为 LLM 准备的上下文信息检索到的相关文档片段或图路径。特点仅返回检索结果不调用 LLM 生成可用于检查检索质量支持自定义上下文处理适用场景调试检索效果、自定义上下文处理逻辑、分析检索结果7.3 上下文版本模式以下模式是核心查询模式的上下文版本仅返回上下文信息不生成最终答案/localcontext本地模式的上下文版本返回局部子图检索结果/globalcontext全局模式的上下文版本返回全局检索结果/hybridcontext混合模式的上下文版本返回混合检索结果/naivecontext朴素模式的上下文版本返回向量检索结果/mixcontext混合策略模式的上下文版本返回混合检索结果7.4 使用示例# 默认混合模式查询 Whats LightRAG? # 使用本地模式 /local 华为发布了哪些产品 # 使用全局模式 /global 哪些公司与华为有合作关系 # 使用混合策略模式 /mix 数据安全管理办法的具体要求是什么 # 绕过检索直接使用LLM /bypass 解释一下量子计算的基本原理 # 仅获取上下文 /context 华为的合作伙伴有哪些7.5 模式选择建议查询类型推荐模式说明精确实体查询/local快速获取直接关联信息多跳推理查询/global发现间接关联和路径通用查询/hybrid默认平衡精度和召回率简单语义匹配/naive降级方案或简单场景高召回率需求/mix多种检索手段互补调试检索效果/context系列检查检索质量非知识库问题/bypass直接使用LLM参考东南大学《知识图谱》研究生课程-github/npubird/KnowledgeGraphCourse从零开始构建知识图谱-github.com/myhhub/KnowledgeGraphLightRAG