Azure Databricks での LLMOps ワークフロー

この記事では、LLMOps ワークフローに固有の情報を追加することで、Databricks の MLOps ワークフローを補完します。 詳細については、「MLOps のビッグ ブック」を参照してください。

LLM では MLOps ワークフローはどのように変わりますか?

LLM は、自然言語処理 (NLP) モデルの 1 つのクラスであり、オープンエンドの質問の回答、要約、命令の実行など、さまざまなタスクにわたって、サイズとパフォーマンスの点で以前のものを大幅に上回っています。

LLM の開発と評価は、従来の ML モデルとはいくつかの重要な点で異なります。 このセクションでは、いくつかの LLM の主なプロパティと MLOps への影響について簡単に説明します。

MLOps と LLMOps の共通点

MLOps プロセスの多くの側面は、LLM でも変わりません。 たとえば、次のガイドラインは LLM にも適用されます。

• 開発、ステージング、運用には個別の環境を使用します。
• バージョン コントロールに Git を使用する。
• MLflow でモデル開発を管理し、Unity Catalog のモデルを使用してモデルのライフサイクルを管理します。
• Delta テーブルを使用してレイクハウスのアーキテクチャにデータを格納します。
• 既存の CI/CD インフラストラクチャでは、変更は必要ありません。
• MLOps のモジュール構造は変わらず、特徴付け、モデル トレーニング、モデル推論などのパイプラインが存在します。

Reference architecture diagrams (参照アーキテクチャ図)

このセクションでは、2 つの LLM ベースのアプリケーションを使用して、従来の MLOps の参照アーキテクチャの調整の一部について説明します。 図は、1) サードパーティ API を使用した取得拡張生成 (RAG) アプリケーションと、2) セルフホステッド微調整モデルを使用した RAG アプリケーションの運用アーキテクチャを示しています。 どちらの図もオプションのベクトル データベースを示しています。この項目は、モデル サービス エンドポイントを介して LLM に直接クエリを実行することで置き換えることができます。

サードパーティ LLM API を使用した RAG

この図は、Databricks 外部モデルを使用してサードパーティ LLM API に接続する RAG アプリケーションの運用アーキテクチャを示しています。

微調整されたオープン ソース モデルを使用した RAG

この図は、オープン ソース モデルを微調整する RAG アプリケーションの運用アーキテクチャを示しています。

MLOps 運用アーキテクチャに対する LLMOps の変更

このセクションでは、LLMOps アプリケーションの MLOps 参照アーキテクチャに対する主な変更を重点的に取り上げます。

モデル ハブ

LLM アプリケーションでは、多くの場合、内部または外部のモデル ハブから選択された既存の事前トレーニング済みモデルが使用されます。 モデルは、そのまま使用することも、微調整することもできます。

Databricks では、Unity Catalog と Databricks Marketplace に高品質で事前トレーニング済みの基盤モデルが含まれています。 これらの事前トレーニング済みモデルを使用して最先端の AI 機能にアクセスできるため、独自のカスタム モデルを構築する時間とコストを節約できます。 詳しくは、「Unity Catalog と Marketplace での事前トレーニング済みモデル」を参照してください。

ベクトル データベース

一部の LLM アプリケーションでは、たとえば、LLM クエリでコンテキストやドメインの知識を提供するために高速な類似性検索にベクトル データベースが使用されます。 Databricks には、ベクトル データベースとして Unity Catalog の Delta テーブルを使用できる統合ベクトル検索機能が用意されています。 ベクトル検索インデックスは Delta テーブルと自動的に同期されます。 詳しくは、ベクトル検索に関するページを参照してください。

ベクトル データベースから情報を取得するロジックをカプセル化し、返されたデータをコンテキストとして LLM に提供するモデル成果物を作成できます。 その後、MLflow LangChain または PyFunc モデル フレーバーを使用してモデルをログに記録できます。

LLM を微調整する

LLM モデルはコストが高く、ゼロから作成するのに時間がかかるため、LLM アプリケーションでは、多くの場合、既存のモデルを微調整して、特定のシナリオでのパフォーマンスを向上させます。 参照アーキテクチャでは、微調整とモデルのデプロイは、個別の Databricks ジョブとして表されます。 デプロイ前に微調整されたモデルを検証することは、多くの場合、手動のプロセスです。

Databricks には、独自のデータを使用して既存の LLM をカスタマイズし、特定のアプリケーションのパフォーマンスを最適化できる Mosaic AI モデル トレーニングが用意されています。 詳細については、Mosaic AI モデル トレーニングに関するページを参照してください。

モデルの提供

サードパーティの API シナリオを使用する RAG では、重要なアーキテクチャの変更は、LLM パイプラインでモデル サービス エンドポイントから内部またはサードパーティの LLM API に外部 API 呼び出しが行われるということです。 これにより、複雑さ、潜在的な待機時間、さらに資格情報管理が追加されます。

Databricks には、AI モデルのデプロイ、管理、クエリを行う統合インターフェイスを提供する Mosaic AI Model Serving が用意されています。 詳細については、Mosaic AI Model Serving に関するページを参照してください。

監視と評価に関する人間のフィードバック

ほとんどの LLM アプリケーションでは、人間のフィードバック ループが不可欠です。 人間のフィードバックは他のデータと同様に管理する必要があります。理想的には、ほぼリアルタイムのストリーミングに基づいて監視に組み込む必要があります。

Mosaic AI Agent Framework レビュー アプリは、人間のレビュー担当者からのフィードバックを収集するのに役立ちます。 詳細については、「エージェント アプリケーションの品質に関するフィードバックを得る」を参照してください。