修正につながる AI 障害分類を構築する

最近のベンチマークは段階レベルの診断を重視しています

2026 ChemCost プレプリントでは、科学ツールのタスク内の接地、回収、調達の選択、および計算におけるエラーが分離されています。別のエンタープライズ RAG プレプリントでは、多次元の診断フレームワークが提案されています。どちらも、エンドツーエンドのスコアだけでは障害を特定するには不十分である理由を示しています。彼らの領域と前​​提条件は、一般的なビジネスアシスタントとは異なります。

証拠: エージェントは反応に価格を設定できますか?化学物質のコスト推論に関する LLM の評価 [1]RAG の「非実用性」の克服: 現実世界のベンチマークと多次元診断フレームワークの提案 [2]

3 レベルの説明を保持します

Rubrex は、症状、調査範囲、および因果関係仮説の信頼レベルを記録することをお勧めします。例: 回答では古いポリシーが引用されています。取得の鮮度を調査する。原因はまだ確認されていません。これにより、最終応答が間違っているという理由だけでレビュー担当者がプロンプト バグを割り当てることがなくなります。

さまざまな査読者が一貫して適用できる、小さなトップレベルの語彙を使用します。大幅に異なる救済策が必要な障害が含まれる場合は、カテゴリを展開します。数十の微妙なラベルを含む分類法では、正確に見える一方で、意見の相違が生じ、レビューに時間がかかることがあります。

修正を提案する前に分類する

入力、取得したコンテキスト、ツールの結果、出力を一緒に確認します。必要な証拠が入手可能かどうか、それがモデルに到達したかどうか、モデルがそれを使用したかどうか、下流システムが結果を受け入れたかどうかを尋ねます。 1 つのトレースで複数の障害が発生する可能性があります。要因を保持しながら、主要な意思決定に関連する失敗を特定します。

インシデントの ID をラベルとは別に追跡します。 1 つの失敗した応答が検索タグと引用タグの両方を受け取った場合でも、分母では 1 つの失敗した応答のままです。カテゴリ数は重複する場合がありますが、その重複は明示的に示す必要があります。

説明例: 重複した更新

タイムアウト後にエージェントが顧客レコードを 2 回更新します。症状は重複した状態変更です。原因として考えられるのは、冪等性の欠如、ツールの応答があいまいであること、失敗しても副作用がないと想定する再試行ポリシーなどです。この出来事を幻覚と分類してしまうと、この 3 つすべてが曖昧になってしまいます。

制御されたタイムアウト応答でツール境界をテストし、結果の状態を検査します。次に、同じ条件下で再試行ポリシーの変更を比較します。この実験は、新しいシステム プロンプトがより慎重に聞こえるかどうかを尋ねるよりも有益です。

分類法がガイド作業を停止した場合は分類法を見直す

未分類の事件や頻繁に起こる意見の相違を定期的にレビューします。同じ調査につながるラベルを結合し、異なる介入を隠すラベルを分割します。分類の変更がシステム動作の変更として現れないように、評価実行で分類バージョンを保持します。

よくある質問