Why shouldn’t the main focus of a project be on using complex techniques? For my part there are three important reasons, which I’ll explain here.

Reason 1. The business doesn’t care

The primary and most significant reason is that the business doesn’t care! Your stakeholders should not excited about the technical details of your model. Whether you used boosted trees or a neural network, to them, it’s all the identical. What they need to know is how your model helps them achieve their business goals. If the model must be retrained often, you’ll be able to justify your decision to make use of a straightforward model like logistic regression over a neural network since it’s super fast to coach.

Often, the important goal of a machine learning model is just not to succeed in 100% accuracy. As an alternative, a machine learning model helps with business processes. Spending an excessive amount of time optimizing the model will delay the time it takes to deliver a working product to the market. It’s higher to create an MVP, ensure it meets the business requirements, and get it into production. It’s essential to take not only performance but additionally interpretability, computation speed, development costs, robustness, and training time into consideration. These aspects are necessary too and will be as relevant to business people as performance.

Besides yourself, there are other individuals who care a couple of complex model and state-of-the-art methods. Those persons are often researchers or data science colleagues. Should you work too closely with them as a substitute of with the business, you’ll be able to get to the purpose where you think modeling is the important goal. To beat this, attempt to work closer with business people. Demo your product after every recent feature implementation and ask the business in case your assumptions are correct. Decisions that appear small will be really necessary for business people.

Reason 2. A posh model adds less value than a working MVP

The more time you spend on the model, the less time you could have for good engineering principles, resembling writing modular code, testing, architecture, logging, and monitoring. Setting this stuff up in a very good way at first saves loads of time later. You possibly can easily add recent features to a solid codebase. That is more helpful than having a posh model in a Jupyter Notebook that performs barely higher but doesn’t run in production. One other good thing about a straightforward model is interpretability, which may help persuade stakeholders because they will see the predictions make sense.

Especially at first, deal with making a product that works and has robust code and a well-crafted CI/CD pipeline. This makes it easier to enhance the answer in a while. If the business doesn’t feel the urge to enhance the present solution, you’ll be able to move on to a different project. You didn’t waste your time making a ‘perfect’ model.

What pertains to that is the Pareto principle. It’s a rule that states that 80% of results will be achieved through 20% of our efforts (aka the 80/20 rule). Often, creating a posh model that performs barely higher than a straightforward model doesn’t fall into the 80% of the outcomes but is a task that is difficult and takes loads of time. The complex model is that last hard-to-reach 20% that takes 80% of the hassle. Before you begin, persuade yourself it’s price it.

Reason 3. Complex projects require more maintenance

The more complex the project, the more resources and time are needed to keep up it. Because of this you’ll spend more time fixing bugs, optimizing the model, keeping the info up to this point, and fewer time adding recent features or improving the product. A straightforward project, however, requires less maintenance, which implies which you can spend more time iterating on the MVP and adding recent features to enhance the product.

A crucial thought to take into account is that the very best solution is commonly the only solution that matches the necessities. This will assist you determine if that deep learning state-of-the-art model is really well worth the extra work that comes with it! If there are two models that perform equally well, and one is easy and the opposite is complex, go together with the easy one.

One example from my work at an organization: I attempted to resolve a scheduling problem with reinforcement learning. It was quite complex, and we were progressing slowly. The business became a bit annoyed and dissatisfied because we couldn’t show good results. Once we switched our solution method to (good old) mathematical optimization, it went much faster! It was less interesting, but we gained the trust of the business and will implement recent features and constraints easily.