AI search

AI image search: a shopper photographs a product and your catalogue answers

A customer is standing in their kitchen holding a cracked container. They do not know the brand, the model number or what you call it in your catalogue. They can photograph it. That is the entire premise of image search, and it converts because it removes the vocabulary problem completely.

GoGee handles the photo in one pass: a vision model reads the image into structured facts, those facts are resolved against your real brand and barcode data, and the results are ranked so that a verified barcode match always outranks something that merely looks similar.

GoGee feature series · 2 of 33

How it's actually built

Vision model
google/gemini-2.5-flash, structured output
Accepted formats
JPEG, PNG, WebP, validated by file signature
Size cap
6.5MB decoded
Candidate pool
24 products, or 72 when branch-aware
Similarity floor
0.15 cosine, then re-scored by match tier
Rate limits
10/5min and 30/hour per visitor, 400/hour site-wide
Photo pipeline
  1. 01Input

    Photo upload

    JPEG, PNG or WebP checked by file signature

  2. 02AI

    Vision read

    Gemini 2.5 Flash returns name, brand, type, SKU, barcode, colours

  3. 03Deterministic

    Relevance gate

    Non-product photos clear results and switch to a suggest path

  4. 04Database

    Shared text index

    Caption embedded into the same product vector index

  5. 05Output

    Tiered matches

    Candidates re-scored by match tier

Guardrails and fallbacks

  • 6.5MB decoded cap
  • 24 candidates, 72 when branch-aware
  • 0.15 similarity floor
  • 10/5min and 30/hour per visitor

AI image search, snap & find, data flow, generated from the shared GoGee feature diagram template.

What the vision model actually extracts

The photo is not thrown at a similarity index as pixels. It is read into a strict structure: likely product name, brand, product type, model number or SKU printed on the item, barcode digits if legible, colours, materials, a search phrase, a confidence score, and a flag for whether this is even a household product you would stock.

That last flag matters. If the customer photographs their dog, results are deliberately cleared rather than filled with the closest plastic object, and the interface switches to a "suggest this product" path instead of pretending to have an answer.

How the matching is ranked

The extracted search phrase is embedded and matched against your product vectors, producing a candidate pool. Those candidates are then merged with hard identifier lookups and scored in tiers: barcode or supplier barcode first, then SKU, then brand-plus-name text matches, and finally visual and semantic similarity.

Duplicates collapse to their highest score, so a product that matches on both barcode and similarity appears once, at the top. If a branch is selected, results can be filtered to what is actually in stock at that branch before the shopper commits emotionally to a product they cannot collect today.

  • Barcode and supplier barcode: highest confidence tier
  • SKU printed on the product: second tier
  • Brand plus product name text match: third tier
  • Vector similarity from the vision caption: final tier

Captioning, not a separate image index

It is worth being precise about the architecture, because plenty of vendors are not. GoGee does not maintain a second parallel image-vector index at query time. The photo is captioned into text by the vision model, and that text is embedded with the same embedding model used for typed search.

The practical consequence is good: image search inherits every improvement made to text search, including exact-identifier scoring, price filters and stock awareness. Product photos are also captioned in bulk on the catalogue side, and those captions feed each product's embedding, which is what makes the visual half of the match work.

Guardrails before the AI call

Uploads are validated by magic bytes rather than trusting a file extension, capped by size, and rate-limited per visitor and globally. If structured extraction fails, a second call runs in strict JSON mode and the response is parsed manually. Every search is logged with its input mode so you can see how many people are choosing photo over typing.

Questions we get asked

Does the customer need an app?

No. It is a browser upload or camera capture on your own site. There is nothing to install.

What if we do not stock the product they photographed?

The result set is intentionally cleared when the vision model says the item is not something you stock, and the flow becomes a product suggestion instead of a bad match. Those suggestions are a useful buying signal.

Can it read barcodes off the photo?

Where the barcode digits are legible in the image, they are extracted and used as the highest-confidence match tier against your barcode and supplier-barcode fields.