Concepts / Evaluating Conversational AI Applications

Evaluating Conversational AI Applications

Conversation length is another commonly tracked signal, but it has no fixed meaning.

  • Programming

A Quiet First Week

Imagine you launch a chatbot and the first week of feedback is quiet. Nobody has filed a report, and nobody has written an angry message. It is tempting to conclude that users are happy. This section argues that the quiet is not reliable 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?

After a quiet first week with no complaints, can you conclude that users are satisfied?

  • Yes, silence means satisfaction

  • No, silence is not reliable evidence

Reveal answer
Answer:

No, silence is not reliable evidence of satisfaction.

Users often complain without trying to correct outputs, and some users simply leave or quietly stop using the product. Silence can hide dissatisfaction as easily as it reflects happiness.

Where Dissatisfaction Hides

Two questions separate the possible behaviors. The first is whether the user complains in writing. The second is whether the user tries to correct the output. Combining the two answers gives four situations, and they do not all look alike from the outside.

Complains andcorrectsDissatisfaction is visibleSilent, correctsoutputDissatisfaction shows ineditsComplains, nocorrectionFrustration is voiced, nofix triedSilent, leavesDissatisfaction stayshidden
How do the four combinations of complaining or not complaining and correcting or not correcting the output differ, and which one hides dissatisfaction?

The source material points out that users often complain about outputs without trying to correct them. An unhappy person may simply leave, may react with a single word of frustration, or may quietly stop using the product. Complaints are only one channel, and they are not the most common one. The silent-and-leaves case is the most dangerous, because nothing in the written feedback reveals that anything went wrong. Negative sentiment can also appear as a general expression of frustration or disappointment that never explains its cause.

Eight Groups of Written Complaints

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. Clustering here means letting the data organize itself into groups of similar messages, rather than deciding the categories in advance. Each group is useful because it points to a different kind of failure in the application, and that failure can guide a specific fix, such as a change to the prompt.

Written complaintsNatural language feedbackEight feedback groupsFound by clustering theFITS datasetLargest groupA user restating a demandSix other groupsEach marks a differentfailureSmallest groupRepetition and rudenessclustered intocontainscontainscontains
How do the eight feedback groups sit under the broader complaint category, and where does a given complaint belong?

Notice the spread of the counts. 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 it describes a serious failure. Categorizing complaints is only useful if the category leads to a change. The idea is to read a pattern of complaints as a description of the behavior you want to fix.

Worked example

Placing a Single Complaint

A user writes: 'That is not what I asked. Please answer the question about my billing date.' The reply was a general description of billing, not a date. Which kind of failure does this complaint describe, and what should the team read from it?

  1. 1
    Read the content

    The user is restating the original demand, which is about a specific billing date, and says the answer missed it.

  2. 2
    Match to a group

    A message that asks for a second attempt at the same request resembles the largest group in the clustering, which the source describes as users restating a demand.

  3. 3
    Read it as a behavior

    The pattern describes the model failing to answer the actual question. The fix to look for is a change in how the application handles direct questions, not a general claim that users are unhappy.

Result

The complaint belongs to the restated-demand pattern, and it points to a specific failure to answer the question asked.

Implicit Signals and Their Ambiguity

Implicit feedback is inferred from what users do rather than from what they say. Actions such as 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 much more plentiful than complaints. 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.

RegeneratingA response is requestedagainPossible satisfactionThe action may mean theresult was usefulDeletingA conversation is removedPossibledissatisfactionThe same action may meanthe result failedRenamingA conversation is relabeledSharingA conversation is passed onmay meanmay meanmay meanmay meanmay mean
For each implicit action, what different user intentions could produce the same observed behavior?

The same observed action can come from opposite intentions. A regeneration might mean the first answer was wrong, or it might mean the user wants an alternative they already find good. A deletion might reflect dislike, or simply tidying up. Sharing could be praise or could be a way of showing a failure to someone else. Because each action is ambiguous, the source material insists that each signal be interpreted in context and corroborated with other evidence.

The sensible response to noisy implicit signals is to add more of them. The source gives the example of a user who rephrases a question after sharing a conversation. That pattern suggests the conversation did not meet the user's expectations, and the rephrasing is the clarifying signal that the sharing alone could not provide. One ambiguous action becomes more informative when a second action follows it.

Reading a Sentiment Curve

Sentiment analysis looks at the emotional tone of a user's messages instead of the content of a complaint. A user may express frustration, disappointment, or ridicule without ever explaining why. A message as short as an exclamation of irritation still carries a negative signal, even though it tells you nothing about which answer caused it. The more useful idea is that sentiment changes over the course of a conversation. The source describes how 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.

Opening messagesNegative toneModel replyA clarifying answerMiddle messagesTone begins to easeModel replyThe issue is addressedClosing messagesCalmer tonenext turnnext turnnext turnnext turn
How does user sentiment change over successive turns, and where does a negative shift appear relative to the model's responses?

In this generated example, the conversation starts with a negative tone and ends with a calmer one. The change is the evidence. It suggests the issue was resolved, even though the user was unhappy at the start. The direction of change is often more informative than any single message. A negative shift that appears right after a model reply, however, points to that reply as the place where the application went wrong.

Refusals, Length, and Diversity

Some feedback can be inferred from the model's own responses. The refusal rate, meaning how often the model declines to answer or hedges heavily, is an important signal. Replies such as 'Sorry, I don't know that one', or a statement that the model cannot do something because it is a language model, suggest that the user is probably unhappy. A high refusal rate is therefore a warning sign that the application is failing to deliver answers.

Conversation length is another commonly tracked signal, but it has no fixed meaning. Whether a long conversation is good depends entirely on what the application is for. A long conversation with an AI companion can mean the user enjoys the exchange. A long conversation with a productivity chatbot, such as customer support, can mean the bot is inefficient at helping the user resolve an issue.

Because length is ambiguous, the source pairs it with dialogue diversity, which can be measured by the count of distinct tokens or distinct topics in a conversation. Length and diversity together reveal something length alone cannot. A long conversation that keeps covering new ground is different from one that keeps circling. Read together with refusal rate and sentiment, these measures give evidence about quality rather than a single verdict.

Mistakes Evaluators Make

  • Common mistake

    Treating a quiet channel as proof of satisfaction

    What it looks like

    A team sees no complaints in week one and reports that users are happy.

    Why it fails

    Users often complain without correcting outputs, or leave without saying anything at all.

    Do this instead

    Look at implicit actions, sentiment, and refusals alongside any written feedback before judging satisfaction.

  • Common mistake

    Reading one implicit action as a clear verdict

    What it looks like

    Every deletion is counted as dislike of the answer.

    Why it fails

    Regeneration, deleting, renaming, and sharing are each ambiguous and can come from different intentions.

    Do this instead

    Interpret each action in context and corroborate it with another signal, such as a rephrased question.

  • Common mistake

    Judging length without knowing the application's purpose

    Why it fails

    The same length can be good for a companion app and bad for a support bot.

    Do this instead

    Decide what success looks like for the application first, then interpret length against that goal.

  • Common mistake

    Ignoring small complaint groups

    Why it fails

    Counts show where to look first, but the source notes a small group can still describe a serious failure.

Practice Reading the Signals

MEDIUM

A chatbot for customer support shows three signs in one week: a long average conversation length, a rising refusal rate, and many users who rephrase their question after sharing a conversation. Which evidence supports the view that the application is failing, and what would you check next to confirm it?

Hints
  • Ask what a long conversation means for a support bot specifically.
  • Refusal replies are described as a sign that users are probably unhappy.
  • A rephrased question after sharing is the clarifying signal the source describes.

Summary

  1. 1
    Silence and the absence of written complaints do not reliably indicate satisfaction, because users often complain without correcting outputs or leave without saying anything.
  2. 2
    Written complaints fall into eight groups found by clustering the FITS dataset, and each group points to a different failure that can guide a specific fix.
  3. 3
    Implicit signals such as regeneration, deleting, renaming, and sharing are abundant but ambiguous, so each must be interpreted in context and corroborated.
  4. 4
    Sentiment shifts across a conversation, refusal rate, conversation length, and dialogue diversity are evidence about quality, and each must be read against the application's purpose.

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 found by clustering the FITS dataset, and each group points to a different 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.
  • Sentiment shifts, refusal rate, conversation length, and dialogue diversity are evidence about quality, and each must be read against the application's purpose.

More concepts starting with E