許多企業團隊都有共同的目標：為公司數據打造一個類似 ChatGPT 的分析師。
他們希望用自然語言提問，並從試算表、資料庫、儀表板和內部報告中獲得答案。他們渴望 AI 的速度，同時又不願失去對敏感數據的控制。
這聽起來很簡單，但實際建構起來卻不容易。
私有 AI 數據分析系統不僅僅是連接到檔案的聊天機器人。它還需要受控的存取權限、可靠的運算、審計日誌、模型部署，以及符合團隊實際工作流程的使用者體驗。
企業對私有 AI 數據分析的定義
當一家公司要求私有 AI 分析時，通常同時包含以下幾點：
- 數據不應傳送到未經授權的公開 AI 工具
- 使用者只能看到獲准存取的數據
- 敏感檔案應保留在核准的儲存空間
- 計算過程應可追溯
- 提示詞與輸出應可審計
- 模型應在核准的環境中運行
- 管理員應能控制保留期限與日誌記錄
這就是為什麼通用的 AI 演示（Demo）往往令企業買家失望。演示只能回答問題，但真正的系統必須在回答問題的同時，兼顧身份驗證、權限控管、數據血緣（Data Lineage）和合規性要求。
為什麼只有聊天機器人是不夠的
聊天機器人可以摘要文字、解釋報告或撰寫草稿。
但數據分析不同，許多業務問題需要「運算」。
考慮這個問題：
為什麼第三季的毛利率下降了？哪個地區的影響最大？
一個有用的答案需要多個步驟：
- 識別正確的營收與成本欄位
- 應用毛利公式
- 篩選出第三季的數據
- 與前一期進行比較
- 按地區分組
- 計算各地區對變動的貢獻度
- 結合證據解釋結果
一個僅限檢索（Retrieval-only）的系統可能會找到一份提到毛利的文檔，但它無法可靠地計算出答案。
對於企業分析來說，RAG（檢索增強生成）很有幫助，但遠遠不夠。
私有 AI 分析師的四個層級
一個實用的系統包含四個層級。
1. 介面層 (Interface layer)
這是使用者提問與查看答案的地方。
形式可能是：
- 試算表介面
- 聊天側邊欄
- 儀表板助手
- 內部 Web 應用程式
- 現有工具的 API
對於業務團隊來說，試算表介面通常是最自然的，因為這正是即時分析（Ad hoc analysis）發生的場所。
2. 推理層 (Reasoning layer)
這是 LLM 或代理（Agent）層。
它負責解讀使用者的問題、提出澄清、選擇工具、編寫 SQL 或公式，並解釋結果。
不應將其視為計算結果的唯一事實來源。
3. 執行層 (Execution layer)
這是實際處理數據的地方。
執行層可能使用：
- SQL 倉庫
- DuckDB
- pandas 或 Polars
- 試算表公式引擎
- BI 語義層
- 內部 API
此層級負責計算數值、合併表格、篩選行，並回傳結構化的證據。
4. 治理層 (Governance layer)
此層級控制誰可以存取什麼、記錄哪些內容、數據保留多久，以及如何審核輸出。
它包括：
- SSO 與 RBAC（基於角色的存取控制）
- 行級與列級權限策略
- 審計日誌
- 提示詞與回應的保留控制
- 數據血緣
- 敏感數據脫敏
- 模型與工具權限
沒有這一層，私有 AI 分析師就無法達到企業級標準。
RAG vs 直接分析
當問題涉及文字時，RAG 非常有用。
例如：
- 這項政策說了什麼？
- 淨收益是如何定義的？
- 哪份報告解釋了流失率（Churn）的計算方法？
當問題涉及數據時，則需要直接運算。
例如：
- 哪個地區導致了下滑？
- 按毛利排名的前五大客戶是誰？
- 本月有哪些異常支出？
- 這兩份匯出檔案之間有什麼變化？
最佳的企業架構會結合兩者。
使用 RAG 來檢索定義、業務背景和文檔；使用 SQL、試算表公式或 Python 來計算結果；最後使用模型以自然語言解釋答案。
無法事後補救的治理需求
治理應該在早期就納入設計。
一個私有 AI 數據分析系統應該能夠回答：
- 誰問了這個問題？
- 系統存取了哪些數據？
- 是哪個模型回答的？
- 運行了哪些工具？
- 生成了什麼查詢或公式？
- 回傳了什麼結果？
- 是否有敏感數據被遮蔽？
- 其他使用者能否重現或審核該答案？
這些問題對於受監管的團隊至關重要，對於一般的業務運作也同樣重要。如果 AI 的答案影響了預測或高層報告，必須有人知道數據從何而來。
可觀測性與評估
企業 AI 分析需要的不僅僅是運行時間監控。
營運指標包括：
- 延遲
- Token 使用量
- 模型錯誤
- 工具調用失敗
- 查詢執行時間
- GPU 利用率
- 每個問題的成本
質量指標包括：
- 答案正確性
- 引用準確性
- SQL 合法性
- 公式合法性
- 幻覺事件
- 使用者修正率
- 澄清請求率
優秀的團隊會建立一套包含真實問題與預期答案的測試集。在更改模型、提示詞、工具或檢索設定之前，都會先運行測試。
試算表的特殊需求
試算表是一個特殊案例，因為它們靈活且雜亂。
生產系統應能處理：
- 多個工作表
- 隱藏的工作表
- 公式
- 合併儲存格
- 具名範圍
- 註解
- 不一致的標題
- 匯出的 CSV
- 樞紐分析式的摘要
- 本地日期與貨幣格式
這就是為什麼試算表 AI 不同於通用的文檔問答。系統必須理解結構並執行計算，而不僅僅是摘要文字。
自建 vs 購買
建構私有 AI 數據分析師可以獲得最大控制權，但需要大量的工程投入。許多團隊在決定自建之前，會先規劃所需的功能版圖，從 AI 報告 到儀表板交付：
- 模型部署
- 活頁簿解析
- 提示詞編排
- 數據連接器
- 沙盒化執行
- 存取控制
- 審計日誌
- 評估
- 使用者介面
購買或部署專門的工作流層可以縮短開發路徑。
關鍵在於避免將整個策略綁定在單一模型上。模型更迭迅速，而圍繞公司數據的受控工作流才是持久的資產。
RowSpeak 的定位
RowSpeak 專為試算表原生的 AI 分析而設計，特別適合需要 AI 數據分析 但又不希望使用者直接接觸原始模型端點的團隊。
在私有架構中，RowSpeak 可以位於核准的模型端點和數據系統之上。模型提供推理能力，而 RowSpeak 提供上傳試算表、提問、生成圖表、產出摘要的工作流，並確保分析與底層數據緊密相連。
這使得 RowSpeak 不同於原始的模型伺服器。它是將私有 AI 能力轉化為業務團隊可用分析體驗的關鍵層級，類似於 AI 商業智慧數據策略 中描述的工作流。
結語
私有 AI 分析師不是一個模型加一個提示詞，而是一個受控的系統。
成功的模式是：
LLM 推理 + 確定性運算 + 權限感知的數據存取 + 可審計性 + 使用者熟悉的工作流程。
對於許多企業團隊來說，這個工作流程依然是從試算表開始。
來源與延伸閱讀
- KServe: https://kserve.github.io/website/
- NVIDIA NIM: https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- dbt Semantic Layer: https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
- Snowflake Cortex Analyst: https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
- vLLM OpenAI-compatible server: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
