Recommended resources
The freely available resources this lesson will direct you to.
Hello. This course will move from the foundations of machine learning to building, evaluating, and operating AI systems. The first step is deciding what a system should actually accomplish. A well-framed problem gives you a way to judge whether AI is useful before you choose a model or write code.
In this lesson, you’ll specify four things: the information available as input, the output you want from a model, the decision someone or something will make with that output, and a measurable success criterion. We’ll use a support-request example throughout. Allow about 40 minutes, including the readings.
Start with the outcome, not the technology
Suppose a team says, “We want AI to handle support requests.” That describes a proposed technology, but not the problem. Does the team want faster replies, fewer requests sent to the wrong queue, or answers that solve more problems on the first attempt? Each goal could call for a different system—or no AI at all.
A better starting statement is: “Reduce the time it takes customers to receive a helpful first response, without delaying urgent requests.” It describes a result that matters outside the model. You can now ask what currently causes delays and whether a simpler change, such as clearer routing rules, might help.
Understand the problem | Machine Learning - Google for Developers
Read Google for Developers’ “Understand the problem” to see how a product goal is stated before choosing an ML approach.
In “State the goal,” begin with the goal examples and notice that they describe tasks rather than model types. Then, in “Clear use case for ML,” read the comparison through the advice to try a non-ML heuristic. Focus on why an existing process or simple rule is a useful point of comparison.
For our example, the existing process might send every new request to a first-in, first-out queue. That is a baseline: a way of handling the problem against which a proposed system can be compared. We are not yet claiming that AI will improve it. The baseline makes the claim testable.
Specify what is known when the decision is made
An input is the information the system can use for a particular request. Timing matters. If the system must route a request when it arrives, it could use the request’s initial text and the product area selected on the form. It cannot use the eventual resolution or an agent’s later notes: those do not exist at routing time.
For predictive ML, examples used to develop a model also need a target, often called a label: the answer the model is intended to learn to predict. In this case, reviewers might examine past requests and label which ones required urgent human attention. Those later judgments can help evaluate or train a system; they are not inputs available when a new request arrives.
Understand the problem | Machine Learning - Google for Developers
Return to “Understand the problem” for its data requirements. They provide a practical check on whether a proposed input is usable.
In “Predictive ML and data,” read the data requirements. Pay particular attention to “Available” and “Representative”: can you obtain each input at the moment of use, and do your past examples resemble the requests the system will encounter?
Our input specification can now be precise: for each newly submitted support request, use its initial text and selected product area, as received at submission time. If either field is often missing or unreliable, the design needs to account for that rather than quietly assuming perfect data. Specifying the moment of use will also matter later when you build datasets without using information from the future.
Separate the model’s output from the decision
A model’s output is not necessarily what a user sees, and it is not necessarily the final action. For the support example, one possible output is a classification: “urgent human attention needed” or “standard handling.” Another design might generate a draft reply. These are different tasks with different requirements.
The classification has a narrower role. The application could put requests classified as urgent into a priority human queue. It could put other requests into the standard queue and offer relevant self-service material, while preserving a way to reach a person. The classification is the model’s output; the routing choice is the application’s decision. Humans and product rules can remain part of that decision.
Framing an ML problem | Machine Learning
Read Google for Developers’ “Framing an ML problem” to connect an ideal outcome to a model goal and to distinguish classifications, numerical predictions, and generated content.
In “Define the ideal outcome and the model’s goal,” read the comparison table. Then, in “Identify the output you need,” continue through “Classification” and “Regression”: read the output discussion. Stop before the detailed video-caching scenario. Notice how an output can inform a decision without being the decision itself.
The image below makes that distinction for a numerical output. A model could predict a number, while the application assigns different decisions to different ranges. A category prediction could likewise be mapped to an action. The useful question is not merely “What can the model predict?” but “What action will change because of its prediction?”
Understand the problem | Machine Learning - Google for Developers
Read the short “Predictions vs. actions” subsection to reinforce the distinction between producing an output and helping someone.
Under “Predictions vs. actions,” read the action examples. Stop before “Check Your Understanding,” and identify what the product does with each prediction.
If the team instead chooses a generated reply, the frame must change: specify what material the generator may use, what a useful draft must contain, and who checks it before it is sent. “Use generative AI” is not, by itself, an output specification.
Make success observable
A model could accurately reproduce past urgency labels yet fail to improve support. Perhaps urgent requests reach the priority queue but still wait too long for an agent. Conversely, a faster automated acknowledgement might look good on a response-time dashboard without answering anyone’s question.
This is why model evaluation and product success are related but distinct. Model evaluation asks how well an output matches an expected answer—for example, how often the classifier identifies reviewer-confirmed urgent requests. Product success asks whether the resulting workflow helps people. Sometimes even the expected answer is only a proxy: something observable that stands in for what you truly care about.
Framing an ML problem | Machine Learning
Finish with the parts of “Framing an ML problem” that distinguish an imperfect training label from a real-world success measure.
In “Proxy labels,” read the proxy examples; note why clicks or likes need not mean a video was useful. Then, in “Define the success metrics,” read the success guidance. Focus on the difference between a model metric and a measured change in the product.
Here is a complete, illustrative frame. The numbers are proposed targets, not evidence that an AI system can achieve them:
- Desired outcome: Customers receive a helpful first response sooner, without urgent requests being delayed.
- Input: A request’s initial text and selected product area, available when it is submitted.
- Desired model output: A classification of “urgent human attention needed” or “standard handling.”
- Decision: Route classified-urgent requests to a priority human queue; route others to the standard process, with a way to request human help.
- Measurable success criterion: Over four weeks, reduce the median time to a helpful first response by at least 15% compared with the existing routing process, while at least 95% of requests independently identified as urgent reach the priority queue within two hours.
The last line needs an operational definition. “Helpful” could be assessed from a sample of responses using a consistent review rubric; “urgent” should be judged independently of the model’s own classification. The comparison should cover similar types of requests in both processes. If the team cannot measure those things credibly, it should revise the criterion before claiming success.
Notice that this frame leaves room for a useful answer of “don’t use AI.” If a simple rule meets the same targets with less cost and maintenance, it solves the stated problem.
Where this leads
A strong AI problem frame connects a real-world outcome to information available at the right time, a clearly defined model output, an action that uses it, and a success measure that can be checked against the current approach. Keeping those parts separate prevents an impressive prediction from being mistaken for a useful system.
Next, you’ll examine the shapes of vectors and matrices in a simple model computation. That technical work will be easier to place in context: a model is one component inside the larger problem you have just learned to define.