原文リンク(2024-10-01)

キーポイント

InfoQ: ChatGPTのようなAPIベースのモデルと、「ローカル」またはセルフホストモデルを選択する際のガイドラインは何か？

関連スポンサーコンテンツ

Meryem Arik氏: APIベースのモデルではなく、セルフホストモデルを使うべき主な理由はいくつかあり、最近のブログ記事で取り上げました。まず、コントロールとデータ・プライバシーです。多くの企業にとって、LLMアプリケーションはビジネス上かなりセンシティブなデータに触れることになり、そのデータを見るモデルをコントロールすることが重要になります。

第二に、カスタマイズ性です。モデルをセルフホストする場合、モデル内のすべてのウェイトをコントロールができます。つまり、モデルを好きなように微調整したり適応させたりすることができます。これにより、小規模なモデルであっても、より良い結果を得ることができます。

第三に、コストと拡張性である。実験段階では、APIベースのモデルの方が、セルフホスティングのインフラを構築する必要がないため、コストが安くなる傾向があるのは事実です。しかし、規模が大きくなれば、非常に効率的な推論スタックを使ったセルフホストの方が、より安く、よりスケーラブルになります。

Llama 3のようなオープンソースモデルが登場した今、セルフホストする能力を構築しない理由はほとんどないです。Llama 3は、主要なAPIベースのモデルに匹敵するが、個人で独自の環境にデプロイできるという利点もあります。すべてのアプリケーションがセルフホストモデルを使用しているわけではないとしても、すべての企業はセルフホスト機能を構築しなければならないです。そうしないと、大きな損失を被ることになります。

Numa Dhamani氏: APIベース・モデルとローカル・モデルまたはセルフホスト・モデルのどちらを選ぶかを決める際、考慮すべき重要な要素がいくつかあります。まず、データのプライバシーとセキュリティです。APIベースのモデルを使用すると、機密情報がサービス・プロバイダーに公開される可能性があり、データに所有権や機密情報が含まれている場合は懸念事項となります。一方、ローカル・モデルでは、自社のインフラ内でデータを管理できるため、医療や金融などデータ・プライバシーに規制のある業界では、ローカル・モデルの方が適しています。

さらに、コストとリソースの配分も重要な検討事項です。APIベースのモデルは、一般的に、使用ごとに支払い、インフラのセットアップやメンテナンスに関連する費用を避けることができるため、運用上のオーバーヘッドに関して、当初はより費用対効果が高いです。また、一般的に統合や利用が容易であり、AIシステムの複雑なインフラを管理する能力や意欲のない組織にとって理想的であることが多いです。

しかし、ローカルモデルは、セットアップと継続的なメンテナンスのために、当初はより多くのリソースを必要とするが、長期的な節約とより大きな柔軟性を提供する可能性があります。また、ローカルにホスティングすることで、データがインターネット上を移動する必要がないため、レイテンシーを削減できます。これは、時間に敏感なアプリケーションにとって非常に重要です。最後に、APIモデルへの依存は、サービスの可用性、条件や価格の変更に関連するリスクをもたらす可能性があり、長期的な計画と運用の安定性に影響を与える可能性があります。

Maggie Engler氏: ほとんどの組織は、何よりもまず構築と維持にかかるコストを気にするでしょう。2つのモデルの規模や機能がほぼ同じだと仮定すると、APIベースのモデルはセットアップに必要なエンジニアリングリソースが少なくて済み、負荷管理やスケーリングは通常APIプロバイダーが行うことになります。インフラを提供するコストを考慮すると、特に探索的なプロジェクトや概念実証のためには、APIコールごとに支払う価値があるかもしれないです。

長期的かつ大量に利用する場合は、セルフホストモデルの方がコスト効率が良く、パフォーマンスやレイテンシーをよりコントロールしやすいでしょう。さらに、データのプライバシーやセキュリティの基準が高い組織は、サードパーティプロバイダーとのデータ共有を避けるために、セルフホストモデルを選ぶかもしれないです。

Tingyi Li氏： APIベースモデルとローカルモデルまたはセルフホストモデルのどちらを選ぶかは、特定のユースケース、技術的専門知識、リソースの有無、予算など、さまざまな要因によって決まります。通常、規制の厳しい業界の企業は、データガバナンス、プライバシー、透明性に関する法的要件や規制があるため、自社ホスティングを余儀なくされます。

大規模なカスタマイズが必要な場合や、特定のドメインやユースケースに合わせてモデルを微調整する必要がある場合は、セルフホスティングモデルが望ましいかもしれないです。モデルのアーキテクチャ、トレーニングデータ、パラメータを完全にコントロールできます。トレードオフとして、インフラストラクチャーのメンテナンス、モデルの更新、発生した問題への対処はあなたの責任となります。

APIベースのモデルでは、カスタマイズのオプションはプロバイダーが提供するものに限定されるかもしれませんが、プロバイダーによって管理されるため、自動アップデート、バグフィックス、改良の恩恵を受けることができます。

コストも考慮すべき重要な要素です。APIベースのモデルは通常、サブスクリプションまたは利用ベースの価格モデルで運用され、特に中小規模のアプリケーションではコスト効率が高くなります。しかし、利用が拡大するにつれて、コストは大幅に増加する可能性があります。セルフホストモデルは、インフラへの先行投資と継続的なメンテナンスコストが必要ですが、トラフィックの多いアプリケーションの場合、長期的には費用対効果が高くなる可能性があります。

また、リアルタイム性やレイテンシーに敏感なアプリケーションでは、ローカルでモデルをホスティングした方が、ネットワークのオーバーヘッドがなくなるため、パフォーマンスが向上する可能性があります。APIベースのモデルでは、ネットワーク通信によるレイテンシが追加されます。

InfoQ: プロンプト・エンジニアリングでLLMを「アウトオブボックス」使うのではなく、どのようなシナリオでLLMを微調整することを薦めるか？

Arik氏: 私は、微調整の代替案を試すことを常に推奨しています！このような代替案には、検索拡張生成（RAG）、コントロール・ジェネレーション、プロンプト・チューニングなどがあります。

Dhamani氏: LLMのファインチューニングとプロンプトエンジニアリングの違いは、目の前のタスクに大きく依存します。ユニークな要件があったり、モデルに高い特異性を持たせる必要があったりする場合は、ファインチューニングの方がよいでしょう。たとえば、専門用語が飛び交うニッチな業界で事業を営んでいる場合、ファインチューニングを行うことで、モデルの反応を特定の文脈に合わせることができます。

一方、プロンプトエンジニアリングは、カスタマイズの必要性がそれほど高くない一般的なアプリケーションやタスクに適しています。特に、特定のタスクに深く特化するよりも、幅広いタスクに対する柔軟性や適応性を重視する場合に有効です。

Engler氏: LLMの利用を検討しているのであれば、あるアプリケーションについて、成功基準を極めて明確にする必要があります。ユーザーがモデルとどのように相互作用するかをとらえた評価コンテクストのセットで、成功する反応の構成要素を定義し、理想的には、この方法で任意のモデルを評価できるようにすべきです。

多くのアプリケーションでは、プロンプトエンジニアリングは微調整を加えなくても機能するかもしれないです。適切なプロンプトは信頼できる生の応答を生成するかもしれないし、特定の出力制約がある場合は、その制約を満たすように後処理できる応答を生成するかもしれないです。微調整を行えば、常にモデルの反応をより細かくコントロールできるが、よりシンプルな方法をまず試してみる価値はあります。

Li氏: 微調整をしなければならないケースはないし、微調整を避けるべきケースもたくさんあります。経験則から言えば、まずは手近なものから始めることだ。つまり、迅速なエンジニアリングとRAGを備えた「すぐに利用可能な」モデルを使うことです。プライベート・データを使ったユースケースのこのような概念実証は、スピンアップに半日もかからず、本番でのパフォーマンスとコストの大まかな評価を得ることができます。

微調整を行うかどうかは、求めるROI、つまりモデルの評価と微調整にかかるコストと、パフォーマンス向上やビジネスにもたらす価値との比較によって決まります。

例えば、Perplexity.aiのようなGenAIを活用した垂直型のOaaSを展開している場合、あるいはGenAIを差別化の核としてビジネスを強化したい場合は、微調整に投資した方がよいでしょう。しかし、Llama3-8Bのようなオープンソースモデルの出現とその推論能力の進歩により、小規模なモデルによるニッチなユースケースのための参入障壁は、より実現可能で簡単になるかもしれないです。

InfoQ: LLMの「民主化」についてはどう考えているか？小型のオープンソース/オープンウェイト・モデルで十分な場合もあるのか？

Arik氏: そうだ！一部というより、実際にはほとんどです。Llama3がリリースされた今、多くのAPIベースのモデルに劣らない結果を出しており、オープンソースの言語モデルを使わない理由はほとんどないです。たとえそれが「バックアップ」であったとしても、言語モデルをセルフホストする機能に投資しないのは無責任です。そうしないと、多くの制御をサードパーティの手に委ねることになります。

Dhamani氏: LLMの民主化は確かにイノベーションを促進し、参入障壁を下げ、AI分野での競争を高める可能性があります。小規模でオープンソースのモデルは、特定のシナリオにおいては十分であり、有利でさえあります。

特に、教育や研究目的、実験、計算リソースが限られている環境での使用には価値があります。現在、個人や小規模な組織や研究機関は、AIの能力を探求し、その限界を緩和するために努力し、大規模なモデルに必要な多額の財政投資をすることなく、アプリケーションのプロトタイプを作成できます。

しかしもちろん、小さなモデルは特定のタスクには非常に効果的ですが、より複雑で微妙なタスクを処理する上では、その性能は通常、より大きく高度なモデルには及ばないのが一般的です。このトレードオフは、多くの場合、タスクごとのリソース制約と性能要件のバランスにあります。

Engler氏: そうだ！小規模なオープンソースのモデルはますます強力になってきており、多くのユースケースではすでに十分な性能を発揮しています。また、モバイルデバイス上でLLMを実行するような、小さなモデルを必要とするユースケースもあります。

私はよく、より小さなモデルが機能し、コストを大幅に削減できることに気づいていない敏腕エンジニアと話をします。最近、あるコンサルタントに会ったが、GPT-4を10億以下のパラメータを持つモデルで簡単に処理できるタスクに使っていました。彼らに、GPT-4を使って数千の例にラベルを付け、そのアノテーションで小さなモデルを微調整して推論コストを節約するよう提案しました。

Li氏: オープンソース／オープンウェイトモデルは、間違いなく透明性をもたらし、オープンソース開発と様々な派生モデルの普及を加速させています。小規模なオープンソースのLLMには利点がありますが、すべてのユースケースに適しているとは限りません。一般的に、オープンソースのモデルがクローズドモデルと同等になることはまだほとんどない段階です。

しかし、すべてのユースケースに最先端のモデルやもっとも性能の高いモデルが本当に必要なわけではないです。オープンソースや小規模のLLMの有効性は、アプリケーションの特定の要件、リソース、制約に大きく依存します。多くのシナリオにおいて、LLMは、特に慎重なカスタマイズと最適化を組み合わせた場合、大規模なプロプライエタリ・モデルに代わる、実行可能で利用しやすい選択肢を提供できます。

InfoQ: LLMの一般的なリスクにはどのようなものがあるか。また、そのリスクを軽減するにはどうすればよいか？

Arik氏: 人々が口にするもっとも一般的なリスクは、ハルシネーションの問題です。しかし、これは問題ではなく、むしろ理解されるべき特徴だと思います。ハルシネーションはLLMを使用する上で避けられないものだと理解すれば、それを軽減するシステムを設計できます。

ハルシネーションを軽減するもっとも一般的で人気のある方法は、RAGを使用することです。RAGとは、本質的に、モデルがその答えに役立つ情報を「検索」する機能です。RAGの素晴らしいところは、モデルがデータにリアルタイムでアクセスできるだけでなく、ユーザーがモデルがどのような情報を使って答えを導き出したかを見ることができるという、可聴性のレイヤーを追加していることです。RAGアプリケーションの構築方法については、我々のブログをご覧ください。

Dhamani氏: LLMにはいくつかのリスクと制約があり、その機能を効果的に活用するためには注意深くナビゲートする必要があります。LLMは学習データに存在するバイアスを受け継ぐだけでなく、増幅することもよく知られています。これは、特に予測警察、雇用、信用スコアリングのようなデリケートなアプリケーションにおいて、差別的慣行や、歴史的な不正や不平等の永続化につながる可能性があります。バイアスを軽減するには、徹底的なバイアスの監査、多様なデータセットの使用と文書化、包括的なテストと検証プロセスが必要です。

LLMは不注意に機密情報を記憶し、漏洩する可能性があるため、もう一つの懸念はプライバシーです。ディファレンシャル・プライバシーなど、プライバシーを強化するテクニックをトレーニングプロセス中に使用することで緩和することができ、強固なデータ匿名化プロトコルを導入することで、ユーザーデータをさらに保護することができます。

LLMはまた、ハルシネーションを見やすい（つまり、もっともらしいが完全にでっち上げられた情報を生成します）。RAGのような技術を活用することで、追加的な文脈データをLLMに提供することができ、モデルのハルシネーションを減らすのに役立つ可能性があります。

最後に、意思決定がAIに取って代わられるのではなく、AIによって補強されるような、ヒューマン・イン・ザ・ループ・ソリューションを奨励することは、ハルシネーションやバイアス、労働力のスキル低下などの懸念を軽減するのに役立つだけでなく、人間の経験に中心的な焦点が置かれ続けることを確実にすることができます。

Engler氏: LLMが回答を生成する際に実際に行っていることについては、間違いなく誤解があります。基本的に、LLMは過去に見たデータからもっとも可能性の高い反応を予測している。そのため、現実的に聞こえるが不正確な情報を作り上げ、バイアスを強化してしまう可能性があります。

さらに、通常とは異なる入力が予期せぬ出力を生み出すことがあることを意味し、多くの場合、安全でないコンテンツを生成する最後の段階で、モデルのトレーニングの一部を回避するLLMの「ジェイルブレイク」をすでにたくさん見てきました。緩和策を論じれば一冊の本が埋まってしまうが、大まかに言えば、これらのリスクは、信頼できるデータソースからの検索、堅牢性のための微調整、入力と出力のサニタイゼーションによって緩和できます。

Li氏: LLMには、誤解を招く情報による詐欺、知的財産の悪用、プライバシーの侵害、バイアスなど、一般的なリスクがたくさんあります。つまり、組織は責任を持って管理された方法で AI システムを構築することを検討する必要があるということです。

公正さ、説明可能性、AIシステムの堅牢性、AIの動作の制御、データのプライバシーとセキュリティ、責任あるAIの実践、AI利用の透明性、悪用や危害からの安全性を含む8つの重要な次元があります。8つの次元を実施するためには、責任あるAIを、モデルを構築する企業と、そのモデルを使用するアプリを構築する企業の間で共有される責任とみなすことができます。

LLMの採用を成功させるためには、技術的・組織的にどのような変革が必要か？

Arik氏: ひとつはリソースの統合です。LLMはデプロイが難しく、多大なリソースを必要とするため、チーム間でリソースを統合することで得られる価値は大きいです。各チームがそれぞれデプロイを行うのではなく、優れたアプリケーションの構築に専念し、その代わりに中央チームが提供するリソースを共有できるはずです。そうすることで、リソースをより有効に活用し、開発サイクルを大幅に短縮できます。

もうひとつは教育です。LLMは、コンピューターがどう動作するべきかという人々の考えとはまったく異なる方法で動作します。LLMは非決定論的で、時にはミスを犯すこともあります。つまり、彼らは非決定論的であり、時にはミスを犯します。Mindstoneのような素晴らしいコースがあるので、技術者でないスタッフにも、AIとは何か、それをどのように仕事に活用できるかをよりよく理解してもらうために提供することを勧めます。

Dhamani氏: 組織内でLLMの導入を成功させるには、技術的な導入にとどまらない包括的な組織改革を行うことが重要です。まず、リーダーシップによるサポートが必要であり、そのためには、部門を横断してLLMの利用を推進するだけでなく、人材トレーニング、倫理とガバナンスの枠組みの導入、継続的な学習と開発の文化の醸成が必要となります。

LLMが高いレベルでどのように機能するか、LLMの能力と限界、LLMと接する際のベストプラクティスなど、LLMの基本的な知識について、あらゆるレベルや部門の従業員が教育を受けるべきです。

また、強固な倫理とガバナンスの枠組みを導入することで、LLMの採用が公正、プライバシー、透明性の基準を遵守し、潜在的な倫理的・法的落とし穴から身を守ることができるます。

Engler氏:　組織内でLLMの採用を成功させるには、ハルシネーションやデータプライバシーに関する懸念など、LLMの能力とリスクに関するトレーニングが必要です。しかし、それは人々が想定しているよりも少ない変更で済むかもしれないです。LLMは現在のところ、仕事を代替するのではなく、仕事を補完するのに最適な人材であります。LLMは、素早く質の高い初稿を作成し、コンセプトを説明し、面倒な作業を自動化できます。

スタンフォード大学とマサチューセッツ工科大学（MIT）の最近の研究では、LLMを使用することで、コールセンターの従業員の生産性が全体的に約14％向上し、その効果は新人従業員に最も顕著に表れ、熟練者にはツールによる効果があまり見られませんでした。組織は、LLMの導入に現実的かつ反復的に取り組み、実験を行い、投資対効果を継続的に評価すべきです。

Li氏: LLMに関連するのメリットを最大化し、潜在的なリスクを軽減するには、非技術的かつ組織的な変革が重要な役割を果たします。まず、組織はLLMのようなAI技術を受け入れる文化を促進する必要があります。これには、あらゆるレベルの従業員にAIに対する認識、理解、受容を促すことが含まれます。

AIの安全かつ責任ある開発に取り組む企業は、リーダーを教育し、科学を発展させることを優先し、エンド・ツー・エンドのAIライフサイクル全体で責任あるAIの統合を目指し、人材中心のアプローチを取ることができます。包括的なトレーニングプログラムを実施し、ワークフローにおけるLLMの効果的な活用方法について従業員のスキルアップを図るべきです。これには、ベストプラクティス、倫理的配慮、AIが生成したコンテンツの解釈と信頼方法に関するトレーニングが含まれます。

データの取り扱い、モデルの展開、プライバシー保護、規制要件の遵守に関するガイドラインなど、LLMの使用に関する明確なガバナンス構造とポリシーを確立する必要があります。最終的には、組織は組織の文化や慣習に合った、LLMの責任ある使用を導く倫理的なGenAI採用フレームワークの開発を目指すべきです。

また、 Foundation Model Operations（FMOps）には、ヒューマンインループやモデルのベンチマーキングと評価など、組織の伝統的なMLOpsの実践に統合された追加のメカニズムが必要です。LLMのパフォーマンス、インパクト、ROIを評価するためには、継続的なモニタリングと評価が極めて重要です。組織は、主要なパフォーマンス指標を追跡するための指標を確立し、ユーザーからのフィードバックを求め、時間の経過とともにモデルの改善を繰り返すべきです。

結論

我々のパネルディスカッションは、いくつかの一般原則についてコンセンサスに達した。第一に、大規模でクローズドなAPIベースのLLMは、実験用の初期ツールとして適している。しかし、より小規模なオープン・モデルは多くのシナリオにおいて実行可能なソリューションであり、セルフホスティング・モデルは長期的なコストを節約し、プライバシーに関する懸念に対処できる。

どのモデルを選んだとしても、モデルの応答を改善しようとする場合、モデルを微調整するよりも、プロンプトエンジニアリングや検索拡張世代（RAG）の方が良い選択であることが多い。RAGはまた、ハルシネーションのようなLLMのリスクを軽減するためにも有効である。

LLMは、企業や組織にとって、従業員の効率を向上させる絶好の機会である。特に、従業員がこの技術の利点と限界を理解するよう訓練されている場合にはなおさらである。しかし、企業は明確な成功基準を持ち、モデル使用のROIを追跡するべきである。