Files
PlantAI-rag/docs/autoSKG_comparison.md
2026-07-10 17:59:59 +08:00

198 lines
7.1 KiB
Markdown
Executable File
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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**:
```json
{
"total_runtime": 85.103,
"num_documents": 1,
"input_load_time": 0,
"workflows": {...}
}
```
用途:**运行统计**(用于监控pipeline性能)
**方案A的merged_7_papers.json的stats**:
```json
{
"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镜像提取源代码
```bash
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*