本日、こちらのイベントに登壇させていただきました。
スライドはこちらです。
- MLOpsとは？
- LLMOpsとは？
- LLMOpsのベストプラクティス
- DatabricksのMosaic AI
- (時間があれば)デモ
MLOpsとは？
MLOpsとは機械学習モデルライフサイクル全般を円滑にするために必要な体制・基盤・手法全般を意味します。
MLOps(Machine Learning Operations)とは、データサイエンスチーム、運用チームなど、機械学習モデルの構築・運用に関わるチームが協調し、円滑に機械学習モデルを運用していくための体制・基盤を構築すること、その概念全般を意味します。
MLOps = DataOps + DevOps + ModelOpsです。
LLMOpsとは？
LLMOpsとはLLMライフサイクル全般を円滑にするために必要な体制・基盤・手法全般を意味します。
LLMOps(Large Language Model Operations)とは、データサイエンスチーム、運用チームなど、LLMの構築・運用に関わるチームが協調し、円滑にLLMを運用していくための体制・基盤を構築すること、その概念全般を意味します。
従来のMLモデルがLLMに置き換わったようにも見えますが、実際にはプロンプトやチェーン、フロントエンドなどもまとめてオペレーションする必要があるので、さらに広い範囲をケアしなければいけません。
MLOps - LLMで何が変わる？
| LLMの特性 | MLOpsの示唆 |
|---|---|
| 様々な形態でLLMを利用可能 | インクリメンタルな開発プロセス、APIからスモールスタートして、精度を求める過程でファインチューニングしたカスタムモデルへ |
| LLMは入力として自然言語のプロンプトを受け入れる | LLMに問い合わせを行うテストテンプレートの設計が開発プロセスの重要な一部に、パッケージングされるアーティファクトとプロダクションにおけるプロンプトは、モデルというよりパイプラインに |
| LLMにはサンプルやコンテキストを伴うプロンプトを指定可能 | 適切なコンテキストの検索に使用されるベクトルデータベースのような外部ツールをサービングするインフラストラクチャは必要に |
| サードパーティのAPIプロバイダー経由でプロプライエタリモデルやOSSモデルを利用可能 | APIプロバイダーをスイッチできる選択可能性や柔軟性を持つために、APIガバナンスのための集中管理されたシステムを持つことが重要に |
| LLMは非常に大きなディープラーニングモデルであり、多くの場合、数Gバイトから数百Gバイトに | サービングのインフラストラクチャ: LLMのサービングにはGPUが必要。モデルを動的にロードする必要がある場合には、高速なストレージが重要 |
| LLMにおいては、多くの場合、単一の「適切な」回答が存在しないため、従来のMLメトリクスを通じた評価が困難 | 人間のフィードバック: LLMの評価、テストで必要になることが多い。将来的なファインチューニングのためには、テスト、モニタリングを含むMLOpsに直接組み込むことが重要に |
これらの新たな要件に適合するために、多くの既存ツール、既存プロセスの修正は軽微です
- 開発、ステージング、プロダクションの分離は変わりません
- パイプラインやモデルをプロダクションに移行する際に、Gitのバージョン管理とUnity CatalogにおけるMLflowモデルレジストリは依然として主要なパイプラインとなります。
- データ管理に対するレイクハウスアーキテクチャは、効率性のために依然として適切で重要です。
- 既存のCI/CDインフラストラクチャには変更はありません。
- モデルトレーニングのためのパイプライン、モデル推論のためのパイプラインなどを用いた、モジュール化されたMLOpsの構造は同じです。
LLMOpsのベストプラクティス
機械学習にデータ中心アプローチを採用
- いかなるMLプロジェクトにおいても、コアとなる構成要素はシンプルにデータパイプラインと見なすことができます: 特徴量エンジニアリング、トレーニング、モデルのデプロイメント、推論、パイプラインのモニタリングのすべてはデータパイプラインです。
- そのようなMLソリューションの本格運用には、予測結果、モニタリングからのデータ、特徴量テーブルやその他の適切なデータとの結合が必要となります。
- 基本的に、これを達成する最もシンプルな方法はプロダクションデータの管理に用いられているのと同じプラットフォームでAIを活用したソリューションを開発することです。
DatabricksのUnity Catalogでは、データやモデルは同じ場所で管理されます。
そして、ペルソナやスキルレベル、シナリオに合わせたAIモデルの構築が可能です。
常にビジネスゴールを念頭に置く
- LLMOpsにおける技術的な取り組みの優先度付けを行う際、ビジネスインパクトを考慮しましょう: これは新たなビジネスユースケースを実現するのか？データチームの生産性を改善するのか？オペレーションコストやリスクを削減するのか？
- 最新、あるいは最も複雑なモデルによって気が逸らされる誘惑に抗いましょう。はじめに、シンプルな経験則を用いてあなたのKPIやベースラインの成功を定義しましょう。
モジュール化された方法でLLMOpsを実装する
- すべてのソフトウェアアプリケーションと同じように、LLMアプリケーションにおいてコードの品質は最重要事項です。
- モジュール化されたコードによって、個々のコンポーネントのテストを可能にし、将来的なコードのリファクタリングの難易度を軽減します。
プロセスは自動化をガイドすべきである
- 開発プロセスは最も重要なものであり、このプロセスにおけるそれぞれのモジュールは必要に応じて自動化されるべきです。
- 依然として、人間がビジネス上の質問を定義し、いくつかのモジュールは常にデプロイメントの前に人間による確認を必要とします。
- 特定の自動化ツールを検討する際、あなたの人材やプロセスに調和するものを選択しましょう。
- 例えば、エージェントシステムを構築する場合、エージェントの開発から管理、監視までもカバーするMosaic AI Agent Framework & Agent Evaluationを活用することができます。
Databricksでは、開発当初から評価の仕組みを組み込む評価ドリブン開発ワークフローを提唱しています。これを実現するのが、Agent FrameworkやAgent Evaluationです。
DatabricksのMosaic AI
Mosaic AIは、Databricksにおいて生成AIに関わるすべてのことをサポートするツールスイートです。モデルの事前学習やファインチューニング、RAGを含むエージェントシステムの開発、運用を強力にサポートします。
Databricksのレイクハウスアーキテクチャに完全にインテグレーションされています。
データの準備から開発、評価、本番環境へのデプロイと監視まで、生成AIアプリのライフサイクルをサポートします。
デモ
クッキーの販売データを取り扱うチャットbotの開発を想定しています。
最初にデータベースに格納されている売り上げデータや店舗データにアクセスするツールをSQLで開発します。
次に、上記のツールを用いてプロトタイピングを行います。AI Playgroundを用いることで、言語モデルとツールを選択するだけでチャットbotの挙動を確認することができます。
ここから、チェーンを含むPython実装のノートブックをエクスポートすることができ、そのままサービングエンドポイントにレビュー用アプリと一緒にデプロイすることができます。
専門家にレビューアプリを用いて評価してもらい、フィードバックを収集することもできます。
フィードバックを監視するダッシュボードを構築することができるので、必要に応じてモデルや仕組みの見直しが可能です。
