ecommerce-product-search-embeddings-static

A ~31MB static embedding model for e-commerce product search that runs on any CPU — no GPU, no PyTorch forward pass, ~34× faster than a transformer. This is the model2vec static distillation of ecommerce-product-search-embeddings, which was fine-tuned on 427,655 real Amazon ESCI shopping-query relevance judgments.

If you want free, self-hostable semantic product search on a $5 VPS, a Raspberry Pi, a serverless function, or inside an Electron/desktop app — this is the artifact. If you can afford 33M transformer parameters, use the parent model for higher quality.

How do I run semantic product search without a GPU?

pip install sentence-transformers   # that's all — loads natively, no model2vec needed

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("albertobarnabo/ecommerce-product-search-embeddings-static")
# 256-dim embeddings, encoding is a lookup + mean — microseconds per query on CPU

q = model.encode(["pan that doesnt stick eggs"], normalize_embeddings=True)
docs = model.encode(["T-fal Nonstick Fry Pan 12 Inch", "JBL Flip 5 Speaker"], normalize_embeddings=True)
print(q @ docs.T)

Or with the model2vec library directly (from model2vec import StaticModel; StaticModel.from_pretrained(...)).

How much quality do I trade for the size?

Honest numbers, same protocol as the parent (ESCI US test split, 8,956 real queries; full details on the parent card):

model	size	nDCG@10 ↑	Recall@100 ↑	MRR@10 ↑	CPU speed
fine-tuned parent (33M transformer)	~130MB	0.7483	0.5212	0.4220	2,135 q/s
this model (static, 256-dim)	~31MB	0.6799	0.3160	0.2703	73,163 q/s
all-MiniLM-L6-v2 (generic transformer)	~90MB	0.7070	0.4269	0.3385	4,085 q/s

Read the table straight: the static model gives up 2.7 nDCG@10 points vs a generic transformer (all-MiniLM-L6-v2), and 6.8 points vs its own parent, in exchange for the size and speed win — pick it for the constraint, not for the quality, while encoding queries orders of magnitude faster than any transformer. Typo-noise robustness delta on held-out dev queries: -2.3 nDCG@10 points (parent: -3.5).

When should I pick static vs the full model?

• Pick this static model when queries must embed in microseconds on cheap CPUs (autocomplete-as-you-type, edge devices, serverless cold starts, batch-embedding millions of titles on a laptop).
• Pick the parent transformer when you can spend ~10ms/query for the best relevance.
• Both are drop-in sentence-transformers models: numpy, FAISS, Qdrant, pgvector, Chroma all work unchanged.

How was it made?

model2vec 0.8.2 distillation (pca_dims=256, float32) of the fine-tuned parent — the transformer's contextual knowledge of shopping queries is baked into static token embeddings. Training data (real ESCI + labeled synthetic noisy queries) is published at esci-product-search-pairs. Evaluation protocol, leak guards, and limitations: see the parent card — everything there applies, plus: static embeddings have no word-order awareness (bag-of-tokens), so they are weaker on queries whose meaning depends on token order or negation.

Citation

@article{reddy2022shopping,
  title={Shopping Queries Dataset: A Large-Scale {ESCI} Benchmark for Improving Product Search},
  author={Reddy, Chandan K. and M{\`a}rquez, Llu{\'i}s and Valero, Fran and Rao, Nikhil and Zaragoza, Hugo and Bandyopadhyay, Sambaran and Biswas, Arnab and Xing, Anlu and Subbian, Karthik},
  journal={arXiv preprint arXiv:2206.06588},
  year={2022}
}

Family: fine-tuned model · dataset · live demo.