【HPE AI Japan】生成AIの利用リスクを解決しうるプライベートLLM

[AI_Japan]

こんにちは、HPEで金融・公共向けにサービスをデリバリーしている安江です。

かれこれChatGPTがリリースされてから2年が経過しようとしてます。今まで身近にAIを感じてこなかった方もニュースやSNSなどで見聞きし、『AIすごい！』と感じているのではないでしょうか。

業務改善を目的としたシステム導入などで先進的に生成AIを取り込まれている企業もいる一方で、セキュリティ面におけるリスクを懸念し、導入を踏みとどまっている企業も少なくないでしょう。

本記事では生成AIの利用リスクを解決しうるプライベートLLM(Large Language Model)について情報を共有したいと思います。

プライベートLLMとパブリックサービス

対話型生成AIのパブリックサービスを利用するリスクとしてよく取り扱われるのが、機密情報の漏洩や不適正な利用リスクです。パブリックサービスの多くは、プライバシーや機密情報の取扱いに関するリスクが指摘されています。というのもサービスプロバイダーは、利用者のプロンプト情報を分析し、モデルの改善に使用する可能性があるからです。 

このようなリスクを解決しうるのがオンプレミス環境でLLMの利用ができるプライベートLLMです。昨今、LLMにおいてもオープンソースのモデル開発が進んでおり、多様なモデルサイズが公開されています。そのため、自社環境で確保できるGPUリソースに合わせてLLMの選定をすることが可能です。OSSを利用したChat botの概略図は以下のようになります (図1.) 。

図1. オープンソースのLMMを利用したChat bot概略図

上記のようなChat botは、サーバー1台、GPU1枚あれば構成可能です。以前、HPE ProLiant DL380  Gen11とNVIDIA A100 40GBを利用することができたので、オープンソースのLLM(vicuna-13b-v1.5.Q8_0.gguf )を社内の検証環境で構築しました。パブリックサービスのようなChat UIを作成できるオープンソースのStreamlitを利用し、モデルの実行エンジンはllama-cpp-pythonを利用しました。CPU(Xeon® Gold 6442Y)を利用して文章を生成したときの様子とGPU(A100)を利用して文章を生成したときの様子を図2に示します。  図2　CPU、GPUを利用した文書生成速度の違い

一般的にAIを使う場合には、GPUが必要だと言われますが、本当にGPUは必要なのだろうか。どれぐらい性能が違うのだろうか。といったような疑問をお持ちの方も図2を見ていただくことで、GPUの必要性をご理解いただけるのではないでしょうか。次にプライベートLLMはパブリックサービスと比較して、どれぐらいの生成速度の差があるのか、1秒当たりに生成されるtoken数で定量化し、棒グラフでまとめました(図3)。縦軸は生成速度(tokens/sec)を示し、横軸は評価サンプルを示しており、パブリックサービスのモデル名はA-Iでマスキングして、示しました。各サンプルで6回同じプロンプトを入力し、文章を生成したときの生成速度を計測し、生成速度の平均値と生成速度のばらつきをエラーバー(標準偏差)で示しました。それぞれのパブリックサービスが文章生成速度を向上するために発表した軽量化モデルはプライベートLLMよりも早い生成速度を示しました。一方で、他のモデルはプライベートLLMよりも遅い生成速度を示しました。今回の検証では、プライベートLLMがパブリックサービスの文章生成速度と比較して遜色なく使うことができるポテンシャルを示すことができました。利用するモデルや使用するGPUを変えることで生成速度は上下するため、一例としてご参考にしていただければ幸いです。

図3. プライベートLLMとパブリックサービスの文章生成速度比較

パブリックサービスでは、高性能なモデルを明日にでも安く使い始めることができるといったメリットがありますが、HW構成、利用者数、モデルサイズなどパブリックサービスに依存するため、応答速度を利用者側でハンドリングすることはできません。プライベートLLMであればセキュリティのリスクへの対応に加え、安定したパフォーマンスで利用することができるため、快適な生成AIシステムを利用し始めることができます。

RAGを活用した文書生成

企業での生成AIシステム導入で、昨今注目されているのが社内情報を活用した文書の生成です。パブリックLLMは、事前学習情報にインターネット上で公開されていないような社内情報など、クローズドな情報が学習インプットとなっていないため、社内情報を前提とした文章の生成をすることができません。前述したオープンソースのLLMを利用する場合も例外ではありません。数十台のサーバーやGPUを準備できるのであれば事前学習するのも良いですが、HWリソースに加え、膨大な人的リソース、時間が必要となります。そこで注目されているのがRAG(Retrieval-Augmented Generation)です。RAGシステムは、モデル開発なしで企業が持つ独自情報を活用した文章の生成ができるため、サーバー1台、GPU1枚から構成可能です。RAGを活用したLLMの概略図は以下のようになります (図4.)。

図4. RAGを活用したLLMの概略図

ユーザーは、RAGシステムを活用していることを意識せずに社内情報を活用することができます。このシステムは大きく3つの段階に分かれています。

1. データ準備

最初に、利用したい社内情報を収集し、適切なサイズ(チャンク)に分割します。次に各チャンクをembeddingモデルによってベクトル化し、ベクトルデータベースに保存します。このプロセスにより、社内情報を基にしたに情報を検索できるようになります。

2. 情報検索

ユーザーがプロンプトを入力すると、embeddingモデルによってプロンプトがベクトル化されます。次に、プロンプトのベクトルを、ベクトルデータベースに保存されている社内情報のベクトルと類似度検索を行います。

3. 文章生成

検索結果として得られた社内情報をプロンプトに追加し、LLMに入力することで、社内情報を基にした文章生成をすることができるようになります。また、生成された文章がどの情報のどこを参照して文章を生成したか確認することができるため、誤った情報の利用リスクを低減することができます。

以前、片山が投稿した「【HPE AI Japan】生成AIの市場動向とオンプレLLMの必要性」で触れているモデルがクラウド上でデプロイされている場合のセキュリティリスクは「3. 文章生成」のステップで発生するため、データベースだけではなく、モデルもオンプレミス上でデプロイしておく必要があるわけです。

> RAGシステムからの問い合わせ先であるモデルがクラウド上にホストされる場合、当然ながら固有のデータもクラウドに流れてしまう仕組みとなります。

RAGはAI利用で問題視される出力データの「透明性と説明可能性」も解決できる優れた手段である一方で、精度を向上させることが難しいです。RAGは「カンニングペーパーを持ち運んで試験を受けるようなもの」と比喩されることがあります。持ち込み可能な試験に教材を持ち込んだものの、記載元を見つけることができず、試験をパスできなかった経験に心当たりがある方もいらっしゃるのではないでしょうか。RAGの精度向上では、検索で利用するプロンプトを変換したり、検索の手法を変えたり、検索結果の指標を多面化したり、検索元の最適化をしたりと様々なアプローチがあります。以下の論文でもRAGシステムにおける検索の重要性がわかります。青色のグラフは検索なしでLLMを利用したときの精度、黄色がランダム抽出した仮の検索結果を追加してLLMを利用したときの精度を示しており、検索アルゴリズムの最適化の重要性がわかります。

 Ori Yoran, Tomer Wolfson, Ori Ram, and Jonathan Berant. 2023. Making Retrieval-Augmented Language Models Robust to Irrelevant Context. arXiv preprint arXiv: 2310.01558 (2023).

また、RAGシステムの最適化には検索アルゴリズムの他に検索元の意識が不可欠です。「Garbage in Garbage Out（ごみを入れたらごみが出てくる）」といいう言葉があります。今回であれば「1. データ準備」の段階で、利用シーンを想定した社内情報の選定ができているか、データの最新化はできているか、誤った情報を見つけたときに整備するための組織を形成できているかなどデータマネジメントの観点も忘れてはいけません。

ITmediaにてPrivate LLMについて解説した内容を掲載させていただいているので、ぜひご一読ください！

企業のAI活用の“真打ち”　「プライベートLLM」の可能性から実践方法まで、専門家が解説