NVIDIA Auto Ontology：面向可靠智能体分析的开源语义层
NVIDIA Auto Ontology 是一个采用 Apache-2.0 许可的 Python 框架，它在企业数据之上构建一个基于图结构的语义本体层，使 LLM 和智能体工作流能够生成确定性的、经过验证的、带有溯源信息的 SQL 查询，而不是靠猜测。NVIDIA 将其作为开源仓库发布在 github.com/NVIDIA/auto-ontology，并在 Hacker News 上获得了 206 分和 70 条评论。
该仓库将自身的动机定位为可靠性而非速度：“智能体可以检索文档和查询数据库，但可靠性是智能体分析的门槛：如果数字是错误的，那么更快回答的收入指标毫无价值。”Auto Ontology 被定位为上下文层，为智能体回答以下问题：数据在哪里、它意味着什么、是否使用它、如何使用它、它来自哪里，以及什么是相似的。NVIDIA 表示，它补充而非取代客户已有的语义模型。
本体层解决了什么问题
核心主张是智能体需要经过认证的业务含义，而不仅仅是数据库访问权限。Auto Ontology 从现有的企业元数据构建其层，跨系统协调定义，并通过 MCP、CLI 和 HTTP API 将结果暴露给任何智能体框架。
仓库中列出了五项能力：
- 发现：从元数据生成企业本体，连接现有本体和语义模型，并构建面向 AI 的知识图谱。
- 落地：为指标、实体和关系提供可信的业务含义，并协调跨系统的不一致定义。
- 验证：根据经过认证的定义和谱系检查生成的查询，并为每个答案返回溯源信息。
- 暴露：通过 MCP、CLI 和 API 向任何智能体框架提供上下文。
- 学习：将经过认证的修正和用法反馈到本体中，使共享上下文随着每个问题而改进。
软件组件和默认端口
Auto Ontology 以多服务栈的形式交付。前端是一个 Next.js 16 应用程序（React 19、TypeScript、Tailwind CSS 4），使用 Better Auth 和 Prisma，在端口 3000 上提供 Web UI、身份验证和 API 网关。后端是运行在 Python 3.12+ 上的 FastAPI，使用 LangChain，在端口 3001 上处理聊天、自然语言到 SQL、目录和数据源 API。一个单独的 FastAPI 摄取工作器在端口 3002 上摄取表格数据并写入嵌入。带有 pgvector 的 Postgres 在端口 5432 上存储应用程序元数据、目录和本体以及向量存储。HashiCorp Vault 是可选的，在组件表中没有分配端口。
Web UI 涵盖聊天、分析、数据目录、分析和设置。部署支持通过 Kubernetes 的 Helm chart 或本地栈的 Docker Compose 进行。
推理通过 NVIDIA NIM 和模型三元组配置
Auto Ontology 使用 NVIDIA NIM 端点进行推理，可以是托管的 NVIDIA API 目录（integrate.api.nvidia.com）或自托管的 NIM。仓库中 .env.example 的默认值是：
- LLM：nvidia/nemotron-3-nano-30b-a3b
- 嵌入：nvidia/nemotron-3-embed-1b
- 重排序：nvidia/llama-nemotron-rerank-vl-1b-v2
每个模型角色由三个环境变量组成的三元组配置：PREFIX_ENDPOINT URL、PREFIX_API_KEY 和 PREFIX_MODEL。角色包括 DEFAULT_MODELS（所有其他角色回退的共享默认值）、REASONING（主要的聊天和 NL 到 SQL 模型）、NON_REASONING（用于实体提取的较轻量模型）、EMBED（文本嵌入模型，必须在摄取和查询之间匹配）和 RERANK（检索流程使用的重排序器）。任何未设置的字段都会回退到匹配的 DEFAULT_MODELS_ 字段，任何 *_API_KEY 也会回退到旧的 NVIDIA_API_KEY 变量以实现向后兼容。
部署前提条件
本地栈需要 Docker 和 Docker Compose v2、从 build.nvidia.com 获取的 nvapi-... 格式的 NVIDIA API 密钥，以及要查询的源数据库的连接详细信息。仓库中提到的受支持源系统是 Databricks、Postgres、Snowflake 和 DuckDB。
安装过程是克隆仓库，将 .env.example 复制为 .env 并填写值（如 Postgres 凭据、DEFAULT_MODELS_API_KEY 和 CONNECTION_STRINGS），然后运行 docker compose up -d --build。该构建会生成后端（auto_ontology）和前端（auto-ontology-frontend）镜像，启动 Postgres 和 pgAdmin，运行一次性的 frontend-migrate 任务来同步数据库模式，并启动应用程序。UI 在 http://localhost:3000 上提供，后端 API 在端口 3001 上，pgAdmin 在端口 5050 上。
仓库指出了两个配置陷阱。AUTH_SECRET 和 APP_URL 是必需的，没有它们，每个页面都会出现 Better Auth 的“默认密钥”错误。POSTGRES_PORT 只更改主机端的端口映射，因为容器始终通过内部网络端口访问 Postgres。它还记录了一个故障排除案例：重启后 UI 加载时没有左侧导航面板，因为浏览器持有过期的会话 cookie，这发生在 AUTH_SECRET 更改或数据库重置时；清除 localhost:3000 的站点数据或删除 better-auth.session_token cookie 可以解决此问题。
凭据存储默认为明文，除非配置了 Vault
这是仓库中操作上最重要的安全细节。通过 UI 添加的连接，除非配置了 Vault，否则其凭据以明文存储在 Postgres 中。没有 Vault 时，完整的连接对象（包括密码）会被 JSON 序列化并无加密地存储在目录的数据库行中。使用 Vault 时，凭据会写入 Vault，以数据库名称作为键，目录行不存储任何凭据，因为数据库名称本身就是查找键，没有单独的引用字段。
仅当 VAULT_ADDR、VAULT_NAMESPACE、VAULT_ROLE_ID 和 VAULT_SECRET_ID 全部设置时，Vault 才会启用；VAULT_AUTH_MOUNT 和 VAULT_KV_MOUNT 是可选的覆盖项。它默认关闭，部分配置会被忽略并发出警告，然后回退到明文存储。
连接定义的第二个来源是 CONNECTION_STRINGS 环境变量，这是一个在部署时提供的逗号分隔列表，例如通过 Helm 的 --set connectionStrings=
智能体 API、API 令牌和 FastAPI 信任边界
公共客户端调用经过身份验证的 Next.js 网关，地址为 POST /api/chat/completions。响应是一个 SSE 流，携带 step、result 或 error 事件，后跟 [DONE]。conversation_id 字段是可选的：省略它进行无状态的一次性请求，或提供客户端生成的 UUID 来创建或继续对话，并在每一轮中重复使用相同的 UUID。调用者必须等待 [DONE] 后再发送下一轮，因为同一对话的重叠请求会返回 409 Conversation in progress。
对于对话请求，FastAPI 会加载最近最多五个已完成的轮次，限制为 12,000 个字符，并在运行现有的文本到 SQL 图之前，将“八月怎么样？”等上下文输入重写为独立问题。独立问题会原样通过。内部智能体想法、图表负载、错误和原始 SQL 结果集不会作为上下文重用。对话历史仅限于经过身份验证的 Auto Ontology 用户。
仓库围绕 FastAPI 划定了明确的安全边界。它指出 FastAPI 端口是受信任的内部服务边界，不得公开暴露，因为 FastAPI 不会独立验证 Next.js 网关转发的内部 x-auto-ontology-user-id 标头。没有 conversation_id 的直接 FastAPI 请求保持无状态；带有 conversation_id 的直接请求需要受信任的身份标头。API 创建的对话可以在 UI 中通过 /chat?focus=
API 令牌适用于无法持有浏览器会话 cookie 的脚本、笔记本和计划任务。它们从用户菜单的“API 令牌”下创建，Auto Ontology 仅存储 SHA-256 哈希，因此令牌只显示一次，丢失就意味着要创建新令牌。令牌作为 x-api-key 标头发送到任何 /api/... 调用，Authorization: Bearer
文档记录了四种令牌行为：
- 令牌代表其所有者行事，本身不携带任何权限，因此每次调用都根据所有者的角色进行授权，就像在浏览器中一样，查看者的令牌无法执行管理员操作。
- 整个 API 表面接受令牌，因为身份验证在每一路由的一个位置（frontend/auth/resolve-user.ts）解析，因此 docs/openapi/auto-ontology-api.json 中任何未标记为 withPublic 的端点都可以使用令牌。
- 撤销是即时的：在 UI 中删除令牌，或删除或封禁所有者用户，会导致下一次使用该令牌的请求收到 401。
- 令牌无法管理令牌，因为创建和撤销令牌需要已登录的会话，因此泄露的令牌无法为自己生成继任者。
支持 SSO 进行身份验证，重定向 URI 在身份提供者中配置为 APP_URL/api/auth/sso/callback。
MCP 服务器和编码智能体技能
Cursor 和 Claude Desktop 等智能体框架可以通过 Auto Ontology 的 MCP 服务器查询数据，相关文档在 mcp/ 目录和 docs/mcp.md 中。编码智能体被引导从 AGENTS.md 开始，skills/ 目录中提供了三个技能：nvidia-ontology-setup、nvidia-ontology-management 和 nvidia-ontology-query。项目维护者继续使用 CLAUDE.md。
基准测试被引用但未在仓库中发布
仓库引导开发者前往一个单独的本体 SQL 评估仓库 github.com/NVIDIA/ontology-sql-eval 来运行 BIRD 等文本到 SQL 基准测试。Auto Ontology 自己的 README 没有发布准确率、延迟或成本数据，因此任何关于该项目的性能声明都必须针对该评估框架进行复现，而不能直接从仓库引用。
许可、贡献和外部依赖
Auto Ontology 根据 Apache License 2.0 版许可，SPDX 标识符为 Apache-2.0。NVIDIA 编写的源文件带有 SPDX 头，内容为“SPDX-FileCopyrightText: Copyright (c) 2024-2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved.”，以及“SPDX-License-Identifier: Apache-2.0”。第三方开源组件在 THIRD_PARTY_NOTICES.md 中列出了上游许可证和项目 URL，容器镜像添加的组件在 CONTAINER_THIRD_PARTY_NOTICES.md 中单独列出。
尽管采用开源许可证，该项目目前不接受外部贡献：“来自 Auto Ontology 维护团队之外提交的问题、拉取请求和补丁将不会被审查或合并。”与安全相关的报告通过 SECURITY.md 处理，维护者工作流程在 CONTRIBUTING.md 中。
仓库还包含一个通知，说明该软件会检索和交互未随其分发且受单独条款约束的外部材料。列出的运行时外部材料包括：NVIDIA 托管的模型 API（build.nvidia.com 和 integrate.api.nvidia.com），用于聊天、摄取和语义编译期间的 LLM、嵌入和重排序；用户通过 *_ENDPOINT 和 *_MODEL 变量配置的任何其他 OpenAI 兼容模型端点；KumoRFM 预测查询服务（仅在设置 KUMO_RFM_API_KEY 时使用），受 Kumo 条款约束；以及用户自己的源数据库，在摄取、分析和查询执行期间使用。
Hacker News 讨论的反应
反应分为两派：一派认为企业本体工作是 AI 的真正瓶颈，另一派则怀疑增加另一个 LLM 驱动的层能否修复智能体的不可靠性。
最尖锐的技术反对意见来自 grey-area，他认为该架构增加了不确定性而非消除不确定性：
用更多不可靠的智能体来修复不可靠的智能体。遗憾的是，我们无法解决 LLM 倾向于更重视其权重而非所分析数据的问题。我想这归根结底是因为它们没有明确区分关于世界的学习数据、指令和正在分析的数据。你可以要求它们只考虑面前的 5 个事实，但它们不会这样做，也无法这样做。
HexDecOctBin 提出了本体框架所引发的符号 AI 问题：为什么不使用 LLM 编写尽可能多的符号规则来拟合数据，同时保持规则集可审查和可维护？这个问题直接指向了 Auto Ontology 设计中的张力：它使用 LLM（通过 NIM）来生成和维护一个符号化、可审查的目录，而不是直接回答问题。
几位评论者质疑产品在哪里结束，周围复杂性从哪里开始。podocarp 问这与一个记忆系统加上收集企业 API 和 CLI 的技能有何区别。bbor 发现 README 是为企业项目经理写的，并询问该项目与任何哲学或学术本体工作（如果有的话）有何关联，称具体细节难以理解。dstu 对开篇句子中的“gates”一词有强烈的反感，并认为一个值得构建的工具值得用作者自己的平实语言来描述。
采用摩擦被视为一个实际障碍。igleria 表示感兴趣，但发现项目需要 NVIDIA API 密钥后便望而却步。这与仓库一致，其中 NVIDIA API 密钥是列出的前提条件，默认模型端点指向 build.nvidia.com。
在需求方面，monkeydust 描述说花费了大量资金来做好本体工作，因为它对企业 AI 的实际成功至关重要，并表示好奇这是否能有所帮助。原始发帖人 campervans 直白地总结了价值主张：“企业（技术）债务的游戏规则改变者。”
另一条怀疑的线索更广泛地针对 NVIDIA 的开源姿态。einpoklum 写道：
开源？不如我们先把 NVIDIA 的用户空间库开源：libcuda、libcudart、libOpenCL、libnvtx，以及 nvidia-smi 和 CUDA 与 OpenCL 分析器。
该批评针对的是上游驱动程序和工具链组件，而不是 Auto Ontology 本身的许可证（它是 Apache-2.0）。
采用 Auto Ontology 前需要验证的事项
仓库中有三件事值得针对特定部署进行核查。首先，除非设置了全部四个 Vault 变量，否则 UI 添加的连接凭据默认以明文存储在 Postgres 中，因此对于任何处理生产数据库密码的部署，Vault 配置都不是可选的。其次，FastAPI 端口不得公开暴露，因为身份标头在该边界是被信任而非验证的。第三，项目不发布自己的基准测试结果；README 仅引导读者前往单独的 ontology-sql-eval 仓库来运行 BIRD 等文本到 SQL 基准测试。潜在采用者还应权衡，外部贡献目前是关闭的，因此路线图完全由 NVIDIA 的维护团队控制。