Skip to content

[8.19] [ML] Stabilize uncertain trend forecasts (#3189) - #3199

Open
valeriy42 wants to merge 1 commit into
elastic:8.19from
valeriy42:backport/8.19/pr-3189
Open

valeriy42 wants to merge 1 commit into
elastic:8.19from
valeriy42:backport/8.19/pr-3189

Conversation

@valeriy42

Copy link
Copy Markdown
Contributor

Backport

This will backport the following commits from main to 8.19:

Questions ?

Please refer to the Backport tool documentation

## Summary

Fixes elastic#2772, where an uncertain fitted trend could dominate a long forecast and produce implausible curvature, including values outside a percentage metric's natural range.

## Mathematical rationale

The trend component returns a polynomial regression prediction `f(x)` and its covariance-derived forecast variance.  Previously, a forecast evaluated the fitted polynomial directly at every future time.  This means a small but poorly determined quadratic coefficient is multiplied by `x^2`; over a long horizon that term can become much larger than the local signal even when the model is highly uncertain about it.  The existing prediction-horizon guard does not cover this case: the requested duration can be operationally reasonable while the selected trend is still statistically unreliable to extrapolate.

The fix keeps the model's near-term prediction but attenuates its *change from the first forecast point* according to the fraction of variance explained by the fitted trend:

```text
w(t) = V_trend / (V_trend + V_extrapolation(t))
y_fixed(t) = f(t0) + w(t) * (f(t) - f(t0))
```

Here `t0` is the first forecast time, `V_trend` is the component's long-term variance, and `V_extrapolation(t)` is the additional uncertainty incurred by projecting the fitted polynomial from the regression origin to `t`.  Thus `w(t)` is close to one when the trend is reliable, preserving the original prediction; it falls toward zero when extrapolation uncertainty dominates, smoothly anchoring the forecast at the boundary instead of allowing an uncertain high-order term to diverge.  This uses no new persisted state, settings, metric bounds, or customer-wide runtime cost.

The covariance calculation must use the regression basis.  The trend model is parameterized at its regression origin, so the variance of the change `f(t) - f(t0)` uses the basis delta:

```text
[0, t - t0, t^2 - t0^2]
```

Using `[1, t, t^2]` instead incorrectly includes the intercept and computes the variance of an absolute prediction rather than the extrapolated change.  This PR corrects that basis.

## Behaviour and coverage

- Exact zero extrapolation variance retains the original trend prediction (`w = 1`); this prevents a regression for deterministic affine trends.
- Invalid or negative numerical variances take the conservative anchored fallback.
- The forecast remains continuous at the first prediction point.
- Added tests cover the restored elastic#2772 state, prefix continuity, affine trends, and exact zero-uncertainty trends.

This targets the intended observability workload: ordinary trend forecasts remain unchanged when their extrapolation is well supported, while temporary changes and weakly identified curvature cannot dominate a long-horizon forecast.

(cherry picked from commit aca6006)

# Conflicts:
#	lib/maths/time_series/unittest/CTrendComponentTest.cc
@valeriy42 valeriy42 added :ml >bug backport ci:run-qa-tests Run a subset of the QA tests labels Sep 17, 2026
@valeriy42 valeriy42 removed the ci:run-qa-tests Run a subset of the QA tests label Sep 17, 2026
@valeriy42
valeriy42 enabled auto-merge (squash) September 17, 2026 11:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants