ジェネレーティブ AI ソリューションを構築するための主要な概念と考慮事項
大規模な言語モデル (LLM) は驚くべきものですが、制限があります。 開発者は、これらの制限事項、"すぐに使用できる" LLM の機能、および構築する生成型 AI ソリューションに最適な結果を得るためにそれらを変更する方法を理解する必要があります。 この記事では、LLM のいくつかの課題と制限要因について説明します。 アプリケーションに組み込む生成 AI 機能の種類に関係なく、課題を克服し、コンテンツ生成プロセスを制御する一般的な方法について説明します。
LLM を使用するときのエンジニアリングの課題
次の一覧は、LLM を使用する際に注意すべき最も重要な課題または制限事項をまとめたものです。
知識のカットオフ: LLM のトレーニングコストが高いため、LLM の知識の本文は、ある時点でトレーニングされたものに制限されます。 プラグインやその他の宿泊施設がない場合、LLM はリアルタイム情報にアクセスできないため、プライベート データにアクセスできません。
幻覚: LLM は統計的確率と少しランダム性を使用して情報を生成します。 生成された応答を、質問された質問や LLM がトレーニングされた情報の人間の意図に合わせて維持するためのメカニズムが用意されていますが、LLM では正確ではない応答を作成できます。
透明性: また、LLM のトレーニング方法により、トレーニングされた基本的な知識にアクセスできなくなります。 たとえそうであったとしても、情報が真実であり、最初に根拠があったという保証はありません。 また、生成された応答が正確であることを確認するための検証手順はありません。
ドメイン固有の知識がない: 知識のカットオフと同様、社内専用の会社のドキュメントなどの個人情報がある場合、LLM はこの情報に関するトレーニングを受けませんでした。 ドメイン固有のデータに関する知識がありません。
LLM で発生する可能性のある課題や問題を軽減し、ユーザーと組織に役立つ最良の結果を得るには、どうすればよいですか? まず、LLM がデータを取得する場所を補足する方法を理解します。
LLM が情報を取得する場所
LLM から最良の結果を得るための良い出発点は、LLM が情報を取得する場所や方法を理解することです。 次のカテゴリは、LLM がさまざまな情報ソースと対話して応答を生成する方法に関するさまざまなアプローチを表しています。
リトリーバル・オフ・ジェネレーション (ROG): 従来の LLM はこのモデルを利用しています。 モデルは、生成プロセス中に外部情報にアクセスしたり取得したりすることなく、トレーニングされた知識のみに基づいて応答を生成します。 モデルの知識は静的であり、カットオフ日までのトレーニング データに含まれていたものに限定されます。 創造的な書き込みに加えて、インターネット上ですぐに利用できる情報に関する質問に答えることができます。
取得拡張生成 (RAG): LLM の生成機能と、外部データベースまたはドキュメントからリアルタイムで情報を取得する機能を組み合わせます。 このモデルは、外部ソースに対してクエリを実行して関連情報を検索します。 その後、情報を使用して応答を形成します。 このアプローチにより、モデルは、事前トレーニング済みの知識だけを使用して得た情報よりも正確で最新の情報を提供できます。 ユース ケースには、ファクト チェック、リアルタイム データに基づく質問への回答、プライベートなドメイン固有のデータに基づく質問への回答などがあります。
取得中心生成 (RCG): 外部から取得されたコンテンツにさらに重点を置き、多くの場合、外部ソースからフェッチされた情報に関する応答を構造化します。 モデルは、取得されたテキストの大きなセグメントを出力に直接組み込み、ユーザーのクエリに合わせて編集または注釈を付ける場合があります。 このアプローチは、取得ベースのメソッドと生成メソッドのハイブリッドと見なすことができます。この場合、バランスは、モデル独自の生成機能よりも取得された情報を大きく優先する可能性があります。 使用例には、長いドキュメントの要約、複数の類似したドキュメント間の比較やテーマの探求を行う調査支援、さまざまな資料ソースをコンパイルまたは照合して組み合わせた出力をすることが含まれます。
ROG の良い例は ChatGPT です。 これに対し、Copilot (Bing 経由) は、ニュース ソースの外部ソースを使用して (およびそれらのソースへのリンクを提供することによって) LLM を拡張します。
一見すると、RAG と RCG は、外部情報を言語生成プロセスに統合する必要があるため、似ています。 ただし、生成プロセスで取得した情報に優先順位を付けて使用する方法は異なります。
RAG システムでは、外部データ取得を使用して、事前トレーニング済み言語モデルの生成機能
RCG システムでは、取得された情報自体に重点が置かれています。 RCG システムでは、多くの場合、取得されたデータは応答の中心
RAG と RCG の両方を強化するデータを外部から取得するためのメカニズムについては、ドキュメントのベクター化された埋め込みの格納と LLM の微調整に関する記事で説明されています。LLM の初期トレーニングに基づいて LLM が利用できる知識を補完するための 2 つの一般的なアプローチです。
取得モデルの違いを理解することは、特定のアプリケーションに適したアプローチを選択するのに役立ちます。 クリエイティブ合成の必要性と、ソース マテリアルに対する精度と忠実性のバランスを取るのに役立ちます。
推論のしくみに影響を与える要因
ChatGPT の Web ベースのユーザー インターフェイスに慣れている可能性があるため、質問に答えるしくみを理解することは、独自のアプリケーションで生成型 AI 機能を構築する際に不可欠な概念を理解するのに役立ちます。
ユーザーが ChatGPT とチャットすると、ユーザー インターフェイスの設計により、ユーザーと LLM の間で何度かやり取りを行う過程で状態を維持する長時間のチャット セッションの錯覚が生まれます。 実際には、特定のチャット セッションでは、すべてのプロンプトとすべての LLM 応答 (入力候補とも呼ばれます) が新しいプロンプトごとに送信されます。 会話が増えるにつれて、処理するために LLM に送信されるテキストが増えます。 新しいプロンプトごとに、以前のすべてのプロンプトと完了を送信します。 ChatGPT は、現在のプロンプトに対する応答を作成するときに、現在のプロンプトだけでなく、チャット セッション全体のコンテキストを使用します。 チャット セッション全体を コンテキスト ウィンドウと呼びます。
コンテキスト ウィンドウには、使用する ChatGPT のバージョンによって異なる長さの制限があります。 チャット会話のコンテキスト ウィンドウの長さの制限を超える部分は、ChatGPT が最新のプロンプトへの応答を作成するときに無視されます。
長い会話は最初は良い考えのように思えるかもしれませんが、長いコンテキスト ウィンドウは、プロンプトの処理と完了の作成に必要な計算量に影響する可能性があります。 コンテキスト ウィンドウのサイズは、応答の待機時間と、OpenAI が要求を処理するためのコストに影響します。
ChatGPT のコンテキスト ウィンドウの制限とは つまり、ChatGPT で使用できる単語の数はいくつですか?
コンテキスト ウィンドウの制限は、使用している LLM モデル、バージョン、エディションによって異なります。 さらに、コンテキストの長さは、単語ではなくトークンで測定されます。 トークンは、モデルが理解して生成できるテキストの最小単位です。 これらの単位には、単語、単語の一部 (音節や茎など)、または個々の文字を指定できます。 トークンは、自然言語処理 (NLP) の中心にあります。
トークンの使用は、開発者にとって 2 つの重要な考慮事項に影響します。
- コンテキスト ウィンドウの上限
- プロンプトおよび完了あたりの価格
トークン化とは
トークン化 は、テキストをトークンに変換するプロセスです。 これは、LLM を使用してトレーニングまたは推論 (プロンプトに基づいて完了を作成するプロセス) 用にデータを準備する上で重要な手順です。 このプロセスには、複雑なテキストを管理可能な部分 (トークン) に分割するなど、いくつかの手順が含まれ、モデルで処理できます。 このプロセスは、スペースや句読点でテキストを分割するなどの単純な場合や、さまざまな言語、形態 (単語の構造)、構文 (単語の配置) を処理する高度なアルゴリズムを含む複雑な場合があります。 LLM の研究者と開発者は、達成しようとしている内容に基づいてトークン化の方法を決定します。
OpenAI トークナイザーの ページでは、トークン化の詳細について説明しています。 ページには、文や段落がトークンにどのように分割されるかを示す電卓も含まれています。
OpenAI トークナイザー ページの下部にあるメモが示すように、一般的な英語のテキストでは、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 の生成結果に影響を与えることができるという考えを示しています。
ユーザーのプロンプトを変更する理由 会社の従業員、顧客、パートナーを含む可能性があるプロの対象ユーザー向けの生成型 AI 機能またはアプリケーションを構築する場合は、回答できるトピックまたはドメインの範囲を制限するセーフガードを追加することが間違いなく必要です。
ただし、ユーザー プロンプトの変更は、ユーザーのテキスト生成エクスペリエンスを向上させるための 1 つの方法にすぎません。
ChatGPT のユーザーのテキスト生成エクスペリエンスを向上させる方法
テキスト生成の結果を改善するために、開発者は単にプロンプトを改善することに限定されており、役立つプロンプト エンジニアリング手法が多数あります。 ただし、独自の生成型 AI アプリケーションを構築する場合は、ユーザーのテキスト生成エクスペリエンスを向上させるいくつかの方法があり、それらのすべてを実装して実験する必要があります。
- プログラムによってユーザー プロンプトを変更します。
- 推論パイプラインを実装します。
- Retrieval-Augmented 世代 (他の記事で説明)。
- 微調整 (他の記事で説明)。
プログラムによってユーザー プロンプトを変更する
ユーザーの会話にシステム プロンプトを追加するには、特別な API を使用しません。 必要に応じて、プロンプトに指示を追加するだけです。
ただし、いくつかの手法を使用して、ユーザー プロンプトを改善できます。
- コンテキスト プライミング: ドメイン内の会話のコンテキストを明示的に設定するシステム プロンプトを作成します。 このアプローチでは、各操作の開始時に簡単な説明または一連の手順を提供します。 この手順では、AI が問題のドメイン内に留まるようにガイドします。
- サンプル ベースのガイダンス: 最初のプロンプトに、ドメインに関連する質問と回答の種類の例を含めます。 このアプローチは、AI が期待する応答の種類を理解するのに役立ちます。
任意のプロンプト エンジニアリング手法を使用できます。 プログラムで実行できる場合は、ユーザーの代わりにユーザー プロンプトを改善できます。
この方法に対する注意事項は、プロンプトが長いほど、LLM への各呼び出しのコストが高くなることです。 それでも、この方法は、この記事で説明する最も安価なアプローチである可能性があります。
推論パイプラインを実装する
ユーザーのプロンプトをプログラムで変更する以外の次の手順は、推論パイプライン全体を作成することです。
推論パイプライン は、生の入力（テキストや画像など）を処理して基本プロンプトを実行する前にデータを整える「前処理」や、結果を完成させてユーザーのニーズを満たしているかを確認する「後処理」を行う一連のプロセスです。
前処理には、キーワード のチェック、関連性スコア付け、またはクエリを変換して、想定されるドメイン言語に合わせる必要があります。 たとえば、ユーザーが送信した最初のプロンプトを分析できます。 まず、プロンプトが適切かどうか、受け入れる対象の境界内にあるかどうか、障害のある前提に基づいている場合、または特定のバイアスを回避するために書き換える必要があるかどうかを LLM に尋ねます。 LLM がプロンプトを分析し、問題を検出した場合は、さらに一歩進むことができます。 LLM にプロンプトを書き換えて、潜在的に回答を改善するように依頼できます。
後処理には、ドメインに対する回答の関連性と妥当性の検証が含まれる場合があります。 これには、ドメインの要件に合わない回答の削除やフラグ設定が含まれる場合があります。 たとえば、LLM が提供する生成結果を調べて、それが品質と安全性の要件を満たしていることを確認できます。 LLM に回答の評価を依頼して、実際に準拠するように求められた要件を満たしているかどうかを確認できます。 そうでない場合は、LLM に完了の変更を依頼することができます。 満足のいく結果が得られるまで、これらの手順を繰り返します。
前処理手順の追加には 1 つの注意事項があります。推論パイプラインで LLM への呼び出しを追加するたびに、全体的な待機時間 (応答する時間) とユーザーとの各操作のコストが増加します。 経験豊富なソフトウェア開発者は、ソフトウェア システムの予算、パフォーマンス、有効性に影響を与えるこのようなトレードオフを既に認識している可能性があります。
推論パイプラインを構築するために実行する具体的な手順については、「高度な取得拡張生成システムを構築する」を参照してください。
完了に影響を与えるその他の要因
プロンプトのプログラムによる変更、推論パイプラインの作成、その他の手法に加えて、取得拡張生成と微調整を使用した大規模言語モデルの拡張に関するページで詳しく説明します。 また、Azure OpenAI API を呼び出すときにパラメーターを変更することもできます。
完了のさまざまな側面に影響を与える可能性のある必須パラメーターと省略可能パラメーターを確認するには、チャットエンドポイントのドキュメントを参照してください。 SDK を使用している場合は、使用する言語の SDK ドキュメントを参照してください。 Playgroundでパラメーターを試すことができます。
Temperature: モデルによって生成される出力のランダム性を制御します。 0 の場合、モデルは決定論的になり、トレーニング データから最も可能性の高い次のトークンを一貫して選択します。 1 の温度では、高確率トークンの選択と出力へのランダム性の導入のバランスがモデルによって調整されます。Max Tokens: 応答の最大長を制御します。 上限または下限を設定すると、生成されるコンテンツの詳細とスコープに影響を与える可能性があります。Top P(核サンプリング): 応答のランダム性を制御するためにTemperatureと共に使用されます。Top Pでは、各トークンを生成するときに、AI が確率質量 (P) の上位パーセントのみを考慮するように制限されます。 値を小さくすると、テキストのフォーカスが高くなり、予測しやすくなります。 値が大きいほど、多様性が高くなります。Frequency Penalty: モデルが同じ行または語句を繰り返す可能性を減らします。 この値を大きくすると、生成されたテキストの冗長性を回避できます。Presence Penalty: モデルに、完成時に新しい概念と用語を導入するよう奨励します。Presence Penaltyは、より多様でクリエイティブな出力を生成するのに役立ちます。Stop Sequences: 1 つ以上のシーケンスを指定して、より多くのトークンの生成を停止するように API に指示できます。Store Sequencesは、文や段落の末尾で完了を終了するなど、出力の構造を制御するのに役立ちます。Logit Bias: 指定したトークンが完了に表示される可能性を変更できます。Logit Biasを使用して、完了を特定の方向に導いたり、特定のコンテンツを抑制したりできます。
Microsoft OpenAI セーフガード
LLM の回答を特定の主題またはドメインに限定したままにすることに加えて、ユーザーが LLM について尋ねている質問の種類についても懸念される可能性があります。 生成される回答の種類を考慮することが重要です。
まず、Microsoft OpenAI Services に対する API 呼び出しでは、API が不快感を与える可能性があるコンテンツが自動的にフィルター処理され、多くのフィルターカテゴリで報告されます。
OpenAI Moderation API を直接使用して、有害な可能性のあるコンテンツがないかコンテンツを直接確認できます。
その後、Azure AI Content Safety を使用して、テキスト モデレーション、画像モデレーション、脱獄リスク検出、保護された素材の検出に役立ちます。 これにより、ポータルのセットアップ、構成、レポートエクスペリエンスと、アプリケーションに追加して有害なコンテンツを識別できるコードが組み合わされます。
アプリケーション設計に関する最終的な考慮事項
トークン化、価格、コンテキスト ウィンドウについて理解し、プログラムによる改善を実装してユーザーのテキスト生成エクスペリエンスを強化することは、生成 AI システムの設計方法に影響します。
アプリケーションの設計上の決定に影響を与える可能性がある、この記事で考慮すべき事項とその他のポイントの簡単な一覧を次に示します。
- コストに関する考慮事項に対して、最新の AI モデルを使用する必要性を評価します。 コストの低いモデルは、アプリケーションのニーズに十分な場合があります。 パフォーマンスと予算の制約のバランスを取る。
- ユーザー エクスペリエンスに大きな影響を与えずにコストを管理するために、コンテキスト ウィンドウの長さを最適化することを検討してください。 会話の不要な部分をトリミングすると、品質の対話を維持しながら、処理料金が削減される可能性があります。
- トークン化と入力と出力の粒度がパフォーマンスに与える影響を評価します。 選択した LLM がトークン化をどのように処理するかを理解することで、API 呼び出しの効率を最適化し、コストを削減し、応答時間を向上させることができます。
生成型 AI ソリューションの構築の実験をすぐに開始する場合は、「Python用の独自のデータ サンプルを使用してチャットを開始する」を参照することをお勧めします。 このチュートリアルは、