In context
Lexical search matches words and structured identifiers; vector search can also match semantic intent, such as "something cosy for a rainy day". They are complementary: exact model numbers and product codes can be better served by lexical or structured matching. Embedding-based search compares query and product vectors to find candidate matches.
The "closeness" metric is usually cosine similarity. Common sizes are 384, 768, or 1536-dimension vectors generated by an embedding model. More dimensions do not automatically mean better results: model quality, source data, filters and evaluation matter, as do storage and query costs.
Embeddings power more than search - they're also how AI does product clustering, "similar items" recommendations, duplicate detection, and categorization. Similarity alone does not prove compatibility or complementarity: a similar laptop is an alternative, while a compatible charger needs explicit connector, wattage and model evidence. Stock and prices need separate freshness checks.
How Zubby uses this
Zubby uses store-scoped pgvector retrieval with 1536-dimension embeddings in the current implementation. Catalog and knowledge changes queue indexing work; updates become searchable after successful processing, not simply when a webhook arrives. Custom stores must push changed source data. Check sync and indexing status before testing a recently edited product.
We pair vector similarity with structured filters (price, stock, collection) and a re-ranking pass so results respect both semantic intent and your business rules.