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.