LLM-Mediated Group Decisions and Online Preference Elicitation

MemoryEvaluationAdvanced14 min

By: Anacodic Team

TL;DR — When several people must agree on one option, an LLM can act as a mediator: it proposes a choice, states in plain language who is being compromised, listens for objections, and updates how much each person's preference counts before proposing again — looping until nobody objects. The engine underneath is small: a weighted group score Σ wᵢ·sᵢ, an exponentiated-gradient weight update wᵢ ← wᵢ·exp(η·gᵢ)/Z that gives an objecting member more say, and a consensus stop. The LLM's real job is elicitation and explanation (turning natural-language reactions into the feedback signal gᵢ and narrating the tradeoff), not the arithmetic. It breaks without damping (weights can oscillate), it is not strategyproof (members can bluff), and the LLM can misreport why it chose — so log the weights and the objections, don't trust the narration alone.

1. Simple explanation

A one-shot recommender guesses once and stops. But group decisions are rarely one-shot: someone objects, the group adjusts, and a new option surfaces. A mediated system keeps a human-style loop going — propose, listen, adjust — except an LLM runs the loop.

The mediator does two very different kinds of work. One is social/linguistic: read a messy chat ("ugh not sushi again", "I'm easy", "anywhere but far"), figure out who is unhappy and how strongly, and explain the current pick in a way people accept. The other is numeric: keep a weight per person for how much their preference currently counts, and recompute the best option when those weights change. LLMs are good at the first and unreliable at the second, so the design keeps the math in code and uses the LLM only to feed it — turning language into a feedback signal — and to narrate the result.

Analogy — a good meeting facilitator. They don't impose their own preference. They float a proposal, watch the room, notice the one person who keeps frowning, say "Dana, this doesn't work for you — what would?", give Dana's view more airtime, and re-propose. After a couple of rounds the room settles. The facilitator's skill is reading the room and giving the overruled person more weight — not doing sums. That is exactly the split here: the LLM reads the room; a tiny formula gives the overruled person more weight.

2. Diagram

   weights start equal:  w = [1/n, ..., 1/n]

   ┌───────────────────────────────────────────────────────────────┐
   │  1. PICK      option k* = argmax_k  Σ_i w_i · s_i(k)           │
   │  2. NARRATE   LLM: "Going with k*. It compromises <member>."   │
   │  3. ELICIT    read reactions -> feedback g_i (accept/object)   │
   │  4. REWEIGHT  w_i <- w_i · exp(η·g_i) / Z   (objector gains say)│
   └───────────────────────────────────────────────────────────────┘
            │ repeat
            ▼
   stop when: no objection (consensus)  OR  round limit hit

   who does what:
     LLM  -> steps 2 & 3 (language: explain, and turn words into g_i)
     code -> steps 1 & 4 (math: argmax and the weight update)

3. How it works

3.1 The setup

There are n participants and a set of options. Each participant i has a satisfaction s_i(k) in [0,1] for option k (from ratings, a model, or similarity — see the embeddings article). A weight vector w, wᵢ ≥ 0, Σwᵢ = 1, records how much each person currently counts; it starts uniform. The mediator's output each round is one option plus a short natural-language justification. Nothing is persisted except the running weights and the objection history — that log is what makes the process auditable.

3.2 The propose–object–reweight loop

Each round: (1) pick the option maximizing the weighted group score; (2) the LLM announces it and names who is most compromised (the member with the lowest s_i on that option); (3) the LLM reads the participants' reactions and converts them into a feedback signal g_i — positive for a member who pushes back, zero for acceptance; (4) the weights update so that objecting members count for more next round. Repeat until no one objects (consensus) or a round cap is reached. The loop is a form of online preference elicitation: instead of surveying everyone up front, the system learns preferences as the conversation happens, spending questions only where there is disagreement.

3.3 The reweighting rule (exponentiated gradient)

The update is multiplicative and then renormalized:

  w_i  <-  w_i * exp(eta * g_i)  /  Z        with  Z = sum_j w_j * exp(eta * g_j)

eta > 0 is the learning rate (how big each nudge is) and g_i is the feedback for member i. This is the exponentiated-gradient / multiplicative-weights update from online learning: weights stay non-negative and sum to one automatically, and a member who repeatedly objects sees their weight grow geometrically until the pick shifts toward them. It is well-behaved and defensible precisely because it is a standard algorithm, not an ad-hoc "add 0.1 to whoever complains."

3.4 What the LLM actually contributes

Strip the LLM out and you still have a working reweighting algorithm — but a brittle one that needs numeric feedback and produces no explanation. The LLM adds three things a formula cannot: it elicits g_i from unstructured language (sarcasm, hedging, "I guess that's fine"), it explains the pick so people accept a compromise instead of feeling railroaded, and it detects consensus ("sounds like everyone's good?") from tone rather than an explicit vote. Crucially, it should not be trusted to compute the pick or invent the weights; those are cheap and must be exact.

Boundary condition. The loop assumes preferences are roughly stable within a session, that feedback is honest, and that some option can satisfy everyone enough to stop. If no option clears the consensus bar, the weights will chase objections forever (Section 8). If members learn the rule, they can bluff to grab weight. And if you let the LLM both decide and report, you lose the audit trail — keep the decision in code.

4. The math

4.1 The pieces

  weighted score   S(k)   = sum_i w_i * s_i(k)
  pick             k*      = argmax_k S(k)
  most compromised worst   = argmin_i s_i(k*)
  feedback         g_i     = 1 if member i objects, else 0   (simplest form)
  reweight         w_i    <- w_i * exp(eta * g_i) / Z
  consensus        stop when  s_worst(k*) >= tau

4.2 Worked example

Three users, three options, satisfaction rows s:

  user 0: [0.90, 0.65, 0.40]
  user 1: [0.20, 0.62, 0.70]
  user 2: [0.80, 0.60, 0.30]

Consensus bar tau = 0.60, learning rate eta = 0.8. Start w = [0.33, 0.33, 0.33].

Round 0: weighted scores are option0 = 0.633, option1 = 0.623, option2 = 0.467, so the pick is option 0. Its worst-off member is user 1 at 0.20, below tau — user 1 objects.

Reweight user 1: w becomes about [0.24, 0.53, 0.24]. Recompute: option0 = 0.51, option1 = 0.63, option2 = 0.54, so the pick moves to option 1. Its worst-off member is user 2 at 0.60, which meets tau — consensus on option 1. The group went from a pick that stranded user 1 (0.20) to one where the least-happy person is at 0.60, in a single reweighting round.

5. Real code

import math

# 3 users, 3 options; u[i][k] = user i's satisfaction with option k in [0,1].
u = [[0.90, 0.65, 0.40],   # user 0
     [0.20, 0.62, 0.70],   # user 1
     [0.80, 0.60, 0.30]]   # user 2
n, K = len(u), len(u[0])
CONSENSUS = 0.60           # everyone at least this happy -> stop

def wscore(k, w): return sum(w[i] * u[i][k] for i in range(n))
def pick(w):      return max(range(K), key=lambda k: wscore(k, w))

def eg_update(w, i, eta=0.8):        # exponentiated-gradient: give user i more weight
    w = [w[j] * math.exp(eta * (1.0 if j == i else 0.0)) for j in range(n)]
    Z = sum(w); return [x / Z for x in w]

w = [1 / n] * n
print(f"round 0  weights={[round(x,2) for x in w]}  pick=option{pick(w)}")
for r in range(1, 6):
    k = pick(w)
    worst = min(range(n), key=lambda i: u[i][k])       # most-compromised user
    if u[worst][k] >= CONSENSUS:
        print(f"round {r}  CONSENSUS on option{k} (worst satisfaction={u[worst][k]:.2f})")
        break
    w = eg_update(w, worst)                            # that user objects -> reweight
    print(f"round {r}  user{worst} objected -> weights={[round(x,2) for x in w]}  pick=option{pick(w)}")

# Output:
#   round 0  weights=[0.33, 0.33, 0.33]  pick=option0
#   round 1  user1 objected -> weights=[0.24, 0.53, 0.24]  pick=option1
#   round 2  CONSENSUS on option1 (worst satisfaction=0.60)

In a real system, steps that read worst and decide "objected" come from the LLM parsing chat, not from min(); the arithmetic (wscore, eg_update) stays in code exactly as above.

6. Real-world example

A scheduling assistant for a 5-person team picked meeting slots by maximizing summed availability. It kept choosing a slot two senior members loved and one part-time member could never make; the summed score was highest, so the tool "worked" while quietly excluding the same person every week. Reframing it as a mediated loop changed the behavior: the assistant proposed a slot, said in the thread "this one doesn't work for Sam — Sam, which windows are OK?", weighted Sam's stated windows more heavily, and re-proposed. Consensus took two rounds and landed on a slot with slightly lower total availability but no chronic exclusion.

The failure mode showed up too, and it is instructive. In a week when no slot worked for everyone, the loop oscillated — each round a different person objected and the pick flip-flopped without settling. The fix was not more LLM cleverness but a damping rule (shrink eta over rounds) plus a fallback ("no slot satisfies all; here are the two least-bad, please decide manually"). The lesson generalizes: a mediation loop must define what happens when consensus is impossible, or it will chase objections forever.

7. Interview questions companies actually ask

Q1. Why put an LLM "in the loop" instead of ranking once? Because group preferences surface through interaction, not up front. A one-shot ranker cannot incorporate "actually, not that" — a loop elicits preferences as reactions arrive, spends effort only where there is disagreement, and can explain its compromise, which is what gets a group to accept an outcome.

Q2. What is the LLM actually responsible for, and what should it never do? It should elicit feedback from natural language, explain the current pick, and sense consensus. It should never be trusted to compute the winning option or invent the weights — those are exact, cheap operations that belong in code. Mixing the two is how you get confident, wrong, unauditable decisions.

Q3. Why exponentiated-gradient for the weight update? Because it keeps weights non-negative and normalized automatically and gives a repeatedly-overruled member geometrically more say — and it is a standard online-learning update (multiplicative weights), so it is defensible rather than ad hoc. A raw additive bump can go negative or fail to normalize.

Q4. How do you know when to stop? Define a consensus condition — e.g., the worst-off member's satisfaction clears a bar, or no member objects — plus a hard round cap. Without an explicit stop and a fallback for "no option satisfies everyone," the loop can oscillate indefinitely.

Q5. Isn't this manipulable? Yes. The update is not strategyproof: a member who understands it can exaggerate objections to accumulate weight. Mitigations include capping per-member weight, decaying the influence of repeated objections, or using a strategyproof aggregation rule where manipulation is a real threat. Always log objections so gaming is at least visible.

Q6. The LLM said it "balanced everyone fairly" — do you believe it? Not from the narration. LLMs can produce a plausible rationale that doesn't match what the code did ("unreliable narrator"). Trust the logged weights and the objection history; treat the LLM's explanation as UX, not as ground truth, and evaluate the loop on measured outcomes (worst-off satisfaction, rounds to consensus).

Q7. How would you evaluate such a system? On measurable loop outcomes, not vibes: worst-off satisfaction at consensus, rounds/time to converge, fraction of sessions that reach consensus vs. hit the fallback, and a fairness metric over the final pick. Compare against the one-shot baseline it replaces.

8. When to use / tradeoffs

Reach for LLM mediation when:

A single choice must serve several people whose preferences conflict and emerge through conversation.
Explaining the compromise matters for acceptance (the group must buy in, not just be told).
You can keep the decision math in code and use the LLM only to elicit and explain.

Do NOT use it when:

Situation	Why it breaks	Use instead
No option can satisfy everyone	loop oscillates, never stops	damping + explicit fallback / manual pick
Members will game the weighting	update is not strategyproof	weight caps / strategyproof mechanism
A hard constraint must hold	soft weighting can still pick a violator	filter to a feasible set before the loop
Latency/cost budget is tight	every round is one or more LLM calls	one-shot aggregation, no loop
You need reproducible decisions	LLM elicitation is stochastic	deterministic rules / fixed seeds + logging

Honest limits. The loop optimizes a session snapshot and assumes preferences hold still while it runs; drift breaks it. Convergence is not guaranteed — without damping the weights chase whoever objected last. The LLM layer adds cost, latency, and a narration you must not trust as an audit trail. And "fairer by weight" is not the same as fair: giving the loudest objector more weight can itself be unfair if objection strength reflects confidence rather than need. Keep the weights, objections, and final satisfactions logged, and evaluate on those numbers rather than on the mediator's own account of itself.

An LLM mediator runs a propose → narrate → elicit → reweight loop until consensus, instead of ranking once.
The math is small and lives in code: a weighted score Σwᵢsᵢ, an exponentiated-gradient update that gives objectors more say, and a consensus stop.
The LLM's job is elicitation and explanation — turning language into the feedback signal and narrating the tradeoff — not the arithmetic.
It is online preference elicitation: learn preferences from reactions, spending questions only where there is disagreement.
Boundary: needs stable, honest preferences and a reachable consensus; add damping + a fallback or it oscillates, cap weights or it is gamed, and never trust the LLM's self-narration as the audit trail.

Fair Aggregation: Balancing Utility and Fairness — the weighted group score the loop maximizes each round.
Agent Evaluation — how to measure a looping agent's outcomes rather than trusting its narration.
Autonomous Agents — the broader pattern of agents that act, observe, and adjust.

Resources

Kivinen, J., Warmuth, M. (1997). "Exponentiated Gradient versus Gradient Descent for Linear Predictors." Information and Computation, 132(1), 1–63 — the multiplicative-weights update used for reweighting. (Volume/pages from public record; verify before citing.)
Masthoff, J. (2015). "Group Recommender Systems: Aggregation, Satisfaction and Group Attributes." In Recommender Systems Handbook (2nd ed.), Springer — group decision rules the mediator sits on top of.
Christakopoulou, K., Radlinski, F., Hofmann, K. (2016). "Towards Conversational Recommender Systems." KDD — interactive preference elicitation. (Venue confirmed; DOI/pages not verified here.)

← Previous: Autonomous Agents Next: Consistency Memory: Making Repeated AI Judgments Agree With Each Other →