Text-to-SQL 中小企業 BI 採購完整指南：老闆自己查、不再排隊等資料工程師的 5 條 LLM 路徑與 4 個治理風險

每隔幾個月，我們就會接到類似的詢問：「我想知道上個月哪個業務員的業績最好、哪個產品利潤最薄——這應該不難吧？」

結果通常是這樣的：資料在 ERP 裡，ERP 廠商要收模組費才開報表，IT 說要排程，這個需求就這樣被擱了三個月。

這不是特例。Gartner 2025 年的調查顯示，超過 60% 的中小企業老闆每週至少有一次「想查數據但只能靠印象決策」的狀況——真正能自助查詢的，不到 15%。大多數人卡住的地方，是資料在系統裡，但查詢能力被資料工程師或廠商顧問當成稀缺資源。

Text-to-SQL 的出現，是為了把這道牆打掉：你用自然語言說「查上個月利潤前十的 SKU」，AI 把它翻成 SQL，資料庫回你表格。理論上，老闆自己查，不用排隊。但理論到落地之間，有五條走法、四個治理風險、一個採購決策框架——這篇就是這三件事。

為什麼「老闆自己查」在 2026 年終於可行

BI 工具存在幾十年了，Tableau、Power BI、Metabase 都很成熟。但它們有個共同前提：你得先「建好儀表板」。建儀表板要資料工程師定義 schema、建 dimension table、設 refresh 排程——通常要花幾週到幾個月，之後改一個指標又要走一輪流程。

Text-to-SQL 的核心差異是：把「查詢界面」從 drag-and-drop 換成自然語言。LLM 扮演翻譯員，把你的問句翻成 SQL，直接打到資料庫。你需要準備的，是讓 LLM 認識你的 schema——而不是讓工程師把每個可能的問題都預先建成儀表板。

驅動這件事在 2026 年變可行的，是兩個技術進步：一是 LLM 的 context window 夠大，能吃進完整 schema 定義；二是推理能力夠強，能處理多表 JOIN、subquery、條件篩選，不再只能應付單表簡單查詢。Snowflake Cortex、Mode AI這類 SaaS 在 2025-2026 年都在快速往 Text-to-SQL 方向整合，正是這個風向的具體指標。

Text-to-SQL vs 傳統 BI：差在哪裡

五條 LLM 路徑全解析：從最簡單到最強大

市面上的 Text-to-SQL 做法，從技術複雜度到準確率，可以分成五條路徑。沒有最好，只有最合你的規模和需求。

路徑一：原生 LLM 直譯（最快，適合 POC）

做法最直接：把你的 schema DDL（建表語句）貼進 system prompt，讓 GPT-4o 或 Claude Sonnet 直接翻成 SQL。這是大多數人第一次嘗試的方式，實作時間通常不超過一個下午。

• 優點：零架構成本，prompt engineer 就能做
• 缺點：schema 一大就 token 爆，且沒有業務語意（欄位名叫 amt，LLM 不知道是含稅還是未稅）
• 適合：驗證可行性的 POC、資料表不超過 20 張的小系統

路徑二：RAG schema-aware（加業務語意層）

在 LLM 之前加一層向量搜尋：把 schema 文件（含欄位說明、業務定義、常見查詢範例）向量化存進 vector DB，查詢時先用 similarity search 找出相關表和欄位，再把這個「精準 context」送給 LLM。

• 優點：能處理大型 schema（100+ 張表），準確率顯著提升
• 缺點：需要維護 vector DB，且 schema 文件要人工撰寫才有效
• 適合：中型企業、schema 複雜、表數超過 30 張的情況

路徑三：Fine-tuned 小模型（企業資料不出境）

用企業自己的 SQL query log（歷史查詢 + schema）微調一個輕量模型（如 Llama 3.1 8B 或 Qwen 2.5）。好處是模型能在本地或私有雲跑，資料完全不出企業邊界。

• 優點：資料主權最強，推理成本低（小模型）
• 缺點：fine-tuning 要有足夠的 query log（通常 500+ 條），且模型需要定期 retrain
• 適合：有資安合規要求、資料絕對不能出去的製造業、金融業

路徑四：Hybrid 規則 + LLM（最穩定的生產架構）

把常見的固定查詢（週報、月報、KPI 儀表板）用規則 template 處理，只讓臨時性 ad hoc 查詢走 LLM 路徑。兩條路徑共用同一個介面。

• 優點：固定報表零 hallucination，LLM 只處理它最擅長的彈性查詢
• 缺點：需要分類器判斷哪條路徑，架構複雜度增加
• 適合：已有穩定報表需求 + 想加入 ad hoc 查詢的企業

路徑五：Agentic 多步驟查詢（最強大，最複雜）

讓 AI agent 自主規劃查詢步驟：先查哪張表、結果不對就自動修正 SQL、需要的話再 JOIN 另一張表、最後把多個查詢結果整合成回答。這是 2026 年開始在大型企業 PoC 中出現的做法。

• 優點：能回答跨多表、需要多步推理的複雜問題
• 缺點：延遲高（多次 LLM call）、debug 難、幻覺風險乘以步驟數
• 適合：有全職 AI engineer 的團隊，不適合直接外包給廠商然後不管

在我們做客製化系統的觀察裡，大多數中小企業在第一年應該從路徑二或四進入——路徑一夠了就不用升，路徑五目前在中小企業場景基本沒有 ROI。

四個治理風險：老闆能查不代表可以亂查

Text-to-SQL 把查詢門檻降低，但「誰能查什麼」的問題沒有消失，只是換了形式。以下四個風險，是業界在 Text-to-SQL 生產環境踩過的真實坑。

風險一：資料權限外洩

自然語言查詢最大的危險，是讓員工能輕鬆問出「他不應該看到」的資料。一個業務查「所有客戶的歷史交易金額」，或是 HR 助理問「哪些員工薪水最高」——LLM 如果沒有 row-level security 機制，它就會把 SQL 生出來、資料庫就回答。

實作建議：為每個角色建立對應的 database role，Text-to-SQL 用該角色連線執行 SQL，而不是用超級管理員帳號。

風險二：錯誤 SQL 跑爆資料庫

LLM 生成的 SQL 不一定正確，也不一定有效率。一個沒加 LIMIT 的全表掃描，可能讓你的 RDS 瞬間 CPU 100%。一個錯誤的 Cartesian product，可能回傳幾百萬列資料把你的應用層打掛。

• 必須加 SQL validator：在執行前用 EXPLAIN 或 dry-run 模式估算查詢成本
• 強制加 LIMIT：所有 LLM 生成的 SELECT 自動附加 LIMIT 10000 ceiling
• 禁止 DDL / DML：Text-to-SQL 只允許 SELECT，不允許 INSERT / UPDATE / DELETE / DROP
• Rate limiting：每個用戶每分鐘查詢次數上限

風險三：業務語意誤解

老闆問「上個月的銷售額」，LLM 可能查 order_date、也可能查 payment_date、也可能查 invoice_date——哪一個才算「銷售額」，是業務定義，不是 LLM 能自己猜的。

這是 Text-to-SQL 最難解的問題。技術再好，欄位名叫 rev_amt 而沒有文件說明它是含稅的，LLM 就會猜錯。解法是建立 semantic layer：用文件明確定義每個關鍵業務術語對應哪個欄位、哪個條件。這件事要人做，不能全丟給 AI。

風險四：審計與合規

在有合規要求的行業（金融、醫療、上市公司 IR 部門），「誰在什麼時間查了什麼資料」必須留下 audit log。Text-to-SQL 如果直接打到資料庫，中間沒有紀錄層，稽核的時候就什麼都沒有。

架構上必須在 Text-to-SQL 層記錄：原始自然語言問句、翻譯後的 SQL、執行者 ID、時間戳、資料庫回傳的 row count。這不只是合規，也是 debug 和持續改善系統準確率的基礎。

採購決策框架：自建、SaaS，還是讓廠商包？

市場上的選擇可以分三類：純 SaaS（Mode AI、Hex Magic、Snowflake Cortex）、自建（把路徑一到五自己做）、外包客製化（找廠商按你的 schema 和業務語意做一套）。決策關鍵不是哪個最強，是哪個最符合你的規模和風險承受度。

SaaS 方案比較

ROI 試算框架

在評估是否值得投入 Text-to-SQL 之前，先算這三個數字：

• 目前你的團隊每月花多少時間在「等報表 / 手動撈資料」：（人力小時數 × 時薪）
• 這些查詢中有多少可以被 Text-to-SQL 取代（估 40-70%）
• 建置成本（SaaS 月費 或 開發費用）÷ 每月節省的人力成本 = 回本月數

自建 vs SaaS：五個決策紅線

選 SaaS 還是自建，以下五個情境是清楚的分水嶺：

有個常見的誤判：「我們系統比較特別，SaaS 一定不合用。」其實大多數中小企業的查詢需求沒那麼複雜，SaaS 試用 30 天就知道夠不夠用。先試 SaaS，試完再決定要不要客製化，是比較有效率的做法。

這篇說的「客製化系統開發」，在我們的AI 系統開發服務範疇內。如果你的 schema 複雜、或有特殊的業務語意定義需求，我們很樂意聊聊你的情況適合哪條路徑。

中小企業常見的三個採購誤區

誤區一：以為 Text-to-SQL 能處理非結構化資料

Text-to-SQL 的前提是：資料要在關聯式資料庫裡，而且 schema 要整齊。如果你的業績數字還在 Google Sheet，客戶資料在 LINE 群組記事本，那 Text-to-SQL 在你這裡的先決條件還沒到。要先有「可查詢的資料庫」，才能接 Text-to-SQL。

誤區二：語意層可以偷懶不做

很多人 POC 成功了就直接上線，結果老闆查「本月毛利」得到一個數字，財務查「本月毛利」得到另一個數字——因為兩個人說的「本月」定義不一樣（會計月 vs 自然月），「毛利」的算法也不一樣（含不含退貨？含不含倉儲成本？）。語意層是 Text-to-SQL 準確率的地基，沒有它，準確率永遠在 60-70% 天花板晃。

誤區三：準確率 90% 就夠了

十次查詢錯一次，聽起來不嚴重。但如果那一次錯誤恰好在月底財務結算、或是老闆用來做年度預算，後果可能遠超一次報表出錯。高風險查詢（財務、HR 薪資、客戶資料）需要額外的 SQL 審查機制，不能全部自動放行。

這讓我想到一個相關的觀察：很多公司在導入客製化 SaaS 多租戶架構的時候也有類似問題——技術層面可行，業務語意層沒對齊就先上線，後期維護成本遠高於預期。

我們怎麼看 Text-to-SQL 在中小企業的真實落地

我們做過這件事

下一步：先搞清楚你的資料架構，再選路徑

在談 Text-to-SQL 採購之前，有兩件事值得先確認：你的核心業務資料現在在哪裡（哪個系統、哪種 DB）、以及最常被問的前 10 個查詢問題是什麼。有了這兩份清單，選哪條路徑就清晰很多。

如果你的情況比較複雜——資料散在多個系統、或是有合規要求、或是 schema 文件幾乎是零——我們很樂意聊聊你的現況，一起看看從哪一塊開始最值得。

也可以參考我們整理的相關文章：

• AI 模型 Fine-tuning vs RAG：成本決策指南
• 客製化 SaaS 多租戶架構：3 種資料隔離模式
• MCP + RAG 企業混搭架構完整指南
• 企業 AI 導入自動化完整指南
• 系統發包前 SOW + 規格書 + 合約完整指南

常見問題