Exercises — Beam search decoding
Prerequisite links if a step feels shaky: 3.5.12-Sequence-to-sequence-models, 3.5.13-Attention-mechanism, 3.4.8-Temperature-sampling, 4.2.5-BLEU-score.
All logarithms below are natural logs (), matching the parent note (e.g. ).
Level 1 — Recognition
L1.1
What value of the beam width makes beam search identical to greedy decoding, and why?
Recall Solution
. With a beam of width one we keep only the single highest-scoring partial sequence at every step. That is exactly the rule "pick the highest-probability token each step" — which is greedy decoding. So beam search with is greedy decoding; nothing else can happen because there is no second candidate to keep alive.
L1.2
For the sequence [<START>, Bonjour, <END>], what is (the number of generated tokens used in length normalization)?
Recall Solution
.
We drop the leading <START> because it is a fixed marker the model did not predict — it carries no predicted probability. The two generated tokens are Bonjour and <END>.
Level 2 — Application
L2.1
The model gives for Bonjour. Convert this to a log-score. (Use .)
Recall Solution
. Note it is negative: any probability below 1 has a negative log, so all sequence scores are negative and "less negative = better".
L2.2
A beam has cumulative score after Bonjour. The model then predicts <END> with probability . What is the new cumulative (un-normalized) score?
Recall Solution
We add the new log-probability (that is why we work in log space):
L2.3
Two finished sequences have un-normalized scores and , each with generated tokens. Using , which one does beam search output?
Recall Solution
Normalize by :
Higher (less negative) wins: the first sequence, score . This reproduces the "Bonjour wins" result from the parent worked example.
Level 3 — Analysis
L3.1
Run one full beam-search step with . Starting beam:
[<START>, Bonjour] (score ) and [<START>, Salut] (score ).
The model's next-token probabilities are:
From Bonjour |
prob | From Salut |
prob |
|---|---|---|---|
<END> |
0.9 | <END> |
0.85 |
Salut |
0.08 | Bonjour |
0.10 |
All four candidates finish (they end in <END> or hit the same 2-token length). Using , which two sequences survive, and what are their normalized scores?
Recall Solution
Expand every beam by every candidate token, adding the new log-prob:
| candidate | cumulative score | normalized | |
|---|---|---|---|
Bonjour <END> |
2 | ||
Bonjour Salut |
2 | ||
Salut <END> |
2 | ||
Salut Bonjour |
2 |
Sort by normalized score, keep top 2:
Bonjour <END> () and Salut <END> ().

Look at the figure: four orange candidate branches fan out, but only the two teal-highlighted paths pass the top- cut. The two branches ending in Salut/Bonjour (plum, dashed) are pruned — the model gave them tiny probabilities, so their cumulative scores plunged.
L3.2
In L3.1, the worse-starting beam Salut still survived to the final output list. Explain in one sentence how beam search "recovered" it, and give the numeric reason it did not beat Bonjour.
Recall Solution
Salut <END> survived because at we keep the top two sequences, and its normalized score was the second best of the four candidates.
It did not win because Bonjour began with a higher first-token probability ( vs ), giving a less-negative starting score that its ending never overcame: .
Level 4 — Synthesis
L4.1
Two finished candidates:
- A =
[<START>, I, go], cumulative score - B =
[<START>, I, will, go, now], cumulative score
Compute the normalized score of each under , , and . For each , say which sequence wins. What does this reveal about the role of ?
Recall Solution
Generated lengths: , . Normalized score .
| A score | B score | winner | |||
|---|---|---|---|---|---|
| A | |||||
| A | |||||
| B |
Reading it: with (no normalization) the shorter A wins easily — raw sums always favour fewer negative terms. With full the longer B wins because we divide by the full length, rewarding B's good per-token average. At we sit in between: A still edges out here, but the margin has shrunk dramatically. That is exactly why practitioners pick — enough length reward to stop the decoder emitting <END> too early, without over-rewarding rambling.

The figure plots each sequence's normalized score as sweeps . The two curves cross near : left of the crossing the short sequence wins, right of it the long one does.
L4.2
Vocabulary size , beam width , maximum length . Contrast the number of full sequences an exhaustive search would score against the number of candidate-expansions beam search performs. Use the parent note's complexity claims.
Recall Solution
- Exhaustive: every position can be any of tokens, so there are possible sequences — astronomically intractable.
- Beam search: each of steps expands live beams by tokens, i.e. candidate-expansions per step, giving expansions total. Beam search replaces an exponential with a linear-in- cost — that is the whole point of pruning to survivors each step.
Level 5 — Mastery
L5.1
We decode word by word. The true best full sequence is I have a cat. Below are the cumulative log-probabilities (natural log, summed over the tokens generated so far) of the live partial sequences at the moment the decoder has produced three generated tokens after <START>:
I have the— cumulative log-probI own a— cumulative log-probI have a— cumulative log-prob
The prefix I have a (score ) is the one that would eventually grow into the true best I have a cat. Beam width . Show, step by step, why beam search fails to return the true best sequence, and name what kind of algorithm beam search therefore is.
Recall Solution
At this step we sort the live partial candidates by their cumulative log-prob and keep the top (all three partials have the same length , so comparing cumulative scores is fair here):
| partial | cumulative log-prob | rank |
|---|---|---|
I own a |
1 ✔ kept | |
I have the |
2 ✔ kept | |
I have a |
3 ✘ pruned |
I have a is only the third-best partial, so with it is discarded. Since it is gone, beam search can never extend it to I have a cat, even though that completed sequence would have been the global optimum. The high-probability word cat arrives too late to rescue a prefix that already fell outside the beam.
Therefore beam search is an approximate (heuristic) search, not an exact/optimal one: it can permanently prune the prefix of the true best sequence whenever an early token sits outside the top .
L5.2
Design fix. A team notices their summarizer keeps emitting <END> after just 3 tokens even though good summaries are ~15 tokens. Name two parent-note hyperparameters they should adjust, state the direction of each change, and explain the mechanism in one line each.
Recall Solution
- Length penalty → increase (toward ). Larger divides by a bigger , which rewards longer sequences' per-token averages, so premature short sequences stop dominating (exactly the flip we saw in L4.1 as ).
- Min length → set to ~15 (or some floor ). This hard-forbids
<END>before tokens are generated, directly banning the "quit after 3 tokens" behaviour regardless of score. (A supporting third fix: n-gram blocking if the longer outputs start repeating phrases.)
Recall Quick self-check (clozes)
Beam search with reduces to greedy decoding.
We work with log-probabilities so that products become sums and small numbers don't underflow.
Length normalization divides the score by ==== where = number of generated tokens.
Why don't we count <START> in ? ::: Because it is a fixed marker the decoder never predicted, so it contributes no term.
Beam search is approximate because it can prune the prefix of the true-best sequence if an early token falls outside the top .