英伟达开源语义层库，为智能体SQL提供依据

NVIDIA 发布的 Auto Ontology，想解决的是 AI 查数里一个容易被忽略的问题：SQL 能执行，不代表算出来的就是业务要的数。它从企业元数据生成语义层，让 Agent 依据经过认证的指标、实体和关系查询数据库。

这套开源方案提供了 MCP 接口、部署工具和评测框架，但效果还需要打个问号。NVIDIA 自报本体创建时间缩短 90%，目前却没有公开 text-to-SQL 准确率。对准备做企业数据问答的团队，它值得研究，收益需要自己验证。

SQL 写对了，为什么业务数字还会错

假设用户问收入，数据库里可能同时存在订单金额、实付金额和退款金额。知道表名与字段类型，还不足以判断该用哪一个。Auto Ontology 试图补上这层业务含义。

它位于 Agent 和数据仓库之间，说明数据在哪里、字段是什么意思、应该怎样使用，以及来自哪里。这里的本体（Ontology），可以理解为把业务概念及其关系整理成机器能查询的结构。

它承担五项工作：从元数据生成本体并连接已有语义模型；提供可信的指标、实体与关系；依据认证定义和数据血缘检查查询；通过 MCP、CLI、API 提供上下文；把经过认证的修正写回本体。

自动生成的是业务定义的起点，业务专家仍要测试、修订和认证。

因此，它并没有消除治理工作。字段名含糊、指标口径冲突时，生成一个结构完整的目录，并不等于获得了正确答案。

Agent 能查哪些信息，系统又怎样接入

Auto Ontology 采用 Apache 2.0 许可证，核心栈有 4 个服务：Next.js 16 前端在端口 3000 提供界面和认证；FastAPI 配合 LangChain，在端口 3001 处理聊天、自然语言转 SQL 和目录 API；摄取 worker 在端口 3002 写入嵌入向量；Postgres 配合 pgvector 存储目录、本体和向量。

数据源支持 Databricks、Postgres、Snowflake、DuckDB。默认 LLM 是 nvidia/nemotron-3-nano-30b-a3b，嵌入和重排也使用 Nemotron 模型。推理、非推理、嵌入、重排分别配置 endpoint、key、model 三项参数，并支持任意 OpenAI-compatible endpoint，因此可以替换默认模型。

MCP 文档列出 9 个只读工具。ask_question 将答案、SQL、数据行作为独立字段返回，最多返回 100 行；check_readiness 检查语义层是否已编译，以及数据库连接是否可用。

这里有一个明确的设计选择：MCP 不提供浏览原始 schema 的工具，Agent 要通过语义层访问数据。

这样能约束查询路径，但如果语义层漏掉了业务概念，Agent 也可能缺少绕过去探索的入口。底层 OpenAPI 规范另有 87 个操作，不能把这个数量当成 MCP 工具数。登录通过 OAuth，每次调用携带当前用户权限。

本地填好 .env 后，执行 docker compose up -d --build 启动；Kubernetes 部署提供 Helm chart 和 DEPLOYMENT.md，后端也有 NGC 容器。推理可以调用托管 NVIDIA NIM endpoints，或使用自托管 NIMs；默认模型需要来自 build.nvidia.com 的 NVIDIA API key。

90% 的提速，和查数准确率是两回事

NVIDIA 自报，在内部测试中，本体创建时间缩短 90%。这个数字回答的是构建效率，不能用来证明 SQL 更准确，原文也没有给出足以复核该提速的测试细节。

准确率方面，NVIDIA 提供独立的 auto-ontology-eval。它在 NeMo Gym 中比较两组：只拿 schema 的 LLM，以及获得本体上下文的 Agent。评分采用确定性的执行结果匹配，不依赖 LLM 裁判，判断依据更容易复核。

随附数据包括 BIRD Dev 的 1,534 个问题、11 个数据库，Mini-Dev 的 500 个问题，FDABench-Lite 的 169 个问题，以及 BEAVER 默认抽样的 100 个问题。但公开 text-to-SQL 准确率成绩仍是 0 份：有评测框架，没有结果。

评测还存在两个解释边界。可选的少样本示例和字段取值提示，只提供给本体组；开启后测出的差距，包含额外输入的贡献，不能全归给语义层。仓库已测试的配置，则让两组都通过 NVIDIA inference gateway 调用 Claude，并非默认 Nemotron 模型。

我的判断

我认可它优先解决业务定义的方向。企业查数经常卡在口径，而不是 SQL 语法。将认证、血缘、权限和修正流程放进上下文层，比只向提示词塞入表结构更完整。

但「工程完整」和「效果已验证」需要分开。原文没有公开准确率，也没有与其他语义层的对照实验，目前不足以判断它是否更准、更省钱。

替代方案的差别主要在维护方式。Wren AI 使用 Agent 辅助生成、放在 Git 中的上下文文件，提供 MCP、CLI、SDKs，支持 22+ 数据源；Cube Core 用代码定义，提供 SQL、REST、GraphQL API；dbt MetricFlow 在 dbt 项目中用代码定义，通过 Python library 和 CLI 使用。

许可证也需分别看：Wren AI 是 Apache 2.0 核心的 open core；Cube Core 后端为 Apache 2.0、客户端为 MIT；dbt MetricFlow 从 v0.209.0+ 使用 Apache 2.0。

Auto Ontology 的特色是从元数据生成，再交给业务认证。如果团队已有成熟的 dbt 指标定义，原文不足以证明重建一层更划算；如果定义散落、人工整理成本高，它的生成流程更值得试验。最终仍取决于谁维护口径，以及变更后如何验证。

能拿来做什么

• 做企业数据问答前，先整理一组真实业务问题及标准答案，运行 auto-ontology-eval，分别记录是否启用少样本示例和取值提示，避免混淆收益来源。
• 开发查数前端时，可以利用 ask_question 分开的答案、SQL 和数据行展示结果依据，同时按最多 100 行处理结果展示。
• 给现有 Agent 接入 MCP 时，先用 check_readiness 检查语义层与连接，再验证当前用户权限下能查询哪些数据。
• 已有 dbt 或代码化指标体系的团队，先检查现有定义能否复用，再决定是否引入自动生成和认证流程，避免出现两套业务口径。