PlantAI-rag/docs/KG_RAG_PROBLEM_ANALYSIS.md

KG-RAG方案A系统性问题分析报告

日期: 2026-04-23 分析人: xialab的幸运星

---

一、问题表象

用户问题："现在有多少个物种开展了SPL基因家族分析?"

系统回答（不准确）：

根据提供的文献内容，我来回答关于SPL基因家族分析的物种数量问题...
[后续内容偏离问题核心]

正确答案应为：

7篇论文 → 7个物种：
1. 小米 (Setaria italica)
2. 丹参 (Salvia miltiorrhiza)
3. 山核桃 (Pecan)
4. 柑橘 (Citrus)
5. 油菜 (Brassica napus)
6. 向日葵 (Sunflower)
7. 未知物种 (FPOWERS论文)

---

二、数据层面问题

问题A: 数据分层断裂

数据层	存储位置	内容	可访问性
stats	merged_7_papers.json	论文统计、实体类型统计	❌ 查询流程未访问
entities	merged_7_papers.json + Neo4j	1259个实体	⚠️ 覆盖率17.7%
relations	merged_7_papers.json + Neo4j	1887条关系	✅ KG可查询
vector_chunks	FAISS + merged构建	100条文本块	⚠️ 内容偏差

根本问题: 四层数据割裂，查询流程只访问KG+向量，遗漏stats层。

问题B: 实体覆盖率低

实体ID数: 672
关系引用实体数: 1883
实体覆盖率: 17.7% ← 严重问题

意味着82.3%的实体未参与任何关系，查询命中率极低。

问题C: 关系语义泛化

1887条关系中：
- RELATION类型: 1887条 (100%) ← 所有关系都是RELATION
- 具体类型(regulates/promotes等): 0条

无法区分：

• 正向调控 vs 负向调控
• 强关系 vs 弱关系
• 直接关系 vs 间接关系

问题D: 向量索引内容偏差

当前chunks来源：

# 从relations构建chunks
for r in relations:
    text = f"{r.source} {r.relation} {r.target}"
    chunks.append({'text': text})

问题：

• 内容是关系三元组，不是原文
• 缺少基因结构细节（外显子数、结构域特征）
• 缺少实验方法描述

---

三、查询流程问题

问题E: 实体识别能力不足

输入问题："有多少个物种开展了SPL基因家族分析?"

识别结果：

entities: ['SPL(gene_family)']  ← 漏掉关键词

漏识别的关键语义：

• "有多少" → 应触发统计查询
• "物种" → 应识别为species实体
• "开展了" → 应识别为研究活动

根本问题: 语义理解停留在关键词匹配，不理解问题意图。

问题F: 检索策略单一

固定流程：

实体识别 → KG查询 → 向量检索 → 融合生成

无法适应不同问题类型：

问题类型	应有策略	实际策略	结果
统计类	直接查stats	KG查询	❌ 无答案
功能类	KG关系优先	KG查询	✅ 正确
结构类	向量精确检索	向量检索	⚠️ 内容偏差
比较类	跨表聚合	KG查询	❌ 无法聚合

---

四、举一反三：类似问题场景

场景1: WRKY基因家族研究

预期问题：

Q: "有多少物种研究了WRKY?"
→ 统计类，同样无法回答（与SPL问题完全相同）

Q: "WRKY结构域的特点?"
→ 向量索引可能缺失WRKY结构细节

Q: "WRKY在胁迫响应中的作用?"
→ 功能类，可回答但关系语义不明确

场景2: NAC基因家族研究

预期问题：

Q: "NAC基因在不同组织中的表达?"
→ 实体链接不完整（覆盖率17.7%）

Q: "NAC与WRKY的协同调控?"
→ 跨家族关系未建模

场景3: 多基因家族比较

预期问题：

Q: "SPL vs WRKY基因数量差异?"
→ 跨表聚合，系统无此能力

Q: "转录因子家族的共同特征?"
→ 抽象层推理，KG不支持

场景4: 其他领域RAG系统

类似问题可能在任何RAG+KG系统出现：

领域	问题类型	类似缺陷
医疗文献	"有多少病例?"	统计层未接入
法律判例	"有多少判决支持X?"	统计查询缺失
产品文档	"有多少版本?"	元数据未建模
学术论文	"有多少引用?"	引用关系未存储

---

五、根本设计缺陷

缺陷1: 数据分层断裂

┌──────────────────────────────────────────────────────┐
│                 用户问题                               │
├──────────────────────────────────────────────────────┤
│                                                       │
│    ┌─────────┐    ┌─────────┐    ┌─────────┐        │
│    │  stats  │    │   KG    │    │  Vector │        │
│    │  ❌未接 │    │  ✅接入 │    │  ✅接入 │        │
│    └─────────┘    └─────────┘    └─────────┘        │
│                                                       │
│    问题：查询流程只能访问KG+Vector，stats层被忽略      │
└──────────────────────────────────────────────────────┘

缺陷2: 语义理解薄弱

问题: "有多少物种开展了SPL分析?"

意图理解层次：
├─ L1: 关键词提取 → ['SPL']  ← 当前能力
├─ L2: 意图分类 → [统计类]   ← 缺失
├─ L3: 查询规划 → [查stats.papers] ← 缺失
├─ L4: 答案模板 → [数字+列表] ← 缺失

问题：只停留在L1，无法理解L2-L4

缺陷3: 关系建模粗糙

理想模型：
  SPL2 ─[regulates (+)]─→ LFY
  SPL9 ─[inhibits (-)]─→ AP1
  MiR156 ─[targets]─→ SPL3

当前模型：
  SPL2 ─[RELATION]─→ LFY
  SPL9 ─[RELATION]─→ AP1
  MiR156 ─[RELATION]─→ SPL3

问题：所有关系类型相同，无法区分方向和强度

缺陷4: 检索策略单一

理想架构：
  问题 → 意图分类 → 策略路由
                      ├─ 统计类 → stats查询
                      ├─ 功能类 → KG优先
                      ├─ 结构类 → 向量优先
                      ├─ 比较类 → 跨表聚合
                      └─ 混合类 → KG+向量融合

当前架构：
  问题 → 实体识别 → KG查询 → 向量检索 → 融合
  
问题：固定流程，无法根据意图调整

---

六、改进方向（不提供具体方案，只指明方向）

方向A: 数据模型重构

需要考虑：

• stats如何与KG/向量打通？
• 实体-关系如何提高覆盖率？
• 关系类型如何细化？

方向B: 意图理解增强

需要考虑：

• 如何识别"有多少"、"多少个"等统计关键词？
• 如何识别"比较"、"差异"等比较关键词？
• 如何将意图映射到查询策略？

方向C: 检索策略路由

需要考虑：

• 不同问题类型的检索路径如何定义？
• 如何实现策略路由器？
• 混合问题如何拆解？

方向D: 关系语义细化

需要考虑：

• 如何在提取阶段保留关系语义？
• KG如何建模不同关系类型？
• 查询如何利用关系语义？

---

七、关键数据验证

实体覆盖率计算

entity_ids = set(e.get('id', e.get('name')) for e in merged['entities'])
# 结果: 672个实体ID

rel_entities = set()
for r in merged['relations']:
    rel_entities.add(r.get('source'))
    rel_entities.add(r.get('target'))
# 结果: 1883个关系引用实体

覆盖率 = len(entity_ids & rel_entities) / len(entity_ids)
# 结果: 17.7% ← 严重问题

关系类型分布

rel_types = {}
for r in merged['relations']:
    rel = r.get('relation', r.get('relationship_resolved'))
    rel_types[rel] = rel_types.get(rel, 0) + 1

# Top 10:
#   express: 177
#   with: 146
#   expressed_in: 110
#   regulate: 96
#   ...
# 但这些是resolved字段，实际KG中全是RELATION

问题类型匹配

问题示例	类型	数据源	可回答性
有多少物种研究SPL?	统计	stats.papers	❌
SPL的功能是什么?	功能	relations	✅
SPL外显子数?	结构	vector_chunks	⚠️
SPL vs WRKY差异?	比较	跨表聚合	❌

---

八、结论

当前KG-RAG方案A存在系统性设计缺陷，表现在：

1. 数据层割裂 - stats数据无法被查询
2. 语义理解薄弱 - 无法识别问题意图
3. 关系建模粗糙 - 无法区分关系语义
4. 检索策略单一 - 无法根据问题类型调整

这些问题不是单一功能的bug，而是系统架构的设计缺陷。类似问题会在所有基因家族、所有统计类问题中复现。

---

分析完成时间: 2026-04-23 21:35 数据来源: merged_7_papers.json, Neo4j查询, KG-RAG测试日志