Generative AI in production · FLO Group · 2025
Content for 121,000 SKUs: machines draft, people review
Images, SEO text and size advice were produced by hand and by agencies, one product at a time.
In short
Situation: A catalogue of more than 121,000 SKUs needed product images, SEO-optimised descriptions and “why buy” copy, all produced by hand and through external agencies. More than a million customer reviews sat unused while size-related returns kept coming. Decision: A multi-model system rather than a single tool. Diffusion models for product imagery, transformer language models for descriptions and advantage text, a size recommender that learns from reviews, and an MLOps layer that runs them all, so models can be swapped and outputs measured. Result: Validated in live production. Content production time fell by about 70%, manual intervention by up to 60% and external content cost by 40–50%. The size recommender showed potential to cut size-related returns by 5–8%. Published as a conference paper in January 2026. My role: Product owner: scope, quality bar, category-by-category rollout and measurement, built with the data and engineering teams.
- My role
- Product owner
- Period
- 2025
- Scale
- 121,000+ SKUs · 1M+ reviews
- Key figure
- ~70% less production time
Situation and complexity
Every product on a large fashion and footwear site needs the same things: good images, a description that reads well to search engines and to people, a short reason to buy, and honest size guidance. At 121,000 SKUs that is a factory. This one ran by hand, with agencies for images and copy and people for the rest.
Two kinds of cost followed. One was obvious, the money and time spent per product. The hidden one was returns: customers guessed their size, and more than a million reviews that could have told them better were never used.
Options on the table
- Buy more agency capacity
Rejected. It scales cost with the catalogue and leaves quality uneven.
- One generative model for everything
Rejected. Images, SEO copy and size inference are different problems; a single model does one of them well and the others badly.
- A multi-model system with an operations layerChosen
The right model for each job, one pipeline to run them, one place to measure what they produce.
The decision and how it was organised
The architecture paired each task with the model family suited to it: diffusion-based generation for product imagery, transformer-based language models for SEO descriptions and advantage text, and a recommender that read the review corpus to predict how a product sizes. An MLOps layer ran the pipeline, versioned the models and tracked output quality, so improving one component never meant rebuilding the system.
The rollout went category by category, with a quality bar agreed with the content and e-commerce teams before each category went live. Manual work shifted from producing content to reviewing samples, which is where human judgement counts most.
The first release deliberately skipped categories whose imagery carried legal or brand constraints that automation could not yet respect. Those stayed with the agencies until the pipeline had proved itself elsewhere.
Result
Figures as published in the conference paper, validated in a live production environment.
Public record: Paper: 12th International Hasankeyf Scientific Research and Innovation Congress, January 2026, pp. 533–540
What went wrong, what I learned
Intent: One pipeline for every category from the first release.
What went wrong: Categories differed more than planned. In some niche categories the first outputs needed heavier editing than the quality bar allowed.
What changed afterwards: Category-specific prompts and review sampling became part of the pipeline, and the rollout order followed measured quality rather than catalogue size.