Skip to content

Gaia 产品范围

Status: Current product direction. Current v0.5 implementation is the local Python DSL + CLI; LKM/server capabilities below are target ecosystem services, not code shipped in this repository.

相关文档： - Gaia IR design - ../theory/04-reasoning-strategies.md - Gaia Lang design

目的

本文档定义 Gaia 的产品定位和理论基础。

本文档的职责：

  • 陈述理论基础——Gaia 为何存在，以及现有工具为何无法替代它
  • 陈述已决定的产品方向

理论基础

目标：大型知识模型

Gaia 的目标生态是构建一个 Large Knowledge Model (LKM)——一个十亿级 规模的推理超图，其中命题是节点，推理关系是超边。当前 v0.5 仓库提供 的是本地 Python DSL、CLI、IR、review、registry 和 BP 基础；云端 LKM 自动构建属于后续服务层。

这需要一种机器可读、机器可写的知识表示，支持：

  1. 结构化推理——不是自由文本，而是类型化的知识对象和明确的支持/约束结构
  2. 概率信念——知识不是非真即假，而是携带信念度，因为科学知识本质上是不确定的
  3. 可组合模块——知识必须能够被打包、导出、导入和组合，就像编程语言中的代码一样
  4. 自动推理——当新证据到来时，系统必须自动通过图传播信念

这些需求共同定义了一种用于科学推理的形式化包语言。Gaia 就是这种语言。

Gaia 作为概率科学推理的结构化语言

Gaia 是一种用于概率科学推理的结构化语言。

它结合了：

  • 一个确定性的编写包表面
  • 一个结构性的 Gaia IR 层
  • 一个在其上的概率推理层
层 提供什么 编程语言类比
编写包表面 声明、引用、模块、包结构 类型化 DSL / 包语言
Gaia IR 提交的结构图、规范化边界、因子图形状 类型化中间表示
推理层 先验、因子参数、BP、审查衍生的判断 概率推理层

只有封闭的、具有真值的科学断言直接参与普通领域 BP。问题、工作流声明、审查制品和内部策展制品可能仍然存在于 Gaia 包或服务输出中，但它们默认不是普通领域 BP 变量。

理论定位：

  • Polya（Mathematics and Plausible Reasoning，1954）——推理超越演绎证明，延伸到似然推理
  • Jaynes（Probability Theory: The Logic of Science，2003）——概率是似然推理的逻辑，是演绎逻辑向信念度的推广
  • Cox 定理——任何一致的似然推理系统都同构于概率论

Gaia 致力于成为似然推理的 Curry-Howard：正如函数式编程语言（Haskell、Lean）建立在证明与程序之间的 Curry-Howard 对应关系之上，Gaia 将其从演绎确定性扩展到似然信念。这是一个开放的研究方向，而非已确立的定理——概率计算的完整 Curry-Howard 对应关系仍然是一个活跃的研究领域（参见 "Curry and Howard Meet Borel", LICS 2022）。

现有工具为何无法替代 Gaia

为何不用现有的概率编程语言（Pyro、Stan、Church、Hakaru）？

这些语言建模的是统计概率——用于数据建模的随机变量上的分布。Gaia 建模的是认知概率——对命题真值的信念度。

统计概率（Pyro/Stan） 认知概率（Gaia）
概率的对象 随机变量（数值） 命题（知识对象）
概率的含义 结果的频率/测度 对真值的信念度
条件化对象 观测数据 依赖角色（direct / indirect；语义 premise / context）
图模型 DAG（Bayesian 网络） 超图（多前提 → 多结论）
推理计算 后验分布 命题上的信念分数
推理算法 MCMC、变分推断 从 Gaia IR 派生的因子图推理；小树宽图走精确 Junction Tree，大图/宽图走 TRW-BP 或 Mean Field VI

数学基础相同（Bayesian 概率），但领域结构根本不同——就像 SQL 和 Haskell 都基于集合论，但 SQL 存在是因为关系数据需要自己的语言。

为何不用现有的函数式编程语言（Haskell、OCaml）？

这些语言提供演绎逻辑层，但没有内建的概率推理。你可以在 Haskell 之上构建 Gaia，但你需要添加整个概率层（先验、Belief Propagation、条件化语义、超图推理）——到那时你已经构建了一种新语言。

为何不用现有的知识图谱（Neo4j、OWL、RDF）？

这些提供图存储和确定性查询，但没有概率推理。它们能告诉你"A 与 B 相连"，但无法告诉你"给定 A 的证据，你应该多大程度上相信 B？"

Gaia 的独特组合

Gaia 结合了三种没有任何现有工具能同时提供的能力：

  1. 基于包的结构化知识表示——声明、链、模块、包，以及明确的结构降级
  2. 认知概率推理——先验、信念、依赖角色、矛盾/撤回语义——根植于 Jaynes 的概率即逻辑传统
  3. 超图 Belief Propagation——当前本地 CLI 在从知识包结构派生的因子图上自动选择 Junction Tree、TRW-BP 或 Mean Field VI；整个 LKM 上的全局自洽信念属于目标服务层

这种组合使核心产品方向成为可能：AI 代理编写知识包（概率程序）， 本地 CLI 给出可复现实验级 posterior preview，目标云端服务在通过 review/registry 后运行更大规模的 Belief Propagation（后验推理），结果 是一个大型知识模型，其中每个命题都携带校准的信念度。

产品方向（已决定）

Gaia 是 CLI 优先，服务器增强。

  • CLI 是主要产品——AI 代理和研究人员通过 CLI 与 Gaia 交互，在本地工作，零服务器依赖
  • 目标本地管线是 build -> self-review skill -> graph-construction skill -> infer -> publish，在 v0.5 alpha-0 的 grouped CLI 上对应 gaia build init/compile/check → gaia inquiry review / focus / hypothesis → gaia run infer → gaia run render → gaia pkg register；详见 ../cli/workflow.md 与 ../../migration.md
  • 正式的外部提交优先使用 Gaia 包——默认为 knowledge，另有 review、rebuttal 和有意对外公开的 investigation 作为额外制品配置
  • 服务器提供四项可选增强服务加内部维护：
  • 知识集成——将批准的包合并到全局 Large Knowledge Model
  • 全局搜索——跨包的向量 + BM25 + 拓扑搜索
  • 同行评审与注册集成——独立评审、编辑决定、身份分配
  • 大规模 BP——十亿节点的 GPU 集群 Belief Propagation
  • 内部策展——服务器内部的离线图维护，不是默认的外部提交表面

目标共享交互路径为：CLI → git push / publish → 同行评审 → 反驳 / 编辑周期 → 合并或拒绝（类似于学术出版工作流）。

用户可以完全离线使用 CLI。服务器是可选的注册中心和计算后端，而非前提条件。

产品定位总结

Gaia 是一个 CLI 优先、服务器增强的大型知识模型平台。

  • CLI——创建、构建、审查和发布 Gaia 包的主要产品表面
  • 服务器——提供知识集成、全局搜索、同行评审/身份分配、大规模 BP 和内部离线策展的可选注册中心
  • 仪表盘——用于探索服务器端知识图的浏览器 UI

对未来工作的启示

大型新工作应以以下方式之一来规划：

  1. 扩展 CLI 产品表面（主要产品）
  2. 将服务器扩展为 CLI 的注册中心和计算后端
  3. 加强 CLI 和服务器共同依赖的共享基础

这意味着：

  • 共享合约（本体论、包 schema、审查/策展边界、制品配置）是最高优先级的基础工作
  • CLI 架构应驱动设计决策，而非作为附带考虑
  • 服务器工作应聚焦于增强服务，而非成为唯一的产品表面

已决定的问题

这些问题已解决，不应重新讨论：

  1. CLI 优先还是服务器优先？ → CLI 优先，服务器增强。
  2. 主要交互路径？ → CLI 本地管线（build -> self-review -> graph-construction -> infer -> publish）→ 共享同行评审 / 编辑周期 → 合并或拒绝。

开放的产品决策

这些在后续基础阶段仍待决定：

  1. 直接发布（gaia publish --server）的合约是什么？（已推迟）