企业官网建设流程全解析

上周有个做数据平台的朋友问我：为什么他们内部的知识库Agent，查销售额能查对，一换成"上个季度华东区退货率环比"就开始编？我让他把Agent的执行链路打出来看，问题很典型——模型拿到了一堆表名和列名，但不知道"退货率"这个业务词对应哪几列、口径是哪个经过审核的SQL、这几张表之间怎么join。它只能猜，猜错了还很自信。

NVIDIA开源的auto-ontology就是冲着这个场景去的。原项目在GitHub上有4406 stars，主语言Python，Apache-2.0协议。我这两天在看它的中文版（yangshun2005/auto-ontology-cn），翻译已经完成，文档做了中文化。这篇就结合中文版文档，把安装、跑通、以及我判断的落地边界讲清楚。

它到底解决哪一层问题

先把这个项目的定位说准，不然容易误判。官方一句话描述是：一个Python框架，用于在数据之上构建语义的、基于图的推理层，支持确定性查询生成、更好的上下文检索，以及更可解释的AI，面向LLM和Agent工作流。

落到工程上，它是一个跟数据库并排跑的服务。它把数据库元数据编译成一套"本体"（ontology）：业务术语映射到列、经过审核的度量SQL表达式、以及表之间的关系。Agent不直接看Schema，而是通过本体来查询，查询前先做一次可回答性检查，回答时把SQL和执行步骤一起返回。

README里有一张对比表，我觉得是全文最有价值的部分，它把"把Schema粘进上下文窗口"和"用工具操作本体"这两条路摊开对比了：

Token消耗上，粘Schema是随每张表每列线性增长的，而本体工具只涉及问题相关的术语和表。含义上，粘Schema只有列名，其余靠模型推断；本体里业务术语是显式映射到列和SQL的。连接与度量上，前者每个问题临时拼凑，后者是已解析的关系加经过审核的SQL表达式。最关键的是最后一行：面对无法回答的问题，粘Schema的Agent会自信作答、往往答错，而本体路径有可回答性检查，能让Agent主动请求澄清。

这一行基本就是我在开头那个例子里看到的现象。所以我的判断是：这个项目不是"又一个Text2SQL"，它卖的是治理能力——把"这个词是什么意思、该不该用、怎么用"从模型脑子里挪到可审核的资产里。

中文版做了什么，没做什么

说清楚边界。中文版是原项目文档的中文翻译版本，翻译日期2026-11-05，保留了原始README（README_en.md）作为对照。页面顶部额外加了一段"中文快速上手"，明确标注为非原文内容，是面向中文用户的补充导读，目的是不用读完整篇README就能先把项目跑起来。

这个补充导读其实挺实用，因为原README的Quickstart信息密度高但跳跃，中文版把它压成了五步。需要说明的是，翻译已完成，但项目QA没有完全走完，所以别把它当成"官方认证的中文发行版"，它更像一份能让你少踩语言坑的对照文档。有翻译不准确的地方，仓库里也写了欢迎提Issue或PR。

对国内团队来说，这类基础设施工具的文档中文化，价值不在"看得懂"，而在"评估成本"。一个平台团队要做选型，通常得先有一个人把README啃完、把Demo跑起来，才能给出判断。语言门槛会把这段时间拉长。中文导读把这段压缩了，这是我认为中文版最实在的收益。

跑起来：五步，但有两个坑

以下流程来自README的Quickstart，用Docker Compose对Wide World Importers示例数据库跑。

第一步，克隆并配置环境变量：

gitclone https://github.com/NVIDIA/auto-ontology.git&&cdauto-ontologycp.env.example .env

然后在.env里设置DEFAULT_MODELS_API_KEY（nvapi-开头）、AUTH_SECRET、APP_URL=http://localhost:3000、POSTGRES_PASSWORD、CONNECTION_STRINGS、AUTO_ONTOLOGY_ADMIN_PASSWORD、PGADMIN_PASSWORD等。README给了完整示例，照着填就行。

第二步，起Postgres并灌示例数据。种子脚本不在主仓库，在配套的auto-ontology-eval仓库里：

dockercompose up-d--waitpostgresgitclone https://github.com/NVIDIA/auto-ontology-eval.git../auto-ontology-eval(cd../auto-ontology-eval&&uvsync&&cp.env.example .env&&\POSTGRES_PASSWORD=' '\uv run python scripts/seed/seed_wwi.py --database-name wideworldimporters --drop)

这里第一个坑：种子脚本依赖uv，不是pip。uv得先装好，否则uv sync直接失败。第二个坑是那个POSTGRES_PASSWORD=' '，看着像占位符，实际是脚本读取环境变量的方式，别自作聪明改成真实密码，容易和第一步.env里的值对不上。

第三步，构建并启动其余服务：

dockercompose up-d--build

第四步，打开http://localhost:3000，用.env里的AUTO_ONTOLOGY_ADMIN_EMAIL和AUTO_ONTOLOGY_ADMIN_PASSWORD登录。进去后到Settings → Semantic Compilation，把它开启。启动时会执行ingestion，编译完成后界面会显示"Semantic compilation is ready"。这一步是编译本体，别急着提问，等这个提示出来。

第五步，到Chat里验证。README给的示例问题是关于2015年6月宾夕法尼亚州某产品的revenue，回答会附带SQL和推理步骤。我建议第一次验证就用这个原题，变量最少，跑通了再换自己的问题。

环境要求方面，原文没限定操作系统，Dockerfile基于nvcr.io/nvidia/base/ubuntu（jammy），Makefile默认多架构发布平台是linux/amd64,linux/arm64。硬件没有特殊要求说明。依赖上明确要Docker及Compose v2、uv，Python版本pyproject.toml要求>=3.12。

我建议的落地顺序

基于这套东西的形态，我给一个选型判断，供参考。

先别急着接生产库。第一步应该是拿一个业务方抱怨最多的数据集，把本体编译出来，让业务分析师在Web UI里过一遍术语映射——这一步能暴露的问题比技术验证多得多。很多团队以为难点在模型，实际难点在"退货率到底算不算运费"这种口径分歧，本体只是把这个分歧显性化了。

第二步，验证可回答性检查的边界。这是它跟普通Text2SQL最大的差异点，也是最需要你亲自试的地方。构造一批"库里根本没有这个字段"的问题，看Agent是请求澄清还是硬答。这个行为决定了它能不能进生产——能请求澄清，才谈得上可信。

第三步才是接MCP或REST API到现有Agent框架。README里提到它通过MCP、智能体技能和REST API向任意Agent框架提供上下文，这部分是集成面，工程上相对确定，反而不用太早投入。

至于评估，配套的auto-ontology-eval仓库在BIRD、BEAVER、FDABench-Lite和Wide World Importers上做基准衡量。我的建议是别只看它的分数，而是用你自己的问题集跑一遍——基准能说明方法有效，说明不了你的口径能被正确编译。

一点保留

这个项目的信息密度高，但有些地方我还没完全验证。比如语义编译在大表上的耗时、ingestion对Schema变更的响应方式，README里没有展开，我的样本也不够。另外它强调"与你已有的语义模型互补"，这句话怎么落地，取决于你现有的dbt或指标平台长什么样，没有通用答案。

如果你正在被Agent乱答数据问题困扰，值得花半天把Demo跑起来。重点不是看它答对那道revenue题，而是看它在答不了的时候，会不会老实说答不了。