Búsqueda de fragmentos de respuesta en el contexto

Under the hood, extractive QA never writes text. It picks a span: a contiguous slice of the context defined by where it starts and ends.

The model's real job is to predict two positions: the start token of the answer and the end token. The slice between them is the answer.

Inside the model the context is split into tokens, not raw letters. Start and end are token indexes that get mapped back to characters.

For every token the model emits a start logit and an end logit. These scores say how likely each token begins or ends the answer.

The chosen span is the start and end pair with the highest combined score, with the rule that end never comes before start.

The pipeline returns character offsets so you can slice the original context yourself and recover the exact answer text.

Those offsets let you highlight the answer right inside the passage, which is great for showing users where a fact came from.

You can cap how long a span may be with max_answer_len. This stops the model from returning an entire sentence as the answer.

Set top_k to return more than one candidate span. Reviewing a few options helps when the best answer is ambiguous.

A span is always one continuous stretch of text. Extractive QA cannot stitch together words from different parts of the passage.

Because answers are exact spans with offsets, you can highlight them in place, giving users a verifiable source for every reply. 🔦

How does the model decide what the answer is?

The model predicts start and end positions, picks the best valid pair, and offsets let you slice and highlight the exact answer. 📌