こんにちは、CCCMKホールディングスTECH LAB三浦です。
私の住んでいる街でも雪が降り、朝には少し雪が積もっていました。雪が降るのを見ながら、「寒くなるな・・・」とか、「道が歩きにくくなるな・・・」とか、「電車動くのかな・・・」とか、マイナスなことばかり考えている自分に気づきました。子どもの頃は雪が降ると、いつもと違う雰囲気にワクワクしていました。そういえばいつから雪を見てワクワクしなくなったんだろう、とふと考えたりしまいた。
さて、今回は最近興味があって調べていたレコメンデーションタスクへのLarge Language Models(LLMs)の活用方法についてまとめてみたいと思います。調べるまで、LLMsをどうやってレコメンデーションに使うんだろう？？と、イメージがなかなか浮かばなかったのですが、調べてみると学ぶことが多く、色々なシーンで活用出来そうなテクニックも知ることが出来ました。
各レコメンデーションタスクへのLLMsの活用
レコメンデーションタスクにはユーザーにアイテムをレコメンドしたり、ユーザーのあるアイテムへの評価値を予測するタスクなどが含まれます。それぞれのタスクにおいて、LLMsをどのように利用するのかについて、最初にまとめてみたいと思います。
ここでは次の論文を参考にしています。
Title: Large Language Models for Generative Recommendation: A Survey and Visionary Discussions
Authors: Lei Li, Yongfeng Zhang, Dugang Liu, Li Chen
Submitted: 3 Sep 2023
arXivURL: https://arxiv.org/abs/2309.01157
この論文の"4 How to Do Generative Recommendation"のセクションで紹介されている内容をいくつかまとめます。LLMsは自然言語を扱うモデルですので、基本的に全てのタスクを自然言語の問題(特にテキスト生成)に落とし込むことになります。
Rating Prediction
これは特定のユーザーの特定のアイテムに対する評価値を推計するタスクです。具体的にはユーザー情報とアイテム情報を入力すると、たとえば1~5の間のスコアを出力させます。これをLLMsが扱える問題に置き換えると、入力として
user_1234のIDのユーザーはitem_5678のIDのアイテムをどのように評価しますか？ 1～5までの評価スコアを出力してください。
のようなプロンプトを書いてLLMsに与えることになります。以降のタスクにおいても同様ですが、ここで使用されるLLMsはレコメンデーションタスクへの利用を想定して事前学習またはFine-TuningされたLLMsです。レコメンデーションタスク用途にLLMsを事前学習する方法として、たとえば"P5"という方法があります。"P5"についてはこの記事で後程まとめています。
Top-N Recommendation
特定のユーザーに対してN個のおススメのアイテムを提示するタスクです。従来のレコメンドシステムにおいては対象のアイテム群に含まれるアイテムに対し、該当のユーザーとのスコアを計算し、すでにそのユーザーが接触済みのアイテムを除いたスコアの上位アイテムを抽出して提示する流れになります。LLMsを用いる場合、直接LLMsにおススメのアイテムのIDリストを生成させることになります。
Sequential Recommendation
ユーザーと、そのユーザーがこれまでに接触してきたアイテムの履歴から、次にそのユーザーが接触するアイテムを探すタスクです。これはLLMsのテキスト生成の能力と親和性が高そうな印象があります。LLMsへの入力は、たとえば以下の様なプロンプトが考えられます。
user_1234はこれまでitem_3456, item_4567,..., item_5678を利用しています。 この履歴を踏まえて次にこのユーザーが利用するアイテムを予測してください。
Top-N Recommendationと同様、このタスクでもアイテムIDをLLMsに生成させます。その際アイテムの特徴を反映したIDが設定されていた方が、LLMsにとって学習しやすく、またIDの生成もしやすくなります。
どのようにアイテムにIDを与えるべきかについては「Large Language Models for Generative Recommendation: A Survey and Visionary Discussions」のセクション"3 ID Creation Methods"でも触れられていますし、別の論文でも述べられています。IDを与える方法については、この記事で後程まとめたいと思います。
Explainable Recommendation
これはアイテムをおススメするタスクではなく、あるユーザーに、あるアイテムをおススメする理由を説明させるタスクです。たとえば
user_1234にitem_5678をおススメする理由を説明してください。
といった入力をLLMsに与えておススメ理由を説明させます。
Review Generation/Review Summarization
ユーザーとアイテムを入力するとそのユーザーがそのアイテムに対して持つであろう感想をレビューとして生成するのがReview Generationで、ユーザーとアイテムとユーザーのレビューを与えてレビューを要約させるのがReview Summarizationです。
Conversational Recommendation
ユーザーと複数回の会話のやり取りを通じ、おススメのアイテムを提示するタスクです。
LLMsによるレコメンドのメリット
LLMsによるレコメンド: "Generative Recommendation"以外にも従来より使われてきたレコメンド手法はたくさんあります。その中でGenerative Recommendationを使うメリットは何か。
この点について、「Large Language Models for Generative Recommendation: A Survey and Visionary Discussions」の"2 Why Generative Recommendation"で述べられている内容をまとめてみます。
従来のレコメンドにおいてはユーザーに多数のアイテムからおススメのアイテムをチョイスするために、全アイテムに対して推薦するためのスコアを計算する必要がありました。計算に複雑なロジックを採用すると計算コストが膨大になるため、最初に簡単なロジックを適用して候補となるアイテムを絞り、限られたアイテムに対して推薦スコアを計算する、という段階に分けてレコメンドを行います。どんなに優れた推薦スコアを計算するロジックがアカデミアの領域で開発されても、産業の領域では全体に適用できない、というギャップが生まれてしまいます。
一方Generative Recommendationにおいては全てのタスクにおいてLLMsがベースとなります。このLLMsを共有することで、アカデミアと産業間でのギャップを減らすことにつながると考えられます。
また、レコメンド対象のアイテムを幅広くカバーできる点もGenerative Recommendationにおける強みになります。たとえばアイテムのIDが10個のトークンで構成されている場合、もしLLMsが扱える語彙数(トークン数)が1,000個だったとすると10の30乗種のアイテムのレコメンドが可能になります。
レコメンデーションタスクに対応したLLMs
Generative Recommendationは様々なレコメンドのタスクを共通のLLMsで対応可能で、レコメンド対象になるアイテムの数もほぼ無制限というメリットがあります。しかし、LLMsが特定のサービスやドメインでアイテムのレコメンドが出来るようになるためには、そのサービスやドメインでのこれまでの履歴を元にした学習データによる事前学習が必要になります。具体的にどのような手順になるのか、おそらく様々な手法が存在すると思いますが、「Recommendation as Language Processing (RLP): A Unified Pretrain, Personalized Prompt & Predict Paradigm (P5)」という論文に述べられている"P5"という手法がとても面白いと感じました。ここからはP5の論文を元に、LLMsをレコメンデーションタスク用に事前学習する方法についてまとめてみます。
参考にした論文はこちらです。
Title: Recommendation as Language Processing (RLP): A Unified Pretrain, Personalized Prompt & Predict Paradigm (P5)
Authors: Shijie Geng, Shuchang Liu, Zuohui Fu, Yingqiang Ge, Yongfeng Zhang
Submitted: 24 Mar 2022 (v1), last revised 2 Jan 2023
arXivURL: https://arxiv.org/abs/2203.13366
P5について
P5については論文のこちらの図が分かりやすくその特徴を表しています。
この図、どこかで見たことがあるな・・・と思ったのですが、T5の論文にも同じような図が掲載されていました。P5はモデルの構造はT5と同じもの(TransformerのEncoder-Decoder構造)を使用しており、様々なタスクをテキスト生成タスクに変換している点に共通点があります。
先の図の通り、P5はSequential Recommendation, Rating, Explanation, Review, Direct Recommendationの5つのレコメンデーションタスクをテキスト生成タスクに変換しています。それぞれのタスクに対する入力データと出力データを生成するために、複数のプロンプトのテンプレートが用意されています。各ユーザーのアイテム接触履歴を集計したデータから、これらのプロンプトテンプレートを通じて各タスク用の入力と出力のペアを生成し、それらを用いて事前学習を行います。論文に掲載されている次の図を見るとイメージしやすいと思います。
異なるタスクでありながら、テキスト生成のタスクに変換することで共通の損失関数を適用できる点が特徴として挙げられます。
P5の特徴
5つのレコメンデーションタスクに対応した入力と出力テキストで事前学習されたP5は、それぞれのタスクに特化した代表的な従来手法と遜色のない精度を出すことが出来ているそうです。
また事前学習時と異なるドメインのレコメンデーションの性能も検証されています。たとえばToys(玩具)のアイテムの接触履歴を用いて事前学習したモデルをBeauty(美容)アイテムのレコメンデーションタスクに利用した場合などです。この場合もRatingや一部のExplanationタスクで未知のアイテムにも関わらず高い精度を保つことが出来ているとのことです。
検証の中ではアイテムのIDの持ち方についても触れられています。P5ではトークナイザはSentencePieceが使用されていて、この場合たとえばアイテムIDとして"item_7391"といった文字列を使用すると、トークナイザにより4つのトークン"item","_","73","91"に分割されます。 一方アイテムごとに特殊トークン(たとえば"<item_7391>")を用意する方法も考えられます。この場合は"<item_7391>"が1つのトークンとして扱われます。そして前者と後者の方法で精度の比較を行うと、後者の方法ではSequential RecommendationとDirect Recommendationにおいて精度が劣化してしまったそうです。要因として後者の方法ではアイテムごとにトークンが追加されるため、語彙数が大きく増えてしまい、埋め込み表現の学習が上手くいかなかったことが考察されています。
この検証からもうかがえるように、アイテムのIDをどのように設定するかはLLMsを用いたレコメンデーションタスクにおいて結構重要な要素であると考えられます。この点について検証を行っている論文があり、最後にその論文の内容を参考に、アイテムIDの設定方法についてまとめてみたいと思います。
どのようにアイテムIDを設定するか
参考にした論文は次の論文です。
Title: How to Index Item IDs for Recommendation Foundation Models
Authors: Wenyue Hua, Shuyuan Xu, Yingqiang Ge, Yongfeng Zhang
Submitted: 11 May 2023 (v1), last revised 26 Sep 2023
arXivURL: https://arxiv.org/abs/2305.06569
アイテムを識別するIDを付与する方法として、単純な方法だとランダムにIDを与える(RID)、アイテムの名前(タイトル)をIDにする(TID)、アイテムごとに特殊トークンを用意して設定する(IID)などが考えられます。
RIDについてはたとえば"4332"と"4389"というIDが与えられた2つのアイテムでは、SentencePieceでIDをトークン化すると"43""32"と"43""89"に分割され、それぞれ"43"というトークンを共有することになります。2つのアイテムには関連性は無いにも関わらずトークンを共有している状態は、モデルの学習に悪影響を与える可能性が考えられます。
TIDでも同様の事象が考えられます。たとえば"The Lord of the Rings"と"The Lord of War"は"the""load""of"を共通のトークンに持ちますが、それぞれ異なるジャンルの映画で内容に関連性はありません。また、文字数が多すぎるIDを設定してしまうとLLMsがIDを生成するのが困難になり、存在しないIDを生成してしまう"ハルシネーション"が発生してしまう可能性も増えてしまいます。
IIDはアイテムIDに個別にトークンを設定します。そのため学習時に似た傾向のアイテムのIDのトークンは似た傾向の埋め込み表現を獲得出来ることが期待できますが、アイテム数分語彙数が増えてしまうため、学習コストが増加してしまうデメリットがあります。
これらを踏まえると、アイテムにIDを付与する方法として以下の条件を満たしていると望ましいことが考えられます。
- テキスト生成を容易にするため、適切な文字数にすること
- 似ているアイテム・似ていないアイテムといった事前知識がIDの構造に反映されていること つまり、似ているアイテムはIDも共通部分が多いようにし、似ていないアイテムはIDにも共通部分が少ないようにする
この条件を考慮したIDの生成方法について、まとめてみます。
Sequential Indexing
ユーザーごとに接触したアイテムをシーケンシャルに並べ、順に連番でIDを付与していく方法です。以下の論文に掲載されている図がイメージが付きやすいと思います。
User1は"1001"と"1002"に同時期に接触しており、またシーケンシャルにIDを付与したことから多くの部分を共有しています。Sequential Indexingはこのように共起性に着目したID付与の方法といえます。
Collaborative Indexing
ユーザーとアイテムの接触頻度による共起行列を元にSpectral Clusteringというクラスタリングを繰り返し、ツリー構造にアイテムを分類します。そして所属するクラスタの番号を連結したものと自身が所属する末端ノードにおける連番を連結したものをIDとして使用します。
共起行列を元に生成したクラスタであることから、同時に接触されやすいアイテム同士に共通部分の多いIDが付与されます。
Semantic(Content-based) Indexing
こちらもツリー構造にアイテムを分類してIDを付与するのですが元々アイテムに設定されていたカテゴリを活用する方法です。カテゴリ名に対して特殊なトークンを与え、それらのトークンを結合してIDにします。
また上記の方法と主にIIDを組み合わせたHybrid Indexingという方法も紹介されています。
まとめ
今回はLLMsをレコメンデーションタスクに活用するための様々な方法について、いくつかの論文を読んで調べたことをまとめてみました。今回調べたことを実際に適用しようとすると、IDをどのように設定するのかなど、事前にしっかりと設計しなければならないことがたくさんあることが分かりました。ただアプローチ自体は分かりやすく、またアイテム以外にもロケーションなど様々なレコメンデーションに応用が出来そうです。一度自分でもチャレンジしてみたいと感じました。
