上一篇文章翻译了 Palantir CEO Alex Karp 的致股东信《卡普致股东信全文：我们要拿下整个市场》。其中有一个判断值得关注：没有 Palantir 开创的运营模式，就无法把大模型可靠地接入大型企业。
这个判断是否成立可以讨论，但它指出了企业 AI 落地中的一个真实难题：大模型会写 SQL，不等于它理解企业业务；能够查询数据库，也不等于能够给出可信的业务答案。 这恰恰是 AI 问数从技术演示走向企业生产环境时，最难跨越的一道坎。
最近，英伟达开源了一个名为 Auto Ontology 的项目。它不是又一个 Text-to-SQL 工具，而是一个面向 AI 问数和企业数据 Agent 的开源语义层框架。它试图把企业数据库背后的业务术语、指标口径、字段映射和表间关系，转化为 Agent 可以理解和调用的上下文，让大模型不再仅仅根据数据库 Schema 猜测业务含义，而是基于经过整理和认证的企业知识生成查询。
它在 README 开头写了一句话，比很多产品宣传都实在：一个收入指标答得更快，如果数字是错的，那就一文不值。
这句话实际上点出了 AI 问数的核心矛盾：查询效率不是第一位的，业务语义的准确性才是。
问一句“上季度华南收入多少”，对人来说很日常，对数据库却是一道多选题。
数据库里没有一个叫“华南收入”的字段。模型得先知道收入由哪几列算出来，是单价乘数量，还是另有一列含税金额，退货要不要扣。它得知道华南对应哪些省，这份对应关系存在哪张表里。它得决定时间用下单日、发货日还是开票日，三个口径能算出三个都合理、却彼此不同的数字。它还得知道哪些表能连，连错一张表，结果可能悄悄翻一倍。
这些问题不答清楚，SQL写得再漂亮也只是精确地错。
过去这部分知识在分析师脑子里。于是同一批对话反复发生：这个收入为什么不等于财务报表里的收入，这张表应该和哪张表连，这个指标为什么又变了。分析师的时间大量花在重复解释上，而每个新来的同事、每个新接的AI，都要重新猜一遍。
Agent一多，问题更直观。销售Agent、财务Agent、运营Agent各自理解同一批表，同一个“收入”能长出三种算法，最后没人说得清该信哪一个。
Auto Ontology做了什么
Auto Ontology是英伟达在GitHub上开源的一个库，Apache 2.0协议。它的定位是从企业元数据里构建出一层上下文，告诉Agent数据在哪里、是什么意思、该不该用、怎么用、从哪里来，再通过MCP、CLI和API把这层上下文交给任意Agent框架使用。README特别说明，它是对企业已有语义模型的补充，不是要求你推倒重来。
这层上下文里主要放三类定义：
术语（Terms），也就是“客户”“订单”“发票行”这样的业务概念，每个术语带描述和同义词，并映射到实际存它的列。
SQL属性（SQL attributes），挂在术语下面、经过审核的SQL表达式，比如毛利率、滚动十二个月合计。Agent复用这些表达式，而不是每次临时发明一种算法。
关系（Relationships），表与表怎么连，包括桥接表，可以从外键和数据本身推断出来。
图1：Agent请求经前端到后端，右侧的数据接入服务读取源数据库，模型调用走NVIDIA NIM，语义层与目录存在PostgreSQL里。
这套东西存在PostgreSQL里，向量索引用pgvector，不是另起一套独立的图数据库服务。整体是一个可以自己部署的栈：Next.js前端、FastAPI后端、负责接入与语义编译的服务、MCP服务，再加上Postgres。
三个阶段：生成、认证、回答
README把使用过程讲成三个阶段，这个顺序本身就是它的核心主张：先自动起草，再人来认证，最后才让Agent拿去答问题。
生成（Generate），机器先干活。接入服务读取schema、分析列的分布、抽取样本值，逐表抽出业务术语并映射到列，再推断表之间的连接关系和桥接表，还能从查询历史里建议常用的SQL属性。最后把术语、关系、SQL属性写进Postgres，把用于检索的向量写进pgvector。
图2：示例库一次编译生成31个术语，选中Order可以看到它的描述、7个相关术语、10个映射列和2个SQL属性。
认证（Certify），这一步必须有人。用真实问题在Chat里试，或者通过MCP调用检查工具，然后在界面或API里修正术语、描述和SQL表达式，确认无误之后再做认证。
语义层值不值得信，主要取决于这一步做了多少。机器起草的术语描述可能跑偏，自动推断的连接关系可能漏掉业务限制，这些都要懂业务的人逐个看。所谓可审计，并不是说模型不会错，而是每一个口径都有人工确认过的版本可查、可改。
回答（Answer），Agent拿到问题后先判断意图、抽出实体，用向量检索找出候选的术语、列和SQL属性，据此写SQL，再拿数据库校验过滤值和查询本身，校验不过就修复，最后执行并返回结果。
返回的不只是一个数字，还有生成它的SQL和执行步骤。这是它和普通聊天式查数最不一样的地方，你可以顺着SQL回去对源表。
图3：提问哪些产品贡献最多收入和最多客户数，回答附带生成的SQL，可以查看明细行、导出CSV或看图表。
答不了的时候，它应该说答不了
真正让我觉得这个项目值得写的，是README里的两个对照示例。
示例库用的是微软的Wide World Importers。问某个产品2015年6月在宾夕法尼亚州的收入，Agent把收入、产品、州分别解析到术语，沿着发票行、发票、客户、城市、州一路连下去，返回答案是588.80美元，来自3条发票行，同时给出SQL和解析路径。
接着问同一个产品的广告支出回报率。这个库里根本没有广告数据。通过MCP接入的Agent先做可答性检查，得到的覆盖率是0.5，没有任何术语能覆盖“广告支出”，于是它回答：我能查到这款产品的收入，但这份数据里没有广告花费，算不了广告支出回报率。你要不要看2015年6月的收入，或者广告花费记录在别的系统里，需要我接过来？
不硬算一个看似专业的数字，而是说清楚缺什么，这个行为比多答对几道题更难，也更有用。
不过有两点要说清楚，免得高估它。这段澄清话术是Agent的行为示例，不是一个固定的结构化返回字段。而check_answerable返回的覆盖率，衡量的是问题里的实体有多少能被语义层覆盖，既不是准确率，也不代表SQL一定对。文档还提到，检索不到足够内容时，问答接口可能返回空答案且没有报错，需要调用方自己再检查。
上手要准备什么
本地跑起来的门槛不算高：Docker Compose v2、uv，以及一个在build.nvidia.com申请的NVIDIA API key。官方示例就是上面那个Wide World Importers库。
git clone https://github.com/NVIDIA/auto-ontology.git && cd auto-ontology
cp .env.example .env # 填API key、AUTH_SECRET、数据库密码等
docker compose up -d --wait postgres
# 示例数据由配套评测仓库的seed脚本导入，详见README Quickstart
docker compose up -d --build
然后打开localhost:3000，在Settings里打开Semantic Compilation，等到界面显示ready，就可以去Chat里提问。主服务要求Python 3.12以上。
模型可以换。默认走NVIDIA NIM，按推理、轻量步骤、向量、重排四个角色分别配置，每个角色用一组端点、密钥和模型名环境变量，没填的回落到公共默认。自建的OpenAI兼容接口也能接，但模型必须支持结构化输出，而且入库和查询两端的向量模型必须一致。
数据源支持十种：PostgreSQL、MySQL、Databricks、Snowflake、ClickHouse、Trino、Apache Kyuubi、HeavyDB、DuckDB、SQLite。注意BigQuery不在列表里，DuckDB和SQLite只能用连接串配置，不能从界面添加。
接给自己的Agent用，最省事的是MCP，不用单独克隆仓库：
AUTO_ONTOLOGY_API_URL=http://localhost:3000 \
uvx --from "git+https://github.com/NVIDIA/auto-ontology.git#subdirectory=mcp" auto-ontology-mcp
MCP提供的都是只读工具，查术语、查术语对应的列和SQL属性、查表结构、做可答性检查、提问。每次调用都带当前登录用户的权限，不会因为是Agent就越权。
我的看法：把隐性经验变成资产，但成本没有消失
这个项目的价值，不在于又让大模型多会写一种SQL，而在于它把“企业数据是什么意思”从分析师的隐性经验，变成了可以查询、可以认证、可以复用的东西。口径一旦固定下来，销售、财务、运营几个Agent就不必各自猜，新员工也不用靠打听。
它和Palantir讲的本体是同一个方向的问题：模型要进入企业，得先理解业务对象和口径。差别在于形态，Palantir是商业平台加交付体系，Auto Ontology是开源库，部署、认证和后续维护都留给你自己。所以不能说装上就获得了同等能力，更准确的说法是，它把这套做法的门槛降到了可以自己动手验证的程度。
也要看到成本只是转移了，不是消失了。自动起草省掉的是起步阶段，认证口径、处理口径变更、协调不同部门对同一个词的分歧，这些长期工作仍然落在业务和数据团队身上。语义层不维护，过期得比数据库还快。
可审计也要打个折扣来理解。答案附SQL和步骤，是核查的起点，不是正确的保证。可答性检查只看语义覆盖，MCP提问默认最多返回100行，拿截断的结果去下完整榜单的结论就会出错。
真要上生产，还有几件README和文档里写明的事不能跳过：后端和接入服务端口要放在私网，接入服务的导入、删除、编译接口本身没有认证；凭据加密存储用的Vault默认是关的，不配置的话，界面添加的数据库连接密码会以未加密的形式存进Postgres。另外项目目前不接受外部代码贡献，集成需求得走官方渠道。
最后是效果数字。官方给了一个对照评测仓库，方法很规矩：同一个模型，一边只给问题和schema，一边让它用Auto Ontology检索，两边跑同一批题，在同一个库上执行SQL比对结果，不用大模型打分。但主README里并没有公布一组可核实的准确率成绩。所以看到第三方引用具体提升百分比时，最好先回到原始结果文件再决定信不信。
对正在做企业AI落地的团队，我的建议是把它当成一个可以低成本试错的语义层起点：挑一个口径争吵最多的域，比如收入，跑一遍生成和认证，看看人工认证到底要花多少工夫。这个数字，比任何演示都更能说明它适不适合你。
资料来源：NVIDIA/auto-ontology仓库README及docs目录（2026年11月5日读取），评测方法见NVIDIA/auto-ontology-eval。示例输出为官方示例库结果，不代表任意企业数据上的效果。
提醒：请朋友们将“智见AI视界”加“星标”，觉得写得好就点击右下角“拇指”和“收藏”哦，不然会慢慢收不到文章推送~
关联阅读