[ad_1]
Why shouldn’t the project focus on using complex techniques? In my opinion, there are three main reasons, which I will explain here.
Reason 1. Business doesn’t care
The first and most important reason is that businesses don’t care! Your stakeholders are not interested in the technical details of your model. Whether you used boosted trees or a neural network, it’s all the same to them. What they want to know is how your model helps them achieve their business goals. If the model needs to be retrained frequently, you can justify your decision to use a simple model such as logistic regression in a neural network because it is very fast to train.
Often, the main goal of a machine learning model is not to achieve 100% accuracy. Instead, the machine learning model helps business processes. Spending too much time optimizing the model will delay the time to market of the working product. It’s best to create an MVP, make sure it meets business requirements, and take it to production. It is necessary to consider not only performance, but also interpretation, computation speed, development costs, robustness and training time. These factors are also important and can be as relevant to business people as performance.
Besides you, there are other people who care about the complex model and modern methods. These people are often researchers or data science colleagues. If you work very closely with them instead of the business, you can get to the point where you think modeling is the main goal. To overcome this, try to work more closely with business people. Demo your product after each new feature is introduced and ask the business if your assumptions are correct. Decisions that seem small to us can be really important to business people.
Reason 2. A complex model adds less value than a working MVP
The more time you spend on the model, the less time you have for good engineering principles like writing modular code, testing, architecture, logging, and monitoring. Getting these things right from the start will save a lot of time later. You can easily add new features to the hardcode base. This is more valuable than having a complex model in a Jupyter Notebook that works slightly better but doesn’t work in production. Another benefit of a simple model is interpretability, which can help convince stakeholders because they can see the predictions make sense.
Especially in the beginning, focus on building a product that works and has strong code and a well-designed CI/CD pipeline. This makes it easier to further improve the solution. If the business does not feel the need to improve the existing solution, you can move on to another project. You won’t spend time creating the “perfect” model.
What this relates to is the Pareto principle. This is the rule that says that 80% of the results can be achieved with 20% of our efforts (aka the 80/20 rule). Often creating a complex model that performs slightly better than a simple model is not included in 80% of the results, but it is a difficult and time-consuming task. A hard model is the last hard-to-reach 20% that requires 80% of the effort. Before you start, make sure it’s worth it.
Reason 3. Complex projects require more maintenance
The more complex the project, the more resources and time it takes to maintain it. This means you spend more time fixing bugs, optimizing your model, keeping data up-to-date, and less time adding new features or improving your product. On the other hand, a simple project requires less maintenance, which means you can spend more time iterating on the MVP and adding new features to improve the product.
An important point to keep in mind is that the best solution is often the simplest solution that fits the requirements. This will help you determine if the latest deep learning model is worth the extra work that comes with it! If there are two models that work equally well, and one is simple and the other is complex, go with the simple one.
An example from my work in a company: I tried to solve a planning problem with reinforcement learning. It was quite difficult and we were going slowly. The business became a bit irritated and disappointed because we did not show good results. When we switched the solution method to (good old) mathematical optimization, it went much faster! It was less exciting, but we gained the trust of the business and could easily implement new features and restrictions.
[ad_2]
Source link
