ERGO Hestia 4 招縮短定價上線
4 個架構調整讓 ERGO Hestia 把定價上線時間縮短，並在單一 lakehouse 內治理 100+ 模型。
這篇在講 ERGO Hestia 如何用 Databricks 把定價資料、模型服務和治理整合起來，縮短上線時間。
看完這 5 個做法，你可以判斷自己該先改資料流、模型呼叫、治理控管，還是部署方式，避免像原系統那樣在 100+ 模型、1,000+ 變數下出現 10x 到 20x 的延遲尖峰。
| 項目 | 規格 A | 規格 B | 規格 C |
|---|---|---|---|
| Lakebase | Delta tables 上的線上特徵層 | 免抽取作業 | 持續同步 |
| Mosaic AI Model Serving | 直接 API 存取模型 | 毫秒級請求路徑 | 少一層 adapter |
| Unity Catalog | 資料與模型統一治理 | 血緣可追蹤 | 版本與保留一致管理 |
| Azure DevOps CI/CD | 分階段部署 | 降低切換風險 | 保留既有 ETL |
1. Lakebase 把線上特徵留在 lakehouse
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Lakebase 讓 ERGO Hestia 把定價所需的線上特徵，直接放在 Lakebase 與 Delta tables 的組合裡，不必再匯出到 PostgreSQL。這一步先解決的是資料搬運本身，而不是先去優化模型。
對定價系統來說，少一次抽取，就少一次延遲與失真來源。Sync Tables 讓處理後資料和服務資料持續對齊，團隊也不用靠人工批次補資料。
- 資料留在 Databricks 內部
- Sync Tables 自動更新
- 不再依賴外部資料庫匯出
2. Mosaic AI Model Serving 直接接模型
Mosaic AI Model Serving 取代了原本夾在定價引擎和服務資料庫之間的 adapter 層。請求現在直接打到託管端點，路徑更短，維護點也更少。
這種改法最適合需要毫秒級回應的場景。少掉自建快取和轉接邏輯後，白天流量波動時比較不容易被某一層卡住。
Pricing engine -> Model Serving Endpoint -> response in milliseconds3. Unity Catalog 讓模型和資料共用治理面
Unity Catalog 把資料、模型版本、血緣和保留政策放進同一個控制面。對保險業這種受監管環境來說，這不只是管理方便，而是能回答「這個價格怎麼算出來」的必要條件。
它也讓測試更安全。定價專家可以在同一個受治理環境裡驗證 live data、做 A/B 測試，還能保留完整歷史紀錄，方便事後稽核。
- 模型版本先註冊再服務
- 訓練資料保留可追溯
- 資料層與模型層都有血緣
4. 分階段遷移，比一次切換更穩
ERGO Hestia 沒有一次把整套系統翻掉，而是保留既有 ETL，先把同步資料導到 Lakebase，再逐步擴大使用範圍。這種做法降低風險，也讓每一步都能先驗證。
如果你的業務不能停機，這會比大改寫更實際。它的重點不是加更多工具，而是把原本多餘的跳轉一層一層拿掉，讓新舊系統可以並行。
- 既有 ETL 繼續運作
- 同步路徑從 PostgreSQL 轉到 Lakebase
- Azure DevOps 負責部署流程
5. 先改資料流，再改定價速度
最後的結果，是一套能隨市場變化即時反應的定價架構，不必再等排程刷新。對 ERGO Hestia 來說，這代表定價模型可以更快上線，也能支援 real-time B2C pricing。
對一個跑 100+ 模型、1,000+ 變數的團隊，真正的價值不只是快，而是把定價變成可持續迭代的成長機制，從資料進來到對外決策都更清楚。
怎麼挑
如果你最痛的是資料搬運，先看 Lakebase；如果卡在模型呼叫延遲，先改 Mosaic AI Model Serving；如果你最怕稽核和版本混亂，Unity Catalog 應該先上。
若你正在現有生產系統上做現代化，且不能接受高風險重寫，最值得抄的是分階段遷移。ERGO Hestia 的案例說明，提速通常不是靠多加一層，而是把不必要的 hop 拿掉。