※本記事は、Mounia Lalmas氏によるThe ACM Web Conference 2026の基調講演「Building AI-driven Web Experience at Scale」の内容を基に作成されています。Lalmas氏はSpotifyのシニアディレクター・オブ・リサーチとして、パーソナライゼーション、検索、レコメンデーション、ディスカバリーシステムの研究チームを率いており、これまでにYahooのディレクター・オブ・リサーチ、Queen Mary University of Londonの情報検索学教授などを歴任し、現在はUniversity College Londonの名誉教授、University of Amsterdamのディスティングイッシュト・リサーチ・フェローも務めています。動画の詳細は https://www.youtube.com/watch?v=jNOjJ0z9HhY でご覧いただけます。本記事では、講演内容を要約しております。なお、本記事の内容は講演者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演映像をご視聴いただくことをお勧めいたします。
1. 講演の背景とパーソナライゼーションの意義
1.1 講演者紹介と講演構成
Moderator: 本日はACM Web Conference 2026の2つ目の基調講演にお越しいただき、ありがとうございます。ここでMounia Lalmas博士をご紹介させていただきます。Lalmas博士はWeb検索およびレコメンダーシステムの研究コミュニティにおいて、著者として、また複数の主要な学会の共同座長として、長年にわたり非常に活発に貢献されてきた方です。これまでに260件を超える論文を執筆されており、本カンファレンスであるThe Web Conferenceをはじめ、CIKM、WSDMといった主要学会の共同座長も務められています。現在はSpotifyのシニアディレクター・オブ・リサーチとして、パーソナライゼーションに関する技術研究チームを率いており、検索、レコメンデーション、ディスカバリーシステムを大規模に運用する研究にフォーカスされています。研究領域は情報検索、レコメンダーシステム、ユーザーエンゲージメント、そして生成モデルを含む最新のAI技術を大規模なオンラインプラットフォームに応用することまで広がっています。これまでにもYahooのディレクター・オブ・リサーチ、Queen Mary University of Londonの情報検索学の教授など、産業界と学術界の両方でシニアなポジションを務められており、University of Glasgowでもリサーチプロフェッサーシップを持たれています。さらに、University College Londonの名誉教授、University of Amsterdamのディスティングイッシュト・リサーチ・フェローでもいらっしゃいます。Lalmas博士の研究は基礎研究と実運用への展開を橋渡しするものであり、現在の関心はAIが大規模システムをどのように変えていくかという点にあります。本日のご講演のタイトルは「Building AI-driven Web Experience at Scale」です。Lalmas博士、この度はご招待をお受けいただき、誠にありがとうございます。皆様にご講演を伺える機会を大変嬉しく思っております。それでは、よろしくお願いいたします。
Mounia Lalmas: ご紹介ありがとうございます、Hakimさん。皆様、おはようございます、こんにちは、こんばんは、そしてご参加いただき本当にありがとうございます。The Web Conferenceで基調講演をさせていただけることは、私にとって大変な光栄です。改めて、この度お招きいただいたオーガナイザーの皆様に感謝申し上げます。私はMounia Lalmasと申します。Spotifyでリサーチチームを率いており、パーソナライゼーション、レコメンデーション、そして評価に関する研究に取り組んでおります。本日は、このWeb Conferenceのコミュニティが関心を持たれている研究領域と、私たちが現在AIを通じて業界で経験していることの、まさに交差点にあるテーマについてお話ししたいと思います。私はパーソナライゼーションシステム、つまりユーザーが何を見て、何を聴いて、何を発見するかを決定するシステムに焦点を当てます。同時に、できるだけ具体的な内容にするために、私たちがSpotifyで実際に取り組んでいる研究についてお話しします。これは特定のアプリケーションや課題に少し特化した内容になるかもしれませんが、他の多くのレコメンダーシステムにも関連する内容だと考えています。
本日の講演は4部構成にしたいと思います。まず、パーソナライゼーションの役割について説明し、AIがそれをどのように変えているかをお話しします。次に、講演の中心となる部分として、AIに伴う新しい技術である生成AIとエージェント型システムに焦点を当て、少なくとも私たちがSpotifyで見ている現象、そして他の方々も同様に見ているであろう、検索とレコメンデーションがどのように収束しているかについてお話しします。時間があれば評価についても触れたいと考えています。これは私自身にとって非常に思い入れの強いトピックでもあります。AIによって新しい生成システムを評価する必要が生じている一方で、AI自体が評価のための新しいツールを提供してもいるという状況です。最後に、今後私たちが取り組むべきことについて展望を述べて締めたいと思います。それでは早速始めさせていただきます。
1.2 Webにおけるパーソナライゼーションの役割とSpotifyの規模
Mounia Lalmas: AIとパーソナライゼーションというテーマは、まさにWebが人々をコンテンツへと結びつける方法そのものに関わるものです。この点を少し整理してお話ししたいと思います。まず豊富さという観点から始めます。Webには、誰も到底ナビゲートしきれないほど膨大なコンテンツが存在します。例えばSpotifyだけを見ても、1億以上のトラックを抱えています。パーソナライゼーションとは、こうした膨大なコンテンツの中から関連性のあるものを浮かび上がらせることで、Webをナビゲート可能にするものです。検索エンジンやレコメンデーションの結果の大部分はこのスケールの問題に関わっており、それらは各個人ごとに一意に組み立てられ、数十億のユーザーに対してミリ秒単位で処理されなければなりません。誰かがSpotifyやGoogle、あるいは他のどのプラットフォームを開いたとしても、隣にいる人と同じものを見ているわけではありません。その体験はリアルタイムでその人のために構築されているのです。
これがパーソナライゼーションの本質であり、そこには大きな利害が伴います。何が表面化されるかによって、人々が文化、情報、商取引などをどのように発見するかが左右されるからです。この意思決定には、ユーザー、クリエイター、プラットフォーム、広告主など、それぞれ異なる関心を持つ複数の関係者が関わっています。本日の講演では、Webを利用して何かを消費しようとしている人々、つまり消費者の視点に焦点を絞ってお話しします。
このスケールと課題を具体的に理解していただくために、少し数字を挙げたいと思います。Spotifyには7億人を超えるアクティブユーザーがおり、118以上の市場で利用可能です。コンテンツとしては音楽トラック、オーディオブック、ポッドキャストタイトルなどがあります。ここで重要なのは、コンテンツの多様性がボリュームと同じくらい重要だという点です。音楽、ポッドキャスト、オーディオブックはそれぞれ異なるリスニングパターンを持ち、異なる発見のダイナミクスがあり、ユーザーがそれらと関わる方法も異なります。これらすべてを、すべてのユーザーに対してリアルタイムでパーソナライズする必要があるのです。つまり、単に大きな数字の話だけではなく、コンテンツの種類そのものが課題になっているということです。
2. パーソナライゼーションの進化と検索・レコメンドの融合
2.1 パーソナライゼーションの3つの進化フェーズ
Mounia Lalmas: パーソナライゼーションはこれまで、おおよそ3つの大きなフェーズを経てきたと考えています。最初のフェーズは人間による編成です。人間が何が関連性が高いかを判断し、それをエディトリアルに表示するというものでした。例えば古い時代のYahooのオリジナルディレクトリや、Spotifyでいえば編集者が手作業で作成したプレイリストの時代がこれに当たります。これは編集者によってハンドピックされたプレイリストの時代でした。
第2のフェーズは予測型です。これは本カンファレンスでも多く発表されている機械学習的なアプローチが中心となる段階です。モデルがユーザーの行動から学習し、コンテンツを予測してランキングするというものです。システムはユーザーが何を聴いたか、何をスキップしたか、何を語ったかを観察・記録し、そこから次にユーザーが望むであろうものを予測することを学習します。Spotifyでよく知られた例がDiscover Weeklyです。これは各リスナーに固有のミックステープであり、毎週月曜日に届けられ、ユーザーがSpotifyプラットフォーム上で聴いてきたすべての履歴から構築されています。
そして現在私たちがいるのが第3の生成フェーズです。これは意図を理解し、その場で推論を行うシステムの段階です。過去の行動から何をユーザーが望んでいるかを推測するのではなく、生成システムはユーザーがその瞬間に表現した内容に応答することができます。「元気になれるポストカードが欲しい」あるいは「通勤中に聴きたい」といった表現に対して、システムはそのリクエストを解釈し、応答を生成します。
この変化は、実はより深い概念的な転換を伴っています。パーソナライゼーションの歴史の大部分において、システムの仕事はおおむね、ユーザーがクリックしたものやストリーミングしたもの、あるいは途中でやめたものといった暗黙的な信号を使って推測することでした。システムはパターンを学習し、次に何が関連性があるかを推論していました。これは強力なアプローチですが、常にユーザーが過去のインタラクションの中で既に明らかにしたものから出発するという制約がありました。つまり、ユーザーが言語で表現した「今、まさに」望んでいることには応答できないのです。ここにこそ、推論に基づくパーソナライゼーションへの転換があります。システムは言語を理解し、コンテキストを把握し、表明された意図に応答することができるようになります。「長時間のドライブ中なので、何か引き込まれるようなものが欲しい」「このアーティストの作品はもう全部聴いた。似ているけれど新しいものは何かないか」といった要求は、過去の履歴の信号だけからは答えることができません。言語理解とその場での推論が必要になるのです。
推論に基づくパーソナライゼーションが実現すると、システム側で4つのことが可能になります。1つ目は意図理解です。自然言語がキーワード検索に代わり、システムは何が入力されたかだけでなく、何が意図されていたかを解釈します。2つ目は説明可能性です。レコメンデーションが単なるランキングリストではなく、理由を伴って提示されるようになり、その意思決定の過程を追跡できるようになります。3つ目はエージェント的推論です。システムはリスニング履歴、カタログの知識、コンテキストを横断して統合し、計画を立ててから応答を生成します。この点について付言しておきたいのですが、エージェントに関する研究自体はまったく新しいものではなく、実はずっと以前から取り組まれてきたものです。今変わったのは、推論能力が大きく向上し、それが大規模に実現できるようになったという点です。4つ目はリアルタイムでのステアリングです。会話の途中であっても、最初からやり直すことなく、自然言語を通じて体験の方向を変えることができます。これもパーソナライゼーションにおける大きな変化の一つです。
2.2 ユーザー体験の変化と検索・レコメンドの収束
Mounia Lalmas: こうした変化は、ユーザー側にも影響を及ぼしています。現在起きているのは、パーソナライズされたシステムとのインタラクションが、会話へと変化しているということです。人々は明示的に好みを表現し、結果を精緻化し、システムが自分をどのように理解しているかを確認できるようになりつつあります。これは、なぜその結果が出てきたのか分からないまま単にレコメンデーションを受け取るという従来のあり方とは対照的です。これらの能力自体は完全に新しいものではありませんが、規模と品質の両面で、以前よりもはるかにうまく機能するようになってきているという点を付け加えておきたいと思います。
Spotifyでは、こうした新しい能力を実際に活用しています。ここでお見せしているのは、実際の推論ベースのパーソナライゼーションがどのように機能するかを示す2枚のスクリーンショットです。一方では、ユーザーがディナーパーティー用の音楽を求め、結果を精緻化していく会話の例があります。例えばもっとハウスミュージックを追加するといった形です。もう一方では、比較的新しい機能であるテイストプロファイルの例をお見せしています。これはSpotifyがユーザーのリスニングの好みをどのように理解しているかを、自然言語でユーザーに提示する機能です。これによってユーザーは、システムが自分自身をどのように理解しているかを把握し、それを自分自身で形作ることができるようになります。Spotifyでは、こうした能力の構築と評価に取り組んでおり、本日はその中から3つに絞ってご紹介したいと思います。1つ目は生成的レコメンデーションで、これはアイテムを選択することから、その瞬間に合わせた応答を生成することへの移行です。2つ目はエージェント型検索で、単一クエリの検索から、システムが意図を推論しながら行うマルチターンの発見プロセスへの移行です。3つ目は評価で、オフラインの指標から、意図の充足度や応答の品質を評価できる手法への移行です。なお、本日ご紹介するのはあくまで能力そのものについてですが、その背後には多くの作業があります。システムを利用することに伴うコスト、レイテンシ、そして安全性の側面もあります。本日は明確さを保つため、能力そのものと、実際にアルゴリズムがどのように変化しているかに焦点を当てたいと思います。
それでは、この生成型・エージェント型システムについてお話ししていきます。検索とレコメンデーションは、人々をコンテンツへと結びつける2つの方法であり、これまで伝統的に別個の学問領域として扱われてきました。検索は明示的な意図に基づいて動作します。ユーザーがクエリを入力し、システムはそれをコーパスにマッチングさせ、関連性に基づいてランキングします。これはユーザー主導で単発的なものです。一方でレコメンデーションは暗黙的な好みに基づいて動作します。システムは時間をかけてユーザーの好みやプロファイルをモデル化し、推論に基づいて何が良さそうかを表面化させます。これは主にシステム主導で継続的なものです。異なる信号、異なるアーキテクチャ、異なる研究コミュニティが存在してきましたが、それでもある程度は――私自身がSIGIRのシニア committee に関わっている中で感じたことですが、今年のSIGIRには実は多くのレコメンデーション関連の論文が投稿されていました。話は1992年に遡りますが、当時を覚えている方もいらっしゃるかもしれません。Nick BelkinとBruce Croftは、Communications of the ACM誌において、情報検索、すなわち検索と、その基本的な形態であるフィルタリング、すなわちレコメンデーションのようなシステムは、「同じコインの両面」であると述べています。つまり、両者は異なる方向からではありますが、人々を関連性のある情報へと結びつけようとしているという直感は、当時から既に存在していたのです。
現在変わったのは、AIがこの収束を実際に実用的なものにしているという点です。AIは、自然言語を理解し、ユーザーのコンテキストをモデル化し、意図について推論するシステムを構築するためのツールを提供します。これらすべてが可能になったとき、検索とレコメンデーションの区別は溶けていき始めます。これが本講演のこの部分におけるテーマであり、もう少しこの点について掘り下めていきたいと思います。
このアーキテクチャは、こうした収束の方向性を示しています。左側には3つのインタラクションのモードがあります。ユーザーは明示的なクエリを持って何か特定のものを見つけたいと思っているかもしれません。あるいはオープンな発見を望んで、驚きを求めているかもしれません。あるいはマルチターンの会話の途中にいて、ターンを重ねながら精緻化やフォローアップを行っているかもしれません。ユーザーが関わるインターフェースは異なりますが、その根底にあるニーズは同じです。それは、どのようにリクエストが表現されたかにかかわらず、正しい結果を得ることです。その中心に位置するのがAIであり、私はこれをエージェント、あるいはエージェントになりつつあるものと呼びたいと思います。AIの役割は、リクエストがどのように表現されたかにかかわらず、ユーザーが何を達成しようとしているのかを解釈することです。それは意図についての推論を意味します。それはルックアップなのか、探索なのか。ユーザーについて私たちが知っていること、その好み、その履歴、過去のインタラクションを引き出すことも意味します。会話がどのように展開してきたか、以前に何が語られ、何が明確化され、その道筋でどのような好みが表現されてきたかを追跡することも意味します。右側には知識の2つの源があります。AIエージェントはプラットフォームデータ、すなわち私たちの場合であればSpotifyがユーザーとカタログについて知っているすべての情報を活用します。そしてもう一方は、大規模言語モデルがもたらす世界知識、すなわちLLMが持つセマンティックな理解であり、これはインタラクションログだけからは得られないコンテキストとコンテンツの意味についての推論を可能にします。私たちはこの理想像にまだ到達しているのでしょうか。私自身の考えでは、その方向に向かっている途中だと思います。この講演の残りの部分では、私たちがこの理想に向けて実際に取ってきたステップについてご説明していきます。
3. 統合生成モデルの構築(第一論文)
3.1 課題設定と単一モデルの3つの能力
Mounia Lalmas: まず、ランキングから生成への移行についてお話ししたいと思います。こちらの右側にお見せしているのは、現在のSpotifyのポッドキャストのサーフェスです。これはランキングリストではなく、私たちがユーザーについて知っていること、新しく登場したもの、そしてユーザーがフォローしている対象に応じて応答する、生成されたフィードになっています。これこそが、実際の本番環境における生成的レコメンデーションの姿です。ここでご紹介する研究は、2つの論文に基づいています。両者は関連していますが、それぞれ異なる問題に取り組んでいます。1つ目は、レコメンデーション、テキスト検索、ユーザー理解などを統合的に扱う単一モデルの構築についてのものです。2つ目は、その基盤モデルを実際の本番環境とレイテンシ制約の中に落とし込むことについてのものです。両論文が共有している前提は、会話というものは、検索用、レコメンデーション用といった形で個別のシステムを切り替えることを許容しないということです。ひとつの会話が必要とするのは、単一のモデルなのです。
そもそもの課題は、レコメンデーション、テキスト検索、ユーザー理解といったものが、これまで必ずしも常にというわけではありませんが、概して別々のモデルの中で、タスク間で理解を共有することなく存在してきたという点にあります。タスクごとに個別のモデルを構築することはコストが高く、かつ、あるタスクが別のタスクの学習に寄与するという利点を失ってしまいます。より根本的な問題として、こうした個別のモデルのいずれも、私たちが会話に必要だと考える、あるいは今後さらに必要になるであろう機能の全範囲をカバーすることができません。そこで私たちは、3つの能力を持つ単一のモデルを構築しました。すなわち、複数のコンテンツタイプにわたるパーソナライズされたレコメンデーションの生成(これ自体もいくつかの能力に分かれます)、自然言語クエリからのカタログアイテムの検索、そしてレコメンデーションの説明とユーザーの好みの記述、という3つです。私たちが1つのモデルに3つの能力を持たせた理由は、ひとつの会話の中で「これは検索用だから」「これはレコメンド用だから」といってモデルを切り替えることを許容できないからです。
3.2 設計決定と実験結果
Mounia Lalmas: これを実現するにあたり、重要な設計上の決定が3つありました。1つ目は、インターフェースとして自然言語を採用したことです。これらすべての能力は自然言語を通じてアクセスされます。これはLLMに付随するものであり、まさにこれによって、モデルを再学習せずに推論時にステアリングすることが可能になります。2つ目は、モデルの基盤としてテキストのタイトルではなく、セマンティックIDを採用したことです。セマンティックIDとは、カタログ上のアイテムを表現する短いトークン列です。LLMがトークンをどのように扱うかは既によく知られていますが、私たちはこのトークンという概念を、LLMがもたらす世界知識とも結びつけるようマッピングしたいと考えました。この構築方法にはいくつかの手法があり、私たちも現在なお実験を続けている段階です。詳細は論文をご覧いただければと思いますが、Googleをはじめとする他社からも関連する研究が出てきています。私たちの場合、このトークン列は粗い階層から細かい階層へと構成されています。最初のトークンはジャンルのようなものを表し、その下にサブジャンルがあり、さらにその下に特定のアイテムが来るというイメージです。意味的に類似したアイテムは類似したトークン列を持つことになります。もう少し直接的に言えば、コンテンツを表すベクトルがあり、コンテンツが関連していれば2つのベクトルが近くなるという発想を、このトークン表現に落とし込んでいるということです。これによってモデルは、実在するカタログ上のアイテム、つまり実際に存在する候補アイテムを直接生成できるようになり、LLMが得意としがちなタイトルのハルシネーションを避けることができます。私たちはこの方式で組織化されたアイテムが、フラットなID表現を直接用いる代替手法よりも優れた性能を示すことを確認しています。
学習は3つのステージに分けて行われ、その順序自体も意図的な設計上の選択です。第1ステージでは、モデルはカタログを学習します。すなわちアイテムをそのセマンティックIDのトークン列にマッピングすることを学びますが、この際にLLMがもたらしている言語理解能力を損なわないように保つことが重要な制約となります。私たちが用いているバックボーンのLLMが持つ言語能力を上書きしてしまうことは避けたいと考えているからです。第2ステージでは、モデルはユーザーがカタログアイテムとどのように関わるかに、より整合するよう調整されます。ここでは行動パターン、好み、シグナルなどが用いられます。第3のフェーズでは、実際にマルチタスク学習を行い、レコメンデーション、検索、ユーザー理解を同時に学習させます。このタイミングで学習を行うことで、モデルは既に安定した基盤を持っており、各タスクは互いに競合するのではなく、強化し合う関係になります。結果として、タスクに特化した強力なベースラインと比較して全般的に性能の向上が見られ、さらにタスク間でのポジティブな転移効果が確認されました。例えば、検索の性能を高めることが、レコメンデーションの性能をも向上させるという結果が得られています。これが統合された基盤モデルによってもたらされるものであり、まさに検索・レコメンデーションを含む会話において、ユーザーがどのような形でリクエストを表現しても、単一のモデルで対応できるということを示しています。以上が第1部の内容であり、次にこの基盤モデルを実際にスケールさせた話に移りたいと思います。2つ目の論文では、このセマンティックIDという基盤モデルを取り上げ、それをLLMに組み込み、Spotifyの実際のユーザーの好みなどのデータを取り込みながら、ポッドキャストレコメンデーションという文脈で本番環境に投入した内容についてお話しします。
4. プロダクション展開とエージェント技術
4.1 ポッドキャストレコメンドの本番展開
Mounia Lalmas: 会話の中では、ユーザーが馴染みのあるコンテンツを求めている場面もあれば、後になって何か新しい発見を求める場面もあります。このような場面において、リスニング履歴のみで学習された従来のレコメンドは、当然ながらユーザーが既に見て消費してきたものを優先してしまう傾向があります。新しいコンテンツを表面化させるには、従来、異なる目的関数を用いて再学習することが必要とされてきました。これはコストが高く、時間もかかり、結果として一つのことだけが得意な、限定的なモデルになってしまいます。私たちはこうしたあり方から離れたいと考えました。そこで、モデルに対して「これは馴染みのあるコンテンツである」「これは発見のためのコンテンツである」といった形で指示を与えられるようにしたいと考えました。
このために、私たちは先ほどご説明したセマンティックIDという基盤をそのまま維持しました。つまりモデルはポッドキャストのカタログに根ざした状態を保っていますが、そこに本番環境の制約に対応するために特別に構築した2つの仕組みを加えています。1つ目はユーザー履歴に対するソフトプロンプトです。ユーザーの全リスニング履歴をそのままプロンプトに含めると、コンテキストの上限を超えてしまいます。これが今後も問題として残り続けるかどうかは議論の余地がありますが、私たちはこれを回避するために、長期的な参照情報を圧縮した密なベクトルとして扱い、それをモデルの入力に前置するという、いわゆるソフトプロンプトの形で活用しています。2つ目はコントロールトークンと呼んでいるものです。サービング時に、「馴染みのある」または「馴染みのない」という単一のトークンがプロンプトに付加され、これによってモデルが特定の種類のレコメンデーションへとステアリングされる仕組みになっています。つまり、1つのモデルで2つのモードを実現しており、再学習は一切不要です。プラットフォームは会話の異なる瞬間ごとに、何も再構築することなくサービングできるようになっています。
このシステムは、Spotifyのホームサーフェスにおいて本番環境の規模で展開されました。ポッドキャストレコメンデーションに向けた典型的なパイプラインとしては、まずポッドキャストカタログに対してセマンティックIDを用いたオフライン学習を行います。次にサービング時に候補生成が行われ、モデルが出力するトークン列がエピソードIDへとデコードされ直され、そこにコントロールトークン、つまり馴染みがあるかないかというリクエストが付加されます。A/Bテストの結果、私たちは「非習慣的なストリーム」、つまり新規のコンテンツや、これまでユーザーにあまり見えていなかった番組のストリーミングを増加させることができました。これはレイテンシとコストの制約を守った上での結果です。また、この点について強調しておきたいのは、LLMは決して高速なものではなく、Spotifyのトラフィック規模でトークン列のデコーディングを実行するには、相当なエンジニアリングの工夫が必要になるということです。論文にはこのあたりの詳細が多く記載されていますが、この展開から得られた教訓は、モデル設計そのものと同じくらい重要なものだったと考えています。
ここでのキーとなる原則は、コントロールトークンによって1つのモデルが会話の異なる瞬間にサービングできるという点です。必要に応じて馴染みのあるコンテンツを、また必要に応じて新しい発見のコンテンツを提供でき、私たちはこれを実践の中で「ステアラビリティ(steerability)」と呼んでいます。ここから得られた教訓を、もう少し高い視点でまとめたいと思います。生成的レコメンデーションシステムの収束という観点では、検索、レコメンデーション、ユーザー表現などが1つに統合されていく方向に進むのであれば、共有された表現、すなわち統一されたモデルが必要になります。これは、すべての能力がコンテンツの表現を共有している場合にのみ可能になるものであり、私たちはこのためにセマンティックIDを用いていますが、これが最善の方法であるかどうかについてはまだ検証すべき点が残っており、現在も進行中の取り組みです。再学習を伴わない安定性は実現可能であることが分かっています。このコントロールトークンという考え方は、異なるサーフェス、異なる瞬間に適応させることができますが、これは現時点ではプラットフォームレベルでの話です。この後お話ししますが、これを実際の商品として、大きな意味を持つ形にするにはまだ作業が必要です。学習コストは高いままですが、1つのモデルで異なるニーズに対応し、それを推論時に実現できるという点は大きな利点です。まだ取り組みが必要な領域として、ゼロショットの汎化があります。私たちはいくつかのタスクでモデルを学習させ、関連するタスクを追加することはかなりうまくできていますが、まったく異なるものを追加しようとすると、そこにはまだ到達していません。このゼロショット汎化という考え方は、大きなテーマになっています。次のステップはステアラビリティです。これはこれまで主にプラットフォームレベルで語られてきましたが、まだやるべきことは多いものの、少なくとも私たちが取り組んでいるユースケースにおいては、その制御をユーザー側に移していくこと、つまりユーザーがその場で自分の経験を自ら形作れるようにすることが、この会話型ビジョンの今後の方向性だと考えています。これは単純な話ではなく、インタラクションはかなり高速に動作する必要があります。スケーラビリティの問題もありますし、体験の品質、安全性、コストといった領域にも踏み込んでいく必要があります。しかし、能力自体はある程度整ってきており、優れた体験を大規模に実現するためにはまだ取り組むべきことがある、という状況です。
4.2 エージェントへの移行とParallel Fusion Router
Mounia Lalmas: それでは次のテーマである、エージェント技術に移りたいと思います。これは私たちだけでなく、多くの企業が検索からエージェントへと移行している流れです。ここで一つ例をご紹介します。右側の2枚のスクリーンをご覧ください。左側では、ユーザーが「最近の元気なインディーソウルを流して」と入力し、システムがレコメンデーションを返しています。同じユーザーが続けて「いいね、このアーティストについてもっと教えて」とフォローアップすると、システムは新しい検索やランキングリストではなく、そのアーティストについての自然な応答で答えます。これはたまたま私が誰なのか分からないアーティストのスクリーンショットですが、同僚によるとかなり良いアーティストだそうです。ただ重要なのは、これが1つの連続した会話の一部だということです。このセクションで焦点を当てたいのは、単にクエリを正しいAPIにルーティングするということ以上の、1つの会話をどう実現するかという点です。つまり検索するのか、レコメンドするのか、対話を続けるのか、そのすべてに対応できる能力を持つということです。
ご紹介する内容は、こちらに挙げた2つの論文に基づいています。1つ目は、システムがユーザーの意図をどのように判断するかを扱ったものです。これは、ユーザーが過去に何をしてきたかを見て推測するという従来の考え方から、ユーザーが実際に何かを伝えようとしているのだと理解する方向への転換に関わるものです。2つ目は、システムがどのように対話を維持する方法を学習するか、つまり新しいプロダクトを立ち上げる際、十分なデータがない状況でどのように会話を構築していくかを扱っています。
まず最初の問いは、会話が答えなければならない「このユーザーは実際に何を望んでいるのか、検索結果なのか、レコメンデーションなのか、それとも別の何かなのか」というものです。Spotifyにおいても、他のプラットフォームと同様に、クエリの種類は非常に多様です。例えば私たちが観察したところでは、Spotify上のクエリのかなりの割合が探索的なものであり、「新しいインディーのリリース」「こういう感じのポッドキャスト」「通勤中に聴くもの」といった形で、特定のエンティティを指定する狭いクエリではなく、レコメンデーションのリクエストが検索クエリの形で表現されているようなものです。従来の検索システムは、依然として主に語彙的・意味的なマッチングに最適化されており、私たちはこの点で苦労していました。私たちが行ったのは、いわゆる「パラレル・フュージョン・ルーター(Parallel Fusion Router)」の構築です。ユーザーがクエリを送信すると、LLMルーターがその意図を解釈します。ここでの大きな変化は、この意図の推測がクエリそのものから行われるという点です。単語が何を意味しているかだけでなく、ユーザーが実際に何を達成しようとしているのかを推論する、これが推論の部分です。それに基づいて、ルーターはどのツールを呼び出すかを決定します。検索APIかもしれませんし、レコメンデーションAPIかもしれません。私たちはエージェント的なエコシステムへと移行しており、特化型のサブエージェントや、それらの組み合わせを利用することも可能です。複数のツールが必要な場合には、それらは並列に実行されます。ルーティングの決定はクエリのみに基づいて行われ、ユーザーの特徴には基づきません。つまりルーターのレベルではパーソナライゼーションを行いません。これによってレイテンシを低く抑え、キャッシュを大規模かつ効率的に機能させることができます。パーソナライゼーションはその後、個々のAPIのレベルで行われ、ルーターでは行われません。そして、呼び出しが並列に実行されるため、全体のレイテンシは各処理の合計ではなく、最も遅い処理にかかる時間に等しくなります。この違いは本番環境のスケールにおいて非常に重要な意味を持ちます。
ルーターを本番環境に投入するには、ある中心的な課題を解決する必要がありました。モデルは複雑なクエリを理解できるだけの能力を持たなければならない一方で、規模を持って動作できるだけ小さくなければなりません。私たちが採用した解決策は、大規模なティーチャーLLMを用いた知識蒸留であり、そこから小さなスチューデントモデルを構築するというものです。さらに「リジェクションサンプリング」と呼ぶ手法も併用しています。つまり、大規模なティーチャーLLMがラベル付けされたルーティング判断を生成し、その中から高品質なものだけを残します。この品質の検証にはLLMジャッジを用いており、これについては後ほどお話しします。そして、この高品質なデータのみを用いて小さなスチューデントモデルを学習させます。この「高品質のみを残す」というフィルタリングは非常に重要であることが分かっており、これによってティーチャーが判断に確信を持てなかったケースを除外することができました。この結果として得られたスチューデントLLMは、ティーチャーと比較してレイテンシとコストが低く、かつ品質は3%向上しました。オフラインでの改善は全般的に大きく、類似アーティストのクエリ、新しい音楽、幅広いジャンルのポッドキャスト検索など、これまで探索的な意図に対してあまりうまく機能していなかったサーフェスにおいて特に効果が見られました。
この意図理解こそが、パーソナライゼーションの観点で大きく変化している点であり、これによってルーターは、ユーザーが検索したいのか、発見したいのか、あるいはその中間なのかという、会話の中の正しい瞬間に対応できるようになります。この理解こそが、ルーターがリアルタイムで解明しようとしていることであり、これもまた本番環境において大規模に展開されています。ルーターは検索するかレコメンドするかを決定しますが、先ほどお見せした例に戻ると、ユーザーは単に結果を得ただけでなく、会話を行い、フォローアップし、アーティストについて質問していました。そこにはやり取りの往復があり、それこそが会話としての体験を本物にしていたのです。そして、それには実際に対話を維持できるエージェント、つまり会話型エージェントが必要になります。
5. マルチターン対話エージェントの構築
5.1 コールドスタート問題と合成データ生成
Mounia Lalmas: そうした会話型エージェントを構築するには、対話を学習するためのデータ、つまりマルチターンの会話データが必要になります。私たちのケースにおいても、そして今後開発されるであろう多くのこうしたエージェント型システムにおいても同様だと思いますが、こうしたデータはエージェントが既に展開されていない限り存在しないという、典型的なコールドスタート問題に直面します。そこで私たちが取り組んだのは、AIを用いた合成データの生成でした。私たちはこれ以前からこうした手法を使い始めていましたが、これが実際にかなりうまく機能することが分かってきました。おおまかに言えば、会話がどのようなものであるかをシミュレートすることができるのです。
その出発点となるのが、単一ターンの会話を見ることです。ユーザーがこれを尋ね、こういう結果が返ってきた、というものをシードとして扱います。これが「ダイアログプラン」という考え方です。エージェント的推論に長年取り組んできた方々にとっては、ダイアログプランという用語自体は決して新しいものではありませんが、LLMを用いることで、実際にはるかに多くのことができるようになっています。会話が始まる前に、まずダイアログプランが書かれます。これはLLMが、ユーザーが何を尋ねるか、私たちが特定した5つの会話能力のうちどれが関わるか、どのようなやり取りが必要になるか、そして会話がターンを重ねる中でどのように展開すべきかについての計画を書くというものです。私たちはシミュレートされたユーザーとリード役のエージェントを用意し、それをターンごとに追わせることで、実際の完全な会話を生成します。つまりダイアログプランは、会話がどのように進むべきかについてのテンプレートのようなものであり、シードはそこに「これはこういうトピックについての会話であり、こういう種類の会話が期待される」という情報を与えるものです。
これによって、単一ターンのデータセットをシードとして、ゼロからスケールさせていくことが可能になります。それぞれのプランは、私たちが特定した5つの会話能力を軸に設計されています。1つ目はコンテンツの精緻化で、例えば「もう少しアップビートなものにして」といったものです。2つ目は指示の保持で、例えば「20分以内のポッドキャストだけにして」というものです。3つ目は参照解決で、例えば「2番目のやつについてもっと教えて」というものです。4つ目は意図のシフトで、例えば「実は今はリラックスできるものが欲しい」というように、まったく別の方向に切り替わるケースです。そして、これらが複合的に組み合わさった入力もあります。つまりユーザーが望んでいることが、完全に別々の複数の要素を同時に含んでいるようなケースです。この5つが、実際の会話の中で起こりうることの全範囲をカバーしており、これらを合わせることで会話型エージェントにとっての「能力」とは何かが定義されます。これはまた、例えば音楽やポッドキャストについて学ぶための選択肢としての側面も持っています。つまりアプリが何についてのものであるかというタクソノミーにしっかりと根ざしたものになっているということです。この能力ごとの分類は、学習のためだけでなく評価のためにも同じくらい重要であることが分かりました。エージェントが失敗したとき、「会話がどう間違ったか」という漠然とした問いよりも、「どの能力が失敗したのか」という、はるかに有用な問いに答えることができるようになります。例えば、ユーザーが20分以内のものだけを求めていたことを理解できなかった、といった具体的な失敗の特定ができるのです。
5.2 セルフインプルーブメントループと本番展開
Mounia Lalmas: これは大きな発見でした。こうした会話は、シードとなる元データから、先ほど述べたダイアログプランに従って構築されています。これは実際に、合成でありながらリアルなデータになっています。エージェントを動かしてみると、当然エージェントはいくつかの誤りを起こすことがあります。ここで問題となるのは、コンテンツを生成しているエージェントにとって、どの誤りが実際に重要な意味を持つのかということです。というのも、エージェントが会話を生成するプロセスは確率的なものであるため、同じ能力であっても、あるプランでは失敗し、別のプランでは成功するということが起こり得ます。応答の中には多くのニュアンスがあり、エージェントがどのように応答するかにもばらつきがあることは、皆さんもよくご存知の通りです。そこで私たちは、本当に構造的なギャップ、つまり「これは明らかに間違っている」というケースと、単に確率的な出力における自然なばらつきに過ぎないケースとを区別するためのセルフインプルーブメントループを構築しました。これは自動化されたプロンプト最適化の領域に踏み込むものです。
このループが実際に行うことは、まずシードから複数のプランを生成し、それぞれを5つの能力の各次元についてLLMジャッジを用いて採点することです。ここでも、より良いプロダクト、より良いレコメンデーションを構築するためにAIを使っているという点についても、後ほどお話ししたいと思います。次に、分散分析を行い、ある能力がプラン全体を通してどの程度一貫して失敗するかを見ます。ほとんどのプランで失敗するのであれば、それは本当に構造的なギャップです。「これはうまくいっていない」ということが明確になります。一方で、たまにしか失敗せず、ほとんどの場合は成功しているのであれば、それは単に確率的なシステムの性質にすぎません。そのため、私たちはそこには手を加えません。この区別ができるようになったことで、セルフインプルーブメントループはすべてを解決しようとするのではなく、はるかに効果的に機能するようになりました。
本当に構造的なギャップであると判断された場合には、私たちが「コーディングエージェント」と呼ぶものを使用します。これは、その能力に責任を持つプロンプトを自動的に書き直すエージェントです。手作業でのプロンプトエンジニアリングは不要で、システム自身が自らの失敗モードを見つけ、それを修正します。これは大きなブレークスルーであり、強力な手動ベースラインと比較して、大幅に優れた結果を、A/Bテストの結果としても得ることができました。このシステムは本年4月に本番環境でローンチされています。自己改善型エージェントというものは、今後会話がますます高度になっていく中で、非常に重要な意味を持ちます。
ここから得られた教訓と、今後の方向性についてお話ししたいと思います。まず、意図こそが統一的な抽象化であるという点です。正しい問いは「ユーザーが何を望んでいるか」であり、それを理解しようとするとき、検索とレコメンデーションの境界はある程度溶けていきます。ルーターは、あるクエリが検索らしく見えるか、レコメンデーションらしく見えるかを気にしません。気にするのはあくまで意図であり、そこから適切なサーフェスが導かれます。この推論の部分に、私たちは多くの時間をかけて取り組んできました。これをスケールさせるためであり、また安全性の問題にも関わるからです。単純な会話能力だけでは不十分で、対話能力そのものをブートストラップさせる必要があるという点も重要です。これは新しい種類の会話、新しいエージェントを開発していく場面に関わってきます。私たちはコアとなる問題に対しては合成データを活用していますが、しばらくすれば実際の会話データが得られるようになり、それをエージェントの学習に戻していく必要があります。会話自体も時間とともに進化していくためです。これは次の教訓、つまり能力は今後さらに成長していくという点にもつながります。評価もそれに合わせて成長していく必要があります。現在何とか実現できていることも、能力がさらに向上したり変化したりするにつれて、それに応じて進化していくはずです。したがって、「これが評価の方法だ」と決めてそれで終わりにするべきではありません。次のステップは、能力から信頼性へと進むことです。エージェントは会話を維持することができますが、必ずしも最高の応答ばかりではなく、時には方向がずれてしまうこともあります。望まないような会話になってしまうこともあるでしょう。すべてのユーザーの意図、特に未知の意図に対しても、大規模かつ高品質に信頼性を持たせることこそが、まさに残された未解決の課題です。能力自体はある程度整ってきていますが、信頼性の面ではまだ多くの作業が残っています。
6. 評価手法(LLM as Judge)と今後の展望
6.1 LLM Judgeの仕組みと改善策
Mounia Lalmas: それでは評価の話に移りたいと思います。システムを構築することは、問題の半分に過ぎません。もう半分は、それがうまく機能しているかどうかを知ることです。実際にAIに関しては2つのことが起きています。私たちは新しいAIシステムを評価する必要がある一方で、AI自体をそれらの評価に使い、さらにはこれまで「非AI」システムと呼んでいたものの評価にも使うようになっています。ここで取り上げたいのがLLMジャッジ、すなわちLLM as Judgeと呼ばれるものです。
このLLMジャッジには非常に大きな関心が集まっています。私からは、その仕組みと、Spotifyでどのように活用しているかについて少しお話ししたいと思います。まずLLMジャッジとは何かということですが、これはLLMを用いて、AIによって生成されたものであれ、それ以外のものであれ、出力を評価する仕組みです。例えば画面のスクリーンショットを渡して、それが良いか悪いかを判断させることもできます。ここで一つ例をお示しします。右側の2つの画面は、LLMジャッジができることを示しています。ユーザーが「Lady Gagaの最新アルバム」を検索している状況です。左側では、トップの結果がヒット曲を集めたプレイリストになっています。ジャッジはその世界知識に基づいて、これを不適切として赤くフラグを立てます。右側では、実際に正しい結果、つまり彼女の最新アルバムがトップに表示されており、これは緑色で適切と判定されます。これは単純な例ですが、LLMジャッジはこれよりもはるかに多くのことができます。ジャッジはクエリが何を意味していたのかを理解し、結果がそれを満たしているかどうかを判断し、その理由を説明することができます。これは以前は不可能ではなかったものの実現が難しく、特に大規模に行うことは確実に不可能でした。
LLMジャッジは今、ますます活用されるようになっており、私たちもこれをスケーラブルな評価レイヤーとして使っています。検索の文脈で言えば、クエリを受け取り、さらにコンテンツの仮説を受け取ることもでき、システムの出力とユーザーコンテキストを受け取り、ルーブリックを適用します。「ここだけを見たい」「この結果は良い」「この結果はそれほど良くない」といった判断を行うわけですが、ここでルーブリックの定義そのものが非常に重要になります。そして最終的に、根拠を伴った判断を生成します。これはスケーラブルであり、例えば数千件のクエリや結果ページを、人手によるアノテーションのごく一部のコストで評価することができます。また、グラウンディングされているべきものであり、常にそうであるとは限りませんが、LLMはこうした知識を理解する力を持っているため、根拠を与えることができます。この点については次にお話しします。さらに監査可能性もあります。判断の推論過程が可視化されているという点は、評価を行う際に非常に重要です。
ここでの重要な教訓は、LLMジャッジは与えられたコンテキストの質に応じてしか機能しないということです。グラウンディングがなければ、基本的なケースについてはある程度うまく機能するかもしれませんが、一般的な知識だけからの推論には限界があり、私たちのケースでは、パーソナライズされたケースや、複数の満たし方があるような曖昧なクエリにおいて、うまく機能しませんでした。おそらく他にも多くの同様のユースケースがあるはずです。
そこで私たちが行ったのは、テキスト化されたユーザープロファイルの活用です。具体的には、LLMを使ってユーザーのリスニングログから要約を抽出し、そのユーザーの一般的な興味についての自然言語のサマリーを作成し、それをルーブリックの一部として与えるという方法です。もう一つは行動シグナルの活用です。満たすことが難しい、非常に曖昧なクエリがある場合、そのデータを使って、そのクエリがどのように満たされてきたかについてのカードを構築し、それを再びLLMに与えます。この行動シグナルを用いることで、最も難しいケースにおいて大きな改善が見られました。簡単なケースについては、LLMジャッジは元々良い仕事をしており、そこまで手助けは必要ありません。私たちはまた、Cranfieldスタイルのテストコレクション、すなわちドキュメント・クエリ・アセスメントの組み合わせによる評価手法を、LLMを使って再現する試みも行い、そこで十分に良い結果を得ることができました。この手法の利点は、レコメンデーションの目的のためのテストコレクションを構築できるという点です。情報検索の分野には、テストコレクション構築についてはるかに長い歴史があります。
LLMジャッジはスケールします。私たちのケースのようにパーソナライゼーションが関わる場合、これは非常に大きな助けになります。人手によるアノテーションではとても追いつくことができず、パーソナライゼーションが加わるとさらに難しくなります。私たちが見ているのは、問いが「もっとアノテーションできるか」ということから、「本当に何を評価すべきか、どうすれば良いルーブリックを設計できるか」へとシフトしているということです。例えば、「これは新しいか」「これは関連性があるか」といった観点です。つまり単に関連性だけではなく、良いレコメンデーションとは何かという、さまざまな次元を捉えることができるわけです。ここで一つ注意点があります。評価対象のモデルが特定のLLMを使っており、そのジャッジにも同じLLMを使ってしまうと、そこには一種の循環性が生じます。両者は互いに同意しやすくなってしまうのです。ジャッジには必ず、評価対象のシステムよりも優れた、非常に強力なLLMを使うべきです。ジャッジは評価対象よりも優れている必要があり、そうでなければ両者は互いを強化し合うだけになってしまいます。LLM自身が誤りを犯している場合、同じLLMに基づくジャッジもまた同じ誤りを犯すことになるからです。
オンラインの結果を予測するという話もしましたが、これは意思決定を助けてくれると考えています。まだお話ししていないのは、これが結果を見るために使われるだけでなく、私たちが今まさに向かっている先、つまりコンテンツや出力そのものを生成する方向への活用です。それはもはや固定的なものではなく、単にランキングの品質だけの話ではありません。生成されたテキストの評価、マルチターンにおける一貫性の評価などについては、まだ取り組むべき作業が残っています。
6.2 今後のオープンな課題とまとめ
Mounia Lalmas: ここまでの内容を締めくくりたいと思います。私たちが構築してきたのは、ステアラブルで展開可能なジャーニー・レコメンデーションシステム、意図を認識した統一的なエージェント型検索、そしてマルチターンの会話型エージェントのための基盤です。私たちが進めているのは、検索とレコメンデーションが1つの会話へと収束していく方向であり、実際にそれを支えるシステムの一部を構築しています。共有された表現がますます重要になっていきますし、評価はそれ以上に重要になっていくと考えています。
最後に、オープンな課題についてお話しして終わりにしたいと思います。ここで挙げる課題は、今まさに私が見ているものであり、フロンティアモデルは進化し続けているため、1年後にはこれらのうちいくつかは解決されているかもしれませんし、新たな課題が生まれているかもしれません。1つ目は、ユーザーレベルでのステアラビリティをより高めることです。私たちは馴染みのあるものと馴染みのないものを制御できるようになっていますが、これをもっとライブなものにしたいと考えています。ユーザー自身が「馴染みのあるものが多すぎるから、何か別のものをくれ」と決められるようにしたいのです。こうした兆候は既に出てきており、ユーザーはこれを会話の一部として扱い、精緻化していくことができますが、これをユーザーの意図の全範囲にわたって、本番環境のスケールで確実に機能させるには、まだかなりの作業が残っています。2つ目は汎化です。私たちは良い仕事をするモデルを構築できていますが、完全に新しいコンテンツ、新しい意図、新しいタスクにモデルを拡張しようとすると、ここは改善されつつあるものの、まだ到達していません。3つ目は生成的なエージェントシステムの評価です。LLMジャッジは道を開いてくれましたし、ツールキットも存在していますが、これらのツールの使い方にも、こうした生成システムをどう評価するかという点にも、まだ多くの課題が残っています。以上で私の講演を終わります。ありがとうございました。
7. Q&Aセッション
7.1 プライバシーと外部LLM利用に関する質疑応答
Moderator: 素晴らしいご講演をありがとうございました。皆様、拍手をお願いします。プラットフォーム上には拍手のための小さなアイコンがありますので、そちらもご活用ください。本当に刺激的で、いつも通り大変興味深いお話をいただき、ありがとうございます。皆様がまだこのプラットフォームの使い方に慣れていないかもしれませんので、質問がある方はご遠慮なく、声を出す必要はありません。右側にある小さなアイコンから「Q&A」をクリックして、テキストで質問を入力していただければと思います。皆様がプラットフォームの使い方を確認されている間、私自身も個人的に非常に関心のあるトピックについて質問させていただきたいと思います。それはまさに評価についてです。
Moderator: 先ほどのお話の中で、LLMジャッジには、実際にエージェントを動かしている本体のLLMとは異なる、同一ではないLLMを使うことがいかに重要かというお話がありました。これは実践者にもぜひ理解してもらいたいと私自身も強く感じている点です。ただ、その上でお伺いしたいのですが、もちろんSpotifyには企業秘密があるかと思いますので、お答えいただけない場合はその旨を教えていただければと思います。Spotifyはユーザープロファイルなどについて非常に多くの機密情報を保有していると思いますが、非常に強力なLLMをジャッジとして使いたい場合、そうしたモデルは通常、AnthropicやGoogleなど、大手の商用LLMになるかと思います。それらは自社でトレーニングしたり、オンプレミスで保持したりできるものではありません。そうした機密性の高い情報を、オープンな非常に強力な外部LLMにどのように渡しているのでしょうか。あるいはそもそも、そうした外部LLMを利用しているのかどうか、という点についてもお伺いできればと思います。ご質問の意図は伝わっているでしょうか。
Mounia Lalmas: はい、これは良いご質問ですね。これは私たちにとって本当に核心的な課題です。私たちはこうした大規模なLLMを多く利用していますが、切り替えができるようにしておくことも重要だと考えています。というのも、LLMの領域で何が起きているかを見ていると、あるモデルを何かの用途で使っていたところに、何らかの新事実が明らかになって、切り替えを迫られるといったことも起こり得るからです。ですので、誰であっても、切り替え可能な状態を確保しておくことをお勧めします。これが一つの推奨事項です。私たちはこうした企業と契約を結んで協業していますが、生成的なレコメンデーションシステムの最初の部分については、社内で完全に閉じた形で行っているわけではなく、大規模なLLMを利用しつつ、オープンウェイトのモデルを取り込み、それを自社でトレーニングするという形をとっています。
Mounia Lalmas: また、もう一つ興味深い点として、こうした大規模なLLMをジャッジとして使う場合、必ずしもすべての情報をそのまま渡す必要はないということが挙げられます。蒸留(distillation)を自社側で行うという方法もあります。重要なのはパターンであり、例えば「このユーザーはこの種のポストカードが好きかどうか」といったことです。こうした処理は別途行うことができ、それを世界知識に組み合わせて活用することができます。したがって、さまざまな方法があるということです。もう一点私たちが実際に確認したのは、より高性能なLLMを使う方が、コスト削減のために安価なLLMに切り替えるよりも、はるかに良い結果が得られるという点です。実際にコスト削減のために安価なLLMへの切り替えを試みたことがあるのですが、結果としてその価値はありませんでした。実際の成果があまり良くなかったためです。
Moderator: それは素晴らしいご回答です。とても明快でした。今のお話を、今朝のKatrina Ligett氏による素晴らしい基調講演の内容と結びつけて、一点だけ補足させていただければと思います。差分プライバシーを適用したり、匿名化を行ったりしたとしても、そこには常に「プライバシーバジェット」というものが存在し、どこかで必ずリスクが残るというお話がありました。そう考えると、すべてを自社内(in-house)で保持することは、はるかにコストが高くなる一方で、唯一の安全な解決策なのかもしれません。とはいえ、あまり神経質になりすぎないようにしましょう。
Moderator: それでは、これ以上ご質問がなければ、ちょうど時間になりましたので、ここで締めさせていただきたいと思います。改めて、素晴らしいご講演をありがとうございました。皆様、このセッションは録画されていますので、後ほどご覧いただくことも可能です。ありがとうございました。それでは、また次のセッションでお会いしましょう。