@Yusuke Horibe

Embedding-Based Retrieval for Airbnb Search

Embedding-Based Retrieval for Airbnb Search | Airbnb Engineering & Data Science

• TL;DR

  巨大な候補集合（人気エリアでは数万件）から、低レイテンシで質の高い候補を絞り込む EBR（Embedding-Based Retrieval） を two-tower で構築。A/B テストで予約コンバージョンが有意に改善し、その伸びは過去2年の最大級のランキング改善に匹敵した。

• 背景・課題

  物件・クエリの組み合わせが膨大で、柔軟な日程検索などで候補数がさらに増加。 重いランキングモデルにかける前に、候補を「速く・賢く」絞る retrieval 層が必要に。 ただし一般的な IR と違い、在庫が動的（毎秒1万件規模の更新、インデックス遅延に敏感）で、ほぼ全クエリに地理フィルタ等の 絞り込み条件が付く。

• アプローチ

  1. モデル: two-tower

     listing tower（物件側）と query tower（検索側）で同一空間の embedding を学習。 工夫: listing tower はオフラインで日次バッチ計算できるよう特徴量を設計 → サービング時は query tower のみリアルタイム評価でよく、レイテンシを大幅削減。

  2. 学習データ: hard negative

  ランダム負例は簡単すぎて学習にならない。 ユーザーの1回の検索ジャーニー（検索・クリック・wishlist〜予約）をまとめ、予約物件を正例、同じジャーニーで見たのに選ばなかった物件を hard negative に。似た物件同士の微差を学習させる。

  1. サービング: ANN

     HNSW ではなく IVF を採用。更新頻度の高さとフィルタ要件に合うため。 クエリに近いクラスタを取得し、その中で通常の boolean フィルタを適用 → 既存検索基盤と素直に統合。

• 効いたポイント

  • 距離関数の選択が地味に効く: dot product と Euclidean はモデル性能こそ同等だが、IVF では Euclidean の方がクラスタサイズが均等になり優秀。dot product はベクトルの大きさを無視するため、レビュー数などの count 系特徴量が効く Airbnb ではクラスタが偏り、retrieval の精度・速度を悪化させた
  • hard negative の作り方が embedding 品質を大きく左右する。 オフライン日次計算 + クエリ側のみリアルタイムという構成で、精度とレイテンシ／コストを両立。

• 結果

  通常検索・柔軟日程・マーケメールなど複数用途で本番稼働。 A/B テストで予約が有意に増加

• 感想

  HNSWを使いがちだったがIVFの方がいいケースもあるというのが学びだった

@Higuchi Kokoro

Loop Engineering: The Anthropic Playbook

for Designing Systems That Prompt Your Agents

[https://drive.google.com/file/d/1qzKI4DKnyHRpXK1J3ATPqwaqLc0iNu-M/view](https://drive.google.com/file/d/1qzKI4DKnyHRpXK1J3ATPqwaqLc0iNu-M/view)

• Loop Engineerとは何か、どう作るといいのか説明した文書
  • 1回のループを Discovery / Handoff / Verification / Persistence / Scheduling の5動作に分解
  • Automations / Worktrees / Skills / Connectors / Subagents / Memory の6部品で構成される
  • 一番大事なのは「実装AI」と「検証AI」を分けること。AIに自分の成果物を採点させると甘くなるので、別のEvaluatorに「壊れている前提」でテスト実行・画面操作・差分確認をさせる必要がある
  • 理解を怠ると検証負債、理解の腐敗、判断放棄、トークン爆発という負を抱えることになる
  • ループを作ること自体が重要なのではなく、ループを作ったあともエンジニアであり続けることが重要。

@MizutaYuki