LLMOpsを始めよう：より良いAIアプリケーションの構築
OpenAIのChatGPTの出現は、企業における大規模言語モデル(LLMs)への関心の波を呼び起こした。大手ハイテク企業や研究機関は現在、LLMをより利用しやすくし、データ・インフラを強化し、用途に合わせてモデルを微調整し、幻覚や偏見などの問題を監視するよう努めている。この関心の高まりは、大規模言語モデル運用（LLMOps）をサポートするテクノロジーベンダーに対する需要の急増にもつながっている。これらのベンダーは、LLMの開発、微調整、本番環境へのデプロイのための包括的なワークフローを提供しています。
先日のUnstructured Data Meetupでは、Union.aiの機械学習エンジニアであるSage ElliottがLLMのデプロイと管理について議論し、これらのモデルをビジネスアプリケーションに統合するために必要なツール、戦略、ベストプラクティスに関する貴重な洞察を提供した。彼のプレゼンテーションは、特にAI開発者や運用管理者にとって有益であり、本番環境におけるLLMアプリケーションの信頼性とスケーラビリティの確保に焦点を当てていた。
この投稿では、Sageの講演から重要な洞察をまとめ、LLMOpsの概念と方法論について説明する。
<< セージ・エリオットの講演のリプレイを見る >
LLMOpsとは何か？
LLMOpsはLarge Language Model Operationsの略で、MLOpsに似ていますが、特に大規模な言語モデル（LLM）のためのものです。LLMOpsを理解するために、まずMLOpsを解き明かしましょう。
MLOps** (Machine Learning Operations)とは、本番環境で機械学習モデルを効率的にデプロイし、メンテナンスするために使用されるプラクティスとツールのことである。これはDevOps（開発と運用）の延長であり、アプリケーション開発と運用を一貫したプロセスに統合する。このアプローチでは、開発と運用の両方が別々のサイロで機能するのではなく、一緒に考慮されることが保証される。
MLOpsとは](https://assets.zilliz.com/What_are_ML_Ops_49f2255e73.jpg)
MLOpsとは？画像出典:_ https://ml-ops.org/content/MLOps-principles
DevOpsの方法論が登場する以前は、開発チームはアプリケーションやアップデートをできるだけ早く書くことに集中し、運用チームはアプリケーションの安定性、有効性、ユーザーエクスペリエンスを優先していた。この区分化されたアプローチは、しばしば非効率を招き、遅い開発と頻繁でないアップデートを伴う最適でないアプリケーションにつながった。
DevOpsは、開発チームと運用チーム間のコラボレーションを促進し、より合理的で効率的なワークフローを確保することで、このプロセスを変革する。MLOpsはこの原則を機械学習に拡張し、MLモデルのデプロイと保守の課題に対処します。
LLMOpsは、その原則を大規模言語モデル（LLM）アプリケーションに適用することで、MLOpsの全体的なアプローチに磨きをかけます。LLMアプリケーションの開発、デプロイメント、メンテナンス、継続的改善のすべての側面に関係しています。
Sage社のLLMOpsの定義である「Building AI Together」（共にAIを構築する）には、協力という中心的な哲学も内在しており、開発、運用、製品管理など、関連するすべてのビジネス部門が、最もパフォーマンスの高いLLMアプリケーションをタイムリーかつコスト効率の高い方法で製造するために協力しなければならないという考えが強調されています。
##継続的インテグレーションと継続的デリバリー／デプロイメント（CI/CD）
DevOpsと同様に、LLMOpsの基本原則の1つは、継続的インテグレーション/継続的デプロイメント（CI/CD）です。
継続的インテグレーション(CI)とは、アプリケーションのアップデートを自動的に取り込み、メインブランチ、つまり現在本番稼動しているLLMアプリケーションのバージョンにマージすることである。開発者が GitHub などのリポジトリにコードを投稿すると、このアクションが自動化されたワークフローをトリガーし、アップデートが統合の準備ができているかどうかを検証する。CIは開発チームによる頻繁な変更を促し、コードのマージ競合を避けるのに役立つ。
継続的デリバリー／デプロイメント（CD） は、統合と検証の後、アプリケーションの変更を本番環境に自動的にデプロイするプロセスを指す。このプロセスには、機能テストやユーザー受け入れテスト、インフラ構成などのさらなるテストが含まれる。
継続的デリバリーとデプロイはしばしば同じ意味で使われますが、両者には違いがあります。継続的デリバリーは自動的な本番デプロイメントの手前で停止し、通常は組織や規制のコンプライアンスを確保するために人手による最終チェックを行う。逆に、継続的デプロイは、アプリケーションのアップデートを自動的にユーザーにリリースする。この概念を念頭に置くと、本当の意味での継続的デプロイは稀であり、特にLLMアプリケーション開発はまだ始まったばかりである。
LLMOps を使うべき人とは？
要するに、LLMアプリケーションを開発している人なら誰でも、ある程度はLLMOpsを利用すべきだ。
一方では、LLMOpsはプロダクションレベルのAIアプリケーションには不可欠であり、正確なインフラストラクチャはアプリケーションのニーズに依存します。これとは対照的に、シンプルで個人的なAIプロジェクトであっても、シンプルなLLMOpsパイプラインを実装することで恩恵を受けることができます。
LLMOpsをAIアプリケーションに統合することで、次のようなメリットが得られます：
リソース管理とスケーラビリティ**：最適なユーザー・エクスペリエンスを提供するために計算リソースの使用を意識する。LLMを効果的に実行するには大量のメモリを必要とするため、ハードウェア、つまりGPUがアプリケーションのニーズに対して十分かどうかを判断できることは非常に重要です。
モデルの更新と改善**：モデルの失敗や欠点をより短時間で認識し、それに応じてモデルを更新すること。
倫理的で責任あるAIの実践**：AIアプリケーションの意図された目的と、その誤作動の潜在的な結果を意識すること。LLMに関する主な懸念事項の1つは、「幻覚を見る」、すなわち不正確な出力や無関係な出力を提供する傾向があることです。この問題は、例えば医療アドバイスを与えるためのアプリケーションにおいて致命的な結果をもたらす可能性があります。
この問題は、例えば医学的な助言をするようなアプリケーションでは致命的となりうる。
CBInsightsが作成したマーケットマップでは、企業がLLMプロジェクトを最初から最後まで管理するのを支援する12のカテゴリーにわたる90以上の企業が特定されています。このランドスケープはLLMOps市場の規模も示しています。
LLMOps市場ランドスケープ](https://assets.zilliz.com/LLM_Ops_market_landscape_6ac51baf56.png)
LLMOps市場の展望：企業がLLMプロジェクトを最初から最後まで管理するのを支援する12のカテゴリーにわたる90以上の企業(英語)
理解しやすくするために、Sageは簡略化したLLMOpsパイプラインを作成した。
簡略化されたLLMOpsパイプライン
この図の要素を説明しよう：
システム・プロンプト:** ユーザー入力はシステム・プロンプトの一部となり、LLMに入力される。
モデル：*** LLMは回答生成のためのアプリケーションを支える。
ガードレールユーザーが適切な入力しかしないように、つまり有害または攻撃的なコンテンツを生成させようとするモデルを確実にするために導入したコントロール。
データストア**：MilvusやZilliz Cloud(マネージドMilvus)のようなベクターデータベース。これらのデータベースは、LLMに長期記憶と文脈に基づくクエリ情報を提供し、LLMがより正確な結果を生成するのに役立つ。このコンポーネントは、Retrieval Augmented Generation (RAG)アプリケーションにおいて特に有益である。
モニターLLMアプリケーションを継続的に監視するためのツール。
CI/CDオーケストレーター**：アプリケーションを管理し、本番環境への統合とデプロイの自動化を支援するプラットフォーム。
##LLMOpsを始めよう
LLMOpsは急速に変化しており、ベンダーは日々新しいLLMOpsツールをリリースしていますが、幸いなことにLLMOpsの基本原則は変わりません。
ここでは、LLMOpsを始めるためのシンプルな3ステップの考え方を紹介する。
1.**モデルを出荷する
2.**モデルの性能をモニターする。
3.**モデルの改良
それぞれのステップを詳しく見てみよう。
モデルを出荷する
モデルの出荷とは、LLM アプリケーションをできるだけ早く本番環境にデプロイすることです。このアプローチは、モデルと対話するユーザーから正確なデータを取得し、ユーザーのニーズにLLMアプリケーションを適合させる方法を迅速に学ぶことができるため、不可欠です。代表的な例はチャットボットアプリケーションで、テスト環境で単に入力を予測するよりも、実際のユーザー入力とそれに対するモデルの出力の例を得る方がはるかに役に立ちます。
HuggingFace Spaces は、モデルの本番環境への出荷を効率化する素晴らしいリソースだ。これはほとんどのMLアプリケーションのホスティング・プラットフォームであり、LLMを動かすための低コストのクラウドGPUを提供するため、プロトタイピングに理想的です。また、プライベートスペースにアプリケーションをデプロイして、LLMアプリケーションをテストしたい人に限定したアクセスを提供したり、HuggingFaceの大規模で活発なコミュニティからのフィードバックを得るために公開することもできます。
HuggingFaceスペース](https://assets.zilliz.com/Hugging_Face_Spaces_4ae8674167.png)
**ハギングフェイス・スペース
HuggingFaceは、モデルデプロイのためのSpaces以上のものを提供している。彼らの提供するサービスの中心は、音声、コンピュータビジョン、言語モデルを含む、64万を超えるオープンソースのMLモデルの膨大なコレクションである。さらにHuggingFaceは、エンドツーエンドのLLMアプリケーションを構築するために必要なすべてのコンポーネントを含むいくつかのライブラリを、トレーニングに必要なデータセットとともに提供しています。
HuggingFaceでどのようにLLMアプリケーションを構築できるかを説明するために、Transformer（LLMにアクセスするため）とDatasets（トレーニングデータにアクセスするため）ライブラリを使ってモデルをダウンロードし、トレーニングする方法を見てみましょう。
まず、適切なライブラリをインストールする必要があります：
pip install torch transformers datasets
次に、アプリケーションで使いたいLLMをダウンロードする。上述したように、HuggingFaceには何十万ものモデルがあり、それぞれがアプリケーションに統合するために必要なコードを提供しています。例えば、Llama 3モデルを次のようにロードします：
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")
次に、モデルを微調整するためにデータセットをロードする必要があります。この例では、HuggingFaceの多くの利用可能なデータセットのうちの1つを使う。しかしながら、もしあなたがドメイン固有もしくはタスク固有の目的のために、あなた自身のデータを使いたいのであれば、単にファイルパスをあなたのトレーニングデータフォルダを指すものに置き換えるだけでよいのです。
from datasets import load_dataset
dataset = load_dataset("talkmap/telecom-conversation-corpus")
データセットを読み込んだら、LLMが処理しやすいようにトークン化する必要がある。Llama 3モデルに関連付けられたトークナイザーを使って、事前学習プロセスと同じようにデータをトークン化し、同じトークン対インデックス、つまり "語彙 "を維持する必要があります。このステップはほんの数行のコードで完了します。
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")
# トークナイザー関数を定義する
def tokenize_function(examples)：
return tokenizer(examples["text"], padding="True", truncation=True)
tokenized_dataset = dataset.map(tokenize_function, batched=True)
次に、TrainingArguments オブジェクトを使用して、モデルを微調整するためのハイパーパラメータ設定を行う。この設定には109個のオプションのパラメータがあり、学習プロセスを細かく制御することができる。お好みであれば、特定のパラメータを渡さず、デフォルトの設定に依存することもできます。
from transformers import TrainingArguments
training_args = TrainingArguments()
最後に、モデルの要素を定義した後、それらをトレーニングオブジェクトの中に配置し、以下のように関連するtrain関数を呼び出すだけです：
trainerオブジェクトの要素が構成されたので、あとはそれを組み合わせて、Llama 3のベースモデルを微調整するためにtrain`関数を呼び出すだけです。
from transformers import Trainer
trainer = Trainer(
model=model、
dataset=dataset、
args=training_args、
)
trainer.train()
たった数行のコードで、LLMアプリケーションに使える言語モデルをダウンロードし、学習させることができます。
HuggingFaceがどのようにLLMアプリケーションの開発を簡素化するかについてのより具体的で詳細な例については、私たちのMilvusを使ったQAアプリケーション構築のチュートリアルをご覧ください。
継続的なモニタリングと評価
LLMアプリを本番環境にデプロイしたら、以下の理由でアプリを監視することが不可欠です：
本番環境でモデルがどのように機能するか、意図したユースケースを満たしているか？ユーザーの期待に沿っているか？
モデルをどのように改善できるか？
その後、モデルに改良を加えたとき、期待された性能の向上につながるか、あるいはさらなる変更が必要か。
モデルが消費する計算リソース：アプリケーションのパフォーマンスを向上させるために、GPUなど、より多くのリソースを割り当てる必要がありますか？さらに、消費するリソースで、アプリケーションはどの程度スケーラブルですか？
例えば、追加トレーニングやファインチューニングなどの変更後、アプリケーションはどのように動作しますか？
評価メトリクスは、ユーザーのプロンプトに応答して正しい出力を生成するモデルの能力を測定するのに役立ちます。最も一般的に使用されるメトリクスには、BLEU、ROUGE、BERTScoreがあります。
| 指標 | |
| BLEU（Bilingual Evaluation Understudy）｜機械翻訳でよく使われ、n-gram（連続するn個の単語）の重なりに基づいて、モデルが生成したテキストと参照テキストの類似度を測定する。 | |
| ROUGE（Recall-Oriented Understudy for Gisting Evaluation）｜ n-gramの重複、単語列、単語ペアを参照要約と比較することで、モデル生成要約の品質を評価する。 | |
| BERTScore (Bidirectional Encoder Representations from Transformers) Score｜意味的な意味を捉えるためにBERT埋め込みを活用することで、テキストの類似性を測定。 |
さらに、LLMアプリケーションのパフォーマンスを評価する定性的な方法が他にもあります。
アウトプットの正確さと関連性の評価：回答はうまく作られているかもしれませんが、入力プロンプトについてどの程度役に立っているでしょうか？それはユーザーが期待する価値を提供していますか？
ユーザーがLLMアプリケーションをどのように使用し、それに応じて微調整する必要があるかどうかを判断します。
応答のセンチメントを評価する：アプリケーションは望ましいトーンで応答しているか？
ジェイルブレイク（脱獄）、つまり、モデルに本来出すべきでない出力を出させようとする試みはないか？例えば、チャットボットに自家製武器の作り方を尋ねるなど。このアプローチによって、アプリケーションにガードレールを含めるべきか、すでに実装しているものを改善すべきかが決まります。
LLMアプリケーションを継続的にモニタリングすることは複雑ではありません。LLMを搭載したアプリケーションを評価するためのツールは、LangKit、Ragas、Continuous Eval、TruLens-Eval、LlamaIndex、Phoenix、DeepEval、LangSmith、OpenAI Evalsなどがあります。
LLMアプリケーションの評価についての詳細は、RAG評価の記事をご覧ください。
モデルの改善
モデルのモニタリングから得られるメトリクスとフィードバックを使用することで、LLMの新しい反復をはるかに短時間で行うことができます。改善を実施する強力で効率的な方法は、FlyteのようなMLOpsオーケストレーターをパイプラインに統合することです。MLOpsオーケストレーターは、以下の方法でLLMアプリケーションの管理を簡素化します：
自動テスト:**変更が加えられるたびに自動的にテストを実行します。
ソフトウェアビルド**：コードのコンパイルとデプロイの準備。
デプロイメント***：アプリケーションの最新バージョンを本番環境に移行します。
ビルド、テスト、デプロイのステータスを追跡し、フィードバックを提供する。
オーケストレータは、特定のタスクや目的を実行するために必要な一連のステップであるワークフローを通じてアプリケーションを管理します。ワークフロー内の各ステップは、オーケストレータが各タスクの実行順序を処理する間に、個別に実行、テスト、検証することができます。ワークフローの例としては、LLMのトレーニングや微調整、アプリケーションの環境へのデプロイ、運用中のアプリケーションへの新機能の統合などがあります。
ワークフローは、いくつかの方法でLLMアプリケーションの開発と保守を合理化する。第一に、ワークフローは再現可能であるため、既存のワークフローを異なるパイプライン間でコピーでき、時間と労力を大幅に節約できる。同様に、ワークフローはバージョン管理できるので、パイプラインをある時点の状態に戻すことができます。
現実的には、MLOpsオーケストレータは、複数の人やチームによって開発されるエンタープライズレベルのLLMアプリケーションに最適であり、小規模なアプリケーションにはオーバーキルである可能性が高い。オーケストレーターの代わりに、モデルをプロダクションに出荷し、その使用を監視し、得られた洞察に従ってアプリケーションを手動で更新することが、より現実的なアプローチです。
まとめ
さて、Sage ElliotのLLMOpsに関する話をまとめると、次のようになる：
LLMOpsとは、LLMアプリケーションの効率的な開発、デプロイメント、メンテナンス、改良を促進する哲学とテクノロジーの集まりを指す。
LLMOpsは「Building AI Together（一緒にAIを構築する）」とも定義され、（LLMOpsの由来である）DevOpsのように、組織内のさまざまなチームが、対照的な目標を掲げてサイロで活動するのではなく、協力してLLMアプリケーションを構築することを意味する。
一見圧倒的に見えるが、LLMOpsは3つのステップで始めることができる：
出荷**：モデルを本番環境に早急に導入し、実際のユーザーからのフィードバックを得る。
モニター**：メトリクスを使用してパフォーマンスを評価する。
Improve: アプリケーションを改善するためにモニタリングからの洞察を使用します。
HuggingFaceは、プロトタイプをプロダクションに素早くデプロイするための優れたリソースです。Transformerライブラリはモデルを簡単にダウンロードして微調整することを可能にし、Datasetsライブラリはそれを微調整するためのデータを提供し、Spacesは本番環境に素早くデプロイするためのホスティングプラットフォームを提供します。
Flyteは、LLMアプリケーションの管理を簡素化するMLOpsオーケストレーターの一例です。
その他のリソース
LLMOpsの理解を深め、AIアプリケーションの開発プロセスに適用する方法を学ぶために、以下のリソースを参照することをお勧めします。
セージ・エリオットのYouTubeプレゼンテーション](https://youtu.be/fRsqAILVhPo?t=1498)
HuggingFace Spaces](https://huggingface.co)
フライテ](https://flyte.org/)
ベクターデータベースとは](https://zilliz.com/learn/what-is-vector-database#:~:text=A%20vector%20database%20is%20a,vector%20embeddings%20from%20ML%20models.)
検索拡張世代(RAG)](https://zilliz.com/learn/Retrieval-Augmented-Generation)
RAGアプリケーションの評価方法](https://zilliz.com/learn/How-To-Evaluate-RAG-Applications)
Software2.0、MLOps、MilvusでAIを大規模に運用する](https://zilliz.com/blog/Operationalize-AI-at-Scale-with-Software-MLOps-and-Milvus)
ベクトルデータベース、大規模言語モデル(LLM)、その他のAIおよび機械学習の主要概念についてさらに学ぶには、Zilliz Learn ナレッジベースをご覧ください。
読み続けて
Empowering Innovation: Highlights from the Women in AI RAG Hackathon
Over the course of the day, teams built working RAG-powered applications using the Milvus vector database—many of them solving real-world problems in healthcare, legal access, sustainability, and more—all within just a few hours.
Advancing LLMs: Exploring Native, Advanced, and Modular RAG Approaches
This post explores the key components of RAG, its evolution, technical implementation, evaluation methods, and potential for real-world applications.
Stop Waiting, Start Building: Voice Assistant With Milvus and Llama 3.2
We'll learn to build a Voice Assistant, a specialized Agentic RAG system designed for voice interactions, with Milvus, Llama 3.2, and other GenAI tools.