『Retrieval-Augmented GenerationとSelf-Hosted LLMsから期待されること』
「『Retrieval-Augmented GenerationとSelf-Hosted LLMsの期待されるポイント』」
リトリーバル拡張生成（RAG）は、外部の知識ベースから取得した情報をLLMと統合するためのAIフレームワークです。RAGに対する注目が最近高まっていることからも、RAGはAI/NLP（人工知能/自然言語処理）エコシステムで注目されるトピックであると結論付けることは合理的です。したがって、自己ホスト型のLLMと組み合わせた場合のRAGシステムの期待値について議論してみましょう。
「リトリーバル拡張生成とパフォーマンス向上を発見する」というブログ記事では、取得したドキュメントの数がLLMの回答の品質を向上させる方法を調査しました。また、コンテキストに関連する知識とデータセットのファインチューニングなしでベクトル化されたMMLUデータセットに基づくLLMが、MyScaleなどのベクトルデータベースに統合されると、より正確な応答が生成されることも説明しました。
したがって、要点は以下の通りです:
RAGは外部データを用いてプロンプトを増強し、知識のギャップを埋めることで誤謬を減らす。
アプリケーションで外部のLLM APIを使用することは、データセキュリティに潜在的なリスクをもたらし、制御を減少させ、特に高いユーザー数の場合はコストを大幅に増加させる可能性があります。したがって、疑問となるのは次のような問いです:
より高いデータセキュリティとシステムの制御をどのように確保できるのでしょうか？
簡潔な答えは、自己ホスト型のLLMを使用することです。このアプローチは、データとモデルに対する優れた制御を提供するだけでなく、データプライバシーとセキュリティを強化し、コスト効率を向上させるものです。
なぜ自己ホスト型のLLMを使用するのか？
オープンAIのChatGPTなどのクラウドベースの大規模言語モデルは、簡単にアクセスでき、さまざまなアプリケーションドメインに価値を追加できます。ただし、公開されているLLMプロバイダーは、データセキュリティやプライバシーの問題、また支配の問題、知識漏洩の問題、コスト効率の問題が発生する可能性があります。
注意:これらの懸念が共感する場合は、自己ホスト型のLLMを使用することが価値があるでしょう。
議論を続ける中で、以下の4つの重要な懸念について詳しく説明していきましょう:
プライバシー
LLM APIをアプリケーションに統合する際、プライバシーは最も重要な懸念事項となります。
なぜプライバシーが問題なのでしょうか？
この質問の答えはいくつかの部分から成り立っており、次のポイントで強調されています:
- LLMサービスプロバイダーは、個人情報を訓練または分析に使用することがあり、プライバシーやセキュリティを危険にさらす可能性があります。
- また、LLMプロバイダーは、検索クエリを自身の訓練データに組み込むことがあります。
自己ホスト型のLLMを使用することで、これらの問題が解決されます。なぜなら、データはサードパーティのAPIに公開されることはないため、セキュリティが強化されるからです。
制御
OpenAI GPT-3.5のようなLLMサービスでは、暴力や医学的助言のリクエストなどのトピックが一般的に検閲されます。どのようなコンテンツが検閲されるかについては制御することができません。しかし、独自の検閲モデル（およびルール）を開発することができるかもしれません。
要件を満たす検閲モデルをどのように採用するのでしょうか？
幅広い理論的な回答としては、カスタムフィルターを構築してLLMをカスタムファインチューニングすることが、プロンプティングを使用するよりも望ましいとされています。また、自己ホスト型のファインチューニングされたモデルを使用することで、パブリックドメインLLMに含まれるデフォルトの検閲を変更したり上書きしたりする自由が得られます。
知識漏洩
先述のように、サードパーティのLLMサーバーを使用する場合、特に独自のビジネス情報を含むクエリを実行する場合、知識漏洩が懸念されます。
注意:知識漏洩は、プロンプトからLLMへの流れ、および問い合わせアプリケーションへの流れの両方の可能性があります。
知識漏洩を防ぐにはどうすればよいでしょうか？
要約すると、プロプライエタリなビジネス知識ベースの一部としての自己ホスト型のLLMを使用することです。
コスト効率
クラウドホスト型のLLMと比較して、自己ホスト型のLLMがコスト効率的かどうかは議論の余地があります。記事「持続可能なバンキングにおけるAI：p50レイテンシーの低減とエコフレンドリーな支出の促進」に記載されている研究によると、自己ホスト型のLLMは高度な連続バッチング戦略と適切に平衡が取れている場合、よりコスト効率的であると報告されています。
注意：この概念については、このテキストの後半で詳しく説明します。
自己ホスト型LLMを使用してRAGの限界を引き出す
LLMは計算リソースを大量に消費します。推論と応答を提供するためには膨大なリソースが必要です。RAGを追加すると、質問に回答するために必要なトークン数に2,000以上のトークンが追加されるため、計算リソースの需要はさらに増加します。残念ながら、これらの追加のトークンには追加のコストがかかります。特にOpenAIなどのオープンソースのLLM APIとのインターフェースを行っている場合は、追加のコストが発生します。
これらの数字は、LLMを自己ホストすることで、行列やKVキャッシュ、連続バッチングなどの方法を使用して効率を改善することで改善する可能性があります。ただし、一方で、自己ホスト型RAGシステムでは、ランニング時間に対して請求されるクラウドベースのコアGPUコンピューティングプラットフォーム（例：RunPod）は、トークンのスループットに対して請求されるわけではありません。これは、プロンプトのトークンごとの低コストレートをもたらします。
以下の表は、自己ホスト型LLMとRAGの組み合わせがコスト効率と精度を提供できることを示しています。要約すると：
- 最大限に活用した場合、
gpt-3.5-turboのコストはわずか10％になります。 llama-2-13b-chatのRAGパイプライン（コンテキスト数10）は、1840トークンに対して$0.04のコストで、gpt-3.5-turboのコストの3分の1です（コンテキストなし）。
表：米セントによるトータルコストの比較
当社の手法
この記事のすべての評価について、text-generation-inferenceを使用して、量子化されていないllama-2-13b-chatモデルを実行しました。また、1x NVIDIA A100 80GBを備えたクラウドポッドを$1.99/時間でレンタルしました。このサイズのポッドはllama-2-13b-chatを展開することができます。特筆すべきは、すべての数字が第4四分位数を下限とし、第3四分位数を上限として使用されており、データの分散を箱ひげ図を使用して視覚的に表現していることです。
注意：70Bのモデルを展開するには、より多くの利用可能なGPUメモリが必要です。
LLMのスループットを最大限に引き出す
全体的なスループットは最初に考慮するべきです。私たちは、LLMを1から64のスレッドでオーバーロードし、多数の同時のクエリをシミュレートしました。次の図は、大きなプロンプトでスループットがどのように低下するかを説明しています。並行度をどのように増やしても、生成スループットは約400トークン/秒で収束しました。
プロンプトを追加するとスループットが低下します。解決策として、精度とスループットのバランスを保つために、10以上のコンテキストを持つRAGを使用することをお勧めします。
長いプロンプトの起動時間の測定
モデルの応答時間は重要です。また、カジュアルな言語モデリングの生成プロセスは反復的であるということも知っています。モデルの応答時間を向上させるために、KVキャッシュを使用して前の生成の結果をキャッシュし、計算時間を削減しました。私たちは、このプロセスをLLMの生成時にKVキャッシュを使用するときに「ブート」と呼んでいます。
注意：プロセスの最初の段階で、すべての入力プロンプトのキーと値を計算する必要があります。
プロンプトの長さを増やすにつれて、モデルのブート時間を評価し続けました。次のグラフは、ブート時間を対数スケールで示しています。
このチャートには以下のポイントがあります：
- スレッド数が32未満のブート時間は許容できます。
- ほとんどのサンプルのブート時間は1000ms未満です。
- 並行度を上げるとブート時間が大幅に上昇します。
- 64スレッドを使用する例は1000ms以上で始まり、約10秒で終わります。
- ユーザーが待つにはあまりにも長すぎます。
私たちのセットアップでは、同時接続が32スレッド以下の場合、平均起動時間は約1000msです。そのため、LLMを過度に過負荷にすることはお勧めできません。起動時間が異常に長くなります。
生成レイテンシの評価
KVキャッシュを使用したLLM生成は、起動時間と生成時間の2つのカテゴリに分類できます。実際の生成レイテンシまたはユーザーが次のトークンをアプリケーションで表示するまで待つ時間を評価することができます。
生成レイテンシは起動時間より安定しています。なぜなら、起動プロセスの大きなプロンプトは連続的なバッチング戦略に配置するのが難しいからです。したがって、同時により多くのリクエストがある場合、次のトークンが表示される前に前のプロンプトがキャッシュされるまで待たなければなりません。
一方、キャッシュが構築されれば生成は簡単です。KVキャッシュは反復数を減らし、バッチ内で利用可能な場所があるときに生成がスケジュールされます。レイテンシは異なるステップで上昇し、大きなプロンプトではこれらのステップが早く到着し、バッチが飽和します。より多くのリクエストがLLMを使い切り、リクエストをより多く処理するために制限を増やすと、レイテンシが上昇します。
コンテキストと同時実行にあまり負荷をかけない場合、常に90ms未満の生成レイテンシを期待できます。さらに、コンテキストを32、同時実行を5に設定することをお勧めします。
コスト比較：gpt-3.5-turbo
このソリューションのコストには非常に興味があります。したがって、上記で収集したデータを使用してコストを推定し、パイプライン用の次のコストモデルを作成しました。
- CservはクラウドGPUサーバーの1時間あたりのコストです。
- TbootとTgenは、各リクエストに対する起動時間と生成時間（ミリ秒単位）です。
- Nparallelは、同時に処理されるスレッドの数を計算します（並行性）。
KVキャッシュと連続的なバッチングの使用は、適切なセットアップでコスト効率を向上させ、gpt-3.5-turboのコストを10分の1に削減することができます。最適な結果を得るためには、32スレッドの同時実行が推奨されています。
次は何ですか？
最後の質問は次のようになります：
これらのチャートから何を学び、次にどこに進めばよいでしょうか？
レイテンシとスループットのバランス
レイテンシとスループットの間には常にトレードオフがあります。日常の使用量とユーザーのレイテンシに対する許容度を推定することが良いスタート地点です。パフォーマンスを最大化するためには、1xのNVIDIA A100 80GBとllama-2-13bまたは類似のモデルで32の同時実行を期待することをお勧めします。これにより、最良のスループット、比較的低いレイテンシ、そして合理的な予算が得られます。いつでも決定を変更できますが、まず自分のユースケースを推定することを忘れないでください。
モデルの微調整：より長く、より強力に
RAGシステムを使用してモデルを微調整することができます。これにより、モデルが長いコンテキストに慣れることができます。 Long-LLaMAなど、長い入力長に対してLLMを微調整するオープンソースのリポジトリもあります。長いコンテキストで微調整されたモデルは、RoPEスケーリングで伸ばされたモデルよりも性能が向上します。
MyScaleとRAGシステムの組み合わせ：推論対データベースのコスト分析
MyScaleとRunPodの10 A100 GPUを使用して、Llama2-13B + Wikipediaの知識ベースRAGシステムを簡単に構成して、最大100人の同時ユーザーのニーズに対応することができます。
この議論を締めくくる前に、このようなシステムの単純なコスト分析を考えてみましょう：
注意事項：
- これらのコストは、上記で強調されたコスト計算に基づく概算です。
- 大規模なRAGシステムは、ベクトルデータベースサービスの追加コストが15％以下でLLMパフォーマンスを大幅に向上させます。
- ユーザー数が増えるにつれて、ベクトルデータベースの償却コストはさらに低くなります。
最後に
追加のプロンプトを使用すると、RAGのコストが上がり、遅くなると直感的に考えられます。しかし、私たちの評価では、これは実世界のアプリケーションに対して実現可能な解決策であることが示されています。この評価では、セルフホストされたLLMから期待できること、この解決策のコストと総合的なパフォーマンスを評価し、外部の知識ベースを使用したLLMの展開時のコストモデルの構築を支援しています。
最後に、MyScaleのコスト効率の高さにより、RAGシステムはさらにスケーラブルになります！
したがって、RAGパイプラインのQAパフォーマンスを評価することに興味がある場合は、DiscordまたはTwitterで私たちに参加してください。そして、RQABenchmarkを使用して、独自のRAGパイプラインを評価することもできます！
LLMとベクトルデータベースに関する最新の知見については、随時お知らせいたします！
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
