LLMOpsを推進！Azure Log Analyticsを活用したLLMの継続的な監視と改善

こんにちは！AIソリューショングループの太田です。

このコラムでは、Azure Log Analyticsを使ったLLMOpsの実現方法について紹介します。

昨年から大規模言語モデル（LLM）を製品やサービスに組み込む企業が増えています。しかし、LLMサービスの品質を維持するには、その運用にも注意を払う必要があります。

具体的には、LLMの出力の品質管理や、ユーザーからのフィードバックを元にしたプロンプトの最適化など、継続的な監視と改善が求められています。これらの運用上の活動にAzure Log Analyticsが役立ちます。

LLMOps（LLM（Large Language Model）+ Ops（Operations））とは

LLMOpsは製品に組み込まれたLLMの運用に必要なベストプラクティスの概念を指します。例えば、LLMの運用ではLLMの出力の監視と評価とプロンプト管理をおこないます。

昨年からMLOpsに続いて、LLMOpsに関係する様々なツールやサービスが提供されています。またIT大手各社はLLMOpsの取り組みや考え方を宣言しています。

サービス・会社名	URL
AWS	FMOps/LLMOps：生成系 AI の運用と MLOps との違い \| Amazon Web Services ブログ
Microsoft	An Introduction to LLMOps: Operationalizing and Managing Large Language Models using Azure ML
DeepLearning.ai（GCP）	LLMOps - DeepLearning.AI
IBM	What Are Large Language Model Operations (LLMOps)? \| IBM
DataBricks	LLMOps とは\| Databricks
snowflake	LLMOps: a Structured Approach for Operationalizing Large Language Models \| Snowflake
weight&biases	Understanding LLMOps: Large Language Model Operations - Weights & Biases
NVIDIA	LLM テクニックの習得: LLMOps - NVIDIA 技術ブログ
fiddler	Large Language Model Operations (LLMOps) \| Fiddler AI
langsmith	LangSmith \| 🦜️🛠️ LangSmith

こちらに挙げた企業以外にも、様々なLLMOpsに関係するツールが提供されています。

RagOps Defined – RAGOps

Building LLM applications for production

Awesome-LLMOpsリポジトリ

このコラムでは、LLMの出力の監視からプロンプト改善について焦点を当てて、LLMOpsの実施方法を解説したいと思います。

LLMOpsが必要になる問題設定の具体例

最初にLLMOpsが必要になる問題設定を説明します。

今回は、質問と同時にChatGPTに業務ドキュメントを参照させて回答を得ることができるチャットボットを作ることを前提にします。

そこで、RAG（Retrieval-Augmented Generation）アルゴリズムを使用した対話アプリをチャットボットとしてデプロイします。

RAGに関しては、以下の記事をご参照ください。

aitc.dentsusoken.com

具体的な対話的RAGアルゴリズムを以下のフロー図で実現するとします。

このフローでは最初に、質問に対して新たな情報を検索するのか、前回の検索で得た情報を再利用して回答するかを判断するステップを入れました。

検索の必要性を判断する際のプロンプトでは、前回の検索結果と対話履歴をもとに、追加で情報の検索を実施するのかの判断結果をLLMに出力させるように設定します。プロンプトを作ったら、データセットを用意して数十件程度のサンプルで正しく挙動するのかテストします。

この際、プロンプトでは以下の項目を問題なく対応できることを評価しました。

１ターン目に検索が不要な質問であれば、検索しないフラグを生成すること
２ターン目以降に１ターン目の内容と関係ない質問をした場合、検索するフラグを生成すること
２ターン目以降に１ターン目の内容と関係ある質問をした場合、検索しないフラグを生成すること
明示的に検索することを要望する記述があった場合、検索するフラグを生成すること

しかしこの検証だけでは運用時に、実際にされた質問に対して意図通りの回答ができるのか、プロンプトの書き方に改善すべき点があるのかわかりません。そこで、運用時にはプロンプトの生成結果を監視する仕組みも導入する必要があります。

プロンプトの生成結果を監視する必要性

ここで、もう少し監視が必要な理由を掘り下げて説明します。運用時には当たり前ですが評価データのときと違う質問がされる可能性があり、その質問に対してLLMが意図しない回答を生成することがあります。例えば、追加検索するかのフラグを生成する際に以下のような意図しない挙動が起きる懸念があります。

１ターン目から検索しないが選ばれること
必要なタイミングで検索するフラグが生成されないこと
毎ターン検索されること
フラグの形式で生成できないこと

例えば、毎ターン検索されると、対話の中で前回の回答内容を掘り下げたいのに、新たな検索で前回の回答に使った参考文章を再現できないことがあります。

このような問題が起こりうると考えたとき、開発者として問題を定量的に評価し、ある閾値を超えた際に自動的にアラートをあげる仕組みを検討します。もし、深刻なアラートが上がった場合はプロンプトを改善することになりますが、改善策を洗い出すために、どういった問題が起きているか把握する必要もあります。

また、改善後にはプロンプト変更後に精度が改善されたのか評価する必要があります。

つまり、開発者はLLMの出力監視から状況の把握、改善施策の立案、施策後の効果分析を行えるようにする必要があると言えます。

Azure Log Analyticsによる出力の監視

今回はAzure Log Analyticsの使用を前提にどのようにLLMの挙動を監視、分析、改善するのか説明していきます。もちろん、他のLLMOpsツールを使用して同様の仕組みを構築することも可能です。

Azure Log Analyticsを使用することで、これらの運用タスクを効果的にサポートできます。具体的には、リアルタイムでの出力監視により、モデルのパフォーマンスが期待値から逸脱した場合に即座に警告を受け取ることができます。さらに、長期的なデータ分析を通じて、LLMの応答品質に影響を与える要因を特定し、その知見をもとにプロンプトの改善やモデルのチューニングを行うことが可能になります。

Azure Log Analytics ログの記録設定

Azure Log Analyticsでは、監視データの収集と分析をAzure Portal上からログデータに対するクエリ実行することで実現できます。

今回は、Azure FunctionsにデプロイしたアプリのAPI の実行時に流れたコンソールログをAzure Log Analyticsワークスペースに流し、そのログデータをLog Analyticsで分析します。

Azure Portal上からAzure Functionsのリソースを選び、サイドバーの【診断設定】からログを記録する設定ができます。保存先はAzure Log Analyticsワークスペースで大丈夫です。

Azure Portal上のAzure Functionsリソースの診断設定からログの記録方法

設定後にAzure Functions上からデプロイしたアプリのAPIを叩き、利用ログを貯めます。

コンソールログに流す情報

コンソールログでは、LLMの生成後に分析用の情報を出力しておきます。今回、ログには以下のクラスの内容をjson形式で出力します。

from typing import Literal
from pydantic import BaseModel, Field

class GptLogResponse(BaseModel):
    prompt_type: str = Field(title="promptの種類")
    prompt_version: int = Field(title="promptのバージョン")
    deployment_name: str = Field(title="デプロイモデル名")
    response_time: float = Field(title="レスポンス時間")
    prompt_tokens: int = Field(title="promptのトークン数")
    completion_tokens: int = Field(title="completionのトークン数")
    datetime: str = Field(title="日付")
    request: str = Field(title="リクエスト")
    response: str = Field(title="レスポンス")
    status: Literal["Success", "Failed"] = Field(title="生成ステータス")
    metadata: dict = Field(title="メタデータ")

Azure Log Analytics ログ分析

ある程度、ログが貯まった後の分析方法について紹介します。 Azure Log AnalyticsではKQL（Kusto Query Language）を使ってログ集計と可視化から分析します。ここでは各ターンの検索するかLLMが判定したフラグの生成数を分析します。ターン数は、ログのメタフィールドに格納してあります。

実行したKQLを説明すると、json形式でコンソールログに出力した情報をもとに集計ロジックを記述しています。会話のターンごとに検索するかどう判定したのかを集約し、その生成内容の内訳を集計しています。期待する結果ではターン数が1のときは検索するためYes（検索を実施する）が多く、2ターン目以降はNo（検索を実施しない）が多くなることです。またYes/Noでもない生成結果は0が望ましいです。

図の集計結果を見るとどのターンもYesの方に偏りが多いように感じますが、Yes/No以外のものを生成することはなさそうです。集計クエリは保存することができるので、これで定期的に状況を確認できます。

クエリの実行方法などは以下を確認してください。

Log Analytics tutorial - Azure Monitor | Microsoft Learn

Azure Log Analytics アラートルール

定期的に確認するのも大事ですが、アラートルールを作っておくと事前に閾値を超えたタイミングで通知が来るようにできます。 Azure Log Analyticsではアラートルールを設定できます。さきほどのKQL実行画面から【新しいアラートルール】を押して設定できます。

この設定では、1日おきに先ほどのログ集計クエリを実行し、Yes/No以外のフラグが生成された件数が10件以上あった場合、"警告"のアラートになる設定です。

アラートの設定方法は以下で確認ください。

Overview of Azure Monitor alerts - Azure Monitor | Microsoft Learn

プロンプトの改善方法

最後にプロンプトの改善方法を紹介します。ログの集計結果から3ターン目でも検索しにいくことが多いようです。 KQLで以下を実行して、該当ログだけ絞り込みます。

そのあとは、ログに流してあるプロンプトを確認し、原因分析します。以上で、ログの監視方法から具体的な分析方法までの紹介です。

監視ツールの選定基準

最後に監視ツールの選定理由を説明します。このコラムでは、Log Analytics を使った監視方法を紹介しましたが、他にもLLMOpsの監視ツールはあります。例えば、PromptFlowやLangSmithはコードの追加しなくても簡単に始められるので今後LLMOpsのツールとして利用されることが増えると思われます。

・生成 AI アプリケーションのモデルの監視 (プレビュー) - Azure Machine Learning | Microsoft Learn

・LangChain Expands Collaboration with Microsoft

ただ、これらのツールには制限があります。 PromptFlowで監視する場合、PromptFlow上でアルゴリズムを開発し、プロンプトごとに専用のエンドポイントを作成する必要があります。そのエンドポイントをアプリ上で利用するとログが取られる仕組みです。取りたいログがカスタマイズできない点とエンドポイントのVM運用料金がもったいないので使わない方針になりました。ただPromptFlow自体は製品開発前の事前検証の実験管理には優れていると思います。

LangSmithの場合、優れたインターフェースを持っており、利用したかったのですがブログを書いていた当初は事前申請が必要だったため断念しました。というのも、今後のことを考えると顧客ごとにPaaSサービスでソリューションを提供する場合、どの顧客も利用申請する必要があり手間になるからです。