Multi-Armed Bandits

A multi-armed bandit repeatedly chooses one action and observes reward only for that action. In recommendation, an arm can be a headline, module, notification, or item bucket. The missing labels for unchosen arms are the key difference from ordinary supervised ranking: the system only learns from what it showed.

Bandits sit between pure ranking and full contextual bandits. They are the simplest online exploration setting: there is no user feature vector yet, just repeated choices, partial feedback, and the need to learn while serving traffic.

Formal setup

Let there be arms. At round , a policy chooses an arm , shows it to a user, and observes reward only for that chosen arm. Each arm has an unknown mean reward , which is the long-run expected click, conversion, or other product reward for that arm.

SymbolMeaning
number of available arms
arm chosen at round
reward observed after showing
expected reward of arm
best arm,
mean reward of the best arm,
horizon, or number of rounds

Because rewards are random, bandit papers often measure pseudo-regret: how much reward the policy left on the table compared with always showing the best arm.

The same quantity can also be written as

This formula is easiest to read as: each suboptimal choice costs the gap between the best arm and the arm actually shown. The larger the gap, and the longer the system keeps choosing the wrong arm, the larger the regret.

Regret

Regret is the main lens for bandits because it captures the exploration cost directly. A greedy policy can have low regret early if it gets lucky, then high regret later if it locks onto a mediocre arm. A good bandit policy pays some short-term regret to reduce long-term regret by learning which arm is actually best.

Cumulative regret over rounds: a greedy policy grows almost linearly because it can lock onto a suboptimal arm, while epsilon-greedy and UCB grow sublinearly, with UCB accumulating the least regret.

UCB-style methods choose arms with high estimated reward plus uncertainty:

Contextual bandits condition the choice on user and item features.

Why recommenders use bandits

A recommender usually wants two things at once:

  • good immediate reward from the items it shows now;
  • better future decisions from the feedback those items generate.

That makes bandits a natural fit for news headlines, homepage modules, notification templates, and item buckets where the system must pick one option per impression and only learns from the displayed option. If the system never explores, it can miss a better arm that just had bad luck early. If it explores too much, user experience suffers. The bandit formulation makes that trade-off explicit.

Worked example

Suppose a homepage has three newsletter modules:

ArmContent
0sports roundup
1personal finance tips
2weather alerts

Their true click-through rates are unknown to the system, but in reality they are:

ArmTrue click rate
00.03
10.05
20.08

The system starts with only a few impressions, so the observed data are noisy:

ArmWins / pullsEmpirical rate
01 / 100.10
11 / 100.10
20 / 20.00

A greedy policy would keep showing arm 0 or 1 because they currently look best, even though arm 2 is actually the best arm. That is the danger of early luck: a small sample can make a mediocre arm look strong and a strong arm look weak.

After 55 total pulls, a UCB policy combines the empirical win rate with an uncertainty bonus:

The exploration bonus is the uncertainty term in the UCB rule. It is large when an arm has few pulls, and it shrinks as the arm gathers evidence. The UCB score is the empirical rate plus that bonus; the policy chooses the arm with the largest score.

ArmWins / pullsEmpirical rateExploration bonusUCB score
04 / 400.1000.4480.548
12 / 100.2000.8951.095
20 / 50.0001.2661.266

Arm 2 has no wins, but its low count gives it the largest exploration bonus, so it is chosen next. That is the point of the upper-confidence-bound rule: if an arm has not been tried much, the policy treats it as promising until it has enough evidence to prove otherwise. If arm 2 keeps losing, its empirical rate stays low and the bonus shrinks as the count rises; if it starts winning, the policy learns that it should be shown more often.

In regret terms, each round spent on arm 0 instead of arm 2 loses about expected clicks. Over 1,000 impressions, that gap costs about 50 expected clicks. The bandit algorithm is trying to discover and then avoid that persistent loss.

This is the mechanism behind exploration versus exploitation. The next page, Bandit Algorithms, gives the concrete policies such as epsilon-greedy, UCB, and Thompson sampling.

Caveats

Bandits need reward definitions that match product goals. Delayed rewards, repeated exposure, and interference between users violate the simplest assumptions. The reward should reflect the thing the product actually values, not just clicks. Use replay or randomized traffic for offline versus online evaluation, not ordinary logged-label accuracy.

References