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

特徵存儲是解決機器學習生產中數據不一致問題的關鍵基礎設施。許多團隊在實際部署中才意識到其必要性：一個欺詐檢測模型在筆記本中表現完美，但在生產環境卻頻繁出錯；一個支持代理由於缺乏用户上下文而給出泛泛的回覆；一個推薦流水線在三個作業中重複計算相同的“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創始人。