從零構建特徵儲存：最小可用實現

特徵儲存是解決機器學習生產中資料不一致問題的關鍵基礎設施。許多團隊在實際部署中才意識到其必要性：一個欺詐檢測模型在筆記本中表現完美，但在生產環境卻頻繁出錯；一個支援代理由於缺乏使用者上下文而給出泛泛的回覆；一個推薦流水線在三個作業中重複計算相同的“30天消費額”，其中兩個結果不一致。這些問題的根源在於訓練與服務之間的資料偏差（skew），而特徵儲存正是為此設計的。它允許你一次性定義特徵，將其儲存為兩種形態——一種用於訓練，一種用於服務——並保持兩者同步。

本文將帶領你使用Python、DuckDB、Parquet、Redis和FastAPI，從零構建一個最小可用的特徵儲存。我們還將探討AI應用如何改變我們對特徵儲存的實際使用方式。完整的程式碼僅有約200行，足以覆蓋每個核心元件。

特徵儲存解決的現代問題

傳統上，特徵儲存主要解決訓練-服務偏差，即構建訓練集的SQL程式碼與推理時執行的程式碼不同，導致特徵值逐漸漂移。離線/線上分離是標準修復方案。然而，如今的挑戰更為廣泛：大語言模型（LLM）代理和檢索增強生成（RAG）流水線需要在每次請求的10毫秒內獲取結構化使用者上下文。LLM沒有使用者記憶，若要實現個性化輸出，我們必須將使用者的計劃層級、近期活動、賬戶狀態等資訊注入提示詞，且需要一個能夠快速、一致地返回這些值的系統。這正是特徵儲存的線上儲存和檢索API提供的功能。因此，我們構建的特徵儲存同時服務於傳統預測機器學習和LLM上下文兩大用例，五個元件相容兩者。

五個核心元件

1. 特徵登錄檔：以程式碼形式定義特徵。使用Python資料類（dataclass）宣告每個特徵的名稱、實體、資料型別和資料來源（Parquet檔案路徑）。登錄檔是所有其他元件的單一事實來源，修改特徵只需在這一處進行。在生產系統中，登錄檔通常作為YAML檔案或Python模組儲存在Git倉庫中，每次更改都需程式碼審查。

1. 離線儲存：基於Parquet檔案，使用DuckDB作為查詢引擎。離線儲存儲存每個特徵值的完整歷史記錄。DuckDB可以直接讀取Parquet檔案，無需額外資料庫。透過ASOF LEFT JOIN實現點對點連線，確保每個訓練行只使用到該時間點之前已存在的特徵值，從而防止資料洩露。這對於任何需要訓練或微調的模型都是必須的。即使是純推理的LLM用例，離線儲存也是回填、評估資料集和審計的來源。

1. 線上儲存：基於Redis，僅儲存每個實體的最新特徵值。Redis的雜湊查詢在亞毫秒級完成。鍵的格式為entity:entity_id，值是一個包含所有特徵的雜湊。單次HMGET即可在一個往返中返回所有請求的特徵。例如，在本地Redis例項上查詢三個特徵，耗時遠低於1毫秒。

1. 物化管道：定期將離線儲存中的最新值推送到線上儲存。透過QUALIFY子句選取每個實體的最新記錄，然後將同一實體的所有特徵合併為一次Redis寫入，減少往返次數。排程頻率根據特徵更新需求設定：watch_count_30d每小時更新，last_genre近乎即時，user_segment每天更新。在真實系統中，此管道可由Airflow、cron或流處理作業執行。

1. 檢索API：基於FastAPI，提供型別化的HTTP端點（如POST /get-online-features），供模型或LLM應用呼叫。以個性化LLM推薦服務為例：當使用者開啟流媒體應用時，端點為使用者ID返回使用者段、30天觀看次數和最後觀看型別，這些上下文被注入LLM提示詞，促使其生成個性化的“接下來看什麼”訊息。特徵儲存將“使用者8a2f”轉化為LLM可用的結構化上下文。

特徵儲存與向量資料庫的邊界

向量資料庫（如Pinecone、Weaviate、pgvector）常被混淆為特徵儲存，但二者解決不同的檢索問題。向量資料庫返回最相似的過往觀看會話，而特徵儲存返回使用者段和近期統計。一個完整的LLM棧二者皆需：向量資料庫提供相似性檢索，特徵儲存提供結構化鍵值查詢，兩者互補而非替代。

常見反模式

1. 在模型服務中計算特徵：導致訓練筆記本和API中的邏輯定義漂移。
2. 將線上儲存視為資料來源：Redis可能在重啟後丟失資料，離線儲存才是權威，線上儲存應視為快取。
3. 跳過登錄檔：不同團隊獨立定義同一特徵（如active_user），導致儀表盤與模型不匹配。
4. 將向量資料庫稱為特徵儲存：它無法進行實體鍵控的結構化查詢。
5. 未使用點對點連線進行回填：訓練集看似良好，生產模型卻崩潰，其差距即為資料洩露。

與Feast、Tecton和Databricks的對比

我們的約200行程式碼以微縮形式實現了相同的功能。若期望繼續使用自託管方案，Feast是最接近的開源選擇。Tecton和Databricks提供託管路徑，並具備明確的LLM特性（如Tecton的LLM特徵檢索API、Databricks的複合生成AI特徵服務）。選擇主要取決於希望自運營的程度以及現有技術棧是否已基於Databricks。

結論

一個可工作的特徵儲存僅需五個元件：登錄檔、離線儲存、線上儲存、物化步驟和檢索API。親手構建一次，就能理解生產級系統為何如此設計。它也揭示了AI對設計的改變：線上檢索路徑是LLM的接入點，點對點連線在訓練和評估時至關重要，向量資料庫則與特徵儲存並肩工作。一旦掌握這些元件，將簡化版替換為Feast、Tecton或Databricks基本上只是登錄檔的遷移，系統架構保持不變。

——作者Nate Rosidi，資料科學家及產品策略專家，StrataScratch創始人。