marketplace-recsys-feature-engineering

マーケットプレイスエンジニアリング：レコメンダーシステムの特徴量エンジニアリングのベストプラクティス

両面型の信頼性重視マーケットプレイスにおける生データ（リスティングの写真、オーナーが提供するリスティングのメタデータ、シッターのウィザード回答）から、アイテム間、ユーザーからアイテム、ユーザー間のソリューションに使えるレコメンダーシステムの特徴量を導き出すための、包括的な第一原理ガイドです。特徴量エンジニアリングのライフサイクルへの連鎖的な影響が大きい順に並べた8カテゴリ、44のルールと、ルールをエンドツーエンドの特徴量発見ワークフローとして組み合わせた1つのプレイブックを収録しています。

このスキルは、marketplace-personalisation（AWS Personalize）および marketplace-search-recsys-planning（OpenSearch の検索）に先行する上流工程です。これらのスキルでは、特徴量はすでに用意されている入力として扱います。このスキルでは、生データからどの特徴量を構築するか、それらがどの意思決定に役立つか、そしてそれぞれが維持コストに見合う価値を持つことをどう証明するかを決めます。

適用するタイミング

以下のような場合に、このスキルを参照してください。

• i2i 類似度や u2i ランキングに活用するため、リスティングの写真、説明文、アメニティリストから何を抽出するか計画するとき
• レコメンダーシステムの特徴量を主な出力とするシッターのオンボーディングウィザードを設計または改訂するとき
• ビジョン埋め込みパイプライン、テキストエンコーダー、またはそのどちらも構築しないかを、またその順序を決めるとき
• 既存のベース特徴量を組み合わせて、アイテム間、ユーザーからアイテム、またはユーザー間のスコアリングを行うとき
• 既存の特徴量ストアについて、カバレッジ、ドリフト、PII、重複、または孤立した特徴量を監査するとき
• 新しいレコメンダーシステム特徴量のリリース／廃止基準を選び、アブレーション A/B テストを設計するとき
• 「類似する家の棚を改善したい。どの特徴量を構築すべきか？」という質問に答えるとき

セットアップ

このスキルにはユーザー固有の設定はなく、単体で利用できます。参照先は、Airbnb、Pinterest、DoorDash、Uber、Netflix、Google のエンジニアリングブログ、オープンソースライブラリ（Feast、Sentence-Transformers、Hugging Face CLIP、H3）、基礎となる学術論文（Airbnb KDD 2018、Pinterest ItemSage、YouTube Semantic IDs、PinSage）、および Google の Rules of Machine Learning への有効な URL です。

ルールのカテゴリ

カテゴリは、特徴量エンジニアリングのライフサイクルへの連鎖的な影響が大きい順に並んでいます。監査の誤りは存在しないデータを基に特徴量を構築することにつながり、第一原理の誤りは実際の意思決定に対応しない特徴量を生み、抽出の誤りは後続のすべてに悪影響を及ぼす、という具合です。後の段階に進む前に、より早い段階の問題を解決してください。

#	カテゴリ	プレフィックス	影響度
1	アセットの監査とインベントリ	audit-	CRITICAL
2	第一原理に基づく特徴量分解	firstp-	CRITICAL
3	画像特徴量の抽出	vision-	HIGH
4	リスティングのテキストとメタデータの抽出	listing-	HIGH
5	シッターウィザードとプロフィールの抽出	wizard-	HIGH
6	類似度と親和性の導出	derive-	MEDIUM-HIGH
7	特徴量の品質とガバナンス	quality-	MEDIUM-HIGH
8	段階的なロールアウトと価値の実証	prove-	MEDIUM

クイックリファレンス

1. アセットの監査とインベントリ（CRITICAL）

• audit-measure-coverage-before-modelling — カバレッジが80%未満のフィールドを特徴量計画から除外する
• audit-sample-every-asset-type-end-to-end — 計画を立てる前に、実際の取得経路を通じて実データのインスタンスを100件取得する
• audit-verify-rights-and-privacy-before-extraction — エンコーディングの前に ToS、GDPR、同意、顔のぼかし処理を確認する
• audit-quantify-freshness-per-asset — 経過時間の分布、期限切れ、更新バケットを把握する
• audit-separate-raw-assets-from-derived-features — 生データはオブジェクトストアに不変の状態で保存し、派生特徴量は特徴量ストアでバージョン管理する

2. 第一原理に基づく機能分解（重要）

• firstp-start-from-the-decision-not-the-algorithm — まず判断、次に下位の判断、最後にツール
• firstp-ask-what-signal-a-human-uses — オーナーとシッターに8〜12件のインタビューを実施し、機能の根拠を発言までたどる
• firstp-tie-every-feature-to-a-specific-solution — 名前の明示された i2i/u2i/u2u の利用先がない機能は追加しない
• firstp-prefer-directly-observed-over-learned — まず観測された列、次に学習済み埋め込み
• firstp-reject-features-you-cannot-serve-at-inference — 学習と推論の整合性は設計時から始まる
• firstp-kill-features-a-popularity-baseline-already-captures — 登録前に相関を確認する

3. 画像特徴量の抽出（高）

• vision-use-clip-for-zero-shot-listing-embeddings — ゼロショット CLIP は1週間で導入可能
• vision-detect-room-types-before-detecting-amenities — 部屋の事前情報でアメニティの閾値を調整する
• vision-quantify-image-quality-separately-from-content — ぼやけ、照明、美的品質をそれぞれ独立した特徴量にする
• vision-extract-per-object-counts-not-just-presence — n_bed = 4 は has_bed = true より有用
• vision-pool-embeddings-across-a-listings-photo-set — リスティング全体のベクトルをプーリングし、写真ごとのベクトルも併せて保存する
• vision-fine-tune-on-your-domain-when-clip-underperforms — ゼロショットの性能が頭打ちになってから、対照学習でファインチューニングする

4. リスティングのテキストとメタデータの抽出（高）

• listing-declare-categorical-fields-for-bounded-vocabularies — 語彙が限定される場合はカテゴリ型にし、書き込み時に検証する
• listing-multi-hot-encode-amenity-lists — 固定のアメニティ語彙をマルチホットベクトルに変換する
• listing-hash-geo-to-hierarchies-not-raw-lat-lon — 複数の解像度で H3 を使用する
• listing-embed-description-with-pretrained-sentence-encoder — 低コストで意味的なテキスト特徴量を得るには all-MiniLM-L6-v2 を使用する
• listing-extract-stay-duration-shape-not-just-length — 生の日数だけでなく、ビン、祝日との重なり、柔軟性を使う
• listing-encode-pet-requirements-as-structured-triples — (species, count, special_needs) のトリプルと自由記述テキストを併せて使う

5. シッターのウィザードとプロフィール抽出（高）

• wizard-order-questions-by-information-gain — 識別力の高い質問を先に、自由記述を最後にします
• wizard-prefer-multiple-choice-over-free-text — 設計段階で特徴をカテゴリ化します
• wizard-make-skips-genuine-and-log-them — スキップはシグナルです。デフォルト値はこれを失わせます
• wizard-capture-experience-as-counts-and-dates — 形容詞ではなく数値を使用します。プラットフォーム上の履歴を自己申告より優先します
• wizard-separate-hard-constraints-from-soft-preferences — フィルターとランキング用の特徴を分けます

6. 類似度と親和性の導出（中〜高）

• derive-precompute-i2i-nearest-neighbours-offline — ANN の候補群を毎晩構築し、KV から 5ms 未満で提供します
• derive-fuse-modalities-before-item-similarity — ビジョン、テキスト、構造化データを重み付けして正規化します
• derive-use-two-tower-for-user-item-affinity — インタラクションで学習したデュアルエンコーダーを使い、ANN 検索に対応できる状態にします
• derive-score-u2u-as-symmetric-mutual-fit — min(P(owner), P(sitter)) を使用します。一方のみのスコアリングでは、リクエストが無駄になります
• derive-decompose-affinity-into-interpretable-subscores — 適合性、安全性、ロジスティクス、価格のサブスコアを組み合わせます
• derive-cache-user-embedding-with-short-ttl — セッション単位でキャッシュし、TTL は 60〜300 秒に設定します

7. 特徴の品質とガバナンス（中〜高）

• quality-version-feature-definitions-in-one-registry — 名前、実装、所有者をそれぞれ一つにします
• quality-serve-training-and-inference-from-one-store — 特徴ストアを唯一の信頼できる情報源にします
• quality-gate-features-on-coverage-and-drift — カバレッジの下限と PSI アラームを設けます
• quality-scrub-pii-before-features-leave-secure-zone — エンコード前に顔をぼかし、正規表現でスクラブします
• quality-freeze-feature-schemas-per-model-version — スキーマハッシュをモデルアーティファクトに固定します

8. 段階的なロールアウトと価値の実証（中）

• prove-ship-one-feature-at-a-time — 一つの特徴、一つの実験、一つの判断で進めます
• prove-measure-lift-against-feature-ablated-variant — アブレーションによって、偶発的な変更から特徴の効果を切り分けます
• prove-kill-features-that-dont-earn-maintenance — 効果に基づき、四半期ごとに廃止を検討します
• prove-dedicate-random-exploration-slice-to-new-features — 3〜5％の枠を設け、オフラインで僅差だった候補の勝者を見極めます
• prove-retain-feature-free-baseline-permanently — 人気度ベースラインをドリフトの基準点として維持します

新機能の発見

1 つのプレイブックでルールを組み合わせ、エンドツーエンドのワークフローを構成します。

• references/playbooks/discovering.md — マーケットプレイスの生データから新機能を発見します。アセットの監査と意思決定の分解から始まり、機能を除去したベースラインに対するアブレーション A/B テストをリリースするまでの、7 ステップのワークフローです。「次に何を作るべきか？」というタスクで使用します。「この特定の機能を修正する」というタスクでは使用しません。

「X からより多くのシグナルをどう抽出するか？」という自由度の高いタスクでは、まずプレイブックを読んでください。具体的な実装上の疑問が生じた場合は、個々のルールを読んでください。

使用方法

• カテゴリー構成とカスケードの根拠については、references/_sections.md を読んでください
• 介入策を提案する前に、これまでに蓄積された診断上の教訓について gotchas.md を読んでください
• 新しい機能発見サイクルを計画するには、references/playbooks/discovering.md を読んでください
• 特定のタスクがルールのタイトルに該当する場合は、references/ 配下の個々のルールファイルを読んでください
• スキルの成長に合わせて新しいルールを作成するには、assets/templates/_template.md を使用してください

関連スキル

• marketplace-personalisation — AWS Personalize で抽出後のパーソナライズを行います。イベント追跡、スキーマ設計、双方向マッチング、コールドスタート、フィードバックループが含まれます。機能がストアに揃い、ランカーのトレーニングを始める準備ができたら引き継いでください。
• marketplace-search-recsys-planning — OpenSearch の検索計画を行います。クエリの理解、インデックス設計、ランキング、検索とレコメンデーションの融合が含まれます。ボトルネックが機能の利用可能性ではなく検索にある場合に引き継いでください。
• marketplace-pre-member-personalisation — 匿名での訪問から有料会員登録までの会員登録前のジャーニーを扱います。匿名シグナルの推定、オンボーディング時の意図の把握、会員登録前の測定が含まれます。有料会員との境界で引き継いでください。

参照ファイル

ファイル	説明
references/_sections.md	カテゴリーの定義、影響度の順序、カスケードの根拠
references/playbooks/discovering.md	エンドツーエンドの機能発見プレイブック
gotchas.md	これまでに蓄積された特徴量エンジニアリングの診断上の教訓（随時更新）
assets/templates/_template.md	新しいルールを作成するためのテンプレート
metadata.json	バージョン、分野、権威ある参照情報