Timestral：小型預測模型，不能忽略的資料截止時間
明天的促銷已排進行事曆，明天的銷量卻還不知道。預測功能必須分清這兩種資料，即使它們是資料倉儲同一張表裡相鄰的欄位。
Mistral於10月15日推出Timestral，本週再次引起開發者討論。這個數值預測模型家族有四種規模，從500萬到2.09億參數，可接收相關時間序列與外部輸入，輸出未來值的分布。三項公開零樣本基準領先及CPU推論能力，都是廠商公布的結果，不是NxCode實測。
對要加入需求、容量或監控預測的團隊，數值元件更容易取得是實際變化。難題依舊是：輸入資料在當時真的拿得到嗎？本文以介面、公開程式及零售排班回測說明這條界線。我們檢查了程式與文件，沒有執行模型權重，也沒有重現準確率或延遲。
小模型也可以提供不只一個答案
時間序列是依時間排列的觀測。時序基礎模型先從多樣資料學習，再套用到新序列；零樣本指不針對該序列另行訓練，不代表不用歷史資料，也不保證能預見每種商業變化。
209M模型卡列出最多32768個歷史時間步，每32步組成一個patch，單次前向運算最多預測1024步。步數是觀測點而非語言token。96步若按小時取樣是四天，若每15分鐘取樣則是一天；數值之外，應保留取樣頻率與時區。
模型為每個未來時間點輸出21個分位數。中位數是中間估計；0.9分位數估計有90%的結果會低於該門檻，前提是機率校準良好。整齊的上下界並不能證明真實值確實依相應比例落在其中。
假設零售店用它安排隔天人力。這是示意情境，並非客戶成果。中位數協助理解需求，較高分位數可支持保守排班，但工時、服務目標及人力不足成本仍由應用決定。產品需要說清楚區間支援哪個決策，並在保留日期檢驗。
最有幫助的輸入，也可能偷偷帶入答案
協變量是能幫助解釋預測目標的其他資料，例如過去來客數或預先安排的促銷。介面區分只在歷史範圍可用的輸入，與覆蓋歷史及完整預測區間的已知未來輸入。
截止時間之前核准的促銷計畫可以是已知未來資訊，明天實際來客數不行。今天發布的天氣預報可用，但明天才量到的實際氣溫不是同一份資料。回測若以實際天氣取代當時的預報，就讓模型取得正式運作時不可能有的資訊。
NxCode原創示意圖，說明預測截止點前後的資料可用性；圖塊不是模型預測或實測準確率。
計畫本身也會修改。用倉儲最新版本重建歷史，可能夾帶預測發布後才做的調整。應同時保存事件生效時間與資料可取得時間：前者把促銷放在週五，後者決定週四的預測是否能讀到它。
因此，加了許多外部輸入的展示，不一定比只用歷史更可信。以相同截止點和目標，比較純歷史版本與符合資訊可用時間的協變量版本，才能判斷額外資訊在現實條件下是否有用。
注意力遮罩無法修好倉儲的錯誤關聯
注意力遮罩程式給不同資料列不同的可見範圍。已知未來輸入可以查看整個視窗，卻受到限制，不能讀取目標列、再把目標的未來傳回預測。這種架構可以從程式檢查。
它仍無法判斷現實中的資料到達時間。若把明天實際銷量藏在「活動計畫」欄位，遮罩不會替你找回正確語意。資料整理是整體正確性的一部分。
長區間也有另一項限制。超過單塊長度時，預測分塊產生，前一塊的中位數會接回上下文。介面能傳回超過1024步，並不等於一次聯合預測完整未來，更不代表取得了完整且互相關聯的未來情境。
例如把七天各自的高分位數相加，不能直接宣稱是週總量的同機率上界；天與天的相依關係會影響結果。應檢驗最後真正呈現給使用者的總量，而非假設任意運算都保留原本的機率含義。
三個排行榜領先，仍是評估的起點
Mistral稱最大模型在GIFT-Eval、TIME及fev-bench的預訓練零樣本組領先。儲存庫說明同時列出輸入差異：第一項用歷史協變量，第二項含歷史及已知未來資料，TIME則沒有協變量。這不是同一個實驗做三次。
MASE以樸素參照尺度衡量點預測誤差，分位數評分則考察分布；中央估計不錯，不等於所有區間都適用。讀取排名時要保留指標、比較群組與資料組成。
GIFT-Eval維護者分別追蹤模型類別、訓練資料重疊及測試洩漏，其零樣本類別排除用該基準的訓練與測試資料訓練；「預訓練」範圍較廣。廠商有條件的領先，不能改寫成超越所有預測方法。
10月12日的IND-Eval論文著重工業多變量及更細取樣，指出整體領先模型仍存在特定資料來源的例外。研究沒有評測Timestral，只用來說明方法：總體排名可能掩蓋產品真正依賴的領域，並不能證明Timestral在那些工業任務的好壞。
CPU部署與權重授權，要分別確認
套件使用PyTorch、NumPy、safetensors與Hugging Face Hub。Mistral報告的CPU例子是伺服器八執行緒，以三週15分鐘歷史預測一天，最小及最大模型分別10與140毫秒。這不是對筆電、繁忙服務或大量聯合變量的效能承諾。
應分別量測冷啟動、穩態推論和完整請求，記錄批次、序列數、協變量與執行緒。下載權重和暖機後推論的成本不同。CPU可執行代表值得納入預算評估，並非已測得服務成本。
程式是Apache2.0，209M權重卻是Modified MIT。條文規定，公司或雇主前月全球合併月營收超過2000萬美元時，不獲授權行使此許可權利，並指向商業授權或託管服務；也要求保留聲明。統稱「MIT開源」會漏掉重要條件，部署清單應分開記錄套件與權重。
第一次回測必須容許新模型落敗
先挑可撤回的動作，例如建議隔天尖峰時段增派人手，最後由店長排班。看結果前就固定保留門市、日期、發布時間、預測區間及現行規則，避免不斷改實驗直到新模型看似有效。
fev評估庫讓每個視窗分開提供歷史資料及僅含已知輸入的未來資料，摘要保留任務、資料指紋與設定。內部可以借用這項設計，不必宣稱重現完整公開基準。
| 紀錄 | 零售場景要保存的內容 |
|---|---|
| 發布 | 門市、時區、截止點與長度 |
| 輸入 | 銷量歷史及當時已取得的促銷版本 |
| 對照 | 現行規則、季節樸素法、純歷史模型、合格協變量版本 |
| 輸出 | 模型版本、設定、中位數與選定分位數 |
| 結果 | 保留真值、各門市與距離誤差、覆蓋率及排班影響 |
季節樸素法重複上一週對應小時之類的季節值。若新模型無法在目標決策上勝過簡單重複，複雜度就缺乏理由。繁忙與冷清時段分開看，避免平均改善藏住最重要班次的退步。
區間覆蓋率應連同寬度檢驗：太寬可能涵蓋多數結果卻無法決策，太窄可能漏掉尖峰。再看加入外部輸入是否有效、後來資料修訂是否改變答案，以及結論在下一批保留日期是否成立。
助手可以解釋數值或查促銷政策，但敘述必須連到原輸出、截止點與封存輸入，不能暗中換成新的估計。對NxCode開發者，第一個實用功能是讓使用者能檢查、也能覆寫的預測。Timestral降低取得元件的門檻；是否採用，仍應由一個可能建議「維持舊規則」的實驗決定。