SplunkとRAGで実現するエンドツーエンドのLLMオブザーバビリティ構築術

大規模言語モデル(LLM)は、あらゆる業界でユーザーエクスペリエンスを再定義しています。LLMは重要なアプリケーションの原動力となって、リアルタイムでインサイトを提供し、ワークフローを効率化し、人とテクノロジーとの関わり方を一変させています。

たとえば、シスコでは、Splunk AI Assistantが検索拡張生成(RAG)システムを活用し、厳選された公開コンテンツに基づいて、よくある質問(FAQ)に対して迅速かつ正確な回答を提供しています。しかし、現代の複雑なデジタル環境において、LLM搭載アプリケーションを大規模に運用するには、特有の課題が伴います。それは、回答の正確性や信頼性から、コスト管理、そしてユーザーの信頼獲得に至るまで、多岐にわたります。

構築の舞台裏：CIRCUITを利用したRAGの実装

• アプローチ：CIRCUITを利用した検索拡張生成(RAG) APIをハッカソンスタイルの短期集中開発サイクルで開発
• データ範囲：セッションリスト、イベントポリシー、Tips集、グローバルブロードキャストスケジュール、厳選されたコンテンツマトリックス(シスコ公開情報)など、実際の.conf24の資料
• 運用面：SplunkサーチとSplunk Observabilityの強力な機能を駆使し、コンテキストの鮮度と安全性を維持するためのダッシュボードとアラートを構築

重要なポイント：プロンプト、検索、生成のすべての工程において、設計段階からオブザーバビリティを組み込むことで、反復的な作業を加速し、リリースに伴うリスクを低減できます。

LLMオブザーバビリティを実現するSplunk

LLM (大規模言語モデル)やRAG (検索拡張生成)システムを監視する際には、レイテンシーなどのパフォーマンスだけでなく、回答の精度や信頼性についても可視化することが不可欠です。以下に示すSplunkのダッシュボードは、LLMの出力、ソースドキュメント、レイテンシー、そして信頼性スコアといったスタック全体の主要なシグナルを統合し、単一の画面で可視化します。

各要素がどのように包括的なLLMオブザーバビリティの実現に貢献するか、その詳細を解説します。

• 🔍 単一の画面：このダッシュボードでは、回答品質、モデルのレイテンシー、ドキュメントの信頼性、そしてコストといった主要なメトリクスを1つの統合ビューに集約します。これにより、運用チーム、ML (機械学習)チーム、コンテンツ所有者は、複数のツールやログを行き来することなく、パフォーマンスや回答の精度を詳細に分析できるようになります。
• 📑 ドキュメントの透明性：ダッシュボードの「コンテキスト内ドキュメント」セクションでは、ユーザーの特定のクエリーについてどのようなソースドキュメントが検索され、LLMに渡されたかが明確化されます。これは、ハルシネーションなどの問題を監査、デバッグする上で不可欠です。精度の低い回答が生成された際、その根拠となったドキュメントまで遡って特定できるからです。
• 🟢🔴 ソースの信頼性の構成比：ソースドキュメントは、定義済みの品質基準に基づいて信頼性が3段階(緑/黄/赤)で分類されます。この分布を確認することで、精度の低い出力の原因がソースのキュレーションの質の低さにあるかどうかを特定できます。それを基に、どのドキュメントを修正、再インデックス化、削除すべきか、優先順位を明確に判断できるようになります。
• 🧠 RCA (根本原因分析)ワークフロー：回答が「低品質」と判定された場合、このダッシュボードがエンドツーエンドの調査を強力にサポートします。ユーザーの質問から、検索されたドキュメント、LLMプロンプト、応答レイテンシー、トークン使用量(コスト)、さらにはリクエストを処理したモデルのバージョンに至るまで、一連の流れを追跡できるため、LLMの不具合における平均修復時間(MTTR)を大幅に短縮できます。

重要なポイント：これらのビューをSplunkに統合することで、本番環境でLLMやRAGアプリケーションを運用するチームは、以下のことが可能になります。

• ハルシネーションの抑制
• プロンプトと検索設定の最適化
• システムパフォーマンスの監視
• ソースドキュメントの健全性の追跡と改善

事例：LLMアプリケーションの品質監視

このスクリーンショットは、RAG (検索拡張生成)アプリケーションの品質監視に特化して構築された、Splunk SPLカスタムダッシュボードです。回答の正確性、ドキュメントの関連性、モデルの信頼度、レイテンシーに関するメトリクスを統合し、RAGの出力品質を360度全方位から可視化します。

統合によるメリット：エンドツーエンドのRAG品質監視

• レイヤー：検索、LLM出力、レイテンシー

• 監視対象ソース：コンテキストラベルとドキュメントソース、LLMスコアと回答の正誤、レイテンシーの時系列データ、ソース品質の構成比(パイチャート)

• 生み出される価値：

  • LLMに対して最適な関連ドキュメントを確実に提供
  • 回答の正確性を把握し、ハルシネーションのリスクを特定
  • システムパフォーマンスとユーザーの待ち時間を監視
  • トレーニングデータと検索データセットをクレンジング

重要なポイント：検索、出力品質、レイテンシーを統合することで、単なる「点」のメトリクスではなく、因果関係を可視化できます。

事例：ハルシネーション

以下は、軽微なハルシネーションが発生する様子の典型的な例であり、特にRAGベースのLLMシステムにおいてオブザーバビリティがいかに不可欠であるかを浮き彫りにしています。

類似する2つのクエリーと異なる回答

質問1：「ボストンへのフライトが日曜の夜8時頃と、かなり遅い到着になります。カンファレンスセンターでのバッジ取得手続きなどの受付時間を教えてください」

• モデルの挙動：「アジェンダを確認した上で」という明確なプロンプトがなかったため、LLMは最も関連性の高いドキュメントを優先できませんでした。その結果、一部の登録関連情報は含んでいるものの、完全な回答に必要な「曜日別の詳細スケジュール」が欠落した「出発前の注意事項」に関するドキュメントを引用してしまいました。これにより、不完全、あるいは誤解を招く恐れのある回答、すなわち軽微なハルシネーションが引き起こされました。

質問2：「アジェンダを確認した上で、もう一度答えてください。ボストンへのフライトが日曜の夜8時頃と、かなり遅い到着になります。カンファレンスセンターでのバッジ取得手続きなどの受付時間を教えてください」

• モデルの挙動：「アジェンダを確認した上で」という明確な指示により、LLMは詳細なドキュメントの抽出に成功しました。その結果、登録時間に関する正確な回答が提供されました。

LLMオブザーバビリティが不可欠な理由

• 入力の監視：プロンプトの品質や構成を追跡することで、質問1には質問2のような明確な「指示」が欠けていたことが浮き彫りになります。
• RAGパイプラインの監視：「コンテキストコンテンツ処理」や「ソースの品質」(Splunkダッシュボードの例を参照)を監視することで、各クエリーに対してどのドキュメントが検索されたかが明確になります。前述の質問1の場合、正解を含む「アジェンダ」に関するドキュメントが優先されて検索されなかったことが示されたため、それが軽微なハルシネーションの原因であったと特定できます。
• 出力の監視：LLMスコアやヒューマンインザループ(人間参加型)フィードバックを活用することで、質問1の回答に「不完全」または「関連性が低い」などのフラグを立て、即座に詳細な調査を開始できます。

重要なポイント：オブザーバビリティとヒューマンインザループ(人間参加型)を組み合わせることで、どのような場合にコンテキスト不足による軽微なハルシネーションが発生するかを理解し、プロンプトや検索ロジックの的確な改善につなげることができます。

事例：構造化ログペイロード(RAG回答)

以下は、正常に処理されたRAG回答でのアプリケーションログのサンプルです。プロンプトと回答のコンテキスト、検索ソース、トレース用のメタデータが含まれています。このように高度に構造化されたログを活用することで、Splunk上での精密なダッシュボード作成、アラート設定、そして根本原因分析が可能になります。

オブザーバビリティとRCAを支える主要機能

• イベントタイプとステータス：event=RAG_ANSWER_DEBUG、status=success、isAnswerUnknown=false、errorCode=0
• クエリーと回答：query=global broadcast live? (グローバルブロードキャストはライブ配信ですか？)という質問とユーザーに向けて表示された回答
• 検索の透明性：sources、sources_initial、references、信頼性と網羅性を分析するためのurl_category (緑/黄/赤)
• 根拠のシグナル：事実との整合性を測るmemory_facts_probability_category=green
• トレースコンテキスト：mdc.trace_id、mdc.span_id、trace_flagsによって、Splunk Observabilityでログとトレースを紐付け
• ランタイムメタデータ：hostName、processName、コンテナコンテキストでフリート全体を比較

重要なポイント：プロンプト、ソース、トレースIDを含む構造化ログにより、精密なダッシュボードの構築、アラート設定、根本原因分析が可能になります。

事例：回答品質を測定するSPLクエリー

回答品質を分析するための、サンプルSPLクエリー

index="web-eks" sourcetype="kube:container:*" container_name="it-ai" cluster_name="wmd-columbia" "event=RAG_ANSWER" 
| spath input=message 
| rex field=message "answerStatus\\s*=\\s*\\\"(?[^\"]+)\\\"" 
| stats count by answerStatus 
| eventstats sum(count) as total 
| eval percentage=round((count / total) * 100, 2) 
| table answerStatus count percentage 
| eval answerStatus=case( 
    answerStatus="true", "NOT_FOUND", 
    answerStatus="false", "ANSWER_FOUND" 
) 

この分析が役立つ場面

• 生のアプリケーションログを、SLAの評価に使用できる回答品質の分布データへと変換する。
• 一定期間内に「回答不能(NOT_FOUND)」がしきい値を超えた際にアラートを通知する。
• モデルのバージョン、ルート、またはソースの信頼性セグメントごとのトレンド分析を行う。

重要なポイント：SPLを使用することで、ログを実践的なメトリクスへと変換し、SLAに準拠したアラート設定を実現できます。

可視化とアラート

• リアルタイムKPI：根拠性と関連性、レイテンシー、エラー率、トークン予算、リクエスト単価
• ドリフトと鮮度低下：根拠性が低下した際や、主要なソースドキュメントが古くなった際のアラート通知
• セキュリティ：プロンプトインジェクションやジェイルブレイクパターンの検知と異常アラート
• 根本原因分析：低品質な回答から、プロンプト、検索ドキュメント、モデルのバージョン、コストへと即座にドリルダウン

重要なポイント：単なるエラーにとどまらず、根拠性の低下やソースの鮮度低下、プロンプトインジェクションのパターンまで網羅してアラートを通知できます。

RAGオブザーバビリティコンテキストのサマリー

以下のスクリーンショットは、Splunk Observability Cloudを用いたRAGアプリケーションのオブザーバビリティ監視画面です。ここでは、本番環境(service-prod)における「ai-deployment」サービスを示しています。

Kubernetesとリソースの健全性

Splunk Observability CloudのこのAPMダッシュボードは、.conf RAGパイプラインのメインAIオーケストレーションを担う「bridgeit-ai-svc」サービスを監視しています。

APMによるRAGオブザーバビリティのサマリー

重要なポイント：APMを活用することで、生成AIの監視やユーザーエクスペリエンスに直結する成功率、レイテンシー、依存関係を可視化できます。

事例：膨大なデータからピンポイントで検索

Splunk Observability CloudのAPMトレースを捉えたこれらのスクリーンショットは、まさに「干し草の山から針を探す」ような困難な検知シナリオを再現しています。これは、RAGシステムのトラブルシューティングにおいて、オブザーバビリティが果たすべき極めて重要な役割です。

トレースの概要

以下は、Splunk APMダッシュボードの「Traces (トレース)」タブのスクリーンショットです。ここでは、RAGサービスの挙動の全体像を捉え、エラーパターンとパフォーマンスの異常値の両方を明確に把握できます。

RAG特有のオブザーバビリティ：重要ポイント

1つのユーザーリクエストが複数の内部サービスを横断することは珍しくありません。数千件の正常なリクエストの中から、たった1件の異常なリクエストの根本原因を特定することは、まさに「needle-in-a-haystack (干し草の山から針を探す)」ような困難な作業です。

オブザーバビリティによる主要なメリットの例

重要なポイント：トレースを軸としたRCAにより、RAGライフサイクル全体に潜む稀なエラーを特定し、迅速に修正できます。

ガバナンスと再現性

• スコープとデータの最小化：シスコの公開データのみを使用。プロンプト、RAGプロセス、テスト、ログには個人情報を一切含めていません
• デプロイとアクセス：提供制限対象地域への制限を遵守しつつ、グローバルなリーチを実現する、.conf参加者向けのハイブリッドデプロイ
• 監視とメンテナンス：モデルドリフトの監視、定期的なテスト、インシデント対応の計画を策定します
• バージョン管理：BridgeIT RAG-as-a-Serviceにより、検索ロジック、インデックス、モデルのバージョン管理とロールバックに対応します

重要なポイント：データの最小化、厳格なバージョン管理、そして精度の劣化(ドリフト)を見据えた設計がガバナンスの遵守と信頼性の確保に不可欠です。

オブザーバビリティを競争優位性につなげる

✅ What We Learned

LLMオブザーバビリティは、単なる「あれば便利な機能」ではありません。それは「実験」を「オペレーショナルエクセレンス」へと進化させる架け橋です。これによって、ブラックボックス化しがちなAIの挙動を、測定可能でアクションにつなげられるインサイトへと変えることができます。特に検索拡張生成(RAG)システムにおいて、オブザーバビリティはAIが回答を生成するライフサイクル全体を追跡することを可能にします。ユーザーのクエリーから、ドキュメントの検索、プロンプトの構築、そしてLLMによる最終的な回答とその品質評価に至るまで、すべてを網羅します。シスコでは、LLM搭載アプリケーションの オブザーバビリティの基盤としてSplunk を採用しました。これにより、回答の品質、インフラのパフォーマンス、そしてビジネスインパクトがどのように交差しているかを統合的に把握できます。その結果、パフォーマンスの低下やドリフト、あるいは予期せぬ挙動に対し、ユーザーが気づく前、そしてコストが膨れ上がる前に、迅速に対処することが可能になっています。

🚀 オブザーバビリティを競争優位性につなげる

LLMオブザーバビリティは、AIを「期待の試作品」から「信頼できる製品」へと進化させます。それは、AIのパフォーマンスが良い理由を「推測」しているだけなのか、あるいは成功や失敗の要因を「正確に把握」できているのかという、決定的な違いをもたらします。

RAGシステムの文脈において、これは以下の要素を監視し、相互に関連付けられることを意味します。

• プロンプト処理
• ドキュメント検索の品質
• コンテキストの構築
• 生成のレイテンシーとコスト
• 出力の評価とソースの追跡可能性

このレベルでの可視化を実現できるだけの投資を行っている組織は、信頼性が高く、コスト効率に優れ、拡張性の高いAIソリューションを実現できるでしょう。一方で、それを怠る組織は、信頼性、コスト管理、そしてユーザーの信用の面で、山積する課題に直面することになります。

🔧 次なるステップ

LLMオブザーバビリティを実運用に落とし込むためには以下を実行しましょう。

1. 成功指標を定義する：自社のユースケースにおいて、許容可能な品質、コスト、パフォーマンスの基準を明確にします。
2. パイプラインにオブザーバビリティを実装する：LLM/RAGフローのあらゆる工程で、意味のある「構造化データ」がログとして記録されるようにします。
3. 因果関係を把握できるダッシュボードを構築する：技術的メトリクス(レイテンシー、トークン使用量など)が、ビジネス成果(回答の正確性、サポート削減率など)にどう結びついているかを可視化します。
4. プロアクティブなアラートを設定する：品質の低下、レイテンシーのスパイク、コスト超過を、ユーザーに影響が及ぶ前に検知できるよう監視します。
5. レビュー体制を確立する：エンジニアリング、データサイエンス、製品担当のステークホルダーが一貫して連携し、AIスタックを継続的に改善できる体制を構築します。