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

Reason 1. The business doesn’t care

The primary and most vital reason is that the business doesn’t care! Your stakeholders will not be serious 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 possibly can 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 predominant goal of a machine learning model shouldn’t be to succeed in 100% accuracy. As a substitute, 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 in addition interpretability, computation speed, development costs, robustness, and training time under consideration. These aspects are necessary too and may be as relevant to business people as performance.

Besides yourself, there are other individuals who care a few complex model and state-of-the-art methods. Those persons are often researchers or data science colleagues. If you happen to work too closely with them as a substitute of with the business, you possibly can get to the purpose where you think modeling is the predominant 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 may be really necessary for business people.

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

The more time you spend on the model, the less time you’ve got for good engineering principles, similar to writing modular code, testing, architecture, logging, and monitoring. Setting these items up in a very good way originally saves plenty of time later. You possibly can easily add recent features to a solid codebase. That is more useful 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’ll see the predictions make sense.

Especially to start with, give attention to 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 possibly can 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 may 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 plenty of time. The complex model is that last hard-to-reach 20% that takes 80% of the trouble. Before you begin, persuade yourself it’s value 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 so far, and fewer time adding recent features or improving the product. A straightforward project, however, requires less maintenance, which implies that you could spend more time iterating on the MVP and adding recent features to enhance the product.

A vital thought to be mindful is that the most effective solution is commonly the only solution that matches the necessities. This could assist you determine if that deep learning state-of-the-art model is actually definitely 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 unravel a scheduling problem with reinforcement learning. It was quite complex, and we were progressing slowly. The business became a bit annoyed and upset because we couldn’t show good results. After 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.