基礎模型徹底改變了企業從非結構化資料中獲取價值的方式。然而，更大的潛力在於串流資料，因為許多關鍵任務決策都源於此，例如：訂購多少、停止哪筆付款、幫浦何時會故障、生產線應如何運作，以及上次出現類似情況時發生了什麼。IBM 和 Confluent 現正將此能力帶入串流原生環境，這些模型已在 Confluent Cloud 上開放搶先體驗，直接在資料流動處運行，Confluent Platform 也將隨後推出。

\n\n迄今為止，這些決策一直依賴過時的經濟模式：每次一個客製化模型，每個模型都需要數月的專家工作。因此，團隊只能針對少數幾個與利潤相關的序列建立模型，其餘則以安全邊際、額外庫存、額外餘裕和額外容忍度來應對，但往往在機會之窗關閉後才採取行動。

這些邊際成本，正是每次循環中為無法預測的決策所付出的代價。\n\n時間序列基礎模型（TSFM）改變了這種現狀。它只需一次訓練，就能處理大量且多樣的訊號，並泛化到從未見過的序列：給予它一段測量數據，它就能告訴你接下來會發生什麼、行為偏離正常的程度、哪些歷史數據與當前情況相似，以及哪些設定最能達成目標。

使用這些模型也不需要龐大的資料科學家團隊：需求規劃師、詐欺分析師或製程工程師都能將這些模型應用於自己的資料串流。圍繞著這些模型，IBM 正在開發能夠「左移」工作的功能，讓預測、異常偵測、最佳化和語義智慧成為可直接呼叫的能力，而非需要從頭建立的專案。

\n\n想像一下巧克力工廠中的一條調溫生產線，其溫度、速度和產量每隔幾秒鐘就被取樣一次，並與固定閾值進行監測。將基礎模型導入該串流後，它能預測晚班的生產線產出，讓規劃人員在仍有時間採取行動時發現短缺。它會根據生產線處理黑巧克力的正常行為來評估今天的運行狀況，因此在巧克力條出現問題之前，就能發現緩慢的偏差。

它還能在工廠歷史中找到最接近的匹配，讓工程師了解上次類似運行結果如何。它能根據操作人員控制的設定進行條件化，並在最後一點精確度值得時進行微調。這一切都不需要資料科學團隊，而且同一個模型可以應用於每間工廠的每一條生產線。\n\n在推出這些模型之前，IBM 已在其自家產品和營運中率先運行，隨後與水泥、鋼鐵、紙漿和造紙、食品及電信領域的設計合作夥伴共同測試。

數據證明了其價值：每提高一個精確度點數都價值數百萬美元，生產力提升達 5 到 10 倍，而過去需要專家處理的工作，現在則由掌握決策權的領域專家負責。\n\n現在，這項驗證與即時情境結合：IBM 帶來了理解訊號行為的前沿模型，擁有超過 4400 萬次的下載量；而 Confluent 則提供了業務的即時狀態，並能觸及每個執行系統。

它們共同以串流原生方式運行，託管於 Confluent Cloud 並透過 Flink 呼叫。目前已在 AWS 上的 Confluent Cloud 開放存取，Confluent Platform 也將隨後推出，將相同的模型和功能帶到地端和混合環境。

\n\n通常用於將模型整合到生產環境的數月時間，現在可以省下來了：Granite 負責讀取訊號，Confluent 則提供情境、治理以及向下游所有系統的交付。\n\n訊號的價值會隨時間衰減：今天發現幫浦有偏差，可能只是一張工單；但如果同樣的幫浦到下週才發現，就可能導致停機。

\n\n預測和偵測都是有狀態的：下一個數值只有在與近期歷史數據對比時才有意義，而異常也只有在與持續運行的「正常」狀態對比時才存在。Flink 負責管理這種狀態，它按序列鍵控並具備容錯能力，因此每個模型都能獲得所需的歷史數據，而無需單獨的資料儲存或每次呼叫都存取資料庫。

\n\n這正是價值倍增之處。Confluent 的資料串流平台讓業務資料動起來，並使其可用於機器學習。該平台持續串流、連接、治理和處理即時資料，捕捉即時業務訊號，供 IBM Granite 時間序列模型用於預測、異常偵測、相似性搜尋、分類、資料填補和最佳化。

Confluent 提供您快速、可靠且安全地實施串流使用案例所需的一切，讓您能專注於開發即時機器學習應用程式，而非管理資料基礎設施。\n\nConfluent Cloud 是 Confluent 資料串流平台的雲端部署，提供原生推論功能，讓您能夠直接在 Confluent 上的 Apache Flink® 中運行 IBM Granite 時間序列模型。

這為即時資料處理提供了更大的靈活性、安全性與成本效益，同時整合了資料和機器學習工作流程。其優點包括：\n\n資料所在之處的即時智慧：直接在串流資料上運行預測和異常偵測，在業務狀況變化的那一刻即時處理，無需將時間序列資料提取到單獨的機器學習平台或資料倉儲。

\n\n零配置：Confluent 管理模型服務、基礎設施、擴展和運行操作，因此無需管理供應商憑證，也無需在資料管道和模型之間進行繁瑣的連接。您可以直接從 Flink SQL 呼叫 IBM Granite 時間序列模型，進行即時異常偵測和預測。

\n\n新鮮、豐富的情境：Confluent 持續捕捉和處理資料，形成業務當前狀態的最新視圖，從感測器遙測和支付活動到應用程式指標，讓模型能夠根據當前發生的情況而非過時的批次資料採取行動，從而做出更可靠、更準確的預測。推論結果會寫入 Kafka 主題並進行扇出共享，可供警報系統、儀表板、資料湖倉和 AI 代理程式使用。

\n\n內建治理和可追溯性：推論管道遵循與平台上所有其他內容相同的架構、沿襲和存取控制。Kafka 主題具有持久性和可重放性，支援稽核、故障排除、模型評估以及針對歷史資料重新運行推論。\n\n成本效益：原生推論消除了配置和管理專用模型服務基礎設施或 GPU 的需求，且沒有雲端資料進出費用。

\n\n增強安全性：資料在 Confluent Cloud 內進行推論，並在整個平台中遵循 RBAC 和隱私政策。\n\n更快的價值實現時間：團隊可以使用熟悉的 SQL 語法，在幾分鐘內從串流資料轉變為可運作的預測和異常偵測管道，而無需建立單獨的機器學習堆疊或點對點資料管道。

\n\n透過連接營運和分析領域，Confluent 幫助團隊將即時業務事件轉化為可操作的智慧，將 IBM Granite 時間序列模型引入串流。由於沒有單一模型能同時服務洗髮水生產線、信用卡網路和零售目錄，IBM 和 Confluent 提供的是模型組合，而非單一模型。

\n\n每項決策都對未來提出不同的問題。規劃週期需要一系列結果，交易台需要每個費率下最準確的數據，十萬個序列的車隊需要保持合理的成本，而安全團隊則需要知道串流何時停止正常行為以及上次發生這種情況時發生了什麼。這個組合包含四個互補的時間序列基礎模型，目前都處於搶先體驗階段，可透過 Confluent 現有的 AI_FORECAST 和 AI_DETECT_ANOMALIES Flink SQL 函數呼叫。

只需一個 SQL 參數即可切換模型，無需重新設計管道。\n\n整個專案只需一次呼叫即可完成。\n\n更改模型值，同一個呼叫就能運行四個模型中的任何一個，無需建立或操作單獨的機器學習堆疊。\n\n沒有單一的最佳模型，因此有幾個問題可以引導選擇。

是一個序列還是數千個？一個變數還是多個？需要訓練時間，還是開箱即用？預測多遠？是預測，還是異常偵測？PatchTST-FM 像語言模型讀取文本一樣，逐塊讀取序列，每個變數在自己的通道中，這樣一個嘈雜的訊號就不會拖垮其他部分，並返回完整的分布，讓規劃人員可以根據第 90 個百分位數設定再訂購點。

FlowState 則會隨著每個數據點更新運行中的摘要，由於其動態在時間上是連續的，因此它能同時讀取秒級的 SCADA 和小時級的市場數據。TTM 捨棄了注意力機制，轉而採用沿時間和跨變數的微小混合網路，因此一個百萬參數的模型每晚可以在 CPU 上處理十萬個序列。

而 TSPulse 則在一個小型多任務模型中結合了時間和頻率視圖，用於異常偵測、分類、資料填補以及每個操作員都會問的問題：我們以前見過這種情況嗎？\n\n「小」是一個決定，而非妥協：推論可以在 Confluent Cloud 內部原生運行，或者在您自己的 CPU 上使用來自 Hugging Face Hub 的開放權重，而且沒有雲端資料進出費用，這使得架構保持簡單並降低成本。

IBM Granite 還帶來了 IBM 的企業 AI 治理框架，包含模型來源和授權透明度，以及越來越多的模型功能，使每個使用案例都能開箱即用。這正是模型組合與平台結合之處，模型不再是過去的圖書館管理員，而是正在進行中的決策最佳化工具。\n\n這四個模型都能縮短事件發生與得知事件之間的時間。

在串流中，這個時間差從數天縮短到數秒，訊號成為其他 AI 系統、代理程式和工作流程的觸發器，它們負責調查、分類重要事項，並在決策需要人工介入時，將已收集的情境傳遞給人類。這四個模型也都被打包成功能，因此大部分工作都由平台完成，使用者團隊的負擔更輕。

\n\n大多數預測仍然是統計模型和直覺判斷包裝成的決策。客製化機器學習未能彌補這一差距，每個序列一個模型，手動重新擬合並隨時間推移而漂移，因此規劃只涵蓋了少數值得投入的序列，其餘則依賴安全庫存。\n\n想像一位雜貨零售商的需求規劃師，她的規劃只觸及商品目錄的前端，而忽略了作為營運資金滯留在貨架上的尾端商品。

她將一個共享模型指向整個目錄：它能立即處理未見過的序列，考慮天氣和促銷等驅動因素，並返回一個分布而非單一線條。無需為每個 SKU 建立模型，因此一個模型就是一個模型工廠：一個兩年的 SKU 和一個三個月的 SKU 在同一個任務中處理，一個沒有歷史記錄的新品可以從相似的 SKU 開始預測，每晚在 CPU 上處理 10 萬個 SKU，並且在不同類別和地區都能應用相同的策略。

\n\n這個分布將服務水準轉化為她可以明確表達的政策。而且由於每個預測都落在一個主題上，它是一個觸發器而非報告：補貨從中啟動，分配和定價讀取相同的數字，降價在庫存老化前發生，補貨在貨架清空前進行。這些結果體現在業務績效的關鍵指標上：更少的缺貨和降價、顧客能找到他們想要的商品、貨架上的營收得到保護，以及釋放的營運資金，這通常是業務案例中最大的一項。

\n\n異常偵測是應用最廣泛的領域，而一次錯過的異常很少是小問題：在詐欺中，它關乎客戶的錢財；在安全方面，它是一次資料外洩；在 IT 營運中，它是客戶首先遇到的停機，每一次都會對品牌和資產負債表造成同樣嚴重的打擊。在金融服務領域，基於規則的偵測是可列舉的，因此對手也會列舉它。