EvoOntology

1个月前发布 63 00

EvoOntology 可以理解为数据分析 AI 助手专属的**业务词典**。企业数据库、表格里大多只有字段代号与原始数值,AI 很难理解背后真实业务含义,分析时容易误判,反复试错。EvoOntology 负责梳理业务规则,构建结构化语义知识库,并且可以观测 Agent 执行过程,自动补充、修正这套词典,越使用越贴合业务。

所在地:
中国
收录时间:
2026-09-19
EvoOntologyEvoOntology

在企业数据分析场景中,AI Agent 常常面临一个核心痛点:原始数据只有代号和数字,缺乏显式的业务语义。这导致 Agent 在分析时频繁猜测、重复探索,甚至产生严重的语义错误。EvoOntology 正是为解决这一 “Agent-Data Gap” 而生的开源项目。

EvoOntology

它不仅仅是一个静态的知识库,更是一个可训练、自进化的 Ontology Layer。通过 MCP 工具集成,它能根据真实的 workload 和执行轨迹持续自我修正,让 Data Agent 越用越聪明。

核心价值:为什么需要 EvoOntology?

  1. 消除语义不确定性:将隐藏在表名、字段背后的指标口径、实体关系与业务约束显式化,避免 Agent “望文生义”。
  2. 拒绝重复探索:跨任务复用经过数据验证的知识,让 Agent 聚焦于分析本身,而非每次重新理解环境。
  3. 降低维护成本:告别依赖专家手工维护的静态语义层。EvoOntology 根据实际交互自动适配,且所有更新均可检查、比较和回滚。
EvoOntology

架构设计:三层联动 + 门控进化

EvoOntology 将 Ontology Layer 视为一种可训练的 Agent 状态,由三个相互关联的层组成:

层级作用关键特性
Content Layer类型化语义图包含 Term、Mapping、Constraint、Evidence 四类节点及其关系
Schema Layer表达边界定义规定节点字段、合法关系类型及结构引用模式
Tool Layer运行时访问接口通过 browse_semantics / resolve_semantics 按需暴露语义,会话初始化仅注入轻量 manifest

自进化生命周期

  • Build:从 workload 提取候选概念,在原始数据源中验证后发布 ontology_v0。
  • Use:Agent 按需查询并记录交互轨迹与任务结果。
  • Evolve:诊断重复出现的问题,生成局部 Candidate 补丁。
  • Evaluate:在相同配置下配对评估 Parent 与 Candidate。
  • Publish/Reject:只有通过门控评估的 Candidate 才会发布为新版本,确保进化方向始终正确。

快速开始:一键安装,零配置接入

EvoOntology 已上架 GitHub Marketplace,支持 Claude Code 和 Codex 等主流 Agent 框架,无需手动 clone 或配置环境。

Claude Code

claude plugin marketplace add MeiduoChong/EvoOntology
claude plugin install evoontology@evoontology
# 新建会话后运行
/evo-build      # 构建初始本体
/evo-evolve     # 触发自进化
/evo-visualize  # 可视化语义图

Codex

codex plugin marketplace add MeiduoChong/EvoOntology
codex plugin add evoontology-codex@evoontology
# 新建 thread 后使用
$evo-build
$evo-evolve
$evo-visualize

构建完成后,Data Agent 即可直接调用 MCP 工具查询语义,无需额外配置。

性能表现:实测显著提升

在四个主流分析 Benchmark 上,EvoOntology 相比无 Ontology Layer 的 ReAct 基线均取得明显提升:

Benchmark指标ReAct (无本体)初始本体EvoOntology相对提升
DDR-Bench (10-K)Trajectory-Wise69.581.889.5+20.0
BIRDExecution Accuracy63.668.772.4+8.8
InsightBenchInsight Score53.254.054.2+1.0

💡 关键洞察:初始本体已带来显著收益,而自进化机制能在此基础上进一步持续提升,证明“基于真实 workload 的定向进化”策略有效。

两种使用模式适配不同场景

  • fixed_split:适用于有固定测试集的 Benchmark 评估。Construction 数据用于构建和诊断,Validation Reserve 专用于最终门控。
  • rolling_trajectory:适用于生产环境或冷启动项目。持续积累新轨迹,通过独立抽样或 LLM Judge 进行门控评估。

两种模式共用同一套 .evoontology/ workspace 和版本管理体系,无缝切换。

相关导航