Files
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

1.4 KiB

QUANT: what each vector encoding buys (commit cd9851a12)

  • corpus: 165973 vectors, 384 dimensions, 200 probes, top 10
  • machine: Linux 6.18.40.1-microsoft-standard-WSL2, 32 cores, 4 threads per query, load [2.46, 4.17, 4.58]
  • probes are drawn from the corpus itself, so these arms are compared with each other, not quoted as retrieval quality; a hit is any returned atom whose true cosine is at least the 10-th best, because byte-identical atoms make the id set ambiguous
arm p50 ms p95 ms recall@10
sqlite-vec float 41.2 55.4 1.0
sqlite-vec float + holder filter 29.8 30.7 0.599
sqlite-vec int8 35.5 42.2 0.977
sqlite-vec int8 + holder filter 22.3 28.1 0.595
sqlite-vec bit 2.6 2.8 0.728
sqlite-vec bit + holder filter 4.1 4.3 0.513
numpy float32 scan (the truth) 8.0 9.6 1.0
numpy hamming (sign bit) 18.9 19.8 0.011
numpy float32 first 192 dims 7.5 8.2 0.722
numpy float32 first 128 dims 7.9 8.9 0.57
numpy float32 first 64 dims 4.0 8.3 0.43
bit coarse@200 -> float32 rerank in numpy 23.7 24.7 0.983
encoding bytes per vector
float32 1536
int8 384
bit 48

Latency is wall time per query on the machine named above with the thread budget the benchmark pins; a run on a loaded machine is not comparable.