New §14.6 captures the 2026-05-11 findings:
- Measured embed rate: ~4.3 chunks/s on the contended dev box (load
~11 on 8 cores; the embed process got ~28% of one core). One wiki
shard (~1.56M chunks) at that rate ≈ 100h ≈ 4+ days; all four ≈
~16 days. The full int8 backfill was abandoned as not feasible to
brute-force there.
- The 54K-chunk partial on 000.db confirmed ~409 B/chunk apparent
→ 384 B amortized → ~2.4 GB for the full 6.24M-chunk corpus at
int8 — the deterministic number a full backfill would only
re-confirm, so finishing it bought nothing.
- On an idle healthy box (batching + all cores) bge-small does
~50-200 chunks/s → full corpus ≈ ~9-35h (the ticket's earlier
"~17h" is the optimistic end).
- Per-chunk cost breakdown: bge-small ONNX inference ~5-30 ms/chunk
dominates; the existing arborist ingest steps (chunker + SHA-256
leaf + Merkle commit + sqlite INSERTs + zstd + FTS5) are well
under 1 ms total. So adding vec multiplies ingest by ~10-100×,
entirely in the ONNX matmuls — the non-vec ingest path is
unchanged and still runs at hundreds of chunks/s.
- Implication for §14.2: this is *why* lazy-out-of-band is the
default and `arborist ingest --embed` is the opt-in. Production
guidance: a corpus-wide backfill is a one-time batch job (hours
on idle / days on contended), best run off-peak or on a dedicated
box; it does not slow ongoing ingest (which never embeds unless
--embed is passed); a GPU/accelerated embedder is a drop-in via
the pluggable Embedder callable if backfill latency matters.
Status line updated to point at §14.6. Doc-only.
russell@unturf.com
2ad2dceada