AI

Auto Ontology：NVIDIA 開源的企業語意層，讓 Agent 用「認證過的商業定義」寫 SQL

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

「上一季北區的營收是多少？」對人類分析師來說，這個問題的難點從來不是 SQL 語法，而是定義：「營收」是含稅還是未稅？退貨要不要扣？「北區」是哪幾個門市？這些定義通常散落在不同系統、不同部門的腦袋裡。讓 LLM 直接把問題翻成 SQL，最常見的失敗就是「語法正確、定義錯誤」。Auto Ontology（NVIDIA/auto-ontology）要解決的正是這個問題：在資料庫和 Agent 之間，建立一層經過人工認證的語意層（ontology）。專案約 9.1k stars，在 11 月 6 日的 AI 開源趨勢報告中被列為當日 AI 基礎設施類的焦點專案。

1. 專案背景與定位

Auto Ontology 由 NVIDIA 以 Apache-2.0 授權開源，官方描述是「一個用於在資料之上建立語意化、圖狀推理層的 Python 框架，讓 LLM 與 Agent 工作流程能確定性地產生查詢、取得更好的脈絡，並提供更可解釋的 AI」。

它的核心用途很明確：企業關聯式資料庫上的自然語言轉 SQL。它從企業的 metadata 中建立語意層、整合不同系統間的定義，再透過 MCP、CLI 與 API 提供給 Agent 使用——用於探索資料、讓 Agent 理解商業術語、驗證生成的 SQL 是否符合認證定義，並從修正中學習。要注意的是，它不是通用的「文件轉知識圖譜」工具。

2. 技術架構與核心設計

整個流程分為三個階段：

  • Generate（產生）：讀取資料來源的 schema、欄位統計與範例值，逐表萃取商業詞彙，推斷表格間的關聯與橋接表，並從查詢歷史建議 SQL 屬性；結果存進 Postgres，並以 pgvector 建立 embedding。
  • Certify（認證）：由人類在 UI 或 API 中測試、修改並認證這些詞彙、描述與 SQL 屬性——這是整個系統可信度的關鍵。
  • Answer（回答）：判斷意圖、以 embedding 搜尋候選詞彙、撰寫 SQL、對照資料庫檢查篩選值與查詢本身並自動修復、執行查詢，最後回傳答案以及使用的 SQL 與推理步驟。

其他重點：

  • 技術棧：Next.js 16 前端（port 3000）、FastAPI + LangChain 後端（3001）、FastAPI 資料匯入服務（3002）、FastMCP 的 MCP Server（3003）、Postgres 17 + pgvector；可選用 HashiCorp Vault 管理資料庫憑證。
  • 模型：預設使用 NVIDIA NIM 上的 Nemotron 系列模型（推理、embedding、rerank 各自設定），也可以改接任何 OpenAI 相容或自架的 NIM 端點。本機不需要 GPU。
  • 支援 10 種資料庫：PostgreSQL、MySQL、Databricks、Snowflake、ClickHouse、Trino、Apache Kyuubi、HeavyDB、DuckDB、SQLite；並支援 Apache Ossie YAML 的匯入匯出。
  • Agent 整合：MCP Server（可用 uvx 執行）、Agent Skills，以及 REST API（POST /api/chat/completions）。
  • 部署：Docker Compose 快速啟動（搭配 Wide World Importers 範例資料庫），或以 Helm chart 部署到 Kubernetes。

3. 社群熱度與生態採用

約 9.1k stars、730 forks、1,367 commits。和本月介紹的 OpenShell 一樣，它來自 NVIDIA，並明確定位在企業使用情境。官方另外提供 ontology-sql-eval repo，用 BIRD 文字轉 SQL 基準做評測，但主 repo 的 README 並未列出具體分數。

需要注意的是，README 表示團隊不接受外部 pull request，只接受整合需求與 bug 回報的 issue——這是一個「開放原始碼」但非「開放協作」的專案。

4. 局限性與潛在風險

  • 內部服務沒有驗證：README 明確要求 3001 與 3002 port 只能放在私有網路，因為資料匯入服務的端點本身沒有驗證機制。部署時一定要做好網路隔離。
  • 它會讀取你的資料庫：schema、欄位統計、範例值與查詢歷史都會被讀取，部分內容會送往模型端點做萃取；使用 NVIDIA 雲端 API 時，這些 metadata 會離開公司。敏感環境應使用自架的 NIM。
  • 預測功能會上傳資料表：若設定 KumoRFM 的 API 金鑰，預測類問題會把連接的資料表上傳到第三方託管服務（預設上限 20 張表），README 也建議事先審查資料。
  • 認證需要人力：自動萃取的定義未經認證前不應被信任；語意層的品質最終取決於資料團隊投入多少時間審核。
  • SQL 的權限風險：Agent 產生的 SQL 會直接在資料庫上執行，連線帳號應只給唯讀權限，並限制可存取的 schema。
  • 模型需求：必須使用支援結構化輸出的模型，且匯入與查詢時的 embedding 模型必須一致；README 中範例設定的模型名稱前後也略有不一致。
  • 適用範圍：只支援關聯式資料庫，不處理文件或非結構化資料。

5. 應用價值與適用場景

最適合已經有資料倉儲、想讓業務人員或 Agent 用自然語言查資料的企業：財務、營運、銷售團隊可以直接問問題，背後由認證過的商業定義確保答案一致。對資料團隊來說，它也是一個把「部落知識」整理成可維護語意層的工具——那些原本只存在於資深分析師腦中的定義，會被明確記錄、認證、版本化。

Monday 的觀點與架構建議

  • Auto Ontology 抓住了企業 AI 最被低估的問題：LLM 寫 SQL 的瓶頸不是語法，而是語意。「產生 → 人工認證 → 回答」的設計，把人類的判斷放在最關鍵的位置，而不是期待模型自己猜對商業定義。
  • 回傳答案時同時附上 SQL 與推理步驟，讓每個數字都能被追溯與質疑——這對財務與決策相關的查詢至關重要。
  • 部署建議：內部服務只開放在私有網路；資料庫連線使用唯讀帳號；敏感資料使用自架模型端點；先在一個小範圍的資料集市（data mart）上建立並認證語意層，再逐步擴大。
  • 這個月我們看了很多 RAG 與記憶工具（Graphify、PageIndex、Cognee），Auto Ontology 則把同樣的思路帶到結構化資料：Agent 需要的不只是資料，而是對資料「意義」的共識。

參考來源