marketplace-personalisation

マーケットプレイスエンジニアリングにおける両面パーソナライズのベストプラクティス

AWS Personalize を利用した、両面型の信頼できるマーケットプレイス向けパーソナライズおよびレコメンデーションシステムの設計、構築、改善に関する包括的なガイドです。パーソナライズのライフサイクルへの影響が大きい順に並べた9カテゴリ、49のルールに加え、新しいシステムをゼロから計画するためのプレイブックと、既存システムの問題を診断するためのプレイブックが含まれています。

適用する場面

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

• 新しいレコメンダーシステムのイベントスキーマとトラッキングを設計するとき
• AWS Personalize のレシピ（USER_PERSONALIZATION_v2、SIMS、PERSONALIZED_RANKING_v2）を選ぶとき
• マーケットプレイスの検索やホームフィード向けに、候補生成および再ランキングのコードを作成またはレビューするとき
• 新しいプロバイダー、新しい利用者、または新しいカタログ地域のコールドスタートに対処するとき
• 稼働中のシステムが「おおむね機能しているものの、鮮度や公平性、パーソナライズが足りない」と感じられる原因を診断するとき
• レコメンダーの次の実験、ベースライン比較、または A/B テストを計画するとき
• 集中、カバレッジの崩壊、デススパイラル、または学習時とサービング時の偏りを調査するとき
• 可観測性ダッシュボード、ドリフト検出、またはオンライン指標のスライスを追加するとき

セットアップ

このスキルにはユーザー固有の設定はなく、単独で使用できます。参照先は、AWS Personalize の公式ドキュメント、バイアスと露出に関する学術論文、Airbnb および DoorDash のエンジニアリングブログへの最新の URL です。

ルールカテゴリ

カテゴリは、影響が波及する順に並んでいます。前段の問題は、後続のすべてに悪影響を及ぼします。

#	カテゴリ	プレフィックス	影響
1	イベントのトラッキングと記録	track-	CRITICAL
2	データセットとスキーマの設計	schema-	CRITICAL
3	両面マッチングのパターン	match-	CRITICAL
4	シンプルなベースラインと制約理論	simple-	HIGH
5	フィードバックループとバイアス制御	loop-	HIGH
6	コールドスタートとカバレッジ	cold-	HIGH
7	レシピとパイプラインの選択	recipe-	MEDIUM-HIGH
8	推論、フィルター、再ランキング	infer-	MEDIUM-HIGH
9	可観測性とオンライン指標	obs-	MEDIUM-HIGH

クイックリファレンス

1. イベントのトラッキングと記録（CRITICAL）

• track-log-impressions-alongside-clicks — クリックを率に変換し、バイアスのない学習を可能にする分母
• track-use-stable-opaque-item-ids — リスティングの名前変更や移動による履歴の消失を防ぐ
• track-stamp-events-with-request-id — インプレッションと結果のアトリビューションを可能にする結合キー
• track-stream-events-via-putevents — リアルタイムの適応と、1日の終わりに行う一括インポートを比較する
• track-capture-negative-signals — 非表示は有益な情報ですが、無反応はそうではありません
• track-measure-outcomes-not-clicks — クリックを誘うだけのコンテンツではなく、完了した予約を報酬とする

2. データセットとスキーマの設計（CRITICAL）

• schema-design-conservatively — Interactions スキーマは変更できず、Users／Items の変更は困難です
• schema-keep-user-item-thin — 変化しやすいフィールドはイベントに含めます
• schema-enforce-metadata-freshness — メタデータが変わるたびに PutItems を実行します
• schema-prefer-categorical-fields — 値ごとの特徴量を利用できるようにします
• schema-weight-event-value — モデルをビジネス上の成果に合わせます
• schema-include-context-everywhere — 学習時とサービング時の特徴量の整合性を保ちます
• schema-meet-minimum-dataset-sizes — 学習前にユーザー50人、アイテム50件、インタラクション1,000件を用意します

3. 双方向マッチングのパターン（CRITICAL）

• match-rank-mutual-fit — 双方の受諾確率で順位付けする
• match-hard-filter-before-ranking — 検索で実現可能性を担保する
• match-cap-provider-exposure — 多様性を公平性の制約として扱う
• match-model-capacity-constraints — 容量を考慮してスコアを調整する
• match-balance-supply-demand — セグメントごとに戦略を振り分ける

4. シンプルなベースラインと制約理論（HIGH）

• simple-ship-popularity-baseline — すべての ML モデルが上回るべき基準点
• simple-find-bottleneck-first — 最適化の前に診断する
• simple-heuristic-rerank-cold-cohorts — 信頼度 × 新しさ × 距離
• simple-budget-complexity — 実行前にリリースまたは中止を判断する基準
• simple-audit-before-build — テレメトリの監査をモデル開発の開始条件とする
• simple-measure-gap-to-baseline — ベースラインを恒常的な少数派バケットとして維持する

5. フィードバックループとバイアス制御（HIGH）

• loop-log-ranking-slot — 位置バイアス補正に使うスロットデータ
• loop-reserve-random-exploration — バイアスのないトレーニングデータ
• loop-optimize-completed-outcome — 代理指標ではなく、目標を報酬する
• loop-decay-event-weights — 古い嗜好は薄れていく
• loop-detect-death-spirals — 露出のジニ係数を先行指標として使う

6. コールドスタートとカバレッジ（HIGH）

• cold-use-v2-recipe-with-metadata — メタデータを新しい掲載情報に外挿する
• cold-best-of-segment-popularity — グローバルな上位 N 件よりセグメント分けを優先する
• cold-capture-onboarding-intent — 推測するのではなく、尋ねる
• cold-reserve-exploration-slots — プロモーションで新しい在庫を優先する
• cold-tag-cold-start-recs — ウォームとコールドで指標を切り分ける

7. レシピとパイプラインの選定（MEDIUM-HIGH）

• recipe-default-to-user-personalization-v2 — ディスカバリーのデフォルト
• recipe-sims-for-item-page-only — 類似アイテムはホームページ用のレシピではない
• recipe-personalized-ranking-as-reranker — 候補生成器ではない
• recipe-build-candidate-rerank-pipeline — 2 つのレイヤー、2 つの関心事
• recipe-defer-hpo-until-baseline-measured — チューニングの前にモデルの有効性を実証する

8. 推論、フィルター、再ランキング（MEDIUM-HIGH）

• infer-use-filters-api — Personalize が numResults まで補充する
• infer-rerank-rules-after-model — モデルの分布を維持する
• infer-deduplicate-canonical-entity — 掲載情報単位ではなく、プロバイダー単位で重複を排除する
• infer-enforce-exposure-caps — ローリング方式の公平性制約
• infer-cache-responses-short-ttl — セッションの継続性とコスト管理

9. 可観測性とオンライン指標（中〜高）

• obs-always-ab-test — 実施前と実施後の比較だけでは決して十分ではありません
• obs-track-coverage-and-gini — エクスポージャーの健全性を示すシグナル
• obs-slice-metrics-by-segment — 集計指標ではセグメントごとの性能低下が見えません
• obs-watch-online-offline-divergence — 代理指標への過学習を検出します
• obs-alarm-on-prediction-drift — 分布のKLダイバージェンスを早期警告として使用します

レコメンデーションの計画と改善

以下の2つのプレイブックでは、上記のルールを組み合わせたエンドツーエンドのワークフローを扱います。

• references/playbooks/planning.md — 新しいレコメンダーシステムをゼロから計画します。計測から始まり、人気度ベースラインを初めて上回るA/Bテスト済みの機械学習による改善で終わる、9ステップのワークフローです。
• references/playbooks/improving.md — 既存のレコメンダーを診断して改善します。現在のボトルネック（テレメトリー、鮮度、カバレッジ、フィードバックループ、アルゴリズム）を特定し、解決に役立つ個別のルールへ誘導する決定木です。

「レコメンダーを設計する」または「このレコメンダーの性能が低い」というタスクでは、まずプレイブックを読んでください。実装やレビューの途中で具体的な疑問が生じた場合は、個別のルールを読んでください。

使用方法

• カテゴリー構成と影響度の順序については、references/_sections.mdを読んでください。
• 該当するルールがタスクにある場合は、references/以下の個別のルールファイルを読んでください。
• 新しいシステムを設計するには、references/playbooks/planning.mdを読んでください。
• 既存のシステムを診断するには、references/playbooks/improving.mdを読んでください。
• スキルの拡張に伴って新しいルールを作成する際は、assets/templates/_template.mdを使用してください。

リファレンスファイル

ファイル	説明
references/_sections.md	カテゴリーの定義、影響度の順序、カスケードの根拠
references/playbooks/planning.md	新しいレコメンダーの計画用プレイブック
references/playbooks/improving.md	既存のレコメンダーの診断用プレイブック
assets/templates/_template.md	新しいルールを作成するためのテンプレート
metadata.json	バージョン、分野、信頼できるリファレンスURL