Problem
retriever harness run <benchmark> correctly starts from code-owned benchmark defaults, and --set is useful for expert tuning such as changing query.top_k. However, a developer running one registered benchmark on a workstation without the canonical dataset mount must currently know internal configuration paths:
uv run --frozen --project nemo_retriever retriever harness run jp20_beir \
--set dataset.path=/raid/data/jp20 \
--set evaluation.dataset_name=/raid/data/jp20_query_gt.csv
Machine-local corpus and evaluation inputs are normal operator inputs, not experimental benchmark tuning. Operators also should not need to know whether a local queries/qrels source is represented by dataset.query_file or evaluation.dataset_name.
This surfaced during second-host validation of the portable nightly workflow: the nightly dataset map handles host paths, but the direct single-benchmark CLI still exposes internal override keys.
Proposed interface
retriever harness run jp20_beir \
--dataset-path /raid/data/jp20 \
--ground-truth /raid/data/jp20_query_gt.csv
For an evaluation-free smoke run:
retriever harness run jp20_smoke \
--dataset-path /raid/data/jp20
Design notes
- Keep both options optional so existing registry defaults remain unchanged.
- Keep
--set as the advanced escape hatch for benchmark tuning.
- Model these as typed run inputs at the benchmark-resolution seam rather than constructing internal
--set strings in the Typer command.
--ground-truth should supply the local queries/qrels input and hide the current dataset/evaluation representation details.
- Define unambiguous precedence. Preferably fail early when a first-class flag conflicts with the corresponding
--set key.
- Validate local paths before model, Ray, or GPU initialization.
- Record the final resolved paths in
resolved_benchmark.json.
- Remote evaluation datasets such as ViDoRe should remain unchanged.
Acceptance criteria
Scope
This makes registered benchmarks portable across machines with different local paths. It does not attempt to infer arbitrary corpus formats: the selected benchmark still defines input type, loader, ingest/query configuration, and evaluation semantics.
Problem
retriever harness run <benchmark>correctly starts from code-owned benchmark defaults, and--setis useful for expert tuning such as changingquery.top_k. However, a developer running one registered benchmark on a workstation without the canonical dataset mount must currently know internal configuration paths:Machine-local corpus and evaluation inputs are normal operator inputs, not experimental benchmark tuning. Operators also should not need to know whether a local queries/qrels source is represented by
dataset.query_fileorevaluation.dataset_name.This surfaced during second-host validation of the portable nightly workflow: the nightly dataset map handles host paths, but the direct single-benchmark CLI still exposes internal override keys.
Proposed interface
For an evaluation-free smoke run:
Design notes
--setas the advanced escape hatch for benchmark tuning.--setstrings in the Typer command.--ground-truthshould supply the local queries/qrels input and hide the current dataset/evaluation representation details.--setkey.resolved_benchmark.json.Acceptance criteria
retriever harness run jp20_beircontinues to use the registered defaults.--dataset-path PATHoverrides the registered corpus location.--ground-truth PATHprovides the local queries/qrels source without requiring internal override keys.jp20_smoke --dataset-path PATHworks without a ground-truth argument.resolved_benchmark.jsoncontains the resolved corpus and ground-truth paths.--set, runfile, runset, nightly, and remote ViDoRe behavior remains compatible.Scope
This makes registered benchmarks portable across machines with different local paths. It does not attempt to infer arbitrary corpus formats: the selected benchmark still defines input type, loader, ingest/query configuration, and evaluation semantics.