Content & Media Generation

A Two-Model Pipeline That Turns Any Passage Into Study-Ready Question-and-Answer Flashcards

How Pfactorial Technologies built a web application that generates and answers comprehension questions from any user-supplied passage, on demand.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_QA_Flashcards image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client wanted a way for anyone - a teacher building a quiz, a student reviewing a passage, a content team producing study material - to paste in a block of text and get back a working set of comprehension questions and answers, without touching a machine-learning pipeline themselves.

The naive version of this is one model doing both jobs badly: generating a question is a different task from answering one, and gluing them together with a single call hides failures where they're hardest to diagnose. It also has to hold up against an external API that can rate-limit or time out mid-request, which a demo-quality integration will treat as fatal rather than as something to quietly retry through.

Pfactorial built a Flask application that pairs a dedicated question-generation model with a dedicated question-answering model behind one simple interface - generate a full set of flashcards from a passage, or answer a specific custom question against it - with resilient retry handling on every external call.

Why this engagement is representative This engagement demonstrates Pfactorial's approach to applied NLP prototypes: pairing the right specialized model to each sub-task rather than forcing one model to do a job it wasn't trained for, wrapped in a simple interface a non-technical user can actually use.

THE CHALLENGE

Turning free text into reliable question-and-answer pairs runs into problems that only show up once real users start pasting in real passages.

1. Question generation and question answering are different tasks

A model tuned to generate plausible questions from a passage is not the model to trust for pinpointing the answer span inside that passage - using one model for both would trade accuracy on one task for the other.

2. Long or short passages both need to produce something usable

The tool has to cap input length sensibly and still produce a coherent set of questions whether the passage is a single paragraph or close to the input limit, without generating obviously redundant or malformed questions.

3. External model APIs fail transiently, not just permanently

A single failed call to a hosted inference API shouldn't sink the whole request - rate limits and brief outages are common enough that the application needs to retry before giving up.

4. Users need both automatic and self-directed study modes

Some users want the system to generate the questions; others already know what they want to ask and just need the answer pulled from their own passage - both paths have to work through the same interface.

The real brief Not "call a question-answering model and show the result" but "pair the right specialized model to each sub-task, and keep the whole pipeline working through the inevitable hiccups of a third-party inference API."

THE SOLUTION

Pfactorial built a Flask application that routes passages through a dedicated question-generation model and a dedicated question-answering model, hosted via the Hugging Face Inference API, with retry logic wrapping every external call.

Pfactorial_Case_Study_QA_Flashcards image 2

Figure 1 - The passage flows through two specialized models - one for generating questions, one for answering them - before results reach the user.

Architectural principles

One model per task, not one model for everything - question generation runs on a T5 model fine-tuned specifically for that task, and answering runs separately on a RoBERTa QA model, so each step gets a model actually trained for the job it's doing.
Resilience to third-party API failure is not optional - both the generation and answering calls retry automatically - up to 30 attempts with a delay between each - so a transient failure at the inference API doesn't surface as a broken experience for the user.
Sentence-aware chunking instead of a raw text dump - input passages are tokenized into sentences and grouped before being sent to the generation model, producing more coherent questions than feeding the model an undifferentiated block of text.
Two entry points for two study styles - the same passage can drive fully automatic flashcard generation or a targeted custom-question lookup, covering both the user who wants the system to do the work and the user who already knows what they want to ask.

CAPABILITIES DELIVERED

Each capability turns a plain-text passage into something a learner or content author can act on immediately.

CAPABILITY	WHAT IT DOES
Automatic flashcard generation	Generates up to five question-and-answer pairs directly from a user-supplied passage, no manual authoring required.
Custom question answering	Accepts a user's own question against a supplied passage and returns a model-generated answer.
Interactive card interface	Generated questions render as clickable cards that reveal their answer on demand.
Sentence-grouped question generation	Splits and groups passage sentences before generation, producing more coherent questions than a single undifferentiated pass.
Resilient external API handling	Wraps every generation and answering call in automatic retry logic to absorb transient Hugging Face Inference API failures.
Lightweight, dependency-light interface	A plain HTML/CSS/JavaScript front end backed by a single Flask service, with no heavyweight frontend framework required.

Pfactorial_Case_Study_QA_Flashcards image 3

Figure 2 - The same passage feeds both the automatic flashcard path and the custom-question path through the same two-model pipeline.

Design note The retry logic - up to 30 attempts with a delay between each - is deliberately aggressive because the application has no fallback model if the call ultimately fails; the tradeoff accepts slower worst-case response time in exchange for treating a hosted inference API's transient failures as routine rather than fatal.

ENGINEERING FOR SCALE AND RELIABILITY

Four decisions kept the prototype dependable despite depending entirely on third-party model hosting.

Hugging Face Inference API instead of self-hosted models

Using hosted T5 and RoBERTa models let the prototype ship without standing up GPU infrastructure, at the cost of taking on the availability and rate-limit behavior of a third-party API - which the retry logic exists specifically to absorb.

Sentence tokenization and grouping before generation

Splitting the passage into sentences and grouping them keeps each generation call working against a digestible unit of text rather than an arbitrarily long block, improving the coherence of the resulting questions.

A capped input length rather than an unbounded one

Limiting passages to 2,411 characters keeps generation and answering calls within a predictable, reliable range for the hosted models rather than letting an oversized passage degrade output quality unpredictably.

Separate routes for generated and custom questions

The /qanda and /questionanswer endpoints are kept distinct rather than merged into one flexible endpoint, so the automatic-generation path and the self-directed question path can evolve independently.

DELIVERY APPROACH

The engagement built the two-model pipeline first, then layered the interface and resilience handling on top.

1. Model selection - identified and validated a T5-based question-generation model and a RoBERTa-based question-answering model hosted on the Hugging Face Inference API.

2. Core pipeline - built the sentence tokenization, grouping, and generation logic (functions.py) that turns a passage into a set of candidate questions.

3. Answering path - wired generated and custom questions alike through the QA model to retrieve answers against the original passage.

4. Resilience layer - added automatic retry-with-delay handling around every external model API call to absorb transient failures.

5. Interface - built the HTML/CSS/JavaScript front end, including the interactive card display and the custom-question flow.

6. Deployment - packaged the application as a Dockerized Flask service exposed on a dedicated port for evaluation.

RESULTS AND IMPACT

Pfactorial_Case_Study_QA_Flashcards image 4

- Key outcomes from this engagement.

The application is built and functioning end-to-end: users can generate up to five questions and answers from any passage up to 2,411 characters, or ask their own question against the same passage, with both paths backed by automatic retry handling against the underlying model APIs.

Because question generation and question answering run through separately specialized models rather than one general-purpose model doing both jobs, the output quality on each task reflects a model actually suited to it, rather than a compromise.

What it enabled commercially

The client now has a working, demonstrable prototype for automated question-and-answer content generation that can inform a production build decision - including where a self-hosted or fine-tuned model might eventually replace the current API dependency - without having committed to that infrastructure investment up front.

WHY PFACTORIAL

This engagement reflects Pfactorial's applied AI prototyping practice - pairing the right model to each sub-task, wrapping third-party model APIs in resilience the demo layer alone wouldn't need, and shipping a working tool a non-technical user can pick up immediately.

Pfactorial_Case_Study_QA_Flashcards image 5

- Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with education and content teams who want to turn generative and comprehension AI models into tools their non-technical users can actually use. If you're evaluating an applied-NLP prototype, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.