198 lines
7.1 KiB
Markdown
198 lines
7.1 KiB
Markdown
|
# 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*
|