How do you make AI product search match how buyers shop?

01AI product search starts with how buyers decide

Most product search is built around the catalog's fields: make, model, year, price. Buyers often think in other terms. In vehicle and RV sales, many buyers know what they can pay each month, not the price they can afford. In Canada, many think in payments every two weeks. A search that only filters on sticker price forces the buyer to do the arithmetic, and a chat assistant that cannot do it gives a vague answer. This is part of our larger guide, How do you build a RAG chatbot on your knowledge base?.

The U.S. Consumer Financial Protection Bureau has long noted how much the monthly payment shapes car buying. Its auto loan shopping guidance warns that a lower monthly payment often comes from a longer loan and more interest, and encourages buyers to compare total cost. Whatever you think of payment-led shopping, it is how many buyers start, so a search tool that ignores it ignores the buyer.

The first step is research, not engineering. Read real search logs and chat transcripts. List the ways buyers describe what they want. Group them into constraints the product can turn into filters, and constraints it cannot.

02Turn natural language into precise filters

We built and run a white-label AI sales assistant for dealer websites, serving RV, marine and vehicle dealers. On it, buyers ask in natural language with follow-ups: towing questions, payment budgets, location limits and changes of mind. Supporting payment-based filtering by country turned a common question into a precise inventory search instead of a vague answer.

The pattern behind it is to let each component do what it is good at:

1. 01

   The language model reads the request and extracts structured constraints

   category, budget and its period, towing need, location, new or used.

2. 02

   Code converts constraints into filters the search engine understands, using rules per country, such as monthly payments in the U.S. and biweekly payments in Canada.

3. 03

   The search engine applies hard filters first, then ranks within them using keyword and vector similarity.

4. 04

   The model explains the results it was given, with the reasons each unit fits, and never adds units or prices of its own.

5. 05

   If nothing matches, the assistant says so and offers the nearest useful alternative or a person to talk to.

Hybrid search fits this well. Elastic's documentation describes running full-text search and vector search in one request and merging the two result lists with reciprocal rank fusion. Keyword matching handles exact model names and trims; vector similarity handles descriptions like a family camper that sleeps six.

The table shows how common buyer phrasing maps to search behavior.

03Keep every answer grounded in live inventory

Inventory changes constantly. In the dealership assistant, each dealer's inventory feed syncs into the search index every hour, and answers are grounded in the dealer's own inventory, website and FAQ content. The rule that could never break was that the assistant must never invent stock or prices.

That rule shapes the architecture. The model never sees the whole catalog and never answers from memory. It calls a search tool, receives real units, and writes about those units only. Prices and availability are displayed from the feed, not paraphrased by the model. When a buyer asks about a unit that sold an hour ago, the next sync removes it.

Messy data is the other half of grounding. Dealer feeds differ: missing prices, duplicate classification fields, placeholder prices, RVs and boats mixed in one file, and different page address schemes. Early dealer tests showed context loss and wrong categories. Cleaning rules per feed, such as excluding placeholder prices from payment math and enforcing strict category values, matter as much as the model. Exclusion rules and new-versus-used rules are set per dealer.

04Route the questions search cannot answer

Not every buyer question is a search. Service, parts, finance and trade-in questions need to reach the right department, and some buyers want a person. The dealership assistant routes questions by intent and captures leads and appointments into the client's existing CRM with a transcript summary, the filters applied and the vehicle data. It also supports hand-off to a human agent. English and Spanish are both supported, and each dealer's data is isolated.

The lesson for any commerce product is to decide early which intents the search assistant owns and which it hands off. A search tool that tries to answer a finance question with inventory results frustrates buyers more than one that says it will connect them to the finance team.

05Test with the questions buyers really ask

Search quality is easy to overestimate when the test questions are written by the team that built the search. Buyers phrase things in ways engineers do not expect, combine several constraints in one sentence, and change their minds halfway through a conversation.

We build the test set from real conversations wherever we can. Each test records the buyer's words, the constraints that should be extracted, and the units that should and should not appear. A test passes only if the filters are right and no unit outside the constraints shows up. We also keep tests for the empty case, where the honest answer is that nothing matches, because that is where an assistant is most tempted to stretch.

These checks run whenever the prompt, the model, the feed rules or the search settings change. A fix for towing questions should not quietly break payment questions, and only a stable test set shows that.

06What we see in production

The dealership sales assistant has been live in production on dealer websites since early 2026, for a dealership software company serving RV, marine and auto dealers in the U.S. and Canada. Leads and appointments flow into the existing CRM. A few lessons stand out.

Payment questions are among the most common ways buyers start, and country rules matter. A payment filter that assumes U.S. monthly terms gives Canadian buyers wrong results. Handling the period per country is a small piece of code with a large effect on answer quality.

Towing-capacity matching and pricing sync needed fixes after real buyer conversations. Test sets built from real dealer prompts caught more problems than any synthetic list we wrote ourselves. Stabilizing with a small number of live dealerships before scaling gave us those prompts early.

We also see that the simplest search architecture that stays grounded wins. Moving from a general data agent to search-backed inventory lookup, and later rebuilding the flow as a tool-using agent with search filters and similarity search, made answers more precise and easier to test. Token usage is logged per conversation, which keeps cost visible as traffic grows. For more on that side, see how much production AI costs in SaaS.

Frequently asked questions