Opik LLM 可観測性: グリーンになる前の監査スレッド スコア

Opik はマルチターン エージェントについて多くのことを教えてくれますが、目に見える痕跡や高い会話スコアはまだ健全性を判断するものではありません。合理的なデフォルトは、トレースと評価の証拠に Opik を使用し、緑色で表示される前に 4 つの追加の事実を要求することです。つまり、意図したターンが 1 つのスレッド ID で着陸したこと、スレッドがスコアリングの対象となったこと、スコアが最新のアクティビティの後に生成されたこと、要求された結果が宛先に存在することです。 この区別は、スコアが欠けている場合、または安心できるように見える場合に最も重要です。 「スコアなし」とは、会話がまだアクティブであるか、サンプリング ルールによって除外されているか、スコアリングが保留中であるか、スコアリングが停止していることを意味する場合があります。 0.94 のスコアは、スレッドの前のバージョンに属している可能性があります。新しい 0.94 であっても、欠落したファイル、未送信のメッセージ、または失敗したアップデートと共存する可能性があります。 このガイドでは、内容のないレシートを作成し、それに対して 10 件のケースを再生します。リポジトリのコミット時に Opik 2.2.12 に対してチェックされました c54a6a9 プロンプト、応答、認証情報、顧客 ID は必要ありません。 スコアを判断する前にスレッドを証明してください Opik は、ユーザー定義の thread id を使用して関連するトレースをグループ化します。その 固定された会話ドキュメント 識別子はプロジェクト内で一意である必要があると述べています。これにより、オペレータに重要な境界が与えられます。つまり、会話は、ダッシュボード内で「関連しているように見える行が何であれ」ではないということです。 スレッドレベルの評価結果を読み取る前に、次のことを記録してください。 トレースを受信すると予想されるワークスペースとプロジェクト。 予期されるスレッド ID の不透明なハッシュまたは非機密表現。 意図したターンで観察された個別のスレッド ID。 最新のトレース アクティビティ時間。 可視性を確立するために使用されるコレクターまたはクエリ時間。 期待される ID と一致する観察された ID が 1 つアイデンティティ ゲートを通過します。ゼロ ID はテレメトリの問題です。 1 つの意図された会話に 2 つの ID がある場合、両方のフラグメントに個別に有効なスパンがある場合でも、フラグメント化となります。別のプロジェクトで同じ表示用 ID を再利用することも、証拠の範囲が異なります。 痕跡が存在しないときに評価者を責めることから始めないでください。 Opikさん 固定された SDK 構成ガイド TypeScript SDK および明示的な client.flush() および flushAll() コントロールでバッチ処理されるドキュメント。完了したフラッシュは配信の証拠としては役立ちますが、コレクターがバッチを受け入れたことや、クエリが意図したプロジェクトを読み取っていることは証明されません。フラッシュ境界後の可視性を確認します。 この順序により、一般的な診断ミスを防ぐことができます。 クールダウンとサンプリングを不合格ではなく資格として扱う スレッドレベルのオンライン評価は意図的に非同期になっています。 Opik には、最後のアクティビティの後、スレッドがスコア付けされるまでのデフォルトの 15 分間のクールダウンが記載されています。この値は、ワークスペース設定で、または文書化されたセルフホスト環境設定を通じて変更できます。同じ 固定されたドキュメント 遅延は会話全体を落ち着かせることを目的としていると説明しています。 したがって、 now last activity at < configured cooldown は アクティブ であり、期限を過ぎていません。エージェントは、正規のユーザーの順番を待っているか、単に監視ウィンドウ内で作業している可能性があります。記録されたポリシーが 15 分の場合に 5 分にページングするとインシデントが発生します。 サンプリングにより、障害のない 2 番目のパスが作成されます。 Opik オンライン ルールには、モデル、プロンプト、変数マッピング、スコア定義とともに明示的なサンプリング レートが含まれています。レシートにスレッドが選択されていないことが示されている場合、正しい状態は coverage excluded です。 scoring overdue ではありません。 選択したスレッドについては、クールダウン後に別のスコアリング猶予期間を追加します。この猶予期間は運用 SLO であり、Opik 保証ではありません。 その間は、 scoring pending の判決を維持してください。 overdue at の後、ルール ログ、評価者の資格情報、モデルの可用性、レート制限、キューの健全性を検査します。これにより、正当なアクティビティと失敗した評価者を混同することなく、明確なアラート境界が作成されます。 領収書には、決定を下したポリシーを保存する必要があります。実際に構成されたクールダウン、ルールのバージョン、サンプリング決定、評価者名、および猶予期間を分類とともに保存します。クールダウンが 15 分から 30 分に変更されたとしても、歴史上の出来事は新たな意味を黙って獲得するのではなく、説明可能なままであるはずです。 表示されるスコアがまだ古い場合がある 新しいアクティビティにより証拠のバージョンが変更されます。 Opikさん 会話スレッドのドキュメント トレースを追加すると、既存のフィードバック スコアが保持され、クールダウンが再開され、新しいクールダウン後にオンライン評価が再実行されると述べています。保存は継続性に役立ちますが、一時的に陳腐化するリスクが生じます。 このルールを使用します。 表示されているスコアが最新のターンよりも前の場合、その値に関係なく score stale として分類されます。再実行を待つか、最新のスレッド リビジョンを明示的に評価してください。古いスコアを平均して緑色にしたり、消去したりしないでください。以前のスレッド状態に関する証拠としてそれを保持します。 新鮮さは必要ですが、十分ではありません。 Opik はオンライン評価出力をフィードバック スコアとして保存し、そのスレッド ルールは会話全体を判断できます。の 固定ルールのドキュメント また、会話の一貫性、ユーザーの不満、選択したモデルがツール呼び出しをサポートする場合の実行パスへのアクセスなどのカスタム メトリクスについても説明します。 以上が評価結果です。彼らは、メトリクスにエンコードされた質問に答えます。これらは、外部の副作用や成果物の存在を自動的に証明するものではありません。 サポート エージェントがチケットを更新したと述べた後、高い関連性と一貫性のスコアを受け取ったとします。スレッドの証拠は、「会話に一貫性があった」こと、そしておそらく「予期されたツール呼び出しが表示された」ことを裏付けることができます。チケット システムだけが、意図したチケットに意図した制限付き変更が含まれていることを証明できます。最終ゲートは、機密でない相関キーを使用してその宛先をクエリし、その結果を決定的な受け入れルールと比較する必要があります。 これにより、次の 3 つの異なる決定が生成されます。 しきい値を下回る新しいスコア: quality alert ; 宛先の領収書がない新しい許容スコア: outcome unverified ; 新しい許容スコアと一致する宛先レシート: verified 。 順序付けは意図的です。目的地のレシートは、質の悪い会話を健全なものにするわけではありません。また、会話のスコアが良いからといって、目的地の結果が生まれるわけでもありません。 10 州の監査を再生する 付属の opik thread score audit.mjs フィクスチャには会話コンテンツが含まれていません。各ケースでは、可視性、予想される ID と観察された ID、最後のアクティビティ、サンプリング選択、スコアとスコア時間、およびブール宛先レシートのみが提供されます。このポリシー例では、文書化されている 900 秒のデフォルトのクールダウン、ローカルで選択された 300 秒のスコア猶予、および 0.7 のデモンストレーションしきい値を使用します。 状態の優先順位は、モバイル セーフな意思決定リストとして適用するのが最も簡単です。 1. telemetry missing : 意図したトレースが表示されません。フラッシュ、コレクター、プロジェクト、クエリの新鮮さをチェックします。 2. thread fragmented : 観測された ID は、予期される ID と等しくありません。判断する前に伝播を修復してください。 3. active : 最新のアクティビティはクールダウン中です。放っておいてください。 4. coverage excluded : 対象となるスレッドはサンプリングされませんでした。記録範囲。ページしないでください。 5. scoring pending : 選択されたスレッドは適格ですが、猶予期間内です。不明のまま待ってください。 6. scoring overdue : 選択したスレッドはスコアなしで猶予を超えています。エバリュエーターのパスを検査します。 7. score stale : スコア時間は最新のアクティビティより前のものです。最新のリビジョンを評価します。 8. quality alert : 新しいスコアは選択したしきい値を下回ります。限定された権限で証拠をレビューします。 9. outcome unverified : スコアは新鮮で許容範囲内ですが、宛先の領収書がありません。実際の結果を確認します。 10. verified : アイデンティティ、タイミング、スコア、結果はすべて合格です。領収書は保管しておいてください。 ディレクトリからアーティファクトを実行します。 修正されたリプレイは 10 個の異なる予想される状態を返し、ケースが予期せず変化した場合はゼロ以外で終了します。次の 2 つのケースを比較する価値があります。 最初のスコアは 0.94 ですが、スコアは最新のトレースよりも前のものです。 2 番目には新しい 0.91 がありますが、宛先の領収書がありません。 3 番目のみ、スレッドが安定しており、現在の評価が完了し、許容可能なスコアがあり、出力が検証されています。 合成レシートを環境からのコンテンツを最小限に抑えたエクスポートに置き換えて、フィクスチャを適応させます。等価性だけが必要な場合は、識別子をハッシュします。プロンプト テキスト、応答、ツール ペイロード、シークレット、および絶対ローカル パスをヘルス ストリームから除外します。独自の評価者のレイテンシーとキャリブレーション データからスコアの猶予と品質のしきい値を設定します。どちらの値も、汎用の Opik デフォルトとしては提供されません。 1 つの冷静な運用ルールを使用する Opik LLM の可観測性の場合、実際的なルールは次のとおりです。 意図したトレースが 1 つの現在のスレッドを形成し、スコアリング ポリシーによってスレッドが適格であると示されるまで、スレッド スコアを解釈しないでください。スコアが最後のアクティビティより新しくなり、要求された結果が個別に検証されるまで、実行をクリアしないでください。 このルールにより、正当な待機が維持され、サンプリングが可視化され、スコア不足のアラームと古いスコアのグリーン状態の両方が防止されます。また、境界を正直に保ちます。Opik は貴重なトレースと評価の証拠を提供します。目的地が結果の受領書を提供します。 監査には限界があります。評価者の調整、プロンプトの品質、セマンティックの正確性、プロバイダーの完全性、またはライブ Opik デプロイメントの可用性はテストされません。コンテンツフリーのステート マシンは、 0.7 がタスクの適切なしきい値であるかどうかを判断できません。決定論的および人間によるラベルに対して裁判官を調整し、不確実性を記録し、結果的な決定に対する人間による審査パスを維持します。 Sidewisp は現在プライベートプレビュー段階です。 その計画された正常性レイヤーは、証拠、最新性、待機状態、および検証済みの結果を 1 つのオペレーター ビューにまとめることを目的としていますが、この記事は、Opik アダプターまたは運用監視エンジンが本日出荷されることを意味するものではありません。 一次情報源 Opik 会話とスレッド ID ドキュメント、レビュー済みのコミットに固定 Opik オンライン評価ルール、レビュー済みのコミットに固定 Opik SDK 構成とフラッシュ コントロール、レビュー済みのコミットに固定