How we replaced keyword search with an AI that understands intent

The Search That Returns Nothing

A customer lands on a pet supplement site and types "something gentle for my dog's stomach" into the search bar. The site's keyword search returns zero results. No product in the catalog contains that exact phrase. The customer leaves.

That same query, run through a retrieval system that understands intent, returns a pumpkin digestive supplement for dogs. The product description mentions "supports digestive health" and "gentle formula for sensitive stomachs." The ingredients list includes pumpkin powder, probiotics, and ginger root. A human reading the description would immediately connect it to the query. Keyword search can't make that connection because it matches strings, not meaning.

We rebuilt a client's product discovery system using retrieval-augmented generation, and search-to-purchase conversion increased by 34% in the first eight weeks.

Why Keyword Search Fails

Keyword search treats every query as a literal string to match against a database of product titles and descriptions. It doesn't understand synonyms, natural language, or the intent behind a question.

This creates specific failure modes. Customers searching for "joint support for older labs" won't find products labeled "glucosamine supplement for senior large breed dogs." Customers searching for "something to calm my cat during fireworks" won't find products listed as "feline anxiety relief chews." The meaning is identical. The words are different. Keyword search sees no match.

Health and wellness categories are especially vulnerable because customers describe symptoms and outcomes while product catalogs describe ingredients and features. The gap between customer language and catalog language is where sales disappear.

What We Built

We started with the client's entire product catalog: 340 products with descriptions, ingredient lists, usage instructions, customer reviews, and FAQ content. We converted all of that text into vector embeddings, which are numerical representations that capture the meaning of the content rather than just the words.

When a customer types a query, the system converts that query into the same kind of embedding and finds the products whose meaning is closest to the query's meaning. "Something gentle for my dog's stomach" lands near products about digestive health, gentle formulas, and stomach sensitivity, even if none of those products contain the word "gentle" or "stomach" in their title.

The retrieval layer returns the ten most semantically relevant products. A ranking layer then reorders them based on additional signals: purchase history for similar queries, current inventory, margin, review ratings, and whether the product is part of an active promotion. The customer sees five products, ranked by relevance to what they actually asked for.

Handling the Edge Cases

The system needed to handle several situations that keyword search ignores entirely.

Ambiguous queries were the first challenge. When someone searches "best supplement," the system needs context. Best for what species? What condition? We trained the ranking layer to ask a clarifying question when confidence is below a threshold, showing a short prompt like "For dogs or cats?" before returning results. This added one click but improved result relevance significantly.

Out-of-stock products were the second issue. The previous keyword search would show out-of-stock items with a "notify me" button, which frustrated customers. We filtered unavailable products from the retrieval results and surfaced available alternatives that matched the same intent profile.

New products without review data presented a cold-start problem. Products with no reviews or purchase history had fewer signals for the ranking layer to use. We addressed this by weighting ingredient similarity and product description embeddings more heavily for new products, effectively saying "this product is similar to these well-reviewed products" until it builds its own history.

What Changed After Launch

Search-to-purchase conversion went from 2.1% to 2.8% within the first eight weeks. The average number of searches per session dropped from 3.4 to 1.8, which means customers were finding what they wanted on the first try more often.

The client's support team reported fewer "I can't find X" tickets. Before the rebuild, about 15% of support inquiries were customers asking for help finding products that were in the catalog but invisible to keyword search. That dropped to under 4%.

The most useful outcome was the query data itself. Every search query is logged with what was shown and what was purchased. This gives the client a direct feed of customer language, which they now use to rewrite product descriptions, add FAQ content, and identify gaps in their catalog. When dozens of customers search for "probiotic for kittens" and nothing in the catalog specifically targets kittens, that's a product development signal, not just a search problem.

The system took six weeks to build and deploy. Most of that time was spent on data preparation and embedding quality, not on the retrieval infrastructure itself. The infrastructure is modular, so the client can update product data, adjust ranking weights, and add new signal sources without rebuilding the pipeline.