honghulabs 內部策略研究 ·《AI Agent 重塑 IT 維運 — 產業應用與策略地圖》· 產業研究與策略分析
資料與商業智慧副駕:當「用人話問資料庫」成真
《AI Agent 重塑 IT 維運 —— 產業應用與策略地圖》系列 · 第五篇
honghulabs 內部策略研究 · 撰寫對象:負責人 蔡長明
摘要
「我想知道上個月哪個產品毛利最高」——這個問題,過去要嘛你會寫 SQL,要嘛你得排隊等資料分析師。2026 年,你可以直接用中文問,系統秒回。text-to-SQL(自然語言轉查詢)是企業 AI 中最快回本的應用之一:它把「資料」從少數技術人員的禁臠,變成全公司都能對話的對象。
但本篇要講的核心考究是:這個能力的準確度有一個巨大的星號。在「資料模型乾淨」的前提下,準確度可達 90–95%;但在現實世界的混亂資料上,它可能自信地給你錯誤的數字——而一個「看起來對、其實錯」的商業數據,比「沒有答案」更危險。真正的護城河不在模型,在語意層(semantic layer)。
一、為什麼這是最快回本的 AI 應用之一
- 每家公司都有「沒人查得動」的資料:資料躺在資料庫/倉儲裡,但只有少數人會寫查詢。業務決策者想看數字,得提需求、排隊、等分析師——一個簡單問題的答案可能等好幾天。
- 分析師是瓶頸:資料團隊 80% 的時間花在回答重複的、臨時的「幫我拉一下這個數字」,而非做真正的深度分析。
- AI 同時解放兩端:決策者「即問即答」,分析師被釋放去做高價值工作。ROI 直接對應「決策速度」與「分析師產能」——和第一篇 AIOps 一樣,是可換算成錢的硬指標。
二、準確度的真相:90% 的數字背後
廠商會告訴你準確度很高,這是真的——但有嚴格前提:
- Snowflake Cortex Analyst:在真實案例上 90%+ SQL 準確度;資料建模良好時可達 95%。
- Databricks Genie:在其內部基準上提升到 90%+。
但關鍵字是「資料建模良好(well-modeled)」。 這些數字的前提是:存在一個乾淨、定義清楚的語意模型——把「毛利」「活躍客戶」「上個月」這些業務術語,精確對應到資料表的欄位與計算邏輯。
- 有好的語意層 → 90–95% 準確。
- 沒有語意層、schema 混亂、欄位命名隨意 → 準確度斷崖式下跌,AI 開始「猜」,並自信地給出錯誤 SQL。
這是本篇最重要的一句:text-to-SQL 的勝負不在 LLM,在語意層。 投資要投在「把業務語言對應到資料」這件事上,而不是換更強的模型。
三、玩家與打法:倉儲原生 vs 跨源
- Snowflake Cortex Analyst + Intelligence:倉儲原生,靠 語意 YAML 模型做受治理的 NL-to-SQL。強在治理與準確,但調查深度止於「單一查詢的答案」(尚無自動的驅動因子排名、主動告警)。
- Databricks Genie:綁 Unity Catalog 的對話式分析;Genie Research(beta)開始處理「多步驟調查問題」,但自動變異分解、主動監控仍未到位。
- Microsoft Fabric:微軟生態的垂直整合方案。
共同代價:資料集中化。這些倉儲原生方案準確度高,但要求你先把資料搬進它的平台——這是 lock-in,也是導入成本。跨源(不搬資料)的方案彈性高但準確度與治理較難。
四、從「查詢」到「調查」:下一個前沿
目前主流停在 L2「單一查詢」:你問一個明確問題,它給一個數字。前沿正往 L3「多步驟調查」 推進:
| 等級 | 能力 | 例子 |
|---|
| L1 | 自然語言查詢 | 「上月營收多少?」→ 數字 |
| L2 | 帶語意的受治理查詢 | 「上月毛利最高的前 5 品項?」→ 正確聚合 |
| L3 | 多步驟調查 | 「為什麼這季毛利掉了?」→ 自動拆解、找驅動因子、給假設 |
| L4 | 主動洞察 | 在你問之前,主動發現異常並告知「X 客戶的訂單下滑了」 |
L3「為什麼」比 L2「是多少」難一個量級——它要的不只是查詢,是因果推理與假設檢驗。這正是 Databricks Genie Research、各家「AI 資料分析 agent」競逐的下一塊地。
五、侷限與風險:考究的那一面
- 「自信地錯」比「答不出來」更危險:90% 準確意味著 10% 的查詢產生錯誤 SQL——而它不會說「我不確定」,它會給你一個看起來合理的數字。有人據此做了商業決策,才是真正的災難。 沒有答案會讓人去查證;錯誤答案會讓人直接行動。
- 語意層是隱藏的真實成本:90% 準確的前提是有人先把語意模型建好、維護好。沒有語意治理,就沒有可信的 text-to-SQL。 這是導入的地基(再次與前幾篇的「資料/知識治理」同源)。
- 可驗證性:好的方案會把生成的 SQL 攤開給你看,讓懂的人能審查。黑箱「直接給數字、不給 SQL」的方案,在重要決策上不可信任。
- 權限與資料外洩:NL 介面不能變成繞過資料權限的後門;敏感欄位(薪資、成本、客戶 PII)的存取控制必須在語意層強制執行。
- 資料集中化的取捨:高準確的倉儲原生方案要求搬資料進平台 = lock-in + 成本 + 又一份資料副本的資安責任。
六、對 honghulabs 的策略意涵
(1) 對內:讓營運數字「可被對話」
honghulabs 的庫存、營收、成本、機隊產出,目前要看數字多半得有人手動拉。把這些接上 text-to-SQL(哪怕先用開源 + 自建語意層),負責人就能直接問「這個月各礦池產出?」「哪台機效率最差?」——決策速度的躍升。前提一樣:先建好那層「業務語言 ↔ 資料欄位」的語意對應。
(2) ERP / 業務系統副駕是同一個模式
「用中文問你的 ERP」本質就是 text-to-SQL/text-to-API 的應用。它的價值與限制完全適用這篇的結論:準確度取決於你能不能把業務語意定義清楚,而最敏感的財務/庫存資料,正是最不該送上公有 API 的——這把我們帶到產品化角度。
(3) 產品化:私有資料副駕 + 「語意層即服務」
兩個機會:
- 私有 GPU 上的資料副駕:企業的營運資料不出場,推理在 honghulabs 的算力上——又一個「需要可信地端算力」的需求。
- 語意層服務:既然「語意層才是勝負手」,幫客戶建構並維護語意模型,是比賣模型更高黏著、更難被取代的服務(顧問 + 算力的組合)。
七、結論與行動建議
- text-to-SQL 已可用、且回本快——但只在「資料建模良好」的前提下。
- 語意層才是護城河:投資要投在「業務語言 ↔ 資料」的對應與治理,不是換更強的模型。
- 警惕「自信地錯」:要求方案攤開 SQL 供審查;對重大決策的 AI 數據必須二次驗證。「10% 錯誤 + 直接行動」是最大風險。
- 對 honghulabs:先把核心營運數字(庫存/營收/機隊產出)的語意層建好,讓決策可對話化;ERP 副駕是同一條路。
- 產品化雙機會:私有資料副駕(資料不出場)+ 語意層即服務(顧問×算力的高黏著組合)。
本系列下一篇(系列戰略高潮):#6 地端 vs 雲端 LLM:部署、成本與資料主權——前五篇反覆出現同一個結論「最敏感的場景需要可信的地端算力」。這一篇正面回答:什麼時候該自建、什麼時候該用 API,以及這對一家擁有 GPU 的公司意味著什麼。
資料來源(2026 公開資料):
- Promethium,《Text to SQL Tools Comparison 2026: What Actually Works for Enterprise》
- Kanerika,《Databricks Genie 2026: Features, Limits, and Enterprise Fit》
- Colrows,《Snowflake Cortex Analyst vs Databricks Genie: Where Warehouse-Native AI Stops》
- Tellius,《Best AI Data Analysis Agents in 2026》
- Snowflake,《AI-Powered BI》產品頁
- 準確度:Cortex Analyst 90%+(良好建模達 95%)、Databricks Genie 90%+(內部基準)
註:準確度數據高度依賴語意模型品質,廠商數字多基於「良好建模」前提,真實環境因 schema 治理程度而異。