E-commerce vector search finds products by meaning; hybrid retrieval combines that capability with keyword matching and explicit product filters. Keep exact identifiers, availability, category and price constraints separate from similarity. A semantically similar product is not useful if it is unavailable, incompatible or outside the shopper’s stated requirements.

Key takeaways

• Combine keyword and vector retrieval rather than discarding exact product search.
• Apply hard product constraints consistently across retrieval paths.
• Version embeddings with the catalog content that produced them.
• Evaluate relevance before optimizing conversion.
• Recheck transactional availability and price in the commerce system.

When meaning helps product discovery

A shopper searching for shoes for a rainy commute may not use the exact words in a product title. Embeddings can help retrieve descriptions related to the intended use. A shopper entering a precise model number has a different need: exact matching and compatibility information should remain prominent.

Microsoft’s hybrid-search overview describes parallel full-text and vector retrieval with reciprocal rank fusion. It also identifies exact codes and specialized terms as cases where keyword search can be useful. That capability is a starting point for evaluation, not a guarantee that every catalog query improves.

Separate discovery intent from constraints. “Waterproof walking shoes under 100” contains a use case, a product type and a price limit. Do not rely on an embedding to enforce the price limit or a generated description to establish that a product is waterproof.

A reference product-search architecture

Catalog source → validation → searchable product document
                           ├─ text + structured attributes
                           └─ versioned embedding input → vector
                                          ↓
Query + explicit filters → keyword candidates + vector candidates
                                          ↓
Consistent eligibility checks → rank fusion → optional reranking
                                          ↓
Product cards + accurate facets + clear applied filters
                                          ↓
Commerce source revalidates price, availability and purchase rules

Evaluation: relevance judgments + constraints + latency + outcomes

This is a proposed implementation pattern. The fixture below tests only eligibility and fusion behavior; it does not connect to a vector database or prove semantic-search quality.

Use a stable product or variant identifier throughout indexing, analytics and display. A result for a parent product should not imply that every size or region-specific variant is purchasable.

Prepare catalog content and enforce filters

Define the text used for embeddings: title, verified description, category and relevant attributes. Exclude untrusted promotional claims unless they have passed the catalog’s editorial rules. Keep machine-generated enrichment distinguishable from authoritative product facts.

Record embedding model and input-template versions. When meaningful product content changes, schedule re-embedding and track whether the searchable version is current. A partial index update must not leave a new description paired with an unexplained old vector.

Microsoft documents vector filtering modes and their recall and latency implications. Filtering is performed on suitable nonvector fields. Test the selected mode with restrictive combinations, not only broad queries.

Do not apply a hard filter to only one retrieval branch. If unavailable products can re-enter through a second branch, the final result violates the user’s constraint even if its rank is excellent.

The local example filters a small catalog and checks final candidates. In a real search service, apply supported filters during retrieval where appropriate and retain final validation; filtering a tiny top-k after retrieval can leave too few results.

Runnable eligibility and rank-fusion fixture

Save this complete Python script as ecommerce-retrieval-lab.py and run it with Python 3. It has no external dependencies or network calls. The rankings are hand-authored synthetic inputs, not outputs from an embedding model.

from collections import defaultdict

def eligible(catalog, category, budget):
    return {p['id'] for p in catalog if p['category'] == category
            and p['price'] <= budget and p['in_stock']}

def fuse(ranked_lists, allowed, constant=60):
    scores = defaultdict(float)
    for ranking in ranked_lists:
        seen = set()
        for rank, product_id in enumerate(ranking, start=1):
            if product_id in allowed and product_id not in seen:
                scores[product_id] += 1 / (constant + rank)
            seen.add(product_id)
    return sorted(scores, key=lambda key: (-scores[key], key))

catalog = [
    dict(id='A', category='shoes', price=80, in_stock=True),
    dict(id='B', category='shoes', price=90, in_stock=False),
    dict(id='C', category='shoes', price=150, in_stock=True),
    dict(id='D', category='bags', price=60, in_stock=True),
    dict(id='E', category='shoes', price=70, in_stock=True),
]
allowed = eligible(catalog, 'shoes', 100)
assert allowed == {'A', 'E'}
assert fuse([['A','B','E'], ['E','C','A','D']], allowed) == ['A','E']
assert fuse([['B','C','D']], allowed) == []
assert fuse([['E','E','A']], allowed) == ['E','A']
assert fuse([['A'], ['E']], allowed) == ['A','E']
assert fuse([[], []], allowed) == []
print('6 synthetic eligibility/rank-fusion checks passed')

The six local checks passed. They cover hard eligibility, fusion order, no eligible candidates, repeated IDs, deterministic ties and empty inputs. They do not measure recall, relevance, latency or conversion. The constant is a demonstration parameter, not a tuned catalog recommendation.

For production, keep retrieval and business ranking observable. Store query classification, applied filters, index version and candidate-stage information with appropriate privacy controls. This lets an engineer distinguish missing candidates from poor reranking.

Evaluate relevance before business impact

Build a judged query set containing exact codes, descriptive needs, misspellings, synonyms, narrow filters and no-match cases. Have knowledgeable reviewers label product relevance and constraint compliance independently of the retrieval score.

Compare keyword-only, vector-only and hybrid baselines using the same catalog version and query set. Report where each approach fails. Similarity scores from different ranking methods are not directly interchangeable probabilities.

Use controlled experiments for business outcomes and monitor returns, cancellations and misleading matches as guardrails. Increased clicks alone can reflect curiosity or confusion. Do not claim a conversion uplift from an offline relevance test.

Include inventory and regional variation. A query that works against the full catalog may behave differently when only a small local subset is eligible. Keep sensitive user information out of query logs unless there is an approved purpose and retention policy.

Troubleshooting common failures

• Exact model numbers disappear: inspect keyword candidates, identifier normalization and rank fusion.
• Too few results after filtering: inspect retrieval depth, filter mode and actual eligible inventory.
• Wrong variants appear: check product-versus-variant identity and compatibility fields.
• Old descriptions influence results: compare content, embedding and index versions.
• Relevant results rank below promotions: separate relevance and merchandising effects in evaluation.
• Price or stock differs at checkout: review indexing delay and source-of-truth validation.

A useful first release proves that shoppers can find appropriate products and understand applied constraints. It does not need a conversational interface to demonstrate value.

Common questions

Build product discovery around real shopper intent

Bring catalog structure, query examples and current search failures. Discuss a domain-specific AI solution with measurable relevance and reliable commerce boundaries.