Query-side clients for Qwen3-Embedding-0.6B: keep your index, shrink the query encoder β€” summary and links

#3
by honza-rosecky - opened
thinletter org

Four GGUF query encoders (340 / 385 MiB instead of 1 142 MiB fp16) that stay compatible with document vectors produced by the unchanged Qwen3-Embedding-0.6B: the index is not touched, only the query side moves to the client. On the model's own fp32 indices the Q4_K_M file keeps 100.0 / 99.4 / 100.1 / 99.3 % of nDCG@10 on SciFact / NFCorpus / ArguAna / SciDocs (cosine to the fp32 query vector 0.97–0.98); the file calibrated on Czech text keeps 98.7 % on a 55 071-segment Czech supreme-court index. Q5_K_M (385 MiB) sits 0.01 closer in cosine and is otherwise within noise.

Along the way: every ≀ 3-bit file of this model failed our release rule (nDCG holds on English while the query vectors drift to cosine 0.90–0.94; on Czech nDCG falls to 80–93 %), and a 2-bit token table alone costs 4.6–6.6 points on Czech. The same architecture as a retrieval fine-tune (harrier-0.6b) holds 99 % at 3.4 bits, so the tolerance is a property of the checkpoint, not of the recipe. The official sentence-transformers prompt has no trailing space after Query:; the files were evaluated with that prompt.

Pre-registered runs, paired bootstrap over queries, per-checkpoint compatibility stated on the card:

Limits: one Czech corpus with synthetic queries and no human judgements; differences under 0.01 nDCG@10 are ties (calibration-draw variance). Questions and attacks welcome here.

Sign up or log in to comment