PlantAI-rag/docs/autoSKG_comparison.md

autoSKG vs 方案A对比分析

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

---

一、架构对比

autoSKG架构

┌─────────────────────────────────────────────────────────────┐
│  input_pdfs/ → GROBD → text → LLM(OpenAI) → KG            │
│                                                             │
│  数据流:                                                     │
│  PDF → text.txt → metadata.parquet → KG(parquet)           │
│                                                             │
│  存储格式:                                                   │
│  - parquet（列式存储）                                       │
│  - stats.json（运行统计）                                    │
│                                                             │
│  源代码位置:                                                 │
│  - Docker镜像 szhou956/autoskg:v0.4.0                        │
│  - GitHub仓库无源代码                                        │
│                                                             │
│  服务化:                                                     │
│  - PlantScience.ai虚拟科学家                                 │
│  - KG + LLM + 可视化                                         │
└─────────────────────────────────────────────────────────────┘

方案A架构

┌─────────────────────────────────────────────────────────────┐
│  PDF → MinerU → entities/relations → Neo4j + FAISS         │
│                                                             │
│  数据流:                                                     │
│  PDF → MinerU.json → merged_7_papers.json → KG+向量        │
│                                                             │
│  存储格式:                                                   │
│  - JSON（merged_7_papers.json）                             │
│  - Neo4j图数据库                                             │
│  - FAISS向量索引                                             │
│                                                             │
│  源代码位置:                                                 │
│  - 本地Python文件（kg_rag_fusion.py）                        │
│  - 完全开源可修改                                            │
│                                                             │
│  服务化:                                                     │
│  - FastAPI本地服务                                           │
│  - KG + Vector + LLM(Ollama/DashScope)                      │
└─────────────────────────────────────────────────────────────┘

---

二、数据模型对比

维度	autoSKG	方案A
PDF解析	GROBD（科学文献专用）	MinerU（通用）
存储格式	parquet（列式）	JSON + Neo4j + FAISS
实体提取	LLM(OpenAI GPT)	正则+PC数据
关系提取	LLM	规则模式
stats字段	运行统计（runtime）	KG统计（entities/relations）
源代码	Docker镜像（不公开）	本地Python（完全开源）

---

三、关键差异分析

差异1: 源代码可见性

autoSKG	方案A
Docker镜像封装，无法直接读取源代码	本地Python文件，完全可读可修改
只能通过输出数据推断设计	可以直接分析源代码

影响: autoSKG的设计细节需要通过docker镜像或输出数据推断，无法直接学习其实现。

差异2: PDF解析工具

autoSKG (GROBD)	方案A (MinerU)
科学文献专用解析	通用PDF解析
结构化输出（标题/章节）	全文提取
专为学术文献优化	需要额外处理结构

差异3: 数据组织方式

autoSKG	方案A
parquet（高效列存储）	JSON（易读但效率低）
单表结构	多表（entities/relations分离）
text_unit_ids引用	直接嵌入文本

差异4: stats字段用途

autoSKG的stats.json:

{
    "total_runtime": 85.103,
    "num_documents": 1,
    "input_load_time": 0,
    "workflows": {...}
}

用途：运行统计（用于监控pipeline性能）

方案A的merged_7_papers.json的stats:

{
    "total_entities": 1259,
    "total_relations": 1887,
    "entity_types": {...},
    "papers": [...]
}

用途：KG统计（用于回答统计类问题）

---

四、autoSKG解决方案A问题的可能性分析

问题：统计类问题无法回答

autoSKG是否解决？

• autoSKG的stats.json只有运行统计，没有KG统计
• 如果用autoSKG架构，需要额外添加KG统计字段
• 结论: autoSKG默认也不解决统计类问题，需要定制

问题：实体识别漏词

autoSKG是否解决？

• autoSKG使用LLM提取实体
• LLM能识别"有多少"、"物种"等语义关键词
• 结论: autoSKG通过LLM可能更好地识别问题意图

问题：关系语义泛化

autoSKG是否解决？

• autoSKG使用LLM提取关系
• LLM能区分regulates/promotes/inhibits
• 结论: autoSKG可能保留更细致的关系语义

---

五、为什么每次都没读取autoskg代码

客观原因:

1. autoSKG的源代码在Docker镜像里，不在本地
2. GitHub仓库只有配置文件（docker-compose.yml）
3. 需要通过docker inspect或镜像分析才能获取源代码

我的失误:

1. 没有主动尝试从docker镜像提取源代码
2. 没有主动通过web_fetch获取PlantScience.ai的在线演示
3. 只分析了输出数据，没有深入分析docker镜像

---

六、下一步行动

行动1: 从docker镜像提取源代码

docker pull szhou956/autoskg:v0.4.0
docker create szhou956/autoskg:v0.4.0
docker cp <container_id>:/app /tmp/autoskg_source

行动2: 分析PlantScience.ai在线服务

访问 https://PlantScience.ai 查看其KG查询界面和问答能力。

行动3: 对比两者的查询能力

用同样问题测试autoSKG和方案A，对比答案质量。

---

七、关键教训

对用户问题的处理:

• 用户提到autoskg-wizard时，应主动读取相关代码
• 不应假设源代码不可见，应尝试所有获取途径
• 应对比分析已有数据和设计文档

对系统设计的反思:

• autoSKG用LLM提取实体/关系，可能解决语义理解问题
• autoSKG用parquet存储，效率更高
• 但autoSKG的stats也是运行统计，不解决KG统计问题

---

分析完成时间: 2026-04-23 21:45