生成 AI ソリューションを構築する開発者にとっての重要な概念と考慮事項
大規模言語モデル (LLM) はすばらしいものですが、限界もあります。 開発者は、これらの制限、つまり LLM が "設定なしで使える" ことを理解し、構築している生成 AI ソリューションに最適な結果を得るためにそれらを調整する方法を理解する必要があります。 この記事では、いくつかの課題と制限要素を特定して、それらの課題を克服し、アプリケーションに組み込む生成 AI 機能の種類に関係なくコンテンツ生成プロセスを制御する一般的な方法について説明します。
LLM を使用するときのエンジニアリングの課題
LLM を操作する際に注意すべき最も重要な課題または制限事項:
知識のカットオフ - LLM のトレーニング コストが高いため、知識の本体は特定の時点でトレーニングされたものに制限されます。 プラグインやその他の便宜がなければ、リアルタイム情報にアクセスすることも、プライベート データにアクセスすることもありません。
幻覚 - LLM は統計的確率と少しのランダム性を使用して情報を生成します。 生成された応答を、質問の中の人間の意図とトレーニングされた情報に合わせて維持するメカニズムが用意されていますが、正確ではない応答を生成する可能性があります。
透明性 - ここでも、モデルのトレーニング方法により、トレーニングされた基本的な知識にアクセスできなくなります。 たとえそうであったとしても、情報が真実であり、最初に根拠があったという保証はありません。 さらに、生成された応答が正確であることを確認する検証手順はありません。
ドメイン固有の知識がない - "知識のカットオフ" と同様、社内専用の会社のドキュメントなどの個人情報がある場合、LLM はこの情報に関するトレーニングを受けなかったためドメイン固有の知識を持っていません。
LLM で発生する可能性のある課題や問題を軽減し、ユーザーと組織に役立つ最良の結果を得るには、どうすればよいでしょうか。 まず、LLM がデータを取得する場所を補う方法を理解することから始めます。
LLM が情報を取得する場所を理解する
LLM から最良の結果を得るための良い出発点として、LLM が情報を取得する場所や方法を理解できます。 次のカテゴリは、LLM がさまざまな情報ソースと対話して応答を生成する方法に関するさまざまなアプローチを表しています。
取得オフ生成 (ROG) - これは、生成プロセス中に外部情報にアクセスしたり取得したりすることなく、モデルがトレーニングされた知識のみに基づいて応答を生成する従来の方法である、LLM の動作方法です。 モデルの知識は静的であり、カットオフ日までのトレーニング データに含まれていたものに限定されます。 クリエイティブな文章に加えて、インターネット上で広く入手できる情報に関する質問に答えることができます。
取得拡張生成 (RAG) - LLM の生成機能と、外部データベースまたはドキュメントからリアルタイムで情報を取得する機能を組み合わせます。 このモデルは、外部ソースに対してクエリを実行して関連情報を検索し、その情報を使用して応答を通知します。 このアプローチにより、モデルは、事前トレーニング済みの知識だけで得た情報よりも正確で最新の情報を提供できます。 ユース ケースには、ファクト チェック、リアルタイム データまたはプライベートなドメイン固有のデータに基づく質問への回答などがあります。
取得中心の生成 (RCG) - 外部から取得されたコンテンツにさらに重点を置き、多くの場合、外部ソースからフェッチされた情報に関する応答を構造化します。 モデルは、取得されたテキストの大きなセグメントを出力に直接組み込み、ユーザーのクエリに合わせて編集したり、注釈を付けたりする場合があります。 このアプローチは、取得ベースの手法と生成手法のハイブリッドと見なすことができます。この場合、バランスは、モデル独自の生成機能よりも取得された情報を大きく優先する可能性があります。 ユース ケースには、長い文書の要約、複数の類似ドキュメント間での比較やテーマ別の調査を提供するための調査アシスタンス、さまざまな資料ソースを組み合わせて 1 つの出力にまとめることなどが含まれます。
取得オフ生成 (ROG) の良い例は ChatGPT です。 これに対し、必要に応じて、Copilot (Bing 経由で使用) はニュース ソースの外部ソースを使用して LLM を拡張します (また、それらのソースへのリンクを提供します)。
一見すると、外部情報を言語生成プロセスに統合する必要があるため、検索拡張生成 (RAG) と取得中心の生成 (RCG) は似ています。 ただし、生成プロセス内で取得した情報に優先順位を付け、それを利用する方法は異なります。
RAG システムでは、外部データ取得を使用して、事前トレーニング済みの言語モデルの生成機能が拡張されます。 取得された情報は、モデルが応答を通知するために使用するより多くのコンテキストまたは特定のデータを提供します。 ここでは、言語モデルの生成の側面が応答の中心であり続け、取得されたデータは精度や深さを高めるための補助要素として機能します。
一方、RCG システムでは、取得した情報自体に重点を置きます。 これらのシステムでは、多くの場合、取得されたデータは応答の中心であり、主に取得されたテキストを調整、書式設定、またはわずかに強化する生成モデルの役割があります。 このアプローチは、特に情報の正確さと直接的な関連性が最も重要であり、クリエイティブな合成や外挿が必要な場合に特に使用されます。
RAG と RCG の両方を動かすデータの外部取得のメカニズムについては、ドキュメントのベクトル化された埋め込みの保存と LLM の微調整に関する記事で説明されています。これらは、初期トレーニングに基づいて LLM に利用可能な知識を補足するための 2 つの一般的なアプローチです。
取得モデルの違いを理解すると、特定のアプリケーションに適したアプローチを選択する際に役立ち、クリエイティブな合成の必要性と、ソース マテリアルに対する精度および忠実性のニーズのバランスを取ることができます。
推論のしくみに影響を与える要因を理解する
ChatGPT の Web ベースのユーザー インターフェイスについてはよくご存じでしょう。質問に答える仕組みを理解することで、独自のアプリケーションで生成 AI 機能を構築するときに重要となる概念を理解することができます。
ユーザーが ChatGPT とチャットするとき、ユーザー インターフェイスの設計により、ユーザーと LLM の間で何度もやり取りが行われても状態が維持される、長時間実行されるチャット セッションのような印象が与えられます。 実際には、特定のチャット セッションでは、すべてのプロンプトと LLM のすべての応答 (完了とも呼ばれます) が新しいプロンプトごとに送信されています。 そのため、会話が増えるにつれて、以前のすべてのプロンプトと完了を処理するため、LLM にさらに多くのテキストが送信されます。 ChatGPT は、現在のプロンプトに対する応答を作成するとき、現在のプロンプトだけでなく、チャット セッション全体のコンテキストを使用します。 チャット セッション全体をコンテキスト ウィンドウと呼びます。
使用する ChatGPT のバージョンに応じて、コンテキスト ウィンドウの長さの制限があります。 コンテキスト ウィンドウの長さの制限を超えるチャット会話の一部は、最新のプロンプトへの応答を作成する際に無視されます。
最初は長い会話が良いアイデアのように思えるかもしれませんが、長いコンテキスト ウィンドウは、プロンプトを処理して完了を作成するのに必要な計算の量に影響を与える可能性があります。 これは、応答の待ち時間と、OpenAI が要求を処理するためのコストに影響を与えます。
ChatGPT のコンテキスト ウィンドウにはどのような制限があるのでしょうか? または、ChatGPT で使用できる単語の数はいくつでしょうか? コンテキスト ウィンドウの制限は、使用している LLM モデル、バージョン、エディションによって異なります。 さらに、コンテキストの長さは、単語ではなくトークンで測定されます。 トークンは、モデルが理解して生成できるテキストの最小単位です。 これらの単位には、単語、単語の一部 (音節や語幹など)、または個々の文字を指定できます。 トークンは、自然言語処理 (NLP) の中心です。
トークンの使用は、開発者にとって 2 つの重要な考慮事項に影響を与えます。
- コンテキスト ウィンドウの上限
- プロンプトおよび完了あたりの価格
トークン化とは
"トークン化" は、テキストをトークンに変換するプロセスです。 これは、LLM を使用してトレーニングまたは推論 (プロンプトに基づいて完了を作成するプロセス) 用にデータを準備するために重要な手順です。 このプロセスには、複雑なテキストを管理可能な部分 (トークン) に分割するなど、いくつかの手順が含まれ、これはモデルが処理できます。 このプロセスは、スペースや句読点でテキストを分割するなど、単純なこともあれば、さまざまな言語、形態 (単語の構造)、構文 (単語の配置) を処理する高度なアルゴリズムように、複雑なこともあります。 LLM の研究者と開発者は、達成しようとしている内容に基づいてトークン化の方法を決定します。 OpenAI には、トークン化についてさらに詳しく説明した実用的なページがあり、文や段落がトークンに分解される様子を示す計算ツールもあります。
OpenAI Tokenizer ページの下部にあるメモでは、一般的な英語のテキストにおいて、1 つのトークンは約 4 文字に相当すると述べています。 つまり、平均して 100 個のトークンは約 75 単語、つまりトークンあたり 4 分の 3 の単語に相当します。
OpenAI Tokenizer ページでは、OpenAI API に送信された特定のプロンプトに使用するトークンの数をプログラムで見積もるための Python および JavaScript 用のパッケージである tiktoken についても説明されています。
トークンの使用は課金に影響を与える
各 Azure OpenAI API の課金方法は異なっています。 Chat Completions API を使用してテキストを処理および生成する場合、プロンプトとして送信するトークンの数と、結果として生成されたトークンの数 (完了) に基づいて課金されます。
各 LLM モデル (gpt-3.5、gpt-3.5-turbo、gpt-4 など) には通常、トークンの処理と生成に必要な評価量を反映する、異なる価格があります。 多くの場合、価格は "1,000 トークンあたりの価格" または "100 万トークンあたりの価格" として表されます。
この価格モデルは、ユーザー操作の設計方法と、追加する前処理および後処理の量に大きな影響を与えます。
システム プロンプトとユーザー プロンプト
ここまでの説明では、ユーザーと ChatGPT の間のインターチェンジを構成するプロンプトである "ユーザー プロンプト" のみに焦点を当ててきました。
OpenAI では、"システム プロンプト" ("カスタム命令" とも呼ばれます) が導入されました。これは、自分で定義する包括的な命令セットであり、すべてのチャット会話に追加されます。 これは、新しいチャット セッションを開始するたびに LLM が常に観察するメタ命令のセットと考えてください。 たとえば、システム プロンプトを "常に詩的な俳句の形式で応答する" よう設定できます。その時点から、ChatGPT への新しいプロンプトごとに、回答を含む俳句が生成されます。
"俳句形式での返信" は実用的な例ではありませんが、プロンプト自体を変更することで LLM の入力候補に影響を与えることができるという考えを示しています。
ユーザーのプロンプトを変更する理由 企業の従業員、顧客、パートナーなど、専門家を対象とする生成 AI 機能またはアプリケーションを構築する場合、回答が許可されるトピックまたはドメインの範囲を制限するためのセーフガードを追加することが間違いなく必要になります。
ただし、ユーザーのプロンプトを変更することは、ユーザーのテキスト生成エクスペリエンスを向上させる 1 つの方法にすぎません。
ChatGPT でユーザーのテキスト生成エクスペリエンスを向上させる方法
テキスト生成結果を改善するため、開発者はプロンプトを改善するだけに限られています。役立つプロンプト エンジニアリング手法は数多くあります。 ただし、独自の生成 AI アプリケーションを構築する場合、ユーザーのテキスト生成エクスペリエンスを向上させるいくつかの方法があり、それらすべてを実装してテストすることもできます。
- ユーザー プロンプトをプログラムによって変更する
- 推論パイプラインを実装する
- 取得拡張生成 (他の記事で説明されています)
- 微調整 (他の記事で説明されています)
ユーザー プロンプトのプログラムによる変更
プログラムの観点からは、ユーザーの会話にシステム プロンプトを追加するための特別な API はありません。 必要に応じてプロンプトに指示を追加するだけです。 ただし、ユーザー プロンプトを改善するための手法がいくつかあります。
- コンテキスト プライミング: 目的のドメイン内で会話のコンテキストを明示的に設定するシステム プロンプトを作成します。 これには、各対話の開始時に簡単な説明または一連の指示を提供し、AI が問題ドメイン内に留まるようにガイドすることが含まれます。
- 例ベースのガイダンス: 初期プロンプトにドメインに関連する質問と回答の種類の例を含めます。 これは、予想される応答の種類を AI が理解するのに役立ちます。
さらに、すべてのプロンプト エンジニアリング手法を適用できます。 何らかの方法でプログラムでこれを実現できる場合、ユーザーの代わりにユーザーのプロンプトを改善できます。
このアプローチに対する注意事項は、プロンプトが長いほど、LLM への各呼び出しのコストが高くなることです。 それでも、これはおそらく、説明しているアプローチの中で最も安価です。
推論パイプラインの実装
ユーザーのプロンプトをプログラムによって変更する以外の次のステップとして、推論パイプライン全体を作成できます。
推論パイプラインは、生の入力 (テキストや画像など) を受け取り、それを "クリーンアップ" してから、主要なプロンプトを実行する (前処理) か、ユーザーに表示する前に完了をチェックしてユーザーのニーズを満たしていることを確認する (後処理) エンド ツー エンドのプロセスです。
前処理には、キーワードのチェック、関連性のスコアリング、または予想されるドメイン言語に適合するようクエリを変換することが含まれる場合があります。 たとえば、ユーザーが送信した初期プロンプトを分析し、プロンプトが意味をなしているか、受け入れ可能な範囲内であるか、誤った前提に基づいていないか、特定のバイアスを避けるために書き直す必要がないるかを、LLM に尋ねることから始めることができます。 LLM がプロンプトを分析し、問題が見つかった場合、さらに一歩進むことができます。LLM にプロンプトを再度入力して、回答を改善するよう依頼します。
後処理には、回答の関連性とドメインに対する妥当性の検証が含まれる場合があります。 これには、ドメイン要件に合わない回答の削除やフラグ設定が含まれる場合があります。 たとえば、LLM が提供する完了を調べて、品質と安全性の要件を満たしていることを確認できます。 LLM に回答の評価を依頼し、実際に準拠するように求めた要件を満たしているかどうかを確認できます。 満たしていない場合、LLM に完了を変更するよう依頼し、満足できる結果になるまでこれを繰り返すことができます。
前処理ステップの追加には 1 つの注意事項があります。推論パイプラインで LLM への呼び出しを追加するたびに、全体的な待ち時間 (応答時間) とユーザーとの各操作のコストが増加します。 経験豊富なソフトウェア開発者は、ソフトウェア システムの予算、パフォーマンス、有効性に影響を与えるリーダーシップによって行われる必要がある、このようなトレードオフを既に認識している可能性があります。
「高度な検索拡張生成システムの構築」では、推論パイプラインを構築する具体的な手順について詳しく説明されています。
完了に影響を与えるその他の要因
プロンプトのプログラムによる変更、推論パイプラインの作成、その他の手法について詳しくは、「取得拡張生成と微調整による大規模言語モデルの拡張」で詳しく説明されています。 さらに、Azure OpenAI API を呼び出すときに変更できるパラメーターもあります。
チャット エンドポイントのドキュメントには、完了のさまざまな側面に影響を与える可能性のある、渡す必須パラメーターとオプション パラメーターが掲載されています。 代わりに SDK を使用する場合、選択した言語の SDK ドキュメントをご覧ください。 パラメーターをテストする場合、プレイグラウンドで行うことができます。
温度: モデルによって生成される出力のランダム性を制御します。 0 の場合、モデルは決定論的になり、トレーニング データから最も可能性の高い次のトークンを一貫して選択します。 1 の温度では、高確率トークンの選択と出力へのランダム性の導入のバランスが、モデルによって調整されます。
最大トークン: 応答の最大長を制御します。 上限または下限を設定すると、生成されるコンテンツの詳細とスコープに影響を与える可能性があります。
トップ P (核サンプリング): 応答のランダム性を制御するために温度と共に使用されます。 トップ P では、各トークンを生成するとき、確率質量の上位 P% のみを考慮するよう AI が制限されます。 値を小さくすると、テキストの焦点がより絞られ、予測可能になり、値を大きくすると、テキストの多様性が高まります。
頻度ペナルティ: モデルが同じ行またはフレーズを繰り返す可能性を減らします。 この値を大きくすると、生成されたテキストの冗長性を回避するのに役立ちます。
プレゼンス ペナルティ: モデルが完了時に新しい概念と用語を導入することを促進します。 プレゼンス ペナルティは、より多様でクリエイティブな出力を生成するのに役立ちます。
シーケンスの停止: 1 つ以上のシーケンスを指定して、追加のトークンの生成を停止するよう API に指示できます。 ストア シーケンスは、文や段落の末尾で完了を終了するなど、出力の構造を制御するのに役立ちます。
ロジット バイアス: 指定したトークンが完了に表れる可能性を変更できます。 ロギット バイアスを使用すると、完了を特定の方向に導いたり、望ましくないコンテンツを抑制したりできます。
Microsoft OpenAI のセーフガードについて
LLM の応答を特定の主題またはドメインに限定することに加えて、ユーザーが LLM に尋ねる質問の種類についても考慮する必要があります。 生成される回答の種類を考慮することが重要です。
まず、Microsoft OpenAI Services への API 呼び出しにより、不快な可能性があるコンテンツが自動的にフィルター処理され、多くのフィルター カテゴリにわたって報告されます。
OpenAI の Moderation API を直接使用して、有害な可能性のあるコンテンツを明示的にチェックできます。
第 2 に、Azure AI Content Safety を使用して、テキスト モデレーション、画像モデレーション、ジェイルブレイク リスク検出、保護されたマテリアルの検出に役立ちます。 これにより、ポータルのセットアップ、構成、レポート エクスペリエンスと、アプリケーションに追加して有害なコンテンツを識別できるコードが組み合わされます。
アプリケーション設計の決定に影響を与える可能性がある最終的な考慮事項
トークン化、価格、コンテキスト ウィンドウについて理解し、プログラムによる改善を実装してユーザーのテキスト生成エクスペリエンスを強化すると、生成 AI システムの設計方法に影響を与えます。 アプリケーションの設計上の決定に影響を与える、この記事で考慮すべき事項とその他のポイントの簡単な一覧を以下に示します。
- コストの考慮事項に対して、最新の AI モデルを使用する必要性を評価します。 パフォーマンスと予算の制約のバランスをとると、より安価なモデルでもアプリケーションのニーズを満たすことができる可能性があります。
- ユーザー エクスペリエンスに大きな影響を与えずにコストを管理するため、コンテキスト ウィンドウの長さを最適化することを検討してください。 会話の不要な部分をトリミングすると、品質の対話を維持しながら、処理料金を節約できる可能性があります。
- トークン化と入力と出力の粒度がパフォーマンスに与える影響を評価します。 選択した LLM がトークン化をどのように処理するかを理解することで、API 呼び出しの効率を最適化して、コストを削減し、応答時間を向上させることができます。
生成型 AI ソリューションの構築の実験をすぐに開始する場合は、「Python 用の独自のデータ サンプルを使用してチャットを開始する」を参照することをお勧めします。 このチュートリアルには、.NET、Java、JavaScript でも使用できるバージョンがあります。