Describe `set_{method}_request()` API, expose `_MetadataRequester`, or expose `_BaseScorer`

### Describe the issue linked to the documentation

TL;DR: Metadata routing for scoring could either use a base class or documentation of how to write `set_score_request()`.

Currently the [Metadata Estimator Dev Guide](https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_metadata_routing.html#metadata-routing) has examples of a metadata-consuming estimator and a metadata-routing estimator.  However, the metadata routing is also designed for scorers and CV splitters which may or may not be estimators.   Fortunately, `sklearn.model_selection` exposes `BaseCrossValidator`, which like `BaseEstimator`, subclasses `_MetadataRequester`.  Unfortunately, ~there's no base class for scorers.~ the base class for scorers, `_BaseScorer`, is not public.

I don't understand how to string together the relevant methods that should be a part of `set_score_params`, The current workaround is to simply subclass `BaseEstimator`, even if I'm not making an estimator, or to subclass `_MetadataRequester`, even though its not part of the public API.  ~Or use `make_scorer` to pin the kwargs when instantiating the meta-estimator, rather than in `fit()`~

My use case is for scoring a time-series model where the data generating mechanism is known to the experiment, but not the model, and I need to compare the fit model to the true data generating mechanism.  I understand how to use a custom scorer in `RandomizedSearchCV`, and the [metadata API](https://scikit-learn.org/stable/metadata_routing.html#api-interface) explains how meta estimators like `RandomizedSearchCV` can pass additional arguments to my custom scorer.

### Suggest a potential alternative/fix

* publicly exposing `_MetadataRequester`
* publicly exposing `_BaseScorer`
* Document how to write the `set_{method}_request()` methods.  It looks like `_MetadataRequester` uses a descriptor `RequestMethod`, which relies on an instance having a `_get_metadata_request` method and a `_metadata_request` attribute (which it doesn't really describe).

EDIT: Found out about `_BaseScorer`.  Also, removed `make_scorer` workaround, as it doesn't result in passing the fitted estimator to the `_score_func`

COMMENT:
Hi @Jacob-Stevens-Haas,
Thanks for your thoughtful follow-up and for pinpointing these areas of confusion in the documentation! These are exactly the kinds of questions that help improve understanding for everyone, especially with newer concepts like metadata routing.
Let me try to clarify those two points based on my understanding:

1. On MetadataRouter and "router object":

You're right to question the terminology here, as it can be a bit circular at first glance.

- A "router object" is generally the component that does the routing. In scikit-learn, this would typically be an estimator (like RandomForestClassifier) or a scorer object. These objects have methods (e.g., fit(), score(), transform()) for which metadata (like sample_weight) can be routed.

- The MetadataRouter object (which is what get_metadata_routing() returns, and is an instance of sklearn.utils.metadata_routing.RoutingMethodContainer) is not the router object itself. Instead, it's a data structure that describes the current routing configuration of a specific router object.

- So, when the documentation says a MetadataRouter instance "Stores and handles metadata routing for a router object," it means it holds the settings, rules, or configuration map for how that particular estimator or scorer is set up to handle metadata for its various methods. For example, my_estimator.get_metadata_routing() would return a MetadataRouter object that tells you which metadata my_estimator is configured to request for its fit method, its predict method, etc.
- 
Think of the estimator as the "router device" and the MetadataRouter object as its "configuration sheet" or "routing table."

2. On the "serialized version" from get_metadata_routing():

This is another good catch regarding potentially ambiguous phrasing in the documentation.

- When the docs mention that get_metadata_routing() returns a "serialized version of this class" for consumer-only classes, it's generally referring to the MetadataRouter object (i.e., RoutingMethodContainer instance) itself.

- It's "serialized" in the sense that it's a structured Python object that represents the complete routing information for the consumer (e.g., an estimator). It's not typically "serialized" in the sense of a pickle.dumps() string or a raw JSON string, nor is it usually a simple flat named tuple of attributes.

- Instead, the RoutingMethodContainer is an object that internally holds more detailed structures, often dictionaries. These map method names (like "fit", "score") to MethodRouting objects, which in turn specify which metadata keys are requested (e.g., sample_weight=True, my_custom_meta=False) for each parameter of that method.

- So, the get_metadata_routing() method provides a programmatic way to inspect this structured object and understand the detailed metadata requirements and routing configuration of an estimator or scorer.

Essentially, it gives you an inspectable data structure representing the routing rules, rather than a binary blob.

Hope this helps clarify those points! Let me know your thoughts.

Labels: Documentation, Needs Investigation, Metadata Routing