表多了别只塞 schema：让 Agent 先查本体

表不多的时候，把 schema 整段贴进 prompt 最省事。表到几十张、指标有多个口径之后，先出问题的通常不是上下文窗口，而是模型开始猜：revenue 取哪一列，退货算不算，这两张表能不能 join。答案越流利，越难发现它错在哪。

NVIDIA 的 Auto-Ontology 走另一条路：把数据库元数据编译成一层本体，业务术语映射到列，经过审核的度量 SQL，表与表的关系。Agent 不直接读 schema，而是先查本体，再决定这题能不能答。项目 Apache-2.0，2026 年 4 月创建。

这篇只谈工程问题：schema 塞上下文在什么规模开始亏，本体怎么生成和审核，部署要付什么代价。数字来自 2026-11-04 的 README、docs 和 eval 仓库；NVIDIA 没有公开可引用的准确率提升数字，本文也不编。

先算三笔账：schema 塞上下文什么时候开始亏

先看一个能算的样本。Quickstart 用 Wide World Importers，我数了 eval 仓库的建表脚本：48 张表、557 个列定义（建表脚本 23,103 字节）。按 4 个字符 1 个 token 粗算，整份 DDL 约 6k tokens。放进 128k 上下文不挤，但模型仍要判断 revenue 取哪列、退货怎么算、哪些表能 join。一次编译给这个库生成了 31 个 term。

所以第一个拐点不是 token。token 成本随表和列线性增长，几百张表、上万列之后会挤掉问题、历史、工具返回和示例，那时是硬约束。在那之前，先坏的是歧义：同名列、事实表和维度表、桥表、口径不同的度量，候选 join 随表数量组合增长。

第二个拐点是准确率。它没有通用阈值，取决于命名、问题类型和模型。能做的是拿自己的问题集做对照：同一模型，一组只给 schema，一组走本体，按执行结果比对，记录修好了哪些、弄坏了哪些。Auto-Ontology 的 eval 就是两臂同题、确定性执行匹配，不用 LLM judge。

第三个拐点是可解释性。schema 塞上下文时，你很难回答“这个营收数字用了哪个定义”。本体至少把 term、SQL attribute、relationship 和认证状态存下来，答案可以带 SQL 和步骤。但能生成 SQL 不等于口径统一，SQL 跑通也不等于业务定义正确。

这三笔账可以先在自己的库上量。下面两条 SQL 只读元数据，用来数表和列的规模，以及同名 column 的分布：

select table_schema, count(*) as tables
from information_schema.tables
where table_type = 'BASE TABLE'
group by table_schema
order by tables desc;

select column_name, count(*) as columns_with_same_name
from information_schema.columns
group by column_name
having count(*) > 1
order by columns_with_same_name desc
limit 30;

如果同名 column 很多，或者一个指标在多个表里有不同算法，先别加更多 prompt，先把定义收拢。上下文不是越大越好，这个结论在会话记忆上也成立。

它把 schema 编译成了什么

Auto-Ontology 是跑在数据库旁边的 context layer，不是模型，也不是向量数据库。它读源库元数据，编译成三类定义：

• Terms。 业务概念，比如 Customer、Invoice Line，带描述、同义词，映射到承载它的列。
• SQL attributes。 挂在 term 下的、审核过的 SQL 表达式，比如 margin、rolling total。Agent 复用它，同一个度量每次算法一致。
• Relationships。 表与表怎么 join，包括桥表，从键和数据里推断。

生成分四步：读源库，抽 schema、profile 列和采样值；逐表抽 term 并映射列；推断 join 和桥表，从查询历史建议 SQL attribute；把三类定义写进 Postgres，embedding 进 pgvector。人可以在 Web UI 里把它当语义图看。README 里 Wide World Importers 的一次编译结果是 31 个 term。

对外有五个动作：Discover 从元数据生成本体、导入已有 semantic model、用语义图探索；Ground 一个业务概念一个定义；Certify 在 UI 或 API 里审核、认证；Validate 在查询前判断问题是否可答，回答时带 SQL 和步骤；Expose 通过 MCP、agent skills、REST API 给任意 Agent harness。

它兼容 Apache Ossie，能导入导出 Ossie YAML；源库支持 10 种：PostgreSQL、MySQL、Databricks、Snowflake、ClickHouse、Trino、Apache Kyuubi、HeavyDB、DuckDB、SQLite。README 的原话是 complements the semantic models you already own。它是查询时的上下文层，不替代 dbt 的建模流程，也不是完整的数据目录；dbt 原生 adapter 在仓库里没有文档，待核实。RAG 解决文档，本体解决结构化数据的术语、度量和 join，两者可以同时用。

一次问答怎么走

收到问题后，Agent 先分类意图、抽实体，用 embedding 检索候选 term、column、SQL attribute，再写 SQL。写完不是直接执行：先检查过滤值，再拿查询去数据库验证，失败就修，最后才跑，返回答案、SQL 和步骤。

最关键的是 answerability。MCP 里有 check_answerable，先判断本体覆不覆盖这个问题，再决定要不要 ask_question。README 的例子：问某款产品的广告支出回报率，覆盖度 0.5，因为没有 term 覆盖 ad spend；Agent 会说我能算这家产品的营收，但这份数据没有广告支出，你要不要改问营收，或者告诉我广告数据在哪个源。

MCP 工具只读，包括 check_readiness、search_terms、get_term、get_term_columns、get_term_sql_attributes、get_sql_attribute、describe_table、check_answerable、ask_question。没有浏览原始 schema 的工具，这是故意的：入口被限制在语义层，避免 Agent 又回去猜表。ask_question 返回最多 100 行，带 row_count 和 truncated；一次调用通常几十秒。

OpenAPI 规范当前有 81 个 path、119 个 operation，MCP 只暴露一个精选 allow-list，避免工具太多把选择打散。不是把所有 API 塞给 Agent，而是给它少数几个有明确使用场景的工具。

用 Docker Compose 跑通最小流程

需要 Docker Compose v2、uv，和一个 build.nvidia.com 的 NVIDIA API key（nvapi- 开头）。Quickstart 用 Wide World Importers，不接自己的库也能先看效果。

git clone https://github.com/NVIDIA/auto-ontology.git
cd auto-ontology
cp .env.example .env

.env 里至少改这几个：DEFAULT_MODELS_API_KEY、AUTH_SECRET、APP_URL、POSTGRES_PASSWORD、CONNECTION_STRINGS、AUTO_ONTOLOGY_ADMIN_PASSWORD、PGADMIN_PASSWORD。Compose 会把 Postgres、pgAdmin 和 Web 应用发布到宿主机，默认密码要先换。

docker compose up -d --wait postgres
git clone https://github.com/NVIDIA/auto-ontology-eval.git ../auto-ontology-eval
(cd ../auto-ontology-eval && uv sync && cp .env.example .env && \
  POSTGRES_PASSWORD='<与 .env 中 POSTGRES_PASSWORD 相同>' \
  uv run python scripts/seed/seed_wwi.py --database-name wideworldimporters --drop)
docker compose up -d --build

打开 http://localhost:3000，用 AUTO_ONTOLOGY_ADMIN_EMAIL 和 AUTO_ONTOLOGY_ADMIN_PASSWORD 登录，到 Settings 里的 Semantic Compilation 打开编译。等界面显示 Semantic compilation is ready，再进 Chat 问 README 的样例问题。答案会带 SQL 和步骤，可以拿去和源库对。

要接到自己的 Agent，跑 MCP server，指向 Web 应用：

AUTO_ONTOLOGY_API_URL=http://localhost:3000 \
  uvx --from "git+https://github.com/NVIDIA/auto-ontology.git#subdirectory=mcp" auto-ontology-mcp

Cursor 的 ~/.cursor/mcp.json 写：

{
  "mcpServers": {
    "auto-ontology": { "url": "http://localhost:3003/mcp" }
  }
}

端口是 3000 前端、3001 后端、3002 ingestion、3003 MCP、5432 Postgres。Kubernetes 有 Helm chart，但 Quickstart 只覆盖 Compose。README 当前默认模型是 nvidia/nemotron-3.5-lightning-30b-a3b、nvidia/nemotron-3.5-embed-1b、nvidia/nemotron-3.5-rerank-8b，模型名会变，以 .env.example 为准。

定义归谁：认证、冲突和回滚

这是最容易低估的一段。Auto-Ontology 能生成草稿本体，但草稿不是可信定义。README 把流程拆成 Generate、Certify、Answer：人生成后审核，Agent 才从审核过的本体回答。

Term 有 owner，可以指定用户或组；权限按 resource:action 控制。认证分字段：name、description、列属性和 SQL attribute 各有 certified 标记，聚合出 certified、partial、pending。好处是能看见“名字定了、描述还没定”；坏处是它不是一个原子的评审和发布流程。

仓库的 publication.md 写得很直接：当前 certification 字段不是原子的 review/promotion 系统；在产品生命周期出现之前，不要声称原子认证、晋升、替代或回滚。它还列了三个已知问题：#250 替换模型可能保留被省略的 semantic FK；#265 替换可能保留旧属性；#267 不同物理 ID 但同名数据库可能返回 HTTP 500。处理方式是导出原模型、保留 YAML 和 SHA-256、在隔离环境先应用、再按 ID 和结构回读比对；不要直接改 Postgres 绕过。

冲突怎么处理？产品能记录一个概念一个定义，能记录谁认证了什么，但不能替组织决定“营收”该听财务还是销售。两个团队口径不一致时，先由数据 owner 定口径，再用 term、SQL attribute 和 certification 固化。没有这个前置约定，本体只会把冲突写得更整齐。

导入导出是另一条治理线。支持原生 YAML 和 Apache Ossie；导入是 admin-only，默认 replace=true，会替换现有 catalog 和 semantic layer（管理 skill）。它不是合并补丁，更像换一份模型，生产上要先导出、比对、再导入。

五个坑：端口、凭据、数据外发、成本、导入与贡献

第一，端口暴露。 README 明确说 3001 和 3002 要放在私网；FastAPI 信任前端转发的 x-auto-ontology-user-id 头，ingestion 服务的 ingest、delete、reset、compile 端点没有自己的认证。把 3001/3002 开到公网，等于把写入和重置入口交出去。

第二，凭据存储。 没有配置 Vault 时，连接对象连同密码以明文存储在 Postgres 的 catalog 行里。Vault 默认关闭，要同时设置 VAULT_ADDR、VAULT_NAMESPACE、VAULT_ROLE_ID、VAULT_SECRET_ID 才启用；只配一部分会回退到明文。生产上要么上 Vault，要么至少把 Postgres 的访问面收窄。

第三，预测功能的数据外发。 设置 KUMO_RFM_API_KEY 后，预测类问题会路由到 KumoRFM，Agent 会把连接的表上传过去。默认最多 20 张表（KUMO_MAX_TABLES），每张表的行数默认不限（KUMO_MAX_ROWS_PER_TABLE 未设置时不限）。开之前先看要传什么，走一遍组织的数据审核。

第四，成本和延迟。 ask_question 内部是多次串行模型调用，docs 说通常几十秒；MCP 的 chat timeout 默认 900 秒，普通请求 30 秒。模型走 build.nvidia.com 的 NIM，计费方式待核实；仓库没有给单次问答成本。eval 里还有一条：超过 5% 的问题没有模型输出时，报告会扣住 headline 数字，因为限流跑出来的低分和模型弱看起来一样。

第五，导入和外部贡献。 导入默认替换现有模型，先导出再导入；维护者不接受外部 PR，集成需求走 issue。Apache-2.0 允许 fork，但定制 connector、改认证、修 bug 都要自己维护分支。数据可以导出成原生 YAML 或 Ossie，所以不是数据锁定；锁定主要在运维和定制成本。

结论：先查本体，不是先信本体

schema 塞上下文不是错，错在把它当唯一上下文。表少、口径稳定时，整段 schema 加一个好问题就够用；表多、定义多、多个 Agent 同时问数时，先给模型一层可审核的术语、度量和 join，比让它从列名里猜更稳。Auto-Ontology 的价值不在“本体”这个词，而在把 Discover、Certify、Validate 拆成可检查的步骤，并允许 Agent 在答不了时说答不了。

今天能做的下一步很具体：挑 20 到 50 个真实问题，跑一次 control 和 treatment，记录三组数：schema 占了多少 token、多少问题被判不可答、哪些问题被本体修好或弄坏。不要先全量接入，也不要拿一个没有出处的提升数字立项。

如果这些回答要进入团队流程，还有一层是执行记录。本体解决“业务定义从哪来”，不解决“这次回答是谁在什么任务里、用了哪版定义”。HiFox 的任务执行会把任务上下文、运行状态和结果写回同一个任务；如果 Agent 把本体版本和 SQL 写进结果，回看时就能和这次执行放在一起。它不提供本体，也不替代 Auto-Ontology。机制见 Agent 如何执行任务。

资料来源： NVIDIA/auto-ontology；NVIDIA/auto-ontology-eval；MCP server；Connections；Governed publication；Management skill；Apache Ossie。