Response bias, proxy optimisation, flag quality and winner's curse.
Never read raw thumbs as a satisfaction score.
High precision with tiny recall means you see the loud failures only.
Use enough votes before declaring a winner, and keep a holdout.
A proxy that users reward for the wrong reasons will pull the product with it.
Design rules
Log feedback with the trace id and version, so a signal links to the run (module 8) and to the rollout arm (module 9).
Sample for expert labels across categories, including random non-flagged traces, to estimate recall.
Triage into eval cases with category caps so one noisy complaint type does not fill the set (triage_to_eval_cases).
Do not tune on thumbs alone. Require expert review and offline evals; set launch-blocking behavioural criteria.
Guard against sycophancy: include evals where the correct answer disagrees with the user.
Respect privacy: feedback and the conversation behind it are personal data; consent, redaction, retention (Level 10).
Close the loop: tell users when a reported problem is fixed, if the product allows it.
Interview questions, with the follow-ups
How do you use user feedback to improve an agent?
"I log signals with trace ids, sample and triage them by category, have experts label a sample to estimate real failure rates, fix the cause, add the failing case to the eval set, run the CI gate, then roll out gradually and watch guardrails. I treat thumbs as candidates for review, not as ground truth." Follow-up: "Why not optimise thumbs directly?" Users reward agreement as well as correctness; in my simulation selecting by thumbs dropped correctness from 84 to 59 to 66 percent, and at least one widely reported model update was rolled back for being too agreeable.
Your thumbs-up rate is 90 percent. Is the agent good?
"Not necessarily. Only a few percent of users give feedback, and if unhappy users are more likely to speak, the share is biased, which in my simulation underestimated satisfaction by 30 points. The opposite bias is also possible. I would sample outcomes independently and have experts label them." Follow-up: "Can you correct it?" Only if I know or can estimate the response probabilities, for example from a random survey; otherwise I report it as a trend, not a level.
How do you pick between two prompts using user votes?
"A planned A/B test with a pre-computed sample size (module 9), a guardrail set, and expert review of a sample, because choosing the best of many by noisy votes overstates the gain: 78 percent observed versus 73 percent true with 100 votes each." Follow-up: "How many variants should you test?" As few as practical, and confirm the winner on fresh traffic.
What implicit signals would you track for a chat agent?
"Regeneration, immediate rephrasing, abandonment after a response, copying or accepting the output, escalation to a human, and refusal-related drop-off. Each is noisy: in my simulation regeneration had 53 percent precision and 36 percent recall, so I calibrate each against expert labels." Follow-up: "What about agents that act?" Task completion, undo or correction by the user, and approval rejections (Level 8 module 8) are stronger signals than chat reactions.
Common mistakes
Reading thumbs as satisfaction.
Fine-tuning or prompt-tuning directly on raw feedback.
Ignoring non-responders.
Declaring a winner on few votes.
No trace id on feedback, so you cannot reproduce the failure.
Engagement as quality: longer sessions can mean the agent is failing.
Letting one loud category fill the eval set.
Storing feedback with personal data and no retention policy.
What the example does not do
No real feedback data; every rate is assumed.
Independent users and no segments; real feedback varies by user type, time and UI.
Inverse-propensity weighting assumes known rates, which is the hard part in practice.
The agreeableness trade-off is built in, so the 59 to 66 percent figure shows the mechanism, not a measured effect.
No actual prompt-tuning or learning algorithm; only selection among fixed variants.
Optional real experiment (I did not run this): take a real product's thumbs data, have two experts label 200 random and 200 downvoted traces, and measure the precision and recall of downvotes against the expert labels.
Check yourself
Only 2.4 percent of users leave feedback and the raw thumbs-up share is 50 percent, but true satisfaction is 80 percent. Why the gap? (Unhappy users give feedback more often, so the raw share is biased. Re-weighting by the inverse of the response rate corrects it.)
For the curious The winner of ten prompts looks better than it is
Choosing the best of 10 prompts by thumbs on 100 votes each, the winner looked like 78.1 percent but was truly 72.6 percent. With 1,000 votes each the gap was 75.0 against 74.2. Selecting on noisy data overstates the gain, and selecting on thumbs alone can pick agreeable answers over correct ones. All rates here are assumed.
What you will use daily at work
Practice
What it looks like
Log feedback with trace id and version
A signal then links to the run and the rollout arm.
Sample for expert labels
Include random non-flagged traces to estimate recall.
Cap each complaint category
One noisy type should not fill the eval set.
Test for sycophancy
Include cases where the right answer disagrees with the user.
Draft: confirm what feedback fields your product captures and your consent rules for using them.
What you must be able to say (one page)
Feedback is evidence about quality, but a biased and sparse sample. Explicit feedback (thumbs, ratings, edits) is easy to read but needs user effort; implicit feedback (regeneration, rephrasing, abandonment, refusal-triggered churn) is plentiful but must be inferred. Explicit feedback is sparse and suffers from bias. Make feedback cheap and specific (a reason code with the thumb, an edit box) without harming the experience.
Response bias: if unhappy users give feedback more often than happy ones, the raw thumbs-up share is wrong. In my simulation, true satisfaction was 80 percent, the naive share among givers was 50 percent, and only 2.4 percent of users gave any feedback. Re-weighting by the inverse feedback rate recovered 80 percent, but only because I assumed I knew the rates, which you usually do not.
Signals are noisy detectors. As a failure flag in my simulation, a downvote had precision 72 percent but recall 5 percent (it finds few of the real failures); regeneration had precision 53 percent and recall 36 percent. Use them to find candidates and trend lines, not as ground truth.
Winner's curse: choosing the best of 10 prompts by thumbs on 100 votes each, the winner looked like 78.1 percent but was truly 72.6 percent (a random variant: 70.0). With 1,000 votes each the gap shrank to 75.0 vs 74.2. Selecting on noisy data overstates the gain.
Optimising a proxy can lower quality. If users reward agreement as well as correctness, selecting prompts by thumbs picks agreeable variants; the widely reported 2025 rollback of an over-agreeable model update is the real-world example, and the usual remedies are expert evaluators and launch-blocking behavioural criteria. In my simulation (with an agreeableness and correctness trade-off that I assumed), choosing by thumbs gave 59 to 66 percent correctness versus 84 percent when an expert chose.
A good loop: collect signals, triage by category and join to the trace (module 8), have experts label a sample, fix (prompt, tool, retrieval, guardrail), add the case to the eval set (module 2), verify through the CI gate (module 7), roll out gradually (module 9), then watch guardrails and expert review.
Honest limits: all rates are assumed; the trade-off behind the proxy result is built into the simulation, so it illustrates the mechanism, not its size in real products.