タスクを完了するために大規模言語モデル (LLM) を複数回呼び出す必要がある生成 AI アプリケーションを構築する場合、よくある問題は、LLM へのクエリを繰り返すとコストがかかり、予測不能になる可能性があることです。 GPT-3.5/4 などの大規模モデルは、推論のトレーニングと実行に非常に多くのリソースを消費します。これは、API 料金やサービスの時折の中断に反映されます。 ChatGPT はもともと研究プレビューとしてリリースされ、運用アプリケーションでの使用を意図していませんでした。しかし、膨大な数のアプリケーションにわたってその有用性には議論の余地がないため、 LLM への関心が爆発的に高まっています。
ChatGPT の開始以来、ユーザーは、GPT 使用時のプライバシーの欠如と稼働時間や推論設定を制御できないことを回避する方法を探してきました。これにより、Meta のLlama 2などの無料の公開モデルの人気が高まり、その後、消費者向けハードウェアで実行できる量子化された低パラメータ バージョンの Llama が作成されるようになりました。これらのパブリック モデルは、より少ない計算能力で GPT とほぼ同じ機能を提供できますが、パラメーターと詳細な出力は少なくなります。
アプリケーションが過度に大規模なコンテキストの処理や詳細な出力の生成に必ずしも依存していない場合は、制御するインスタンス上で独自の推論をホストすることが、よりコスト効率の高いオプションとなる可能性があります。そして、 検索拡張生成(RAG) の実世界のアプリケーションとなると、コストの差はさらに大きくなる可能性があります。
ベクトル ストア、語彙検索、およびプロンプト エンジニアリングを組み合わせて、汎用ハードウェアで正確な RAG を実行する簡単な方法を示します。この方法を使用すると、大量の情報の複雑さを軽減し、生成 AI アプリケーションをより正確で効率的かつコスト効率よく大規模に実行できるようになります。特定の情報ストアで RAG を使用すると、サードパーティ API に料金を支払うことなく、幻覚を排除し、あらゆるソース素材から効果的で知識豊富なエージェントを作成できるようになります。
開始するには、ベクターとテキストデータを保存するための DataStax Enterprise 7 インスタンスまたはDataStax Astra DBのいずれかが必要です。また、応答を生成し、データをベクターでエンコードするための LLM および文変換モデルも必要です。データまたはユーザープロンプトの複雑さに応じて、これを、より広範囲のデータに一致するSolr検索を実行できるDataStax Enterprise 6.8データベースと組み合わせることを検討することもできます。この例ではこれを使用しました。 DataStax は、これらすべての操作を 1 つのデータベースで実行できるように継続的に改善に取り組んでいますが、現時点では 2 つのデータベースを使用しています。
幻覚の解決
どの LLM を選択しても、依然として幻覚に悩まされています。現時点では、RAG とも呼ばれる LLM へのプロンプトのコンテキストに真実の情報を入力することで、この制限を解決する必要があります。情報を見つけてプロンプト用に変換する方法は、データ モデルによって完全に異なりますが、ベクトル データベースを使用すると、より効率的な方法でより適切な情報を見つけることができます。
たとえば、ウォーハンマー 40,000 のプレイ方法など、調べたいテーマに関する電子書籍のコレクションがあるとします。通常の状況では、裏付けとなる文献を読み、専門家レベルに達するのに十分なゲームプレイ経験を積むには何年もかかります。
「アデプタ ソロリタスのモルベン ヴァールについて何か教えてください。」などの的を絞った質問。ベテラン プレイヤーかウォーハンマー ストアの従業員が答えるのが最善でしょう。 ChatGPT はゲームに関する多くの質問に答えることができますが、残念ながら、この特定のキャラクターをカバーするトレーニング データはありません。
これを、Nvidia RTX A4000 グラフィックス カードを搭載したコンシューマ ワークステーションでホストされている Llama 2 13B パラメータ LLM と比較してください。同様に、モデルはウォーハンマー ユニバースの基本的な知識を実証できますが、調整により、モデルはキャラクターが見つからないことを気にせず、代わりにベストエフォート型の幻覚を提供します。
初心者とベテランの両方がウォーハンマー 40,000 をプレイするのに役立つチャットボットを構築したい場合、これらの出力は受け入れられません。効果的なゲーム ガイドになるためには、チャットボットがゲームのルール、各ユニットのルール、伝承の一部、戦略と解説を知っている必要があります。幸いなことに、第 10 版ルールに関する情報はすべて、Games Workshop やファン Web サイトから無料で入手でき、チャットボット アプリで検索できるようにするだけで済みます。
これを同じ 13B Llama モデルと比較します。RAG では、Morvenn Vahl に関するいくつかのソースを比較し、ユーザーのプロンプトに基づいて関連する回答を考案することが求められます。今回、チャットボットは、ウォーハンマー 40,000、第 10 版のプレイ方法に関するすべての公開情報が満載された検索データベースとベクターデータベースにアクセスできます。
なんという違いでしょう！このニッチなキャラクターに関する関連情報を見つけるだけでなく、第 10 版のルールでゲームをプレイする方法のコンテキストに沿った出力を維持します。
このすべての中で最も難しいのは、LLM にフィードする関連ページを見つけるために効果的な検索を実行することです。このような場合に、ベクトル データベースが特に役立ちます。
ベクトルの適用
この例では、Docker インスタンスで実行されている DSE 7 と DSE 6.8 を使用して、ベクトルを比較し、語彙検索を実行できる必要があるチャットボット アプリケーションのデータベース要件を満たすようにします。 DSE 7 と Astra DB には、ベクトルを保存し、ベクトル検索を実行する機能と、テキスト一致によるフィルタリング機能が導入されました。この例については数十冊の書籍を検索するだけで済むため、ほとんどのコンシューマ ハードウェアでは Docker で DSE インスタンスを実行するだけで十分です。
データベースでベクトルを使用すると、特定のクエリに類似したドキュメントを検索したり、別の検索で取得した結果を比較するために使用したりできます。これは、字句検索の制限を克服し、データ モデルの有効性を向上させるのに役立ちます。
たとえば、電子書籍 PDF のようなものは、 miniLMのような文変換機能を使用してエンコードすることで利点が得られ、ベクトルを使用してクエリと特定のソース間の類似性比較を実行できます。この場合、センテンス トランスフォーマー モデルを使用して、電子書籍内のページのテキストの埋め込みを作成します。これにより、ユーザーのプロンプトと比較して、結果がクエリに関連しているかどうかを判断できるようになります。関連するページには、ユーザーのクエリに類似した用語のインスタンスが 1 つ以上含まれている必要があり、モデルの観点からより高い類似性スコアが得られます。
そうは言っても、ベクトルは既存の語彙検索モデルへの補足として適用するのが最適です。ベクトルのみで検索すると、無関係なドキュメントが予期せず取得され、それらが適用されないコンテキストとして提供されてしまう可能性があります。
この例では、「Adepta Sororitas の Morvenn Vahl について何を教えていただけますか?」というクエリが表示されます。 LLM によって単純な検索語のセットに変換できます。
Morvenn, Vahl, Adepta, Sororitas
関連するドキュメントを見つけるための最初のステップは、これらの基本用語を含むドキュメントを検索することです。これは、最初にデータベース内のテキスト一致をフィルタリングして、そのようなクエリに一致するページ テキスト内のキーワードを見つけることによって実行できます。 LLM を使用してキーワードを生成する理由は、関連するけれども元のプロンプトのテキストには含まれていないキーワードをさらに追加しようとすることが多いため、検索できるキーワードの範囲を広く提供するためです。ただし、LLM はサニタイズが必要な特殊文字や奇妙なシーケンスも生成する可能性があるため、これには注意してください。
少なくとも 1 つの結果が得られたら、ユーザーのクエリをベクトル化し、それを語彙検索のベクトルと比較して、各結果の関連性のスコアを作成できます。これにより、最終的に結果を LLM に提示する際に、クエリに対する検索結果の正確性をチェックし、無関係な結果を拒否するためのしきい値を設定できます。
この場合、最初のステップは、特に Morvenn Vahl のインデックス カードまたはゲームプレイ メカニクスを示すページと一致する必要があります。これらのページは、ゲーム内でどのようにプレイするかという点でキャラクターのユニットを説明しているからです。ページが、アプリケーションによって決定されたユーザー クエリに対する特定の関連性のしきい値を満たしている場合、そのページは要約され、結果のリストに配置されます。
最後に、検索結果をリストにコンパイルして LLM にフィードバックすることができ、LLM では元のクエリに答えるために最も関連性の高いコンテキストを使用するよう求められます。フローを視覚化すると次のようになります。
ご覧のとおり、このフローでは LLM がかなり頻繁に呼び出されます。 LLM は、ユーザー プロンプトをキーワードに変換し、該当する結果を要約し、クエリに最もよく答えるコンテキストを選択する責任を負います。チェックするソースごとに別の LLM 呼び出しが追加されるため、GPT にクエリを実行するときに非常にコストがかかる可能性があります。ただし、必要な情報がすでにあり、それを要約したり変換したりしたいだけの場合は、これほど大規模なモデルを使用する必要はないかもしれません。実際、小型モデルに切り替えると多くのメリットが得られます。
より小さい LLM を使用すると、各クエリの計算コストを削減でき、時間の経過とともに大幅な節約につながる可能性があります。これにより、ユーザーの応答時間が短縮され、全体的なエクスペリエンスが向上する可能性があります。この例では、小規模な LLM と小規模なデータベースを使用して RAG が実行され、すべて同じ GPU インスタンス上でホストされています。15 個のソースを取得し、それらの関連性を分析して、最終的な答えを提供するのに約 30 秒かかります。また、プロンプト (ソース) が短いほど、出力をより速く返すことができます。
さらに、この方法により、セキュリティとスケーラビリティが向上します。迅速なエンジニアリングと LLM への呼び出しのパイプラインにより、データへのアクセス方法とユーザーの応答で何を取得するかを完全に制御できます。リソース使用量の観点から見ると、サンプル 13B パラメータ モデルは VRAM を 8GB 強しか消費しないにもかかわらず、適切な答えを提供します。これは、ニーズに応じて、ユーザーのワークステーションやモバイル デバイスなど、他の無数のプラットフォームでも RAG を実行できる可能性を示しています。
出力の制御
RAG を希望どおりに実行するには、迅速なエンジニアリングが鍵となります。チャットボットがデータをどのように解釈するか、またチャットボットがどのようなコンテキストを考慮するかを制御できます。この例では、特に Warhammer 情報を求めていることをチャットボットに認識させたいので、最初にユーザーのクエリにサポートするコンテキストを提供するようチャットボットに依頼できます。
クエリ: 「<ユーザークエリ>」
検索エンジン用の最小限のウォーハンマー 40K キーワードのカンマ区切りリストを教えてください。クエリのみで応答します。絵文字や特殊文字は使用しないでください。
答え：
ウォーハンマー 40,000 には、関連性のない他の大衆文化に登場する可能性のある用語や名前がたくさんあるため、最初のクエリで RAG のコンテキストを設定することが重要です。このコンテキストは、アプリケーションが複数のコンテキストをカバーする場合 (たとえば、ウォーハンマー ゲーム ルールの複数の版をカバーする必要がある場合、またはそれらを公式の伝承本と組み合わせる必要がある場合) に選択または変更できるものである必要があります。
この実験では、ユーザーのクエリは常に引用符でカプセル化されることに注意してください。これは、LLM が直接応答しようとしているクエリと、直接応答してはいけない別のプロンプト エンジニアリング命令とを区別するのに役立ちます。プロンプトの質問と回答の部分は、特定のコンテキストに合わせて調整できますが、ほとんどの場合、LLM に直接応答すべきこととすべきでないこと、および応答方法を通知するだけで十分です。
この場合、シリーズはそれなりに人気があり、一般的な情報は無料で入手できるため、LLM がゲーム世界に関する一般的な知識を持っていると想定するのが安全です。この最初のクエリの出力は、アプリケーションにチートシートを組み込むことなく、語彙検索で使用するキーワードを生成するのに役立ちます。
その後、字句比較とベクトル比較がバックグラウンドで実行され、LLM によるレビューのために結果のリストが編集されます。最初のステップでは、ユーザーの元のプロンプトに推論で直接回答することは決してないため、LLM は検索で見つかったものを変換するだけであり、ガード レールまたはナレッジ ベースの外でクエリに回答するのを簡単に停止できます。
検索結果に関連する結果がある場合:
クエリ: 「<ユーザークエリ>」
これらの検索結果を確認し、クエリに答えるために使用します。
結果1
結果 2
等
答え：
検索で関連する結果が見つからない場合:
クエリ: 「<ユーザークエリ>」
検索したものの、質問に対する答えが見つからなかったと丁寧に伝えてください。代わりに、あなたの知識の限りで答えてください。
答え：
セキュリティを強化するために、リクエストを処理できない場合はリクエストを完全に拒否またはリダイレクトできます。
クエリ: 「<ユーザークエリ>」
検索したが質問に対する答えが見つからなかったと丁寧に伝えてください。代わりにカスタマー サポート チームに連絡して支援を求めるように指示してください。
答え：
さらに詳細を尋ねることで、出力を長くすることもできます。ソース素材をコンテキスト ウィンドウ内に収めることができる限り、LLM がそれを変換できます。
クエリ: 「<ユーザークエリ>」
これらの検索結果を確認し、クエリに答えるために使用します。できるだけ詳しく、出典を明記してください。
結果1
結果 2
等
答え：
制限事項
LLM のコンテキスト ウィンドウは限られているため、非常に大きなページのテキストを処理できません。データの管理が容易になり、LLM による処理が容易になるように、行サイズに制限を設けることを検討してください。たとえば、ページを約 1,000 文字の塊に分割するのはうまくいくようですが、プロンプトに 4 つまたは 5 つ以上の詳細な回答を入力することは避けてください。
LLM には、コンテキスト ウィンドウに表示できる内容以外の会話の記憶がありません。会話データの永続的なストアを構築することは可能ですが、LLM が過度に大規模な会話や詳細なコンテキストをプロンプトに適合させることはできません。変身できるものには上限があります。これは、たとえコンテキストとして提供されていたとしても、特定の時点で、LLM が特定の詳細を「忘れている」ように見えることに気づくことを意味します。これは、このツールの固有の制限にすぎません。短い会話の場合にのみ使用し、幻覚を最小限に抑えるために一度に少量のテキストを変換することに集中するのが最善です。
LLM のランダム性が問題になる場合があります。どのプロンプトがデータセットに最適に機能するかを判断し、どのモデルがユースケースに最適に機能するかを判断するには、テストとチューニングが必要です。 13B パラメータ モデルを使用したテストでは、特にプロンプトの長さが長くなると、最初のプロンプトからどの検索キーワードが生成されるかについて、多くの予測不可能性がありました。最良の結果を得るには、プロンプトを短くしてください。
結論
要約すると、ベクトル検索モデルと語彙検索モデルを組み合わせて RAG を活用すると、関連する結果をより効果的に検索して並べ替え、幻覚が起こりにくいエージェント出力を生成できるようになります。検索可能なコンテキストが小さいほど、応答はより正確かつ正確になります。 LLM 呼び出しの独自のカスタム パイプラインを構築すると、希望する精度とガード レールのレベルに合わせて応答を調整する際の柔軟性が大幅に高まります。
限られたコンテキスト ウィンドウ内で過度に大量のデータを処理することはできませんが、限られた知識ベースで効果的なアシスタントを作成したり、以前と同じか、以前よりも少ないハードウェアでより多くのエージェントを同時に実行したりする機能を提供します。これにより、テーブルトップ ゲームなどのアプリケーション向けの仮想アシスタントの可能性がさらに広がり、政府、法律事務所、会計事務所、科学研究、エネルギーなどで使用されるより複雑なトピックもカバーできる可能性があります。
構築を開始する準備ができている場合は、 Astra DB を無料で試すことができます。クラウドやデータベース運用の経験は必要なく、今すぐデータベースを作成して RAG ソースのロードを開始できます。
マリオ・チャーネル・デルガド著、DataStax
ここでも公開されています。
