「LLMモニタリングと観測性 – 責任あるAIのための手法とアプローチの概要」

Overview of LLM Monitoring and Observability - Methods and Approaches for Responsible AI

対象読者: 実践者たち、彼らが利用可能なアプローチを学び、それを実装する方法を知りたい人々、そしてガバナンスフレームワークや技術的なロードマップを構築する際に可能性を理解したいリーダーたち。

まるで一夜のうちに、全てのCEOのやるべきリスト、求人広告、履歴書には生成型AI（genAI）が含まれるようになりました。そして当然のことです。基礎モデルに基づくアプリケーションは既に何百万人もの働き方、学び方、書き方、デザイン、コード、旅行、ショッピングの方法を変えました。多くの人々、私も含めて、これはただ氷山の一角に過ぎないと感じています。

この記事では、大規模言語モデル（LLM）のモニタリングに関する既存の手法についての研究をまとめています。私は多くの時間を費やして、LLMのモニタリングと観測に特化したソフトウェアベンダーやオープンソースライブラリのドキュメントを読み、ビデオを見たり、ブログを読んだりしました。その結果、LLMのモニタリングと観測のための実用的な分類法ができました。役立つ情報となれば幸いです。近い将来、学術論文の文献検索を行い、将来を見据えた視点を加える予定です。

調査対象のソフトウェア*: Aporia, Arize, Arthur, Censius, Databricks/MLFlow, Datadog, DeepChecks, Evidently, Fiddler, Galileo, Giskard, Honeycomb, Hugging Face, LangSmith, New Relic, OpenAI, Parea, Trubrics, Truera, Weights & Biases, Why Labs

• 「スノーフレーク vs データブリックス：最高のクラウドデータプラットフォームを作るために競争する」
• PyCharm vs. Spyder 正しいPython IDEの選択
• マシンラーニングに取り組むため、プライベートエクイティはデータサイエンスの才能を採用しています

• *この記事は、ソフトウェアオプションを評価したり比較したりすることなく、累積的な分類法を提示しています。私の研究でカバーした特定のソフトウェアについて議論したい場合は、お気軽にご連絡ください。

記事の概要

• LLMの評価 — LLMはどのように評価され、本番環境に適したものとされるのか？
• LLMのトラッキング — LLMをトラッキングするとは何を意味し、どのようなコンポーネントが含まれる必要があるのか？
• LLMのモニタリング — LLMが本番環境に配置された後、どのようにモニタリングされるのか？

LLMのライフサイクル

LLMを製品ワークフローに組み込む競争が進行中ですが、技術コミュニティはこれらの強力なモデルが長期間にわたって期待どおりに機能するようにするためのベストプラクティスを開発するために奮闘しています。

LLMの評価

従来の機械学習（ML）モデルの評価は、その出力や予測の正確性を確認することから始まります。これは通常、Accuracy、RMSE、AUC、Precision、Recallなどのよく知られた指標で測定されます。LLMの評価ははるかに複雑です。データサイエンティストたちが現在使用しているいくつかの方法があります。

(1) 分類および回帰指標

LLMは数値予測または分類ラベルを生成することがあります。その場合、評価は簡単です。従来のMLモデルと同じです。これはいくつかのケースで役立ちますが、通常はテキストを出力するLLMの評価に関心があります。

(2) 単独のテキストベースの指標

これらの指標は、グラウンドトゥルースのソースがない場合にLLMからのテキスト出力を評価するのに役立ちます。過去の経験、学術的な提案、他のモデルのスコアとの比較に基づいて、受け入れ可能なものを判断する必要があります。

Perplexityはその一例です。この指標は、モデルが入力テキストシーケンスを生成する可能性を測定し、モデルが学習したテキストの質を評価するものと考えることができます。他の例には、読解レベルや非文字文字があります。

より洗練された単独アプローチでは、モデルの出力から埋め込みを抽出し、それらの埋め込みを異常なパターンで分析します。これは、埋め込みのグラフを3Dプロットで手動で調査することによって行うことができます。ジェンダーや予測クラス、Perplexityスコアなどのキーフィールドで色分けや比較を行うことで、LLMアプリケーションの潜在的な問題やバイアスの程度、説明可能性の尺度を示すことができます。このような埋め込みを視覚化するために使用するソフトウェアツールがいくつか存在します。これらのツールは埋め込みをクラスタリングし、3次元にマッピングします。通常、HDBSCANとUMAPを使用しますが、いくつかのツールではK-meansベースのアプローチを活用しています。

視覚的な評価に加えて、埋め込みに対して異常検出アルゴリズムを実行することで、外れ値を探すことができます。

(3) 評価データセット

グラウンドトゥルースのラベルを持つデータセットを使用することで、テキスト出力を承認済みの応答の基準と比較することができます。

よく知られた例として、ROUGEメトリックがあります。言語翻訳タスクの場合、ROUGEは評価されるLLMと比較して、参照データセットに基づいて回答を評価します。関連性、正確性、およびその他の多くのメトリックを参照データセットに対して計算することができます。埋め込みは重要な役割を果たします。J-S距離、Hellinger距離、KS距離、およびPSIなどの標準的な距離メトリックは、LLMの出力埋め込みとグラウンドトゥルースの埋め込みを比較します。

最後に、LLMのための広く受け入れられたベンチマークテストがいくつかあります。StanfordのHELMページはそれについて学ぶのに最適な場所です。

(4) 評価LLM

一見すると、LLMを評価するためにLLMを使用するのはシステムを騙すように思えるかもしれませんが、多くの人々はこれが最良の方法だと考えており、研究にも約束が示されています。近い将来、評価LLMの使用が主流のLLM評価方法となる可能性が非常に高いです。

広く受け入れられている例として、Toxicityメトリックがあります。これはEvaluator LLM（Hugging Faceはroberta-hate-speech-dynabench-r4を推奨しています）を使用して、モデルの出力が有害かどうかを判断します。評価データセットに対しては、Evaluation Datasetsの上記のすべてのメトリックが適用されます。Evaluator LLMの出力を参照として扱います。

Arizeの研究者によると、Evaluator LLMはテストするメトリックに対してバイナリ分類ラベルを提供するように設定する必要があります。数値スコアやランキングは改善が必要であり、バイナリラベリングほどパフォーマンスが高くありません。

(5) 人間のフィードバック

この記事、ソフトウェアのドキュメント、マーケティング資料では測定可能なメトリックに重点が置かれていますが、手動による人間ベースのフィードバックを忘れてはいけません。これは通常、LLMアプリケーションの初期段階でデータサイエンティストやエンジニアによって考慮されます。LLMの観測可能性ソフトウェアには、この作業を支援するためのインターフェースが通常備わっています。早期開発のフィードバックに加えて、最終評価プロセスにおいても（および継続的なモニタリングにおいても）、人間のフィードバックを含めるのはベストプラクティスです。50から100の入力プロンプトを取得し、出力を手動で分析することは、最終製品について多くのことを教えてくれます。

LLMのトラッキング

トラッキングはモニタリングの前提です。私の研究では、LLMのトラッキングの詳細には十分なニュアンスがあるため、それについて独自のセクションを設ける価値があると判断しました。トラッキングの容易な部分では、リクエストの数、応答時間、トークンの使用量、コスト、エラー率をキャプチャすることが含まれます。標準のシステムモニタリングツールはここで役割を果たし、LLM固有のオプション（および従来のモニタリング企業は、シンプルな機能メトリックトラッキングに基づいたLLMの観測性とモニタリングを主張するマーケティングチームを持っています）。

将来の分析のために入力プロンプトと出力応答をキャプチャすることで、深い洞察が得られます。これは表面上は簡単に聞こえますが、実際にはそうではありません。複雑さは、これまでに軽視してきたことから生じます（ほとんどのデータサイエンティストがLLMについて話したり書いたりする際に同様のことをしています）。私たちはLLMを評価、トラッキング、モニタリングしているのではありません。私たちはアプリケーションに取り組んでおり、1つ以上のLLM、事前に設定された指示プロンプト、および出力を生成するために協力するエージェントの集合体と取り組んでいます。一部のLLMアプリケーションはそれほど複雑ではありませんが、多くのアプリケーションが複雑であり、その傾向はより洗練された方向に向かっています。少しでも洗練されたLLMアプリケーションでは、最終的なプロンプト呼び出しを正確に把握することは困難です。デバッグを行う場合、各ステップでの呼び出しの状態とそれらのステップのシーケンスを知る必要があります。実践者は、これらの複雑さを解明するのに役立つソフトウェアを活用したいと考えるでしょう。

LLMのモニタリング

ほとんどのLLMとLLMアプリケーションは、少なくともある形式の評価を受けていますが、連続的なモニタリングを実施しているものはあまりありません。モニタリングのコンポーネントを分解して、ユーザーとブランドを保護するモニタリングプログラムを構築するのに役立ちます。

(1) 機能モニタリング

まずはじめに、トラッキングセクションで言及された容易な部分を継続的にモニタリングする必要があります。これにはリクエストの数、応答時間、トークンの使用量、コスト、エラー率が含まれます。

(2) プロンプトのモニタリング

次に、ユーザーが提供したプロンプトまたは入力をモニタリングする必要があります。Readabilityなどの単体のメトリックは有益な情報となるでしょう。Toxicityなどをチェックするために、Evaluator LLMを使用することがあります。参照プロンプトからの埋め込み距離もスマートなメトリックです。アプリケーションが予想よりも大幅に異なるプロンプトを処理できる場合でも、顧客のアプリケーションとの相互作用が新しいものであるか、時間とともに変化するかどうかを知りたいと思うでしょう。

この時点で、新しい評価クラスを紹介する必要があります: 公然の試みまたは悪意のあるプロンプトの注入です。初期評価では常にこれを考慮するわけではありません。既知の公然のプロンプトのリファレンスセットと比較することで、悪意のある行為者を特定することができます。評価者LLMもプロンプトを悪意のあるものかどうかで分類することができます。

(3) 応答のモニタリング

期待する出力とLLMアプリケーションが出力しているものを比較する際に実装すると便利なチェックがいくつかあります。関連性を考慮してください。LLMは関連性のある内容を返していますか、それとも草木に迷っていますか（妄想）？予期しないトピックの逸脱が見られますか？感情はどうですか？LLMの応答は適切なトーンであり、これは時間とともに変化していますか？

これらのメトリクスを毎日モニタリングする必要はないかもしれません。月次または四半期ごとのモニタリングがいくつかには十分です。一方、有害な出力や有害な出力は、LLMを展開する際の最大の懸念事項です。これらは、より定期的に追跡したいメトリクスの例です。以前に議論した埋め込みの視覚化テクニックは、原因の分析に役立つかもしれません。

プロンプトの漏洩は、まだ紹介していない敵対的な手法です。プロンプトの漏洩は、誰かがアプリケーションをだまして保存されたプロンプトを漏らすことが発生します。最良の結果を与えるための事前設定のプロンプト指示を特定するために多くの時間を費やした可能性があります。これは機密情報です。プロンプトの漏洩は、応答のモニタリングとプロンプト指示のデータベースとの比較によって発見することができます。埋め込み距離のメトリクスがうまく機能します。

評価またはリファレンスデータセットがある場合は、定期的にLLMアプリケーションをこれらに対してテストし、前回のテスト結果と比較することができます。これにより、時間の経過とともに精度を把握し、ドリフトを検知することができます。問題が見つかった場合、埋め込みの管理ツールには、パフォーマンスが低い出力のデータセットをエクスポートして、これらのトラブルの種類のプロンプトに対してLLMを微調整することができる機能があります。

(4) アラートと閾値

閾値とアラートが多くの誤警報を引き起こさないように注意する必要があります。多変量のドリフト検出とアラートは役立ちます。私はこれをどのように行うかについての考えがありますが、それは別の記事で保存します。ところで、この記事のどの研究でも誤警報率や閾値のベストプラクティスについての言及を見かけませんでした。それは残念です。

アラートに関連するいくつかの便利な機能がありますので、必要なリストに含めることができます。多くのモニタリングシステムは、SlackやPager Dutyなどの情報フィードとの統合を提供します。一部のモニタリングシステムでは、入力プロンプトがアラートをトリガーした場合、自動的な応答ブロッキングが可能です。同じ機能は、ユーザーに送信する前にPIIの漏洩、有害性、その他の品質メトリクスをスクリーニングするためにも適用できます。

ここでさらに1つの観察を追加しますが、それ以外の場所がわからなかったためです。カスタムメトリクスは、モニタリングスキームにとって非常に重要です。お使いのLLMアプリケーションはユニークかもしれませんし、またはチームの優れたデータサイエンティストがアプローチに大きな価値を付加するメトリクスを考えました。この領域ではおそらく進歩があるでしょう。カスタムメトリクスの柔軟性が必要です。

(5) モニタリングUI

システムにモニタリング機能がある場合、メトリクスの時間系列グラフを表示するUIがあります。それはかなり標準的です。UIの違いは、アラートトレンドの詳細な原因分析を示すようにドリルダウンすることを可能にする点で異なります。他のUIでは、クラスタと射影に基づいた埋め込み空間の視覚化を容易にする機能があります（これらの埋め込みの視覚化の有用性に関する調査を見たり、実施したりしたいと思います）。

より成熟したオファリングでは、モニタリングをユーザー、プロジェクト、チームごとにグループ化します。RBACを持ち、すべてのユーザーが知る必要があるという前提で動作します。今日の多くの組織では、ツール内の誰でも他の人のデータを見ることができることは望ましくありません。

警報が受け入れられない誤警報率を引き起こす傾向を強調した問題の原因の1つは、UIがアラートの適切な分析を容易にしないことです。ソフトウェアシステムがこの点で最適化を試みることはまれですが、一部のシステムでは可能です。このトピックについては、後でさらに詳しく説明します。

実務者とリーダーへの最終的な考え

リーダーの皆さま、LLMのモニタリングと可観測性を組織のイニシアチブの最上位に置かないとリスクが高すぎると言わざるを得ません。ユーザーに害を与えたりブランドの評判を損なうことを防ぐためだけでなく、それは明らかにあなたのレーダーにあります。あなたが理解していないかもしれないのは、あなたの会社のAIの迅速で持続可能な採用が成功と失敗の違いを生む可能性があり、詳細な技術的なロードマップを持つ成熟した責任あるAIフレームワークは、競争相手よりもより速く、より良く、より安全にスケーリングするための基盤を提供します。

実践者の皆さん、この記事で紹介されている概念は、LLMの可観測性とモニタリングの実装に含まれるべきツール、テクニック、およびメトリクスのリストを提供しています。これをガイドとして使用して、自分たちのモニタリングシステムが求められる役割を果たしているか確認することができます。また、私たちが議論した各概念についてのより深い研究の基盤としても活用できます。

これは非常に興味深い新しい分野です。これに精通したリーダーや実践者は、AIの時代においてチームや企業の成功に貢献することができるでしょう。

著者について:

ジョシュ・ポドスカは、20年以上の経験を持つAIリーダー、戦略家、アドバイザーです。彼はかつてDomino Data Labのチーフフィールドデータサイエンティストを務め、複数の企業でチームをマネジメントし、データサイエンス戦略をリードしてきました。ジョシュは複数の領域でデータサイエンスソリューションを構築・実装してきました。彼はUCアーバイン校で数学の学士号を取得し、コーネル大学で応用統計学の修士号を取得しています。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!