一句话讲清：Auto Ontology 是 NVIDIA 开源的 Python 框架，它给企业数据之上建一层“语义层”，让 AI 智能体查数据时先理解业务含义、再生成并校验 SQL，而不是凭感觉拼查询。
为什么它值得关注？做数据问答的团队都遇到过同一个问题：智能体回答得很快，但数字未必对。“营收”在不同系统里口径不同、表结构又复杂，模型直接猜表、猜字段、猜连接关系，出错几乎是必然的。Auto Ontology 的思路是先把“数据是什么意思”这件事确定下来：从企业元数据生成本体（Ontology），把业务术语、口径和表间关系整理成智能体可用的知识图谱，再让智能体在这个可信的上下文里提问和查数。
它的核心亮点有四点。第一，生成与统一定义：从源数据库的元数据出发，抽取术语并映射到具体列，推断表间连接关系，还能把不同系统里不一致的指标定义对齐起来；同时支持导入已有的语义模型。第二，可验证的问答：问题先被解析为业务术语，再生成 SQL，执行前还会校验过滤值和查询本身，修不好的就先说“答不了”，而不是硬编一个答案；每次回答都会附带 SQL 和推导步骤，方便人工复核。第三，面向智能体的三种接入方式：MCP 服务器、Agent Skills 和 REST API，智能体可以直接用只读工具查术语、查可答性、提问题。第四，配套完整：有 Web 界面可以聊天、看数据目录和分析结果，支持 Docker Compose 本地部署或 Helm 部署到 Kubernetes，认证与权限管理也包含在内。
它适合谁？最适合三类人：一是做企业数据问答、Text-to-SQL 或 AI 数据分析的工程师；二是数据平台、数仓和 BI 团队，想给智能体一套统一、可复核的指标口径；三是已经在用 Agent / MCP 做内部工具的团队，想把“智能体能查什么、怎么算”管起来。对只是想简单问问公开数据的个人用户来说，它偏重，更适合先看演示和文档。
怎么上手？按 README 的 Quickstart，先准备 Docker（含 Compose v2）、uv，以及一个 NVIDIA API 密钥，然后克隆仓库并复制 .env.example 为 .env，填好模型 API 密钥、数据库密码等配置；接着用 Docker Compose 启动 Postgres 并导入微软示例数据库 Wide World Importers，再启动其余服务，打开 http://localhost:3000 登录后，在“设置 → 语义编译”中开启语义编译，等提示编译完成，就可以在聊天界面提问了。README 给的示例问题是问某款产品在宾夕法尼亚州 2015 年 6 月的营收，回答会给出金额、SQL 和推导步骤。如果已有自己的数据库，可以在“设置 → 连接”里接入，README 列出的源包括 PostgreSQL、MySQL、Snowflake、ClickHouse、DuckDB、SQLite 等十种引擎。
注意事项也要说清楚。第一，这不是“装上就能全自动”的工具：生成的本体只是初稿，README 明确建议人工测试、修正并“认证”术语、描述和 SQL 口径，认证后才可信。第二，安全边界要留心：后端与数据摄入服务的端口应放在私有网络，不要直接暴露；预测功能需要另外配置 KumoRFM，开启前要先评估它会上传哪些表数据。第三，项目目前不接受外部 Pull Request，集成需求和 Bug 建议走 Issue；同时它依赖 NVIDIA NIM 模型端点，部署前要确认模型与密钥的可用性与成本。最后，README 里只给了评测方法、没有直接给出 Text-to-SQL 准确率成绩，选型时不要只看热度，最好用自己的真实问题跑一遍再决定。
一句话总结：Auto Ontology 不是又一个聊天机器人，它想解决的是更底层的问题——让智能体在查企业数据之前，先搞清楚每个数字到底是什么意思。对数据问答“答得对”比“答得快”更重要的团队，这个项目值得收藏和试用。
注：本文核查时该仓库总 Star 为 5148；当日增量因抓取的 Trending 副本未显示，故本文不宣称当日增量。
