How to Build Better E-commerce Search with RAG
For E-commerce product teams building search · Based on Owain Lewis RAG Retrieval Strategy Selector
// TL;DR
E-commerce product teams can use this framework to build search that actually understands shoppers. Full-Text Search handles exact brand names like 'Nike,' Vector Search surfaces semantic matches like 'comfortable' finding 'cushioned midsole,' and SQL RAG handles exact filters like price and rating. Real queries mix all three — 'Nike running shoes comfortable for distance under $100' — so Hybrid Search combining Full-Text and Vector via Reciprocal Rank Fusion is the recommended production default. Matching strategy to query type prevents the classic failure of returning a $200 shoe when a shopper asked for under $100.
Why does my product search return irrelevant results?
Usually because you're using one retrieval strategy for queries that need several. Shoppers combine brand names, vague descriptors, and hard filters in a single search. The RAG Retrieval Strategy Selector diagnoses each query type and routes it to the right strategy — Full-Text for keywords, Vector for meaning, SQL for filters, or Hybrid when they mix. Defaulting to Vector Search for everything is the most common mistake, and it silently returns a $200 shoe when a shopper asks for under $100.
How do I handle brand-name searches?
Use Full-Text Search. When a shopper types 'Show me Nike shoes,' the brand is an exact keyword match. PostgreSQL's built-in TS Vector and TS Query handle this with no extra infrastructure. Apply stemming so 'running' also matches 'runner' and 'runs.' You don't need vector embeddings for exact keyword lookups — Full-Text is cleaner and faster. Just remember it breaks down when synonyms or meaning matter.
How do I surface products that match vague descriptions?
Use Vector Search. When a shopper searches 'comfortable shoes for long-distance running,' your product descriptions might say 'cushioned midsole, marathon-ready' and never use the word 'comfortable.' Full-Text would miss these. Chunk your product catalogue, embed the chunks with an embedding model, and store them in PGVector. At query time, embed the shopper's query and retrieve chunks by vector distance — smaller distance means closer meaning. Vector Search finds intent, not just words.
Critical warning: Vector Search cannot handle exact value filters. Ask for 'shoes under $100' and it may return a $200 shoe that's semantically similar. Never rely on Vector alone for price, brand, or rating constraints.
How do I handle price, rating, and category filters?
Use SQL RAG with predefined queries. For 'running shoes under $100 with at least four stars,' write a parameterised query — `SELECT * FROM products WHERE category = ? AND price < ? AND rating >= ?` — extract the parameters with an LLM, inject them, and execute. This is deterministic and reliable, which is what you want on a customer-facing storefront. Keep dynamic LLM-generated SQL out of production search.
What strategy handles real mixed queries?
Use Hybrid Search. Real shopper queries like 'Nike running shoes comfortable for distance' need both brand-name precision and semantic comfort matching. Run Full-Text Search to find records containing 'Nike,' run Vector Search to find comfort-and-distance-relevant records, then combine both result sets using Reciprocal Rank Fusion into one ranked list. Hybrid Search is the recommended default when you're unsure — it captures both keyword precision and semantic breadth in one pass.
When queries also carry hard filters like price, layer SQL RAG to constrain the candidate set before or alongside Hybrid ranking, so you never surface an out-of-budget product.
How do I validate my search before launch?
Check the failure modes. Confirm Vector Search never handles exact filters alone. Confirm Full-Text isn't your only strategy when shoppers paraphrase. Confirm your customer-facing SQL uses predefined queries, not dynamic ones. Test with real query logs covering brand-only, descriptor-only, filter-only, and mixed searches.
Next step: Pull your top search queries and classify each as keyword, semantic, filter, or mixed. Wire Full-Text, Vector, and SQL RAG for the pure cases, default to Hybrid Search for mixed queries, and validate against the $200-shoe failure mode before shipping to production.
// FREQUENTLY ASKED QUESTIONS
Why does Vector Search return products over my price limit?
Vector Search matches by semantic meaning, not numeric constraints, so it can't enforce a price ceiling — it may return a $200 shoe when a shopper asks for under $100 because it's semantically similar. Handle price, rating, and other exact filters with SQL RAG, and combine it with Vector or Hybrid Search for the descriptive part of the query.
Should e-commerce search use Full-Text or Vector Search?
Use Full-Text for exact keyword matches like brand names, and Vector for vague descriptive searches where synonyms matter. Since real shopper queries mix both — a brand plus a comfort descriptor — Hybrid Search combining them via Reciprocal Rank Fusion is the recommended production default. It captures keyword precision and semantic breadth in a single ranked result list.
How do I combine filters with semantic search on my storefront?
Use SQL RAG to enforce exact filters like price, rating, and category with predefined parameterised queries, then apply Hybrid or Vector Search for the descriptive part of the query. This constrains the candidate set to in-budget, in-spec products first, so semantic ranking never surfaces items that violate the shopper's hard filters.