Natural-language search across a 150,000-SKU catalogue

The problem

The client sells bidets, kitchenware and a full home-renovation range. Their product information lived where product information usually lives: in around a hundred manufacturer catalogues as PDFs, plus fifty or sixty spreadsheets.

In a live conversation with a customer, a salesperson works from memory. That means the few hundred products they know well. The alternative that was in stock, the complementary item that lifts the basket, the newer model at a better margin: all technically available, all practically invisible.

The cost was never a missing feature. It was every quote that quietly under-sold the catalogue.

What I built

A retrieval-augmented assistant over the full product corpus, so a salesperson can ask in plain language and get an answer in seconds, including products they didn't know to ask about.

The chat interface was never the hard part. Ingestion was. A hundred catalogues in inconsistent layouts, mixed with spreadsheets, where a wrong specification in an answer is worse than no answer at all.

Architecture

Fully serverless, provisioned end to end with Terraform. Two models doing two different jobs, chosen on cost and fit rather than defaulting to the most capable one everywhere.

Ingestion · managed by the client

1

S3~100 catalogues and 50–60 spreadsheets

one page at a time

2

Vision extractionreads each page as it was laid out

indexed

3

Knowledge Basesearchable index over the whole corpus

Query · sales floor

4

CloudFrontthe interface a salesperson uses mid-conversation

question

5

Bedrock agentretrieves, then answers with a link to the source page

hybrid retrieval

6

DynamoDBstructured product attributes alongside semantic search

1. The client uploads catalogues and spreadsheets themselves. No dependency on me to add a range.
2. Each page is read as a page, so a specification stays attached to the product it belongs to.
3. The result is indexed once and queried by everyone.
4. A salesperson asks in plain language, in front of the customer.
5. The agent answers and links to the exact catalogue page it drew from, so the specification can be checked before it is quoted.
6. Structured attributes are retrieved alongside the semantic match, because "what fits this" is a different question from "what resembles this".

Decisions that mattered

The right model for each job, not the best model everywhere

Reading a catalogue page and reasoning about a customer's question are different tasks, and the strongest available model is not automatically the right answer to both. Models were evaluated per stage and selected on accuracy rather than price, because in a product catalogue a wrong dimension costs more than an expensive token.

Every answer links to the page it came from

The assistant cites its source: a link straight to the page of the catalogue the answer was drawn from. A salesperson quoting a specification to a customer can verify it in one click rather than trusting the model.

Correctness before throughput on first ingestion

The initial load ran serially rather than in parallel, so I could verify extraction quality across the corpus and catch failures as they happened. Parallel ingestion is a straightforward optimisation, deliberately held back until the output was proven. A fast pipeline that silently mangles a spec table is worse than a slow one being watched.

The client feeds it themselves

Adding a new catalogue, updating an old one or removing a discontinued range is done from the interface, by the client. No dependency on me to load a file. That's the difference between delivering a project and delivering a capability.

Where it goes next

Complementary products currently rely on the structure of the source material: related items are usually printed together, so page-level retrieval keeps them together. An explicit relationship store is the next step, which will make the behaviour deterministic rather than inferred.