LLMのライフサイクル（運用フェーズ）

# はじめに
LLMのライフサイクルについてフェーズごとに投稿しており、今回は第三弾になります。

| No | フェーズ | 投稿予定日 |
|:-:|:-:|:-:|
| 1 | アイデア化・探索フェーズ | [投稿済み](https://qiita.com/k-kimino/items/9adb291765098f120140) |
| 2 | 構築・拡張フェーズ | [投稿済み](https://qiita.com/k-kimino/items/1994051866929fa490e5) |
| 3 | 運用フェーズ | 今回の記事 |

前回、前々回の記事でLLMのライフサイクルにおけるアイデア化・探索フェーズ・構築。拡張フェーズにおいて活用できるAzureのソリューションを紹介しています。まだチェックされていない方は以下も合わせてチェックしてみてください。

# LLMのライフサイクル（再掲）

前回の記事を読んだ方は同じ内容になっているため[3. 運用フェーズ](#3-運用)まで読み飛ばしてください。
[Microsoft Ignite](https://ignite.microsoft.com/en-US/sessions/16ee2bd5-7cb8-4419-95f6-3cab36dfac93?source=sessions)ではLLMのライフサイクルを以下の3つのステージに分類して紹介しています。各ステージで得られたフィードバックは前のフェーズに提供され今後のプロジェクトで改善に利用することができます。本記事ではMicrosoftがフレームワークとして整理した内容に沿って検証した結果を共有します。

- アイデア化・探索（Identing/exploring）
    - 1.1 データソースの接続
    - 1.2 AIチャットボットのテスト
    - 1.3 LLMモデルの選択
- 構築・拡張（Building/augmenting）
    - 2.1 プロンプトフローの構築
    - 2.2 プロンプトフローの評価
    - 2.3 プロンプトフローの修正
- 運用（Operationalizing）
    - 3.1 プロンプトフローのデプロイ
    - 3.2 監視

![Overview2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/8df77a7b-aa31-ed08-6617-91cf2c6e566b.png)

# 3. 運用
本フェーズでは[3.1 プロンプトフローのデプロイ](#31-プロンプトフローのデプロイ)、[3.2 監視](#32-監視)を行います。Azure Machine LearningおよびAzure Monitorで提供されている監視サービスを活用し、運用中のシステムのメトリクス（ユーザー利用数や待ち時間など）とユーザーからのクエリと生成AIの回答の品質をチェックし問題点を洗い出し、改善に役立てます。

## 3.1 プロンプトフローのデプロイ
プロンプトフローの画面からDeployボタンを押下、以下のような設定を行いデプロイを開始します。

- Virtual machine：プロンプトフローをホストする仮想マシンの性能を選択します
- Instance count：デプロイする仮想マシンの数です。高可用性のためには3以上が推奨されています
- Inferencing data collection(preview)：フローの入力と出力が保存され、[モデルの監視](#1モデルの評価メトリクスの監視)に利用できます
- Application Insights diagnostics ：[システムメトリクス](#2システムメトリクスの監視)(トークン数、フロー待機時間、フロー要求など) が収集され、監視に利用できます

![DeployPromptflow.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/4a02186d-3a8b-957b-6ce5-df6f1564452e.png)

エンドポイントのデプロイが完了したら、モニタリングタブから監視を有効化します。以下の画面の通り、Fuency, Cohurence, Groundedness, Relevanceを監視のメトリックとして選択できます。また、プロンプトフローのインプット・アウトプットから以下のように値の紐づけを行います。

- Prompt： query(ユーザーからの質問)
- Completion：reply(生成AIの回答)
- Context：fetched_docs(生成AIに元のプロンプトと共にインプットとして与える情報)

![EnableMonitoring-Selectmetrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/972ef846-7361-71bc-74b0-b71c833ae65f.png)

## 3.2 監視
監視は、Azure Machine Learningによって提供される[(1)モデルの評価メトリクスの監視](#1モデルの評価メトリクスの監視)、Azure Monitorによって提供される[(2)システムメトリクス（トークン数、フロー待機時間、フロー要求など ）の監視](#2システムメトリクスの監視)との2種類に大別されます。これらを活用するメリットとして開発したプラットフォームで基本的な要素を監視することができます。

### (1)モデルの評価メトリクスの監視
デフォルトでは週に1度、以下の事前に設定した指標に対してユーザーのリクエストを評価しモデルのパフォーマンスを監視します。今回はテストのためデプロイ後すぐに手動で監視ジョブを実行しており、さらに利用者が筆者のみのため十分なサンプルではないですが、”Relevance”、”Fluency”、”Coherence”で50％の評価結果になりました。デフォルトでは評価値が70%を下回るとアラートが上がるため1つの目安になりそうです。

悪い評価の原因ですが、すべて同じクエリに対する以下の回答でした。特に間違えた回答をしているわけでもなく自然な回答が生成できているように感じるため、評価が失敗しているように見えます。この原因はもう少し調査してみる必要がありますが、まだ筆者はわかっていません。こういった問題を減らすため可能性として監視ジョブに対してもGPT-4など性能のよいモデルを使用した方が効率がよいと改めて実感しました。

- ユーザーからの質問：Daniel WilsonがBaseCamp Folding Tableを注文したのはいつですか？
    - 生成AIの回答：Daniel WilsonはBaseCamp Folding TableをMay 7th, 2023に注文しました [doc3]。

![MonitorModels.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/34f217ed-5a1d-c8d4-d664-592d6154c96d.png)

### (2)システムメトリクスの監視
アクセス数のみはAzure AI Studioからも確認できますが、詳細はAzure Monitorを使用して確認することになります。以下はリクエスト待ち時間を表示しており、平均1.89秒になっていることがわかります。他にも1分当たりのリクエスト数など性能監視に活用できます。

![MonitorMetrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/0f23b85a-bccf-f75c-0350-c5eaee277fd1.png)

# まとめ
本記事ではLLMのライフサイクルにおける運用フェーズについて活用できるAzureのソリューションを紹介しました。本フェーズで私の感じたポイントは以下です。

- モデルの評価結果の理由がブラックボックス
    - なぜこのような結果になったのかの説明がないために、改善が難しいケースが出てくるかもしれません。運用者にノウハウが求められそうです。筆者が試した例でも原因究明できていないので、もう少し調査してみたいです。
- 導入の容易さ
    - Azureを監視に活用した場合の一番のメリットは導入（設定）の容易さだと感じました。他社のソリューションをまだ比較できていないのですが、他にどういった手法が検討できるか調査する必要がありそうです。