Using Pipelines

Once a pipeline has been built and fitted, the natural next question is how well it performs on data it has not seen. A pipeline is treated as one object, and you can ask that object for a score on the test set. This is the point where a pipeline stops being a convenience and starts behaving like a complete model: you give it raw test features and a set of true labels, and it returns a single number that reflects both the preprocessing and the classification.

Before a pipeline was used, the same evaluation required a sequence of separate manual actions. The test data had to be transformed first, and only then was the score method of the classifier called on that transformed data. The pipeline collapses that sequence into one call. The rest of this article follows what happens inside that one call, why its result can be trusted, and why the same object can be handed to cross-validation and grid search.

When score is called on a pipeline, the work happens in two stages, and they always run in the same fixed order. In the first stage, the test data is transformed using the scaler. In the second stage, the score method of the SVM is called on that scaled test data. The pipeline never scores the raw test features directly. The estimator at the end of the chain only ever sees the output of the transformation.

Read the diagram from left to right. The raw test features enter the first stage, where the scaler transforms them. The scaled version then becomes the only input the SVM sees. Notice what the scaler is not doing here: it is applying a transformation it already learned during fitting, not learning a new one from the test set. The SVM is likewise scoring with the classifier that was fitted earlier. Only the test features are new in this call, and they pass through both stages in order before a single score comes back.

The source states that the score produced by the pipeline is identical to the result obtained earlier, when the transformations were performed by hand. This is the check that gives confidence in the pipeline. It does the same work as the manual steps, just through one call. Because the two stages always run in a fixed order, the single number returned reflects the same chain of operations you would have carried out yourself: transform the test features, then score the classifier on the transformed features.

The comparison makes the logic of the equality clear. Each manual step has a matching pipeline stage, performed in the same order, on the same inputs, by the same fitted objects. Since nothing differs in the operations themselves, the scores agree. The pipeline does not approximate the manual process; it is the manual process, packaged so that the order is enforced for you.

Suppose the pipeline score and a hand-computed score disagree. Because the pipeline is defined as a fixed two-stage chain, you can narrow down the cause by checking the stages in order. The first question is whether the transformation stage produced the same scaled test features as the manual transformation. The second question, asked only after the first is settled, is whether the estimator stage scored those features in the same way.

Locating a discrepancy in the two-stage evaluation flow.

The flow shows why the order of checks matters. The transformation stage is checked first because the estimator only ever sees its output. If the scaled features already differ, the estimator stage is not the place to look, since it is receiving different inputs. Only when the transformed features match should you suspect the scoring call on the classifier itself. Checking each stage separately keeps you from chasing a problem in the wrong place.

The main benefit the source emphasizes is that the pipeline can be used as a single estimator in cross_val_score or GridSearchCV. Those tools expect one estimator to work with. The pipeline is that estimator, even though it contains a scaler and an SVM internally. From the outside, the pipeline has the same interface as any single model, so the evaluation tools do not need to know that preprocessing happens inside it.

Read the sequence as a series of messages from the cross-validation procedure to the pipeline, which then passes work to its two internal components. For each fold, the pipeline is fitted on the training portion, which means the scaler learns its transformation from that portion and the SVM is trained on the scaled result. Then the held-out portion is scored: the scaler only transforms it using what it learned from the training portion, and the SVM scores that output. The held-out data is never used to learn the scaling.

This is why treating the whole pipeline as one estimator keeps the transformations inside each fold. Because the scaler is part of the object being refit, each fold gets its own scaling learned from its own training data. A grid search works the same way: it tries combinations of hyperparameters, and because the pipeline is a single estimator, the optimization can cover the entire pipeline, including the preprocessing stage, rather than only the classifier on its own.