Stop assigning categories by hand, let an ML pipeline do it at around 90-95% accuracy

The Problem

Marketplaces don’t choose their suppliers’ formatting. Every feed arrives with its own conventions. One product gets named ten different ways across suppliers, and none of those names match the marketplace’s internal category tree.

Then there’s the tree itself. A large CIS marketplace catalogue holds roughly 3,500 categories. National fiscal taxonomies run similarly deep. Manual mapping at that depth, against hundreds of thousands of incoming items per day, is impossible. So most platforms compromise. They accept supplier-side categorization, which is wrong, inconsistent, and gameable. They hire an army of moderators, which is slow, expensive, and still inconsistent. Or they leave items uncategorized, which kills discovery.

The same underlying problem shows up in three guises. There is receipt-line classification for fiscal reporting (national tax and fiscal-data systems). There is supplier-feed categorization for marketplaces. And there is product onboarding from new partners, which every B2B marketplace faces.

What the Solution Does

A classification pipeline that takes a product name (plus any structured signals like price, supplier, brand) and assigns it to the correct node in your category tree. One stack handles attribute extraction (brand, weight, type, size) from free-text names and duplicate detection across supplier feeds.

1. Embed, convert each product name into a 500-700-dimension vector that captures meaning beyond keywords.
2. Reference catalogue, a curated set of examples that map each name to its category for your target taxonomy.
3. Classify, KNN in the reference catalogue, plus calibration logic that returns “Other / Unknown” when the model isn’t confident.
4. QC layer, items with low confidence get routed to human moderators (yours or ours). Their corrections feed back into the next training cycle.
5. Extract and deduplicate (one embedder), pull out brand, weight, size, and identify cross-supplier duplicates that point to the same underlying product.

Where It Fits

This makes sense if you…

• Run a marketplace, fiscal platform, or data system with a deep category tree (1,000+ nodes)
• Ingest product data from external suppliers or external feeds
• Have at least some historical data that maps items to categories to bootstrap (5-10k labeled examples is enough to start)
• Need consistent classification that holds across moderators
• Want to extract attributes (brand, weight, type) from messy free-text product names

This is probably not the right time if you…

• Have a small taxonomy (under 100 categories), where simple rule-based or off-the-shelf NLP works
• Have no historical labeled data and no budget for an initial labelling sprint
• Need to categorize highly visual products without text descriptions (use visual-search, or combine the two)
• Want 100% accuracy with no human review. ML does not deliver that, so build the QC layer in

Business Value

The headline metric is accuracy, and it’s worth being specific about it.

Accuracy at scale. On our published deployments in national fiscal receipt classification, accuracy clears 0.9 across all client taxonomies and reaches 0.98 on the best-curated ones. That is measured per-item, against held-out ground truth, on real production volume of millions of receipts per day. The 0.98 figure is best-case: a clean target catalogue, a large training set, well-defined classes. On a typical new deployment, expect the 0.9-0.95 range.

Throughput. A trained pipeline classifies hundreds of items per second per CPU core. Multi-million-per-day throughput is routine on commodity infrastructure.

Stability under catalogue change. The model embeds product names into a stable semantic space and matches against a reference catalogue (KNN). That means changing the taxonomy does not require retraining the embedder. Adding a category, splitting one in two, or remapping for a new region is a reference-catalogue edit, and the model stays put. This matters more than it sounds. A traditional direct-classification model becomes a maintenance burden the moment your taxonomy changes. KNN against a stable embedder absorbs that churn cheaply.

Reduction in manual work. Manual categorization time typically drops 70-90%. Humans handle exceptions and edge cases, the pipeline handles the rest. The exact baseline depends on what manual processes you run today, so we measure during pilot.

How It Works

Three layers, one underlying technology.

1. The understanding layer, embeddings

A neural embedder (BERT-based, fine-tuned on your domain) converts each product name into a vector of 500-700 numbers. The vector captures meaning. So three ways of writing one milk-chocolate bar, full name, swapped word order, and a shorthand abbreviation, all land near each other in vector space. Keywords alone would treat them as different.

The base embedder has been trained on years of data: supplier feeds, fiscal receipts, marketplace catalogues, retail master data. That is what lets it handle typos, abbreviations, and unusual formatting from day one. You do not need a million labeled examples per project to get there.

2. The categorization layer, KNN against a reference catalogue

For a new input, we find the K nearest items in the reference catalogue. That catalogue is a curated set of examples, each mapping a name to its category for your taxonomy. The dominant category among the K nearest wins, with a confidence score. If the score is below threshold, the item gets flagged “Other / needs review”. The system does not force a guess.

This architecture matters. The reference catalogue is editable and the embedder is stable, so you can adjust categorization decisions surgically. If “dog food” is being mistakenly routed to “cat food”, you add a few “dog food” examples to the reference catalogue and the behaviour changes. No retraining, and no risk of side-effects elsewhere in the model.

3. Attribute extraction, Named Entity Recognition

The one embedder is reused for attribute extraction. For each word in the product name, the model predicts which named entity it belongs to, if any: brand, weight, type, packaging, and so on. Extracted attributes can be normalized, so an abbreviated type like “wheat crackers, abbr.” maps to the standard type “crackers”, and then matched against your structured catalogue.

4. Duplicate detection and cross-marketplace publishing

The machinery repeats: extract attributes, fuzzy-match against the master catalogue, decide whether this is a new product or a duplicate of an existing one. For publishing to external marketplaces, that step also normalizes to the target marketplace’s brand, type, and packaging vocabulary.

Stack

BERT-based encoder (we train and host the embedder). KNN with vector indices for retrieval. A custom QC layer for moderator workflows. Datapipe for incremental retraining as new data arrives. Grist or your platform for the editable reference catalogue. Inference is CPU-friendly. Training needs a GPU, but only periodically.

What You Need to Make This Work

Data. Historical pairs that map an input name to its correct category. Even 5-10k labeled examples is enough to bootstrap a reasonable pilot. More data and wider category coverage improve accuracy. If you have zero labeled data, the pilot adds a 2-4 week labelling sprint at the start.

Integrations. Your category tree as a structured taxonomy. Read access to your input feed (supplier API, ingestion DB, receipt stream). A write endpoint for classified results into your downstream system (PIM, marketplace listing system, fiscal database).

Hardware. Cloud or on-prem. CPU is fine for inference. GPU is needed for initial embedder training and periodic retraining (we can run this on our side if you prefer).

Team. A category-ops or data-ops lead who owns the reference catalogue going forward. A moderator pool (yours or ours) for the QC layer. Its size depends on volume and accuracy targets. A data engineer for the integration, about 20-40 hours during pilot.

Implementation Roadmap

1. Test (3-6 weeks)

Use your historical data plus a held-out validation set to measure baseline accuracy on the embedder and reference catalogue. Identify the categories where accuracy is weakest. Output: a written report with per-category accuracy, recommendations for reference-catalogue improvements, and a clear pilot scope.

2. Pilot (2-3 months)

Deploy to a slice of your live volume (one supplier, one category branch, or a percentage sample). Wire up the QC moderator workflow. Tune confidence thresholds for the right balance of automation and human review. Output: a working production deployment with measured accuracy and moderator throughput, and a go/no-go on full rollout.

3. Production (3-6 months)

Full volume. Continuous retraining as moderators correct errors (Datapipe handles incremental retraining without re-running the whole pipeline). Quarterly accuracy review. Your team owns the reference catalogue and the moderator workflow; we stay on for embedder retraining and edge cases.

Keep in Mind

Limits:

• ML accuracy is probabilistic. Even at 0.95 accuracy, 5% of items will be miscategorized. The QC layer carries that gap: it is how you turn 95% model accuracy into 99%+ production accuracy, with humans in the loop on exceptions.
• Your taxonomy quality is the ceiling. If two categories in your tree overlap heavily (think “Cosmetics” against “Body care”), the model will struggle exactly where humans do. Reorganizing the taxonomy is sometimes the fix that pays back most.
• Cold-start on new domains is real. A model trained on FMCG receipts will not transfer directly to industrial parts catalogues. New domains need their own labelled data, which is the slowest part of starting a new deployment.
• “Other / Unknown” is a feature. The model deliberately returns “low confidence” and holds back the guess. Aggressive thresholding kills accuracy. Conservative thresholding routes more to QC. The right setting is project-specific.
• Attribute extraction is fuzzier than categorization. Pulling “brand” from a name is easy when the brand is well-known and present. It is hard for generic items, regional brands, and items where the brand is implied. F1 on attribute extraction is typically 0.80-0.90, below the 0.95+ of category classification.

FAQ

How is this different from sending names to GPT-4?

Two issues with the GPT-4 approach. First, cost. At multi-million-per-day volumes, LLM API calls become a serious line item. Our embedder runs on CPU at thousands of items per second per core, so the cost is mostly compute, with no per-query API fees. Second, control. Categorization decisions need to be explainable and adjustable surgically. With a frozen embedder and an editable reference catalogue, you can fix specific mistakes without retraining anything. Raw LLM prompting does not give you that handle.

That said, LLMs are useful as a bootstrapping tool when you have no labeled data. We sometimes use GPT-4 to generate the initial reference catalogue, then run the embedder and KNN pipeline at scale.

Can this handle multiple languages?

Yes. The base embedder is multilingual: we ship variants trained on Russian and English, and other languages are added via fine-tuning. One product named in two languages maps close together in vector space.

What about brand-new SKUs we’ve never seen?

The whole point of an embedding-based approach is that brand-new product names work, as long as they are recognisably similar to something in the reference catalogue. The model may never have seen a specific “strawberry yoghurt, 200g” listing, yet it reads the words “yoghurt”, “strawberry”, and “200g” and maps the item to dairy or flavoured yoghurt. Confidence on truly novel items runs lower, and the QC layer is how you catch those.

How often does the embedder need retraining?

Less often than people expect. We retrain the embedder every 6-12 months on consolidated data. The reference catalogue gets updated continuously: moderator corrections flow back in via Datapipe. Most accuracy improvements come from reference-catalogue editing. Embedder retraining is the smaller lever.

Does this work for B2B / industrial catalogues?

Yes, with the caveat that B2B catalogues are often very different from consumer ones. The embedder needs to be fine-tuned on B2B data, a 4-8 week project at the start. Once fine-tuned, the architecture is identical to consumer use cases.

Ready to Discuss?

If you operate a marketplace, fiscal platform, or product data system at meaningful scale, and your categorization is a moderator-heavy bottleneck, this is a relevant conversation. We’ll look at your taxonomy, your incoming feed volume, and your current accuracy, then tell you whether the pipeline will move the needle for your specific case.

Discuss your project