[ENH] Add `_reset` parameter to `set_params` in skbase

[SimonBlanke]

Problem

set_params in skbase unconditionally calls self.reset() after setting new parameter values (line 389 in skbase/base/_base.py). The reset() method deletes all instance attributes and re-runs __init__, which destroys any pretrained state including model weights, the _state flag, and the _pretrained_attrs list. This makes the natural workflow of "pretrain a model, adjust hyperparameters for fine-tuning, then continue training" impossible.
The reset() call exists to ensure consistency between parameter values and derived state. In the general case this is correct: if you change a parameter that influenced how __init__ set up internal structures, those structures need rebuilding. But for the fine-tuning (pretraining) use case, the user explicitly wants to keep the derived state (the pretrained network weights) and only change parameters that affect the next training iteration, such as learning rate, batch size, or number of epochs. These parameters are consumed only when training resumes and don't invalidate existing weights.

Proposed Solution

Add a _reset parameter (default True) to set_params in skbase/base/_base.py. When _reset=False, parameter values are set via setattr as usual, but reset() is not called, so all instance state (including pretrained attributes) survives. The parameter propagates through nested component calls so that pipeline.set_params(forecaster__lr=0.001, _reset=False) preserves state at every level.

Design Decisions

User takes responsibility. We deliberately do not validate which parameters are safe to change without reset. Building a validation layer for "finetuning-compatible parameters" would require per-estimator annotation of every parameter and still could not cover value-dependent cases (some parameters are safe to change to certain values but not others, e.g. increasing num_epochs is fine but changing context_length breaks weight dimensions). If a user changes a structural parameter without reset and the model can't handle it, it will fail at the next training or prediction call with a clear error (typically a tensor shape mismatch). This "when it fails, it fails" approach avoids a complex validation system that would be incomplete by nature and burdensome to maintain.

Underscore prefix on _reset. The parameter uses _reset rather than reset to avoid collision with estimator parameters that might be named reset. The underscore prefix also signals "use with care" to the user, which aligns with the responsibility model described above. We could also use a more specific model_reset.

Propagation to nested components. When called on a composite estimator, _reset=False propagates through all nested set_params calls. This is essential for the pipeline use case where a user wants to adjust a finetuning parameter on a nested pretrained component without triggering resets anywhere in the hierarchy.

Example Usage

# Pretrain, adjust LR, continue training
model = TTMForecaster(model_path="ibm/TTM", learning_rate=1e-3)
model.pretrain(X=X_panel, y=y_panel)
model.set_params(learning_rate=1e-4, num_epochs=5, _reset=False)
model.pretrain(X=X_panel2, y=y_panel2)  # continues with lower LR, weights preserved

# Inside a pipeline
pipe = make_pipeline(StandardScaler(), TTMForecaster(...))
pipe.pretrain(X=X_panel, y=y_panel)
pipe.set_params(ttmforecaster__learning_rate=1e-4, _reset=False)
pipe.fit(X=X_test, y=y_test)  # fine-tunes pretrained model on target

What Happens on Misuse

When a user changes a structural parameter without resetting, the stored network has architecture expectations (input dimensions, layer counts, embedding sizes) that no longer match the new configuration. The next training or prediction call will fail with an explicit error from the underlying framework (PyTorch dimension mismatch, shape error, etc.). This is acceptable and expected. The user changed the model's structural identity while keeping its old weights; the inconsistency surfaces immediately.

model.pretrain(X=X_panel, y=y_panel)
model.set_params(context_length=1024, _reset=False)  # structural change
model.pretrain(X=X_panel2, y=y_panel2)
# RuntimeError: mat1 and mat2 shapes cannot be multiplied (512x64 and 1024x64)

Acceptance Criteria

set_params(_reset=False, **params) should set parameter values without calling reset(). Pretrained state (model weights, _state, _pretrained_attrs) must survive a set_params(_reset=False) call. Calling set_params() without specifying _reset must behave exactly as before (full backward compatibility, _reset=True is the default). Nested set_params on composite estimators must propagate _reset to component estimators.

Part of

Tracking issue: sktime/sktime/issues/10151

[Deep-Axe]

also worth considering alongside the reset() parameter

The BaseObject.reset docstring in skbase/base/_base.py currently promises that reset is:

"Equivalent to clone, with the exception that reset mutates self instead of returning a new object."

However, this equivalence is currently broken for pretrained models. In sktime, clone() is now aware of pretrained state (via the _PretrainedCloner plugin in sktime/forecasting/base/_clone_plugin.py), whereas reset() in skbase remains a "dumb" operation that blindly deletes all instance attributes. This means clone() preserves pretrained weights but reset() destroys them, violating the documented contract.

We could have:

1. Generalized reset() protection: Modify reset() to respect an optional list of "protected" attributes (e.g., _reset_protected_attrs). This allows sktime to declare its pretrained attributes for protection without skbase needing any specific knowledge of pretraining semantics to restore the clone()/reset() equivalence and makes the framework "safe by default."

2. and then also the explicit _reset parameter: Add the _reset parameter to set_params to cover the case where a user wants to update parameters without triggering an __init__ re-run at all.

It ensures that even if a composite object or a tuning wrapper in sktime (like sktime/forecasting/model_selection/_base.py) misses the _reset=False flag, the model's foundation weights remain protected.

[fkiraly]

@Deep-Axe, agree! This echoes my comments in sktime/sktime#10151, where I also say the contracts of clone and reset must be equal up to object identity.

The list of tags that I propose is, design-wise equivalent to your protected attributes idea.

Though I would first introduce overrides in sktime before modifying scikit-base, to ensure we do not have to do parallel development with multiple bugfixes or changes in scikit-base caused by moving requirements of sktime.

[fkiraly]

(also, @Deep-Axe, I think chainflow is impressive. Would be super interested to hear about your plans - do you have time for a phone call in the coming weeks? fkiraly at gcos dot ai . Btw, the name choice is problematic, could be trademark infringement on the crypto company of the same name)

[Deep-Axe]

Understood, @fkiraly.

From sktime/sktime#10151

• and by super careful I mean not handwaving and optimistic thinking, but working it out in a written design document that analyzes how states change

Happy to draft the design document

I wanted to clarify, Should the tag explicitly list the internal state attributes that must survive a reset() (e.g., weights stored in _pretrained_attrs), or should it list the __init__ parameters that are 'safe' to change via set_params() without triggering a reset? Or perhaps both?

(also, @Deep-Axe, I think chainflow is impressive. Would be super interested to hear about your plans - do you have
time for a phone call in the coming weeks?)

Thank you very much! I'm really glad you like it. I'll send over an email shortly to schedule a time.

[fkiraly]

I wanted to clarify, Should the tag explicitly list the internal state attributes that must survive a reset() (e.g., weights stored in _pretrained_attrs), or should it list the __init__ parameters that are 'safe' to change via set_params() without triggering a reset? Or perhaps both?

I meant the first, attribute names that survive a reset.

Can you give more explanation about why the second would make sense?

[Deep-Axe]

Its primarily about preventing a 'recursive cloning cascade' in composite models.
For example, In ForecastingPipeline, __init__ calls _check_steps, which calls _get_estimator_tuples(clone_ests=True), which runs _safe_clone on every component in the pipeline.

If a user changes a single parameter in the pipeline via set_params:
skbase updates the parameter -> It calls reset() on the Pipeline. -> The Pipeline re-runs init, which re-clones every single component.
Inside GridSearchCV with many parameter combinations, this results in many redundant deep clones and re-initializations for parameters that don't require them.

[felipeangelimvieira]

@Deep-Axe amazing, I agree!

The list of tags that I propose is, design-wise equivalent to your protected attributes idea.

I would vote for protected attribute instead of a tag, since this tag would not a have a pre-defined set of possible values.