在地端執行大型語言模型（LLM）僅僅是第一步。
如果目標是進行 AI 試算表分析，單靠模型端點（Endpoint）是不夠的。企業用戶並不想向內部的推論伺服器發送原始 JSON 資料；他們希望的是上傳活頁簿、提出問題、獲得可靠的答案、建立圖表，並清楚知道數據的來源。
這需要圍繞模型建立一套完整的架構。
本指南將說明地端 AI 試算表系統的主要組成部分。
參考架構
一個實用的地端 AI 試算表架構如下圖所示：
雖然順序可能有所不同，但原則是一致的：LLM 負責推理與解釋，而受控系統則負責處理資料存取、運算、安全性和可稽核性。
身分與存取控制
從身分驗證開始。
每一個 AI 給出的答案都應該與特定的使用者、工作區、檔案以及權限決策掛鉤。
企業級部署通常需要：
- 透過 SAML 或 OIDC 進行單一登入（SSO）
- 角色型存取控制（RBAC）
- 來自身分提供者（IdP）的群組映射
- 工作區層級的權限
- 檔案層級的權限
- 資料集白名單
- 管理員控制項
如果系統連接到資料庫或物件儲存空間，則不應繞過現有的權限設定。AI 不應成為規避治理的捷徑。
活頁簿擷取 (Workbook Ingestion)
試算表的資料擷取比表面上看起來更困難。
一份真實的活頁簿可能包含：
- 多個工作表
- 隱藏的工作表
- 公式
- 合併儲存格
- 不一致的標題
- 命名範圍
- 註解
- 帶有特定含義的格式
- 受保護的工作表
- 圖表與樞紐分析表
- 外部連結
- 巨集
生產環境系統必須解析出足夠的結構資訊，以避免模型對資料產生扭曲的理解。
出於安全考慮，應謹慎處理啟用巨集的檔案。如果系統需要執行任何內容，應在沙盒（Sandbox）中進行。在許多部署場景中，巨集應被掃描、攔截或視為元數據（Metadata），而非直接執行。
試算表理解
擷取資料後，系統應建立一個有用的活頁簿表示模型（Representation）。
這可能包括：
- 工作表摘要
- 表格邊界
- 欄位名稱與推斷的類型
- 樣本列
- 公式依賴圖
- 偵測到的指標
- 日期範圍
- 缺失值
- 異常值
- 跨工作表或檔案的關聯性
模型首先看到的應該是這個表示模型。將整個活頁簿直接塞進提示詞（Prompt）通常是浪費且具風險的。
目標是給予模型足夠的上下文來規劃下一步，而不是讓模型死記硬背整個檔案。
確定性運算層 (Deterministic Compute Layer)
對於試算表 AI 來說，這是最重要的組件之一。
模型不應在內部計算關鍵數據，而應「調用工具」。
運算層可能包括：
- 試算表公式
- SQL
- DuckDB
- pandas
- Polars
- 數據倉庫下推（Warehouse pushdown）
- 圖表生成
- 驗證檢查
例如，如果使用者詢問營收最高的前幾名客戶，模型可以識別正確的欄位並生成查詢語句。接著由運算層執行查詢，最後再由模型解釋結果。
這種分離提高了準確性、速度和可稽核性。
私有模型服務
模型層可以透過多種方式提供服務。
vLLM 常見於高吞吐量的自託管推論，並提供與 OpenAI 相容的伺服器。
KServe 適用於希望實現 Kubernetes 原生模型服務和標準化推論服務的組織。
NVIDIA NIM 為 NVIDIA 加速基礎設施提供優化的推論微服務。
Ollama 適用於試點計畫和本地測試，但生產環境部署通常需要更強的擴展性、存取控制和可觀測性。
模型層應被視為內部基礎設施：
- 經過身分驗證
- 具備版本控制
- 受到監控
- 透過網路控制進行隔離
- 配置明確的資料保留政策
- 在模型升級前進行評估
AI 編排 (AI Orchestration)
編排層決定系統如何使用模型和工具。
它負責處理：
- 提示詞模板
- 模型選擇
- 工具選擇
- 上下文構建
- 澄清問題
- 查詢驗證
- 代碼沙盒化
- 重試邏輯
- 回應格式化
這是許多安全控制項所在的層級。
例如，如果模型生成了 SQL，系統應驗證該 SQL 是唯讀的、僅限於允許的表格，且運算成本不會過高。如果模型生成了 Python 代碼，系統應在禁用網路存取的沙盒中執行（除非明確允許）。
可稽核性 (Auditability)
在嚴謹的部署中，稽核日誌是不可或缺的。
一份有用的日誌應包含：
- 使用者
- 時間戳記
- 存取的活頁簿或資料集
- 提示詞
- 模型名稱與版本
- 生成的查詢、公式或代碼
- 工具輸出結果
- 最終答案
- 權限決策
- 錯誤與備援方案
這並不意味著每個敏感數值都必須永久儲存。保留期限應該是可配置的。但系統需要足夠的可追溯性，以便進行審查、除錯和合規檢查。
可觀測性 (Observability)
技術團隊需要同時監控基礎設施和答案品質。
基礎設施指標：
- 延遲
- GPU 利用率
- 隊列深度
- Token 使用量
- 模型錯誤
- 工具執行時間
- 儲存空間使用量
品質指標：
- 答案正確性
- 引用品質
- 公式有效性
- 查詢成功率
- 使用者修正次數
- 幻覺報告
- 失敗的澄清請求
缺乏可觀測性，團隊就無法得知 AI 分析師是在進步，還是在悄悄產出不可靠的結果。
常見陷阱
將模型視為試算表引擎
這會導致計算結果出現幻覺和脆弱的答案。請使用工具進行計算。
先檢索後過濾
權限強制執行應在上下文到達模型之前完成。
忽略活頁簿的複雜性
CSV 的展示並不能證明系統可以處理真實的 Excel 檔案。
記錄過多敏感資料
可稽核性很重要，但日誌也必須遵循資料保留和隱私規則。
圍繞單一模型構建
模型更迭迅速。構建工作流時應確保模型是可以更換的。
分階段導入計畫
現實的導入可以分階段進行：
- 使用樣本或脫敏後的試算表建立原型。
- 驗證常見的分析任務和失敗案例。
- 為所有數值運算加入確定性運算層。
- 在使用真實檔案前連接身分驗證與權限系統。
- 透過 vLLM、KServe、NIM 或其他核准的技術棧部署私有模型端點。
- 加入稽核日誌與監控。
- 與一個團隊進行試點，通常是財務、營運或銷售報告團隊。
- 在擴大範圍前，針對已知答案評估輸出結果。
這可以避免常見的錯誤：在治理層尚未建立之前，就將模型 Demo 直接轉為生產系統。
RowSpeak 的定位
RowSpeak 可以作為私有模型端點和受控資料執行之上的工作流層。
模型伺服器提供推理能力，而 RowSpeak 提供試算表體驗：活頁簿上傳、自然語言提問、圖表、摘要、報告，以及像 每週銷售報告 這樣的使用者分析流程。
對於地端部署，這種分離非常有價值。IT 部門可以控制模型和基礎設施，而業務使用者仍然可以透過專為試算表分析設計的介面進行工作，無論最終結果是 AI 儀表板 還是財務報告，都不必處理原始的 API 調用。
結語
地端 LLM 端點是基礎設施。而地端 AI 試算表分析師則是產品體驗加上治理。
模型固然重要，但圍繞它建立的架構決定了系統是否值得信賴。有關特定模型的範例，請參閱 為 RowSpeak 自託管 DeepSeek 的相關指南。
來源與延伸閱讀
- vLLM OpenAI 相容伺服器：https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
- KServe：https://kserve.github.io/website/
- NVIDIA NIM：https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- Ollama 函式庫：https://ollama.com/library
- llama.cpp：https://github.com/ggml-org/llama.cpp
