Linear Regression: Where Did That Prediction Come From?

The restaurant is four kilometres away and Zomato says your food will arrive in 20 minutes. Where did that 20 come from?

Maybe the system knows about traffic, the restaurant's queue, and the delivery partner's location. But suppose we have just one piece of information: distance.

Could that alone give us a useful estimate?

Let's try it with five deliveries. Once we understand the idea, we'll use the same reasoning for a different wait: an LLM generating an answer.

1. What can five deliveries tell us?

Here is what we recorded:

1 km → 12 minutes
2 km → 13 minutes
3 km → 17 minutes
4 km → 19 minutes
5 km → 24 minutes

Distance gives us a useful clue

Loading chart… Data is available below.

View chart data

Distance gives us a useful clue

distanceKm	Observed delivery time ( min)
1	12
2	13
3	17
4	19
5	24

Longer trips took longer. But the increases were uneven: one extra minute between the first two trips, then four, then two, then five.

So distance seems useful, but it does not explain everything. That feels reasonable. A traffic light has very little interest in keeping our dataset tidy.

We want a rule that captures the broad pattern without pretending every delivery behaves identically.

2. A starting time, plus a little more per kilometre

One possible rule is:

predicted time
= starting time
+ time added per kilometre × distance

Try a starting time of eight minutes and three extra minutes per kilometre:

1 km → 8 + 3 × 1 = 11 minutes
2 km → 8 + 3 × 2 = 14 minutes
3 km → 8 + 3 × 3 = 17 minutes

Each extra kilometre adds the same amount. Plot those predictions and you get a straight line.

The starting height is called the intercept. The amount added for each extra unit of distance is the slope. Finding those two numbers from examples is what we're doing here with simple linear regression.

Now the usual notation has somewhere to land:

ŷ = β₀ + β₁x

x  = distance
ŷ  = predicted time
β₀ = intercept, here 8 minutes
β₁ = slope, here 3 minutes per kilometre

That little hat over y means “predicted.” The actual delivery time can be different.

What does this rule predict for the four-kilometre restaurant?

20 minutes. That's 8 + 3 × 4. The trip in our table took 19 minutes, so this prediction is one minute too high.

It is tempting to call the eight-minute intercept “preparation time.” It could reflect something like that, but we have not measured preparation separately. We do not even have a zero-kilometre delivery. A plausible interpretation is still an interpretation.

3. But why this particular line?

Why eight and three? Why not eight and four?

Or why not skip distance entirely and predict 17 minutes for everyone? That is the average of our five delivery times. It is a perfectly reasonable baseline to beat.

Three rules, three sets of predictions

Loading chart… Data is available below.

View chart data

Three rules, three sets of predictions

distanceKm	Always 17 minutes ( min)	8 + 3 × distance ( min)	8 + 4 × distance ( min)
1	17	11	12
2	17	14	16
3	17	17	20
4	17	20	24
5	17	23	28

At five kilometres, the flat rule predicts 17 minutes, the green line predicts 23, and the steeper line predicts 28. Reality, in our little dataset, was 24.

The green line wins that round. But choosing a model based on one convenient example would be a fairly generous marking scheme.

We need to score all five predictions.

4. Give every mistake a number

Take what actually happened and subtract what the line predicted:

observed − predicted = residual

That difference is called a residual. It tells us how far the fitted line misses an observation, including the direction of the miss.

At one kilometre, we observed 12 minutes and predicted 11. The residual is +1: the delivery was slower than expected. At two kilometres, it is 13 − 14 = −1: faster than expected.

The line's mistakes, one trip at a time

Loading chart… Data is available below.

View chart data

The line's mistakes, one trip at a time

distanceKm	Observed minus predicted ( min)
1	1
2	-1
3	0
4	-1
5	1

Now add those mistakes:

+1 − 1 + 0 − 1 + 1 = 0

Zero total error. Four wrong predictions. Clearly, adding signed mistakes is letting them cancel each other out.

We need a score that keeps track of their size.

5. Why square the errors?

One option is to square each mistake before adding:

1² + (−1)² + 0² + (−1)² + 1² = 4

Both +1 and −1 now contribute one. A four-minute miss contributes 16. So squaring does two jobs: it prevents cancellation and makes big mistakes disproportionately expensive.

The rule is then: choose the intercept and slope with the smallest total squared error. That method is called ordinary least squares. NIST's least-squares guide gives the objective and the straight-line solution.

Does distance beat guessing the average?

Loading chart… Data is available below.

View chart data

Does distance beat guessing the average?

model	Sum of squared errors
Fitted	4
Steep	59
Flat	94

Our 8 + 3 × distance line scores four. It is the best of these three, and the least-squares solution among all possible straight lines for these observations.

But squaring is a choice. We could instead add absolute errors: turn −1 into 1 without squaring. That also prevents cancellation and is less dominated by a single huge miss. Optimizing that score is a different fitting method and can produce a different line.

Squared error has a convenient mathematical shape: for this problem, the score forms a convex bowl as we vary the slope and intercept. With distances that are not all identical, there is one bottom. We can solve for it directly; we do not need to guess lines forever.

Show me how the calculation finds 8 and 3

The average distance is 3 km. The average time is 17 minutes. Subtract those averages from each observation:

distance differences: −2, −1, 0, 1, 2

time differences: −5, −4, 0, 2, 7

Multiply matching differences and add: 10 + 4 + 0 + 2 + 14 = 30. Square the distance differences and add: 4 + 1 + 0 + 1 + 4 = 10.

slope = 30 / 10 = 3

intercept = average time − slope × average distance = 17 − 3 × 3 = 8

If every recorded distance were identical, the denominator would be zero. Those observations could tell us about time at that distance, but not how time changes with distance.

That is what the model learned: two numbers chosen to minimize a particular definition of “wrong.”

6. Make a prediction. Then ask how far we wandered

A restaurant 3.5 kilometres away gives us:

8 + 3 × 3.5 = 18.5 minutes

We did not record that exact distance, but it sits between distances we did record. This is interpolation.

What happens if the restaurant is 30 kilometres away?

The line predicts 98 minutes: 8 + 3 × 30. It will happily do that calculation even though our data only covers 1–5 kilometres.

Now we are extrapolating: going outside the range we observed. A 30-kilometre trip could involve highways, different delivery arrangements, or a completely different relationship between distance and time.

The maths still works. Whether the prediction does is another question. Extrapolation is one of the limitations highlighted in NIST's overview of linear regression.

Even the 3.5-kilometre estimate is not guaranteed. Staying inside the range removes one reason for concern; it does not remove traffic.

7. An error of 0.8 minutes sounds excellent

Let's report a score in minutes instead of squared minutes. Take the size of each miss and average it:

mean absolute error = (1 + 1 + 0 + 1 + 1) / 5
                    = 0.8 minutes

That is MAE, or mean absolute error. We fitted using squared error, but we can still evaluate the result using a metric that is easier to interpret.

Less than a minute off, on average. Pretty good.

But we measured it on the same five examples used to choose the line. And I made those examples deliberately tidy. Neither detail belongs in the footnotes of a performance claim.

To find out whether the model is useful, fit it on one set of trips and evaluate it on trips it has not seen. For tomorrow's deliveries, a test set from a later period is a useful way to mimic the actual task. Do not use those test outcomes to keep adjusting the line and still call them an untouched test.

This distinction between training and test error is fundamental to evaluating predictions; see An Introduction to Statistical Learning, Chapter 2.

8. One strange trip can move the whole line

Suppose the five-kilometre delivery took 44 minutes instead of 24. Perhaps the rider got stuck. Perhaps someone typed the number incorrectly.

Against our original line, that trip's miss jumps from one minute to 21 minutes. Its contribution to squared error jumps from 1 to 441.

Refit using that changed observation and the equation becomes:

predicted time = 0 + 7 × distance

One changed row moves the slope from three to seven. The new line predicts seven minutes at one kilometre, even though that observation is still 12.

One changed observation pulls the fitted line

Loading chart… Data is available below.

View chart data

One changed observation pulls the fitted line

distanceKm	Original fit: 8 + 3 × distance ( min)	Changed observation: 7 × distance ( min)
1	11	7
2	14	14
3	17	21
4	20	28
5	23	35

That is the other side of making large errors expensive. Least squares tries hard to accommodate them. NIST notes this sensitivity to unusual observations.

The response should start with investigation. Correct a verified data-entry error. Keep a genuine difficult trip in the picture when deciding what the system must handle. Deleting an inconvenient observation because it spoils the chart is not model improvement.

Also inspect the shape of the residuals. A curve can suggest the straight-line relationship is missing something. An expanding spread can suggest predictions become less precise as distance grows. Five trips are enough for this arithmetic, but too few for confident diagnostics.

9. Same idea, different wait: LLM latency

Now replace kilometres with generated tokens, and delivery minutes with response milliseconds.

Suppose we record output length and elapsed time until the full response completes. Keep the model and serving setup fixed, and use requests with similar input lengths. Here is another fictional dataset:

100 output tokens →  850 ms
200 output tokens → 1150 ms
300 output tokens → 1600 ms
400 output tokens → 1950 ms
500 output tokens → 2450 ms

The same calculation gives:

predicted completion time = 400 + 4 × output tokens

Can output length help estimate completion time?

Loading chart… Data is available below.

View chart data

Can output length help estimate completion time?

outputTokens	Observed completion time ( ms)	Fitted completion time ( ms)
100	850	800
200	1150	1200
300	1600	1600
400	1950	2000
500	2450	2400

At 300 tokens, the prediction is 400 + 4 × 300 = 1,600 ms. The fitted slope says that one additional output token is associated with four additional milliseconds in these examples.

It does not prove that the hardware spends exactly four milliseconds on every token. The intercept is not a measured breakdown of network and processing overhead either. We fitted a relationship, not a profiler trace.

A 350-token answer would take how long under this model?

1,800 ms, or 1.8 seconds: 400 + 4 × 350. That is within the observed output-length range, but still depends on the serving conditions remaining comparable.

There is also a practical catch: before generating an answer, we usually do not know its final token count. This model can help analyze completed requests or estimate time for an assumed output budget. An exact prediction made using the eventual output length is using information we would not have at request arrival.

That distinction matters if someone presents it as a live ETA system.

10. But does the relationship survive production?

Suppose the fit came from quiet periods. Now requests queue behind other work. Two answers with the same output length can have very different total completion times.

Or we change the model, hardware, input lengths, or serving configuration. The line might need to change too. Our five synthetic observations establish nothing about those cases.

We could record additional inputs and fit multiple linear regression:

predicted completion time
= intercept
+ output-length coefficient × output tokens
+ input-length coefficient × input tokens
+ queue coefficient × queue depth at arrival

This is a candidate model to test, not a claim that queue behaviour is linear. Adding columns cannot make an unsuitable relationship suitable. We also need enough varied observations to estimate their effects, and each input must be available when we intend to make the prediction.

For a real evaluation, I would compare the model with a simple baseline on later requests, inspect errors across output lengths and load levels, and check the slow requests separately. An average error can look comfortable while the people waiting longest get terrible estimates.

And prediction still is not causation. If longer answers tend to come from harder requests, output length may be mixed up with other sources of delay. A fitted coefficient alone does not establish what would happen if we intervened and changed only one variable. Chapter 3 of An Introduction to Statistical Learning develops these questions of regression interpretation and model checking.

11. What is worth keeping in your head?

A line is a compact rule: start here, then add this much for each extra unit of input. Least squares chooses that rule by minimizing squared mistakes on the examples we give it.

Everything useful comes after asking what those examples represent. Which range did we observe? What information was available at prediction time? What changed between fitting and using the model?

The next time an app promises food in 20 minutes, or an AI product promises an answer in two seconds, the number is only the beginning.

What taught the system to expect that wait—and does the same relationship still hold when tomorrow's traffic, tokens, or queues look different?

Sources and further reading3 references

1. Least SquaresNIST/SEMATECH e-Handbook of Statistical Methods

   Least-squares objective and the formulas for a straight-line slope and intercept.

2. Linear Least Squares RegressionNIST/SEMATECH e-Handbook of Statistical Methods

   Model definition, extrapolation limitations, and sensitivity to unusual observations.

3. An Introduction to Statistical Learning, second editionGareth James, Daniela Witten, Trevor Hastie, and Robert Tibshirani

   Chapter 2 covers training and test error; Chapter 3 develops linear regression and its interpretation.