多级推理与质量涌现

Status: Ecosystem architecture with v0.5 implementation notes

当前 v0.5 CLI 的 Level 0 是 gaia run infer 本地 numerical preview：它允许 MaxEnt inputs，并且不因 review manifest 未 accepted 而抑制 belief 输出。 gaia build check --gate 才负责 publication-quality gate。本文的 Level 1/LKM snapshot、validated review reports 和 official belief flow 是生态层设计， 不代表当前 CLI 已实现的服务端流程。

本文档描述 Gaia 的多级推理架构——可信度如何在不同层级流动，错误如何被发现和修正，知识质量如何从去中心化的贡献中涌现。

为什么需要多级推理

单一层级的推理不够：

• 只有包级推理： 作者只能看到自己的直接依赖图。两个独立研究者各自得出相同结论，但彼此不知道对方的存在——它们的证据无法汇聚。
• 只有全局推理： 每次任何包更新都要重算全部节点（十亿级），延迟不可接受。而且全局推理依赖服务器，断网就不能工作。

Gaia 采用两级推理：

Level 0: 包级推理（作者本地，gaia run infer）
Level 1: LKM 推理（LKM Server，包含增量 snapshot 和全量收敛）

LKM 内部可能区分快速增量更新（snapshot）和定期全量收敛（global），但这是 LKM 的实现策略，不是架构层面的分级。

关于"federated registries / multi-LKM" 是不是第三层推理。 不是。多个独立 registry / LKM 让一个生态可以同时存在多个 Level-1 实例（每个 LKM 各自跑一份全局推理，给出自己的 belief snapshot），这是 tier-2 内部的多实例，不是单独的 tier-3 推理引擎。"社区 / 治理"层处理的是哪个 LKM 信谁、谁可以 fork 谁这种 governance 问题，而不是另跑一套推理算法。下游可以自由选择跟随某个 LKM 的 snapshot，或并列对比多个 LKM。

Level 0：包级推理（本地）

什么时候运行

作者在本地运行 gaia run infer，通常在编译（gaia build compile）之后。编译和推理的详细流程见 03 包的创建与发布。

做什么

1. 加载本包的编译产物（结构化推理图）
2. 解析作者显式声明的依赖版本
3. （可选）读取某个 LKM Repo 发布的 belief snapshot，作为上游命题的参考输入
4. 在本包的推理图上运行概率推理
5. 输出本包每个命题的可信度预览

为什么有用

• 快速反馈： 作者在发布前就能看到自己的推理结构是否合理。如果结论的可信度很低，可能说明前提不足或推理链薄弱。
• 完全离线： 不依赖任何服务器，作者可以在本地迭代。
• 确定性调试： 相同的输入（编译产物 + 依赖可信度）= 相同的输出。作者可以精确定位问题。

局限

• 只看到直接依赖图，不知道其他包的独立证据
• 如果选择了某个 LKM snapshot，它只是你选定视角下的结果，不是单一官方真理
• 没有跨包去重，相同命题在不同包中是独立实体

Level 1：LKM 推理

什么时候运行

当某个 LKM 观察到以下事件时，会更新自己的推理结果：

1. 带合格 assigned review reports 的包版本被 Official Registry 接收 — 新命题的 prior 和推理链参数进入输入
2. curation 包合并 — duplicate / contradiction / refinement / connection 的结构变更进入图
3. 撤回 / 修正合并（未引入，见 Gaia IR design） — 已有参数或结构被回收，需要回到保守状态
4. 定期全量收敛 — 处理增量更新无法完整覆盖的长链传播和跨 Registry 关系

做什么

事件触发（package merge / curation merge / retraction（未引入） / 定期全量）
  ↓
确定受影响的范围：
  - 增量：从变更点出发，沿推理链找到受影响的局部子图
  - 全量：整个知识网络
  ↓
在对应范围上运行概率推理
  ↓
更新命题的可信度
  ↓
发布到该 LKM Repo 的 belief snapshot

触发场景

触发事件	影响范围	预期效果
包入库（带合格 review reports）	该包版本导出的命题 + 下游	新 prior / strategy 开始生效
duplicate / contradiction / connection 确认	相关命题及其下游	重新评估独立性或约束
推理链撤回	被撤回推理链的结论 + 下游	结论失去该推理链的支持，可信度可能降低
定期全量	整个知识网络	长链传播收敛、跨 Registry 关系处理

增量 vs 全量是 LKM 的内部策略

LKM 内部通常区分两种更新模式：

• 增量更新： 事件驱动，只处理受影响的局部子图，秒到分钟级延迟。适合快速发布可参考的结果。
• 全量收敛： 定期运行，处理整个知识网络，分钟到小时级延迟。处理增量无法覆盖的长链传播和跨 Registry 可信度传播。

两种模式都运行在同一个 LKM Server 上，产出发布到同一个 LKM Repo。用户通常只需要关注最新的 belief snapshot，不需要区分它来自增量还是全量。只有在长链传播或跨 Registry 关系密集的区域，全量结果才可能与增量结果有显著差异。

不同 LKM 之间也可能并存不同的 belief snapshot；用户需要显式选择信任哪个 LKM 的视角。

错误修正

去中心化系统不可避免地会有错误。Gaia 的错误修正策略是：发现错误 → 回退到保守状态 → 重新评估 → 恢复。 全过程可审计，不会悄悄改变结论。

场景 1：迟发现的重复命题

问题： 注册时的去重漏掉了一对语义相同的命题（例如 "YBCO 在 92K 以下超导" 和 "YBa₂Cu₃O₇ 的 Tc 为 92 ± 1 K"），它们被当成两个独立命题各自汇聚了证据。

修正流程：

LKM 发现命题 A ≈ 命题 B
  ↓
在 LKM Repo 创建 equivalence issue（research task）
  ↓
调查确认 → LKM 创建 curation 包，声明 A 和 B 应合并
  ↓
curation 包收集并合并足够的 assigned review reports → 注册到 Official Registry（标准流程）
  ↓
合并执行：
  1. B 的所有引用重定向到 A
  2. B 标记为已合并（保留审计记录）
  3. 暂停受影响推理链的参数（回退到安全状态）
  4. 级联 re-review：重新评估受影响推理链的独立性
  ↓
Re-review 完成 → 恢复参数 → LKM 发布新的 snapshot / 全局结果

为什么暂停参数： 合并前，指向 A 和 B 的推理链被视为独立证据（因为它们指向"不同"命题）。合并后，这些推理链实际上指向同一个命题——它们可能不是独立证据，而是重复论证。暂停参数确保在 re-review 判定之前，不会多算证据。

安全方向： 暂停参数意味着这些推理链暂时不参与推理。可能的结果是相关命题的可信度暂时降低（少算了证据），但绝不会升高（多算了证据）。这是保守方向——宁可暂时低估，也不虚假膨胀。

场景 2：矛盾发现

问题： 两个命题互相矛盾（如 "Tc = 92K" vs "Tc = 89K"），但各自的作者不知道对方的存在。

修正流程：

LKM 发现命题 P 和命题 Q 矛盾
  ↓
在 LKM Repo 创建 contradiction issue（research task）
  ↓
调查确认 → LKM 创建 curation 包，声明 P 和 Q 矛盾
  ↓
curation 包收集并合并足够的 assigned review reports → 注册到 Official Registry（标准流程）
  ↓
推理引擎处理：
  - P 和 Q 之间建立矛盾关系
  - 推理时自动保证 P 和 Q 不会同时具有高可信度
  - 如果支持 P 的证据更多，P 的可信度升高，Q 的降低
  - 反之亦然
  ↓
LKM 更新所有受影响命题的 snapshot / 全局结果

矛盾是结构性事实： 一旦确认矛盾，推理引擎自动维护逻辑一致性。不需要人工干预"哪个对"——证据会说话。

场景 3：推理链撤回

问题： 某条推理链被发现有方法论错误（如数据造假、统计方法不当），需要撤回。

修正流程：

Reviewer 提交撤回 PR
  ↓
撤回执行：
  1. 推理链标记为已撤回（保留审计记录，但不再参与推理）
  2. 该推理链的参数清除
  3. 受影响结论的可信度重新计算
  ↓
LKM 重新发布 snapshot：
  - 结论失去该推理链的支持
  - 如果还有其他独立推理链支持，结论可信度降低但不归零
  - 如果是唯一支持，结论回退到先验概率

撤回不是删除： 撤回的推理链仍然保留在记录中，有完整的审计轨迹（谁撤回的、为什么、什么时候）。这和科学论文的撤稿类似——论文不会从数据库消失，而是被标记为撤稿。

场景 4：依赖包重大更新

问题： 上游包发布了 MAJOR 版本更新（如结论从 "Tc = 92K" 变为 "Tc = 89K"），下游包还在引用旧版本。

修正流程：

上游包发布 MAJOR 版本
  ↓
Official Registry 记录新版本
  ↓
通知下游包的维护者：
  "你的包依赖 X v3.0.0，X 已发布 v4.0.0（MAJOR 更新）"
  ↓
下游维护者决定：
  a. 更新依赖 → gaia build compile + gaia run infer → 重新注册
  b. 暂不更新 → 继续使用旧版本（可信度基于旧数据）
  c. 不再需要该依赖 → 移除引用

下游自主权： MAJOR 更新不会自动传播（和 npm/cargo 一致）。下游维护者决定何时、是否接受更新。这是去中心化的关键——没有任何中心权威能强制更新下游。

质量涌现

Gaia 没有一个中心化的"质量审查委员会"。知识质量通过多个机制从去中心化的贡献中涌现：

机制 1：独立证据汇聚

结论 X 只有一条推理链支持 → 可信度一般（如 0.80）
结论 X 有三条独立推理链支持 → 可信度高（如 0.96）
结论 X 有十条独立推理链支持 → 可信度非常高（如 0.999）

为什么有效： 如果多个独立研究者用不同的方法、不同的数据得出了相同的结论，该结论很可能是正确的。这不是投票——推理引擎考虑的是每条推理链的强度和独立性，不是数量。

机制 2：矛盾自动抑制

命题 P（"Tc = 92K"）和命题 Q（"Tc = 89K"）被确认矛盾
  ↓
支持 P 的证据：5 条独立推理链
支持 Q 的证据：2 条独立推理链
  ↓
推理引擎自动：P 的可信度升高，Q 的可信度降低
  ↓
如果后来 Q 获得了 10 条新的独立证据
  ↓
推理引擎自动调整：Q 的可信度反超 P

为什么有效： 矛盾迫使系统做出选择——不可能两个矛盾命题都有高可信度。证据最终决定哪个更可信。这是自动的，不需要委员会裁决。

机制 3：审核门控

任何人都可以注册包（低门槛）
  ↓
但推理链只有在随包版本附带足够 valid assigned review reports、并通过 Registry 入库之后才进入官方 belief 流程
  ↓
Review Server（LLM/agent）评估推理逻辑并把 prior / strategy 写进 review reports
  ↓
作者可以和 Review Server rebuttal（增加透明度）
  ↓
逻辑不可靠的推理链拿不到高的条件概率 → 对全局结果影响很小

为什么有效： 这在"开放贡献"和"质量保证"之间取得了平衡。任何人都可以贡献证据（低门槛），但推理链必须随包带上满足 Registry 最低标准、且来自 assigned reviewers 的 review reports，才能获得参数并进入 LKM 的 belief 流程（质量门槛）。rebuttal 过程保证了透明度。

机制 4：可 fork 的 Registry

物理学社区运行自己的 Registry → 有自己的审核标准
化学社区运行自己的 Registry → 有自己的审核标准
某机构 fork 了物理学 Registry → 用更严格的标准重新审核

为什么有效： 不同社区可以对同一命题有不同的可信度评估。这不是问题——这正是科学的本质。没有单一的"真理权威"。用户可以选择信任哪个 Registry。

质量涌现的整体图景

开放贡献（任何人可以注册包）
    ↓ 审核门控
有质量的推理链被激活
    ↓ 独立证据汇聚
多条独立推理支持的结论可信度升高
    ↓ 矛盾自动抑制
矛盾的命题不会同时具有高可信度
    ↓ 错误修正
发现的错误被暂停、重审、修正
    ↓ 多级推理
局部更新快速响应，全局推理保证收敛
    ↓ 可 fork
不同社区可以有不同的评估标准
    ↓
= 去中心化的知识质量涌现

没有任何单一机制能保证质量。质量来自于这些机制的组合——每个机制处理一种失败模式，组合起来形成自我修正的知识网络。

两级推理与两个 Server 的关系

	Level 0（包级）	Level 1（LKM）
运行环境	作者本地	LKM Server
触发	gaia run infer	事件驱动（增量）+ 定期（全量）
范围	本包 + 直接依赖	局部子图（增量）或整个知识网络（全量）
Review Server	本地 self-review 仅供预览	入库时通过 assignment + 校验的 review reports 作为推理输入
LKM	不涉及	推理 + belief snapshot 发布 + curation（发现跨包关系）
可用性	完全离线	需要 LKM Server

每一层都是可选增强。用户可以只用 Level 0（完全离线），再选择一个 LKM Repo 的 belief snapshot 作为共享参考。

相关文档

• 02-decentralized-architecture.md — 架构总纲，参与者和交互关系
• 05-review-and-curation.md — Review Server 审核流程 + LKM curation 的两阶段流程
• 04-registry-operations.md — 注册、官方 review 协调、relation report issue