想知道哪些顧客會再下單，資料團隊通常先把顧客、訂單、商品表整理成一份特徵表，再訓練預測模型。NVIDIA 10 月 21 日介紹的 Kumo Relational，把這段流程改成：寫出預測問題，系統從多張表找出相關歷史，再交由模型預測。
對已有交易資料的台灣電商與會員服務團隊，換一個預測問題，不必每次從特徵工程與模型訓練重新開始。例如由「誰會再買」改問「接下來會買多少」，可以重新定義查詢目標，沿用關聯資料與模型。這有機會讓原本排不上開發時程的預測需求，也能先做小規模比較。
十月這篇文章詳解的是整套方法與使用入口；NIM 規格頁另列 1.0.0 容器日期為 8 月 18 日。因此，不宜把本週介紹直接寫成這個模型的首次公開。
多張表保留哪些線索？
把訂單攤平成顧客平均消費金額，容易操作，卻也把原始關係壓縮了。Kumo Relational 先處理各表的欄位與資料列，再沿主鍵、外鍵交換資訊，最後把已知答案的歷史範例與待預測對象放在一起比較。模型因而能利用顧客如何連到訂單、訂單如何連到商品的細節。
運作文件把這個過程稱為上下文學習：模型在推論時接收範例，基本流程不更新權重。歷史範例包含某個時點可取得的相關紀錄，以及後來實際發生的結果。系統從這些對照中估計新的對象，並非把整座資料庫直接塞進聊天提示詞。
實際問題可用預測查詢語言 PQL 表達。文件範例包括「指定顧客未來 30 天是否至少下一張訂單」，也能改成「未來 30 天的總消費金額」。前者得到事件預測，後者得到數值預測；同樣的顧客與訂單關係可以服務不同問題。
這個介面最有意思的地方，是資料分析工作更接近提出可計算的問題。回購窗口、顧客名單與目標金額仍由業務定義，但每個新問題不一定要配一套獨立訓練流程。對經常收到臨時分析需求的團隊，這比單看一項榜單分數更有實務分量。
時間也是這套方法的一部分。時間控制文件允許指定歷史預測時點，分開安排預測與範例的時間範圍。回購問題應以當時可得的紀錄形成線索，再用後來的訂單核對結果；顧客編號與時間欄位若不一致，仍須先完成資料清理。
哪些團隊值得開始用？
我會優先把它用在已有清楚顧客、訂單關係，卻常因建模成本而放棄的新問題。先挑一個已有簡單規則可比較的目標，才能看出多表關係是否帶來額外訊號。NVIDIA 也說明，資料量非常大的任務，專門訓練的監督式模型仍可能更好；重要線索若隔著太多層關係，取樣範圍也可能限制效果。
目前有直接載入模型與部署服務兩條路。模型卡示範在 CUDA 環境傳入歷史範例、答案及相關表格；開源程式庫提供這些資料型別與推論介面。程式碼採 Apache 2.0，模型權重採 OpenMDW 1.1，兩者條款分開列示。
採 NIM 時，資料用戶端會選出相關紀錄，送往設定好的推論服務，再取回結果。1.0.0 規格列約 3,100 萬參數，支援 Linux 與所列 NVIDIA GPU。自架仍要安排 GPU、資料圖與推論記憶體；模型小，不代表資料處理成本可以忽略。
我不建議因為「不用逐題訓練」就立即替換現有回購模型。這次最合理的用途，是讓新增預測需求更容易做出可比較的第一版，之後再看結果與運算成本。在取得自家資料的比較結果以前，廠商榜單還不足以成為換系統的依據。
若你目前只要整理既有報表，先用一般 AI 資料分析工具就好；如果目標是每天的總銷量、氣溫等連續變化，可另看多變量時間序列預測。Kumo Relational 的選用理由，應是資料表之間確實存在值得利用的關係。
常見問題
不用訓練，還要歷史答案嗎？
要。基本流程在推論時參考已知結果的歷史範例，免去的是每個任務重新更新模型權重的步驟。
可以預測哪些回購結果？
文件示範預測指定顧客未來 30 天是否下單，或同一期間的總消費金額。選定事件或數值後，系統使用相關歷史資料推論。
如何選擇本機與服務部署？
直接載入權重需準備 CUDA 環境與資料。採 NIM 時，用戶端會把選出的紀錄送到推論服務，須依資料存放需求安排部署位置。