特徵儲存（feature store）
/ FEE-chur stor /
特徵儲存，是一個集中的去處，用來計算、儲存並供給機器學習模型所「吃」的那些輸入變數（也就是「特徵」）。所謂特徵，不過是關於某事物、一份預先備好的資訊——一位客戶過去 30 天的平均購買額、一件商品的品類、一個用戶本週登入了多少次。特徵儲存，就是那間共享的食材間：這些食材在這裡備好一次、碼放整齊，再一致地分發給任何需要它們的人。
它解決的，是一個靜悄悄卻很折磨人的問題。同一個特徵——比方說「客戶 30 天的消費額」——會在兩處用到：訓練時（在歷史資料上算）和線上服務時（在新鮮資料上算，還得快）。要是兩個團隊算得稍有出入，模型就在一種定義上訓練、卻在另一種定義上服務，準確度便莫名其妙地爛掉。這就是臭名昭著的「訓練—服務偏差」。特徵儲存把每個特徵只定義一次，保證同一個值同時流向訓練和服務，同時還讓各團隊彼此複用對方的特徵，而不必重造。
為什麼這很重要：在成熟的機器學習組織裡，把特徵做對、做一致，其價值往往勝過一個更花俏的模型，而特徵儲存正是讓這份紀律能規模化的基礎設施。誠實的提醒是：它是一件相當重的基礎設施，主要對那些有許多模型、許多團隊共享資料的組織才划算。對一個單獨的小項目而言，它可能是殺雞用牛刀——一張表格、一段簡單腳本就夠了。它解決的是一個協同問題，要是你壓根沒那個問題，也就用不著這副藥。
一個反詐欺模型需要「過去一小時內的交易筆數」。特徵儲存為兩個世界用同一種方式算它：一個批次任務為訓練填好歷史值，而一次快速查詢，在刷卡的那一刻供給即時值——保證模型看到的是同一套一致的定義。
一個特徵定義，兩條供給路徑——這正是治「訓練—服務偏差」的藥。
特徵儲存是為「協同問題」而設的基礎設施，而不是建模上的升級。當許多團隊和模型共享資料時，它才掙回自己的飯錢；對一個孤零零的項目，它通常是不必要的負擔。別僅僅因為它聽起來專業，就搬一個來用。