英伟达 Auto Ontology 深度解读：给数据智能体装上“企业词典”，让 AI 写的 SQL 算对数

是什么（来源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）：

仓库强调，它是对企业已有语义模型的补充，不是替代（来源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）。

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

四、技术架构

（来源1）

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

1. 模型分工

（来源1）

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

2. 支持的数据源

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

3. 三种接入方式

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

智能体技能：提供安装、管理、查询三套技能，教编程智能体操作 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 工具，而在于它把企业数据问答中最难的部分——“口径到底是什么”——变成了可以生成、审核、认证、复用的工程资产，并让智能体学会在数据不足时说“不知道”。它的短板同样清楚：还没有公开准确率，默认配置偏向英伟达托管服务，真正的质量仍取决于业务专家的认证投入。对企业来说，它值得认真试点，但应该在自己的数据上量出效果，再决定投入多少。

事实来源

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

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

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

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