# 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*