Azure OpenAI の微調整を使用する状況
特定のユース ケースを調べるための適切な解決策が微調整であるかどうかを判断する場合、次の重要な用語を理解しておくと役に立ちます。
- プロンプト エンジニアリングは、自然言語処理モデルのプロンプトの設計を含む手法です。 このプロセスにより、応答の精度と関連性が向上し、モデルのパフォーマンスが最適化されます。
- 取得拡張生成 (RAG) は、外部ソースからデータを取得し、プロンプトに組み込むことで、大規模言語モデル (LLM) のパフォーマンスを向上させます。 RAG を使用すると、企業はデータの関連性を維持し、コストを最適化しながら、カスタマイズされたソリューションを実現できます。
- 微調整では、サンプル データを使用して既存の大規模言語モデルを再トレーニングし、提供された例を使用して最適化された新しい "カスタム" 大規模言語モデルを構築します。
Azure OpenAI での微調整とは
微調整について話すとき、継続的な事前トレーニングまたは人間のフィードバックによる強化学習 (RLHF) ではなく、教師あり微調整を実際に意味します。 教師あり微調整とは、特定のデータセットで事前トレーニング済みのモデルを再トレーニングするプロセスを指します。通常は、特定のタスクのモデルのパフォーマンスを向上させたり、基本モデルが最初にトレーニングされたときによく表されなかった情報を導入したりするために使用します。
微調整は、専門知識を適切に使用する必要がある高度な手法です。 以下の質問は、微調整の準備ができているかどうか、およびプロセスをどの程度よく検討したかを評価するのに役立ちます。 これらを使用して、次の手順をガイドしたり、より適切な他のアプローチを特定したりすることができます。
モデルを微調整する理由
- 微調整のために特定のユース ケースを明確にし、微調整するモデルを特定できる必要があります。
- 微調整に適したユース ケースには、特定のカスタマイズされたスタイル、トーン、または形式でコンテンツを出力するようにモデルを操作するケースや、モデルを操作するために必要な情報が長すぎるか複雑すぎてプロンプト ウィンドウに収まらないシナリオなどがあります。
まだ微調整の準備ができていない可能性がある一般的な兆候:
- 微調整のための明確なユース ケースがない場合、または「モデルをより良くしたいと思う」以外に明確に表現できない場合。
- コストが主な動機として認識される場合は、慎重に進めてください。 微調整では、プロンプトを短くしたり、より小さなモデルを使用したりすることで、特定のユース ケースのコストが削減される可能性がありますが、トレーニングのための先行コストが大きくなり、独自のカスタム モデルをホストするために料金を支払う必要があります。 Azure OpenAI の微調整コストの詳細については、価格に関するページを参照してください。
- ドメイン知識をモデルに追加する場合は、データ上の Azure OpenAI や埋め込みなどの機能を使用して、取得拡張生成 (RAG) から始める必要があります。 多くの場合、これは、ユース ケースとデータに応じて、より低コストで適応性に優れ、効果が高い可能性があるオプションです。
これまでに何を試みましたか?
微調整は高度な機能であり、生成型 AI 体験の開始点ではありません。 大規模言語モデル (LLM) の使用の基本については、既に理解している必要があります。 まず、プロンプト エンジニアリングや取得拡張生成 (RAG) を使用して基本モデルのパフォーマンスを評価し、パフォーマンスのベースラインを取得する必要があります。
微調整していないときのパフォーマンスのベースラインを取得することは、微調整によってモデルのパフォーマンスが向上したかどうかを把握するために不可欠です。 不適切なデータを使用して微調整すると、基本モデルが悪化し、ベースラインがないと、回帰を検出するのが困難です。
微調整の準備ができている場合:
- プロンプト エンジニアリングと RAG ベースのアプローチの証拠と知識を実証できる必要があります。
- ユース ケースで既に試行されている微調整以外の手法を使用して、特定のエクスペリエンスと課題を共有できるようにします。
- 可能な限り、ベースライン パフォーマンスの定量的評価を行う必要があります。
まだ微調整の準備ができていない可能性がある一般的な兆候:
- 他の手法をテストすることなく、微調整から始めている。
- 特に大規模言語モデル (LLM) に微調整を適用する方法に関する十分な知識または理解がない。
- 微調整を評価するベンチマーク測定がない。
別の方法では何が機能しないのですか?
プロンプト エンジニアリングが不足している場所を理解するには、微調整に関するガイダンスを提供する必要があります。 基本モデルはエッジ ケースまたは例外で失敗しますか? 基本モデルで一貫して正しい形式で出力が提供されていないため、コンテキスト ウィンドウで修正するのに十分な例を入力することができないのですか?
基本モデルとプロンプト エンジニアリングでの失敗の例は、微調整のために収集する必要があるデータと、微調整されたモデルを評価する方法を特定するのに役立ちます。
次に例を示します。お客様は、GPT-3.5-Turbo を使用して、自然言語の質問を特定の非標準クエリ言語のクエリに変換したいと考えていました。 プロンプトでガイダンスを提供し (“常に GQL を返します")、RAG を使用してデータベース スキーマを取得しました。 ただし、構文が常に正しいとは限らないため、多くの場合、エッジ ケースでは失敗しました。 モデルが以前に失敗し、そのデータを使用してモデルを微調整したケースなど、自然言語の質問とデータベースに対する同等のクエリの例を何千も収集しました。 新しい微調整されたモデルと、設計されたプロンプトと取得を組み合わせることで、モデル出力の精度が許容能な標準にまで向上しました。
微調整の準備ができている状況:
- 代替アプローチの課題に取り組んだ方法と、パフォーマンスを向上させるために可能な解決策としてテストされた内容に関する明確な例があります。
- エッジ ケースでの一貫性のないパフォーマンス、モデルを操作するのに十分な数のショット プロンプトがコンテキスト ウィンドウに収まらない、待機時間が長いなど、基本モデルを使用して欠点を特定しました。
まだ微調整の準備ができていない可能性がある一般的な兆候:
- モデルまたはデータ ソースからの十分な知識がない。
- モデルに対応する適切なデータを見つけることができない。
微調整に使用するデータは何ですか?
優れたユース ケースの場合でも、微調整の効果は、提供できるデータの品質と同程度になります。 微調整作業を行うために時間と労力を費やす必要があります。 モデルによって必要なデータ量は異なりますが、多くの場合、かなり大量の高品質のキュレーションされたデータを提供できる必要があります。
もう一つ重要なポイントは、高品質データであっても、データが微調整に必要な形式でない場合は、データを適切に書式設定するためにエンジニアリング リソースをコミットする必要があることです。
| データ | Babbage-002 Davinci-002 |
GPT-3.5-Turbo GPT-4o と GPT-4o mini GPT-4 |
|---|---|---|
| 体積 | 数千の例 | 数千の例 |
| 形式 | プロンプト/完了 | 会話型チャット |
微調整の準備ができている状況:
- 微調整用のデータセットを特定しています。
- データセットはトレーニングに適した形式になっています。
- データセットの品質を確保するために、ある程度のキュレーションが採用されています。
まだ微調整の準備ができていない可能性がある一般的な兆候:
- データセットがまだ特定されていない。
- データセットの形式が、微調整するモデルと一致していない。
微調整されたモデルの品質はどのように測定しますか?
この質問に対する正しい答えは 1 つではありませんが、微調整による成功の目標を明確に定義する必要があります。 理想的には、検証に予約データのセットを利用するか、ユーザー受け入れテストや、基本モデルに対して微調整されたモデルの A/B テストなど、質的な尺度だけでなく成功の定量的な尺度を含める必要があります。
次のステップ
- 「Azure AI Show episode: "To fine-tune or not to fine-tune, that is the question" (Azure AI ショー エピソード: 微調整するか微調整しないかそれが問題だ)」を見る
- Azure OpenAI 微調整の詳細を参照する
- の微調整に関するチュートリアルを確認する