Picnic：LLMベクトル埋め込みでオンライン食品検索の精度を向上

Before

Picnicはオランダ、ドイツ、フランスで事業を展開するオンライン生鮮食品デリバリーサービスである。スマートフォンの小さな画面から数万種類の商品を注文し、自宅まで届けるというモデルは、実店舗での買い物にかかる時間と手間を削減する顧客価値を提供している。しかし、このモデルの成功には、ユーザーが必要な商品を迅速かつ正確に見つけられる検索機能が不可欠であった。

多様な検索行動の复杂性

Picnicのプラットフォームでは、誕生日パーティーからクリスマス会、レゴからPicnicグッズまで、あらゆる商品が検索対象となり、数百万種類の検索語が使用されていた。3カ国の異なる言語と食文化を抱える顧客基盤に対応する必要があり、検索システムの構築は単純なテーブル参照以上の複雑さを帯びていた。

ユーザーの検索行動は一様ではなかった。ヨーグルトを探すユーザーが「jogurt」と綴り間違いをする場合もあれば、実際には別のものを探している場合もある。二重スペースやタイプミスによるランダムな文字追加など、あらゆるタイポが発生する。「ice（氷）」を探しているユーザーが、氷の塊ではなく製氷器を探していることをどう伝えるか——検索システムは、単なる文字列一致を超えた「意図の理解」が求められていた。

多言語対応の課題

オランダ語圏のユーザーが「fromage（フランス語でチーズ）」と検索した場合、オランダではフランス産チーズを、フランスでは一般的なチーズを期待する。同じ検索語でも、ユーザーの言語・地域コンテキストによって期待する結果が異なるため、単純な翻訳やキーワード対応では不十分だった。

速度とのトレードオフ

多くの顧客が週1回の食材買い出しにPicnicを利用しており、検索結果は入力と同時に表示されることが期待されていた。一般的なLLMの応答は数秒を要するが、ECサイトの検索ではミリ秒単位の応答が求められる。高度な言語理解とリアルタイム性の両立は、技術的に困難な課題だった。

AI導入内容

Picnicはこれらの課題に対し、LLMを活用したプロンプトベースの商品説明生成とベクトル埋め込みによる意味的検索を組み合わせたアプローチを採用した。

プロンプトベース商品説明生成

検索語を、カタログ全体の商品・レシピと比較可能な説明文に動的に変換する仕組みを構築した。OpenAIのGPT-3.5-turboを使用し、検索語からユーザーの意図を捉えた詳細なクエリを生成する。例えば「娘の誕生日パーティー用に何を買えばいい？」や「大切な人とのロマンチックなディナーの準備」といったシナリオでも、プロンプトがユーザーの意図を関連商品の説明に変換する。

GPT-3.5-turboは、はるかに遅いGPT-4-Turboと比較して同等の性能を発揮しつつ、コストとレイテンシのバランスに優れていたため選定された。

事前計算による高速応答

数百万の検索クエリに対して、 埋め込みを事前計算（precompute） する戦略を採用した。過去の顧客検索履歴から、99%の検索語の埋め込みを事前に計算しておくことで、ミリ秒単位のレイテンシ要件を満たす。新規クエリに対しては、OpenSearchを活用して事前計算済みの埋め込みとの類似性検索を高速に実行する。

商品・レシピのコンテンツ埋め込みと検索語の埋め込みの両方を事前計算し、システム全体にキャッシュ機構を実装することで、計算量とエネルギー消費を最小化するコスト効率と環境責任の両立を図っている。

OpenSearchベースのセマンティック検索パイプライン

OpenSearchを使用してデータ集約型アプリケーションを構築。2つのインデックスを使用する設計を採用している。

検索語埋め込みインデックス：事前計算した検索語のプロンプトと埋め込みを管理
エンティティ埋め込みインデックス：商品・レシピの埋め込みを管理

OpenAIのtext-embedding-3-smallモデルを使用して埋め込みを生成。OpenSearchの最大次元数が1,536であるため、このサイズに合致するtext-embedding-3-smallの出力次元が最適と判断された。

パイプライン内には、埋め込みの整合性や適切な長さを検証する**健全性チェック（sanity checks）**を多数統合。言語モデルの更新やモデルイテレーションによる出力のばらつきを検出し、システム全体の信頼性を確保している。

オフライン最適化とオンラインA/Bテスト

開発プロセスは、オフライン最適化から始まる。検索パラメータの調整、プロンプトや次元サイズなどのLLM設定の変更、異なるモデルの実験を本番環境に影響を与えずに実施する。ただし、過去の検索結果を使用したオフライン評価は「ground truthが期待ほどクリーンではない」ため、パラメータの初期調整に留めている。

次にオンラインA/Bテストを実施。新機能を制御されたユーザー群に導入し、実際のユーザーが変更と既存システムとのどちらを好むかを収集する。これは「はるかに信頼性の高い情報源」であり、多くの反復を通じてアプローチを最適化する。

A/Bテストで成功が実証された後、全ユーザーへの展開を行い、負荷増加とシステム安定性を慎重にモニタリングする。展開後も、より多くのユーザーが新機能と相互作用することで追加データが収集され、さらなる最適化とパーソナライズの精度向上に活用される。

After

LLMベースの検索強化により、Picnicは顧客の検索体験を大幅に改善した。

検索意図マッチング精度：約15%向上

従来のキーワードマッチングでは捉えられなかったスペルミス、曖昧な表現、多言語クエリに対して、検索意図と商品のマッチング精度が約15%向上した。「jogurt」のような綴り間違いや、「fromage」のような多言語クエリでも、ユーザーの期待に合った結果が提示されるようになった。

コンバージョン率とエンゲージメントの向上

検索精度の向上は、ユーザーが必要な商品をより迅速に発見できるようになったことで、クリック率とコンバージョン率の改善につながっている。特に「アイス（ice）」を検索した際に製氷器を提示するような、意図の文脈理解による検索結果の質向上は、顧客満足度に直接的に寄与している。

リアルタイム性の維持

事前計算戦略とOpenSearchによる高速検索により、LLMの本来の遅延（数秒）を回避し、ユーザーがタイピングしながら期待するミリ秒単位の応答速度を維持している。顧客の週次買い物の効率性を損なうことなく、高度な言語理解を検索に組み込むことに成功した。

コスト効率と環境責任

埋め込みの事前計算とキャッシュ機構により、APIコール回数と計算量を最小化。LLM APIの使用コストを抑えつつ、エネルギー消費の削減も実現している。これはPicnicの持続可能性へのコミットメントとも一致している。

継続的な実験と進化

Picnicは、検索ランキングの変更からレシピと商品の混在表示の方法、文字列検索とLLMベース検索のハイブリッドアプローチの採用に至るまで、数百万通りの設定パターンと実験を継続的に実行している。検索は「ユーザーのクエリの意図が変化するにつれて進化し続ける」ものであり、常に適応し続ける必要があるという認識のもと、反復的な改善サイクルを回し続けている。

Picnicの取り組みは、生鮮食品ECという特殊なドメインにおいて、LLMの高度な言語理解能力と、EC検索に求められるリアルタイム性・コスト効率を両立させた実践的なアプローチを示している。事前計算とキャッシュによるインフラ最適化、そしてA/Bテストに基づく慎重な展開は、大規模ECプラットフォームにおけるLLM導入の参考となる。