LLMモニタリング: 遅延,エラー,トークンを超えて測定すべきもの

LLMのモニタリングは,モデルの呼び出し状態から始めなければならない. これはチャット機能,リクエストパイプライン,またはAPI包装の合理的なデフォルトです. 同じアプリケーションが計画を立て,ツールを呼び,承認を待て,後で再開するか,またはタスクを完了したと宣言すると,運用健康のための2番目のレジーを追加します. 2つのレジーは異なる質問に答えています モデルサービスが正常に動作していたか? 2番目の質問は, 代理人が有用な進歩を行い,期待された結果をもたらしたのか? run id で参加してください. 緑色の遅延チャートを健康的な仕事であると主張に変えることはありません. デフォルトのLLMモニタリングレイヤから開始する 役に立たない最初のダッシュボードには 何十個のパネルは必要ありません 提供者の失敗,アプリケーションの失敗,コスト漂移,および輸出品質漂移を区別するのに十分な証拠が必要です. 信号 疑問に答えます 実践的な最初の警報 証明できないこと 要求誤差率 モデルの通話が失敗している? 提供者とモデルによって分割されたウィンドウ上の料金 成功した呼び出しが任務を進めたかどうか p50/p95 遅延 反応時間が下がったのか? 類似型操作とモデルを比較する 遅い走りは最終的に 入力/出力トークン 背景や世代が成長したのか? 作業特有のベースラインからの変更 追加トークンが有用かどうか 通過力 負荷が変わってるのか? 1分毎の要求と同時性 予定されたランが逃れたかどうか 品質スコア サンプル出力はルールを満たしたのでしょうか? バージョン評価機と人間の校正 ファイル,チケット,またはデプロイメントが存在するかどうか 追跡対象 オペレーターは実行を再構築できますか? 走行時間による欠落または不完全な痕跡 意図された結果が存在するかどうか このベースラインは現在の検索目的と一致する. ラングフューズは,実行経路と出力品質の評価の痕跡を持つ,遅延,吞吐量,エラー率に関するモニタリングを記述します. SplunkとDynatraceはリソース,安全,コスト,フィードバック,アプリケーション信号にセットを拡張します. これらはLLMアプリケーションの有用な見解であり,エージェント層が存在しただけで,いずれも廃棄されるべきではありません. OpenTelemetryのGenAIセマンティックコンベンションは,機器自体で分離を可視化します. 開発仕様では, gen ai.client.token.usage と gen ai.client.operation.duration を定義し, gen ai.invoke agent.duration ,推論呼び出し数,ツール呼び出し数などのワークフローとエージェントのインストラクタを分離します. 開発 ここで重要なことは: 実行するバージョンを固定し,名前変更を期待する. クリーン実装は, run id , operation , provider , model ,タイムスタンプのキーでモデルコールレジャーです. サービスレベルのアラートに 組み込むが 個々の走行への道を維持する. 実行識別子のないトークンピークは,請求書である. 停止した実行に付属したトークンピークは,事故の手がかりである. アプリケーションがエージェントになったとき,タスク・ヘルスのレジャーを追加する LLMがサポートする機能は,時間の経過とともに作業を行うときに,運用境界を横切ります. データベースに電話したり 報告書を書いたり 引き出願書を開いたり 待機したり 予定通りに目覚めたりします その時点で,成功したモデル応答は,中間的な出来事に過ぎない. OpenAI Agents SDKは,これらのイベントがどれほど豊かになるかを示しています. その内蔵の追跡記録は 世代 機能ツール コール 手渡し 警備線 代理人走行 これは貴重なデバッグ証拠です 同文書はまた,生成と機能範囲には敏感な入力と出力が含まれていることも指摘しており,これはコンテンツキャプチャを監視の前提条件ではなく明示的な選択にする理由です. タスク・ヘルス・レジーは 痕跡よりも小さいものになることがあります ランごとに記録: expected outcome : report exists and parses のような予告語であって, 完成するタスクではない. outcome verified : true , false ,または unavailable ,検証版; progress delta :指定されたウィンドウでタスクの特定カウントまたは消化変更 waiting on : human approval ,または null などの指定された依存性. last heartbeat at と last progress at ,活動と進歩は異なる時計であるため. declared complete : 実行時間の報告; collector freshness :これらの事実が最後に観察されたとき. この本書は意図的にすべての提示,完了,または期間を繰り返さない. ランニングがうまくいくのか 待っているのか 閉じ込められているのか 到達できないのか 完成していないのか 決定するために必要な最低限の証拠を 蓄積します 原油の痕跡は,政策が許可する限り調査が可能になります. 重要なモデリング選択は 三州立証です 収納品が確認できない場合, outcome verified: "unavailable" を記録する. 欠落した証拠を true に変換し,その信号が欠けているだけで未知の実行が失敗したと呼び出さない. 6回でギャップを再現する 付属装置には6つの合成ランが含まれています. LLM レジャーは,要求エラーが少なくとも 20%である場合, p95 遅延が 5,000 ms を超える場合,またはトークン使用が 20,000 を超える場合,アラートします. 任務健康本書は 明確な待機,確定的な結果と宣言された完了と 進歩の新鮮さをチェックします Node.js 20 またはそれ以降で監査を実行する: その正確な結果は 意見の不一致は結果であり 本簿の欠陥ではありません 代理人がまだ進歩しているにもかかわらず サービスモデル調査が必要です 遅い走りは 検証された結果で完了したため 欠勤事故ではなく 性能の問題です LLMモニターでは 承認待ちと誤った失敗は正常に見えます 彼らの通話は速く 安く成功しました 注目すべきことは 任務契約のみです 数字は反例であり 基準ではない. 6つの合成記録は,普遍的な警戒値を設定することはできません. 締め切りを ランタイムからのベースラインに置き換えて progress delta を 実際の仕事に関連した証拠に置き換えてください 任務契約をアラートに変える 一つの高価値なワークフローから始めましょう もう1つのダッシュボードを追加する前に,その完了予測を書きなさい. 研究作業には,Markdownファイル,少なくとも2つのアクセス可能なソース,およびスケーマ有効な証拠レジャーが必要かもしれません. コード作業には クリーンパッチと テストコマンドが必要かもしれません サポートエージェントは チケットを作成するか 記録されたエスカレーションを要求するかもしれません 信号を意味を保つ順序で評価します 1. ランタイムやコレクターが時代遅れなら,ランが到達できないか,不確実であるかをマークする. 2. waiting on が明示されている場合,実行を再起動する代わりに依存をルートします. 3. 実行時間が完了したと宣言した場合,結果予告を評価する. 4. ランがアクティブだが, progress delta が窓の外でゼロにとどまれば,それを固定する. 5. 適用されず 役に立つ進歩が 鮮やかであれば 実行させてください この命令は3つの騒音な介入を防ぐ. 合法的な承認を待つことは 停滞ではありません ゼロから出てきたコマンドは自動的に完成したタスクではありません. 重複した道具で 繁忙な痕跡は 変化しない場合 進歩とは限りません 次の安全対策を警告する 症状だけじゃない 提供者のエラーアラートは,モデル,操作,エラークラス,追跡リンクを含むアプリケーション所有者に送信されます. 承認の待機は 決定できる人に 求められる範囲を正確に指定します 失踪結果の警告は 失敗した予告を指します 再試ループは限られた休憩または調査を推奨する. すべてを集める必要がない限り 結合を有効に保つ 2つのレジャーに1つの不透明な run id を使用する. その識別子に顧客テキスト,秘密,絶対的な経路,またはツール用荷物を入れないでください. 有用な相関記録には: データリスクが異なった場合,保存とアクセス規則を異なるようにしてください. 累積遅延とトークンヒストグラムは,プロンプトベアリングスペンズよりも長期保存が必要である. 結果の証拠は,しばしば手工品そのものではなく,消化,カウント,ステータスコード,またはスケーマ結果である可能性があります. 操作者が痕跡を掘り出すとき,その新鮮さとサンプリングの境界線を示し,欠席を証明と間違えないようにする. 自動評価にも限界がある. 確定性チェックはファイル,HTTPステータス,データベース行,テスト,構造化されたフィールドに好ましい. 意図された結果が質的な場合,バージョン化された評価者は助けることができますが,そのスコアは不確実性による証拠であり,基礎的な真実ではありません. 人間による評価に合わせて カリバーして unavailable 状態を維持する Sidewispが収まる場所 Sidewispの製品指向は,第二本目である. 現行の代理の実行時間に関する健康観,証拠,新鮮さ,発行優先順位,明示的な承認境界線を含む. 実行時間,モデルゲートウェイ,または原始追跡システムを置き換えることを意図していません. 指示だ 輸送された監視の主張じゃない Sidewisp は現在プライベートプレビュー段階です。 公開サイトと記事システムはライブで,生産代理の健康収集,実行時間アダプター,および復旧実行は一般的に送付されません. このモデル・コール・対結果の境界線が 解決する必要があるオペレーティング問題と一致する場合は プライベート・プレビューに参加してください. 主要情報源 OpenTelemetry GenAI メトリックセマンティックコンベンション client, workflow, agent, and tool operation の開発状態のメトリックの名前. OpenAI Agents SDK追跡ガイド 追跡されたイベントタイプ,輸出行動,および敏感データ制御. LLMの観測能力とモニタリングとは? 遅延,通量,エラー,追跡,評価に関する同じ意図のベンチマーク.