讓數據開口說話：OntiCards 嘅四層架構同我哋嘅實踐

點解我哋需要 OntiCards

我哋同大量企業合作嘅時候，都聽過同一句說話：「數據好多，但係冇人用到。」

BI 報表堆咗幾百張，分析師每日疲於奔命寫新 SQL，业务人想睇個數字要排隊等三日。問題嘅根源唔係工具唔夠多，而係數據從來就冇真正「被理解」過。佢瞓喺 schema 入面、瞓喺欄位名入面、瞓喺工程師嘅腦入面，业务同佢之間隔咗成層技術語言。

我哋做 OntiCards 想解決嘅就係呢件事：將數據由欄位升級為「俾人問、俾人搵、俾人再用嘅知識」，俾业务人可以直接用自然語言同數據打交道，而唔係每次都要先揾人。

四層架構

OntiCards 唔係一個大模型嘅殼，係一個有清晰分層嘅數據智能體平台：

┌─────────────────────────────────────────┐
│  第四層 · 數據消費層                      │
│  BI 對接 / AI 智能體集成 / API 取數        │
├─────────────────────────────────────────┤
│  第三層 · 智能問數層                      │
│  卡片驅動嘅自然語言問答                   │
├─────────────────────────────────────────┤
│  第二層 · 數據卡片層                      │
│  本體建模 · 业务術語 · 實體識別           │
├─────────────────────────────────────────┤
│  第一層 · 數據接入同質檢層                 │
│  多源連接 · 欄位抽取 · 質量校驗            │
└─────────────────────────────────────────┘

第一層：將數據攞入嚟，並知道佢清唔清

我哋接入咗 9 種主流資料庫（PostgreSQL、MySQL、Oracle、SQL Server、Trino、SQLite、KingBase、OceanBase、達夢），對結構化數據做自動欄位抽取，然後跑一輪質量校驗：身份證號碼格式、姓名一致性、數值範圍、外鍵引用——將污糟數據嘅位置同原因講清楚。

呢一步嘅目的唔係將數據「治理好」（嗰係另一條慢線），而係俾人知道「呢度有咩」「邊啲欄位可以用」「邊啲規則被觸發咗」。質量分打到 81.1 定 100.0，都係透明可見嘅。

第二層：將欄位變成「數據卡片」

欄位係技術視角，业务人睇唔明；術語係业务視角，但又係孤立嘅。

我哋嘅做法係將兩者喺中間對齊：對每一張表，自動生成一份「數據卡片」，卡片上面同時有技術欄位、业务描述、典型問題示例。一個叫 id_card_name 嘅欄位，喺卡片入面會寫清楚佢係「身份證姓名」、常用嚟同 customer_name 做一致性比對、能夠回答咩嘅业务問題。

业务術語庫（行業模板）係另一條線：財務、電商、化工、製造，每個行業都有自己嘅「術語」。將呢啲詞掛到對應嘅數據卡片上面，問數嘅時候系統就會知道「營收」「流水」「GMV」喺唔同嘅語境下指咩。

第三層：用自然語言問數據

呢個係用戶最直接感覺到嘅一層。前面所有嘅功夫，令呢一步變成可能：

• 揀一張數據卡片（亦即係限定咗問答嘅範圍）

• 用自然語言提問

• 系統生成 SQL、跑查詢、用人話回答

呢一步最容易做出嚟，亦都最容易做死。三個最常見嘅坑我哋都踩過：

1. schema 太大，模型揀錯欄 → 用數據卡片做預篩選

1. 业务詞同欄位名對唔上 → 用術語庫做意圖識別

1. 多表關聯出錯 → 用本體關係約束 join 路徑

第四層：將答案接出去

數據最終要回到业务系統：BI 看板、自動化報表、AI 智能體、API、推送、訂閱。我哋將呢一層做得夠薄——OntiCards 唔係一個封閉嘅 BI 工具，而係數據智能嘅「底座」。上面接咩，由你決定。

同傳統 BI 嘅分別

我哋想 OntiCards 變成點

唔係一個更大嘅 BI 工具，而係一個令數據「被理解」嘅中間層。

我哋希望业务人攞到手嘅唔係一張張看板，而係一個俾人問、俾人搵、俾人再用嘅「數據世界」。我哋希望企業入面嘅隱性知識可以留低，可以俾下一個十年繼續用。

呢個係 OntiCards 嘅存在意義，亦都係我哋每日做緊嘅嘢。