Evaluating AI Application Quality

Imagine you have just finished building an AI application on your own. Perhaps it is a chatbot that answers questions from people who write to a company's support desk. The model runs, the answers look reasonable in a few demos, and you feel ready to show it to the world. Before you do, there is a question that is easy to skip: how will you know whether the application is succeeding?

Without a definition of success, you cannot tell a useful launch from an expensive experiment, and you cannot tell which changes made things better. This article explains how to define that success in advance, which families of metrics to draw on, and how to decide whether a measured result is good enough for a particular use.

The first metric family to define is the business metric, meaning a measure of how the application changes what the business actually does. For a customer support chatbot, the questions a team can ask are concrete. What share of incoming customer messages does the bot handle without a person getting involved? How many more messages can the operation process once the bot is running? How quickly do customers get a reply compared with before? How much human labor is freed up for work that needs a person?

Notice that every item on that list is written as a question about the business, not about the model. The four measures that come out of those questions are automation rate, throughput, response time, and labor saved. A business metric tells you whether the application is doing its job in the setting where it is deployed. That is why it is usually treated as the most important of the metric families. The other families exist to support it.

A tempting shortcut is to assume that if the bot resolves more messages, customers must be happier. The source warns against that assumption. A chatbot can answer a larger volume of questions and still leave people frustrated, for example if the answers are unhelpful and customers have to write in again. Higher volume of answered messages does not by itself show that users are happy.

For this reason customer satisfaction and customer feedback need their own place in the set of metrics. Feedback channels are one way to hear that signal directly. Satisfaction evidence and business evidence are separate: one can look strong while the other is weak, so the team should track both.

Business and satisfaction metrics describe what happens after an application is live. A second question comes earlier: how good must the application be before anyone is allowed to use it at all? The answer is the usefulness threshold, which is the minimum level of performance an AI application needs in order to be worth putting in front of people. Setting this threshold in advance protects you from shipping a product that is not ready, because you have already written down what ready means.

The usefulness threshold is not a single number. It is built from metric groups. The source names three that belong to it: quality, latency, and cost. A fourth group, covering properties such as interpretability and fairness, is also listed as something to consider. The diagram below traces what happens to a draft as it is checked against the threshold.

Read the diagram as a loop. A draft is measured and found short of the bar. The team does not release it. Instead it works on the weak metric and measures again. The product only leaves this loop when the measured performance clears the threshold. The practical value of writing the threshold down early is that the decision to ship no longer depends on how impressive a demo feels on a given afternoon.

The three named groups answer different questions, and an application can do well on one while failing another. The groups are summarized in the comparison below, and each is then described in turn.

A response can be accurate but arrive too slowly to help a customer in the middle of a chat. A fast, accurate system can still be too expensive to run at the volume the business needs. Because of these trade-offs, a threshold should name all three groups rather than only the one that looks best.

The metric families are not a flat list. They are connected. Business metrics describe the purpose of the application. Customer satisfaction checks whether that purpose is being served from the user's side. The usefulness threshold sets the minimum standard, and it is made of quality, latency, and cost. Interpretability and fairness sit alongside that standard as further things to consider. The concept map below shows how these pieces relate.

There is no universal number for acceptable latency. What counts as acceptable depends on your use case, and the right bar is set by what the current process delivers to users. The source illustrates this with a comparison. Suppose every customer request is currently handled by a human, and the median response time is one hour. In that setting, a bot that answers in a few seconds is a large improvement, and even a slower bot could be good enough.