Why are continuous fixes in the production environment a risky strategy?
Why can’t we simply improve the chatbot by deploying it in production and fixing errors on the fly? Let’s explain this with an example.
Company X signed a contract with Company Y to create an AI chatbot for a university website. It was agreed that an MVP chatbot would be quickly deployed, and Company Y would be responsible for ongoing bug fixes. After deploying the chatbot, the situation could look like this:
- The chatbot does not list all the required documents in response to the question: “What documents are needed to enroll in studies?”
- Company X reports the bug to Company Y.
- Company Y informs that it has made configuration changes, which solved the problem – the chatbot now answers the above question correctly.
- Success? Not quite. It turns out that a bug fixed a month earlier (the chatbot recommending psychology to everyone) has returned.
- Company Y once again modifies the configuration, fixing both the psychology recommendation bug and the one related to documents.
- After the fixes, the chatbot answers both questions correctly. However, soon users notice that in some cases the chatbot responds in Chinese, and its overall rating among users drops compared to the initial state.
What to do when it’s impossible to predict every question?
AI-based applications differ from traditional ones because errors may occur even if the code contains no logical mistakes. Additionally, in the case of chatbots, it is obvious that it is impossible to test every possible scenario before introducing changes into production. However, there are solutions that can significantly reduce the risk of regression. So what was Company Y missing? Benchmark tests!
What are benchmark tests and how to use them?
When creating an AI chatbot, it is crucial to prepare a set of benchmark questions that allow evaluation of how well the current version of the solution performs. These questions should reflect the most frequently asked queries in a given context and cover as broad a range of potential chatbot applications as possible.
When we have such a set of benchmark questions and the chatbot achieves 80% effectiveness, any change that lowers this result – for example, to 60% – should not be deployed (even if it fixes a reported bug). A well-prepared set of benchmark questions therefore provides effective protection against introducing regression into the chatbot.
Example:
Question: How can I contact the administration office?
Evaluation criteria:
- The answer contains the phone number “123 456 789”.
- The answer has a formal tone.
There should be as many such questions as possible, and their minimum number depends on the complexity and scope of knowledge the chatbot is expected to cover. From our experience, the number of benchmark questions should generally not be fewer than 15, and in more complex cases may reach up to 50.
Why are benchmark tests necessary?
In all generative AI-based solutions, benchmark tests play a crucial role in assessing whether the introduced changes actually improve the system. Without them, the development of tools would rely solely on the programmer’s subjective “I think it works,” which could lead to stagnation and repeating the same mistakes instead of real progress.
Returning to the earlier example: despite the work done and a series of quick fixes, the chatbot ultimately performed worse than before modifications began. This could have been avoided if a well-defined set of benchmark tests had been applied.
Benchmark tests are particularly important for chatbots, because RAG systems (which we describe in other articles on our blog) offer vast configuration possibilities. Different configurations work for different applications – for example, one setup will be suitable for a chatbot helping with career path choices (where the knowledge base is one large PDF), and another for a chatbot advising on purchasing computer components (where the knowledge base is a specification of thousands of products). Without benchmark tests, it is difficult to objectively assess which configuration best meets the requirements of a given use case.
Automated chatbot testing
We’ve already mentioned that the number of test cases in benchmark tests can reach up to 50 examples. Does this mean that every configuration change requires manually testing and evaluating all 50 questions? Of course not! Modern language models (LLMs) are advanced enough to automatically assess whether a given answer meets the specified requirements. This makes full automation of the testing process possible.
In our Software House’s AI Chatbot – X-TALK (more information can be found here: X-TALK – Intelligent data-driven automation), we implemented exactly this functionality. New clients can define benchmark questions along with response specifications and measure the effectiveness of the chatbot’s current configuration.
Thanks to this, instead of wasting long hours on manual testing and fixes, the X-TALK tool enables quick and efficient delivery of a well-functioning AI chatbot that meets user expectations.
Want to test X-TALK? Write to us!
