Accessing and inspecting pipeline steps

make_pipeline is a convenience function that builds a pipeline and names each step automatically from its estimator's class.

Programming

A Pipeline Result You Did Not Expect

Suppose you build a model as a pipeline and the final result looks wrong. The pipeline has several stages, and the output of one stage becomes the input of the next, so the problem could sit in any of them. Before you change any code, you need a way to see what the pipeline actually contains. This article shows how to read the steps of a pipeline, how the names of those steps are produced, and how to use those names to find the stage where things went wrong.

A useful first move with any unexpected result is to list the pipeline's steps and confirm that they are the estimators you intended, in the order you intended. Keep that habit in mind as you work through the sections below.

Two Ways to Build the Same Pipeline

A pipeline can be built in two ways. The standard Pipeline syntax takes a list of (name, estimator) pairs, so you choose each name yourself. The abbreviated syntax, made with the make_pipeline function, takes only the estimators and generates the names for you. Both produce pipelines that do exactly the same work. The only difference is how each step is labeled and how much typing you need to do.

Definition

make_pipeline is a convenience function that builds a pipeline and names each step automatically from its estimator's class.

Feature	Standard Pipeline syntax	make_pipeline
What you supply	A (name, estimator) pair for every step	Only the estimators
Who names the steps	You do	The function, from each estimator's class
Work performed	Same as make_pipeline	Same as the standard syntax
Best suited to	Names that mean something to you	Cases where default names are enough
Typing required	More, because every name is written out	Less, because no names are written

The two constructors differ in labeling and typing effort, not in computation.

Building and Printing a Pipeline

Read the following code the way you would read any Python program. Each line creates an object, and the final line asks that object to report its contents. Try to predict what the output will show before you read it. The standard version below is included only so you can see that the two syntaxes describe the same two-step work.

python

from sklearn.pipeline import Pipeline, make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.svm import SVC

# Standard syntax: you write each name
standard = Pipeline([("scaler", StandardScaler()), ("classifier", SVC(C=100))])

# Abbreviated syntax: only the estimators are given
abbreviated = make_pipeline(StandardScaler(), SVC(C=100))

print(abbreviated.steps)

from sklearn.pipeline import Pipeline, make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.svm import SVC

# Standard syntax: you write each name
standard = Pipeline([("scaler", StandardScaler()), ("classifier", SVC(C=100))])

# Abbreviated syntax: only the estimators are given
abbreviated = make_pipeline(StandardScaler(), SVC(C=100))

print(abbreviated.steps)

Output (expected)

[('standardscaler', StandardScaler()), ('svc', SVC(C=100))]

Notes on the code

The first pipeline passes (name, estimator) pairs, so the names scaler and classifier are chosen by the author.
The second pipeline passes only the estimators, so the names are generated from the class of each one.
The steps attribute prints each step as a name paired with its estimator, including the estimator's parameter settings such as C=100.

Output

[('standardscaler', StandardScaler()), ('svc', SVC(C=100))]

Predicting the Names make_pipeline Assigns

Before reading further, decide what names you expect make_pipeline to give the two steps in the abbreviated pipeline. Think about what information the function has access to when it names each step. The function is given the estimator objects, and each of those objects belongs to a class, so the class is the only source of a name.

What do you think happens?

Given make_pipeline(StandardScaler(), SVC(C=100)), what name does the SVC step receive?

svc
SVC
classifier
step_2

Reveal answer

Answer:

svc

make_pipeline builds each name from the estimator's class. The SVC class produces the name svc, and StandardScaler produces standardscaler, as the printed output above shows. No name is chosen by the author.

Reading the steps Attribute

A pipeline, whether fitted or unfitted, keeps its list of steps in an attribute named steps. Each entry in that list is a pair: the step name first, then the estimator object. Because the names are stored there, the steps attribute is the place to look when you want to confirm which name belongs to which estimator. Since steps is a list, you reach a step by its position with an integer index. Reaching a step by its name requires finding the pair whose first element matches that name.

python

steps = abbreviated.steps

first_name, first_estimator = steps[0]    # by position
print(first_name)                         # standardscaler

lookup = dict(steps)                      # by name
print(lookup["svc"])                      # SVC(C=100)

steps = abbreviated.steps

first_name, first_estimator = steps[0]    # by position
print(first_name)                         # standardscaler

lookup = dict(steps)                      # by name
print(lookup["svc"])                      # SVC(C=100)

Output (expected)

standardscaler
SVC(C=100)

Notes on the code

steps[0] returns the first (name, estimator) pair, which is the position-based route.
dict(steps) turns the list of pairs into a lookup table keyed by name, which is the name-based route.
Both routes return the same estimator object stored in the pipeline.

Position and Name as Two Views of One Step

The steps list gives every stage a position and a name at the same time. Position 0 holds the first stage, and that stage is also the one called standardscaler. The diagram below shows the steps list as an ordered sequence of positions, with each entry carrying its generated name and the estimator it holds.

What does the steps list contain, and how do I reach the second step by position versus by its name?

Position 1 and the name svc point to the same entry. Choose position when you are walking through the stages in order, and choose the name when you want to check a specific stage whose identity you already know.

Tracing Data Through the Steps

The data flows through a pipeline one step at a time. Input enters the first step, and the values that step produces then enter the next step. A mismatch at any step carries forward to the final result, which means the final output can look wrong even when the error started early. Think of this abbreviated pipeline as a chain of two links: the input enters the scaler first, and the scaled values then enter the SVC.

When the final output is wrong, how does data pass from one step to the next, and at which step did the problem start?

Mapping Names to Estimators

Each step name is a string you can use to refer to that step, and each value is the estimator that the step runs. The printed output also shows the parameter settings of each estimator, but the name-to-estimator mapping is the part that matters for locating a step. The diagram below shows that mapping as a set of key-value pairs.

Given an estimator class such as StandardScaler, what name does make_pipeline give it, and which estimator does that name point to?

Mistakes When Inspecting Pipeline Steps

Common mistake
Assuming make_pipeline gives the steps names you chose
What it looks like
Writing make_pipeline(StandardScaler(), SVC(C=100)) and then looking up a step called classifier.
Why it fails
Only the standard Pipeline syntax lets you write the names. make_pipeline generates them from each estimator's class.
Do this instead
Read the steps attribute to find the generated names, such as standardscaler and svc.
Common mistake
Debugging the last step before checking the earlier ones
What it looks like
Changing the SVC settings when the final result is wrong, without checking what the scaler produced.
Why it fails
Data flows through the steps in order, so a mismatch at an early step carries forward to the final result.
Do this instead
List the steps, confirm they are the intended estimators in the intended order, and then inspect each stage in turn.
Common mistake
Reading only the names and skipping the estimator stored under each name
Common mistake
Treating the steps list as a dictionary
What it looks like
Writing abbreviated.steps["svc"] and expecting the estimator back.
Why it fails
steps is a list, so a string index is not a valid way to reach a step.
Do this instead
Use an integer position, or build a lookup with dict(abbreviated.steps) and then index it by name.

Practice: Locating a Suspect Step

MEDIUM

A colleague builds pipe = make_pipeline(StandardScaler(), SVC(C=100)) and reports a wrong final prediction. Without changing any code, describe the steps you would print and what you would check in each one to decide whether the problem is in the scaler or in the SVC.

Hints

Start with the steps attribute and write down the name and estimator of each entry.
Confirm the order: the scaler should come before the SVC because data enters the scaler first.
Use position to visit each stage in order, and compare its estimator with the one you intended.

Your attempt (not saved)

Key Takeaways

make_pipeline builds the same pipeline as the standard Pipeline syntax, but it names each step automatically from its estimator's class instead of asking you to write names.
The steps attribute is a list of (name, estimator) pairs, so you can reach a step by integer position or, through a lookup such as dict(steps), by its name.
Data flows through the steps in order, so an unexpected result can carry forward from an early step, and checking the names and then each stored estimator reveals where the problem started.

Related concepts

More concepts starting with A