NVIDIA 给 text-to-SQL 补了一层本体，但认证的人听谁的？

text-to-SQL 最安静的错误，是 SQL 能跑，数字不对。数据库里有 extendedprice 这样的列，agent 得猜它是不是收入。同一个公司里，两个系统对 revenue 的定义可能不一样。NVIDIA 开源了 Auto Ontology，想先把这层业务含义补上，再让 agent 写查询。

Akshay Pachaar 在推文里把发布写成 fixed text-to-SQL 的最大问题。GitHub 文档的措辞更克制，写的是 reliability gates agentic analytics：一个收入指标回答得再快，数字错了就一文不值。这个差别值得记住。产品解决的是可靠性入口，不是替公司裁决业务定义。

它到底存了什么

Auto Ontology 把 ontology 存在 Postgres，embedding 进 pgvector。里面有三类定义：

• terms：Customer、Order、Revenue 这类业务概念，带描述和同义词，映射到具体列。
• SQL attributes：审核过的 SQL 表达式，比如 margin 或 rolling total。agent 复用这些表达式，保证同一个指标每次算法一致。
• relationships：表之间怎么 join，包括桥表，从键和数据本身推断。

生成和认证

ingestion 服务先读源库，profile 列，采样值；逐表抽 terms，映射到列；推断 join 和桥表；从历史查询里挖 SQL attributes；写出第一版 ontology。人在 UI 或 API 里改描述、改表达式、认证。NVIDIA 的 Wide World Importers 示例里，一次编译产出 31 个 terms。选中 Order 能看到描述、相关 terms、映射列和 SQL attributes。

查询时发生什么

agent 先把问题分类，抽实体；用 embedding 找候选 terms、列、SQL attributes；写 SQL；拿真实数据检查过滤值；失败就修；执行后返回答案、SQL 和步骤。数据不支持的问题会明说。demo 里问广告花费，销售库没有广告数据，agent 回：我能找这个产品的收入，但没有广告支出，算不了 ROAS，要不要改成 2015 年 6 月收入，或者连接另一个数据源。这个行为比多写对几条 SQL 更有用。编一个数字很容易，承认没数据很难。

架构上，ingestion 服务编译 ontology，agent 通过 MCP、CLI、REST API 接进来。支持十种引擎，包括 Postgres、Snowflake、Databricks、DuckDB；默认走 Nemotron，也能配 OpenAI 兼容端点；许可证 Apache 2.0。GitHub 目前不接受外部 PR，集成请求和 bug 可以开 issue。仓库：https://github.com/NVIDIA/auto-ontology

这套 schema 前置的思路不新。Akshay Pachaar 在另一篇文章里写过 agent memory 的同类问题。向量库把事实存成 chunk，按相似度检索；查询一旦要跨 chunk 连接事实就散。知识图谱用节点和边做遍历，但多数框架把抽取阶段交给 LLM，实体类型、关系标签、属性都由模型自己定，结果很泛。Zep 的做法是用 Pydantic 定义 EntityModel 和 EdgeModel，告诉抽取模型域里有哪些实体、哪些关系、每个类型有哪些字段，还限制 10 个实体类型、10 个边类型、10 个字段。Akshay 的原话是，schema 定义有效记忆的空间。Auto Ontology 做的是同一件事，只不过对象从 agent memory 换成了企业数据库，schema 从元数据起草，人认证。参考：http://x.com/i/article/2058894488295378944

几个不好绕开的问题

自动草稿省的是起草时间，认证省不了。推文回复里几个问题比发布文案更接近落地。

谁裁定定义。Alpha Batcher 问，两个团队都把自己 revenue 列认证成对的，谁说了算。Auto Ontology 的 certify 是人工动作，产品不替组织解决定义权。认证人、版本、失效规则要在流程里写清楚。

历史查询里的错误会不会被固化。Caleb Jimmy 和 Asmir 都问，旧查询里的 revenue 定义如果本来就错，挖历史 SQL attributes 是不是把错误规模化认证。认证界面如果能看到来源，至少能审；看不到就麻烦。

财务改口径。Benjamin 说，认证一次后 finance 改 revenue 算法，agent 还按旧定义自信回答。需要版本和重新认证机制，不然认证会变成一次性合影。

join 基数。Ruslan、Huilong、Paul Salmon 都提到，3 个订单加 2 个支持工单按 customer_id join 会出 6 行，SUM(order_total) 翻倍。SQL 合法，数字错。认证测试要放退款订单、多行订单、一对多 join。Qyravex 还指出 TPC-H 里 revenue 是 extendedprice * (1 - discount)，直接把 revenue 映射到列会错。认证步骤得能审公式，不只审列映射。

这些不是让 Auto Ontology 减分。它们说明它把问题从“agent 会不会写 SQL”挪到了“公司有没有人能认证业务定义”。前者靠模型进步，后者靠组织。NVIDIA 的发布能加速前一步，后一步还得人背。

要试的话，别一上来全库铺开。挑一个高争议指标，比如 revenue 或 active customer，把术语、SQL 表达式、join 路径、认证人写清楚，再让 agent 跑。测试数据里放一条退款订单和一条多行订单，专门看 join 后会不会重复计数。支持 MCP，可以接到 Cursor 或 Claude Desktop，也可以走 REST。默认模型能换，许可证宽松。仓库在 https://github.com/NVIDIA/auto-ontology

自动 ontology 值钱的地方，可能不是自动，是把散落在各团队 SQL 里的口头定义变成可讨论、可认证、可版本化的对象。至于谁说了算，工具回答不了。