NVIDIA开源Auto Ontology：AI查数快90%，README却没给准确率

老板问AI代理：上季度收入多少？3秒后，一个干净数字，一张漂亮图表。问题是它用错了revenue列。没人发现。

NVIDIA开源的Auto Ontology就冲着这个场景去。它把自己放在AI代理和数据库之间，做一层上下文：告诉代理数据在哪、每个字段什么意思、某个问题该不该用这个字段。README里有一句话很直白：“一个更快的收入指标如果数字错了就毫无价值。”

它怎么跑：

• Discover：读数据库元数据，草拟一份本体，把“active customer”这类业务词映射出来。
• Ground：代理用这些业务词，而不是从原始表名里猜。
• Validate：用认证过的定义检查生成的SQL。
• Expose：通过MCP、CLI或API把上下文给代理。
• Learn：认证后的修正回写到本体里。

对用户：问一个问题，拿到答案、它跑过的SQL和返回的行。可以检查过程，不必只信结果。对构建者：Apache 2.0，Docker Compose或Helm部署，支持Databricks、Postgres、Snowflake和DuckDB。默认用NVIDIA Nemotron模型，也接受任何OpenAI兼容端点。MCP server有9个只读工具，故意没有浏览原始表的工具，代理必须走业务术语。

它站在已有工作旁边。Cube和dbt MetricFlow是手写语义层；Wren AI是面向AI代理的开源语义层；Snowflake的Semantic View Autopilot也用AI草拟语义模型，但只服务Snowflake。Auto Ontology的差别是开源、跨四个数据库、面向代理通过MCP。

README里更值得看的是那些不太好看的细节：

• “90% faster”是NVIDIA自己的测试，没有公布基线。
• 没公布准确率分数。NVIDIA带了eval harness，BIRD 1,534个问题，但没有结果。
• 那个harness用Claude Opus 4.8测过，不是Nemotron。
• 不配HashiCorp Vault时，数据库密码在Postgres里明文存储。README自己写了。
• 项目还年轻，素材里提到约750 GitHub stars，而且NVIDIA不接受外部贡献。

评论区比发布稿更有意思。有人问：没有类、层级、逻辑约束和推理，这算ontology吗？有人把MCP当答案，作者回复MCP是连接方式，不负责在你的三列revenue里选对一列。Auto Ontology在连接的另一端，持有业务词和认证SQL。

有网友给了一个落地前的小动作：列一张term×表×业务规则的词表，revenue要区分net、deferred、gross，再拿已知答案做验证查询，核对生成的SQL有没有连到正确的fact表。先上词表和验证集，再把Auto Ontology装到代理前面。

另一个建议是直接用数据库的COMMENT ON COLUMN写字段说明。作者回复，注释是最便宜的改进，任何读schema的代理都能免费拿到。但注释描述单列。它告诉不了代理，“orders last quarter”该用dt还是订单日期。贵的错误常常是哪个问题该用哪一列。

还有人建议拿自己数据里20个已知答案的问题，分别在有语义层和没语义层时测。作者补充，还要算团队认证本体花的时间。财务改一次定义后再跑同样20个问题，那里最容易坏。没公布准确率分数，也让人想先测eval harness。

更大的一点：写SQL本身没那么难。难的是对词的含义达成一致。Auto Ontology把这个问题摆到台面上，也暴露了新的依赖：本体草拟错了，代理会稳定地用错列，结果看起来干净，没人发现。上线前，词表和验证集可能比多一个代理工具更值钱。

GitHub: https://github.com/NVIDIA/auto-ontology
Eval harness: https://github.com/NVIDIA/auto-ontology-eval
MCP docs: https://github.com/NVIDIA/auto-ontology/blob/main/docs/mcp.md
NVIDIA page: https://developer.nvidia.com/topic/ai/agent-knowledge-foundation
MarkTechPost: https://www.marktechpost.com/2026/11/01/nvidia-auto-ontology-open-source-semantic-layer-ai-agents/