現在のエージェントは、単に質問に答えるだけではありません。APIを呼び出し、データベースを照会し、ワークスペースを変更し、サービスを起動します。だからこそ、評価は、最後の一文が模範解答のように見えるかどうかだけを見るべきではなく、本当に実行したか、安全に実行したか、環境の状態が正しいかどうかを見なければなりません。
Claw-Eval-Liveは、Claw-Evalシリーズのライブ拡張版です。前者はまず、エージェントがタスクを本当に完了したかを明確に評価し、後者はさらに踏み込んで、ベンチマークが測定するタスクが現在の実際のワークフローを代表しているかを問い直します。
Claw-Evalの核心は、実行プロセスを監査可能な証拠に変換することです。各評価は隔離された環境で実行され、スコアリングに実際に使用されるのは最終出力ではなく、実行トレース、サーバーサイドの監査ログ、実行後の環境スナップショットです。論文の対照実験によると、LLMジャッジに会話記録と採点スクリプトのみを表示し、監査ログや環境スナップショットを提供しなかった場合、44%の安全違反と13%の堅牢性に関する問題を見落とすことが示されました。つまり、結果だけを見ると、エージェントを過大評価してしまうのです。
しかし、正確に評価するだけでは十分ではありません。エージェントが直面するのはワークフローであり、ワークフローは変化します。今日最も一般的なのは部門間の照合かもしれませんが、明日は人事の入社手続き、チケット発行、カレンダー調整、サプライヤーへの支払い検証かもしれません。静的なベンチマークは再現性が高いかもしれませんが、タスクの混合比率が実際の要求から既に逸脱している可能性があります。
Claw-Eval-Liveが解決しようとしているのは、まさにこの乖離です。毎日ランダムに問題を変更するのではなく、各リリースをタイムスタンプ付きの現実のスナップショットにします。シグナル層では公開されているワークフローの需要シグナルを観察し、リリース層ではタスク定義、実行環境、データフィクスチャ、採点スクリプトを凍結し、結果が依然として再現可能で比較可能であることを保証します。
ここで言うClawHubシグナルは、正確な需要のグランドトゥルースでも、自動問題生成器でもありません。公開され検証可能な、需要の事前分布です。システムは、シグナル収集、パターンクラスタリング、ファミリー重み付け、候補タスクの試行とフィルタリングを経て、MILPを用いて候補から公開タスクを選定します。その際、リリース規模、ファミリー網羅性、リーダーボードの識別力に関する制約が課せられます。
現在の公開リリースには、105のタスク、17のタスクファミリー、13の最先端モデルが含まれています。各タスクは単なるプロンプトではなく、完全に実行可能なユニットです。task.yaml、ツールインターフェース、データフィクスチャ、grader.pyが不可欠です。
スコアリングにおいても、「もっともらしく見えるから加点」という状況は極力避けています。Claw-Eval-Liveは決定論的な証拠を優先的にチェックします。正しいツールが呼び出されたか、エンティティと数値が正解データと一致しているか、必要な状態変更が実際に発生したか、などです。レポートの構成や要約の品質といった意味的な側面に限り、構造化されたLLMジャッジを導入します。
実験結果は非常に厳しいものです。合格率が70%を超えたモデルは一つもなく、首位と最下位の差は22.9パーセントポイントに達しました。さらに注目すべきは、一部のモデルで合格率が近くても、全体完了率が異なることです。これは、完全にできないわけではなく、ツール呼び出しが一歩足りなかったり、証拠が不足していたり、状態が完全にクリーンアップされていなかったりすることを示しています。
最も直感に反するのは、本当に難しいのがターミナル操作ではないことです。開発/ターミナルタスクは、強力なモデルにとって既に天井に近づいています。モデルが本当につまずいているのは、人事/総務、管理/運用、そして部門横断的なワークフローです。人事の平均合格率はわずか6.8%、ワークフローに至っては12.8%です。これは、現在のエージェントの弱点が「ターミナルを使えるか」ではなく、複数のシステム間で継続的に証拠を収集し、レコードを正しく関連付け、必要な書き込み操作を完了できるかどうかにあることを示しています。
Claw-Evalは、エージェント評価が結果だけを見てはいけないことを証明しました。Claw-Eval-Liveはさらに、ベンチマークも静的な問題集に長期間留まることはできないことを示しています。この二つを組み合わせることで、問題は二つに分割されました。まず、エージェントが実際に行動したことを確認し、次に、私たちが現在最も価値のあるワークフローをテストしていることを確認するのです。
論文：https://arxiv.org/abs/2604.28139