DoorDash・Instacart・Uber Eatsは、検索へのLLM統合をそれぞれ別の場所に配置している——各社の公式エンジニアリングブログで確認できる事実だ。DoorDashはLLMを、商品ナレッジグラフの属性抽出・ブランド識別というカタログ側の下ごしらえと、頻出クエリの固定集合に対するバッチ推論に使う(この工程をDoorDash自身が明示的に「オフライン」と呼んでいるわけではない)。Instacartはリアルタイムのクエリ理解層にLLMを置きながら、稀少クエリ向けにLlama-3-8BをLoRAでファインチューニングし、LoRAアダプタの統合とH100 GPUへの移行によって300ミリ秒以下まで軽量化して初めてサービングに乗せた。Uber Eatsはさらに踏み込み、ファインチューニング済みQwenを2タワー検索の埋め込みバックボーンそのものに焼き込み、検索のたびにLLMを呼び出す必要自体をなくした。3社に共通するのは、巨大LLMを検索のクリティカルパスにそのまま置くという選択肢を誰も採っていないことだ。検索を実装する開発者にとっての問いは「LLMを使うか否か」ではなく、レイテンシ予算の中でLLMの知性をどこに・どう圧縮して埋め込むかという設計判断に移る——単体モデルの賢さよりも、モデルをシステムのどこにどう配置するかという設計の巧拙が成果を分ける、というオーケストレーション的な大きな流れを裏付ける一例だ。

何が起きたか

DoorDash、Instacart、Uber Eatsという米国の大手消費者向けサービス3社が、検索システムにLLMを組み込む際に採った実装アプローチが、各社の公式エンジニアリングブログを通じて明らかになっている。3社は「検索にLLMを使う」という目的を共有しながら、LLMをパイプラインのどの段階に置くかという設計判断において、それぞれ異なる解を選んでいる。

仕組み・詳細

DoorDash: カタログ側の属性抽出とバッチ的なクエリ解析

DoorDashは2本の公式ブログ記事にまたがる形で、LLMを検索の裏側で使っている。1本は商品ナレッジグラフ(Product Knowledge Graph)の拡充で、LLMを使って汎用的な属性抽出モデルを構築し、新規ブランドを大規模に識別するLLM駆動のブランド抽出パイプラインを構築した。もう1本は検索クエリの解析で、LLMにクエリの意味的なセグメントを識別させ、既存のタクソノミーに分類させている。この際、LLMの出力は事前に定義された統制語彙(controlled vocabulary)内の概念のみに制約される。DoorDash自身は「頻出クエリの固定集合に対するバッチ推論は高精度な結果を提供できる」と述べており、これは全クエリを常時オフライン処理しているという意味ではなく、頻出クエリ集合に対する限定的な記述である点に注意が必要だ。なお、商品ナレッジグラフの拡充パイプライン自体を「オフライン」処理だと明示する記述は原文には見当たらなかった。

Instacart: リアルタイムのクエリ理解層とLoRAファインチューニング

Instacartは、検索クエリの意図解釈を担う「Intent Engine」と呼ばれるクエリ理解(Query Understanding, QU)層でLLMを使用している。ここではRAG(Retrieval-Augmented Generation)によるコンテキスト付与、LLM出力を検証するポストプロセッシングのガードレール、そして自社データでのモデルのファインチューニングを組み合わせている。特筆すべきは、出現頻度の低い「tail」クエリに対応するため、オープンソースのLlama-3-8BモデルをLoRA(Low-Rank Adaptation)でファインチューニングし、さらにLoRAアダプタの重みをベースモデルに直接統合してH100 GPUへ移行することで、300ミリ秒という目標レイテンシを達成した点だ。

Uber Eats: LLMを埋め込みモデルのバックボーンに統合

Uber Eatsは、2タワー型(two-tower)検索アーキテクチャの埋め込み層そのものに、ファインチューニング済みのQwen LLMを組み込んでいる。Uber公式ブログは「最新のLLM(QWEN)を、その世界知識と多言語対応能力を活用するため、2タワーの内部でバックボーンとなる埋め込み層として使用している」と説明する。さらにUber Eats独自のデータで追加のファインチューニングを行い、埋め込み空間を自社のアプリケーションシナリオに適応させている。この方式では、検索時にLLMを都度呼び出すのではなく、LLMの知識があらかじめ埋め込みベクトルの計算に焼き込まれている。

数字で見る

  • Instacart: Llama-3-8BをLoRAでファインチューニング。LoRAアダプタをベースモデルに統合し、H100 GPUへ移行することで300ミリ秒のレイテンシ目標を達成
  • DoorDash: 一次ソースは2本の別記事(ナレッジグラフ拡充／クエリ解析)にまたがり、単一記事の内容ではない
  • Uber Eats: 2タワー検索の埋め込みバックボーンにQwen系LLMを採用し、自社データで追加ファインチューニング

背景

この実装パターンは、ByteByteGoが3社の事例をまとめた解説記事で取り上げたことで広く知られるようになったが、内容自体は各社が独自に公開している一次ソース(DoorDash公式ブログ2本、Instacart公式ブログ、Uber公式ブログ)に基づいている。一次ソースを直接確認した結果、ByteByteGoの要約と各社の一次ソースの間に食い違いは見つからなかった。

なぜ重要か

検索にLLMを統合しようとする開発者にとって、この3社の事例が示す教訓は「LLMを検索のどこに置くか」という設計判断が、レイテンシ・コスト・精度のトレードオフを直接左右するということだ。カタログ側の下ごしらえやバッチ処理に回せば、リアルタイムの応答速度やコストの制約からは自由になるが、その場で生まれる新規クエリには対応できない。リアルタイムのクエリ理解層に置くなら、Instacartのようにモデルを蒸留・軽量化し、ハードウェアも強化してレイテンシ予算に収める必要がある。埋め込みモデルに焼き込めば推論時のLLM呼び出し自体をなくせるが、埋め込み空間全体の学習・運用コストを引き受けることになる。単体LLMの性能を競うだけでなく、モデルをシステムのどの位置に、どんな形で配置するかという設計判断——オーケストレーション的な巧拙——が、実務上の検索品質とコストを分ける主戦場になりつつある。