NVIDIA/auto-ontology

这是一个需要自托管的完整应用栈，用来让 Agent 读懂一个或多个关系型数据库，而不是可以直接嵌入代码的 text-to-SQL 库。适合已经让 Agent 回答营收类问题、但总在纠正错误 join 或口径冲突的团队。

解决什么问题

分析师想从数仓里要一个营收数字。现在的做法是把表结构和字段说明贴进提示词，看着 Agent 选中一张看似合理实则错误的表，再人工检查生成的 SQL。Auto Ontology 把这份上下文搬进一个从企业元数据构建的目录，查询生成从有记录的库表、含义和口径出发，而不是从原始 DDL 出发。最终产出是一个可见的数据目录，以及一个面向 Agent、能返回与目录条目关联的 SQL 的上下文层。

有什么不同

核心机制是存放在 Postgres 里、与所描述目录同库的 ontology 层。项目会协调不同系统中的定义，并通过 MCP、CLI 和 API 暴露出来，已有的 Agent 框架可以直接消费同一份上下文，不必再把 schema 笔记塞进提示词。自然语言问题会被翻译成 SQL 并在已连接的数据库上执行，聊天、实体抽取、向量化和重排都由 NVIDIA NIM 端点承担。由于入库和查询必须使用同一个 embedding 模型，日后换模型意味着要重做文档索引方式，而不只是改一个配置。

代价是架构偏重。这是一个多服务应用：Next.js 前端（含 Better Auth 和 Prisma）、基于 LangChain 的 FastAPI 后端、Postgres、pgAdmin、摄取服务，以及一次性的数据库 schema 迁移任务。你能得到 UI、基于角色的访问控制和部署编排，但也要接管凭据、数据库迁移和多个容器的生命周期。README 把自己定位为补充客户已有的语义模型，因此更合理的用法是在现有定义之上加一层，而不是替代它们。

谁值得试

适合：拥有三个以上关系型数据源、且错误指标会带来实际代价的分析团队。当多人和多个 Agent 需要共享同一套表和指标解释时，目录、鉴权和 MCP 接口才有意义。如果你已经在用 NVIDIA NIM，或愿意自托管这些模型，并想要一个端到端示例而不是零散组件，也值得试。

不适合：一个人对着单个 DuckDB 文件问问题的小项目。容器栈和环境变量配置的负担超过收益。想找一个可嵌入现有服务的轻量 Python 库的人同样不适合，文档给出的路径就是完整应用。没有 NVIDIA API key 或自托管 NIM 部署的团队，应先确认模型配置实际要求什么，再把它算作可选方案。

使用条件与边界

需要 Docker Compose v2 或 Kubernetes 集群、用于 NIM 的 NVIDIA API key，以及 Databricks、Postgres、Snowflake 或 DuckDB 数据源的连接信息。AUTH_SECRET 和 APP_URL 是必填项，不设置会导致每个页面都报 Better Auth 的默认密钥错误。安装步骤见项目 README和部署说明，完整变量列表在环境变量模板。

日常维护比初次安装更关键。通过 UI 添加的连接，在没有配置 Vault 时会把凭据以明文存进 Postgres；配置 Vault 后，数据库名就是查找键，没有单独的引用字段，因此重命名数据库会影响凭据的定位方式。入库与查询使用一致的 embedding 模型也是一条持续要守的约束。项目采用 Apache-2.0，但明确不接受外部贡献，修复依赖 NVIDIA。基准测试指引指向独立的SQL 评测仓库；本 README 没有给出自身的准确率数字，在你的 schema 上效果如何需要自行评估。

HotRepo 点评

唯一有日期的信号是 2026-10-27 的一次日榜记录：240 stars，当日 +75。仅一个上榜日无法判断热度是否持续，也看不出趋势。如果你需要一套受治理的语义层来支撑 Agent 写 SQL，并且能运维这套栈，可以试；但先确认 MCP 和 API 路径能否不依赖 Web UI 直接读取目录，这决定了它能否接入你现有的 Agent 框架。