オンプレLLMを自社業務に導入する方法

TL;DR

オンプレLLMを導入するには、利用場面、入力、理想の出力、必要な精度と速度を先に定義し、それに合うモデルとハードウェアを選ぶ。機密データを社外に出せず、利用量が多い業務では有力だが、初期費用やモデル性能の制約を考慮し、検索だけを行う構成やルールベースとの併用も検討する。

Transcript

二本研究所江です今回は生成AIの新潮流 オンプレで作る自社特化llmと題しまし てクラウドでインターネット経由で使う ラージランゲージモデル生成AIと自分の パソコンであったりとか自社のサーバー ワークステーション上で使えるローカルの llmローカルな生成AIですねの違いで あったりとかどういう特徴があるのか どんな事例があるのかというところをリモ 系インタビューでご紹介していきたいと 思いますえ2024年の生成アトレンドの 1つとしてこのローカルllmであったり オンプレのllmというのをあげる人も 多いぐらい非常に注目をされています オープンソースのllmがたくさん出る ことによってわざわざチャットGPTとか クドジェミニといったそういったものを 使わないにしても特定の処理だけであれば ... Read More

Key Insights

• オンプレLLMは、モデルによる処理と業務データの保管を自社内で完結させ、プロンプトや機密情報を外部事業者のサーバーへ送らずに利用できる仕組みである。
• クラウド型LLMは、利用開始時の設備負担が小さい一方、APIの利用量に応じて料金が増えるため、多人数が高頻度で使う業務では継続費用が大きくなる場合がある。
• オンプレLLMは、サーバーや高性能PCの導入費が先に必要だが、大量利用する条件ではクラウド型よりランニングコストを抑えられる可能性がある。
• オンプレ環境のモデルは、クラウド上の大規模モデルよりパラメーター数や処理能力が限られるため、用途を絞り、必要以上の精度を求めない設計が重要である。
• 金融企業のレポート作成は、完成文ではなく担当者が確認する叩き台を出力目標にすることで、社外秘データを守りながら作業時間の削減を狙える事例である。
• 生成を省いた検索型の構成は、関連文書の原文と参照箇所を提示し、最終確認を人に任せることで、処理負荷、応答時間、ハードウェア要件を抑えられる。
• 用途特化モデルは、翻訳や検索など対象業務に合うものを選定することで、施設内ネットワークだけで動作する対話システムにも適用できる可能性がある。
• ユースケースの定義は、モデル選定と軽量化の前提であり、入力、理想の出力、許容精度、必要速度が曖昧なままでは削る機能や残す性能を判断できない。
• 🎬 このチャンネルの他の動画:
  • ExcelでChatGPT関数を実務活用する方法
  • Geminiの主要機能を仕事で使い分ける方法
  • Microsoft 365 Copilotの活用方法
• 📺 このチャンネル: いけともch

Questions & Answers

Q: オンプレLLMとは何ですか？

オンプレLLMとは、生成AIのモデルやサーバーを自社内の環境に置き、入力データから出力生成までを社内で完結させる運用方式です。クラウド型のようにプロンプトや業務データを外部事業者のサーバーへ送らないため、社外秘情報や個人情報を外部へ出せない業務の選択肢になります。

Q: オンプレLLMとクラウド型LLMの違いは何ですか？

主な違いは、データの処理場所、費用構造、利用できるモデルの規模です。クラウド型は外部サーバーで処理し、APIでは利用量に応じた料金が発生します。オンプレ型は自社内で処理し、設備の初期費用が必要ですが、大量利用時には継続費用を抑えられる場合があります。

Q: オンプレLLMが適している業務は何ですか？

機密データを社外へ出せず、用途と期待する出力を明確に限定できる業務に適しています。紹介された例は、金融企業の社外秘レポート作成、自社製品の問い合わせに対する社内文書検索、施設内ネットワークだけで利用する多言語の対話システムです。

Q: オンプレLLM導入で最初に決めるべきことは何ですか？

最初に決めるべきことは、具体的なユースケースと理想の回答です。どの場面で、何を入力し、どのような出力を得たいのかに加え、必要な精度と速度を定義します。この要件が決まらなければ、モデル、ハードウェア、軽量化方法を適切に選ぶことができません。

Q: オンプレLLMのコストを判断する方法は？

初期費用と継続費用を分け、想定する人数、利用頻度、処理する文章量に基づいて比較します。オンプレ型にはサーバーや高性能PCの導入費がかかりますが、利用ごとのモデル料金は不要です。クラウド型は始めやすい反面、利用量が増えるほどAPIの従量課金が膨らむ可能性があります。

Q: 軽量なオンプレLLMで精度不足を防ぐ方法は？

業務を限定し、必要な出力水準を現実的に設定することが重要です。完成品を求めず、人が確認するレポートの叩き台を生成させる方法があります。また、処理を複数工程に分け、LLMが得意な工程だけを任せ、残りをルールベースで処理する構成も検討できます。

Q: 生成を使わないRAGはどのように活用できますか？

生成を使わない構成では、質問に関連する社内文書を検索し、該当する原文と参照箇所を利用者へ提示します。専門的な問い合わせで担当者が原文を最終確認するなら、回答文を生成する必要性は下がります。これにより処理を軽くし、速度とハードウェア要件を抑えられます。

Q: オンプレLLMのモデルとハードウェアを選ぶ方法は？

ユースケース、入力、理想の出力、必要精度、応答速度を定義したうえで、それを満たすモデルと設備を選びます。翻訳や検索など用途が限定される場合は、その処理に特化したオープンソースモデルも候補です。量子化などで軽量化する際も、維持すべき性能を先に決める必要があります。

Q: オンプレLLMの導入を早めに検証する利点は何ですか？

現在のローカルモデルが自社業務でどこまで使えるかを把握し、実装可能な工程を先に特定できることが利点です。単体で十分な出力に届かなくても、ルールベースや複数工程を組み合わせて補える場合があります。事前検証で利用条件を整理しておけば、モデルの改善時にも導入判断を進めやすくなります。

Summary & Key Takeaways

• オンプレLLMは、モデル、サーバー、業務データを自社内の環境で運用し、処理を社内で完結させる方式である。クラウド型はプロンプトなどのデータを外部事業者のサーバーへ送り、処理結果を受け取る。オンプレ型は機密情報を外部へ出さずに済み、利用量が多い場合は従量課金型クラウドよりランニングコストを抑えられる可能性がある。一方、サーバーや高性能PCの初期費用が必要になる。

• 適用例には、金融企業の社外秘レポート作成、自社製品に関する問い合わせ対応、施設内ネットワークだけで動く対話システムがある。レポート作成では完成品ではなく、人が確認する叩き台を生成させることで、軽量モデルでも価値を出せる。問い合わせ対応では、回答文の生成を省き、関連する原文と参照箇所だけを検索結果として示す構成にすると、処理負荷とハードウェア要件を抑えられる。

• 成功の起点は、ユースケース、入力、望ましい出力、許容精度、応答速度を具体化することである。要件が決まれば、モデル選定や量子化などの軽量化で、削ってよい機能と維持すべき性能を判断できる。複雑な業務は複数工程に分け、LLMに適する工程とルールベースに適する工程を組み合わせる。まず現時点の性能を検証し、業務で使える範囲を確認しておくことが早期導入につながる。