応答ごとではなく、成功したタスクごとの AI エージェントのコストを測定します

動作とリソースの使用には複数のメトリックが必要です

2026 年 6 月のプレプリントでは、よく知られた結果の尺度とともに、エージェントの行動をエントロピーに基づいて説明することを提案しています。信頼性の研究では、一貫性と堅牢性を個別に調査します。これらの情報源は、実際のコスト モデルを展開されたシステムに依存させながら、繰り返される動作や非生産的な動作に注目することを提案しています。

証拠: AI エージェントの動作に対するエントロピーベースの可観測性 [1]AI エージェントの信頼性の科学に向けて [2]

会計境界を定義する

単位が 1 回の試行、1 回のユーザー要求、または完了したビジネス タスクであるかどうかを決定します。生成、取得、ツール、オーケストレーション、再試行、およびワークフローに必要な人間によるレビューが含まれます。請求対象となるプロバイダー料金を社内の作業見積もりとは別にして、前提条件を検査可能な状態に保ちます。

違いを開示せずに、無制限の再試行を持つ候補を、1 回の試行が許可されるベースラインと比較しないでください。追加の試行は正当な製品選択かもしれませんが、比較は 2 つのモデルだけでなく 2 つの運用ポリシーにも関係します。コストと完了の両方に影響を与える可能性があるため、タイムアウトと同時実行の制限を記録します。

レポートの分布と障害パス

Rubrex は、指定されたポリシーに基づいて、タスクの成功、中央値と末尾のレイテンシ、合計リソース使用量、および完了したタスクごとのコストを表示することを推奨します。失敗した試行と放棄された試行をコスト分母に保持します。タスクが成功しなかった場合は、未定義の比率をゼロとして提示する代わりに、その事実を報告します。

複雑さとツールの依存関係によってタスクをセグメント化します。ルーティングを変更すると、簡単なタスクがより安価なパスに移動される一方で、難しいタスクが悪化するため、平均が低下する可能性があります。両方のスライスと配線エラーを検査します。全体の数値が良好であっても、重大なサブグループ回帰が消去されることはありません。

算術の例: 安易な試みは負ける

抽象的なコスト単位を使用する 2 つの仮想システムを考えてみましょう。システム A は試行ごとに 1 ユニットを消費し、100 個の独立したタスクのうち 50 個を完了します。システム B は試行ごとに 1.5 ユニットを消費し、90 を完了します。タスクごとに 1 回の試行を行うと、成功あたりのコストは A では 2 ユニット、B では約 1.67 ユニットになります。これらの考えられた数字は計算を示すものであり、プロバイダーの価格設定や測定されたパフォーマンスではありません。

失敗に手動修復が必要な場合、再試行が許可されている場合、または成功したタスクの難易度が異なる場合、結果は変わります。システムを選択するために比率を使用する前に、これらのポリシーを文書化してください。

普遍的な勝者ではなく、操作点を選択してください

最初に最低限の品質と許可の要件を設定します。それらを満たす候補の中から、予想されるワークロードの下でコストとレイテンシーを比較します。トレードオフが重要な場合は、いくつかの操作点を保存します。迅速な分類に適したモデルは、長いツールのワークフローには適さない場合があります。

• リソースの合計使用量には、失敗した実行が含まれます。
• 再試行およびタイムアウトのポリシーを記録します。
• タスク クラスとルーティングの間違いを分離します。
• 単位をお金に換算するときは、現在のプロバイダーの価格を再確認してください。

よくある質問