A Slate Bandit (combinatorial bandit) extends actions from single items to a whole page-level list: each round pick K items out of N candidates to form a slate S with ∣S∣=K, i.e. (KN) combinations; rewards may be item-level (per-item clicks) or slate-level (e.g., at least one click, dwell time). The typical solution is Top-K combinatorial exploration: apply UCB/TS-style confidence scores at the item level — sort by μ^a+na2lnt and take the top K, guaranteeing each candidate gets explored, then adjust for position/diversity.
💡Use Cases
home feed, search result pages, email recommendations, ad layout combinations; interviews contrast "one action vs a set of actions" with MAB, hitting combinatorial complexity (KN) and greedy approximation.
⚡Key Problems Solved
enumerating (KN) super-arms explodes combinatorially and cannot be estimated individually; slate bandits exploit the combinatorial structure (per-item contribution + position effects) to reduce the estimation dimension from combinations to items, keeping O(lnT)-scale regret over large candidate pools while explicitly modeling item dependencies (diversity penalties, mutual exclusions).
🎯5 High-Frequency Exam Points
1
Combinatorics: how many slates for N=10,K=3? Why can't we estimate every super-arm individually?
2
Top-K combinatorial exploration: how do item-level UCB/TS scores with top-K selection guarantee exploration?
3
Difference between item-level and slate-level reward modeling, and when to use each?
4
How does position bias distort estimates, and how do you correct for it?
5
Modeling dependencies within a slate: diversity, mutual exclusion, and click co-occurrence constraints?