跳转到内容

技术宪章

状态: 讨论版 v1.1 定位: 规定 Apodex 在技术上的使命、价值观、边界与长期架构原则。


1. 定位与使命:发现式 AI,而非生成式 AI

Section titled “1. 定位与使命:发现式 AI,而非生成式 AI”

Apodex 要构建的是一种新范式的 AI 系统:

  • 不以”取代人类”为目的,而是帮助人类完成人类无法完成或极难完成的任务;
  • 尤其在医学、科学、金融等高复杂、高风险领域,为人类带来长期实质性福祉。

1.2 从”生成”到”发现”:Discoverative AI

Section titled “1.2 从”生成”到”发现”:Discoverative AI”

我们将自身定义为 发现式 AI(Discoverative AI)

  • 与以内容生成为主的”生成式 AI”不同;
  • 核心是:在复杂系统中进行深度推理,发现结构、模式与因果机制,产出可验证的结论与决策建议。

1.3 本质:Heavy-Duty Solver(重型求解器)

Section titled “1.3 本质:Heavy-Duty Solver(重型求解器)”

Apodex 的技术愿景是打造一个 Heavy-Duty Solver

  • 能承受长链条、多分支、高不确定性的推理任务;
  • 能在复杂约束下,给出高置信度、可解释、可复现的答案与策略。

2. 核心原则:Slow & Right 的通用重型求解器

Section titled “2. 核心原则:Slow & Right 的通用重型求解器”

2.1 Slow and Right:以”难题 + 正确”为首要目标

Section titled “2.1 Slow and Right:以”难题 + 正确”为首要目标”
  • 从不把响应速度当作一阶优化目标
  • 优先级:正确性 > 完整性 > 稳定性 > 速度
  • 面向的是高复杂度、容错率极低、需要严肃审计的任务。
  • 目标是构建通用的多步长链解决体系,适配金融、科学研究、药物发现、材料设计、编码等多种复杂系统;
  • 核心求解架构在各行业保持一致,领域差异主要体现在工具、知识与约束层面,而非完全不同的求解逻辑。
  • 长期技术目标:在约 300 步连续推理链路上,达成接近 99% 的逻辑正确率
  • “正确率”不仅指最终答案,更指中间推理步骤的逻辑自洽与证据支持。

  • 我们把 Apodex 自身视为需被求解和优化的最大复杂系统之一
  • 系统必须具备识别自身能力边界、瓶颈、失败模式的能力。

3.2 自循环与自我进化(Self-Evolving)

Section titled “3.2 自循环与自我进化(Self-Evolving)”

Apodex 必须具备面向自身的闭环能力:

  • 自我任务化:清楚”接下来要改进什么”;
  • 自我规划:形成面向数据、模型、工具与架构的演进路线图;
  • 自我执行:自动化地收集数据、运行实验、调整配置;
  • 自我检查:用自身的验证系统评估改动效果,保留有效改动,回滚无效甚至有害的改动。

注:宪章只规定方向,不限制采用哪种具体算法(RL、AutoML、自监督演化等)。


4. 因果三层架构:看到 / 想到 / 做到(See–Think–Do)

Section titled “4. 因果三层架构:看到 / 想到 / 做到(See–Think–Do)”

我们采用受《The Book of Why》启发的因果架构,将系统拆解为三个必须同时推进的层次:

4.1 看到(See)—— 验证与感知层

Section titled “4.1 看到(See)—— 验证与感知层”
  • 负责感知世界和系统自身:读取数据、观测反馈、衡量结果;
  • 核心职责是验证与评估,对推理和行动给出判断与信号;
  • 是系统的”眼睛”和”裁判”。

4.2 想到(Think)—— 大模型与推理层

Section titled “4.2 想到(Think)—— 大模型与推理层”
  • 负责理解问题、构造假设、分解任务、设计方案;
  • 利用大模型及其周边推理机制,构建候选决策图与因果结构;
  • 是系统的”头脑”。

4.3 做到(Do)—— Harness 与执行层

Section titled “4.3 做到(Do)—— Harness 与执行层”
  • 负责把计划落地:调度多 Agent、多工具、多进程,操作外部世界;
  • 管理执行过程中的超时、失败、中断、回滚和重试;
  • 是系统的”手脚”。

📌 宪章要求

  • Apodex 必须是这三层的组合体,而不是”只有一个大模型”;
  • 验证与评估层(See)是差异化核心,不是附属品。

5.1 结构化推理:从线性到图结构

Section titled “5.1 结构化推理:从线性到图结构”

我们拒绝把简单”多轮对话串联”视为真正推理链。Apodex 的推理过程应向**有向无环图(DAG)**或类似的高级图结构演进:

  • 节点:子任务、假设、实验、工具调用、验证步骤等;
  • 边:依赖关系、因果关系、证据支持关系;
  • 支持并行分支、回溯、剪枝与多路径聚合。

方向性要求:

  • 任何关键结论,都应能溯源到其所在的推理子图;
  • 审计者应能看到”是怎样一步步推到这里的”;
  • 注:DAG 是当前推荐的结构化推理方向,宪章鼓励探索更优的图结构或拓扑表达,核心目标是实现推理过程的可溯源与可解释。

5.2 多层记忆:近程 / 中程 / 远程

Section titled “5.2 多层记忆:近程 / 中程 / 远程”
  • 近程记忆(Short-term):针对单次任务会话的上下文与中间结果;
  • 中程记忆(Project-level):针对同一项目 / 病人 / 策略的持续理解与历史;
  • 远程记忆(Long-term / Domain-level):针对领域经验与模式的长期沉淀。

宪章要求: 这三层记忆必须存在,并在 pre-training、mid-training、post-training 中保持一致的接口与语义;不限定具体的数据结构与实现方式。


6. 验证系统:以”逻辑与过程”为核心的第一公民

Section titled “6. 验证系统:以”逻辑与过程”为核心的第一公民”
  • 任何重要结论必须经过独立的验证过程,而不是由同一推理过程自证正确;
  • 验证层在系统中是一等公民:参与任务执行过程;直接影响结果是否采纳与如何呈现。

验证重点包括:

  • 推理步骤是否逻辑自洽,有无明显跳步与矛盾;
  • 引用证据是否真实、相关、充分;
  • 整条推理路径是否在合理假设下成立。

6.3 验证 → 训练 → 系统更新的闭环

Section titled “6.3 验证 → 训练 → 系统更新的闭环”

验证结果不是”评分而已”,而是:

  • 成为训练信号(正例 / 反例);
  • 引导数据与策略的再采样与再加权;
  • 长期塑造系统对”好解法 / 坏解法”的偏好。

7. 训练与系统全流程:从 Pre 到 Post 的一体化工程

Section titled “7. 训练与系统全流程:从 Pre 到 Post 的一体化工程”
  • 强调数据质量与可验证性,优先真实世界、高置信度数据;
  • 适度构建结构化知识与约束(如物理、财务、医学规则)。

7.2 Mid Training(过程与结构学习)

Section titled “7.2 Mid Training(过程与结构学习)”

不只学习”输入 → 输出”,而是学习:

  • 如何分解问题、生成计划;
  • 何时、如何使用工具;
  • 如何在验证信号与反馈下调整路径。

7.3 Post Training(DPO / RL / 其他强化范式)

Section titled “7.3 Post Training(DPO / RL / 其他强化范式)”
  • 强化逻辑自洽、有证据、可解释的解法;
  • 抑制高自信错误和逻辑跳跃。

整条管线对齐在一个长线目标上:长链推理的稳定性与高正确率,而非短题 SOTA 分数。


8. 评估与 Benchmark:逻辑导向的多维评价体系

Section titled “8. 评估与 Benchmark:逻辑导向的多维评价体系”

注:第 6 章的 Verification 是系统内部的、在执行流中实时起作用的验证机制(in-loop verification);本章的 Evaluation / Benchmark 是系统外部的、事后汇总的性能评估(external eval),用于对比不同版本和策略的整体表现。

8.1 Benchmark 是核心仪表盘,而非装饰

Section titled “8.1 Benchmark 是核心仪表盘,而非装饰”
  • 对外:展示 Apodex 在不同维度上的真实能力水平;
  • 对内:作为数据积累、训练策略与架构改动效果的主要量化刻度。

8.2 以逻辑和过程为中心,而非仅最终答案

Section titled “8.2 以逻辑和过程为中心,而非仅最终答案”

评估维度应覆盖:

  • 推理链条完整度与结构合理性;
  • 可解释性与证据支撑情况;
  • 验证系统对错误推理的检出能力与校准程度。
  • 面向一般推理、数学与科学、医疗、金融等建立各自任务集与维度;
  • 同时包含:终局指标(收益、准确率等);过程指标(风险暴露、逻辑质量、不确定性管理等)。
  • 宪章不固定具体榜单与数值;
  • 但要求:逻辑导向、多维度、长期维护,并随系统能力与应用场景共同演化。

9. 安全、可解释性与工程演进原则

Section titled “9. 安全、可解释性与工程演进原则”
  • 在医疗、金融等高风险领域,Apodex 仅作为决策支持系统,最终决策必须由具备资质的人类专业人士做出;
  • 所有任务按潜在危害进行分级,风险等级越高,所需的验证强度、人类复核与审计要求越高;
  • 使用个人与敏感数据时,必须遵守所在司法辖区法律法规,遵循最小必要数据原则,并保留访问和操作审计记录。
  • 面向用户或下游系统输出的关键结论,必须能追溯其主要证据与关键推理步骤,而非不可解释的黑盒判断;
  • 对重要结论,系统应显式给出不确定性或置信度信息;
  • 在信息不足或证据冲突时,允许、并鼓励给出”不确定”,而非伪装为高置信度的单一答案。
  • 长链任务应设计为可分阶段 checkpoint、可在失败后从最近安全点继续,而不是整体静默失败或无提示中断;
  • 每个任务应有明确的计算、资源与时间预算;
  • 当预算或外部条件不允许继续时,系统应给出部分结果与当前局限说明,而不是生成看似完整、实则站不住脚的答案。
  • 在不违反安全与合规前提下,新版本应尽量保证历史任务与轨迹可以重放或重现
  • 对确需破坏兼容性的改动,应提供清晰迁移方案与过渡期;
  • 所有临时性实现与已知缺陷应标记为「技术债」,纳入公开清单,并在版本规划中预留资源持续偿还,避免架构长期腐化。

在上述统一架构与原则下,Apodex 将重点推进三大应用方向:

10.1 医疗决策与新药发现协同系统

Section titled “10.1 医疗决策与新药发现协同系统”
  • 面向单一病人的长期医疗决策:基于完整个人医疗数据(病历、检验、影像、基因、生活方式等),通过多步推理为不同疾病阶段、不同干预路径提供风险 / 收益评估与决策建议;
  • 当现有药物体系中没有合适方案时:通过 Harness 将各类药物研发 Agent / 平台串联,在药物空间中寻找潜在新方案;
  • Apodex 扮演”医疗需求 ↔ 药物探索”之间的桥梁角色。

10.2 真实可验证数据集的生产与服务

Section titled “10.2 真实可验证数据集的生产与服务”
  • Apodex 自身是一个高质量数据生产引擎:借助推理与验证系统,自动生成、筛选、标注高质量、可审计的数据;尤其是过程级、因果级数据,而非仅最终标签;
  • 数据集既是自用的长期燃料,也是对外的重要产品形态,可面向科研机构、企业出售或合作使用。
  • 基于统一推理与验证架构,构建面向金融市场的量化决策引擎:综合宏观 / 微观数据、多资产、多时间尺度;强调风险控制与解释能力,而非只追求短期收益率;
  • 长期目标:在合理风险约束下,实现超越大盘的风险调整后收益;同时为机构客户提供基于 Apodex 平台的量化模型与决策 API / 方案。

💰 商业模式

  • 在上述三大自有应用中直接获得收益;
  • 通过 API 与平台化能力,对科研、材料、工业等其他高复杂度决策场景输出重型推理基础设施

本技术宪章只规定 Apodex 在技术上的使命、价值观、边界与长期架构原则;不规定具体算法、模型结构、训练细节或短期优化路径。

它回答的是”我们要造一个什么样的系统、哪些事坚决不做”,而不是”研究员必须怎样实现”。

在本宪章边界之内,研究员拥有充分的探索与突破自由,具体技术路线与实现规范应由后续技术文档与版本设计在实践中不断演化。