Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クックパッド検索システム統合/Cookpad Search System Consolidation

クックパッド検索システム統合/Cookpad Search System Consolidation

クックパッド検索システム統合について
https://techlife.cookpad.com/entry/2024/12/11/111200

Search Engineering Tech Talk 2025 Winter にて発表
https://search-tech.connpass.com/event/345134/

Orgil Dj

March 05, 2025
Tweet

More Decks by Orgil Dj

Other Decks in Programming

Transcript

  1. © 2025 Cookpad Inc. Search Engineering Tech Talk 2025 Winter

    検索システムの統合 Elasticsearch 移行 クックパッド株式会社 レシピ事業部 D. Orgil (オリギル) 1
  2. - Д. Оргил オリギル (@orgil_) - クックパッド、検索エンジニア - モンゴル人 -

    趣味: - ボルダリング、サバゲー、タイムラプス動画 - アニメ、ガンダム、マクロス - 最近、ガンプラ作りが再燃した 自己紹介 © 2025 Cookpad Inc. 2
  3. - 多言語対応した、通称 Global-search-2という検索システムが動いている - 日本とGlobalではシステムが別れていた - 日本語検索 (Voyager) - 主に

    Solr, ruby - Global-search-2 (GS2) - Elasticsearch, python © 2025 Cookpad Inc. 9 30言語を支える多言語検索エンジン GS2の概要については2022年のCookpad TechConfでも話しました https://speakerdeck.com/giga811/go-global-search-2 8.x
  4. - One-experience project - 去年の8月頃に完全移行した - © 2025 Cookpad Inc.

    10 2つのクックパッドプラットフォームを統合した https://techlife.cookpad.com/entry/2024/10/10/105832
  5. - 検索システムを統合する - GS2 と Voyager どっちに寄せるかを議論した - いろいろ考慮事項はあったが GS2にした

    - まずは機能的に完全にコピーを目指した - RBOという指標で一致度を測りながら実装していった - パフォーマンス改善もたくさんやった - レスポンスタイムを統合前と同じ水準を目指した - ユーザーの体験を損なわないように進めた One-experience Search © 2025 Cookpad Inc. 12 https://techlife.cookpad.com/entry/2024/12/11/111200
  6. - どっちも一長一短、大きく優劣はなかった - Solr vs Elasticsearch: 検索クエリはあまり問題にならなかった、どっちも Luceneベースで同じ順番は再現で きると思えていた -

    検索アルゴリズムのベースはどっちも一緒 - 辞書展開して、synonym, 親子キーワードマッチして、タイトル優先して新着順、人気順で並べている - Global がもともと日本を参考に作られた - ドキュメントの反映時間もほぼ同等 - 日本はベースは日次バッチだが、 5分ごとのリアルタイム反映もある - Globalはkafkaを用いたイベントシステムでドキュメント更新はほぼリアルタイム - しかし Tech stack は大きく違う GS2 vs Voyager © 2025 Cookpad Inc. 13 5分間隔インデックス改修について https://techlife.cookpad.com/entry/2023/10/05/ 150000
  7. - Tech stack: - Voyager - ruby - solr -

    mecab - hako(ECS) - kuroko2 - GS2 - python - elasticsearch - k8s - kafka - fastapi, faust Tech stack の違い © 2025 Cookpad Inc. 14 Hako
  8. - 速さ - GS2 のほうが4倍くらい遅かった(当時) - p50: 20ms vs 80ms

    - p95: 80ms vs 280ms - Voyagerが速い理由 - Solr の構成が効率的 - 1node 1index 構成、独立したノードを並べている - このおかげでコストも大幅に安い - クエリキャッシュがめちゃ効く - pre tokenize - 形態素解析済みのテキストをIndexしてる - synonym filter を用いたシノニムマッチ - Global は都度synonym展開した match query をビルドしている - Voyager は速い! © 2025 Cookpad Inc. 15
  9. - 辞書の変更がすぐに検索に反映される - 日本: 辞書変更→レシピ再tokenize、solr にインポート、各所mecab 辞書更新、solr synonym filter 更新

    - Global: 検索時にES query をビルドするため、即時反映 - 愚直にsynonym展開したES queryをビルドしてる - このせいで遅いのもある - Global は辞書を1から作っている言語が多いし、日々の検索改善、辞書改善を現地の CM(Community Manager)にまかせている(エンジニアが30言語習得できないため ) - 辞書の変更を見ながら改善していく必要性 - 辞書でコントロールできる項目が日本のシステムより多い (=逆輸入コストがでかい ) © 2025 Cookpad Inc. 16 GS2は辞書変更が即時反映
  10. - Lucene ベースで同等な結果を再現できる - synonym filter などの機能も揃っている - 形態素解析も日本と同じように事前にやればいい -

    他言語と違う処理になるが許容できる - Globalは基本ESの設定のみで多言語対応している - ES外トークナイズする必要性はすでにあがっていた - タイ語、中国語がESアナライザーのみではうまく行っていなかった - 速度も日本が早い理由がわかっているので、頑張れそう - synonym filter があれば行けそう - クラスタ構成は、最悪日本専用クラスタ立てれば行けるんじゃない - もしくはクラスタ内で専用ノードを設定するとか - 日本をGS2でやるのはできそう © 2025 Cookpad Inc. 18
  11. - Globalのロジックをベースにするんじゃなく、まずは検索結果の移植を目指した - GS2内で日本専用のクエリビルダーをつくることにした - ロジックの統合はあとで探る - ユーザートラフィックがない中で GS2のスコアリングのクオリティを測ることができなかった -

    大きく2つのタスク - algorithm: - 検索ロジック開発、来たクエリから ESクエリをビルドする - ingestion: - インデックスを用意する、形態素解析、親子フィールド , ML fields、人気順スコアなど 進め方 © 2025 Cookpad Inc. 20
  12. - 検索結果が同等かを RBOという指標を使って測っていた - RBOとは - 2つの結果の一致度を測る指標の一つ - 上位(Rank)にあるものほど、一致度の重要度が上がる -

    1位が似てることのほうが30位より大事 - 20位がないことより、2位が3位にずれているほうが大事 - RBOパラメータによってトップへの Bias度を調整できる - 今回は 0.978 を用いた(0.98でもよかったかも) - top60レシピで9割のスコアに影響するように調整 - 検索トラフィックのほとんどが最初の 3ページにあるため - RBO = Rank Biased Overlap © 2025 Cookpad Inc. 21
  13. - より厳密にはRBOの計算で配列が無限だと仮定した比較方法を採用している - まったく違うプラットフォームを比較しているため、ヒット件数の違う結果を比べる可能性もある - python rbo パッケージの以下に相当 - https://github.com/changyaochen/rbo

    - rbo.RankingSimilarity(a, b).rbo(p=0.978, ext=True) - 例えば p=0.9 だとより上位の似ている度合いが大事になってしまう - 上位10件が似てるかだけが大事になってしまう - 0.978 は上位60くらいの(3ページ目)ところまで広く比較したかった - 両方のシステムで上位 100件を比較していた RBO = Rank Biased Overlap © 2025 Cookpad Inc. 22
  14. - RBO 比較 - 毎日、過去7日の top 20000 クエリに対して比較 - 20000のうちにはtailクエリもたくさん含まれている

    - ある程度エッジケースのうまく行っていないキーワードも発見できた - 上位 100 件の結果を比較 - 新着順と人気順でみる - 人気順のみの挙動とか結構あるので両方でみた - アルゴリズムとingestion の進捗度がわかるような形で測った - 日本のシステム用のデータをインデックスしたもので純粋なアルゴリズムの計測 - Low RBOを見ながら、原因を突き止め、開発していく - Ingestion, GS2 のシステムのみで出来たデータで計測 - gs2 ingestion パイプラインで正しいドキュメントが作成できているか - 正しいデータを作成できていればアルゴリズム比較の測定と同じになるはず RBO を見ながら進捗を測れた © 2025 Cookpad Inc. 23
  15. - ちょっとずつ良くなっていっている - まずは基礎的なサポート - synonym 設定したり - クエリをmecabでトークナイズするように -

    日本のアルゴリズムのベースを実装 - RBO分布を右に寄せるゲーム © 2025 Cookpad Inc. 25
  16. - Voyager の機能をわかるだけ列挙していった - Low RBO キーワードを眺めながら足りない機能の優先度を付けて開発していった - 低RBO(<0.4): -

    未実装の機能や、形態素解析の仕様が微妙に違うとか - 中RBO(0.6-0.8): - 中身見ると結構似ているので、本当に微細は機能差だった - 高RBO(>0.8): - この辺はほとんど問題にならない微差だった Low RBO を分析 © 2025 Cookpad Inc. 27
  17. - ドキュメント正しく用意することも大事 - 同等なドキュメントを用意しないと、アルゴリズムが一緒でも結果にズレが生じてしまう - 正しいドキュメントを生成できていればアルゴリズムの RBOと同じになるはず - レシピのトークナイズ -

    ingestion 時に mecab で形態素解析 - 辞書を使ってドキュメントを拡張 - 日次インポート系の属性 - ML fields - 人気順 score - 一旦Voyagerが用意したデータを GS2がインポートするだけ - あとから、それをGlobalのデータで集計、計算するように置き換えた - プラットフォームも違えば、ログ基盤、ログ集計などすべてが違うため Ingestion の実装の進捗も RBOで測れた © 2025 Cookpad Inc. 28
  18. - 新着 - Recency >=0.9: 74.7% - Recency >=0.8: 97.2%

    - 人気順 - premium >=0.9: 82.5% - premium >=0.8: 95.1% 最終的に: 平均RBO 0.9 RBO 0.9 はほとんど同じ、1,2件のレシピが違うとか、順番 が前後レベル、0.8でも十分高い © 2025 Cookpad Inc. 30
  19. - パフォーマンスチューニング - ユーザーのために同じ結果を同等な速度で返すことに注力 - 検索において速さは大事 - 4倍差は許容できない - いざ組み上げてみるとすでに速かった

    - synonym filter, 辞書の事前拡張などの構成は日本のと同じ - あとはES周りをいろいろ調整した - GS2のAPMでどこを早くすればいいのかわかりやすかった - API側なのか - 検索キーワード解析なのか - ESクエリビルドなのか - ES側なのか - 辞書データフェッチか - 検索リクエストなのか SPEED © 2025 Cookpad Inc. 31
  20. - いろいろやって - API側の無駄な処理を減らしたり - ESでmerged field 使ったり - シャード数増やしたり

    - named query やめたり - クラスタ構成見直したり - いろいろ試してた - Voyager -> GS2 - p50: ~20ms -> ~30ms - p95: ~80ms -> ~50ms p95 では日本より速くなった © 2025 Cookpad Inc. 32
  21. - script score は意外と早い - merged text field が強い -

    速さの秘訣、主にsynonym filter - RBOが使いやすかった - 詳しくは懇親会などで聞いて下さい © 2025 Cookpad Inc. 33 移行の際のいくつかの学び、 tips
  22. - プラットフォーム統合はユーザーに大きな負担を強いる挑戦だった - 検索結果、応答性は同等なものを提供できるよう注力した - デザイン、UI変わるとか変更要素が多い中で出ているレシピは同じものにしたい - 結果 - ほぼ同等な検索、RBO平均0.9以上

    - パフォーマンスも同等 - 統合後 - Global な Search 開発 - 全言語を対象に開発 - 人気順の改善をしたり - 材料検索の改善をしたり - 日本とGlobalの検索アルゴリズム統合 - 両方の良し悪しを議論しながら統合していきたい - 最後に © 2025 Cookpad Inc. 34
  23. - 多言語検索の基礎 - 基本はElasticsearchのtokenizer設定 - lowercase, diacritic mark などの正規化 -

    各言語にあった stemmer - https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-stemmer-tokenfilter.html#anal ysis-stemmer-tokenfilter-language-parm - stemmer のエラーは手動で調整 - keyword_marker: 指定されたキーワードは stem されない - stemmer_override: カスタム stem ルールを追加できる - 例: brownies - © 2025 Cookpad Inc. 35 時間あったら、多言語検索の基礎
  24. - 特別な言語 - continuous language - ハンガリー語、ドイツ語 - 日本語、中国語、タイ語 -

    続きはそのうち弊社 techlife に書こうと思います - X: @cookpad_tech をフォロー - Techlife blog: https://techlife.cookpad.com/ - © 2025 Cookpad Inc. 36 時間あったら、多言語検索の基礎 https://x.com/cookpad_tech
  25. - One-experience 統合について https://techlife.cookpad.com/entry/2024/10/10/105832 - One-experience 検索について https://techlife.cookpad.com/entry/2024/12/11/111200 - -

    Go Global Search 2 https://speakerdeck.com/giga811/go-global-search-2 - JP 5分間隔インデキシング https://techlife.cookpad.com/entry/2023/10/05/150000 - Solr 構成 https://techlife.cookpad.com/entry/2020/11/25/080000 - - Techlife blog: https://techlife.cookpad.com/ - Cookpad Techlife X: https://x.com/cookpad_tech - 資料 © 2025 Cookpad Inc. 37