AI product names and descriptions: fixing a catalogue of thousands, with a human approving every line

Two name proposals, not one

For every product the model returns two options plus a rationale. The cleanup version is a light-touch fix: correct the capitalisation, remove the duplicated brand, drop the legacy supplier prefix, keep the name recognisable to staff who have used it for years. The optimised version follows Google Shopping title methodology, front-loading the first 70 characters with the words people actually search.

Giving the reviewer both is what makes bulk approval realistic. Merchandisers reject a single AI suggestion because it feels like a loss of control; they accept a choice between conservative and aggressive because that is a normal merchandising decision.

Deterministic post-processing runs after the model, not instead of it. Duplicated brand mentions and known supplier prefixes are stripped by code, because those are rules, and rules should not cost an AI call to enforce.

Descriptions that have actually seen the product

Description generation is multimodal. The product's main image is sent to the model along with its structured context, so the copy can describe the item in front of it rather than paraphrasing the name back at you.

It also consumes earlier vision output already stored on the product: visual description, image caption, enhanced name, detected colours, materials and styles. Those signals are why a generated description mentions the ribbed grip and the clip-on lid, details that were never in the supplier data.

Three lengths are produced for different surfaces: a short line for listing tiles and meta descriptions, a long body for the product page, and an extended merged version for pages that need depth for search.

• Image-grounded generation using the product's main photo
• Reuses stored vision attributes: colours, materials, styles, captions
• Short, long and extended variants generated for different placements
• Rationale stored alongside each proposal so reviewers see the reasoning

The queue is the feature

Every generation writes a proposal row with the current value, the proposed values, the rationale, the model used and the prompt version. Approval copies the chosen value onto the product. Rejection leaves the product untouched and the record in place.

Because the prompt version is stored, you can tell which products were written by which generation of the prompt, and re-run only those. This is how a catalogue improves over years instead of being rewritten in a panic every time a better model appears.

Work can be scoped: only selected products, only products missing that field, one category, one brand, newly imported products, or everything. Products that already have a pending proposal are skipped, so two staff members working the same queue cannot generate the same thing twice.

A workbench that shows what is missing

Alongside the generators there is a copy workbench that scans the active catalogue and reports, per product, the state of each field, name, short description, long description, extended description and SEO, as missing, pending, approved or already fine.

That view is what turns "our product data is a mess" into a finite list of work. It is also the honest answer to how long a catalogue cleanup takes: as long as it takes to review, which is far shorter than writing.

Why this improves search, not just reading

Product embeddings are generated from the product's text: name, enhanced name, descriptions, attributes, categories and captions. Better copy therefore produces better vectors, and better vectors produce better semantic search results for both typed and photo queries.

So catalogue content work is not a cosmetic project. It is the cheapest available upgrade to your site's search relevance, its category pages and its Google Shopping performance at the same time.