生成 AI アプリで収集するべきテレメトリは何か
2024 年現在、生成 AI のアプリケーションへの応用が進んでおり
生成 AI 専用のサービスとしては LangSmith と Langfuse が有名で、それぞれモデルへの入出力やトレースなどを取ることができます。
監視 SaaS である Datadog でも LLM Observability の機能がリリースされています。
また先月末には Google Cloud のブログにて GenOps についての記事が投稿され、その中でロギングや評価についての記載もありました。
生成 AI アプリケーションのオブザーバビリティについてはまだ発展途中な部分も多くあります。
しかしこれらのサービスを見る中で、現時点で生成 AI アプリケーションで収集するべきテレメトリが何かある程度見えてきたため、今回はそれらについてまとめていきます。
メトリクス
生成 AI アプリケーションでは以下のようなメトリクスを収集するべきです。
入出力のトークン数、課金額
モデル利用に対しての課金は通常、入出力のトークン数に対してされます。
入出力トークン数を監視することで、モデルをどの程度利用しているかを把握することができます。
より直接的に課金額として監視するのも良いですが、トークン数で記録しておいた方が他のモデルに変更した場合の試算がしやすいため、どちらも収集するのが良いかもしれません。
生成にかかった時間
生成 AI はその他の外部サービスと比べ、一般にレイテンシーが高めになります。
出力トークン数にもよりますが数十秒かかるのが普通で、さらに同期的に実行する必要があります。
結果が全て生成されるのは時間がかかりすぎるため、結果をストリーミングし順次表示していくのが一般的ですが、それでも数秒はかかります。
そのため生成にかかった時間を継続的に監視し、モデル/プロンプト/パラメータなどの変更がユーザに影響ないか観測できる必要があります。
生成にかかった時間としては、以下の二つを取るべきです。
- TTFT (Time to First Token)：最初のトークンが表示されるまでの時間
- TTLT (Time to Last Token)：最後のトークンが表示されるまでの時間
入出力の評価
生成 AI のレスポンスは確率的であり、あらかじめ品質を担保することはできません。
そのため実際の結果に対して評価を行い、精度や品質を監視する必要があります。
実装方法については、実際の入出力についての評価であり期待される解答のようなものはないため、LLM as a Judge でやることになるでしょう。
生成 AI アプリケーションの評価については、単体で記事が書けるような概念なので今回はあまり踏み込みませんが、以下のような観点があります。
- 出力が入力に対する返答になっているか
- ハルシネーションはないか
- 適切な言語で出力しているか
- 有害、または攻撃的な内容が含まれないか
またユーザの入力についても以下のような観点が考えられます。
- 有害な入力やプロンプトインジェクションをしていないか
- ユーザの感情がネガティブなものになっていないか
ログ
生成 AI アプリケーションではログとしてモデルへの入出力を収集するべきです。
メトリクスの部分でも述べましたが、モデルへの入出力に対して評価を行う必要があり、評価にも生成 AI を使うことになります。
そのため評価を同期的に実施することは現実的ではありません。
実際には入出力をロギングし、非同期で評価を行うことになるでしょう。
Google の GenOps の中でも、定期的なスケジューリングやなんらかのイベントをトリガーとして評価することが示唆されています。
トレース
モデルの実行は、生成 AI ということを抜きにすれば「レイテンシーが高めの外部サービスの呼び出し」ということになります。
そのためその他の外部サービスと同様にトレースを収集する必要があります。
特にエージェントとして生成 AI アプリケーションを実装する場合は、 1 つのタスクで複数回のモデル実行や Function calling を行いますが、それらを 1 つのトレースとして確認できる必要があるでしょう。
属性
生成 AI アプリケーションのテレメトリには以下のような属性を付与するべきです。
モデルの（プロバイダと）バージョン
生成 AI のレスポンスはモデルによって異なります。
そのため利用したモデルについての情報を含めるべきです。
プロンプトのバージョン
生成結果の品質はプロンプトに左右されます。
アプリケーションで利用するプロンプトについてはバージョン管理した上で、そのバージョンを属性に含めるべきです。
リクエストのパラメータ
生成 AI のレスポンスはモデルやプロンプトが同じであっても、以下のようなパラメータによって結果を調整することができます。
-
max_tokens：生成結果の長さ -
temperature：出力のランダム性 -
top_k：トークン選択時に上位何件を候補にするか -
top_p：トークン選択時の累積確率の閾値
そのためこれらのパラメータについても属性に含めるべきです。
各サービスの対応状況
最後にここまで述べた内容について、各サービスが現時点でどの程度対応しているかを記載します。
対象のサービスは LangSmith, Langfuse, Datadog です。
LangSmith
LangSmith は今回述べた内容については全て対応しています。
LangSmith には LangChain Hub と統合されたプロンプト管理機能があり、計装している処理の中でプロンプトを取得することでトレースとプロンプトのバージョンが紐付きます。
評価機能についてはデータセットでの評価機能、API を使った評価結果のアップロード、トレースに対する自動評価機能があります。
トレースなど
パラメータ
プロンプトのバージョン
評価結果
Langfuse
Langfuse は今回述べた内容については全て対応しています。
Langfuse にはプロンプト管理機能があり、モデル呼び出しにプロンプトオブジェクトを渡すことでトレースにプロンプトのバージョンが紐づきます。
評価機能については手動でのアノテーションと SDK/API を用いたスコアの追加が可能です。
また SaaS 版ではパブリックベータですが自動での評価機能があり、スコアをトレースに紐づけられます。
トレース
スコア
Datadog
Datadog LLM Observability は今回述べた内容についてはプロンプトのバージョン以外対応しています。
Datadog LLM Observability にはプロンプト管理機能がないため、ユーザ側で管理する必要があります。
紐付けについては、スパンに独自の情報をアノテーションとして追加できるため、アプリ側で設定すれば良さそうです。
評価については組み込みの自動評価のほかに SDK/API を使ったカスタム評価を投稿できます。
トレースなど
評価
Discussion