次の方法で共有

検索拡張生成と微調整による大規模言語モデルの拡張

  • [アーティクル]

このシリーズの記事では、LLM が応答の生成に使用する知識取得モデルについて説明します。 既定では、大規模言語モデル (LLM) はそのトレーニング データにのみアクセスできます。 ただし、モデルを拡張して、リアルタイム データまたはプライベート データを含めることができます。 この記事では、モデルを拡張するための 2 つのメカニズムの 1 つについて説明します。

最初のメカニズムは Retrieval-Augmented Generation (RAG) です。これは、セマンティック検索とコンテキスト プライミングを組み合わせた前処理の一種です ( 他の記事で説明)。

2 つ目のメカニズムは微調整です。これは、最初の広範なトレーニングの後に特定のデータセットでモデルをさらにトレーニングするプロセスを指し、タスクのパフォーマンスを向上させたり、そのデータセットに関連する概念を理解したりするよう調整することを目的としています。 このプロセスは、モデルが特定の種類の入力またはドメインを処理する精度と効率を特殊化したり改善したりするのに役立ちます。

以下のセクションでは、これらの 2 つのメカニズムについて詳しく説明します。

RAG について理解する

RAG は、テキスト コンテンツの大規模なコーパス (社内文書、ドキュメントなど) を持ち、このコーパスをユーザー プロンプトへの回答の基礎として使用する企業で、"データを介したチャット" シナリオを有効にするためによく使用されます。

大まかに言うと、各ドキュメント (または "チャンク" と呼ばれるドキュメントの一部) にデータベース エントリを作成します。 チャンクは、ドキュメントのファセットを表す数値のベクトル (配列) の埋め込み時にインデックス作成されます。 ユーザーによってクエリが送信されたら、データベースで同様のドキュメントを検索した後、クエリとドキュメントを LLM に送信して回答を作成します。

Note

検索拡張生成 (RAG) という用語は寛容な意味で使用されます。 この記事で説明する RAG ベースのチャット システムを実装するプロセスは、サポート容量 (RAG) で使用する外部データを使用するか、応答 (RCG) の中心として使用するかを適用できます。 この微妙な区別は、RAG に関連するほとんどの読み取りでは対処されません。

ベクトル化されたドキュメントのインデックスの作成

RAG ベースのチャット システムを作成する最初のステップとして、ドキュメント (またはドキュメントの一部) のベクトル埋め込みを含むベクトル データ ストアを作成できます。 ドキュメントのベクトル化インデックスを作成するための基本的なステップの概要を示す次の図を考えてみましょう。

ドキュメント インジェストのさまざまな段階を示す図。チャンク処理から始まり、チャンク処理後のプロセス ステップ、埋め込み API の呼び出し、ドキュメント チャンクをベクトル化された埋め込みとしてベクトル データベースに保存する段階が続きます。

この図は、システムによって使用されるデータのインジェスト、処理、管理を担当するデータ パイプラインを表しています。 これには、ベクトル データベースに格納されるデータの前処理と、LLM に送られるデータが正しい形式であることを確認する処理が含まれます。

プロセス全体は、機械学習モデルで処理できる方法によって入力のセマンティック プロパティをキャプチャするデータ (通常は単語、フレーズ、文、またはドキュメント全体) の数値表現である、埋め込みの概念に従って実行されます。

埋め込みを作成するには、コンテンツのチャンク (文、段落、またはドキュメント全体) を Azure OpenAI Embedding API に送信します。 Embedding API から返される内容はベクトルです。 ベクトルの各値は、コンテンツの特性 (次元) を表しています。 ディメンションには、トピック、セマンティックの意味、構文と文法、単語とフレーズの使用法、コンテキストの関係、スタイル、トーンなどが含まれる場合があります。同時に、ベクトルのすべての値は、コンテンツの次元空間を表しています。 言い換えれば、3 つの値を持つベクトルの 3D 表現を考える場合、特定のベクトルは x、y、z 平面の特定の領域に存在します。 値が 1000 (またはそれ以上) の場合はどうでしょうか? 人間が 1000 次元のグラフを紙の上に描いて理解しやすくすることは不可能ですが、コンピューターはその程度の次元空間を問題なく理解することができます。

図の次のステップでは、ベクトルをコンテンツ自体 (またはコンテンツの場所へのポインター) や他のメタデータと共にベクトル データベースに格納する方法を示します。 ベクトル データベースは任意の種類のデータベースに似ていますが、次の 2 つの違いがあります。

  • ベクトル データベースでは、データを検索するためのインデックスとしてベクトルが使用されます。
  • ベクトル データベースは、コサイン類似検索と呼ばれるアルゴリズム (ニアレスト ネイバーとも呼ばれます) を実装します。このアルゴリズムでは、検索条件に最も近いベクトルが使用されます。

開発者は、ベクトル データベースに保存されたドキュメントのコーパスを使用して、ユーザーのクエリに一致するドキュメントをデータベースから取得する取得コンポーネントを構築し、ユーザーのクエリに回答するために必要なものを LLM に提供できます。

ドキュメントによってクエリに応答する

RAG システムでは、まずセマンティック検索を使用して、回答を作成するときに LLM に役立つ可能性のある記事を見つけます。 次のステップでは、一致する記事をユーザーの元のプロンプトと共に LLM に送信して回答を作成します。

次の図は、シンプルな RAG 実装 ("単純な RAG" とも呼ばれます) と考えてください。

シンプルな RAG フローを表す図。ボックスはステップまたはプロセスを表し、矢印が各ボックスを接続しています。フローは、ユーザーのクエリから始まり、Embedding API に送信されます。Embedding API は、ベクター化されたクエリで結果を返します。このクエリは、ベクトル データベースで最も近い一致 (記事チャンク) を見つけるために使用されます。クエリと記事チャンクは Completion API に送信され、結果がユーザーに送信されます。

この図では、ユーザーがクエリを送信しています。 最初のステップでは、ベクトルを取得するユーザーのプロンプトの埋め込みを作成します。 次のステップでは、ベクトル データベースにおいて、"ニアレスト ネイバー" の一致するドキュメント (またはドキュメントの一部) を検索します。

コサイン類似性は、2 つのベクトルの類似度を判断するために使用される尺度であり、基本的にそれらの間の角度のコサインを評価します。 1 に近いコサインの類似性は高い類似性 (小さい角度) を示し、-1 に近い類似性は非類似度 (180 度に近い角度) を示しています。 このメトリックは、ドキュメントの類似性などのタスクにとって非常に重要です。目標は、類似したコンテンツまたは意味を持つドキュメントを見つけることです。

"ニアレスト ネイバー" アルゴリズムは、ベクトル空間内の特定のポイントに最も近いベクトル (ネイバー) を見つけることで機能します。 k ニアレスト ネイバー (KNN) アルゴリズムでは、'k' は考慮するニアレスト ネイバーの数を指します。 このアプローチは、分類と回帰で広く使用されています。このアルゴリズムでは、トレーニング セット内の最も近い "k" ニアレスト ネイバーのマジョリティ ラベルに基づいて、新しいデータ ポイントのラベルが予測されます。 KNN とコサインの類似性は多くの場合、レコメンデーション エンジンなどのシステムで一緒に使用されます。その目的は、埋め込み空間内のベクトルとして表されるユーザーの好みに最も似た項目を見つけることです。

その検索から最適な結果を取得し、一致するコンテンツをユーザーのプロンプトと共に送信して、一致するコンテンツによって通知される応答 (可能であれば) を生成します。

課題と考慮事項

RAG システムの実装には、一連の課題が伴います。 特に外部ソースから情報を取得して処理する場合、システムが責任を持ってユーザー データを処理する必要があるので、データのプライバシーは最も重要です。 取得プロセスと生成プロセスの両方がリソースを大量に消費するため、計算要件も高くなる可能性があります。 データまたはモデルに存在するバイアスを管理しながら、応答の精度と関連性を確保することも、もう 1 つの重要な考慮事項です。 開発者は、効率的かつ倫理的で貴重な RAG システムを作成するため、これらの課題を慎重にナビゲートする必要があります。

このシリーズの次の記事である「高度な検索拡張生成システムの構築」では、運用環境に対応した RAG システムを可能にするデータと推論パイプラインの構築について詳しく説明します。

すぐに生成 AI ソリューションの構築の実験を開始する場合は、python 用の独自のデータ サンプルを使用してチャットを開始する を確認することをお勧めします。 このチュートリアルには、.NET、Java、JavaScript でも使用できるバージョンがあります。

モデルの微調整

LLM のコンテキストでの微調整とは、大規模かつ多様なデータセットにおいて最初にトレーニングされた後、ドメイン固有のデータセットでモデルのパラメーターを調整するプロセスを指しています。

LLM は、幅広いデータセットでトレーニング (事前トレーニング) され、言語構造、コンテキスト、および幅広い知識を把握します。 この段階では、一般的な言語パターンを学習します。 微調整により、より小さい特定のデータセットに基づいて、事前トレーニング済みモデルにトレーニングが追加されます。 このセカンダリ トレーニング フェーズでは、特定のタスクに対してより適切に実行されるようにモデルを調整したり、特定のドメインを理解したりして、その精度と特殊なアプリケーションとの関連性を高めたりすることを目的としています。 微調整時、モデルの重みが調整され、この小さなデータセットの微妙な違いをより適切に予測または理解できるようになります。

いくつかの考慮事項があります。

  • 特殊化: 微調整により、法的ドキュメント分析、医療テキストの解釈、カスタマー サービスの対話など、特定のタスクに合わせてモデルが調整されます。 これにより、これらの領域でモデルの効果が高くなります。
  • 効率: 微調整に必要なデータと計算リソースが少ないため、モデルをゼロからトレーニングするよりも、特定のタスクの事前トレーニング済みモデルを微調整する方が効率的です。
  • 適応性: 微調整により、元のトレーニング データの一部ではなかった新しいタスクやドメインに適応できるため、LLM はさまざまなアプリケーションに対応できるツールになります。
  • パフォーマンスの向上: モデルが最初にトレーニングされたデータとは異なるタスクの場合、微調整により、新しいドメインで使用される特定の言語、スタイル、用語を理解するようにモデルが調整されるため、パフォーマンスが向上する可能性があります。
  • パーソナル化: 一部のアプリケーションでは、微調整によって、ユーザーまたは組織の特定のニーズや好みに合わせてモデルの応答や予測をカスタマイズできます。 ただし、微調整には、一定の短所と制限もあります。 これらを理解すると、取得拡張生成 (RAG) などの代替手段と微調整を選択するタイミングを決定する際に役立ちます。
  • データ要件: 微調整には、ターゲットのタスクまたはドメインに固有の十分な大きさで品質の高いデータセットが必要です。 このデータセットの収集とキュレーションは、困難かつリソースを大量に消費する可能性があります。
  • オーバーフィット リスク: 特に小規模なデータセットでは、オーバーフィットのリスクがあります。 オーバーフィットにより、モデルはトレーニング データに対して高いパフォーマンスを発揮しますが、見えない新しいデータではパフォーマンスが低下し、一般化性も低下します。
  • コストとリソース: ゼロからのトレーニングよりもリソースを多く消費することは少なくなりますが、微調整には計算リソースが必要です。特に大規模なモデルやデータセットの場合、ユーザーやプロジェクトによってはかなりのリソースを消費する可能性があります。
  • メンテナンスと更新: ドメイン固有の情報は時間の経過とともに変化するため、微調整されたモデルは、その効果を維持するために定期的な更新が必要になる可能性があります。 この継続的なメンテナンスには、追加のリソースとデータが必要です。
  • モデル ドリフト: モデルは特定のタスクに合わせて微調整されるため、一般的な言語理解と汎用性の一部が失われ、モデル ドリフトと呼ばれる現象が発生する可能性があります。

「微調整によるモデルのカスタマイズ」では、モデルを微調整する方法が説明されています。 大まかに言うと、潜在的な質問と好ましい回答の JSON データ セットを提供します。 このドキュメントは、50 ～ 100 の質問/回答ペアを提供することにより顕著な改善が見られたことを示していますが、ユース ケースでは適切な数が大きく異なります。

微調整と取得拡張生成の比較

表面的には、微調整と検索拡張生成の間にかなりの重複があるように見えるかもしれません。 微調整と検索強化生成のどちらを選択するかは、パフォーマンスへの期待値、リソースの可用性、ドメインの特異性ニーズと一般化性の比較など、タスクの特定の要件によって異なります。

取得拡張生成よりも微調整を優先する場合:

  • タスク固有のパフォーマンス - 特定のタスクのパフォーマンスを高めることが重要であり、大きなオーバーフィット リスクなしでモデルを効果的にトレーニングするのに十分なドメイン固有のデータが存在する場合、微調整が適しています。
  • データの制御 - 基本モデルのトレーニングに使用されたデータとは大幅に異なる独自のデータや、高度に専門化されたデータがある場合、微調整によってこの固有の知識をモデルに組み込むことができます。
  • リアルタイム更新のニーズが限られている - 必ずしもタスクでモデルを最新の情報で更新する必要がない場合、RAG モデルは通常、最新のデータを取得するために最新の外部データベースまたはインターネットにアクセスする必要があるため、微調整がより効率的になります。

微調整よりも取得拡張生成を優先する場合:

  • 動的または進化するコンテンツ - RAG は、最新情報が重要なタスクに適しています。 RAG モデルは外部ソースからリアルタイムでデータを取り込むことができるため、ニュース生成や最近のイベントに関する質問への回答などの適用に適しています。
  • 特殊化よりも一般化 - 狭いドメインで優れた成績を収めるのではなく、幅広いトピックにわたって優れたパフォーマンスを維持することが目標である場合、RAG が適している可能性があります。 外部サポート情報が使用されるため、特定のデータセットにオーバーフィットするリスクを伴うことなくさまざまなドメイン間で応答を生成できます。
  • リソースの制約 - データ収集とモデル トレーニングのリソースが限られている組織では、RAG アプローチを使用すると、特に基本モデルが目的のタスクに対して合理的に適切に実行されている場合、微調整に代わるコスト効率の高い代替手段を手に入れられる可能性があります。

アプリケーション設計の決定に影響を与える可能性がある最終的な考慮事項

アプリケーションの設計上の決定に影響を与える、この記事で考慮すべき事項とその他のポイントの簡単な一覧を以下に示します。

  • アプリケーションの特定のニーズに基づいて、微調整か取得拡張生成かを決定します。 微調整により、特殊化されたタスクのパフォーマンスが向上する一方、RAG は動的アプリケーションに柔軟性と最新のコンテンツを提供できます。