When & How to Write for Personalized Demand-aware Query Rewriting in Video Search

本論文は、動画検索におけるユーザーの意図特定と曖昧さ解消を目的として、個人化の必要性を自動判定する「いつ書き換えるか」、LLM と検索システムの整合性を高めるハイブリッド学習手法による「どのように書き換えるか」、そして低遅延な展開を実現する「Fake Recall」アーキテクチャを提案し、オンライン実験でクリック率向上とクエリ再定式化率の低下を確認した「WeWrite」というパーソナライズされた需要意識型クエリ書き換えフレームワークを紹介しています。

要約

🍽️ 料理の注文と「WeWrite」の仕組み

想像してください。あなたがレストラン（動画検索サイト）に入りました。

1. 従来の検索の悩み：曖昧な注文

あなたが「光良（コウリョウ）」と注文しました。

• 従来の店員（検索エンジン）は、「光良」という言葉だけで判断します。「歌手の光良さんですか？それとも、お酒の『光良』ですか？」と迷ってしまい、両方の料理（動画）を並べて出します。
• 問題点: あなたが実は「お酒」を探していたのに、歌手の動画ばかり出てきてガッカリしたり、逆に歌手を探していたのにお酒の動画ばかり出てきて「違う！」とまた注文し直したりします。これを「検索のやり直し（リフォーマル）」と呼びます。

2. 新しい仕組み「WeWrite」の登場

この論文で紹介されている**「WeWrite」というシステムは、「賢い注文係（コンシェルジュ）」**のようなものです。

このコンシェルジュは、あなたの**「過去の行動履歴」**（以前何を食べたか、どこにいたか）を覚えていて、注文内容を自動的に補正してくれます。

• あなたの履歴: 「以前、焼肉屋で『光良』というお酒を注文して、とても満足して長くとどまっていた」
• コンシェルジュの判断: 「あ、この人は歌手ではなく、お酒の『光良』を探しているんだな！」
• 自動修正: あなたが「光良」と注文した瞬間、コンシェルジュが裏で**「光良 焼酎」や「光良 銘柄」**というより具体的な注文に書き換えて、厨房（検索エンジン）に伝えます。
• 結果: あなたが求めているお酒の動画が、最初からズバリ表示されます。

---

🔑 このシステムが解決した 3 つの大きな課題

この「賢いコンシェルジュ」を作るには、3 つの難しい壁を越える必要がありました。

① 「いつ」書き換えるべきか？（When to Write）

課題: 何でもかんでも書き換えると、逆に混乱します。

• 例: あなたが「空気清浄機」と検索した場合、これは「掃除機が欲しい」という明確な機能の注文です。これを「過去の趣味（お笑い動画）」に合わせて「空気清浄機で笑えるネタ」に変えたら、ユーザーは怒ります（これを「意図の逸脱」と呼びます）。
• 解決策: コンシェルジュは、**「ユーザーが最初の注文で満足しなかった時だけ」**介入します。
  • 最初の検索で「すぐに離れてしまった（動画を見なかった）」→「あ、間違えてたな。書き換えよう！」
  • 最初の検索で「満足して長く見ていた」→「そのままの注文で OK。書き換え不要！」
  • この「書き換えるべきタイミング」を、過去のデータから自動で学習させました。

② 「どう」書き換えるべきか？（How to Write）

課題: いくら意味が通じても、検索システムが「その言葉」を認識していないと、何も出てきません。

• 例: コンシェルジュが「光良の最高に美味しいお酒」という素敵な文章を生成しても、検索システムが「光良 最高 美味しい」という言葉を登録していなければ、結果はゼロです。
• 解決策: 2 段階のトレーニングを行いました。
  1. SFT（教師あり学習）: 「過去の成功例」を見て、どう書き換えるかを基本教えます。
  2. GRPO（強化学習）: 「検索システムにヒットしやすい言葉」を選ぶように、**「正解の報酬」**を与えて訓練します。「検索結果がたくさん出る言葉」や「クリックされる言葉」を生成するように、AI の癖をシステムに合わせました。

③ 「遅延」をどう防ぐか？（Deployment）

課題: 賢いコンシェルジュは考えるのに時間がかかります。注文から料理が出るまで待たされると、ユーザーはイライラします。

• 解決策: **「並行して動く『偽の在庫』」**という仕組みを使いました。
  • 通常、検索結果を出すには時間がかかります。
  • しかし、WeWrite は**「メインの検索」と同時に、裏で「AI が考えた新しい言葉」で検索**を始めています。
  • さらに、**「よくある検索結果のリスト（偽の在庫）」**を事前に用意しておき、AI が考えた言葉がこれに合致すれば、即座に結果を返します。
  • ユーザーは「待たされた」と感じることなく、瞬時に最適な動画が表示されます。

---

🏆 実際の効果

このシステムを実際の巨大な動画プラットフォーム（微信チャンネルなど）でテストしたところ、素晴らしい結果が出ました。

• 動画視聴時間の増加: ユーザーが「10 秒以上」動画を見てくれる回数が1.07% 増えました。
• 検索のやり直し減少: ユーザーが「あれ？違うな」と思って検索ワードを修正する回数が2.97% 減りました。

まとめ

この論文は、**「ユーザーの過去の行動をヒントに、AI が『今、あなたが本当に求めているもの』を推測して、検索ワードを自動で補正する」**という仕組みを提案しています。

• いつやるか: ユーザーが不満を持っている時だけ。
• どうやるか: 検索システムに合った言葉で、かつユーザーの好みに合うように。
• どう速くするか: 並行処理と事前準備で、待ち時間ゼロを実現。

これにより、ユーザーは「自分が探している動画」を、より早く、より正確に見つけることができるようになりました。

技術概要

論文技術サマリー：WeWrite

1. 背景と課題 (Problem)

ショート動画プラットフォーム（例：微信チャンネル）における検索システムでは、ユーザーの検索クエリが短く曖昧であることが多く、意図の特定が困難です。既存のクエリリライト手法には以下の課題がありました。

• 意図の逸脱（Intent Drift）: 過去の行動履歴を無差別に利用してクエリを拡張・修正すると、機能的なクエリ（例：「エアフライヤー」の使い方）がエンターテインメント志向の履歴によって誤って歪められ、本来の検索意図から外れるリスクがあります（「いつ書くべきか」の判断が欠如）。
• 遅延とコスト: 大規模言語モデル（LLM）の推論コストが高く、リアルタイムな動画検索システムのような厳密なレイテンシ制約を持つ環境に直接統合することが困難です。
• シグナルの希薄化: 従来の暗黙的な履歴特徴量を用いる手法では、フィードバックの遅延やシグナルの希薄化により、高精度なパーソナライズが難しいという問題がありました。

2. 提案手法：WeWrite (Methodology)

著者らは、これらの課題を解決するために**「WeWrite」**という新しいパーソナライズされた需要意識型クエリリライトフレームワークを提案しました。このフレームワークは、以下の 3 つの主要モジュールで構成されています。

A. 「いつ書くか」：事後ベースのサンプルマイニング (Posterior-based Sample Mining)
パーソナライズが「必要不可欠」な場面を特定し、不要なリライトを防ぐためのデータ構築プロセスです。

• ポジティブサンプル（リライトが必要）: ユーザーが元のクエリで短時間しか視聴せず（失敗）、直後に検索し直して長時間視聴した（成功）ケースを抽出。さらに、新しいクエリに含まれる単語がユーザーの履歴（視聴履歴や位置情報など）と重複しているか、LLM による意図検証（Qwen3-32B など）を行い、文脈に基づいた正当なリライトかを確認します。
• ネガティブサンプル（リライト不要）: 元のクエリですでに満足して長時間視聴したケースを抽出し、モデルに「リライトしない（）」ことを学習させます。
• これにより、意図の逸脱を防ぎつつ、パーソナライズが必要な高品質なトレーニングデータを構築します。

B. 「どのように書くか」：スタイル整合型 LLM 微調整 (Style-aligned LLM Fine-tuning)
生成されたクエリが検索システムのインデックスと適合し、実際に検索結果が得られるようにするための学習プロセスです。

• 教師あり微調整 (SFT): 上記で構築したデータセットを用いて、文脈と元クエリから適切なリライト（または拒否）を生成する基礎能力を学習させます。
• 強化学習 (RL) によるスタイル整合: 生成されたクエリが検索インデックスに存在しない（ゼロリコール）や、低品質な場合を防ぐため、GRPO (Group Relative Policy Optimization) を採用します。
  • 報酬関数: 検索ログに基づき、「検索頻度（Freq）」と「クリック率（CTR）」を最大化し、未知の用語（ハルシネーション）にはペナルティを与える報酬を設計。
  • これにより、LLM の出力スタイルを検索システムのインデックス分布に整合させ、実用的なクエリを生成できるようにします。

C. デプロイ：Fake Recall アーキテクチャ (Deployment)
LLM の推論遅延を回避するための並列処理アーキテクチャです。

• Fake Index 構築: オフラインで、有効なシステムクエリとトップドキュメントの対応関係をキーバリュー形式で事前構築した「Fake Index」を作成します。
• 並列実行: ユーザーリクエスト時に、従来の検索パス（テキスト/ベクトル検索）と並行して、LLM によるリライトパスを非同期で実行します。
• 融合: LLM が生成したクエリが Fake Index にヒットすれば即座に候補を取得し、従来の候補リストと融合してランキングします。これにより、LLM 推論によるレイテンシ増加をユーザーに感じさせずに（Zero-perceived-latency）、パーソナライズを実現します。

3. 主要な貢献 (Key Contributions)

1. 事後ベースの「いつ」戦略: ユーザーの事後フィードバック（再検索や滞在時間）を活用し、パーソナライズが厳密に必要となるシナリオを自動マイニングするメカニズムを提案。意図の逸脱を効果的に抑制。
2. GRPO 整合の「どのように」学習: SFT と GRPO を組み合わせたハイブリッド学習パラダイムを提案。検索システム固有のインデックスや CTR を報酬として最適化し、検索に強いクエリ生成を実現。
3. Fake Recall による低遅延デプロイ: LLM 推論をメインパスから分離する並列アーキテクチャを設計し、大規模動画検索システムでの実用化におけるレイテンシ課題を解決。

4. 実験結果 (Results)

大規模な動画プラットフォームでのオンライン A/B テストにより、以下の成果が確認されました。

• クリック率向上: 10 秒以上視聴された動画のクリック数（VV>10s）が 1.07% 向上。
• 再検索率低下: ユーザーによるクエリ再検索（Query Reformulation）率が 2.97% 減少。
• これらの結果は、明示的なパーソナライズ手法が曖昧なユーザー意図の解決に有効であることを示しています。

5. 意義と結論 (Significance)

本論文は、動画検索におけるクエリリライトにおいて、単なる文脈の追加ではなく、「いつパーソナライズを行うべきか（When）」と「システムに適合した形でどのように生成するか（How）」という 2 つの根本的な問いに答える包括的なフレームワークを提示しました。
特に、LLM の高コスト・高遅延という課題を「Fake Recall」アーキテクチャで克服し、大規模システムでのリアルタイム適用を可能にした点は、実務的な観点から極めて重要です。また、強化学習を用いて検索インデックスとの整合性を確保したアプローチは、生成 AI を検索システムに統合する際の新たな指針となるでしょう。