Separate chatbot errors into source quality, retrieval, answer generation and action authority. Use repeatable examples to target and verify corrections.
When a chatbot gives a wrong answer, the first reaction may be a longer instruction or a different model. The issue might instead be an outdated document, the wrong information being retrieved, missing context or an answer outside the bot's scope. Turn the failure into a reproducible example first, then identify the stage that needs correction.
Describe the failure as a specific case
Record the question, relevant conversation context, expected answer and approved source supporting it. “The bot is unreliable” is less useful than “It explains this service using an outdated support policy.” A precise case lets technical and content owners investigate the same problem. Avoid introducing unnecessary personal details into the evaluation set.
NIST's generative AI profile addresses the risk of systems presenting inaccurate information confidently. Fluent, persuasive wording therefore cannot replace a correctness check. Assess tone and factual accuracy separately: a polite incorrect answer is still a failure to resolve.
Inspect the source, retrieved information and answer separately
First establish whether the correct information exists in the approved sources. If documents disagree, the business must decide which version applies. If the right source exists, examine what information was available for that question. Retrieving the wrong passage and misinterpreting the right passage call for different work.
Consider a hypothetical service assistant confusing standard support with support provided under a custom project. The documents have similar names but different scope. Clarifying titles and boundaries, then retesting the relevant questions, may address that ambiguity. Adding an instruction to “be more careful” does not resolve contradictory source material.
Choose a correction that matches the failure type
Populate the table with examples from your conversations. Give each correction an owner and a verification case. Avoid accumulating every issue in one general instruction; simplify the information and workflow boundaries first.
| Failure type | Question | Correction focus |
|---|---|---|
| Outdated or conflicting facts | Is the current source established? | Content ownership and version cleanup. |
| Wrong information retrieved | Is the relevant passage found? | Information structure and retrieval. |
| Correct facts misrepresented | Was the answer checked against its source? | Response rules and evaluation examples. |
| Confident out-of-scope answer | Is a handover condition defined? | Scope and human escalation. |
| An uncompleted action reported as done | Does a real system result exist? | Action-result and confirmation alignment. |
Retest the failure and nearby questions
Repeat the problematic question, but also test another wording, a request missing essential information and a similar request outside the scope. A correction may improve one answer while creating unnecessary handovers or false certainty elsewhere. Record results against the same criteria.
For consequential actions such as pricing, appointments or order changes, use the actual system record to establish what happened. Answer-quality review and action verification are different jobs. Until a repeated failure is corrected, narrowing the relevant authority or routing that topic to a person can be practical. This manages the affected workflow without assuming the whole assistant must stop.