In an earlier video, I mentioned that you don't need to be a machine learning expert to understand how it works, or where to use it. Having the right vocabulary and project framework will be key to your success when applying machine learning in your organization. You've already learned a few of the key terms. Let's now talk about the phases of a machine learning project. The first phase begins by assessing the problem. Next is collecting and preparing the data. These are the input examples. Then training an ML model using pre-selected metrics and objectives. Then evaluating and validating the model. Finally, deploying the model when it's ready. Let's start with the first one. What type of business challenge or problem is right for ML? To do this, I'm going to teach you how to use a tool. It's a simple way to plot a business challenge along two axes. The first axis describes the difficulty level of the ML use case ranging from simple to impossible. You want your ML use case to be challenging but not impossible. That's the sweet spot. Now, brainstorm a few ML use case in the form of three questions. I'll use a manufacturing company to demonstrate this. The first question might be, how could we produce perfect products each time? Two, how could we predict whether our assembly line is moving? Three, how could we reduce the number of accidents on our factory floor? For each question, ask yourself, is this a simple problem impossible to solve, or somewhere in the middle? Take a moment to do this exercise yourself. What would you guess is a difficulty level for each question? You might have noticed that the first question or ML problem is nearly impossible to solve. There will always be some defects. By contrast, the second question or ML problem is too simple, plus it doesn't add value to the business. That leaves us with the third question. How could we reduce the number of accidents on our factory floor? This one is just right. The second factor in the assessing an ML use case is specificity. As with difficulty, there's a sweet spot between too specific and too open or ambiguous that allows you to establish a clear vision but not get derailed by details. Let's use a manufacturing company and the same question format for potential ML use cases to demonstrate this. Here are a few ideas in question form. One, how could we have no safety violations in our company? Two, how could we reduce accidents caused by operator negligence? Third, I will repeat this one, how could we reduce the number of accidents on our factory floor? Again, for each question, ask yourself, where does the problem fall on the axis? Too specific, ambiguous, or somewhere in the between. Take a moment to assess each question yourself. The first question is very open and therefore ambiguous. Companies might have many different types of safety violations and are qualitatively different from each other. So this one will work. The second question is on the other end of the spectrum. It's too narrow and specific, because it focuses on poor choices made by one type of individual. Surely there are other kinds of accidents too. But how could we reduce the number of accidents on our factory floor, is again, just right. Now remember, even though we examined each ML question separately on either to difficulty or specificity access, each time you write an ML problem, you'll want to assess it along both axes to find the sweet spot. We'll practice with a few real-world examples in the next video.
