スクラッチから始めるFeature Stores：最小限の実装例

![image](https://www.kdnuggets.com/wp-content/uploads/Rosidi-Feature-Stores-Minimal-Implementation-2-scaled.png)** ## # イントロダクション 多くのチームは、苦労して特徴量ストア（feature store）の必要性に気づきます。ノートブック上では正常に動作していた不正検出モデルが、本番環境で静かに失敗します。サポート担当者がユーザーの情報を全く把握していないため、一般的な回答しか返せません。レコメンダーパイプラインでは、「過去 30 日間の支出額」という計算を 3 つのジョブで重複して行っており、そのうち 2 つの結果が食い違っています。 特徴量ストアは、これらの問題を解決する**インフラストラクチャ**（infrastructure）です。特徴量を一度定義し、トレーニング用と推論用の 2 つの形式（shape）で保存し、両者を同期させます。私たちは、**[Python](https://www.python.org/)** を基盤とし、**[DuckDB](https://duckdb.org/)**、**[Parquet](https://parquet.apache.org/)**、**[Redis](https://redis.io/)**、そして **[FastAPI](https://fastapi.tiangolo.com/)** を用いて、最小限の特徴量ストアをゼロから構築します。その後、AI アプリケーションが実際にどのように利用されるかを変化させるのかについて考察します。 全コードは非常に短いため、すべてのコンポーネントを順を追って解説していきます。 ** ![image](https://www.kdnuggets.com/wp-content/uploads/Rosidi-Feature-Stores-Minimal-Implementation-3.png) ## # 特徴量ストアが実際に解決する課題 従来の売り文句は、トレーニングと推論の乖離（training-serving skew）です。トレーニングセットを構築するために使った SQL と、推論時に実行されるコードパスが一致していないため、値にズレが生じます。この問題は確かに存在し、オフラインとオンラインの分割が標準的な解決策となっています。 現代の提案はより広範です。大規模言語モデル（LLM）エージェントや検索拡張生成（RAG）パイプラインでは、推論時に、すべてのリクエストにおいて 10 ミリ秒未満で構造化されたユーザーコンテキストが必要です。LLM にはユーザーが誰であるかの記憶がありません。パーソナライズされた出力を得たい場合、プロンプトにユーザーのプラン階層、最近のアクティビティ、アカウント状態を注入する必要があり、これらの値を高速かつ一貫して返すシステムが必要です。まさにそれが、特徴ストアのオンラインストアと検索 API が提供するものです。 したがって、私たちは両方のケースに対応するために構築します。同じ 5 つのコンポーネントが、予測的機械学習ユースケースと LLM コンテキストユースケースの両方を処理します。 ## # 5 つのコンポーネント - 特徴をコードとして定義する特徴レジストリ。 - 学習およびバックフィルに使用される Parquet 形式のオフラインストア（DuckDB でクエリ）。 - 推論時の低遅延ルックアップ用の Redis 上のオンラインストア。 - オフラインから最新の値をオンラインへプッシュするマテリアライゼーションパイプライン。 - タイプ付き検索 API を公開する FastAPI サービス。 ![image](https://www.kdnuggets.com/wp-content/uploads/Rosidi-Feature-Stores-Minimal-Implementation-4.png) ## # 実行例：パーソナライズされた LLM レコメンダー 私たちはストリーミングサービスを提供しています。ユーザーがアプリを開くと、LLM が短くパーソナライズされた「次に見るべきもの」メッセージを生成します。この LLM はユーザーについて以下の 3 つの情報を必要とします： 特徴 型 鮮度 user_segment string daily watch_count_30d int hourly last_genre string per-event エンティティは user_id です。これら3つの機能を登録し、マテリアライズして、リクエスト時に LLM に提供します。 ## // 1. Feature Registry の定義 レジストリとは、機能のエンティティ、データ型（dtype）、およびソースを一度だけ宣言する場所です。ここでは dataclass を使用します。 from dataclasses import dataclass from typing import Literal @dataclass(frozen=True) class Feature: name: str entity: str dtype: Literal["int", "float", "str"] source: str # Parquet ファイルへのパスまたは SQL ビュー REGISTRY: dict[str, Feature] = { "user_segment": Feature("user_segment", "user_id", "str", "data/user_segment.parquet"), "watch_count_30d": Feature("watch_count_30d", "user_id", "int", "data/watch_count_30d.parquet"), "last_genre": Feature("last_genre", "user_id", "str", "data/last_genre.parquet"), } 完全なコードは [こちら](https://gist.github.com/snfnstratcha/d7a1e958122031ae4b3131e37c4211e3) で確認できます。 これを実行すると、出力には以下が表示されます： Registered features: user_segment entity=user_id dtype=str source=data/user_segment.parquet watch_count_30d entity=user_id dtype=int source=data/watch_count_30d.parquet last_genre entity=user_id dtype=str source=data/last_genre.parquet これが契約です。他のすべてのコンポーネントは REGISTRY から読み取るため、特徴量の名称変更、データ型の変更、または新しいソースへの指し示しは、単一の場所で行われます。本番環境のシステムでは、これは [YAML](https://yaml.org)** または Git リポジトリにチェックインされた Python モジュールとなり、すべての変更に対してコードレビューが行われます。 ## // 2. DuckDB と Parquet を用いたオフラインストアの構築 オフラインストアは、各特徴量の値の完全な履歴を保持します。ストレージ層として Parquet ファイルを使用し、クエリエンジンとして DuckDB を使用します。DuckDB は Parquet を直接読み取るため、別途データベースを実行する必要はありません。 以下にコードのサンプルを示します: import duckdb import pandas as pd def get_historical_features( entity_df: pd.DataFrame, features: list[str] ) -> pd.DataFrame: con = duckdb.connect() con.register("entities", entity_df) base = "SELECT * FROM entities" for fname in features: f = REGISTRY[fname] src = f.source.replace("'", "''") con.execute(f"CREATE VIEW {fname}_src AS SELECT * FROM '{src}'") base = f""" SELECT t.*, s.{fname} FROM ({base}) t ASOF LEFT JOIN {fname}_src s ON t.user_id = s.user_id AND t.event_timestamp >= s.event_timestamp """ return con.execute(base).df() 完全なコードは [こちら](https://gist.github.com/snfnstratcha/3e46e5d9e4e288795b094c66919388ad) で確認できます。 これを実行すると、出力には以下が表示されます: user_id event_timestamp user_segment watch_count_30d last_genre 8a2f 2026-05-05 12:00:00 casual 22 NaN b13c 2026-05-07 20:00:00 casual 5 thriller 8a2f 2026-05-07 22:00:00 power_user 47 documentary **[AsOf join](https://duckdb.org/docs/current/guides/sql_features/asof_join)** は、時点結合（point-in-time join）です。各エンティティ行に対して、特徴量のタイムスタンプがイベントのタイムスタンプより以前または同じであるような、最も新しい特徴量値を選択します。これにより、予測対象となる瞬間にはまだ存在していなかった特徴量値を用いてトレーニング行が構築されてしまうというデータリーク（leakage）を防ぐことができます。 時点結合は、今後トレーニングまたはファインチューニングを行う予定のあらゆるモデルにとって依然として適切な解決策です。純粋な推論時の LLM 利用ケースにおいては、この関数を呼び出す機会が全くないかもしれません。それでもオフラインストアが必要なのは、バックフィル（backfills）、評価用データセット、監査情報が得られる場所だからです。 ## // 3. Redis 上のオンラインストアの設定 オンラインストアは、各エンティティについて最新の値のみを保持します。Redis が標準的な選択肢となるのは、ハッシュ検索がサブミリ秒で完了するためです。 ```python import json import fakeredis # 本番環境では redis.Redis() を使用して実際のサーバーに接続する r = fakeredis.FakeRedis(decode_responses=True) def write_online(entity: str, entity_id: str, values: dict) -> None: r.hset( f"{entity}:{entity_id}", mapping={k: json.dumps(v) for k, v in values.items()}, ) def read_online(entity: str, entity_id: str, features: list[str]) -> dict: raw = r.hmget(f"{entity}:{entity_id}", features) return {f: json.loads(v) if v else None for f, v in zip(features, raw)} ``` 完全なコードは [こちら](https://gist.github.com/snfnstratcha/a15be90bac34d0eb509e8a3ddb6aeb71) で確認できます。 これを実行すると、出力には以下が表示されます： read_online -> {'user_segment': 'power_user', 'watch_count_30d': 47, 'last_genre': 'documentary'} missing key -> {'user_segment': None} キーの形式は entity:entity_id です。値は各特徴（feature）に1 つずつフィールドを持つハッシュです。単一の HMGET コマンドで、要求したすべての特徴を 1 ラウンドトリップで取得できます。3 つの特徴を持つローカルの Redis インスタンスでは、この処理は 1 ミリ秒もかからずに完了します。 ## // 4. マテリアライゼーションパイプラインの実行 マテリアライゼーション（materialization）とは、オフラインの値をオンラインへ移動するプロセスです。実際のシステムではこれはスケジュール（Airflow、cron、ストリーミングジョブなど）に基づいて実行されますが、ここでは関数として実装されています。 def materialize(features: list[str]) -> None: by_entity: dict[str, dict] = {} for fname in features: f = REGISTRY[fname] src = f.source.replace("'", "''") df = duckdb.sql(f""" SELECT {f.entity}, {fname} FROM '{src}' QUALIFY ROW_NUMBER() OVER ( PARTITION BY {f.entity} ORDER BY event_timestamp DESC ) = 1 """).df() for _, row in df.iterrows(): by_entity.setdefault(row[f.entity], {})[fname] = row[fname] for entity_id, values in by_entity.items(): write_online("user_id", entity_id, values) 完全なコードは [こちら](https://gist.github.com/snfnstratcha/5d4af61e449c879ea62b5de2ec68d1a6) で確認できます。 これを実行すると、出力には以下が表示されます： user_id:8a2f -> {'user_segment': 'power_user', 'watch_count_30d': 47, 'last_genre': 'documentary'} user_id:b13c -> {'user_segment': 'casual', 'watch_count_30d': 5, 'last_genre': 'thriller'} QUALIFY クラース（句）は、各エンティティごとに最新行を保持します。同じユーザーのすべてのフィーチャーを 1 つの Redis 書き込みへグループ化することで、往復通信回数を削減します。この処理は各フィーチャーが必要とする頻度で実行してください：watch_count_30d は時間ごと、last_genre はニアリアルタイム、user_segment は毎日です。実際の運用では、その頻度をエンコードする適切な場所はレジストリ（登録簿）となります。 ## // 5. FastAPI 取得サービスの公開 翻訳全文 POST /get-online-features -> 200 body: {'user_id': '8a2f', 'features': {'user_segment': 'power_user', 'watch_count_30d': 47, 'last_genre': 'documentary'}} LLM が受け取るプロンプト: システム：ストリーミングサービス向けの番組を推薦してください。 ユーザーコンテキスト：セグメントはパワーユーザー、過去 30 日間で 47 タイトル視聴済み、直近の視聴ジャンルはドキュメンタリー。 タスク：親しみやすい短いメッセージで 3 つのタイトルを提案してください。 このフィーチャーストア（特徴ストア）こそが、「ユーザー 8a2f」という情報を、LLM が利用可能な構造化されたコンテキストへと変換する役割を果たします。 ## # フィーチャーストアの終焉とベクトルデータベースの始まり ** ベクトルデータベース（[Pinecone](https://www.pinecone.io/)**、**[Weaviate](https://weaviate.io/)**、**[pgvector](https://github.com/pgvector/pgvector)**）は、推論時にモデルの手前に位置するという点でフィーチャーストアと共通していますが、ベクトルデータベース自体がフィーチャーストアであるわけではありません。両者は異なる検索問題を解決するものです。 ** ![image](https://www.kdnuggets.com/wp-content/uploads/Rosidi-Feature-Stores-Minimal-Implementation-5.png) 実際の LLM スタックでは、これら 2 つを併用します。ベクトルデータベースは過去に視聴されたセッションの中で最も類似した 3 つを返します。一方、フィーチャーストアはユーザーのセグメントと直近のカウント情報を返します。プロンプトはこの両者を組み合わせて構成されます。 ## # よくあるアンチパターン 頻繁に見られる失敗のパターンがいくつかあります： - モデルサービス内で特徴量を計算する。同じロジックがトレーニングノートブックと API の両方に実装される結果、2 つの定義は四半期ごとに乖離してしまう。 - オンラインストアを真の信頼源（ソース・オブ・トゥルース）として扱うこと。Redis は再起動時にデータ損失を起こす可能性がある。オフラインストアが正統な情報源であり、オンラインストアは単なるキャッシュに過ぎない。 - レジストリをスキップする。3 つのチームがそれぞれ独立して active_user を定義するため、ダッシュボードとモデルの出力が一致しなくなる。 - ベクトルデータベースを特徴量ストアと呼ぶこと。これはエンティティキーに基づく構造化された照合を行うことができないため、両方の機能が必要なプロンプトは結局 2 つのシステムに接続されることになる。 - 時点別結合（point-in-time joins）なしでバックフィルを実行すること。トレーニングセットは完璧に見えるが、本番環境のモデルは壊れているように見え、そのギャップこそがデータリーケージである。 ## Feast, Tecton, Databricks と比較する 私たちの約 200 行のコードは、同じ機能をミニマムな規模で実現している。 ![image](https://www.kdnuggets.com/wp-content/uploads/Rosidi-Feature-Stores-Minimal-Implementation-6.png) [Feast](https://feast.dev)** は、同じパターンを踏襲してさらに拡張する場合、特にセルフホスト環境において最も近い比較対象となる。**[Tecton](https://docs.tecton.ai/)** と **[Databricks](https://www.databricks.com/)** はマネージド型のパスであり、LLM 向けの特徴量機能（Tecton の LLM 用特徴量検索 API、Databricks の複合生成 AI システム向けの Feature Serving）を明示的に備えている。これらの中から選択するのは、主に自前で運用する範囲をどこまでにするか、そして残りのスタックがすでに Databricks に依存しているかどうかという問題である。 ## 結論 ** 動作するフィーチャーストアは、レジストリ、オフラインストア、オンラインストア、マテリアライゼーションステップ、および取得 API の 5 つのコンポーネントで構成されます。これを一度構築することで、なぜ生産環境のシステムが現在の姿をしているのかを理解できます。また、AI における設計変更のポイントも示してくれます：LLM がアクセスする表面はオンライン取得パスであり、トレーニングや評価を行う際にはポイントインタイム結合が重要となり、ベクトルデータベースはフィーチャーストア内部ではなくその隣に位置します。 これらの部品が揃えば、最小限のバージョンを Feast、Tecton、または Databricks に置き換えることは、主にレジストリの移行に過ぎません。システムの形状は同じままです。

スクラッチから始めるFeature Stores：最小限の実装例

背景や根拠まで確認しますか？

調べる

選ぶ

サイト