HUOXIU

LLMOps: AIGC 時代の AI アプリケーション開発プラットフォーム

出典:Financial IT Matters

まえがき:ここ2日間、A2Mカンファレンスに出席し、最近話題のAIGC(AI Generic Domain Name)に焦点を当ててきました。業界がAIGCを重視していることに驚きました。多くの企業が大規模モデルの構築に取り組み、AIアプリケーションの構築に活用しています。特に、He Mian教授の講演では、AIGCが製品のインタラクションとアプリケーションアーキテクチャに与える破壊的な影響が強調されていました。現在、LangChainやセマンティックカーネルなど、大規模モデルに基づくAIアプリケーション開発フレームワークが業界で台頭しており、これらのフレームワークはLLMOpsとも呼ばれています。そこで、本稿ではLLMOpsについて紹介します。原文はWeights & Biasesに掲載された英語の記事で私が翻訳しました。原文へのリンクは以下です。

LLMOps を理解する: 大規模言語モデル操作 | 記事 – 重みとバイアス (wandb.ai)

LLMOps の理解: 大規模言語モデル操作

著者:レオニー、翻訳者:トニー

この記事では、大規模言語モデル (LLM) が AI 駆動型製品と機械学習運用 (MLOps) の構築の見通しをどのように変えているのかを探ります。

申し訳ありませんが、このままでは画像をお送りできません。画像が大きすぎるためです… - 作者が描いた、実稼働中の大規模言語モデル(LLM)の画像。

OpenAIのChatGPTのリリースは、「大規模言語モデル(LLM)の実稼働」というパンドラの箱を開けてしまったようです。近所の人たちが人工知能についてあなたとチャットするだけでなく、機械学習(ML)コミュニティでは「LLMOps」という新しい用語も話題になっています。

LLMは、AI駆動型製品の構築と保守の方法に変革をもたらしています。これにより、LLM駆動型アプリケーションのライフサイクルにおける新たなツールセットとベストプラクティスが生まれるでしょう。

この記事では、まず、新たに登場した用語「LLMOps」とその背景について説明します。LLMを用いたAI製品の構築が、従来の機械学習モデルとどのように異なるのかを考察します。これらの違いを踏まえ、MLOpsとLLMOpsの違いを理解します。最後に、LLMOps分野における今後の展開について考察します。

01 LLMOps とは何ですか?

LLMOpsは「Large Language Model Operations(大規模言語モデル操作)」の略称です。簡単に言えば、LLM駆動型アプリケーションの開発、展開、保守を管理するための新しいツールとベストプラクティスのセットであり、LLM向けのMLOpsとも言えます。

「LLMOps は LLM の MLOps である」と言う場合、まず LLM と MLOps という用語を定義する必要があります。

  • 大規模言語モデル(LLM)は、人間の言語出力を生成できるディープラーニングモデルです(そのため「言語モデル」と呼ばれます)。これらのモデルは数十億のパラメータを持ち、数十億語の単語で学習されます(そのため「大規模言語モデル」と呼ばれます)。

  • MLOps (機械学習オペレーション) は、ML 駆動型アプリケーションのライフサイクルを管理するためのツールとベスト プラクティスのセットです。

これらのことを学んだ上で、さらに詳しく見てみましょう。

02 LLMOps はなぜ登場したのか?

BERTやGPT-2といった初期のLLMは2018年から存在していました。しかし、LLMOpsの概念が急速に人気を集めたのは、それから約5年が経った今になってからです。その主な理由は、2022年12月にLLMsがChatGPTをリリースしたことでメディアの注目を集めたことです。

LLMの出現([1]を参考に著者が作成した画像)

それ以来、次のようなさまざまなアプリケーションが LLM のパワーを活用してきました。

  • チャットボットには、よく知られているChatGPTから、よりプライベートでパーソナライズされたボット (たとえば、 Michelle Huang が子供の頃の自分とチャットする) までさまざまなものがあります。

  • 編集や要約のためのライティングアシスタント(例: Notion AI )と、コピーライティング(例: Jaspercopy.ai )や契約書作成(例: lexion )に特化したライティングアシスタント。

  • プログラミング アシスタントには、コードの作成とデバッグ ( GitHub Copilotなど) からコードのテスト ( Codium AIなど)、セキュリティの脅威の検出 ( Socket AIなど) まで多岐にわたります。

LLM 駆動型アプリケーションを開発してリリースする人が増えるにつれて、彼らは経験を共有し始めます。

「LLMでクールなものを作るのは簡単だが、それを製品品質にまで引き上げるのは非常に難しい。」 -チップ・フイエン[2]

明らかに、本番環境対応のLLM駆動型アプリケーションの構築は、従来のMLモデルを用いたAI製品の構築とは異なり、独自の課題を伴います。これらの課題に対処するには、LLMアプリケーションのライフサイクルを管理するための新しいツールとベストプラクティスを開発する必要があります。そのため、「LLMOps」という用語の使用が増えています。

LLMOps の手順は、いくつかの点で MLOps の手順と似ています。ただし、LLM ベースのアプリケーションを構築する手順は、基盤となるモデルの可用性によって異なります。LLM をゼロからトレーニングするのではなく、事前トレーニング済みの LLM を下流のタスクに適応させることに重点が置かれます。

1年以上が経過し、Andrej Karpathy[3]はAI製品の構築プロセスが今後どのように変化するかを次のように説明しています。

しかし、最も重要な傾向は、特定の対象タスクにおいてニューラルネットワークをゼロから学習するというセットアップ全体が、ファインチューニング、特にGPTのような基本モデルの出現によって急速に時代遅れになりつつあることです。これらの基本モデルは、十分な計算リソースを持つ少数の機関によってのみ学習されており、ほとんどのアプリケーションは、ネットワークの部分的な軽量ファインチューニング、エンジニアリングのヒント、またはより小規模で具体的な推論ネットワークへのデータまたはモデルの蒸留といったオプションの手順を通じて実装されています。 [...] - Andrej Karpathy [3]

この引用文は一見すると圧倒されるかもしれません。しかし、ここで起こっていることのすべてを的確に要約しているので、以下のサブセクションで段階的に説明していきましょう。

ステップ1: ベースモデルを選択する

ベースモデルは、様々な下流タスクに使用できる大量のデータで事前学習されたLLMです。ベースモデルをゼロから学習させるのは複雑で時間がかかり、非常に高価であるため、必要な学習リソースを持つ機関はごくわずかです[3]。

この点を説明すると、Lambda Labs による 2020 年の調査によると、Tesla V100 クラウド インスタンスを使用して OpenAI の GPT-3 (1,750 億のパラメータを持つ) をトレーニングするには、355 年と 460 万ドルかかります。

人工知能は現在、コミュニティが「Linuxの時代」と呼ぶ時期を迎えています。開発者は、パフォーマンス、コスト、使いやすさ、柔軟性のトレードオフに基づいて、独自仕様モデルとオープンソースモデルという2種類の基盤モデルから選択する必要があります。

グラフの独自モデルとオープンソースの基礎モデル(画像作成者、 Fiddler.aiに触発された)

プロプライエタリモデルとは、大規模な専門家チームと多額のAI予算を持つ企業が所有する、クローズドソースの基礎モデルです。通常、オープンソースモデルよりも規模が大きく、パフォーマンスも優れています。また、入手しやすく、一般的に使いやすいという特徴もあります。

独自開発モデルの主な欠点は、高価なAPI(アプリケーション・プログラミング・インターフェース)です。さらに、クローズドソースのベースモデルは、開発者にとって柔軟性がほとんど、あるいは全くありません。

独自のモデルプロバイダーの例は次のとおりです。

  • OpenAI(GPT-3、GPT-4)

  • co:ここ

  • AI21ラボ(ジュラシック2)

  • 人類学的(クロード)

オープンソースモデルは通常、コミュニティハブとしてHuggingFace上に組織化され、ホストされています。通常、オープンソースモデルはプロプライエタリモデルよりも機能が限定され、小規模です。しかし、プロプライエタリモデルよりもコスト効率が高く、開発者に高い柔軟性を提供できるという利点があります。

オープンソース モデルの例には次のようなものがあります。

  • 安定性AIによる安定拡散

  • BigScienceによるBLOOM

  • LLaMA またはMeta AIによるOPT

  • GoogleFlan-T5

  • GPT-JGPT-Neo 、またはEleuther AIPythia

ステップ2: 下流のタスクに適応する

ベースモデルを選択したら、LLM APIを介してLLMにアクセスできます。他のAPIに慣れている場合、LLM APIの使用は最初は少し違和感があるかもしれません。どのような入力がどのような出力につながるのかが不明瞭だからです。テキストプロンプトに対しては、APIはパターンに一致するテキスト補完を返します。

これはOpenAI APIの使用例です。APIをプロンプトとして入力します。例えば、prompt="これを標準英語に修正してください:\n\nShe no went to the market."のように入力します。

API は、完了した応答 response['choices'][0]['text'] = "She did not go to the market." を含む応答を出力します。

主な課題は、LLM は強力ではあるものの万能薬ではないということです。そのため、重要な質問は、 LLM で望む成果を得るにはどうすればよいかということです。

LLMの生産現場に関する調査[4]では、回答者が挙げた問題点の一つとして、モデルの精度と錯覚が挙げられました。これは、LLM APIから目的の形式で出力を取得するには、ある程度の反復処理が必要になる可能性があり、LLMが必要な特定の知識を持っていない場合、錯覚が生じる可能性があることを意味します。これらの問題に対処するために、以下の方法でベースモデルを下流のタスクに適応させることができます。

  • ヒントエンジニアリング[2, 3, 5]は、入力を調整して出力を期待通りにする手法です。ヒントを改善するには様々な手法が利用可能です( OpenAI Cookbookを参照)。一つのアプローチは、期待される出力形式の例をいくつか提供することです。これは、ゼロショット学習環境や少数ショット学習環境[5]に似ています。LangChainやHoneyHiveのようなツールが登場しヒントテンプレートの管理とバージョン管理を支援しています[1]。

プロジェクトを示唆する画像(チップ・ヒューエン氏[c]からインスピレーションを得て著者が作成した画像)

  • 事前学習済みモデルのファインチューニング[2, 3, 5]は、機械学習における既知の手法です。特定のタスクにおけるモデルのパフォーマンスを向上させるのに役立ちます。これにより学習負荷は増加しますが、推論コストを削減できます。LLM APIのコストは、入力シーケンスと出力シーケンスの長さに依存します。したがって、入力ラベルの数を減らすと、ヒントに例を提供する必要がなくなるため、APIコストを削減できます[2]。

LLMを微調整した画像(チップ・ヒューエン[2]のインスピレーションに基づいて著者が作成した画像)

  • 外部データ:基盤となるモデルは多くの場合、コンテキスト情報が不足しており(例:特定のドキュメントやメールにアクセスできない)、すぐに古くなる可能性があります(例:GPT-4は2021年9月以前のデータで学習されています)。LLMは十分な情報がない場合、妄想に陥る可能性があるため、関連する外部データにアクセスできるようにする必要があります。LlamaIndex (GPT Index)LangChainDUSTなど、 LLMを他のプロキシや外部データに接続(「リンク」)するための中心的なインターフェースとして機能するツールがすでにいくつか存在します[1]。
  • 埋め込み:LLM APIから埋め込み情報(映画の要約や製品の説明など)を抽出し、それに基づいて検索、比較、推奨などのアプリケーションを構築するというアプローチもあります。np.arrayでは埋め込み情報を長期記憶に保存するのに不十分な場合は、 PineconeWeaviateMilvus [1]などのベクターデータベースを使用できます。
  • 代替案:この分野は急速に進化しているため、AI製品においてLLMを活用する方法は他にも数多く存在します。例えば、命令チューニングプロンプトチューニングやモデル蒸留などが挙げられます[2, 3]。

ステップ3: 評価

従来のMLOpsでは、モデルのパフォーマンスを示す指標を用いて、予約された検証セット[5]上でモデルを検証します。しかし、LLMのパフォーマンスはどのように評価されるのでしょうか?良いレスポンスと悪いレスポンスはどのように判断されるのでしょうか?現在、多くの組織ではA/Bテストを実施しているようです[5]。

LLM の評価を支援するために、HoneyHive や HumanLoop などのツールが登場しました。

ステップ4: 展開と監視

LLMの完成度はリリースごとに大きく異なる可能性があります[2]。例えば、OpenAIはヘイトスピーチなどの不適切なコンテンツの生成を軽減するためにモデルを更新しました。その結果、Twitterで「AI言語モデルとして」というフレーズを検索すると、無数のボットがヒットするようになりました。

これは、LLM ベースのアプリケーションを構築するには、基盤となる API モデルの変更を監視する必要があることを示しています。

[Whylabs]( https://whylabs.ai/) や [HumanLoop](https://humanloop.com/) など、LLM を監視するためのツールが登場しています。

03 LLMOps と MLOps の違いは何ですか?

MLOpsとLLMopsの違いは、従来のMLモデルとLLMをAI製品の構築に利用する方法の違いに起因します。これらの違いは主に、データ管理、実験、評価、コスト、レイテンシに影響を及ぼします。

データ管理

従来のMLOpsでは、大量のデータを必要とする機械学習モデルに慣れています。ニューラルネットワークをゼロから学習させるには大量のラベル付きデータが必要であり、事前学習済みモデルの微調整でさえ少なくとも数百のサンプルが必要です。データクリーニングは機械学習開発プロセスにおいて不可欠ですが、大規模データセットの欠点は認識しており、私たちはそれを受け入れています。

LLMOpsにおけるファインチューニングはMLOpsに似ています。ただし、Promptプロジェクトはゼロショットまたは少数ショットの学習設定です。つまり、厳選された少数のサンプルのみを使用します[5]。

実験

MLOpsでは、モデルをゼロからトレーニングする場合でも、事前トレーニング済みのモデルを微調整する場合でも、実験は非常に似ています。どちらの場合も、モデルアーキテクチャ、ハイパーパラメータ、データ拡張などの入力と、メトリクスなどの出力を追跡します。

しかし、LLMOpsにおいては、 Promptプロジェクトを実行するか、それとも微調整プロセスを実行するかが問題となります[2, 5]。LLMOpsにおける微調整はMLOpsと似ているように見えるかもしれませんが、Promptプロジェクトでは、Promptの管理を含め、異なる実験設定が必要となります。

評価する

従来のMLOpsでは、モデルのパフォーマンスは、予約された検証セット[5]における評価指標を用いて評価されます。LLMのパフォーマンス評価はより困難であるため、現在、多くの組織ではA/Bテストが用いられているようです[5]。

料金

従来のMLOpsのコストは通常​​、データ収集とモデル学習にかかるのに対し、LLMOpsのコストは推論にかかるものです[2]。実験中に高価なAPIを使用することで多少のコストがかかることは予想されますが[5]、Chip Huyen[2]は、長いヒントのコストは推論にかかることを示しています。

遅れ

LLMプロダクション調査[4]の回答者が挙げたもう一つの課題はレイテンシです。LLMの完了にかかる時間はレイテンシに大きな影響を与えます[2]。MLOpsでもレイテンシは考慮する必要がありますが、LLMOpsでは開発における実験のスピード[5]とプロダクションにおけるユーザーエクスペリエンスの両方にとって重要な問題であるため、より顕著です。

04 LLMOpsの未来

LLMOpsは新興分野です。急速な発展を遂げているため、予測は困難です。「LLMOps」という用語が長期的に意味を持ち続けるかどうかさえ不透明です。確かなのは、LLMの新たなユースケースが数多く登場し、LLMライフサイクルを管理するためのツールやベストプラクティスも登場するということです。

人工知能分野は急速に進化しており、今私たちが書いたものはすべて1ヶ月以内に時代遅れになる可能性があります。LLM駆動型アプリケーションの本番環境への導入はまだ初期段階です。まだ答えが出ていない疑問が数多くありますが、今後の展開は時が経てば分かるでしょう。

  • 「LLMOps」という用語は長期的に存続するのでしょうか? - MLOps の波の中で、LLMOps はどのように進化していくのでしょうか? 両者は統合されるのでしょうか、それとも独立した操作セットになるのでしょうか? - 人工知能の「Linux モーメント」はどのように発展していくのでしょうか?

近い将来、多くの開発や新しいツール、ベストプラクティスが登場すると確信しています。さらに、基本モデルのコストと遅延を削減するための取り組みも既に始まっています[2]。まさに今が興味深い時期です!

05 要約

OpenAIのChatGPTのリリース以来、LLMは人工知能分野で注目を集めています。これらの深層学習モデルは人間の言語による出力を生成できるため、会話型AI、ライティングアシスタント、プログラミングアシスタントなどのタスクに強力なツールとして活用されています。

しかし、LLM 駆動型アプリケーションを本番環境に導入するには独自の課題があり、「LLMOps」という新しい用語が登場しました。これは、開発、展開、保守を含む LLM 駆動型アプリケーションのライフサイクルを管理するための一連のツールとベストプラクティスを指します。

LLMOpsはMLOpsのサブカテゴリと見なすことができます。ただし、LLM駆動型アプリケーションの構築手順は、従来のMLモデルを使用したアプリケーションの構築手順とは異なります。

焦点はLLMをゼロから学習することではなく、事前学習済みのLLMを下流のタスクに適応させることにあります。これには、ベースモデルの選択、下流のタスクでLLMを使用し、それらを評価し、モデルのデプロイとモニタリングが含まれます。

LLMOpsはまだ比較的新しい分野ですが、AI業界でLLMが普及するにつれて、今後も発展と進化を続けると予想されます。LLMとLLMOpsの台頭は、AI駆動型製品の構築と保守における大きな変化を表しています。

LLMOpsに関する推奨読書

1. W&BのLLMホワイトペーパー
LLMをゼロからトレーニングするための最新のベストプラクティス
2. OpenAI APIを使用してPythonでGPT-4を設定する
OpenAI API を使用して、Python でマシン上で GPT-4 をセットアップして実行します。

参考文献

[1] D. HersheyとD. Oppenheimer (2023). 言語モデルのためのDevTools - 未来を予測する(2023年4月14日アクセス)
[2] C. Huyen (2023). LLMアプリケーションを本番環境向けに構築する(2023年4月16日アクセス)
[3] A. Karpathy (2022). ディープニューラルネット:33年前と33年後(2023年4月17日アクセス)。
[4] MLOpsコミュニティ(2023年)。LLM の運用応答(2023年4月19日アクセス)
[5] S. Shankar (2023). Twitterスレッド(2023年4月14日アクセス)