百宝箱

我仔细看了所有参考文档（参考1-9）。直说结论：

v3.0 已经比这些参考文档成熟得多，参考文档的大部分内容是噪音。

几个核心判断：

1. 参考文档的来源质量问题

这些明显是另一个 LLM 的输出，有几个典型特征：每篇结尾都追加销售话术（”世界第一个”、”比你现在强10倍”）、不断堆叠模块名称但没有任何实现细节、同一内容在参考3-9之间反复重述。这不是技术方案，是概念兜售。

2. 少数有价值的技术洞察，v3.0 已经吸收了

参考5提出的 Graph Dilution Problem（图谱结果被 Reranker 压制）是真实问题，参考6的 “Graph-Safe” 思路也对。但 v3.0 的”推理骨架”定位已经比这两篇的方案更干净——不是给 Graph 预留固定席位（参考6的 slot strategy），而是彻底分离角色：Graph 提供骨架结构，BM25+Vector 提供文本证据，两者不竞争。

3. 参考文档提出的模块绝大多数是 0→1 阶段不该碰的

具体说：

Doctrine Guard / Heresy Detection / Tradition Consistency Filter — 这些本质上是分类器或规则引擎，需要大量标注数据和明确的判定标准。在你连基础检索质量都还没验证的阶段，建这些等于空中楼阁。而且”异端检测”的判定边界极其模糊，技术上不是一个 filter 能解决的。
Post-Verification Engine（Scripture Verifier + Citation Checker + Doctrine Validator） — Self-Reflective RAG 的方向是对的，v3.0 也把它标为 Phase 4+ 的目标。但参考文档把它画成一个独立引擎，仿佛加个模块就能实现，实际上 Scripture Verifier 需要一个完整的经文索引和引用解析系统，Citation Checker 需要 chunk 到原文的精确映射验证。这些都是独立工程。
300 节点知识图谱 — v3.0 规划的 50-100 核心节点 + 500-1000 关系已经是 0→1 阶段的合理上限。参考文档反复鼓吹 300+ 节点但没有给出任何抽取方法论，手工构建 300 个高质量节点的工作量是巨大的。
Doctrine Reasoning Engine — 参考文档把它描述成能做”教义逻辑验证”和”教义冲突检测”，但没给任何推理机制的实现路径。图谱遍历不等于推理。真正的教义推理需要形式化逻辑或者极其精细的 prompt engineering，不是画个箭头就有了。

4. 参考2（Concept Graph 方案对比）值得讨论

参考2提出了一个有意思的对比：方案A（概念树引导 Query Expansion，chunk 不绑定概念）vs 方案B（传统 GraphRAG，Graph 直接检索 chunk）。

但它的对比表极其偏颇——方案A全是五星，方案B全是三星，没有任何实验依据。实际上 v3.0 的设计已经取了两者的合理部分：Graph 存概念关系（类似方案A的概念树），同时保留 chunk-concept 的 EXPLAINS 边（方案B的精确关联），用于骨架覆盖检查时的定向补充。这比参考2的任何一个方案都更务实。

结论：v3.0 不需要因为这些参考文档做架构调整。

唯一可以从参考文档提取的 actionable item 是把 Self-Reflective 验证（特别是经文引用验证）的优先级从 Phase 4+ 提到 Phase 3 末尾作为可选项评估，因为经文引用错误是神学 AI 最容易被用户发现的质量问题。但这不是架构变更，只是排期微调。

神学 AI 研究引擎 —— 系统设计文档 v3.0

> **状态：** 当前有效设计（取代 v2.0）
> **日期：** 2026-03-12
> **阶段：** 0→1 开发
> **v2.0 → v3.0 核心变更：** Graph 角色重新定位 · 去掉 PostgreSQL · 简化组件

—

## 一、产品定位

用户输入一个神学真理问题，系统跨越倪柝声、李常受二人的所有著作，从关键词精准匹配、语义相似、概念关联图谱三个维度召回最相关段落，生成有深度、有来源溯源的综合洞察。

核心价值：
– 理解真理概念之间的关联，不是简单全文搜索
– 呈现同一真理在不同书籍、不同时期的完整阐释脉络
– 支持倪、李观点的对比与互补

—

## 二、技术选型

### 关键选型决策记录

**ES 整合双路，不用 Qdrant：**
0→1 阶段数据量有限（估计几十万 chunk），ES 8.x 原生支持 dense_vector + kNN，
完全可以同时承担 BM25 + Vector，减少一个组件。
等数据规模或性能成为瓶颈再考虑独立向量库。

**去掉 PostgreSQL（v3.0 变更）：**
v2.0 引入 PostgreSQL 存元数据（书目、层级、chunk 索引、doctrine 标签）。
评估后认为 0→1 阶段不需要独立关系数据库：
– 元数据（book / author / message / section / doctrine_tags）直接冗余存入 ES `_source`
– 处理进度追踪用本地 `progress.json`
– Doctrine 标签规范用 `doctrines.json` 维护
– 当处理规模变大（几十万 chunk 批处理）或需要管理后台时再引入

**ES 同时承担元数据存储：**
ES `_source` 天然存储 JSON 结构，`keyword` 类型字段支持精确过滤和聚合，
在数据量有限的 0→1 阶段完全胜任元数据查询需求。

—

## 三、整体架构

“`
┌──────────────────────────────────────────────────┐
│ 前端展示层 │
│ Next.js · 对话式查询 · 图谱可视化 │
└────────────────────┬─────────────────────────────┘
│ REST / WebSocket
┌────────────────────▼─────────────────────────────┐
│ API 服务层 │
│ FastAPI · 查询编排引擎 · LLM 调用 │
└───────┬──────────────────────────┬───────────────┘
│ │
┌───────▼──────────────┐ ┌──────▼──────────────┐
│ Elasticsearch │ │ Neo4j │
│ BM25 + Vector 双路 │ │ 概念骨架 · 关系 │
│ + 元数据存储 │ │ │
└───────────────────────┘ └─────────────────────┘
“`

两者通过应用层（FastAPI）关联，纽带是 `chunk_id`：
– Elasticsearch 存 chunk 文本 + 向量 + 元数据（用于检索 + 溯源）
– Neo4j 存神学概念节点和关系（用于推理骨架）

—

## 四、检索流水线

### 4.1 核心设计原则（v3.0 变更）

**Graph 不是第三路检索通道，是推理骨架提供者。**

v2.0 的设计让 Graph 和 BM25/Vector 并行竞争出 chunk，存在根本性问题：
– 图谱扩展的 chunk 被 Reranker 系统性压制（query 文本距离远）
– 把图谱结构”压平”成 chunk 列表后，关系信息丢失
– Graph 的价值（揭示概念间结构关系）在排名竞争中被完全浪费

v3.0 将 Graph 的角色重新定位为：
– **推理骨架**：提供概念间的结构关系，引导检索方向和回答组织
– **完整性保障**：确保关键概念不被遗漏
– **不参与排名竞争**：不进入 RRF，不被 Reranker 评判

### 4.2 完整流程

“`
用户 Query
│
▼
Step 1: Query 理解（LLM 抽取核心概念 · 1-3 个）
│ 输出：[“得胜者”, “赏赐”]
│
▼
Step 2: 概念骨架生成
│ ┌─ 有 Neo4j：图谱遍历，返回关系子图
│ └─ 无 Neo4j（Phase 1 降级）：LLM 生成概念关系骨架
│
│ 输出示例：
│ 得胜者 ──EXTENDS──► 基督的身体
│ 得胜者 ──TYPIFIES──► 拿细耳人
│ 得胜者 ──LEADS_TO──► 千年国赏赐
│
▼
Step 3: 主检索（BM25 + Vector 双路）
│ 输入：用户原始 Query
│ BM25 检索（ES）──► Top-K
│ Vector 检索（ES kNN）──► Top-K
│ RRF 融合（双路）──► 合并排名
│ Reranker 精排 ──► Top-N 段落
│
▼
Step 4: 骨架覆盖检查 + 定向补充
│ 对照 Step 2 的概念骨架，检查 Top-N 是否覆盖了关键概念节点
│ ├─ 已覆盖 → 不操作
│ └─ 缺失 → 定向补充：
│ Neo4j: 该概念的 EXPLAINS 边 → chunk_id → ES mget 取全文
│ 无 Neo4j: 用概念名做 ES BM25 定向检索 → 取 Top-1
│ 补充上限：最多 3 个 chunk（硬限制）
│ 不经过 Reranker，直接进入 Prompt
│
▼
Step 5: 结构化 Prompt 构建
│
│ ## 概念关系骨架（来自 Step 2）
│ 得胜者 ──延伸──► 基督的身体
│ 得胜者 ──预表──► 拿细耳人
│ 得胜者 ──导向──► 千年国赏赐
│
│ ## 高相关段落（来自主检索，Top-N）
│ [chunk 1] [chunk 2] …
│
│ ## 概念补充段落（来自骨架覆盖检查，标注来源）
│ [补充 chunk A – 关于”基督的身体”] …
│
▼
Step 6: LLM 生成（按骨架结构组织回答）
│
▼
结论输出（回答 + 引用溯源 + 概念关系图）
“`

### 4.3 RRF 融合公式（双路）

“`python
# BM25 + Vector 两路各自返回排好序的 chunk_id 列表
# RRF: score(chunk) = Σ 1/(k + rank_i)，k=60

def rrf_score(rankings: list[list[str]], k: int = 60) -> list[tuple[str, float]]:
scores = {}
for ranked_list in rankings:
for rank, chunk_id in enumerate(ranked_list, start=1):
scores[chunk_id] = scores.get(chunk_id, 0) + 1 / (k + rank)
return sorted(scores.items(), key=lambda x: x[1], reverse=True)
“`

### 4.4 Phase 1 降级模式（无 Neo4j）

Phase 1 没有 Neo4j，Step 2 用 LLM 代替图谱遍历：

“`
Prompt: “用户问的是'{query}’，请列出理解这个问题需要关联的
2-4 个相关神学概念及其关系类型（延伸/预表/对立/包含/导向）。
只列出倪柝声和李常受著作中明确教导过的概念。”

LLM 输出：
得胜者 ──延伸──► 基督的身体
得胜者 ──导向──► 千年国
“`

这样 Phase 1 就能验证”骨架式 Prompt”是否比”平铺式 Prompt”产出更深的回答，
不需要等 Neo4j 就绪。Phase 2 把 LLM 猜测替换为 Neo4j 真实子图。

### 4.5 骨架补充的 chunk 选取逻辑

当发现某个概念节点未被 Top-N 覆盖时：

**有 Neo4j：**
1. 查询该概念的 `EXPLAINS` 关系 → 拿到关联 chunk_id 列表
2. 去 ES `mget` 取回这些 chunk 的全文
3. 用 BM25 相关性分数选最高的 1 个

**无 Neo4j（Phase 1）：**
1. 用概念名作为关键词，在 ES 做 BM25 定向检索
2. 取 Top-1

**硬限制：**
– 每次查询最多补充 3 个 chunk
– 补充 chunk 在 Prompt 里明确标注为”概念补充”，与主检索结果区分

—

## 五、Elasticsearch 配置

### 5.1 IK Analyzer 策略

“`
索引时：ik_max_word（最细粒度切分，保证所有子词都被索引）
查询时：ik_smart（智能切分，保持概念完整性）
“`

示例：”长子名分”
– 索引时切为：长子名分 / 长子 / 名分
– 查询时输入”长子名分”→ 作为一个词搜索
– 查询时输入”长子”→ 作为独立词搜索

这是 IK 的标准最佳实践，天然解决复合神学术语的粒度矛盾。

### 5.2 同义词策略

**不加同义词表。**

理由：
– Vector 检索天然覆盖语义近似（”神的爱”和”神伟大的爱”在 embedding 空间是近邻）
– 同义词扩展会稀释 BM25 精准度，破坏两路分工
– 同义词维护成本不可控

唯一例外：同一概念在倪和李的著作里用了完全不同的表达，
且 embedding 模型因为语料稀缺没有把它们拉近的极端情况。

### 5.3 索引 Mapping

“`json
{
“mappings”: {
“properties”: {
“chunk_id”: { “type”: “keyword” },
“text”: {
“type”: “text”,
“analyzer”: “ik_max_word”,
“search_analyzer”: “ik_smart”
},
“embedding”: {
“type”: “dense_vector”,
“dims”: 1024,
“index”: true,
“similarity”: “cosine”
},
“book_title”: { “type”: “keyword” },
“author”: { “type”: “keyword” },
“year”: { “type”: “integer” },
“message_number”: { “type”: “integer” },
“message_title”: { “type”: “keyword” },
“section_number”: { “type”: “integer” },
“section_title”: { “type”: “keyword” },
“doctrine_tags”: { “type”: “keyword” },
“scripture_refs”: { “type”: “keyword” },
“tokens”: { “type”: “integer” }
}
}
}
“`

注：相比 v2.0，元数据字段更完整（book_title / year / message_title / section_title 等），
因为不再有 PostgreSQL 做 JOIN，所有元数据冗余存入 ES。

—

## 六、Neo4j Graph Schema

### 6.1 节点类型

“`cypher
(:Concept {name, aliases, layer}) // 神学概念（如：神圣三一、得胜者）
(:Book {title, author, year, language}) // 书籍
(:Chunk {chunk_id, text_preview}) // 段落（轻量引用，全文在 ES）
(:Scripture {book, chapter, verse}) // 经文
“`

### 6.2 关系类型

“`cypher
(:Concept)-[:EXTENDS]->(:Concept) // 概念延伸（如：基督是灵 → 喝那灵）
(:Concept)-[:CONTAINS]->(:Concept) // 包含（如：神圣三一 → 父/子/灵）
(:Concept)-[:TYPIFIES]->(:Concept) // 预表（旧约 → 新约实化）
(:Concept)-[:OPPOSES]->(:Concept) // 对立/对比
(:Concept)-[:LEADS_TO]->(:Concept) // 导向/结果（如：得胜者 → 千年国赏赐）
(:Chunk)-[:EXPLAINS]->(:Concept) // 段落解释某概念
(:Chunk)-[:CITES]->(:Scripture) // 段落引用经文
(:Chunk)-[:BELONGS_TO]->(:Book) // 段落出自某书
(:Book)-[:REFERENCES]->(:Book) // 李常受著作引用倪柝声著作
“`

注：v3.0 新增 `LEADS_TO` 关系类型（表示因果/目标关系），
在骨架生成中非常关键。

### 6.3 查询时的骨架生成（Neo4j 查询）

“`cypher
// 输入：用户问题中识别出的概念名列表
// 输出：以这些概念为中心的 1-2 跳关系子图

MATCH (c:Concept)-[r]-(related:Concept)
WHERE c.name IN $concept_names
WITH c, r, related
OPTIONAL MATCH (chunk:Chunk)-[:EXPLAINS]->(related)
RETURN c.name AS source,
type(r) AS relation,
related.name AS target,
related.layer AS target_layer,
collect(DISTINCT chunk.chunk_id)[..5] AS chunk_ids
ORDER BY related.layer ASC
LIMIT 20
“`

输出的子图直接作为 Step 2 的概念骨架，chunk_ids 用于 Step 4 的定向补充。

—

## 七、离线数据处理流水线

“`
原始文本（PDF / TXT）
│
▼
1. 文本清洗（去页码 · 去页眉 · 繁简转换）
│
▼
2. 结构解析（书名 → 信息 → 章节 → 段落层级）
│
▼
3. Chunking（按段落/自然段，400-800 tokens，overlap 120 tokens）
│
▼
4. JSON 构建 → 写入 ES（文本 + 元数据 + 向量）
│ 每个 chunk 的 JSON 包含完整元数据：
│ book_title / author / year / message / section / doctrine_tags
│ BM25 索引在写入时自动建立
│
▼
5. Embedding 生成 → 更新 ES 对应文档的 embedding 字段
│
▼
6. 实体抽取（LLM 从 chunk 中抽取神学概念 + 经文引用）
│
▼
7. 关系抽取（LLM 抽取概念间关系）→ 写入 Neo4j
│
▼
8. Doctrine Tagging → 更新 ES metadata 的 doctrine_tags 字段
“`

### 处理进度追踪（替代 PostgreSQL）

“`json
// progress.json
{
“books”: {
“以弗所书生命读经”: {
“total_chunks”: 320,
“embedded”: 320,
“entity_extracted”: 280,
“relation_extracted”: 250,
“doctrine_tagged”: 200
}
},
“last_updated”: “2026-03-12T10:00:00Z”
}
“`

### Chunking 策略

– 目标 token 范围：400-800 tokens（推荐 600）
– Overlap：120 tokens
– 按自然段/段落切分，不硬切断句子
– 保留来源元数据（book / message / section）

### 实体抽取 Prompt 要点

– 明确告知 LLM 这是神学语料
– 预定义关系类型：预表 / 实化 / 应验 / 包含 / 延伸 / 对立 / 导向
– 输出 (实体A, 关系, 实体B) 三元组
– 实体消歧需要领域词典辅助（”基督”=”神的儿子”=”主耶稣”=”羔羊”在某些语境下等价，某些语境下不等价）

—

## 八、知识图谱设计

### 8.1 十层神学概念体系

### 8.2 预估规模

– 0→1 阶段：50-100 核心节点 + 500-1000 关系
– 成熟阶段：200+ 节点 + 3000+ 关系

—

## 九、开发计划

### Phase 1（2-3 周）：基础 RAG + 骨架验证

– 选 1 本书（推荐《以弗所书生命读经》前 10 篇信息）作为种子数据
– JSON → ES 跑通双路检索（BM25 + Vector）
– 实现最简 FastAPI 接口 + 前端查询界面
– **用 LLM 生成概念骨架**（替代 Neo4j），验证”骨架式 Prompt”vs”平铺式 Prompt”的生成质量差异
– 建立评估体系（测试查询集 + Golden Dataset）

### Phase 2（2-3 周）：知识图谱接入

– 用种子数据手动 + LLM 辅助抽取 20-30 个实体和关系
– 导入 Neo4j
– 验证：Neo4j 真实子图 vs LLM 猜测骨架，哪个产出更准确的关系路径
– 验证：骨架覆盖检查 + 定向补充是否带回有价值的遗漏 chunk
– **如果图谱骨架不比 LLM 猜测好，重新评估 Neo4j 的投入**

### Phase 3（3-4 周）：完整流水线

– RRF 融合 + Reranker 精排
– 骨架覆盖检查 + 定向补充
– 结构化 Prompt 构建
– 完整问答闭环

### Phase 4（持续迭代）

– 引用溯源卡片 · 概念关系可视化
– 倪 vs 李对比阅读视图
– 扩展语料到全部著作
– 按需引入 PostgreSQL（管理后台、批处理进度、运营报表）

—

## 十、待建立的评估体系

当前缺失，需要在 Phase 1 同步建设：

– **测试查询集**：30-50 条，涵盖简单术语查询、跨概念推理、倪李对比等场景
– **Golden Dataset**：手工标注每条查询的期望结果（相关 chunk + 期望回答要点）
– **检索指标**：P@K、Recall@K、MRR
– **生成质量评估**：LLM-as-judge 或人工打分
– **骨架对比评估（v3.0 新增）**：同一查询分别用”平铺 Prompt”和”骨架 Prompt”生成回答，人工对比深度和结构性

没有评估体系，无法判断任何架构调整是进步还是退步。

—

## 十一、RAG 架构定位

参照 12 种 RAG 分类，本系统的当前和目标定位：

“`
认知层 [ Agentic ] [ Planning ] [ Self-Reflective ] [ Memory ]
↑ Phase 4+ 可加

结构层 [ GraphRAG ] [ Multi-hop ] [ Federated ]
↑ Phase 2-3（Graph 作为推理骨架，非检索通道）

检索层 [ Hybrid ] [ Hierarchical ] [ Multimodal ]
↑ Phase 1 实现

基础层 [ Naive ] [ Modular ]
↑ 架构基础
“`

优先级：GraphRAG + Hybrid 是核心。
Self-Reflective（生成后自动验证经节准确性）是最有价值的下一步。
Agentic / Planning / Memory 后期再议。

—

## 附录 A：v2.0 → v3.0 变更记录

## 附录 B：已废弃的设计决策（累积）