Files
ely-eye/bench
ZacharyZhang-NY c4a8c36416 Put the scale evidence in the repo and say plainly what still misses
Every number in CHECKLIST p2-1 and p0-3.7 came out of a scratch script: the
kind of artifact a reader cannot re-run, and the kind that quietly drifts
away from the code it describes. These reports are generated by committed
harnesses and each one stamps the commit that carries the code it measures.

DENSE.md  165,973 atoms / 153,857 vectors: build 1421.0s, search p50 75.6ms
          p95 93.0ms, 0.998 agreement with a brute-force scan, one write into
          a full index p50 518ms, 1,729 bytes per stored vector.
QUANT.md  twelve encodings measured on the same vectors: int8 keeps 0.977 of
          the ranking for a quarter of the bytes and no speed, bit is 14x
          faster and keeps 0.728, so bit is a coarse filter and nothing more.
TERMS.md  the stop-word bound swept, not guessed: 0.05 is the measured peak
          (recall@10 0.803 at p50 69.5ms) and also the fastest of the rows
          that keep recall.
SCALE.md  the product's own search at 165,973 atoms: p50 71.7ms against the
          frozen baseline's 20.16s.
LEGS.md   what each retrieval leg is worth, per modality, with the page size
          the product actually asks for in the table.

The acceptance bar the operator set is recall@10 >= 0.90 at n>=300. It is
not met. The best measured row is 0.858 (dense leg on, page widened to 30,
p50 414ms); the shipped configuration gives 0.848 at p50 72.5ms; the
in-repo counterpart at holder scope gives 0.866. The shortfall is
concentrated in picture golds (video 0.583-0.708, ui_screenshot 0.500-0.583,
image 0.750) while the word-shaped ones already pass (code 0.953, pdf 0.919).
Latency passes by three hundred fold; recall does not, and the gap is four
points of cross-modal retrieval, not index scale.
2026-10-08 17:01:20 -04:00
..

bench — the measurement harness

Everything here measures the product as it is. No arm may read a benchmark gold label.

run order

python -m bench.fetch_corpus      # 19 GB of third-party material -> bench/corpus + ~/ely_eye_bench_data
python -m bench.build_sets        # freeze the 6 query sets -> bench/sets/
python -m bench.validate_sets     # schema + gold + scope + modality checks (b-2 gate)
python -m bench.fetch_models      # dense + rerank models used by the ablation arms
python -m bench.ingest_baseline   # the unmodified product ingesting the whole corpus (16 -> 8 workers)
python -m bench.run               # five-arm ablation + latency/scale -> bench/reports/BASELINE.md
python -m pytest bench/tests -q   # metric definitions, hand-computed

bench/runs/ and bench/corpus/ are gitignored; bench/corpus/manifest.jsonl is tracked so the corpus is reproducible from the manifest alone.

the arms (b-3)

arm what it is
bm25_only the product's sparse signal alone
dense_only the product's dense signal alone (product flag is off today)
graph_only the product's graph signal alone — atom.relations is never populated, so it is a constant
no_rerank the product's exact 0.55 / 0.35 / 0.10 fusion
fusion_rerank the same fusion plus a cross-encoder rerank, the upper bound of the current design

python -m bench.run also drives the unmodified RetrievalService.search over the merged database and reports its latency plus how far its top-10 differs from the fast BM25 path.

known environment artifact

pi-lens' pyright reports Import "bench.sets_common" could not be resolved (and the same for bench.metrics, bench.systems, ely_eye.*, cv2, onnxruntime, pypdf.errors) even though every one of those imports works. It is not a repo defect:

  • effective_config on any bench file returns 0 config file(s) with resolvedCwd at the repo root, so neither pyproject.toml [tool.pyright] nor pyrightconfig.json (both of which carry extraPaths: [".", "backend/src"]) is being read by that runner.
  • Runtime proof, run from the repo root with .venv active:
.venv/bin/python -c "import bench.sets_common, bench.metrics, bench.systems, bench.run, bench.ingest_baseline, \
bench.build_mmlongbench, ely_eye.config, ely_eye.db, cv2, onnxruntime, pypdf.errors; print('runtime proof OK')"

Treat that command as the check of record for import health; treat pyright's type findings (it has caught real defects here: an AtomRunner typo, missing strict=True on zip, dict[str, object] over-narrowing) as separate and worth fixing.

The pi-lens mypy cascade also replays stale findings after a fix: it attributes another file's lines to whichever file was edited last (e.g. bench/fetch_models.py:107: "object" has no attribute "encode", where line 107 of that file is a Path call and the quoted text is from bench/systems.py). The check of record is a fresh-cache run, which has passed on every current file:

rm -rf /tmp/mypycache && .venv/bin/python -m mypy --cache-dir /tmp/mypycache bench/   # Success: no issues found
.venv/bin/python -m ruff check bench/                                                  # All checks passed
.venv/bin/python -m pytest bench/tests -q                                              # all green

corpus facts that constrain the numbers

  • 50,789 sources / 5,308 queries (2,928 answerable, 2,380 unanswerable), all third-party.
  • Video-MME ships mp4s for 129 of 900 videos; the set uses those 129 (387 questions).
  • Video-MME has no temporal gold, so its gold region is the whole video — recorded in the set manifest.
  • ScreenSpot-v2 boxes are [x, y, w, h], verified against 755 image headers (xywh in bounds 1271/1272).
  • CodeSearchNet docstrings appear verbatim inside the code, so the query text is stripped before ingest or BM25 gets a free exact match.
  • The product keys a source by {stem[:48]}_{sha256[:16]}, so identical bytes in two sets collapse to one product source; ingest_report.json reports shared_source_ids.