Inputs, Outputs, and Predictions

Goal

By the end of this lesson, you can follow one example from input to prediction, distinguish a model's prediction from the true label, and explain how code can run correctly while the prediction is still wrong.

Three things that sound similar but are not the same

When people first see a machine-learning program, several values can blur together:

• the information given to the model;
• the answer produced by the model;
• the answer we believe is correct.

Keeping those separate makes ML much easier to reason about.

For one example, think of the flow like this:

input -> predictor -> prediction

Then, when we are evaluating the predictor, we compare the prediction with the label.

A simple definition:

• Input: the feature information given to the predictor.
• Prediction: the output guess produced by the predictor.
• Label: the target answer used to judge that prediction.

The prediction and label can match. They can also disagree.

Follow one example carefully

Suppose our predictor uses this rule:

predict True when the input is at least 3.

Now look at this example:

Input	Prediction	True label	Correct?
3	True	False	No

Nothing is broken in the program.

The input really is 3.

The rule really says that 3 >= 3 should produce True.

The code follows the rule correctly.

But the label says False, so the prediction is wrong.

This distinction matters a lot:

A program can execute correctly and still make an incorrect prediction.

A software bug and a model error are not the same thing.

Why the label does not change when the prediction changes

Suppose we change the threshold from 3 to 4.

For input 3, the prediction changes:

• with threshold 3: prediction is True;
• with threshold 4: prediction is False.

But the true label stays False.

The label is evidence about the example. It should not automatically change just because our model changed its mind.

If predictions and labels always changed together, we would have no independent way to tell when a model was wrong.

A model is a function from inputs to outputs

Later, your models will become much more complicated. A model might receive:

• many numbers;
• an image;
• a sentence;
• thousands of tokens;
• audio samples;
• or several kinds of input at once.

Its output might be:

• a category;
• a number;
• probabilities;
• text;
• an image;
• or a tool action.

But the same tracing question remains useful:

What went in, what came out, and what evidence tells us whether the output was appropriate?

That question is one of the foundations of debugging AI systems.

Try the browser Lab

The Lab below contains five labeled examples and a threshold predictor.

1. Click Run without editing anything.
2. The Lab prints one dictionary for each example.
3. Find the row where input is 3.
4. Read these fields separately:
   • input
   • prediction
   • label
   • correct
5. With the starter threshold 3, input 3 should show prediction: True, label: False, and correct: False.

Loading lab…

Now make one controlled change:

1. Find:

threshold = 3

2. Change only 3 to 4.
3. Click Run again.
4. Find the row for input 3 again.
5. Notice that the prediction changes to False while the label remains False.
6. Also check input 4. It should still be predicted True because 4 >= 4.

The point is not that threshold 4 is universally better. The point is that you can trace exactly why each output changed.

A useful debugging order

When one prediction looks wrong, inspect the pieces in this order:

1. Input: Is the model receiving the value you think it is receiving?
2. Model setting: Which rule or parameter is being used?
3. Prediction: What did the model actually output?
4. Label: What answer are you comparing against?
5. Comparison: Why do they match or differ?

This is better than saying only, “The AI is wrong.” That sentence hides several different possible problems.

For example:

• the input could be wrong;
• the model could be using the wrong setting;
• the label could be wrong;
• or the model could simply be too limited for the pattern.

A common misconception

“If the code ran without an exception, the answer must be correct.”

Running without an exception means the computer was able to execute the instructions. It does not mean those instructions produce good predictions.

A calculator can correctly execute 2 + 2 even if you accidentally asked it the wrong question. A model can correctly execute its learned rule even when that rule does not fit a particular example.

Quick Check

1. What is a prediction?

The input measurement given to the modelThe model's output guess for an inputThe known target used to judge that guess

2. For input 3, you change the threshold from 3 to 4. Should its true label change too?

Only if the new threshold changes the model's predictionNo. The true label stays the same.Yes; changing the predictor changes which label counts as correct

3. The program runs successfully but prediction and label disagree. What does that show?

The predictor must be correct because the implementation ranCorrect execution does not guarantee a correct predictionThe label should be changed because the code executed without error

0 of 3 questions answered.

Key Takeaways

• Inputs are the information given to a predictor.
• Predictions are the predictor's outputs.
• Labels are target answers used for learning or evaluation.
• Prediction and label are intentionally separate.
• Code can run correctly while a model prediction is wrong.
• Tracing input -> setting -> prediction -> label is a powerful debugging habit.

Next Lesson

Now that you can identify exactly when a prediction disagrees with its label, the next Lesson will treat those disagreements as useful evidence instead of just calling them “mistakes.”

References

• Google for Developers, Introduction to Machine Learning.