Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Rubric judge未获得被评 agent 的执行轨迹——与论文不一致,且「是否使用了某文件」类 rubric 恒被判通过

オープン
#12 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
65/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
ai, testing-qa

調査の方向性

evaluation/src/agent_as_a_judge.py、特に _build_judge_prompt と _prepare_judge_view から開始し、judge payload と dep_graph_recognition._trace_summary における実行トレースの処理を比較してください。実行データがどのように利用可能になるかを追跡し、ルーブリック評価が出力ファイル、入力ファイル、ルーブリック、実行トレースを受け取ることを確認してください。これにより、入力が見えているというだけでプロセスベースのルーブリックに合格することがないようにします。

索引モデルが issue の本文から書いたものです。

説明

您好,感谢发布 Workspace-Bench。

我们最近在使用 Workspace-Bench 评测多个 Agent 系统。整体上非常认可这个 benchmark 的方向,尤其是大规模 noisy workspace、cross-file dependency reasoning 和 workspace-level grounding。这些设计比传统“小文件包 QA benchmark”更接近真实 Agent 场景。

但是我发现论文明确 Agent-as-a-Judge 评 rubric 时会把被评 agent 的执行轨迹一并给裁判;当前代码(evaluation/src/agent_as_a_judge.py)没给,裁判只能看原始输入 + 候选输出。后果:(1) rubric 通过率无法与论文对标;(2)「agent 是否使用/整合/追溯了某输入文件」这类过程型 rubric 被恒判通过(因为input本质上是模型应该用到哪些文件的gt),抬高分数。

论文规定 — 裁判应拿到 4 样:输出文件 + 输入文件 + rubrics + 执行轨迹。

代码现状 — _build_judge_prompt 的 payload = task/steps/rubrics/data/judgeView{cwd, inputsPath, originalTaskMetadataPath, candidateOutputPath};_prepare_judge_view 只暴露 inputs/ + candidate_output/。无 executionTrace。 max_trace_items 对 rubric 评分是无效参数(轨迹只在 dep_graph_recognition._trace_summary 依赖图那步用)。

影响 — (1) 与论文口径不一致;(2) 只有 inputs/ 可见、目标文件本就在其中 → 「是否用了 X」几乎恒判通过。

主要言語
Python
スター
72
フォーク
7
平均マージ
7分
マージ済み PR(30日)
6

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OpenDataBox/Workspace-Bench のほかの issue

OpenDataBox/Workspace-Bench の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。