Ontology（本体）Part 3：Ontology (OWL) 驱动的数据分析智能体设计与实战

顺势而为

发布于 2026-09-23 23:46:27

560

概述

企业数据分析场景下，用户的业务语言和物理表列名之间存在天然落差。用户会问"高价值订单有多少""客户消费排名"，但物理表里对应的可能是 TotalDue、OrderQty 这类缩写列名。只把物理 schema 喂给大模型，模型缺少业务含义，容易选错列或漏掉隐含的多跳关系；手写一张"业务词 → 列名"映射表，又难以表达关系、层级和正式业务定义。

本文系转载，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

上海同盟

1. 引言：为什么要给 Data Agent (text-to-sql) 加一层 Ontology

2. 背景知识速览
- 2.1 什么是 Ontology / OWL
- 2.2 什么是"推理"（Reasoning）与 HermiT
- 2.3 为什么选择 Owlready2，而不是图数据库或 SPARQL
- 2.4 本项目 OWL 文件里的关键约定
- 2.5 本项目技术栈总览

3. 架构总览：Multi Agent 相互交互调用及Workflow.
- 3.1 Data Agent 整体架构图
- 3.2 两种模式的整体流程
- 3.3 分层设计原则：每一层只对一种"事实"负责
- 3.4 置信度阈值机制：什么时候该"相信"确定性结果

4. 深入 OntologyAgent：语义检索层是如何设计的
- 4.1 设计哲学：属性优先（property-first）、角色中立（role-neutral）
- 4.2 只读查询工具集
- 4.3 两级 Agent 设计：完整工具 Agent + 轻量 Router Agent
- 4.4 确定性组合检索：把常见问题变成代码路径
- 4.5 问题驱动的子图检索
- 4.6 治理 Skill 快速通道：已知高频问题的旁路

5. 深入 MetadataAgent：物理验证层怎么设计
- 5.1 唯一职责：验证物理存在性，不做语义判断
- 5.2 两种运行模式
- 5.3 表摘要索引：为什么不对每次请求做全量拉表

6. 深入 DataInsightAgent：把两层证据变成 SQL
- 6.1 消费两条独立证据流而不互相坍缩
- 6.2 sql-planning Skill：把语义证据转成可执行查询计划
- 6.3 SQL 生成与作用域校验
- 6.4 有界恢复机制
- 6.5 结果诊断与降级说明
- 6.6 SQL 标识符纠正的安全边界

7. 横切关注点
- 7.1 请求级隔离
- 7.2 失败处理与可见降级

8. 可复用的设计原则总结

9. 典型问题查询分析结果展示及阐述
- 9.1 Ontology 开启
- 9.2 Ontology 关闭

10. 结语

附录

Ontology（本体）Part 3：Ontology (OWL) 驱动的数据分析智能体设计与实战

Ontology（本体）Part 3：Ontology (OWL) 驱动的数据分析智能体设计与实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐