← 返回博客解決方案

銀行嘅數據資產,點樣由『淨係技術先睇得明嘅庫』變成『業務同事隨口問到嘅數』

基於 OntiCards 數據語義層 + 智能體平台交付:將晦澀嘅表結構翻譯成業務可讀嘅 DataCard,自然語言問數自動生成 SQL 同圖表。AI 產出 2 小時採納率 85%,同業務專家 8 小時產出相當,效率提升 4 倍。

OntiCards 團隊·2026-07-23·8 分鐘閱讀
銀行嘅數據資產,點樣由『淨係技術先睇得明嘅庫』變成『業務同事隨口問到嘅數』

由「淨係技術先睇得明嘅庫」到「隨口問到嘅數」

一家西南地區嘅省級法人銀行,正正將「數據資產」由名詞變成動詞。以前,業務同事想分析「今個月零售存款嘅增長結構」,要先搵數據團隊排需求,字段叫乜名、口徑係乜,都寫喺一份冇人睇得明嘅數據庫字典入面;而家,同樣嘅問題用自然語言直接問,系統自動生成可執行嘅 SQL、推薦合適嘅圖表類型,過程全程可追溯。

呢套能力基於 OntiCards 數據語義層與智能體平台交付。項目驗證嘅結果好有說服力:AI 產出(2 小時)嘅採納率達到 85%,同業務專家 8 小時產出嘅 90% 採納率基本相當,效率提升約 4 倍——即係話,喺保證質量唔跌嘅前提下,分析產出嘅速度被大幅壓縮。

背景與痛點

呢間銀行喺數據資產場景化上遇到四個典型障礙。

其一係數據資產難以被業務理解。 字段含義對業務人員唔透明,數據庫入面幾十上百張表、上千個字段,業務同事唔知「cust_level」係乜意思,更唔知佢同「客戶等級」係咪一回事,數據與場景嚴重脫節。

其二係分析響應鏈路過長。 業務需求必須經過數據團隊嘅人工支持:提需求、排隊、開發、驗證、交付,一個分析往往要等幾日,回應慢、效率低,業務創新節奏被拖累。

其三係 BI 工具使用門檻高。 非技術人員難以自助完成分析——拖拽維度、配置篩選器、理解指標口徑,每一項都係門檻,缺少一個「業務意圖到 BI 操作」嘅橋樑。

其四係數據質量缺乏保障。 分析結論嘅可信度與合規性缺乏全鏈路質量檢查機制,業務唔敢直接用 AI 分析結果做決策。

呢啲問題喺銀行業高度普遍。數據資產越建越多,但「睇得明、用得動」嘅少;大模型越來越強,但叫佢直接「讀庫寫 SQL」嘅結果又唔穩定、唔可控。

我哋點樣做

方案架構總覽
方案架構總覽

項目基於 OntiCards 數據語義層 + 智能體平台,構建一套「三層融合」嘅交付方案。

第一層:OntiCards 數據語義層(核心底座)。 自動掃描業務數據庫,由大模型將晦澀嘅表結構轉化為業務可讀嘅 DataCard——標註字段含義、典型值與跨表關聯,存入向量庫,作為智能問數嘅推理基石。業務同事睇到嘅唔再係「cust_level」呢類天書字段,而係「客戶等級(高/中/低,嚟自客戶分層模型)」呢種睇得明嘅描述。成個過程唔需要 ETL,數據資產由「得技術人員先睇得明」變成「人人可用」。

第二層:雙知識庫體系。 其一係業務場景知識庫,沉澱分析規範與指標口徑;其二係 BI 操作知識庫,沉澱平台操作步驟。兩類知識經智能體平台智能關聯融合,令業務意圖與 BI 操作指令精準匹配——用戶問嘅係業務問題,系統知道應該用邊個指標、行邊條分析路徑。

第三層:智能服務層。 構建「自然語言 → 意圖識別 → 知識檢索 → 分析思路 → BI 分步操作指引」嘅全鏈路響應:自動生成可執行 SQL,智能推薦圖表類型,過程透明可追溯。用戶既可以攞到數據結論,亦都可以睇到每一步係點樣計出嚟。

喺呢個基礎上,項目設計咗三重質量護欄:字段存在性自動校驗,由源頭攔截「問咗個唔存在嘅指標」;知識入庫前強制人工審核,確保入到系統嘅每一份語義描述都經過把關;問答輸出嚴格限定於已審核知識庫,確保輸出可信、可用、可控、可審計。同時,系統唔直連生產數據庫,分析鏈路同生產環境隔離,由架構上保障數據安全與合規。

落地效果

  • 數據資產激活:OntiCards 自動將晦澀表結構轉化為業務可讀嘅 DataCard,數據資產由「得技術人員先睇得明」變成「人人可用」。
  • 效率提升 4 倍:AI 產出 2 小時、採納率 85%,同業務專家 8 小時產出(採納率 90%)相當,分析產出嘅速度大幅壓縮,質量唔跌。
  • 自然語言問數:業務同事直接提問,系統自動生成精準 SQL 並推薦可視化圖表,唔需要掌握 BI 工具操作技能。
  • 端到端分析導航:由業務提問到 BI 操作步驟嘅完整指引,大幅降低分析工具嘅使用門檻。
  • 合規與安全:唔直連生產數據庫,三重質量護欄確保分析輸出合規、可審計。

對銀行嚟講,呢個方案嘅價值唔只係「取數快咗」,而係將沉澱多年嘅數據資產真正轉化為業務生產力——數據同事由重複取數中解放出嚟,業務同事第一次覺得「數據離我好近」。

經驗沉澱:由項目到 OntiCards

呢個項目係 OntiCards 喺金融行業數據語義層嘅直接實踐:將「數據庫表結構 → 業務可讀語義 → 可信問數」嘅鏈路標準化、產品化。我哋從中沉澱咗三條核心經驗。

其一,語義層要由業務嚟讀、而唔係技術嚟讀。DataCard 嘅每一句描述都一定要令業務同事睇得明,否則語義層就會退化成為「數據團隊二次維護嘅 Schema」。其二,護欄與知識要分層設計:字段校驗、人工審核、輸出限定三層護欄,分別攔住「問錯、入錯、答錯」三類風險,層層遞進、缺一不可。其三,唔直連生產係金融場景嘅底線:分析能力可以強,數據邊界必須清晰。

呢啲經驗沉澱落嚟,成為 OntiCards 喺金融行業嘅解決方案。更完整嘅架構視角,可以參閱 OntiCards 四層架構(接入、卡片、問數、消費四層解耦)與 數據語義層嘅實踐思考。行業層面,Gartner 已將語義層視為支撐未來分析與 AI 嘅關鍵組件,Spider 2.0 等接近真實企業環境嘅 NL2SQL 基準亦都證明:冇語義層治理,模型直出 SQL 嘅路行唔遠。

解決方案

對 OntiCards 感興趣?