NVIDIA 开源的 Auto Ontology 已在 GitHub 获得约 5,670 个 Star。它的判断很清楚：企业让 AI 查数据，最大的风险不是 SQL 跑不通，而是数字跑通却算错，因此需要在模型与数据库之间增加一层经过人工认证的业务语义。

这是什么

Auto Ontology 是连接企业数据与 AI Agent（能自主调用工具完成任务的软件代理）的“语义层”。语义层就是统一解释收入、活跃用户、客户等业务概念，明确字段映射、计算公式和表间关系。

项目采用“生成—认证—回答”流程：先从数据库元数据、查询记录中提取候选术语与 SQL，再由人员用真实问题测试、修正和认证。Agent 回答时会检索这些定义、检查查询，并附上 SQL 与依据；候选信息不足时，系统允许追问或明确表示无法回答。

它可通过 MCP（让 Agent 调用外部工具的开放连接方式）、REST API 或命令行接入，支持 PostgreSQL、MySQL、Snowflake、Databricks 等 10 类数据库。需要注意，项目目前没有标注稳定版本，且默认部署中的数据摄取接口缺少认证，公开服务前必须补齐安全配置。

行业怎么看

我们认为，Auto Ontology 抓住了一个容易被忽略的问题：大模型能力越强，企业越容易把错误结果包装成可信答案。企业数据助手的竞争重点，正在从“会不会写 SQL”转向“是否理解业务口径、能否说明依据”。

这也是它比通用 Text-to-SQL（把自然语言转换为数据库查询）工具更务实的地方：把人工确认嵌入流程，而不是假设模型能从字段名称自动推断一切。

但风险同样明确。语义层如果维护不当，会把过期口径固化；认证质量则依赖业务专家持续参与。开源仓库不接受外部 Pull Request，README 又未给出稳定版本，短期更适合技术团队验证，而非直接替代成熟企业语义模型。

对普通人的影响

对企业 IT：已有数据仓库和语义层的团队可将其作为补充，重点评估术语认证、权限隔离和运维成本，而不是重复建设另一套口径。

对个人职场：销售、财务和运营人员使用 AI 查数时会更常看到 SQL、计算步骤及“信息不足”提示，但能否说“不会”，仍取决于企业是否愿意维护可靠定义。

对消费市场：未来 AI 助手给出的经营数字会更强调可追溯，但同一问题在不同公司的口径仍可能不同，“附答案”不等于“答案可横向比较”。