Feature StoreとPrompt Storeのトレードオフ
· 7分で読める
Feature Storeはモデル向けの決定的シグナルを最適化し、Prompt StoreはLLM向けの言語・ツール・ポリシーを最適化します。混同すると二重の真実と古いコンテキストが生まれます。
異なる鮮度問題を解く
Feature Storeが答えるのは：意思決定時点でこのエンティティについてどの数値/カテゴリシグナルを知っていたか—ポイントインタイム正確性と学習-配信スキュー制御付き。Prompt Storeが答えるのは：このサーフェスでモデルにどの指示・例・ツール定義・安全ポリシーを見せたか—監査可能性とロールバック付き。
埋め込み、RAG断片、ビジネスルールを一つの「コンテキストバケツ」に入れるチームは、しばしば両システムを下手に再実装します—特徴の系譜もプロンプトのレビューフローもなく。ストアを名付ける前に問題を名付けてください。
Feature Storeが価値を出すとき
複数モデルやルールが同じシグナルを消費するとき、オフライン学習がオンライン配信と一致すべきとき、コンプライアンスが予測ごとに再現可能な入力を要するときにFeature Storeを使います。バッチバックフィル、マテリアライズドビュー、エンティティキーは一等公民です—ベクターDBへの後付けではありません。
プロンプト調整は欠けた特徴の代わりにはなりません。チャーン模型が利用集計を要するなら、チャット履歴からLLMに数字を即興させるのではなく、オーナーとSLA付きの特徴パスに置いてください。
- コンシューマごとにエンティティキーと鮮度SLAを定義
- 学習対オンライン配信のポイントインタイム結合を追跡
- モデル重みだけでなくマテリアライズ特徴セットを版管理
- 配信がポリシーを超えてバッチパイプラインに遅れたらアラート
Prompt Storeが正しい抽象のとき
プロダクト・安全・法務が言語、ツール露出、拒否ポリシーのレビュー済み変更を要するとき—多くの場合コードデプロイより速く、ダッシュボード即席編集より遅い—Prompt Storeを使います。本番設定へのコピペではなく、評価スイートと環境昇格と組み合わせます。
Prompt Storeは取引事実の主たる居場所としては弱いです。残高・権利・在庫など値が厳密であるならツールや特徴で取得し、プロンプトは話し方だけを記述します。
検索を統一し、真実を複製しない
多くのプロダクトは両方必要です：スコアリング用の特徴と対話用のプロンプト。文書とポリシーで検索層を共有しつつ、特徴系譜とプロンプト承認は分離します。矛盾時にどの層がオーナーか文書化します。
目標は鮮度とオーナーシップの一本の運用ストーリーであり、何でもあるふりをする一つのDBではありません。
2026年9月12日、Berktug Berke Ates が公開。