AI text search: how GoGee understands what a shopper actually meant

Stage one: the sentence becomes filters

When a shopper types "cheap plastic storage boxes with lids under R150", the query first goes to a language model with a system prompt that describes your store and hands it a live vocabulary of your own category slugs, brands and branches, pulled from your database on the request, not hard-coded into a prompt someone wrote a year ago.

The model returns a structured object that is schema-validated before anything touches your database: keywords, colours, brand hints, category slugs, price bounds, and a flag for whether the query is even about your products. Off-topic queries are answered as off-topic instead of being forced through a catalogue search that will return nonsense.

Prices are the one thing we never fully trust a model with. "Under R150" is also matched deterministically with a pattern rule, and that rule overrides whatever the model guessed, because a shopper who sets a budget and is shown a R900 product does not come back.

• Structured output is validated against a strict schema, not parsed hopefully
• Category and brand vocabulary is loaded live from your own tables
• Off-topic queries short-circuit before any database work happens
• Price bounds are enforced by deterministic rules, not model judgement

Stage two: meaning, not string matching

The query is embedded with Gemini's embedding model at its native 3,072 dimensions and matched against the product embedding column using cosine similarity inside Postgres. Every product's vector is generated from a rich text blob: name, AI-enhanced name, short and long descriptions, supplier attributes, colours, materials, styles, category names, custom fields, variant labels and SKU.

That is why a search for "container for leftovers" finds a food-storage set with no shared words, and why a misspelling still lands. The match runs against an HNSW index built for cosine distance, so similarity search stays sub-second as the catalogue grows into thousands of SKUs.

Exact hits always beat clever hits

Semantic search on its own has one dangerous failure mode: a trade customer types an exact SKU and gets shown five products that are conceptually similar to it. GoGee prevents this with a scoring merge. Barcode and supplier-barcode matches are scored highest, then SKU matches, then exact brand-and-name matches, and only then vector neighbours ranked by similarity.

If the merged result set is still thin, a plain keyword search runs as a final safety net. A shopper should never see an empty results page because the AI layer had an opinion.

It gets better because you correct it

Every AI search is logged with the query, the extracted filters and the model used. When a result set is wrong, an admin marks it down, and the lesson learned from that correction is injected into the system prompt on every future search.

This matters more than model choice. A generic search engine cannot know that in your business a "crate" and a "bin" are different things and a "lid" is never sold alone. Your corrections teach it, and the correction sticks.

Built to survive real traffic

AI calls cost money and bots do not care. Search is rate-limited per visitor and globally, timeouts fall back to a faster model, schema failures trigger a single repair pass, and total failure degrades to a deterministic keyword search using the raw query. The shopper still gets results; you do not get a surprise invoice.