推薦システムにおける大規模言語モデルの実用化

1. 背景と課題

従来の推奨モデルのネットワークパラメータの影響は比較的小さく（埋め込みパラメータを除く）、トレーニングと推論の時間と空間のオーバーヘッドも比較的小さく、ユーザーとアイテムの協調信号も十分に活用できます。しかし、データセット内の知識しか活用できず、オープンドメインの知識を適用することが難しいこと、意味情報や深い推論などを得る能力に欠けていることが欠点です。

これらの観点から、大規模言語モデルは、推奨モデルをある程度補完する能力を持っています。外部知識を導入でき、ドメイン間機能も備えていますが、推奨シナリオに必要な協調シグナルがありません。さらに、計算コスト（トレーニングまたは推論）が非常に高くなります。

このレポートでは、推奨モデルと大規模モデルがどのように相互に補完し合うことができるかについて説明します。具体的な角度は 2 つあります。

• 推奨プロセス全体の中で、大規模なモデルはどこで使用できますか?
• 大きなモデルをどのように使用するのですか?

この記事の目的は、従来の推奨プロセスに大規模モデルを導入して、何らかの支援を提供することです。もちろん、LLM をバックボーンとして使用することは、検討する価値のあるもう 1 つの方向性です。このレポートの既存の作業の調査と分析は、当社のレビュー「レコメンデーション システムは大規模言語モデルからどのようなメリットを得られるか: 調査」でもご覧いただけます。

2. ビッグ言語モデルを使用する場所（場所）

まず最初の質問に答えましょう。推奨システム プロセスで大規模言語モデルをどこで使用するかです。

従来の推奨プロセスには、データ収集、特徴エンジニアリング、特徴のエンコード、スコアリングとソート、およびプロセス全体の制御が含まれます。上の図は、推奨システムにおける大規模言語モデルの使用に関連する最近の（2021 年以降の）研究を示しています。以下では、推薦プロセスにおけるLLMの役割を皆さんに感じていただけるよう、各プロセスにおける代表的な仕事をピックアップして紹介します。

特徴エンジニアリングは主に 3 つの側面に焦点を当てています。1 つ目はユーザー ポートレート、つまりユーザー側の理解です。2 つ目はアイテム ポートレート、つまりアイテム コンテンツの理解です。3 つ目はサンプル拡張です。 LLM を活用してこれらを強化するさまざまな取り組みが行われてきました。

この研究 (GENRE) では、LLM を使用して、ニュースの要約の書き換え、ユーザー ポートレートの構築、サンプルの強化という 3 つの異なるプロンプトをニュース推奨シナリオで構築します。

まず、ニュースのタイトル、概要、カテゴリを入力として受け取り、次に大規模な言語モデルに要約の生成を要求し、この要約をニュースの新しい特徴としてダウンストリームに入力することがわかります。

次に、ユーザーのポートレートです。ユーザーが過去に視聴したニュースのタイトルに基づいて、ビッグ言語モデルに、ユーザーが興味を持っているトピック、つまりユーザーの好みや場所を知っているかどうかを尋ねてみます。

さらに、一部のユーザーはニュースをほとんど読んでいないため、サンプルを拡張するために大規模な言語モデルが使用されます。ここでは、ユーザーが読んだニュースのカテゴリとタイトルがビッグ言語モデルに入力されます。ビッグ言語モデルは、ユーザーが読んだニュースに基づいて、ユーザーが読んでいないが興味を持つ可能性のある「疑似ニュース」を生成し、これらの「疑似」インタラクション データをトレーニング セットの一部としてトレーニングに使用できることが期待されます。

実験では、これらの方法により、元の推奨の効果を高めることができることが示されています。

2 番目の部分は、言語モデルを使用して機能をエンコードし、意味情報を充実させることです。ここでの言語モデルは、Bert と同様に、トレーニングと推論のために推奨モデルに組み込む必要があるため、実際には大きくありません。リアルタイム要件が比較的高く、トレーニング サンプルが大量にある場合、言語モデルのサイズは大きくなりません。ここでは、言語モデルを使用してユーザー機能の表現を充実させる方法と、言語モデルを使用してアイテム機能の表現を充実させる方法という 2 つの側面に焦点を当てます。

U-BERT の作業では、言語モデルを使用してユーザーの特徴を表現し、BERT に似た構造を通じてユーザーが書き込んだレビュー情報をエンコードします。このユーザーのエンコーダーへのもう 1 つの入力は、ユーザーの元の ID 埋め込みと、現在の推奨ドメインの埋め込みです。これら 2 つの部分は、ユーザーのレビュー情報のエンコードとともに、ユーザーのパーソナライズされた表現を形成し、下流の推奨タスクに送信されます。

UniSRec の作業では、言語モデルを使用してアイテムの特徴を表現します。アイテムのタイトルの説明を Bert のような構造でエンコードした後、アイテムのテキスト情報のエンコードが取得されます。事前トレーニング段階の後、アイテムのテキスト表現にユーザーアイテムシーケンス情報を追加するための 2 つの対照的な学習タスクが構築されます。

最初の比較タスクは、さまざまなシナリオでのさまざまな種類のユーザーの履歴行動 (閲覧、クリック、ダウンロードなど) をすべて非常に長いシーケンスにまとめ、このシーケンスで次のトークン予測に似たタスクを実行することです。もう 1 つの比較タスクは、シーケンス間の比較タスクで、マスキングまたはサンプリングによってシーケンスから複数のシーケンスをサンプリングします。 2 つのシーケンスが同じ元のシーケンスから構築される場合、それらは正の例のペアであり、そうでない場合は負の例です。

この事前トレーニング方法により、シーケンス情報とテキスト情報が一緒にエンコードされ、下流の特定のシナリオでレコメンデーションを行う際に、次のアイテム予測に基づいたさらなる微調整が行われます。

スコアリングとソートの段階は、次の 3 つの異なるタスクに分けられます。1 つ目はアイテムを直接スコアリングすることです。2 つ目はアイテム生成タスクで、ユーザーが関心を持つ次のアイテムまたはアイテム リストを直接生成します。3 つ目は、マルチタスク アプローチを使用してモデリングする混合タスクです。

これは今年 arxiv で公開された作品です。Zero shot、Few shot、fine-tuning の 3 つの異なるシナリオでスコアリングに言語モデルを直接使用しています。

ゼロショットのシナリオでは、構築されたプロンプトには、映画のタイトル、ジャンル、過去の評価など、ユーザーの過去の行動が含まれます。映画の名前と主題が与えられたら、ユーザーがその映画をどのように評価するかを大規模言語モデルに尋ねます。

Few shot は Zero shot とは形式が若干異なりますが、いくつかの採点例が示され、質問と回答のペアもプロンプトに挿入される点を除いて、基本的な考え方は同じです。

3 番目のシナリオは微調整シナリオです。これは、プロンプトの一部としてユーザーと映画のインタラクション データを取得するだけでなく、実際のスコアと予測スコアの残差を通じてモデルを更新します。この研究では、マルチタスク アーキテクチャを使用して、一方では回帰タスクを実行し、他方ではマルチ分類タスクを実行し、これら 2 つの損失をマージしてモデルを更新することを提案しています。実験では、微調整法がゼロショットや少数ショットよりもはるかに優れていることがわかります。

次のタスクは、アイテムの推奨を直接生成することです。推奨タスク全体を 2 つの部分に分けます。最初の部分は、ユーザーが視聴したすべての映画を入力としてユーザー プロファイルを生成し、出力としてユーザーがどのような種類の映画を好むかを尋ねます。2 番目の部分は、最初の部分のユーザー プロファイルをプロンプトの一部として入力し、また、過去にインタラクションされた映画と推奨される候補セットを大規模言語モデルに入力し、大規模言語モデルを使用して推奨リストを生成します。

一見統合されているように見える推奨タスクをなぜ 2 つの部分に分割する必要があるのか​​考えてみませんか?実際、理由の 1 つは、この分解を通じて、大規模な言語モデルを促すことが推奨システムの最も重要な部分であると考えられるためです。 LLM を使用して 1 つのステップで推奨を行うと効果が低い可能性があるため、大規模言語モデルを段階的に進めるために、より直接的な方法が使用されます。最初のステップでは、ユーザーのポートレートを出力し、2 番目のステップでそれを製品推奨プロンプトに明示的に入力することで、より良い結果が得られる可能性があります。これは、思考の連鎖に多少似た、LLM が推奨事項を作成するためのアイデアも提供します。推奨プロセスは比較的複雑であり、人間の経験を使用して設計および複数のステップに分割できるため、推奨の作成は必ずしも 1 つのステップで行う必要はありません。

プロセスを複数のステップに分割することの欠点は、大規模な言語モデルへのリクエストの数が増えることです。 1 回のリクエストではなく、2 回のリクエストが必要になり、将来的には複数のリクエストが必要になる可能性があります。

次の作業は P5 で、これは実際には M6-Rec に似ています。具体的な技術的詳細は異なりますが、やりたいことは実際には同じです。統合された大規模な言語モデルを使用して、さまざまな推奨タスクに対してさまざまなプロンプトを構築し、その後、SFT を使用してさまざまな下流タスクを微調整します。

Google が提案した作業は、大規模な言語モデルを会話型推奨フレームワークのプロセスとして扱うことです。コア コンポーネントはダイアログ マネージャーにあり、大規模な言語モデルを使用して他のモジュール (ランカーを含む場合があります) を呼び出します。LLM は、ユーザー シミュレーターまたはその他のユーザー ポートレートの構築に使用できます。他のモジュールは、大規模な言語モデルを使用することも、使用しないこともできます。その仕事は、大規模な言語モデルをコア スケジューラとして使用して、比較的複雑な会話型推奨タスクを解決するプロセスとフレームワークを構築することです。

この章の紹介を通じて、大規模言語モデルには、特徴エンジニアリングの構築方法、ユーザーとアイテムの特徴を充実させる方法、データの構築方法など、推奨のさまざまな段階で行うべき作業があることがわかります。特徴エンコーディングでも言語モデルを使用できますが、この段階では表現を強化するために大規模言語モデルは使用されません。さらに、スコアリングモジュールでは、直接スコアリングまたは生成方法を使用して推奨したり、ハイブリッドタスクを実行したりできます。最後に、大規模言語モデルはスケジューリングのスケジューラとして使用できます。

3. 大規模言語モデルの使い方（方法）

次に、大規模言語モデルの使い方を紹介します。

既存の言語モデルベースの推薦作業を分類しました（データは6月末時点のもので、今後更新される予定です）。ここでの x 軸は、大規模言語モデルがトレーニング フェーズ中に微調整されたかどうかを示します。左側は大規模言語モデルの微調整を必要としない作業を示し、右側は微調整を必要とする作業を示します。 Y 軸は、大規模な言語モデルが推論段階で完全に使用されているかどうか、および従来の推奨モデルが放棄されているかどうかを示します。 Y 軸の上部では、推奨モデルが依然として支援に必要とされていますが、下部では推奨モデルは完全に放棄され、推奨システムの推論を処理するために大規模な言語モデルが使用されています。ここでの色は、各論文の比較の基準を表していますか?色が寒色系であればあるほど、打ち破れるベースラインは弱くなります。色が暖色系であればあるほど、打ち負かすことのできるベースラインが強くなります。

ここで、第3象限の色が比較的冷たいことがわかります。第3象限では、トレーニングフェーズでLLMを微調整せず、推論フェーズで推奨モデルを使用しません。LLMはAPIとして呼び出され、プロンプトルートを完全にたどります。モデルの名前から、ChatGPTやGPTなどの単語が多いことがわかります。それらの効果は実際に改善する必要があり、他の3つの象限よりも効果が弱いです。 X軸の左側のモデルサイズは全体的に大きめです。左側の作業ではLLMを微調整せず、APIとして直接呼び出すため、ある程度大きめのモデルが使えます。大きなモデルの微調整やトレーニングになると、リソースの制約によりモデルは一気に小さくなってしまいます。

時間の観点から見ると、最初の象限は実際には何年も前に開始され、Bert を使用してユーザーとアイテムのエンコードが行われました。最近、ChatGPT がリリースされてから、ChatGPT をレコメンデーションにどのように使用するかを探る作業が数多く行われてきました。第一象限から第三象限に直接挿入された探索的作業もいくつかあるが、その効果は改善する必要がある。その後、2 つの明らかな傾向が生まれました。その中核となるのは、大規模な言語モデルを直接使用して適切な推奨を行うことは不可能であるため、推奨シグナルを追加する方法を見つけなければならないということです。 1つ目の傾向は、大規模言語モデルがまだ微調整されておらず、モデル方式で改善され、推奨モデルが追加され、主な作業は第2象限にあります。もう1つの傾向は第4象限にあり、大規模言語モデルだけで推奨を行うことができると考えられており、推奨信号を追加して微調整しています。おそらく将来的には、これら 2 つのルートは第 1 象限に戻る可能性があります。この図は、現在の LLM ベースの推奨モデルを分類しようとするものであり、この作業は今後も更新され続ける予定です。現在の調査はアプリケーションの観点に偏っていますが、技術的な観点に偏っている他の作業にも注目することができます。

私たちのチームが行った、比較的初期段階の研究である 2 つの研究を紹介したいと思います。上の図の作業は第 2 象限に属し、大規模な言語モデルを API として使用します。大規模な言語モデルを微調整しないと、最終的な推奨は従来の推奨モデルによって行われます。この作業を一言でまとめると、大規模な言語モデルを使用して、ユーザー ポートレートとアイテム ポートレートの生成を強化することです。

推奨システムは、小さな家にいるのと同等の、閉じたトレーニング セットを使用してトレーニングされます。マルチシナリオのクロスドメイン推奨には一定の移行機能がありますが、それでも別荘内の複数の小さな家に閉じ込められているのと同等です。この別荘と外の世界を結ぶ道路がまだ必要です。大規模言語モデルは、比較的強い推論能力と世界知識のモデリング能力を備えており、小さな別荘と外界を結ぶ道路として非常に適しています。この作品では、この道路を使用して、ユーザーポートレートとオブジェクトポートレートを作成します。しかし、ユーザーの好みは複雑かつ多面的であり、この世界における知識も膨大であるため、大規模な言語モデルを何のガイダンスもなく直接使用すると、依然として問題が発生します。一部のデータセットでは、ユーザー機能とアイテム機能がそれほど豊富でない場合、言語モデルは多くの情報を追加できますが、それでも多くのノイズが発生します。

たとえば、私たちは以前、ユーザープロファイリングによって生成される 2 つの特徴を紹介しました。1 つはユーザーの興味であり、もう 1 つはユーザーの地域です。映画の推奨を行う場合、ユーザーの興味は映画の推奨に関連していますが、ユーザーの地域情報はこのタスクに関連しない可能性があり、ノイズ情報である可能性もあるため、このユーザー機能を生成する必要がない場合があります。

そのため、私たちのチームは、LLM を使用してユーザー ポートレートとアイテム ポートレートを生成することを提案しました。主要なサブ ファクターを構築する必要があります。ユーザー ポートレートとアイテム ポートレートを生成するには、LLM が必要です。これらの主要なサブ ファクターに焦点を当て、あまり逸脱しないようにする必要があります。この重要なサブファクターは、推奨シナリオに関連しています。映画の推奨、製品の推奨、ビデオの推奨では、重要なサブファクターが異なります。

次の問題は、主要なサブファクターをどのように構築するかということです。 1 つは主要なサブファクターを手動で指定することですが、大規模な言語モデルに問い合わせるという、より自動化された別の方法も見つかりました。たとえば、映画を推薦するシナリオでは、推薦に影響を与える最も重要な 10 の要素とその特徴は何かを教えてください。ビッグ言語モデルは、主題、俳優、監督などを教えてくれます。他の推奨シナリオでは、大規模な言語モデルを出力し、手動で再度確認して主要なサブファクターを決定し、これらの主要なサブファクターを次のユーザー機能とアイテム機能のプロンプトに入力し直すことができます。

さまざまな要素を入力すると、プロンプトは大規模な言語モデルをガイドして、必要な情報を拡張するだけでなく、現在必要な映画推奨シナリオに焦点を当てるようにします。すると、大規模言語モデルの出力がここでより重点的に扱われることになります。アイテムについても同様で、ユーザーの興味が何であるかを尋ねるなどの質問をします。この質問は非常に一般的です。複数の主要なサブ要素に分割すると、回答はドメイン固有の主要なサブ質問にさらに焦点を絞ることができます。

最初のステップは、これらの主要なサブファクターを構築し、ユーザー ポートレートとアイテム ポートレートを構築するためのプロンプトに追加することです。大規模な言語モデルを入力してユーザー ポートレートとアイテム ポートレートの情報を取得し、それを知識エンコーダーに出力します。ここでは、比較的小さなモデルを使用してエンコードし、ユーザーとアイテムの意味表現を取得できます。最終的には、これら 2 つの表現を、従来の推奨モデル (任意のモデル) に追加機能の 2 セットとして追加したいと考えています。

産業的な観点から見ると、これは生産に導入できるソリューションだと考えています。最初の段階はオフラインで生成できるため、ユーザーの長期的な行動を LLM に入力してユーザー ポートレートを生成できます。このプロセスは時間がかかり、リソースを大量に消費するため、チームのリソース状況に応じて週に 1 回実行できます。生成されたユーザーポートレートとアイテムポートレートのテキストは、メモリデータベースに保存されます。推論拡張ベクトルと事実拡張ベクトルを保存して、さらに多くのコンピューティング リソースを節約し、これら 2 つのベクトルをバックエンドの推奨モデルに入力することもできます。この研究は ArXiv で公開されています。このバージョンでは公開データセットでのみ実験を行っており、次のバージョンを補完するためにさらに多くのデータセットに取り組んでいます。ユーザーポートレートとアイテムポートレートの生成プロセスは、さまざまなバックボーン上の汎用モジュールとして使用できることがわかります。k AR モジュールを追加した後も、AUC と LogLoss の改善は依然として非常に明らかです。

実現可能性の面では、大規模な言語モデルに基づく推論生成はオフラインで行うことができます。LLM を API として呼び出すと、時間がかかります。ただし、LLM によって生成されたユーザー ポートレートとアイテム ポートレートのエンコードされたベクトルをデータベースに保存し、推論中にリアルタイムで取得すると、時間計算量が大幅に削減されます。また、他の事前トレーニング済みモデルと比較したところ、結果も比較的良好でした。

また、一連のアブレーション研究も実施し、ユーザーとアイテムの両方の機能を同時に強化したり、ベースラインではまったく何もせずに片側だけを強化したりしました。段階的な増加が見られます。ユーザーポートレートとアイテムポートレートのどちらか一方しかできない場合は、アイテム側よりもユーザー側の機能を強化する方が効果的であり、両方を行うことが最大の効果を発揮します。

この作業を要約すると、大規模言語モデルは、ユーザー ポートレートと製品ポートレートの補足として使用されます。ただし、LLM にもっと一般的で素朴な質問をすると、効果は良くありません。代わりに、補足テキストを現在の推奨シナリオにより適したものにするために、いくつかの重要なサブファクターを構築する必要があります。生成されたテキスト情報は、テキスト エンコーダーを介してベクトルに変換され、ナレッジ アダプターを通過して、生成されたベクトルがセマンティック空間から推奨空間にマッピングされます。

2 番目のタスクは CTRL と呼ばれ、第 1 象限にあります。言語モデルは推奨モデルと連携して使用され、トレーニングフェーズ中に言語モデルも微調整されます。現段階では言語モデルはそれほど大きくありませんが、さらに大きな言語モデルを使用することも試みています。

ここで、推薦システムの情報は 2 つのモードに分けられます。1 つ目はテーブル モードまたはコラボレーション モード (従来の推薦モデルはこのモードに重点を置いています)、2 つ目はテキスト モード (大規模言語モデルはこのモードに重点を置いています) です。これらの 2 つのモードは、アライメント方法を使用してアライメントすることで、効果を高めることができます。まず、さまざまなプロンプトを構築して、共同モーダル データをこの記事のデータ モダリティに変換します。たとえば、サンプルは次のようになります。18 歳の女性医師が、過去にある映画を観て、次に別の映画を観るかどうかを判断します。このような推奨問題をテキスト記述に変換し、コラボレーション モダリティとテキスト モダリティを 2 つの異なるモデルに入力します。1 つは従来の推奨モデルで、もう 1 つはテキスト モデルです (BERT と ChatGLM で試しました)。テキスト情報が入力されると、トレーニング サンプルのテキストは言語モデル エンコーダーを介してベクトルにエンコードされ、2 つのモダリティでエンコードされた情報は、きめ細かい対照学習方法によって比較されます。このようにして、事前トレーニング済み言語モデルの世界知識と意味情報の一部を、協調フィルタリング モデルへの埋め込みに転送できることが期待されます。

比較学習の後、次の段階に入り、コラボレーションモデルのみを使用して特定のシナリオで SFT を実行します。このように、コラボレーションモデルの埋め込みにはすでにいくつかの意味情報が含まれています。これらの推奨信号を追加することで、より良い結果が得られると期待しています。

MovieLens、Amazon、Alibaba を含む 3 つの異なるデータセットで実験を実施しました。比較のためのベースライン モデルが 2 セットあります。1 つは完全なコラボレーション モデルで、もう 1 つは完全なセマンティック モデルです。私たちのモデルの精度は、これら 2 つのベースライン セットと比較して大幅に向上しています。一方、推論時には協調モデルのみを使用するため、推論の待ち時間は増加しません。 Huawei の産業データセットでオフライン実験を実施し、比較的良好な結果が得られました。現在はオンラインでの展開を行っています。

IV. 課題と展望

最後に、産業応用シナリオにおける課題と今後の展望について見てみましょう。

最初の大きな課題はトレーニングの効率です。考えられる解決策としては、いくつかのパラメータを効率的に微調整し、更新頻度を減らすこと（リアルタイム パフォーマンスを向上させるために推奨される共同モデルを使用する）が挙げられます。

2 つ目の問題は、推論のレイテンシが長すぎることです。このため、上で紹介した 2 つの研究では推論段階で LLM を導入していません。代わりに、推論段階で LLM を導入しないように、結果の一部を事前に保存したり、蒸留や比較に似た方法を使用したりしています。量子化と蒸留の方法を使用してモデルを小型化し、展開することもできます。さらに、ソートやスコアリングには使用せず、特徴エンジニアリングやエンコードにのみ使用して、オンラインで直接モデル推論を行わないようにすることもできます。

3 番目の課題は、推奨ドメインにおける長いテキストのモデリングです。現在の解決策は、リコール モデルまたは粗いソート モデルを前部に接続して候補セットを 10、20、または 100 のみに絞り込み、それを LLM に送信することです。将来的には、より長いテキストを処理して、より多くの候補を直接ランク付けしたり、採点したりすることも可能になるかもしれません。

最後に、ID 機能は推奨システムにおいて依然として非常に重要です。さて、言語モデルの場合、ID 型機能のモデリングは実はあまり良くありません。意味情報に基づいてアイテムをクラスタリングし、意味クラスタリングの結果に基づいてそれらを再エンコードすることを検討した論文があります。これは非常に良いアイデアです。

記事全体を振り返ってみましょう。アプリケーションの観点から始めて、レコメンデーション システムを中核として、ビッグ言語モデルをレコメンデーション プロセス全体のどこで使用できるか、そしてビッグ言語モデルがレコメンデーション モデルとどのように連携するかという 2 つの中核的な問題を分析しました。

将来の発展を見据えると、最初の傾向として、LLM は従来のエンコーダーやスコアラーから、特徴エンジニアリング、一部のニューラル ネットワークの設計、さらにはプロセス制御へと徐々に拡張されてきました。 2つ目の傾向は、LLMを微調整せずに使用することです。現在の実験結果から判断すると、効果は良くありません。より良い推奨効果を達成したい場合は、2つの方法があります。1つは大規模な言語モデルを微調整することであり、もう1つは従来の言語モデルを融合に使用することです。

将来的には、ビッグ言語モデルは次のシナリオでの推奨に使用できるようになります。

1 つ目は、コールド スタートとロング テールの問題です。

2 つ目は、外部知識を導入することです。外部知識を導入する現在の手段はまだ比較的粗雑で、大規模な言語モデルを使用して生成します。実際、純粋な言語モデルを使用する場合、外部知識はあまりありません。逆に、言語モデルでは、何らかの検索機能を統合する必要性や、何らかのツール呼び出し機能を統合する必要性など、外部の知識も必要です。現在は、基本言語モデルのみを使用し、その検索機能やツール呼び出し機能は使用していません。将来的には、検索やツールを通じて、より多くの外部知識をより効率的かつ完全に導入できるようになることも、推奨エクスペリエンスを向上させる方向性となるでしょう。

3 つ目は、インタラクティブなエクスペリエンスを向上させ、ユーザーがインタラクティブなインターフェースを通じて積極的かつ自由にニーズを説明できるようにすることで、正確な推奨を実現することです。

5. 質疑応答

Q1: LLM の事前トレーニングには大規模なコーパスが必要です。推奨システムの公開データセットは LLM の事前トレーニングをサポートできますか?

A1: 現在、LLM のトレーニングには膨大なコーパスが必要です。公開データセットの規模は、LLM の事前トレーニングをサポートするには不十分です。より実現可能な解決策は、事前トレーニング済みの LLM と公開データセットを使用して第 1 段階の SFT を実行することです。その後、独自の推奨シナリオに基づいて第 2 段階の SFT を実行できます。

Q2: 推奨のためのグラフモデルと言語モデルの本質的な違いは何ですか?

A2: グラフは異なるノード間の構造に重点を置いていますが、それでも外部の知識を十分に活用しているわけではありません。例えば、ナレッジグラフの構築も、ある垂直ドメインのナレッジグラフです。世界レベルのナレッジグラフを構築することは不可能ですが、言語モデルはある程度、世界知識を構築することができます。