Resources / Field guide

Natural-language search over a product catalog

A staff member at the counter searches for a part, doesn't know the exact term, and gets nothing — even though the product is right there. Keyword search only finds what you can already name. Here's how to add a semantic layer that understands intent, and how to pick the right approach for your stack.

The problem with keyword search

Exact-match and keyword search are unforgiving: if the user's words don't match the words in your data, the result doesn't surface. Someone types "the thing that holds bikes on a car" when your catalog calls it a "hitch-mount carrier," and the search comes up empty. The product exists; the vocabulary didn't line up. This costs real time at a service counter and real sales on a storefront.

Semantic search fixes the vocabulary gap by matching on meaning rather than spelling. Crucially, it should augment your existing exact-match search, not replace it — SKU and part-number lookups still need to be precise.

How semantic search actually works

The core idea is embeddings: a model converts each product (title, description, specs, category) into a vector — a list of numbers that captures meaning. Do the same to the user's query, and "closest vectors" are the most semantically relevant products, regardless of shared words. That's the engine under every approach below; what differs is where the vectors live and who computes the "closest."

Three ways to build it

1. Platform-native AI search

If your data platform offers a built-in semantic/AI search feature, try it first. It keeps everything in the stack you already run and operate, with the least new infrastructure. The trade-off is that results quality and tuning control vary — some teams find it excellent, others find it underpowered for their data. Cheap to spike, so spike it.

2. SQL + embeddings (a RAG-style setup)

Generate embeddings for the catalog, store them alongside your data (many SQL engines now have vector support), and rank by vector similarity at query time. More moving parts, but it's a proven, well-documented pattern with full control over indexing and ranking. This is the dependable middle path.

3. A managed search service (e.g. Azure AI Search)

A dedicated search service gives you vector search, hybrid keyword+semantic ranking, and re-indexing pipelines out of the box. It "just works" and scales, at higher cost and with the work living outside your core app. Reach for it when search is central and you want it to be someone else's operational problem.

My recommendation: start with the simplest option your platform supports, measured against a real test set (below). Only escalate to SQL+embeddings or a managed service if the simple option underperforms on your data. Don't buy infrastructure you might not need.

The thing most teams skip: a real test set

The single highest-leverage step is collecting actual queries that failed — the awkward, plain-language searches staff or customers really typed. That set becomes your benchmark. Without it you're tuning blind; with it you can compare approaches objectively and know when "good enough" is actually good enough.

A sensible rollout:

  1. Export the catalog (titles, descriptions, specs, categories, SKUs) and gather a list of real failed/awkward queries.
  2. Add any known synonym list (e.g. informal term → industry term).
  3. Spike the simplest approach against that query set.
  4. If it underperforms, prototype embeddings-in-SQL or a managed service and compare on the same set.
  5. Wire the winner into the search box staff already use.

Questions to answer before you build

  • Catalog size and churn — drives index cost and how often you re-embed.
  • Latency budget — a counter interaction needs sub-second; an overnight report doesn't.
  • Languages — multilingual queries change model choice.
  • Where it lives — internal tool, public storefront, or both (which affects scale and cost).

Want search that understands what people mean?

I design and build semantic search over product and document data — and I'll start by proving it against your real queries before recommending any infrastructure. Let's talk.

Work with me