知识图谱 + RAG：关系型问题终于能答了

陈陈老师2024/05/11947 阅读

传统 RAG 有个明显短板：多跳关系问题。"A 公司的 CEO 之前在哪家公司任职？"这种问题，向量检索很难答——因为答案分散在多个文档里，且靠语义相似度匹配不出来。知识图谱就是为这类问题准备的。

什么是知识图谱：把实体（人、公司、产品）和关系（任职于、属于、发布）抽取出来，存成图结构：节点是实体，边是关系。查询时按图遍历，而不是相似度检索。

实现思路：

实体和关系抽取。用 LLM 从文档里抽取三元组（主语、关系、宾语）。我用的 prompt 大概是：从文本中抽取所有 (实体, 关系, 实体) 三元组。实测准确率 80% 左右，人工抽检修正。
存储。轻量方案用 Neo4j，功能最全（Cypher 查询、可视化）；只想快速验证也可以用 NetworkX 纯内存，导出 JSON 存文件。
查询转换。用户问题进来，先判断是不是关系型问题，如果是，让 LLM 转成图查询（Cypher），执行查询得到答案。

一个例子：

Cypher

// "A 公司的 CEO 是谁？"
MATCH (c:Company {name: "A公司"})<-[:CEO_OF]-(p:Person)
RETURN p.name

坑：

抽取质量是瓶颈。实体抽取错了，图就是错的，查询结果自然错。我的经验：宁缺毋滥，抽取置信度低的先不建边，等人工确认。
查询生成的准确性。LLM 生成 Cypher 经常出错，特别是复杂查询。我在查询前会先展示"将执行的查询"让人确认，或者限制查询模板（只允许预定义好的几种查询模式）。
维护成本。知识图谱需要持续更新，文档变了，图要跟着变。我目前是文档更新时触发重新抽取，增量更新。
别什么都往图里塞。知识图谱适合"实体关系密集"的领域（组织架构、产品线、人物关系），如果是散文型文档，向量检索才是主战场。

混合方案：现在我的系统是"向量检索答事实类，图谱答关系类，路由层判断走哪条路"。实测两类问题的准确率都上来了。

还没有评论，来抢沙发～

评论0