イントロダクション
主要コンセプト
Splunk Agent Observabilityは少数の用語を中心に構築されています。以降の章でこれらのコンセプトをすべて使用するため、まず整理しておきましょう。また、これらはこのワークショップのアジェンダに直接対応しています。
Trace、Span、セッション #
エージェントテレメトリの構造
- Trace はエージェントを通る1つのエンドツーエンドのリクエストです。例えば、チャットにおける1回のユーザーターンです。
- Span はTrace内の1つのステップです。LLM呼び出し、ツール呼び出し、または検索などがあります。Spanはネストするため、Traceはエージェントが何をどの順序で行ったかのツリー全体を示します。
- セッション は関連するTraceをグループ化します。例えば、1つの会話内のすべてのターンです。
Traceは project と agent stream で整理されます。projectはコンテナであり、agent streamはその中の名前付きの送信先です。このワークショップでは project-1 や project-2 のようなproject名と、default というagent stream名を使用します。ここでTraceを表示し、Evaluatorを有効にします。
Evaluators: 大規模な品質評価 #
Evaluators はTraceとSpanにスコアを付けます。例えば、Context Adherence（回答は根拠に基づいているか？）、Correctness、Tool Selection Quality、Prompt Injection などがあります。定性的な品質の問いを、モニタリングやアラート設定が可能な数値に変換します。
しかし、すべてのTraceを手頃なコストで評価するのは困難です。
大規模評価が難しい理由とLunaによる解決方法
大規模な汎用LLMをジャッジとして使用する方法は、1日数百のTraceでは機能しますが、数百万になると破綻します。すべての評価が高コストで低速なLLM呼び出しとなるため、チームはトラフィックの5〜10%のみをサンプリングし、ほとんどの本番Traceはスコアリングされないままになります。
Splunk Agent Observabilityは Luna を使用します。これは評価に特化してファインチューニングされた専用のSmall Language Models（SLMs）ファミリーです。その結果、劇的に安価で高速なスコアリングが実現し、トラフィックの すべて に対して実行できる精度を持ち、ユーザーエクスペリエンスを損なうことなく リアルタイムガードレール を動作させるのに十分な速度を備えています。
Signals: 未知の未知を浮上させる #
Metricsは測定しようと考えた問題について教えてくれます。Signals は本番Traceから繰り返し発生する障害パターン（計画ループ、ツールエラー、ハルシネーション、ルーティング障害など）を自動的に浮上させ、何が 問題だったか、なぜ そうなったか、次に何をすべきか を説明します。数週間かかるインシデント後分析を、的を絞った数分間の修復作業に変えます。
Guardrails: ランタイムでのアクション #
回答が患者に害を与える可能性がある場合、観測と測定だけでは不十分です。Guardrails（エージェントコントロール）はランタイムで各ステップを評価し、アクションを実行します。安全でないステップを完全に ブロック するか、エージェントを安全な応答に 誘導 します。ポリシーは一元管理されているため、エージェントをオフラインにすることなく数秒で変更できます。
1つのチャットメッセージがLLM呼び出しとそれに続く患者検索ツール呼び出しをトリガーします。これにより何個の Trace と何個の Span が生成されますか？