Preference Fine-Tuning from User Comparisons
Silence and the absence of written complaints do not reliably indicate satisfaction, because users often complain without correcting outputs or express only general frustration.
The Quiet First Week
Imagine you launch a chatbot and the first week is quiet. Nobody has filed a report, and nobody has written an angry message. It is tempting to conclude that users are happy. This lesson follows what happens when we test that conclusion against the evidence. Feedback from people using an AI application arrives in several forms: the words users choose when they complain, the emotional tone that runs through a conversation, the signals that appear in the model's own replies, and the things people do with a conversation once it is over. Each of these carries information, and each one also carries a risk of misreading.
What do you think happens?
A chatbot launches and receives no complaints in its first week. Does that mean users are satisfied?
Reveal answer
No, silence is not reliable evidence of satisfaction.
Users often complain without trying to correct outputs, and some people simply leave or quietly stop using the product. A missing complaint can hide dissatisfaction as easily as it can reflect satisfaction.
Where Unhappy Users Go Quiet
Complaints are only one channel of feedback, and they are not the most common one. People who are unhappy with an answer do not always say so. Some simply leave the conversation. Some react with a single word of frustration. Some quietly stop using the product altogether. Each of these behaviors is a possible sign of dissatisfaction, and none of them explains what went wrong.
- No written complaint at all: could reflect satisfaction, or could reflect a user who has already given up
- A complaint without any correction: the user saw a problem with the output but did not try to fix it
- A single word of frustration: clearly negative, but it does not say which answer caused the reaction
- Quietly stopping use: a silent exit that produces no text to analyze
The practical lesson is that the quiet channel has to be read on purpose. A team that only reads explicit complaints will see a sample that is biased toward users who were willing to write something down. Negative sentiment also appears as general frustration or disappointment that never names its cause, so even a complaint that is clearly negative may still be unhelpful for finding the fix.
Sorting Complaints into Feedback Groups
When users do write about what went wrong, their complaints tend to fall into recognizable patterns. Researchers working with the FITS (Feedback for Interactive Talk and Search) dataset grouped natural language feedback automatically through clustering, and the result was eight groups.
Each group points to a different kind of failure in the application, and that is what makes the groups useful. A group describes a behavior you could change. The sizes of the groups also matter. The largest group is simply a user restating a demand, which suggests that many complaints are really requests for a second attempt. The smallest group concerns repetition and rudeness. Counts tell you where to look first, but a small group can still matter a great deal if the failure it describes is serious.
Sorting a complaint into a group is only worthwhile if the group leads to a change. Read a pattern of complaints as a description of the behavior you want to fix.
Reading Sentiment Across a Conversation
Sentiment analysis looks at the emotional tone of a user's messages rather than the content of a complaint. A user may express frustration, disappointment, or ridicule without ever explaining why. Even a very short exclamation of irritation carries a negative signal, although it tells you nothing about which answer caused it.
The more useful idea is that sentiment changes over the course of a conversation. Some call centers track the voices of callers throughout a call, on the reasoning that a caller who grows steadily louder signals that something is going wrong. The same logic applies to text. The direction of change is often more informative than any single message.
Implicit Signals and Their Ambiguity
Implicit feedback is inferred from what users do rather than from what they say. Regenerating a response, deleting, renaming, sharing, and bookmarking a conversation can all be read as signals of satisfaction or dissatisfaction. Because users never have to write anything, these signals are far more plentiful than complaints.
Implicit signals are abundant but ambiguous, so each one has to be interpreted in context and corroborated with other evidence. Explicit feedback is deliberate and easy to interpret, but it costs users effort. Implicit feedback arrives for free and in large volume, but each signal is noisy. The sensible response to noisy signals is to add more of them and see whether they agree.
Length, Diversity, and Refusals
Three further signals come from the conversation itself. Conversation length is commonly tracked, but it has no fixed meaning. Dialogue diversity, which can be measured by the count of distinct tokens or distinct topics in a conversation, helps separate productive length from circling. Refusal rate, meaning how often the model declines to answer or hedges heavily, is a warning sign, because replies such as 'Sorry, I don't know that one' suggest that the user is probably unhappy.
| Metric | What it may indicate | Where it can mislead |
|---|---|---|
| Conversation length | Engagement, or inefficiency | Good in an AI companion, a sign of trouble in customer support |
| Dialogue diversity | New ground being covered, or circling | Must be read alongside length to tell the two apart |
| Refusal rate | Application failing to deliver answers | A high rate signals trouble, but it does not name the cause |
| Sentiment shift | Issue resolved (negative to positive) or failing (calm to angry) | Direction matters more than any single message |
Four conversation-level signals and their ambiguities
Reading a Long Support Conversation
A customer support chatbot logs a conversation with 40 turns. The user's messages start out irritated and stay that way. The refusal rate across the conversation is high, and the topics mentioned in the last 20 turns repeat those from the first 20. What does this conversation suggest about application quality?
- 1Check the purpose of the application
This is a productivity chatbot for customer support. Length is ambiguous, but for a support tool a long conversation can mean the bot is inefficient at helping the user resolve an issue.
- 2Check dialogue diversity
The later topics repeat the earlier ones, so the conversation is circling rather than covering new ground. Length and diversity together point toward a problem, not productive engagement.
- 3Check sentiment direction
The user stays irritated from start to finish. There is no shift toward a happier tone, so the sentiment does not suggest the issue was resolved.
- 4Check the refusal rate
A high refusal rate is a warning sign that the application is failing to deliver answers, and it corroborates the other signals.
- 5Combine the evidence
Each signal is ambiguous alone, but together they agree. The conversation points to a failure to resolve the issue, and the repeated topics suggest the bot needs a fix in how it handles that kind of request.
The four signals converge on inefficiency and failure to resolve the issue. A single long conversation would not justify that conclusion; the agreement across length, diversity, sentiment, and refusals does.
The same long conversation can be good news in another application. In an AI companion, a long exchange can mean the user enjoys the conversation. Before judging length, identify what the application is for.
Common Misreadings of Feedback
Common mistake Treating silence as satisfaction
What it looks likeA chatbot gets no complaints in its first week, so the team concludes users are happy.
Why it failsUsers often complain without correcting outputs, or leave and stop using the product without writing anything.
Do this insteadTrack quiet channels such as leaving and stopping use, and look for corroborating signals before drawing a conclusion.
Common mistake Reading one sentiment message as the whole story
What it looks likeA user writes a single irritated line near the start of a conversation and the team marks the whole conversation as failed.
Why it failsA single message says nothing about which answer caused it, and the direction of change over the conversation is often more informative.
Do this insteadRead the sentiment across the conversation and note whether the tone moves toward or away from resolution.
Common mistake Assuming long conversations are always good
What it looks likeA support bot's conversations get longer, and the team celebrates higher engagement.
Why it failsLength has no fixed meaning; in a productivity chatbot, length can mean the bot is inefficient.
Do this insteadPair length with dialogue diversity and the purpose of the application before interpreting it.
Common mistake Treating an implicit signal as a fixed verdict
What it looks likeA user deletes a conversation, and the team concludes the answer was wrong.
Why it failsDeleting can be read as satisfaction or dissatisfaction, and the meaning depends on context.
Do this insteadCorroborate the signal with other evidence, such as a follow-up rephrasing or a sentiment shift.
Common mistake Ignoring small complaint groups, which can still reveal serious failures
Interpreting a Chatbot's Feedback
A chatbot's logs show three things: 25 percent of conversations contain a sentence like 'Sorry, I don't know that one,' most users who rephrase a question after sharing their conversation are rephrasing the same unanswered question, and the largest complaint group is users restating a demand. Which of these signals points most directly toward a quality problem that could be fixed, and why?
Hints
- Think about which signal describes the application failing to deliver answers.
- Consider whether the largest complaint group describes a behavior you could change.
- Check whether the rephrasing signal is corroborated by another signal.
Explain in one or two sentences why a quiet week after launch is not reliable evidence of satisfaction, naming at least one quiet behavior that could hide dissatisfaction.
Hints
- Recall the difference between complaining and correcting an output.
- Think about what a user might do without writing anything.
Summary Takeaways
- 1Silence and missing complaints are not reliable evidence of satisfaction, because users often complain without correcting outputs, or leave without saying anything.
- 2Natural language complaints fall into eight groups found by clustering, and each group points to a different failure that may guide a specific fix.
- 3Implicit signals such as regeneration, deleting, renaming, and sharing are plentiful but ambiguous, so each must be interpreted in context and corroborated.
- 4Length, dialogue diversity, sentiment shifts, and refusal rate are evidence about quality, but each needs the application's purpose and the other signals to be read correctly.
At a glance
- Silence and the absence of written complaints do not reliably indicate satisfaction, because users often complain without correcting outputs or leave without saying anything.
- Written complaints fall into eight groups discovered by clustering, and each group points to a different kind of failure that can guide a specific fix.
- Implicit signals such as regeneration, deleting, renaming, and sharing are abundant but ambiguous, so each must be interpreted in context and corroborated with other evidence.
- Conversation length, dialogue diversity, sentiment shifts, and refusal rate each carry information about quality, and their meaning depends on the application's purpose.