ScholarMind 技术选型决策记录 (ADR)
ADR-001: PDF解析引擎选择 MinerU 2.5 VLM
背景
需要解析1000+篇学术PDF论文，包含大量公式、表格、复杂多栏布局。
决策
主引擎: MinerU 2.5 VLM；快速通道: PyMuPDF (纯数字PDF)
依据
| 指标 | MinerU 2.5 | Marker | Nougat | 要求 |
|---|---|---|---|---|
| 文本精度 (Edit Distance↓) | 0.047 | 0.080 | 0.365 | <0.1 |
| 公式识别 (CDM↑) | 88.46 | 17.6 | 15.1 | >70 |
| 表格识别 (TEDS↑) | 88.22 | 67.6 | 39.9 | >75 |
| 吞吐 (A100 pg/s) | 2.12 | ~5 | ~0.5 | >1 |
MinerU 2.5 在所有关键指标上全面领先，是学术论文解析唯一达到生产级精度的开源方案。
来源
- OmniDocBench (CVPR 2025, arxiv:2412.07626)
- MinerU 2.5 论文 (arxiv:2509.22186)
ADR-002: 知识抽取采用两阶段策略 (GLiNER + LLM)
背景
需要从论文中抽取学术实体(方法、数据集、指标等)和关系，支持本地和API模型。
决策
Stage 1: GLiNER (零样本NER, 440M参数, 本地) Stage 2: LLMGraphTransformer (关系抽取, 本地/API LLM) Stage 3: Graphusion (实体融合+冲突消解)
依据
- GLiNER vs ChatGPT NER: GLiNER F1=47.8 vs ChatGPT F1=36.5 (20个NER基准平均)
- GLiNER: 零样本、自定义标签、440M参数本地运行，不依赖API
- LLMGraphTransformer: LangChain原生集成，支持strict_mode约束抽取schema
- Graphusion: 比naive抽取在下游QA准确率提升9.2% (arxiv:2410.17600)
替代方案
- REBEL (seq2seq, 400M): 在Wikipedia上训练，不适合学术文本
- ReLiK: 学术界SOTA但生态集成不如LangChain方案
- 纯LLM抽取: 成本高(1000篇×API费用), 且小模型(<13B)噪声大
来源
- GLiNER (arxiv:2311.08526)
- Graphusion (arxiv:2410.17600)
- SciER数据集 (arxiv:2410.21155)
ADR-003: 图数据库选择 Neo4j 5.x Community
背景
存储学术知识图谱，支持实体/关系查询、子图检索、向量搜索。
决策
Neo4j 5.x Community Edition
依据
- LangChain/LlamaIndex原生集成: 开箱即用的GraphRAG支持
- Cypher查询语言: 最成熟的图查询生态
- 向量索引: Neo4j 5.x 原生支持向量索引，无需额外组件
- 全文索引: 内置Lucene全文搜索
- APOC/GDS插件: 社区检测、PageRank等图算法
- 生态工具: Neo4j Browser (可视化), neo4j-labs/llm-graph-builder (参考实现)
替代方案
- ArangoDB: 多模型优势，但LangChain集成不如Neo4j
- NebulaGraph: 更适合10亿+节点规模，当前场景(~100K节点)不需要
- Kuzu: 嵌入式轻量，但生产特性(HA、备份)不足
规模评估
1000篇论文预计: ~50K实体节点, ~200K关系边 → Neo4j Community轻松承载
ADR-004: 向量数据库选择 Qdrant
背景
存储文本嵌入向量，支持Dense+Sparse混合检索。
决策
Qdrant (Rust核心, 原生Hybrid搜索)
依据
- 性能: 3000+ RPS, p99<10ms (HNSW+标量量化)
- 原生Hybrid: 同一Collection支持Dense+Sparse向量，无需外部BM25
- 简单部署: 单Docker容器，无Zookeeper/etcd依赖
- Disk-based HNSW: 内存友好，适合1M+向量
- Payload过滤: 支持元数据过滤(paper_id, section, year等)
替代方案
- Milvus: 更适合>10M向量的分布式场景，运维复杂度更高
- Weaviate: API设计好但资源占用较高
- ChromaDB: 无分片/HA，不适合生产
- FAISS: 仅库不是服务，需要自建API层
规模评估
1000篇论文 × ~40 chunks/paper × 1536维 = ~40K向量 → Qdrant单节点轻松承载
ADR-005: 检索策略采用三路混合 + RRF + Cross-Encoder
背景
学术问答涉及事实查询、多跳推理、全局分析等多种类型。
决策
- 三路检索: Dense向量 + Sparse BM25 + 知识图谱
- 融合: Reciprocal Rank Fusion (RRF)
- 重排: BAAI/bge-reranker-large (Cross-Encoder)
- 查询增强: HyDE (假设文档嵌入)
依据
- RAG+GraphRAG融合 > 单一方案: +6.4%准确率 (arxiv:2502.11371)
- bge-reranker-large: 实验验证的共识最优重排器 (arxiv:2502.11371)
- HyDE: 零成本+10 NDCG提升 (arxiv:2212.10496)
- 256 token分块: 实验验证最佳分块大小 (arxiv:2502.11371)
- RAPTOR层次树: 专为层级文档设计, +20%准确率 (arxiv:2401.18059)
ADR-006: Agent编排选择 LangGraph
背景
需要多Agent协作处理复杂学术问答，支持条件分支和循环。
决策
LangGraph (有状态图Agent编排)
依据
- 有状态图: 天然支持条件路由、循环(自检→补充检索)
- 持久化: 可持久化Agent状态，支持长对话
- 流式输出: 原生支持SSE/WebSocket流式
- LangChain生态: 与LangChain检索器、工具无缝集成
- 生产级: LangGraph Server提供REST API部署
替代方案
- smolagents: 更简单但缺乏复杂状态管理
- AutoGen: 偏向多Agent对话，不如图结构灵活
- CrewAI: 角色定义好但底层编排不如LangGraph灵活
ADR-007: LLM接入层选择 LiteLLM
背景
需要同时支持本地(vLLM/Ollama)和外部API(OpenAI/Anthropic/DeepSeek)，不同任务使用不同模型。
决策
LiteLLM Proxy Server (统一OpenAI兼容接口)
依据
- 统一接口: 100+ LLM提供商统一为OpenAI格式
- 路由策略: latency-based, cost-based, model-specific
- Fallback: 本地模型失败自动切换API
- 成本追踪: 内置token计数和费用统计
- 缓存: Redis缓存重复请求
- 速率限制: 防止API配额耗尽
任务-模型映射
| 任务 | 模型选择 | 原因 |
|---|---|---|
| 知识抽取(NER/RE) | 本地 Qwen2.5-14B | 批量处理，成本敏感 |
| 答案生成 | GPT-4o-mini | 生成质量要求高 |
| 意图分类 | 本地 Llama-3.1-8B | 简单任务，延迟敏感 |
| 实体融合 | GPT-4o-mini | 需要强推理能力 |
| HyDE查询改写 | 本地 Llama-3.1-8B | 简单改写，延迟敏感 |