Put simply, I think you’re right that this is a compatibility issue, but it looks like one of those cases where the workaround is easy and the proper fix is awkward
:
Yes, the notebook appears to need either a version constraint or a code/content update. The error is raised while pipeline() is validating the task name, before it gets as far as loading a question-answering model, so this does not look like a model download problem or a mistake in your question/context inputs.
The first useful check is the actual Transformers version and task registry:
import transformers
from transformers.pipelines import get_supported_tasks
print("Transformers version:", transformers.__version__)
print("Imported from:", transformers.__file__)
print(
"question-answering registered:",
"question-answering" in get_supported_tasks(),
)
The same Course example was reported in huggingface/course#1211 with Transformers 5.3.0. The v5.2.0 registry still contained question-answering, while the v5.3.0 registry no longer does. The current pipeline API’s accepted-task list also does not include the plain text question-answering pipeline.
Practical default: pin v4 if the goal is to finish this notebook as written
For a learner following the existing Chapter 1.3 notebook, I think the least surprising workaround is to use a fresh runtime and pin the notebook to the final v4 series:
# Run this before importing transformers.
!pip install -q "transformers[sentencepiece]==4.57.6" datasets evaluate
Then restart the Colab runtime once and run the notebook again from the top.
A looser constraint such as this expresses the same compatibility boundary:
!pip install -q "transformers[sentencepiece]<5" datasets evaluate
I would prefer the exact version in a teaching notebook because it is more reproducible. This is a compatibility workaround, not a claim that v4 is generally preferable for new projects.
Pinning only to transformers==5.2.0 is a useful QA-only diagnostic, because that version still registered the old QA pipeline. It is not as good a default for the complete notebook: the same notebook also uses the older summarization and translation pipelines, which are part of the broader v5 pipeline migration.
About opening an issue or PR
There are already two relevant Course issues:
So I would probably reference those rather than open an unrelated duplicate.
One slightly confusing detail is that #1211 was closed through Transformers PR #44787. That PR updated several language versions of the Transformers question-answering task guide to use AutoTokenizer and AutoModelForQuestionAnswering directly. It did not update the Chapter 1.3 Course page or its Colab notebook, and both currently still show the old pipeline call:
That is why the closed issue and the still-broken notebook can coexist.
Why this is more than a one-line pipeline rename
The version history is a little confusing
The Transformers v5 migration guide groups the following removals together:
question-answeringText2TextGenerationPipelineSummarizationPipelineTranslationPipeline
It recommends using a chat model through TextGenerationPipeline for many of those use cases.
However, the tagged source shows that the removals did not all appear at exactly the same minor-version boundary:
So I would distinguish two statements:
- Migration policy: the task-specific QA pipeline is part of the v5 removals.
- Observed implementation boundary: the QA registration remained through 5.2 and disappeared in 5.3.
Since your screenshot does not display transformers.__version__, I would describe the error as consistent with current Transformers releases rather than assume one exact version.
There are also a few residual references to question answering on the current general pipeline documentation page even though it is absent from the accepted-task list. That looks like documentation migration lag rather than evidence that pipeline("question-answering") is still supported.
Extractive QA still exists; the convenience pipeline is what disappeared
This distinction matters because “the QA pipeline was removed” does not mean that Transformers can no longer run extractive question-answering models.
The current question-answering task guide still documents:
from transformers import AutoTokenizer, AutoModelForQuestionAnswering
and shows inference using a model’s start and end logits.
That route preserves the type of task demonstrated by Chapter 1.3: extractive question answering, where the answer is selected from a span in the supplied context.
The Course itself explicitly says:
this pipeline works by extracting information from the provided context; it does not generate the answer
That is different from asking a general chat model to generate an answer.
Why the direct-model rewrite is not fully equivalent to changing one line
A minimal direct-model example can tokenize the question/context, run AutoModelForQuestionAnswering, choose start/end positions, and decode the resulting token span. That is enough to demonstrate the basic model contract.
The old pipeline did more than that, however. Its implementation also handled parts of the preprocessing and post-processing contract, including such things as:
- selecting answer spans only from the context rather than the question or special tokens;
- rejecting spans where the end precedes the start;
- limiting the maximum answer length;
- scoring combinations of start and end positions;
- mapping token positions back to character offsets in the original context;
- splitting long contexts into overlapping chunks;
- comparing candidates produced from different chunks;
- returning
answer, score, start, and end;
- optional top-k and impossible-answer handling.
The archived v4 implementation is visible in question_answering.py.
For that reason, the small inference example in the current task guide is a useful educational replacement, but I would not describe it as a drop-in implementation of every behavior of the former pipeline.
Why replacing it with text-generation changes the lesson
The migration guide’s chat-model recommendation may be a reasonable modernization route, but it changes what this particular Course example demonstrates.
| Extractive QA model |
Chat/text-generation model |
| Selects a span from the supplied context |
Generates new output tokens |
| Can return source character offsets |
Normally has no equivalent start/end contract |
| Answer is constrained to the source span by the model structure and decoding |
May paraphrase, combine information, or produce unsupported text |
| Usually uses an encoder model with a QA head |
Usually uses a generative decoder or encoder-decoder model |
| Demonstrates span classification |
Demonstrates prompted generation |
The current QA guide also explicitly separates:
- extractive QA: extract an answer from the context;
- abstractive QA: generate an answer based on the context.
Therefore, changing the notebook to something like this:
pipeline("text-generation", model="<some-chat-model>")
would not merely rename an API. It would change the task, output contract, model family, likely runtime requirements, and some of the failure modes being taught.
There are at least two defensible modernization choices:
Route A: preserve the original lesson
Keep the example as extractive QA and replace the removed pipeline with an explicit tokenizer/model/span-decoding example based on:
This preserves the distinction between extracting and generating an answer, but it requires more code and explanation than the old one-call pipeline.
Route B: redesign the overview for current chat models
Replace the example with prompted text-generation, but rewrite the surrounding explanation so it is presented as generative or abstractive QA rather than as a direct replacement for extractive span selection.
This may align more closely with the general v5 migration recommendation, but it is a content/design change rather than a compatibility-only patch.
Why a complete Course fix spans more than this cell
The current Colab setup installs an unconstrained latest Transformers release:
!pip install datasets evaluate transformers[sentencepiece]
The notebook then uses all three of these older task-specific calls:
pipeline("question-answering")
pipeline("summarization")
pipeline("translation", ...)
In addition, the rendered Course lesson and the runnable Colab notebook live in separate repositories:
Updating only the MDX would leave the Colab button opening an outdated notebook. Updating only the notebook would leave the displayed Course example outdated.
A durable fix therefore needs an editorial choice as well as a code change:
- Pin Chapter 1 to the legacy API intentionally.
- Rewrite all affected examples for current APIs.
- Preserve the original task taxonomy with lower-level model APIs.
- Redesign the section around current generative models.
- Possibly provide a short legacy note while introducing the current route.
That is the “proper fix is awkward” part: it is not difficult because the error is mysterious; it is awkward because a small beginner-facing API was carrying quite a lot of educational structure.
Possible contribution scopes
There are several reasonable contribution sizes, depending on what the maintainers prefer.
Small compatibility patch
- Pin the notebook to a known v4 release.
- Add a short note explaining that the chapter demonstrates the v4 pipeline API.
- Make the Course page and Colab notebook use the same constraint.
This is the smallest change and restores the lesson quickly, but it deliberately teaches an older API.
Focused QA modernization
- Keep the example extractive.
- Replace
pipeline("question-answering") with an explicit tokenizer/model example.
- Preserve the explanation that the answer is extracted rather than generated.
- Update both the Course MDX and the notebook.
This is conceptually clean, but a little longer than the original beginner example.
Chapter 1.3 v5 migration
Audit the whole section rather than only QA:
- NER arguments;
- question answering;
- summarization;
- translation;
- corresponding prose and expected outputs;
- notebook dependencies;
- Course and notebook synchronization.
#1197 is probably the most relevant place to connect a broader change like this.
A small review-friendly validation matrix
A PR would be easier to evaluate if it states which goal it is pursuing and records a few simple checks:
| Check |
What it establishes |
Print transformers.__version__ |
The result is tied to a known environment |
| Test a fresh Colab runtime |
Rules out state left by an earlier import/install |
| Run the old notebook under v4.57.6 |
Confirms the compatibility workaround |
| Check v5.2 versus v5.3 for QA only |
Confirms the observed registry boundary |
| Run the proposed current-version example |
Confirms the replacement actually works |
| Verify both MDX and notebook |
Prevents the rendered lesson and Colab from drifting apart |
| Preserve or explicitly change the task description |
Makes the extractive/generative design decision visible |
This need not become a large test suite; even a short note in the PR description would make the intended compatibility boundary much clearer to future readers.
So my answer to “Does the notebook need to be updated?” would be yes:
- For continuing the lesson now: pin Transformers to v4 in a fresh runtime.
- For fixing the course: connect the change to the existing issues and decide explicitly whether the example should remain extractive QA or be redesigned as generative QA.
- For a QA-only sanity check: comparing 5.2 with 5.3 is useful, but it does not solve the other old pipelines later in the same notebook.
A new issue may not be necessary, but an update or PR that references #1197, #1211, and the separate Course/Notebook sources would still be useful because the runnable material currently retains the old calls.
