W
AI-Wiki
CONCEPT

RAG与知识图谱融合问答

定义

RAG与知识图谱融合问答，是指在同一个问答系统里，同时接入两类不同形态的知识来源：

  • 一类是面向非结构化内容的 RAG 检索链路，用来处理文档、网页、说明材料等长文本。
  • 另一类是面向结构化关系的知识图谱链路，用来处理“实体—关系—实体”的三元组知识。

在本文语境中，它对应 Yuxi-Know 的核心产品思路，不是泛泛而谈的“融合”，而是一个可实际操作的联合工作流：

  • 先建设知识库，上传文档并建立向量索引；
  • 再建设知识图谱，把三元组导入图数据库；
  • 最后在对话界面中按需启用相应工具，让模型结合文档检索结果、图谱查询结果和大模型生成能力给出回答。

在本文档中的具体语境

本文描述的落地方式非常具体，核心不是单纯的“模型更聪明了”，而是“知识库 + 知识图谱 + 对话工具调用”协同工作。系统登录后，首页就包含智能体对话、知识库管理、知识图谱管理等模块，说明这三部分是并列且联动的能力，而不是某个隐藏在底层的理论概念。

在对话页面中，用户可以：

  • 设置系统提示词；
  • 选择驱动模型；
  • 启用工具；
  • 让回答结合知识库内容、联网搜索结果和大模型能力生成。

其中，知识图谱查询也被明确设计为一个可启用的对话工具。这意味着融合问答的实际运行方式，并不是把所有知识先混成一种统一表示，而是由对话阶段的工具调用来接入不同知识源。

两类知识来源的差异

知识库侧：处理非结构化文档与网页内容

知识库侧面向的是文档和网页内容，支持的输入类型包括：

  • PDF
  • TXT
  • Markdown
  • Docx
  • 通过 URL 抓取的网页内容

这些内容的共同特点是：原始信息通常是自然语言段落、章节、说明文字或教材式内容，适合通过分块和语义检索来召回相关证据。

图谱侧：处理结构化三元组

知识图谱侧面向的是整理好的结构化关系数据，输入格式要求为 jsonl，每行一条三元组。文中给出的示例包括：

{"h": "北京", "t": "中国", "r": "首都"}
{"h": "Python", "t": "编程语言", "r": "属于"}
{"h": "机器学习", "t": "人工智能", "r": "子集"}

这里的 h、t、r 分别对应头实体、尾实体和关系。与知识库不同，这类数据不是大段说明文本，而是已经被明确表达成“谁和谁是什么关系”的结构化知识。

知识库链路：从上传文档到检索证据

本文中的 RAG 链路有明确步骤。

  1. 用户在知识库模块中新建知识库并上传文档。
  2. 系统支持导入 PDF、TXT、Markdown、Docx 文件，也支持通过 URL 抓取网页内容。
  3. 上传完成后，系统会自动进行分块。
  4. 分块后的内容会被索引，并存储到 Milvus 向量数据库中。
  5. 在问答时，系统从这些文档片段中检索与问题最相关的证据，再交给大模型生成回答。

文中还强调了几个实现细节：

  • 分块、索引和入库是自动完成的，不需要用户手动切段。
  • 处理耗时与文件大小相关，大文件可能需要几分钟。
  • 如果底层 Milvus 服务启动失败，系统层面甚至提供了单独重启 Milvus 和重启 API 的操作，说明知识库检索链路确实依赖向量数据库稳定运行。

文档问答示例

文中给出了一个非常直观的例子：上传一份 PDF 格式的《Python 编程入门》文档后，可以在对话中提问“Python 中列表和字典的区别是什么”。系统会从已上传文档中检索相关片段，再结合大模型生成较精准的回答。

这个例子说明，RAG 部分主要解决的是：

  • 说明性知识从哪里来；
  • 长文本内容怎样被定位；
  • 回答是否能引用上传资料中的相关段落。

知识图谱链路：从三元组导入到关系查询

本文中的知识图谱链路也很明确。

  1. 用户准备 jsonl 格式的三元组数据。
  2. 在知识图谱模块中执行导入。
  3. 系统把这些数据导入 Neo4j 图数据库。
  4. 导入完成后，可以在可视化界面查看实体之间的关联关系。
  5. 在对话中启用“查询知识图谱”工具后，模型可以基于图谱回答关系类问题。

这条链路的重点不是语义相似度检索，而是结构化关系表达与图查询。也就是说，系统不是去一堆文本里“猜”北京和中国可能有什么关系，而是直接查询图中是否存在对应的关系边。

图谱问答示例

文中给出的代表性例子是：当图谱中存在 {"h": "北京", "t": "中国", "r": "首都"} 这样的三元组时，在对话中启用知识图谱查询工具，提问“北京和中国是什么关系”，助手会通过图谱查询返回“首都”。

这个例子表明，知识图谱特别适合处理：

  • 实体之间的关系是什么；
  • 某个概念属于哪个上位概念；
  • 两个对象之间是否存在明确连接。

两种能力的互补关系

RAG 擅长的部分

RAG 更擅长处理以下问题：

  • 来自 PDF、教程、制度、课件、网页等长文本中的说明性内容；
  • 需要从多个段落中召回证据的问答；
  • 依赖文档原文描述而不是固定三元组的知识。

例如“Python 中列表和字典的区别是什么”这类问题，本质上更像是在教材或技术文档中找解释、找比较、找定义，因此更适合走知识库检索链路。

知识图谱擅长的部分

知识图谱更擅长处理以下问题：

  • 实体与实体之间的关系查询；
  • 分类、从属、子集、地理隶属等结构清晰的问题；
  • 需要图数据库直接返回关系边的查询。

例如“北京和中国是什么关系”这种问题，核心不是长段解释，而是一个明确的关系槽位，因此更适合走图谱查询链路。

为什么要融合

如果只有知识库，没有图谱，那么系统面对实体关系类问题时，往往只能依赖文本召回与生成推断，关系表达不够直接。 如果只有图谱，没有知识库，那么系统虽然能回答结构清晰的关系问题，却难以覆盖 PDF 手册、技术说明、教学材料中的大量非结构化内容。

因此本文中的融合不是重复建设，而是互补分工：

  • 知识库负责“长文本知识召回”；
  • 知识图谱负责“实体关系表达与关系查询”；
  • 对话工具调用负责把两者接到同一次问答流程里。

关键机制或组成

1. 知识库管理能力

系统提供知识库创建、文档上传、URL 抓取、编辑、删除和权限设置等能力。这里不仅是存文件，更是把文档处理为可检索的知识片段，并在问答时参与证据召回。

2. 向量检索基础设施

文中明确指出，上传后的文档会自动分块、索引并存入 Milvus。由此可以看出，RAG 部分的基础设施核心是向量数据库而不是传统关键词索引。

3. 图数据库能力

图谱部分基于 Neo4j，支持：

  • 三元组导入；
  • 图谱可视化；
  • 图查询；
  • 在对话中通过工具调用返回关系结果。