InfoWorld 寄稿者 |
機械学習の古い時代、大規模言語モデル (LLM) をチューニングされたモデルの基盤として使用できるようになる前は、基本的にすべてのデータに対して考えられるすべての機械学習モデルをトレーニングし、最適な (または最も悪い) 適合を見つける必要がありました。古い時代というのは、2017 年にトランスフォーマー ニューラル ネットワーク アーキテクチャに関する独創的な論文「Attention is all you need」が発表される前の時代を指します。
はい、私たちのほとんどは、その後も何年も、あらゆる機械学習モデルを盲目的にトレーニングし続けました。LLM をトレーニングするのに十分な GPU、TPU、FPGA、および膨大な量のテキストにアクセスできるのはハイパースケーラーとベンチャー資金による AI 企業だけだったため、ハイパースケーラーが LLM を私たち全員と共有し始めるまでにはしばらく時間がかかりました (「少額」の料金で)。
生成 AI の新しいパラダイムでは、開発プロセスは以前とは大きく異なります。全体的な考え方は、最初に生成 AI モデル (複数可) を選択することです。次に、プロンプトを操作し (「プロンプト エンジニアリング」と呼ばれることもありますが、これは実際のエンジニアに対する侮辱です)、ハイパーパラメータを調整して、モデルが希望どおりに動作するようにします。
必要に応じて、ベクトル埋め込み、ベクトル検索、およびベース LLM の初期トレーニングには含まれていなかったデータを使用して、検索拡張生成 (RAG) でモデルをグラウンディング (新しいデータに接続) できます。それでもモデルを必要な方法で動作させるのに十分でない場合は、独自のタグ付きデータに対してモデルを微調整するか、(余裕があれば) 大量のタグなしデータを使用してモデルの事前トレーニングを継続することもできます。モデルを微調整する理由の 1 つは、モデルがユーザーとチャットし、会話の過程でコンテキストを維持できるようにすることです (例: ChatGPT)。これは通常、基礎モデル (例: GPT) には組み込まれていません。
エージェントは、ツール、実行コード、埋め込み、およびベクトル ストアの組み合わせによって会話型 LLM の考え方を拡張します。言い換えると、エージェントは RAG に追加のステップを加えたものです。エージェントは、多くの場合、LLM を特定のドメインに特化させ、LLM の出力をカスタマイズするのに役立ちます。さまざまなプラットフォーム、フレームワーク、およびモデルにより、LLM と他のソフトウェアやサービスの統合が簡素化されます。
まず、モデルを選択するときは、後で別のモデルに切り替える方法について考えてください。LLM はほぼ毎日改善されるため、近い将来に最適ではない、あるいは時代遅れになる可能性のあるモデルに縛られることは避けてください。この問題に対処するには、異なるベンダーから少なくとも 2 つのモデルを選択することをお勧めします。
また、推論の継続的なコストも考慮する必要があります。サービスとして提供されるモデルを選択した場合は、推論ごとに料金を支払うため、トラフィックが少ない場合はコストが低くなります。プラットフォームとしてモデルを選択した場合は、トラフィックを処理するためにプロビジョニングする VM に対して、通常は数千ドルの固定月額コストがかかります。これは、生成モデルには通常、大量の RAM、数十または数百の CPU、および少なくとも 1 桁の数の GPU を備えた大規模な VM が必要であるためです。
企業によっては、生成 AI モデルがオープンソースであることを求めていますが、そうでない企業もあります。現在、Meta Llama モデルなど、厳密にオープンソースである優れた生成 AI モデルはいくつかありますが、大規模なモデルの大部分は独自のものです。X の Grok (ほぼ FOSS ですが、完全には FOSS ではありません) や Databricks の DBRX など、さらに多くのオープンソース生成 AI モデルが、毎週のようにリリースされています。
プロンプト エンジニアリングは、LLM をカスタマイズする最も簡単で最速の方法です。これは、シンプルに見えますが、うまく実行するにはある程度のスキルと繊細さを必要とする点で、モーツァルトの作品に少し似ています。
プロンプト エンジニアリングについては、何百万もの単語が書かれています。この用語を簡単に検索すると、3 億件を超える結果が返されます。その膨大な情報を調べる代わりに、最も役立つプロンプト エンジニアリング手法のいくつかを紹介しましょう。
生成 AI プロンプトから良い結果を得るための全体的な戦略には、OpenAI のプロンプト エンジニアリングに関する最優先の提案である「明確な指示を書く」など、明らかなものが多く含まれています。ただし、表面上はフレンドリーなチャットボットは文字通りコンピューター上で実行されるモデルにすぎず、ユーザーの心を読むことはできないということを忘れがちであるため、詳細な戦術はそれほど明白ではないかもしれません。
たとえば、新しい若い従業員を監督しているかのように、モデルに実行させたいことを段階的に説明する必要があるかもしれません。モデルに使用させたい出力形式を示す必要があるかもしれません。モデルが希望する長さの回答を返すまで、指示を繰り返す必要があるかもしれません。モデルに事実に忠実であり、補間しないように明示的に指示する必要があるかもしれません。そのための便利な (ただし絶対確実ではない) プロンプトの 1 つは、「情報不足で回答できない場合は、その旨を述べてください」です。モデルにペルソナを採用するように依頼することもできますが、それだけで十分かどうかはわかりません。たとえば、モデルに、ある分野の専門家であると伝えても、必ずしも専門家になる準備ができるわけではありません。
ほとんどの場合、例を提供することは役に立ちます。特にプロンプト/応答のペアで提供する場合はそうです。次のように定義された Azure AI Studio Shakespearean Writing Assistant サンプルを検討してください。
あなたはシェイクスピア風のスタイルで話すシェイクスピアの執筆アシスタントです。「汝」や「有る」などの言葉を含むウィリアム・シェイクスピアの執筆スタイルを使った物語、詩、歌などの創造的なアイデアやコンテンツを生み出すお手伝いをします。
シェイクスピアのスタイルの例をいくつか挙げます。
– ロミオ、ロミオ！あなたはなぜロミオなのですか？
– 愛は目ではなく心で見る。だから翼のあるキューピッドには目が見えないように描かれている。
– あなたを夏の日と比べましょうか？あなたの方がもっと愛らしくて、もっと穏やかです。
これは、GPT 3.5 Turbo にシェイクスピアのスタイルをうまく使用するよう説得するのに十分であるが、じゃじゃ馬ならしのグルミオの「疲れた翡翠、狂った主人、そして汚いやり方すべてに、ふざけんな」のような暴言を吐かせるには不十分であることが判明した。モデル (またはプラットフォーム) に組み込まれたフィルターにより、暴言を吐くように求められても、侮辱的なスピーチではなくシェイクスピアのスタイルで適切なスピーチを生成しようとする。
受信者の親が不明であることや知性の欠如について、侮辱的な暴言を書きます。
おはようございます、親愛なる紳士淑女の皆様、私は告白しなければなりません
こんな苦難に巻き込まれるのは私の性分ではない
シェイクスピアの言葉は鋭いが、人を傷つけるものではない。
むしろ高揚させ、刺激を与え、驚かせるために
その代わりに機知と賢さについて話しましょう
悪い韻のwoon/astoundはさておき、おそらく、Grumioの引用を暴言の例として追加し、プロンプトに変更を適用することで、応答を修正できるでしょう。試してみましょう。
アシスタント: 疲れた玉ども全員、気が狂った主人全員、そして汚いやり方全員に、くそったれ。
この追加を適用すると、モデルは少し洗練された火を生成できるようになります。
受信者の親が不明であることや知性の欠如について、侮辱的な暴言を書きます。
ああ、哀れな魂よ！あなたの親は不明だ、
あなたの魂をうめかせる神秘。
あなたの血管には高貴な血は流れていない。
むしろ、無知と愚かさが表に出ているのです。
あなたの心は不毛の荒野、感覚の無い、
理性も知性も存在しない場所。
あなたの考えは愚かなハエのようにブンブン飛び回り、
機知に富んだ戯言、哀れな寸劇。
モデルが「ろくでなし」や「馬鹿」という単語を生成していないことにお気づきでしょう。これらの単語は、おそらく明示的に除外されています。例として、マクベスの引用「これは馬鹿が語る物語で、騒音と怒りに満ち、何の意味もない」を追加してみたい場合は、どうぞご自由に。また、「私もろくでなしだ」で始まるトロイラスとクレシダの引用を追加することもできます。
もう 1 つの便利な戦略は、プロンプトの一部としてドキュメントを提供し、モデルにそのドキュメントに依存するように要求することです。一部のモデルは URL から Web ページを検索できますが、他のモデルではテキストを提供する必要があります。モデルへの指示と、使用するドキュメント テキストを明確に区別し、要約タスクとエンティティ抽出タスクの場合は、応答が提供されたテキストのみに依存するように指定する必要があります。
ドキュメントの提供は、通常、ドキュメントが短い場合にうまく機能します。ドキュメントがモデルのコンテキスト ウィンドウよりも長い場合、ドキュメントの末尾は読み込まれません。これが、生成 AI モデル開発者がモデルのコンテキスト ウィンドウを継続的に増やしている理由の 1 つです。Gemini 1.5 Pro には、Google Vertex AI Studio で選ばれたユーザーが利用できる最大 100 万トークンのコンテキスト ウィンドウがありますが、現在、一般のユーザーは「わずか」128K トークンのコンテキスト ウィンドウで苦労しています。後で説明するように、コンテキスト ウィンドウの制限を回避する 1 つの方法は、RAG を使用することです。
LLM に長い文書 (ただしコンテキスト ウィンドウに収まりきらないほど長い文書) の要約を依頼すると、他のソースから知っていると思われる「事実」が追加されることがあります。代わりにモデルに文書を圧縮するように依頼すると、無関係な内容を追加せずに要求に応じる可能性が高くなります。
要約を改善するもう 1 つの方法は、コロンビア大学、Salesforce、MIT のチームが 2023 年に GPT-4 専用に導入した Chain of Density (CoD) プロンプト (論文) を使用することです。KDnuggets の記事では、論文のプロンプトをより読みやすい形式で提示し、説明を追加しています。論文と記事の両方を読む価値があります。
短い要約: CoD プロンプトは、モデルにベース ドキュメントの要約を 5 回繰り返すように要求し、各ステップで情報密度を高めます。論文によると、人々は 5 つの要約のうち 3 番目が最も好まれる傾向がありました。また、論文で GPT-4 に対して与えられたプロンプトは、他のモデルでは適切に機能しない (またはまったく機能しない) 可能性があることに注意してください。
2022年に導入された思考連鎖プロンプト（論文）は、LLMに一連の中間推論ステップを使用するように求め、「大規模な言語モデルが複雑な推論を実行する能力を大幅に向上させます」。たとえば、思考連鎖プロンプトは算数の文章題に適しています。算数は小学校レベルの数学であるにもかかわらず、LLMが正しく解くのは難しいようです。
元の論文では、著者らは思考の連鎖シーケンスの例を数ショットのプロンプトに組み込んでいました。思考の連鎖プロンプトの Amazon Bedrock の例では、「あなたは並外れた批判的思考力を持つ非常に知的なボットです」というシステム指示と、「ステップごとに考えてみましょう」というユーザー指示により、Llama 2 Chat 13B および 70B モデルから複数ステップの推論を引き出すことに成功しています。
2023年に導入された Skeleton-of-thought prompting（論文）は、「最初にLLMをガイドして回答のスケルトンを生成し、次に並列API呼び出しまたはバッチデコードを実行して各スケルトンポイントのコンテンツを並列に完了する」ことで、LLMのレイテンシを短縮します。論文に関連付けられているコードリポジトリでは、バリアントであるSoT-R（RoBERTaルーターを使用）を使用し、PythonからLLM（GPT4、GPT-3.5、またはClaude）を呼び出すことを推奨しています。
プロンプト エンジニアリングは、最終的にはモデル自体によって実行される可能性があります。この方向の研究はすでに行われています。重要なのは、モデルが使用できる定量的な成功指標を提供することです。
LLM には、プロンプトの一部として設定できるハイパーパラメータがしばしばあります。ハイパーパラメータの調整は、機械学習モデルのトレーニングと同様に、LLM プロンプトでも重要です。LLM プロンプトの重要なハイパーパラメータは通常、温度、コンテキスト ウィンドウ、トークンの最大数、停止シーケンスですが、モデルごとに異なる場合があります。
温度は出力のランダム性を制御します。モデルに応じて、温度は 0 ～ 1 または 0 ～ 2 の範囲になります。温度値が高いほど、ランダム性が増します。一部のモデルでは、0 は「温度を自動的に設定する」ことを意味します。他のモデルでは、0 は「ランダム性なし」を意味します。
コンテキスト ウィンドウは、モデルが回答に考慮する先行トークン (単語またはサブワード) の数を制御します。トークンの最大数によって、生成される回答の長さが制限されます。停止シーケンスは、出力内の不快または不適切なコンテンツを抑制するために使用されます。
検索拡張生成 (RAG) は、多くの場合、モデルの元のトレーニングには含まれていなかった特定のソースを使用して LLM をグラウンディングするのに役立ちます。ご想像のとおり、RAG の 3 つのステップは、指定されたソースからの取得、ソースから取得したコンテキストによるプロンプトの拡張、そしてモデルと拡張されたプロンプトを使用した生成です。
RAG 手順では、多くの場合、埋め込みを使用して長さを制限し、取得したコンテキストの関連性を高めます。基本的に、埋め込み関数は単語またはフレーズを取得し、それを浮動小数点数のベクトルにマッピングします。これらは通常、ベクトル検索インデックスをサポートするデータベースに格納されます。次に、検索ステップで、通常はクエリの埋め込みと格納されたベクトル間の角度のコサインを使用して、意味的類似性検索を行い、拡張プロンプトで使用する「近くの」情報を検索します。検索エンジンは通常、回答を見つけるために同じことを行います。
エージェント (会話型検索エージェントとも呼ばれる) は、ツール、実行コード、埋め込み、およびベクター ストアの組み合わせによって会話型 LLM の概念を拡張します。エージェントは多くの場合、LLM を特定のドメインに特化させ、LLM の出力をカスタマイズするのに役立ちます。Azure Copilot は通常エージェントです。Google と Amazon は「エージェント」という用語を使用します。LangChain と LangSmith は、RAG パイプラインとエージェントの構築を簡素化します。
著作権 © 2024 IDG Communications, Inc.