review_replay: optional judged recall over the credited hits

オープン
  • 何か問題がありますか？
#291 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@antonwolfy がすでに取り組んでいます。

2026年11月1日 から。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
34/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
ai-infra-agents, testing-qa

調査の方向性

Start by reading contract §4.5 and §9, then trace how repo compare reads metrics and how dokimi.llm makes judge calls. The proposal also depends on grade.json details.matches from a separate change, so check that data is available before implementing. Done means the command writes hits_judged.json per cell with a fake LLM in tests, repo compare reads recall_judged, and both contract sections explain its limits.

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

説明

enhancement

Problem

dokimi:review_replay credits a human review thread to the nearest finding on the same file within window lines, one to one. It checks location only, on purpose: the grader is deterministic and runs on the image's standard-library python3 (contract §4.5). So a finding that merely sits near a thread gets credit.

The dokimi report on a replay of IntelPython/dpnp#3099 (26 tasks, 156 runs, 210 credited thread hits) quoted credited threads as evidence of what the guidance catches. An audit read the pairs behind them:

  • pr3098-t2: the thread asks to add a TODO. The credited findings complain that the TODO is repeated five times and has no issue URL. pr3055-t9 and pr3128-t1 look similar.
  • pr3066-t1: one of its two credited findings is about something else (deprecating before removing).

Chance credit also grows with the number of findings. The guidance arm reported more findings (5.26 vs 4.37 per review), so location-only recall can favour it. A list of "threads the guidance made the agent catch" needs each pair read.

Proposal

An optional step after grading, outside the grader, for example dokimi repo hits judge <batch> --judge-model <id> --judge-provider <p>:

  • Input: for every credited pair it reads the thread's comment and the finding's text. They come from grade.json details.matches, which a separate change adds.
  • Judgment: a judge model labels each pair same point, related or unrelated. The call goes through dokimi.llm, as the architecture requires.
  • Output: a hits_judged.json per cell, with each label and recall_judged: the threads whose pair is same point, over all gold threads. repo compare reads it as a measure, for example --metric judge:recall_judged, next to recall.
  • What it can and can't fix: only credited pairs are rescored. So recall_judged ≤ recall, and a finding outside the window that does raise the thread's point stays uncredited.
  • Cost on that batch: 210 pairs, roughly $0.5 with a small judge or $3 with a mid-size one.

Open questions

  • Judge model: a different family from the model under test, as novelty requires? (arms run does not check.)
  • Calibration: a person labels a sample of pairs, and the step reports agreement before any judged figure is quoted. How large a sample?
  • Uncredited findings: should near-misses (a finding on the same file outside the window) be judged too, so judged recall can also rise?
  • Ties: three labels or two?

Done when

The command runs over a batch with a fake LLM in the tests and writes hits_judged.json per cell. repo compare reads recall_judged. The docs (contract §4.5 and §9) say what judged recall is and what it is not.

主要言語
Python
スター
9
フォーク
9
平均マージ
1日 8時間
マージ済み PR（30日）
269

環境構築

はじめの一歩

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

intel/dokimi のほかの issue

intel/dokimi の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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