I have an problem where the dataset consists of:

  • 400k observations
  • 40k classes (mutually exclusive)

60% of the observations belong to the top 4k classes.

The problem is about predicting what is the supplier of a bank transaction (from which supplier/shop a purchase was made) based on the description of the transaction sent by the bank.

As you can understand there are hundreds of thousands if not millions of suppliers in a country hence the so big number of (mutually exclusive) classes.

The dataset has only 4 datapoints:

  • Transaction id (eg 83883)
  • Buyer id (eg 33)
  • Bank description (eg "Payment EU Vodafone 04/11/21", " VDFN payment")
  • Supplier id/name (eg VODAFONE)

Each description consists of only few "technical" words; for example: "Payment EU Vodafone 04/11/21".

About 60%-70& of the descriptions contain the supplier name within them; however in some cases it could be a different form (eg VDFN instead of Vodafone).

How would you solve this problem?

Is ML, DL, general DS (eg similarity metrics) or a rule based way the best way to go for it?

  • 2
    $\begingroup$ ca you provide some example of the classes and why they are so many? Maybe another approach fits your case better than explicit classification $\endgroup$
    – Nikos M.
    Commented May 3, 2021 at 9:33
  • 1
    $\begingroup$ @NikosM. please see my updated post although not sure if this would change something to your answer. $\endgroup$
    – Outcast
    Commented May 4, 2021 at 9:24
  • 1
    $\begingroup$ If the problem is to find the supplier/shop name then can't we do OCR on the receipt image? I would assume that most shops will ha e their names righ on top of a payslip. I will be nice if you break your problem at state level probably, that should reduce the classes. $\endgroup$
    – Aditya
    Commented May 4, 2021 at 9:27
  • 1
    $\begingroup$ @Aditya OCR sounds good and I do it but after this you have to detect the supplier name (with ML) from the whole invoice text, hence this problem above. $\endgroup$
    – Outcast
    Commented May 4, 2021 at 9:30
  • $\begingroup$ Wouldnt the invoice contain some identification of the supplier (eg brand name, address, telephone, other uniquely identifiable items). I think this is an overengineering approach, maybe something simpler (like hinted above) can be way more helpful $\endgroup$
    – Nikos M.
    Commented May 4, 2021 at 15:55

2 Answers 2


There are many options to reduce the number of classes. Here are a couple:

  • Reframe it as a multi-label classification problem. The goal is to predict the presence or absence of a tag.
  • Group similar classes together into bins. Predict at the bin level.
  • Use hierarchical modeling. Create a series of nested groups.
  • Fit a model per supplier. Each supplier will only have a subset of classes.
  • $\begingroup$ Thank you for your interesting answer (upvoted). To be honest, I had already in mind all the solutions you suggest except for the first one. So you did not add much in a way but you did help me in understanding that I am not missing something. Two points: 1) In what way you suggest to possibly frame this in a multi-label problem? 2) Which approach of the above (or others) would you suggest as the best? I am asking this because for example each one of the (last 3) solutions above has its own big challenges and it could end up performing worse than eg a rule based approach. $\endgroup$
    – Outcast
    Commented Jan 31, 2022 at 21:14
  • $\begingroup$ For example, "Group similar classes together into bins. Predict at the bin level." will easily face the challenge of misgroupings etc. "Use hierarchical modeling. Create a series of nested groups." will easily lead to misclassification because of the multiple levels involved but also it will require too much maintenance since there will be multiple models. "Fit a model per supplier. Each supplier will only have a subset of classes." will also require a lot of maintenance beyond the fact that the supplier is what you want to predict $\endgroup$
    – Outcast
    Commented Jan 31, 2022 at 21:18
  • $\begingroup$ so fitting a model per supplier and calling each model in production for just one bank transaction is too "expensive". It could make sense to run a model per buyer (I also have the buyer id) and train a model on each buyer but still this has its problems. $\endgroup$
    – Outcast
    Commented Jan 31, 2022 at 21:20

Given data will keep increasing in the future along with the classes. You need to look at fast methods of doing things. Look at approximate KNN to do classification in high-volume data. Approximate KNN will solve your problem. Here's the library for it. Your accuracy will suffer a bit but this method would scale.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.