---
title: "英伟达 Auto Ontology 深度解读：给数据智能体装上“企业词典”，让 AI 写的 SQL 算对数"
date: 2026-11-05
description: "英伟达开源 Auto Ontology（Apache 2.0），从数据库元数据自动生成业务本体，经人工认证后供智能体通过 MCP、CLI、API 调用，以减少问数场景的错误答案。本文拆解其生成、认证、作答三阶段、九个只读 MCP 工具、安全边界与 PII 机制，并指出尚无公开准确率、样本数据外发等落地风险。"
tags: ["NVIDIA", "Auto Ontology", "语义层", "本体", "Text-to-SQL", "MCP", "数据智能体", "数据治理"]
schema_type: Article
references:
  - title: "NVIDIA/auto-ontology（GitHub 仓库与 README）"
    url: "https://github.com/NVIDIA/auto-ontology"
    source: "GitHub"
  - title: "NVIDIA Agent Toolkit Expands, Grounding Enterprise Agents in Company Data"
    url: "https://blogs.nvidia.com/blog/enterprise-platforms-agent-toolkit/"
    source: "NVIDIA Blog，2026-10-21"
  - title: "Auto-Ontology Eval（评测仓库）"
    url: "https://github.com/NVIDIA/ontology-sql-eval"
    source: "GitHub"
---

**是什么（来源1）：英伟达开源的 Python 框架 Auto Ontology，在智能体和数据仓库之间加一层“上下文层”，告诉智能体数据在哪、是什么意思、该不该用、怎么用、从哪来。**

**怎么做（来源1）：先从数据库元数据自动生成本体草稿，再由人工测试、修正、认证，最后智能体依据认证过的定义写 SQL，并随答案返回 SQL 和推理步骤。**

**背景（来源2）：2026 年 10 月 21 日 GTC 柏林大会上，作为英伟达“Agent Knowledge Foundation”的新组件发布；GitHub 仓库约 4,600 星，采用 Apache 2.0 许可。**

**亮点（来源1）：支持 10 种数据库引擎；提供 9 个只读 MCP 工具；问题超出数据范围时会先判断“能不能答”，而不是硬编一个数字。**

**要冷静看待的地方（本文分析）：仓库尚未公布准确率数字；默认用英伟达托管模型，编译时的列画像与样本值会发往外部推理端点；PII 识别默认关闭；不接受外部代码贡献。**

---

> 写作说明：标注“来源N”的为项目仓库、代码或官方资料；“本文分析”为作者推论。代码观察基于 2026 年 11 月 4 日的仓库版本（来源1）。

## 一、它要解决什么问题

### 1. 问数智能体的老毛病

仓库开宗明义：智能体能检索文档、能查数据库，但**可靠性才是数据分析智能体的门槛——收入数字答得再快，算错了也一文不值**（来源1）。

本文分析：企业里“收入”可能有含税、不含税、已开票、已回款几种口径；客户表可能在三个系统各有一份；同一张表的字段名可能是缩写。只给大模型看表结构（schema），它很容易选错表、连错关系、用错口径，而且错得“看起来很合理”。

### 2. Auto Ontology 的定位

它宣称承担五项工作（来源1）：

| 工作 | 含义 |
|---|---|
| 发现（Discover） | 从元数据生成企业本体；接入已有本体和语义模型；构建面向 AI 的知识图谱 |
| 落地（Ground） | 给智能体可信的指标、实体、关系定义；调和不同系统间的定义冲突 |
| 校验（Validate） | 依据认证定义和数据血缘检查生成的查询；每个答案附带来源 |
| 暴露（Expose） | 通过 MCP、命令行和 API 提供给任何智能体框架 |
| 学习（Learn） | 把认证过的修正和使用情况回流到本体，让共享上下文越用越好 |

仓库强调，它是对企业已有语义模型的**补充**，不是替代（来源1）。它兼容 Apache Ossie 语义模型交换标准，可以导入、导出 Ossie YAML（来源1）。

## 二、本体里装的是什么

本体包含三类定义（来源1）：

1. **术语（Terms）**：业务概念，如“客户”“发票明细”，每个都带描述和同义词，并映射到具体的列；
2. **SQL 属性（SQL attributes）**：挂在术语下、经过审核的 SQL 表达式，如毛利率、滚动合计。智能体复用这些表达式，保证同一指标每次都按同一口径计算；
3. **关系（Relationships）**：表与表之间如何连接，包括桥接表，根据主外键和数据本身推断。

本文分析：第二类最关键。传统 Text-to-SQL 每次让模型“现场发明”指标公式；SQL 属性把公式固化下来，等于把“口径”从模型的随机发挥变成了可审计的资产。

## 三、工作流程：生成 → 认证 → 作答

### 1. 生成（自动）

1. 读取数据源：抽取表结构、对列做画像、采样取值，写入目录；
2. 命名实体：逐表抽取术语并映射到列；
3. 解析关系：推断表间连接和桥接表，并根据历史查询推荐 SQL 属性；
4. 写入本体：术语、关系、SQL 属性存入 Postgres，向量存入 pgvector 供检索。

（来源1）

在示例数据库 Wide World Importers（微软的销售样例库）上，一次编译生成了 31 个术语（来源1）。

### 2. 认证（人工）

1. 用真实问题在聊天界面测试，或通过 MCP 调用 `check_answerable`、`ask_question`；
2. 在界面或 API 中修正术语、描述和 SQL 属性；
3. 确认无误后，对名称、描述和 SQL 属性进行认证。

（来源1）

本文分析：**“自动生成”只是草稿，“人工认证”才是可信的来源**。这是 Auto Ontology 与“一键全自动”宣传最大的区别，也意味着落地成本的大头仍在业务专家。

### 3. 作答（智能体）

1. 判断问题意图，抽取问题提到的实体；
2. 通过向量检索找候选术语、列和 SQL 属性；
3. 基于候选写 SQL；
4. 拿过滤值和查询去数据库核对，检查不通过就修复 SQL；
5. 执行查询，返回答案、SQL 和推理步骤。

（来源1）

候选不足以支撑查询时，智能体会报告“这份数据答不了这个问题”；预测类问题在配置后转给 KumoRFM（来源1）。

### 4. 示例：答得出和答不出

**答得出**：问“2015 年 6 月宾夕法尼亚州寿司卷造型 U 盘的收入是多少”，智能体把“收入”“产品”“州”解析为本体术语，沿“发票明细 → 发票 → 客户 → 城市 → 州”的关系连接 6 张表，返回 588.80 美元、来自 3 条发票明细，并附上完整 SQL（来源1）。

**答不出**：问“这款 U 盘 2015 年 6 月的广告投资回报率”，智能体先调用 `check_answerable`，覆盖率 0.5，没有任何术语对应“广告支出”，于是反问用户：要不要改看收入，或者广告支出是否在另一个数据源里（来源1）。

本文分析：第二个例子比第一个更重要。对企业来说，**“知道自己答不了”比“答得快”更值钱**，这正是幻觉数字最常见的来源。

## 四、技术架构

| 组件 | 技术 | 作用 | 端口 |
|---|---|---|---|
| 前端 | Next.js、Better Auth、Prisma | 网页界面、身份认证、对外 API 网关 | 3000 |
| 后端 | FastAPI（Python 3.12+）、LangChain | Text-to-SQL 智能体、目录、本体 API | 3001 |
| 摄取服务 | FastAPI | 摄取与语义编译 | 3002 |
| MCP 服务 | FastMCP | 基于公开 API 的只读智能体工具 | 3003 |
| 数据库 | PostgreSQL 17 + pgvector | 目录、本体、应用数据、向量库 | 5432 |
| HashiCorp Vault | 可选 | 存储数据库连接凭证 | — |

（来源1）

部署方式：本地 Docker Compose，或 Kubernetes Helm 图表（来源1）。仓库 Python 代码约 12.9 万行，其中测试文件 169 个（来源1，本文统计）。

### 1. 模型分工

| 角色 | 默认模型 | 负责 |
|---|---|---|
| 推理（REASONING） | nemotron-3.5-lightning-30b-a3b | 构建本体、写 SQL 与解释、判断可答性 |
| 非推理（NON_REASONING） | nemotron-3.5-lightning-30b-a3b | 意图识别、实体抽取、候选筛选、SQL 检查与修复 |
| 向量（EMBED） | nemotron-3.5-embed-1b | 为表、列、术语、SQL 属性建索引并匹配问题 |
| 重排（RERANK） | nemotron-3.5-rerank-8b | 编译桥接表 SQL 属性时给候选表排序 |

（来源1）

任何角色都可换成自托管 NIM 或兼容 OpenAI 的端点，但要求模型支持结构化输出，且摄取和查询必须用同一个向量模型（来源1）。

### 2. 支持的数据源

PostgreSQL、MySQL、Databricks、Snowflake、ClickHouse、Trino、Apache Kyuubi、HeavyDB、DuckDB、SQLite，共 10 种（来源1）。

### 3. 三种接入方式

**MCP 服务**：9 个只读工具，每个用户单独登录，每次调用都以该用户权限运行（来源1）。

| 用途 | 工具 |
|---|---|
| 就绪检查 | `check_readiness` |
| 术语查询 | `search_terms`、`get_term`、`get_term_columns`、`get_term_sql_attributes`、`get_sql_attribute`、`describe_table` |
| 可答性 | `check_answerable` |
| 提问 | `ask_question`：返回答案、SQL 和数据行 |

**智能体技能**：提供安装、管理、查询三套技能，教编程智能体操作 Auto Ontology（来源1）。

**REST API**：`POST /api/chat/completions`，以服务器推送事件流返回结果（来源1）。

## 五、安全与治理：代码里能看到什么

### 1. 只读防护

代码中的探测执行器只放行单条 `SELECT` 或 `WITH` 语句：拒绝含内部分号的多语句，并用正则拦截 insert、update、delete、drop、alter、create、truncate、grant 等关键词，没有 LIMIT 时自动补上（来源1，`db_probe/executor.py`）。

本文分析：这是“关键词黑名单”式防护，能挡住明显的写操作，但正则也会误伤合法查询（例如用到 `replace()` 函数的 SELECT 会被拒），且无法替代数据库层面的权限控制。**生产环境应给连接账号只授只读权限**，不能只靠应用层正则。

### 2. 内部端口不能暴露

仓库明确警告：3001 和 3002 端口必须放在私有网络。后端信任前端转发的 `x-auto-ontology-user-id` 请求头来识别用户，摄取服务的摄取、删除、重置、编译接口**本身没有认证**，所有客户端都应经过 3000 端口的网页应用（来源1）。

本文分析：这是一个典型的“网关信任”架构。部署时若误把 3001 暴露出去，任何人伪造请求头就能冒充任意用户。

### 3. PII 识别

- 采用“规则优先、大模型兜底”：先按列名、表名匹配高置信规则（如 customer_email），规则判断不了再交给大模型；
- 大模型提示词要求保守：信息不足或不确定时一律判为 PII；
- 识别结果会作为 PII 标签从列传播到由它生成的 SQL 属性上。

（来源1，`pii_detection/`）

需要注意：**PII 识别默认关闭**，必须在设置中手动开启，摄取时才会分类（来源1，`feature_flags.py`）。

### 4. 数据外发

- 生成阶段会对列做画像、采样取值，再交给推理模型构建本体（来源1）；
- 默认推理端点是英伟达托管的 API 目录（integrate.api.nvidia.com）（来源1）；
- 启用 KumoRFM 预测时，智能体会把已连接的表上传到 Kumo 托管服务，默认最多 20 张表，每表行数不设上限；仓库提醒先完成组织内的数据审查再开启（来源1）。

本文分析：对金融、医疗等受监管行业，**默认配置不能直接上生产**。至少要改用自托管模型、确认采样值的范围，并关闭或严格限制 KumoRFM。

## 六、效果到底如何

仓库 README 没有给出准确率数字，只把读者引向单独的评测仓库（来源1）。

评测仓库的设计值得肯定（来源3）：

- **有对照组**：同一模型回答同一批问题两次，对照组只给表结构，实验组由 Auto Ontology 智能体自行检索本体；
- **确定性评分**：执行两组 SQL 和标准 SQL，按各基准的官方规则比对结果，不用大模型当裁判；
- **数据集**：BIRD（开发集 1,534 题、迷你开发集 500 题）、BEAVER（100 题样本）、FDABench-Lite（169 题）、Wide World Importers（41 题）、多轮的 BIRD-Interact；
- **输出**：两组准确率差值，以及被本体“修好”和“改坏”的题目清单。

但截至本文写作时，评测仓库同样**没有公布任何结果数字**（来源3）。部分媒体报道中“本体构建时间缩短 90%”的说法，本文在官方仓库和英伟达博客中都没有找到出处，因此不予采信。

本文分析：评测方法是“自带尺子、自己量”，企业应该在自己的数据上跑一遍对照实验，而不是等官方数字。

## 七、优势与局限（本文分析）

### 优势

1. **把口径变成资产**：SQL 属性经认证后复用，同一指标每次算法一致；
2. **可解释**：每个答案附 SQL 和推理步骤，业务人员可以复核；
3. **会说“不知道”**：`check_answerable` 先判断覆盖率，减少幻觉数字；
4. **开放生态**：MCP、API、技能三种接入，兼容 Ossie 标准，模型可替换；
5. **工程化程度高**：完整的认证、权限、Vault 凭证、Helm 部署和大量测试，不是演示级原型。

### 局限

1. **没有公开准确率**：价值主张最核心的“少答错”，目前没有官方数字支撑；
2. **人工认证成本不低**：自动生成只是起点，业务专家逐条审核才是质量保证；
3. **只覆盖结构化数据**：本质仍是 Text-to-SQL，文档、邮件等非结构化知识不在范围内；
4. **默认绑定英伟达模型和托管端点**：虽可替换，但对结构化输出有要求，国产或私有模型的效果需要自测；
5. **社区参与受限**：不接受外部代码贡献，只接受问题反馈和集成申请（来源1）；
6. **应用层只读防护较粗**：正则黑名单需配合数据库只读账号。

## 八、与其他方案的关系（本文分析）

- **与传统语义层（如 dbt 语义层、LookML）**：传统语义层由人从零手写；Auto Ontology 先自动生成草稿，再人工认证，并原生面向智能体调用；
- **与 Palantir 本体**：英伟达博客提到，其供应链部门通过 Palantir Foundry、Ontology 和 AIP 使用 Agent Knowledge Foundation（来源2）。Auto Ontology 更像开源、轻量、聚焦 SQL 问数的版本；
- **与直接给大模型看表结构**：后者部署最快，但口径不稳定、无法说明来源；Auto Ontology 用前期认证成本换取答案的一致性和可审计性。

## 九、对企业（尤其是银行）的落地建议（本文分析）

1. **先选一个指标口径混乱、但问题高频的业务域试点**，例如对公存款日均余额或信用卡活跃客户数；
2. **网络与权限**：只暴露 3000 端口；数据库连接用只读账号，按数据域划分；凭证放 Vault；
3. **数据不出域**：推理、向量、重排全部改用行内自托管模型；评估编译阶段采样值是否涉及客户信息；不启用 KumoRFM 或经数据安全审批后再用；
4. **打开 PII 识别**，并把识别结果与行内数据分级分类标准对齐；
5. **把“认证”纳入数据治理流程**：指定指标负责人，SQL 属性变更走审批和版本记录；
6. **自己跑对照评测**：用行内真实问题集，比较“只给表结构”和“接入本体”两种方式的准确率，以及被修好和改坏的题目；
7. **把“答不了”当成正确行为**：上线考核不只看回答率，也看拒答是否恰当。

## 结语

Auto Ontology 的价值不在于又一个 Text-to-SQL 工具，而在于它把企业数据问答中最难的部分——“口径到底是什么”——变成了可以生成、审核、认证、复用的工程资产，并让智能体学会在数据不足时说“不知道”。它的短板同样清楚：还没有公开准确率，默认配置偏向英伟达托管服务，真正的质量仍取决于业务专家的认证投入。对企业来说，它值得认真试点，但应该在自己的数据上量出效果，再决定投入多少。

## 常见问题

Q: Auto Ontology 是全自动的吗？

A: 不是。它自动生成本体草稿，但需要人工用真实问题测试、修正并认证后，才算可信（来源1）。

Q: 它支持哪些数据库？

A: PostgreSQL、MySQL、Databricks、Snowflake、ClickHouse、Trino、Apache Kyuubi、HeavyDB、DuckDB、SQLite（来源1）。

Q: 能不能用自己的大模型？

A: 可以。每个模型角色都能配置为自托管 NIM 或任何兼容 OpenAI 的端点，但模型需支持结构化输出（来源1）。

Q: 它的准确率是多少？

A: 截至本文写作时，官方仓库和评测仓库都没有公布结果数字，只提供了带对照组的评测框架（来源1、来源3）。

## 事实来源

1. **GitHub 仓库（来源1）**：README、源代码、.env.example 与部署说明，2026 年 11 月 4 日版本。
2. **英伟达博客（来源2）**：2026 年 10 月 21 日 Agent Toolkit 扩展公告。
3. **评测仓库（来源3）**：Auto-Ontology Eval 的方法与数据集说明。

**本文推论部分（非来源表述）**：口径问题举例、各节“本文分析”、只读防护与网关风险评估、优势与局限、方案对比、银行落地建议、结语。

**本文不构成任何投资建议。**

*（内容由AI生成，仅供参考）*