LLMOps：大規模言語モデルの操作を理解する

この記事では、大規模言語モデル（LLM）をベースにした製品・サービス開発方法と、機械学習の運用（MLOps）方法をどのように変えているかを見ていきましょう。
Created on August 15|Last edited on August 17
Comment
このレポートは、Leonieによる「﻿﻿Understanding LLMOps: Large Language Model Operations﻿﻿﻿﻿」の翻訳です。
﻿
「申し訳ございません。このように発送することはできません。これは大きすぎます…」  - 製造中の大規模言語モデル（LLM）（作者が描画した画像）
﻿OpenAIのChatGPTのリリースは、大規模言語モデル（LLM）の運用に関するパンドラの箱を開けてしまったような感覚です。隣人が人工知能に関する雑談であなたを悩ますようになっただけでなく、機械学習（ML）コミュニティは、もう1つの新しい用語、「LLMOps」について話すようになっています。
LLMは、AIを使った製品の構築方法とメンテナンス方法を変えつつあります。これによって、LLMを使ったアプリケーションのライフサイクルに関する新しいツールやベストプラクティスが生み出されます。
この記事ではまず、新たに現れた用語「LLMOps」とその背景について説明します。LLMを使ったAI製品の構築が、標準的なMLモデルよりもいかに多様であることについて考察します。また、これらの違いに基づいて、MLOpsがLLMOpsとどのように異なるかを見ていきます。最後に、近い将来、LLMOps空間ではどのような発展を期待できるかについて検証します。
以下は、この記事で扱う内容です： 
Table of ContentsLLMOpsとは？LLMOpsが出現した理由LLMOpsに含まれるステップステップ1：基盤モデルの選択ステップ2：ダウンストリームタスクへの適合ステップ3：評価ステップ4：デプロイとモニタリングLLMOpsとMLOpsの違いデータ管理実験評価コストレイテンシLLMOpsの将来概要LLMOpsに関する推奨文献リファレンス
﻿
﻿
LLMOpsとは？LLMOpsという言葉は、「大規模言語モデルの運用」を指します。「LLMOpsはLLM向けのMLOpsである」、というのが簡単な定義です。つまり、基本的にLLMOpsは、開発、展開、およびメンテナンスを含むLLMを使ったアプリケーションのライフサイクルを管理するための新しいツールとベストプラクティスの組み合わせです。
「LLMOpsはLLM向けのMLOpsである」と言いましたが、LLMとMLOpsという用語をまず定義する必要があります。
LLM（大規模言語モデル）は、人間の言語で出力を生成できるディープラーニングモデルです（このため、「言語モデル」と呼ばれます）。モデルには数十億のパラメーターが含まれ、数十億の言葉でトレーニングされます（このため、「大規模言語モデル」と呼ばれます）。
MLOps（機械学習の運用）は、MLを使ったアプリケーションのライフサイクルを管理するためのツールとベストプラクティスの組み合わせです。
それでは、詳細を見ていきましょう。 
LLMOpsが出現した理由﻿BERTやGPT-2などの初期のLLMは、2018年には存在しています。しかし、その約5年後の現在、LLMOpsという概念が急速に拡大しつつあります。主な理由は、LLMは、2022年12月のChatGPTのリリースがメディアの注目を集めたことです。
LLMの出現（[1]から構想を得た作者による画像）
それ以来、LLMの能力は幅広く活用されるようになってきました：
チャットボットには、有名なChatGPTから、よりカジュアルでパーソナルなもの（子供時代の自分とチャットするMichelle Huangなど）までさまざまです。
ライティングアシスタントには、編集と要約（例：Notion AI）、コピーライティング（例：Jasperおよびcopy.ai）、契約管理（例：lexion）用の専門的なツールなどがあります。
プログラミングアシスタントには、ライティングとコードのデバッグ（GitHub Copilotなど）から、コードのテスト（Codium AIなど）、セキュリティ脅威の検出（Socket AIなど）があります。
多くの人々がLLMを使ったアプリケーションを開発して製品化しながら、自らの体験を共有しています：
「LLMを使って何か優れたものを作るのは簡単ですが、製品化できる水準にするのは困難です。」- Chip Huyen [2]製品化できるようなLLMを使ったアプリケーションの構築には、標準的なMLモデルを使用したAI製品の構築とは異なり、独自の一連の課題が付随することが明らかになっています。これらの課題に対処するために、私たちは、LLMアプリケーションライフサイクルを管理するための新しいツールとベストプラクティスを開発する必要があります。このように、「LLMOps」という言葉がより頻繁に使われるようになっています。
LLMOpsに含まれるステップLLMOpsに含まれるステップは、ある意味でMLOpsと似ています。ただし、LLMを使ったアプリケーションの構築ステップは、基盤モデルの発展とともに変化しています。つまりLLMを最初からトレーニングする代わりに、学習済みのLLMをダウンストリームタスクに適合させること重点が置かれて来ています。
すでに1年以上前に、Andrej Karpathy氏[3] は、AI製品の構築プロセスが今後どのように変わるかについて説明していました。
しかし、最も重要な傾向[…]は、対象のタスクでニューラルネットワークをゼロからトレーニングする設定全体は、[…] ファインチューニング手法が出て来て急速に時代遅れになっています。これは特に、GPTなどの基盤モデルの出現によるものです。これらの基盤モデルは、充実したコンピューティングリソースがある限られた組織によって構築されています。多くのアプリケーションは、ファインチューニングでモデルパラメーターの一部を軽く微調整したり、プロンプトエンジニアリングや、データやモデルを推論時にに抽出するオプションステップによって達成されます。[…] - Andrej Karpathy [3]この引用は、初めて読んだ時は圧倒されるかもしれません。しかし、ここでは現在進行中の状況がすべて正確に要約されているため、以下のサブセクションで段階を追って説明します。 
ステップ1：基盤モデルの選択基盤モデルは大量のデータで学習済みのLLMであり、さまざまなダウンストリームタスクに使用できます。基盤モデルをゼロからトレーニングすることは複雑で時間がかかり、非常に高額になるため、必要なトレーニングリソースを有している組織は多くありません[3]。
これを大局的に捉えるには：Lambda Labsで2020年に実施された研究によると、OpenAIのGPT-3（1,750億パラメーターを使用）のトレーニングでは、Tesla V100クラウドインスタンスを使用して、355年と460万ドルが必要になります。
﻿
AIは現在、コミュニティが「Linux moment」と呼んでいるものを辿っています。現在開発者達は、パフォーマンス、コスト、使いやすさ、および柔軟性の間の妥協点に基づいて、2種類の基盤モデル、つまりプロプラアトリまたはオープンソースモデルから選択する必要があります。
プロプライエタリとオープンソースの基盤モデル（Fiddler.aiから構想を得た、作者による画像）
プロプライエタリは、大規模な専門家チームと高額のAI予算を持つ企業が所有する、クローズドソースの基盤モデルです。これらは通常、オープンソースモデルより大きく、パフォーマンスがより優れています。また、既製品であり、使いやすいツールです。
プロプライエタリの主なマイナス面は、高額なAPI（アプリケーションプログラミングインターフェース）です。また、クローズドソースの基盤モデルは、開発者にとって柔軟性の面で劣っています。
プロプライエタリプロバイダーの例：
﻿OpenAI (GPT-3、GPT-4)
﻿co:here﻿
﻿AI21 Labs (Jurassic-2)
﻿Anthropic (Claude)
オープンソースモデルは多くの場合、HuggingFace上でコミュニティハブとして編成され、ホスティングされています。通常、より小規模なモデルであり、プロプライエタリより機能性が劣ります。しかし利点としては、プロプライエタリよりも費用効果が高く、より高い柔軟性を開発者に提供します。
オープンソースモデルの例：
﻿Stable Diffusion by Stability AI ﻿
﻿BLOOM by BigScience
﻿LLaMA またはOPT (Meta AI)
﻿Flan-T5 by Google﻿
﻿GPT-J, GPT-Neo または Pythia (Eleuther AI)
ステップ2：ダウンストリームタスクへの適合基盤モデルを選んだら、APIを通してLLMにアクセスできます。他のAPIを使った作業に慣れている場合、LLM APIを使った作業は、最初は少し変わっていると感じるでしょう。入力から生じる出力が事前に常に明確ではないためです。テキストプロンプトを考えると、APIはテキストコンプリーションを返し、要求に最善の結果を返します。
以下は、OpenAI APIの使用方法の例です。API入力をプロンプトとして提供します。例：prompt = "Correct this to standard English:\n\nShe no went to the market."
import openai
﻿
openai.api_key = ...
﻿
response = openai.Completion.create(
	engine = "text-davinci-003",
	prompt = "Correct this to standard English:\n\nShe no went to the market.",
	# ...
	)
APIは、コンプリーションを含む応答を出力します。 response['choices'][0]['text'] = "She did not go to the market.」
﻿
主な課題は、LLMは高性能ではあっても全能ではないことです。このため次の重要な問題があります：LLMに必要な出力を提供させるにはどうすれば良いか？
﻿LLM in production survey（生産中のLLMに関する調査） [4]で回答者が言及した1つの懸念は、モデル精度とハルシネーションです。つまり、LLM APIから必要な形式で出力を得るには、多少の反復が必要になることがあります。また、必要な特定の知識がない場合、LLMでハルシネーションが発生することがあります。これら懸念に対処するために、以下の方法で基盤モデルをダウンストリームタスクに適合させることができます：
プロンプトエンジニアリング[2、3、5] は、出力が期待と一致するように入力を調整するための手法です。さまざまなコツを使ってプロンプトを改善できます（OpenAI Cookbookを参照）。1つの方法は、予測される出力形式の例をいくつか提供することです。これは、zero-shot学習またはfew-shot学習の設定に似ています[5]。LangChainやHoneyHiveなどのツールがすでに登場し、プロンプトテンプレートの管理とバージョニングに役立っています[1]。
プロンプトエンジニアリング（Chip Huyenから構想を得た、作者による画像 [c]）
学習済みモデル[2、3、5]の微調整は、MLにおける既知の手法です。これは、特定のタスクでのモデルのパフォーマンスの改善に役立つ場合があります。トレーニングの労力を増加させずに、推論のコストを削減できます。LLM APIのコストは、入力と出力シーケンスの長さによって異なります。このため、入力トークンの数を減らすとAPIコストが減ります。これは、プロンプトで例を提供する必要がなくなるためです[2]。
微調整LLM （Chip Huyenから構想を得た、作者による画像 [2]）
外部データ: 多くの場合、基盤モデルにはコンテキスト情報（例：特定のドキュメントまたは電子メールへのアクセス）が欠けており、すぐに時代遅れになることがあります（例：GPT-4は2021年9月前のデータ上でトレーニングさています）。十分な情報がないと、LLMではハルシネーションが発生することがあるため、関連する外部データへのアクセスをLLMに与える必要があります。これにはLlamaIndex （GPT Index）、LangChain、またはDUSTなどのツールが存在します。これは、LLMを他のエージェントと外部データに接続する（「連鎖させる」）ための中核的インターフェースとして機能できます[1]。
エンべディング： もう1つの方法は、LLM APIからエンべディングの形で情報を抽出して（例：映画のサマリー、製品説明）、その上にアプリケーションを構築します（例：検索、比較、推奨）。 np.arrayが長期記憶用のエンべディングを保存するのに十分でない場合、Pinecone、Weaviate、またはMilvusなどのベクトルデータベースを使うことができます[1]。
代替手段：この分野が急速に発展するにつれ、AI製品でLLMを利用する方法が増加しています。たとえば、インストラクションチューニング/プロンプトチューニングおよびモデル蒸留などです[2、3]。
ステップ3：評価標準的なMLOpsでは、MLモデルは、モデルのパフォーマンスを示すメトリクスを使って、ホールドアウト検証セット[5]上で検証されます。しかし、LLMのパフォーマンスはどのように評価するのでしょうか？応答が正しいかそうでないかをどのように判断できるのでしょうか？現在企業ではは、モデルのA/Bテストが実施されているようです[5]。
﻿
LLMを評価するための、HoneyHiveやHumanLoopなどのツールが登場しています。
💡
ステップ4：デプロイとモニタリングLLMのコンプリーションは、リリース間で大きく異なります[2]。たとえば、OpenAIは、不適切なコンテンツ生成（例：ヘイトスピーチ）を低減するようモデルを更新しました。結果として、Twitter上で「AI言語モデルとして」という語句を検索すると、無数のボットが現れます。
﻿
Want a window into Twitter's totally unsolved bot problem?

Search for "as an AI language model" 

 h/t @lcamtuf pic.twitter.com/d1WcokePOq
— John Scott-Railton (@jsrailton) April 17, 2023
﻿
これは、LLMを使ったアプリケーション構築には、内在するAPIモデルの変化をモニタリングする必要があることを示しています。
﻿WhylabsやHumanLoopなど、LLMのモニタリングツールがすでに登場しています。
LLMOpsとMLOpsの違いMLOpsとLLMOpsの違いは、標準的なMLモデル vs LLMを使ってAI製品を構築する方法の違いによって生じます。違いは、データ 管理、実験、評価、コスト、およびレイテンシに主に影響を与えます。
データ管理標準的なMLOpsでは、私たちはデータが足りないMLモデルに慣れています。ニューラルネットワークをゼロからトレーニングするには、多数のラベル付きデータが必要であり、学習済みモデルの微調整でさえも、少なくとも数百のサンプルが必要です。データクリーニングはML開発プロセスに不可欠であり、私たちは大規模データセットには不完全性があることを理解し、受け入れています。
LLMOpsでの微調整はMLOpsに似ています。しかし、プロンプトエンジニアリングはzero-shot学習またはfew-shot学習設定です。つまり、私たちには手作業で選んだ少量のサンプルしかありません[5]。
実験MLOpsでの実験は一般に、モデルをゼロからトレーニングするか、学習済みモデルを微調整します。いずれの場合も、モデルアーキテクチャー、ハイパーパラメーター、データ拡張などの入力、およびメトリクスなどの出力を追跡します。
しかしLLMOpsでの実験は、プロンプトエンジニアリングまたはファインチューニングになります[2、5]。ファインチューニングはLLMOpsとMLOpsの間で似ていますが、プロンプトエンジニアリングでは、プロンプトの管理を含むさまざまな実験セットアップが必要です。
評価標準的なMLOpsでは、モデルのパフォーマンスは、評価メトリクスを使ってホールドアウト検証セットで評価されます[5]。LLMのパフォーマンスは評価がより難しいため、現在企業でははA/Bテストを使用しているようです[5]。
コスト従来のMLOpsではデータ収集とモデルトレーニングにコストがかかる一方で、LLMOpsでは推論にコストがかかります[2]。実験中に高額のAPIを使うことで多少のコストがかかりますが[5]、Chip Huyen[2]は、長いプロンプトでは推論にコストがかかることを示しています。
レイテンシデプロイ後のLLMに関する調査[4]で回答者が言及したもう1つの懸念は、レイテンシでした。LLMのコンプリーションの長さは、レイテンシに大きな影響を与えます[2]。レイテンシの懸念はMLOpsでも考慮する必要がありますが、この懸念はLLMOpsにおいてより顕著です。というのはレイテンシは、開発中の実験速度[5]と生産中のユーザーエクスペリエンスに関する大きい問題であるためです。
LLMOpsの将来LLMOpsは新たな分野です。この空間は急速に発展しているため、予測は困難です。「LLMOps」という用語が広まっているかどうかは不確かでさえあります。LLMの新しいユースケース、LLMライフサイクルを管理するためのツールとベストプラクティスが今後多数現れることは確実です。
AIの分野は急速に発展しており、今執筆していることが1ヶ月後には時代遅れになる可能性もあります。私たちはまだ、LLMを使ったアプリケーションの製品化の初期段階にいます。回答が得られていない質問は多数あり、物事がどのように展開していくかは、時間が経たないと分かりません。
「LLMOps」という用語は広まっているのでしょうか？
MLOpsの観点から、LLMOpsはどのように発展するのでしょうか？これらはともに変化する、あるいは別々の運用になるのでしょうか？
AIの「Linux moment」はどのように展開するのでしょうか？
多くの開発と新しいツール、およびベストプラクティスがまもなく現れるのは確実です。また、すでに基盤モデルのコスト削減とレイテンシ短縮に向けた取り組みが行われています[2]。現在は、非常に興味深い時期です！
概要OpenAIのChatGPTのリリース以来、LLMは現在、AIの領域で注目の話題です。これらのディープラーニングモデルは人間の言語で出力を生成でき、会話型AI、ライティングアシスタント、プログラミングアシスタントなどのタスク向けの優れたツールになります。
ただし、LLMを使ったアプリケーションを製品化することで、独自の課題が提起されます。これは「LLMOps」という新しい用語の出現につながっています。これは、開発、展開、およびメンテナンスを含む、LLMを使ったアプリケーションのライフサイクルを管理するための新しい一式のツールとベストプラクティスを意味します。
LLMOpsは、MLOpsのサブカテゴリーとして見なすことができます。ただし、LLMを使ったアプリケーション構築に伴うステップは、標準的なMLモデルを使ったアプリケーションの構築のステップとは異なります。
LLMをゼロからトレーニングする代わりに、学習済みのLLMをダウンストリームタスクに適合させることを重視する必要があります。これには、基盤モデルの選択、ダウンストリームタスクでのLLMの使用、LLMの評価、およびモデルの展開とモニタリングが関与します。
LLMOpsはまだ比較的新しい分野である一方、LLMがAI業界でより広く行き渡るにつれて、発展、進化し続けることが予測されます。全体的に、LLMとLLMOpsの利用増加は、AIを使った製品の構築とメンテナンスにおける大きな変化を表しています。
LLMOpsに関する推奨文献W&B's LLM Whitepaper
Current Best Practices for Training LLMs from Scratch
GPT-4o Python quickstart using the OpenAI API
Getting set up and running GPT-4o on your machine in Python using the OpenAI API.
﻿
リファレンス[1] D. Hershey and D. Oppenheimer（2023年）。DevTools for language models - predicting the future（言語モデル用開発ツール  - 未来を予測する） （2023年4月14日にアクセス）
[2] C. Huyen（2023年）。Building LLM applications for production（プロダクション向けLLMアプリケーションの構築） （2023年4月16日にアクセス）
[3] A. Karpathy（2022年）。Deep Neural Nets: 33 years ago and 33 years from now（ディープニューラルネットワーク：現在から33年前と33年後） （2023年4月17日にアクセス）
[4] MLOps Community（2023年）。LLM in production responses（製造中のLLMの応答） （2023年4月19日にアクセス）
[5] S. Shankar（2023年）。Twitterスレッド（2023年4月14日にアクセス）
﻿
Add a comment
Iterate on AI agents and models faster. Try Weights & Biases today.