AI clothing selection: why recommendations miss the mark
The recommendation system for outfit selection breaks at the same place — at the product catalog. While the assortment is small and homogeneous, general rules (“light with blue,” “sneakers with sporty”) are enough.
As soon as the catalog is assembled from dozens of suppliers, product cards start describing the same item differently: some include cut and texture, some only category and color, and some positions are entered manually with no features at all.
Without computer vision, the system does not see the item itself. It works with card text: name, category, tags, purchase history. Anything not labeled does not exist for it — a loose-fit shirt and a slim-fit shirt of the same color pass as one position.
Hence the failure: the rules are formally followed, but the person will not wear the proposed outfit.
The second reason is how success is measured. The team looks at clicks and view depth, not recommendation accuracy. A click proves nothing: a card is opened out of curiosity and closed a second later.
Training on such signals, the system reinforces the most popular — and outfit selection converges to the same set of items for everyone, regardless of body type, occasion, and what has already been bought.
The cost is predictable: the return rate grows, and trust in selection falls so much that people simply stop using it. We analyze how this is addressed.
What changes when outfit selection relies on data
When the catalog is labeled by attributes — silhouette, fit, color, texture, occasion — selection stops guessing from the image and chooses by feature compatibility.
Personalization of selection is built on a knowledge graph: nodes are items and their properties, edges are compatibility rules and body type constraints.
Generating an option takes fractions of a second because candidates are filtered by edges, not by brute-forcing the entire catalog, and the top three positions are assembled immediately as an outfit.
Recommendation quality metrics are counted by behavior, not ratings: share of times the selected item appears in the top three suggested options, share of sessions where selection was made before leaving the page, depth of viewing alternatives.
This separates selection error from size availability error — previously they merged into one failure metric, and it was unclear whether to fix the algorithm or the warehouse.
A separate layer is new item arrivals. An item without view history did not participate in selection until it accumulated statistics; now it immediately gets edges by attributes and joins outfits on par with established positions.
A whole class of errors disappears when a new item sits idle in the catalog while recommendations keep showing previous hits.
On the business side, the effect is visible in return rate and catalog conversion: the buyer less often abandons at the selection stage because they get a complete outfit rather than a single item.
The boundaries are honest — without attribute support in cards and feedback on actual returns, quality will drop. Therefore we maintain labeling as a regular process on the graph platform Neo4j, not as a one-time upload.
Implementation approaches: ready service, own model, hybrid
The choice of approach is determined not by “model power” but by two things: how much of your own data about choice and buyer behavior you have, and how often the assortment changes.
A ready recommendation platform provides working selection in a matter of weeks, but it trains on other catalogs — in a narrow category with rare sizes and complex compatibility, it makes mistakes where precision is needed.
An own model on your data removes this limitation, but requires labeling and accumulated history: up to several months to the first usable result.
Therefore a hybrid scheme is more often used — an external service covers the cold start, while your own model and compatibility rules are further trained on your data and gradually take over the main load.
| Option | When it fits | Limitations |
|---|---|---|
| Ready recommendation platform | You need launch in a short time, the catalog is typical, and you have no selection history yet | Selection logic cannot be adjusted, quality on rare categories is unpredictable, data goes outside |
| Own model, training on your data | You have purchase and view history, the assortment is stable, and you need control over logic | Labeling is needed and several months to acceptable quality; when collections change, retraining is required |
| Hybrid scheme | You need a fast start and precision on your own data | Harder to maintain: two selection branches need to be coordinated with each other |
| Rules and attributes without training | The catalog is small, strict compatibility by size, color, and season matters | Does not account for tastes and history, quality drops as the assortment grows |
Almost always, you should start with compatibility rules — they provide a predictable baseline and serve as a check for any option above. Then the scheme is expanded as data accumulates.
Workflow: from data audit to handover to operation
We start not with the model but with data: without a clean catalog and an agreed feature schema, any selection algorithm produces a plausible but random result. Below is the sequence of stages by which we lead a project from audit to operation.
- Data audit. We export the catalog, check attribute completeness, find duplicates, broken size charts, and positions without photos. We record which features actually exist and which will need to be obtained separately.
- Catalog labeling. We agree on the schema: color, cut, texture, season, style, category compatibility. We label a representative sample — knowledge graph rules rely on verified fact, not guesswork.
- Pipeline setup. We assemble feature extraction from images and descriptions, normalization, and versioning of datasets. Any catalog update follows the same path, without manual edits.
- Model training. We train ranking on “query — outfit” pairs, and separately test cold start: new products without impression history should not fail in the output.
- Quality check. Metrics: share of relevant answers in the top, robustness to noise in descriptions, failure rate. We look at slices by category and separately on the labeling agreed with your team.
- Deployment and handover. We connect the system to the catalog and storefront, set up post-release quality control, train the team, and hand over documentation.
Each stage ends with an artifact that can be checked: catalog report, feature schema, recorded metrics, support instructions.
Project artifacts: knowledge graph, data schema, policies
The project ends not with a demo of a working prototype but with a set of artifacts that the customer’s team launches and changes without us.
Everything is in your repository: the model with fixed weights and metrics, the knowledge graph, the feature schema, and the policies by which the system lives after handover.
- Trained model — weights, a metrics card by slices (category, body type, photo quality) and a training reproduction script so the result repeats on new data.
- Knowledge graph — products, features, styles and categories as nodes, compatibility and interchangeability as weighted edges; a separate query retrieves “what matches this item” without retraining.
- Feature schema — for each feature, the source, normalization method, and behavior when missing, plus test sets showing that the schema has not diverged from the model.
- Request processing schema — the path from the user’s photo to output: where the image vector is calculated, where foreign categories are filtered, and at what point the graph is connected.
- Model documentation — limitations, known error classes, input image requirements, and the confidence threshold below which the system honestly asks for a second photo.
- Access roles — who reads the storefront, who edits the graph, who deploys the model; edge edits and retraining are separated by contours so that assortment changes do not break output.
- Update policy — retraining triggers (output drift, new categories), regression check on a holdout set, and rollout order with rollback to the previous graph and model version.
Case: how recommendation accuracy grew after relaunch
Implementation case: the clothing chain Mode Line with a catalog of tens of thousands of positions. Before relaunch, selection relied on filters and category sales statistics — the user set size and color, and the system returned popular positions.
Selection accuracy did not exceed 41%: more than half of the suggested outfits were changed manually, and an option had to be waited for 4–5 seconds.
The relaunch was assembled from two parts. Computer vision parses a product photo into attributes — fit, cut, length, fabric texture, shade.
The knowledge graph links attributes with compatibility and body type, and the ranking layer is further trained on feedback: what was added to cart, what was returned, what was replaced with an analog.
Metrics before and after
- selection accuracy: 41% → 78% on a holdout set of sessions;
- option generation time: 4–5 seconds → less than a second;
- return rate for selected outfits: 24% → 11%;
- share of orders with an outfit of two or more items: 18% → 34%.
Implementation time — 14 weeks by stages: 3 weeks for catalog audit and labeling, 5 for model training and validation, 3 for interface integration, another 3 for comparison with the previous output logic and fine-tuning.
The limitation turned out to be not the algorithm but the attribute dictionary: while cut and fit were described inconsistently, accuracy was limited by labeling, not the model.
How does photo-based recommendation differ from catalog filters?
Catalog filters are exact match by manually labeled attributes: color, brand, size, material. As long as the card is filled and the query is worded, the path is predictable and easy to debug — incorrect output is reduced to a specific field. It breaks on the query “find similar to this photo”: there are no attributes, only the image.
Photo search solves the inverse task. The image goes through an encoder and turns into a vector where cut, texture, color, and silhouette are considered jointly, not by one field; such models work on multimodal architectures like CLIP. Matching is by vector proximity, so an item not described by any tag is found.
| Criterion | Catalog filters | Photo search |
|---|---|---|
| Matching | exact by attributes | by feature proximity |
| Data requirements | labeled card | images and their vector representations |
| New items without labeling | do not appear in output | are found immediately |
| Cold start | history not needed | needed, but the image replaces it |
| Debugging | by specific field | by similarity labeling |
On cold start, the paths diverge most. Filters do not need interaction history; vector search does — but the image itself partially replaces it.
Therefore pure schemes are rare in production: vector selection forms candidates, filters act as constraints (size availability, season, body type), and reranking considers behavior.
The quality of the hybrid is visible by the share of queries where the relevant item remained in the top ten.
Questions asked before project start
Before the start, we are more often asked not about the model but about data: whether the catalog is enough and what to do with heterogeneous supplier attributes.
Color, cut, season, and composition come with varying completeness — some fields are filled manually, some are exported from accounting systems, and this determines where the system answers confidently and where it guesses.
Implementation timelines are tied to data readiness, not the calendar: we assemble the first working loop on a segment with verified attributes and expand it as metrics are controlled.
After launch, the model is maintained — new collections, seasonal shifts, and discrepancies in supplier exports are tracked in advance, not by complaints.
How complete should the catalog be at the start?
A full catalog is not needed: a segment where attributes are filled and verified is enough. On it we calibrate output, measure the share of correct selections, and only then connect the remaining categories.
What about heterogeneous supplier attributes?
We bring them to a unified value reference and matching rules: some are covered by a synonym dictionary, disputed positions are labeled manually. For each category, a coverage report remains — you can see how many positions are fully described.
How do you check quality before launch?
We prepare a control set of queries and reference selections and run several iterations on it. We look not at overall accuracy but at the share of gross errors — when something incompatible by size, season, or style is suggested.
Who supports the model after deployment?
The model ages with the assortment: collections, shade names, and suppliers change. The policy includes retraining on a new data slice, metric control, and review of disputed selections; new categories are connected in stages.
How is confidentiality ensured?
Images and catalog data are processed in the customer’s environment or in a dedicated environment, access is differentiated by roles, and exports are anonymized. We separately record which data remains with us and which does not leave the customer’s infrastructure.
Let’s discuss the task: how we will start work on the system
The outfit selection system rests not on the model but on data: the knowledge graph about products is assembled from catalog attributes, and computer vision learns on real images and on how buyers choose items.
Therefore the project start begins with an inventory of what already exists — otherwise the task estimate becomes a guess and the implementation plan becomes a wish list.
What we need from your side:
- Catalog export in its current form: SKUs, categories, attributes, size charts, regional availability.
- Product photos and, if available, customer photos — they show how much shooting conditions differ from studio conditions.
- Description of the current customer path: where they search for an outfit, at what step they leave, who consults now.
- Domain restrictions: stop lists, incompatible combinations, seasonality, display rules.
- A test catalog loop or regular export — so the prototype works on live data.
- A responsible person on your side and the metric by which you will consider the pilot successful.
In return we provide:
- A task estimate by stages indicating what exactly moves the timelines.
- An implementation plan from data labeling to production, with checkpoints.
- Pilot composition: one catalog section, a set of metrics, and the condition under which we expand the system to the entire assortment.
- Data and role requirements on your side so integration does not stall midway.
Describe the task — we will come back with an estimate, stage plan, and pilot boundaries.
