← Latest papers
🤖 machine learning

Multi-User Dueling Bandits: A Fair Approach using Nash Social Welfare

This paper addresses fairness in multi-user dueling bandits by introducing a Nash Social Welfare objective to prevent minority marginalization, establishing a novel O(T2/3)O(T^{2/3}) regret lower bound for heterogeneous preferences, and proposing algorithms that achieve matching upper bounds.

Original authors: Maheed H. Ahmed, Mahsa Ghasemi

Published 2026-06-16
📖 5 min read🧠 Deep dive

Original authors: Maheed H. Ahmed, Mahsa Ghasemi

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the DJ for a massive party with hundreds of guests. Your job is to pick the perfect song to play next. But here's the catch: you don't get to ask everyone, "What do you want to hear?" Instead, you have to guess by playing two songs back-to-back and seeing which one the crowd prefers. This is the basic idea of a Dueling Bandit problem: learning what people like by comparing options rather than asking for ratings.

Now, imagine the party is divided into different groups. Some love heavy metal, some love jazz, and others love pop. If you just try to please the "average" person, you might end up playing a boring mix that no one really enjoys, or worse, you might completely ignore the small group that loves jazz because the metal fans are louder.

This paper proposes a new way to be the DJ that ensures everyone gets a fair shot at hearing music they like, not just the majority.

The Core Problem: The "Average" Trap

In most computer systems, the goal is to maximize the "total happiness" (the sum of everyone's enjoyment). If 90 people love rock and 10 people love jazz, the system will only play rock. The 10 jazz fans get zero happiness. The paper argues this is unfair. It wants a system where the "jazz fans" aren't left behind, even if they are a minority.

The Solution: The "Group Happiness" Formula

To solve this, the authors use a concept called Nash Social Welfare (NSW).

Think of it like this:

  • The Old Way (Utilitarian): You add up everyone's happiness. 90+10=10090 + 10 = 100. If you play rock, the 90 fans are happy, but the 10 are miserable. Total score is high, but it's unfair.
  • The New Way (Nash Social Welfare): Instead of adding, you multiply everyone's happiness.
    • If the 10 jazz fans have a happiness of 0, the total score becomes 0 (90×0=090 \times 0 = 0).
    • To get a high score, everyone needs to have at least a little bit of happiness.

This mathematical trick forces the algorithm to care about the smallest group. If it ignores the jazz fans, the "score" crashes. It's like a chain: the chain is only as strong as its weakest link.

How the Algorithm Works

The paper introduces two main strategies (algorithms) to find the best mix of songs (or "arms," as they call them in the math world) that satisfies this fairness rule.

  1. The "Learn First, Then Play" Strategy (Fair-Explore-Then-Commit):

    • Phase 1 (The Taste Test): The DJ spends a lot of time playing different pairs of songs just to figure out exactly what each group likes. They are looking for the "Condorcet Winner" for each group—basically, the one song that beats all others for that specific group.
    • Phase 2 (The Setlist): Once they are confident they know what everyone likes, they stop guessing and play the perfect mix that balances everyone's happiness for the rest of the party.
  2. The "Mix It Up" Strategy (Fair-ϵ-Greedy):

    • This strategy is more flexible. It mostly plays the best mix it knows so far, but every now and then, it deliberately plays a random pair of songs to double-check its assumptions. If it realizes it was wrong about what the jazz fans like, it can change its mind immediately. It's like a DJ who keeps a few surprise songs in the back pocket just in case the crowd's mood shifts.

The Big Discovery: Fairness Has a Cost

The authors proved something very important: Being fair is harder than being efficient.

In the old "average" system, the DJ could learn the best song very quickly. But in this "fair" system, the DJ has to spend extra time figuring out what the quiet, minority groups like, even if it slows down the process of finding the "best" song for the majority.

They calculated exactly how much slower this is. They found that the "regret" (the amount of happiness lost because the DJ didn't know the perfect song yet) grows at a specific rate: roughly proportional to the time squared, divided by the cube root of the number of groups.

  • Simple translation: The more different groups you have, and the more options you have to choose from, the longer it takes to find a solution that makes everyone happy compared to just making the majority happy.

The Results: Does it Work?

The authors tested their ideas with simulations and real data (using a dataset of people's sushi preferences).

  • The Result: Their "Fair" algorithms successfully kept the "Gini coefficient" (a measure of inequality) low.
  • The Trade-off: The "Unfair" algorithms (which just maximize total happiness) made the majority very happy but left the minority with almost nothing. The "Fair" algorithms made the majority slightly less happy than the unfair ones, but they ensured the minority was still satisfied.
  • The Winner: The "Fair" algorithms achieved the highest Nash Social Welfare score, meaning they found the best balance where no group was completely ignored.

Summary

This paper teaches us that if you want to build a system that treats everyone fairly, you can't just look at the average. You have to use a special mathematical lens (Nash Social Welfare) that forces the system to care about the smallest groups. It takes a bit more time and effort to learn what everyone wants, but the result is a system where no one is left out in the cold.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →