When the AI customer service gives irrelevant and off-topic responses, should we revise the prompt first or the knowledge base first?

When a user asks "When will my refund arrive?", the assistant replies with a general policy statement — the root cause of this irrelevant response may lie in the routing, retrieval, knowledge version or generation link. This article dismantles the troubleshooting chain through real cases, from log restoration to intent recognition, knowledge retrieval, and model generation, teaching you to locate problems with evidence and avoid blindly modifying prompt words.

The user asks "When will my refund arrive?" on the order page, and the assistant replies "After the refund application is submitted, the platform will refund via the original payment method, please wait patiently". What the user wants is the progress of their own fund, but what the system gives is a general description.

When encountering this situation, do not rush to make changes. The reason for the irrelevant response may lie in routing, retrieval, knowledge version, generation, or even the fact that real-time data is not called at all. If you modify the prompt words immediately, most of the changes will be useless.

Take this case as an example. That reply is extracted from the general refund description in the help center, while the refund status of this order is actually "completed", and the assistant did not call the order interface at that time. The personal progress query did not even reach the step of real-time query.

But this is only an assumption. When it comes to the online environment, you must first confirm what actually happened at that time. You need to check the records of that session: the user's original words and time, entry and order context, intent and routing results, retrieval candidates and versions, context sent to the model, tool calls and returns, prompt words and model configuration versions, and the final response. Without these, you can only reproduce similar symptoms, but cannot explain why the wrong response was made at that time.

First pull out the logs of that session

This request can be restored according to the log: the user enters from the order page; the user asks when the refund will arrive; the system routes the request to the policy Q&A; the retrieval returns the general refund description; the refund query is not called; the model organizes a policy response based on these materials.

Following this chain to check, the scope of troubleshooting will be narrowed. If the order page does not transmit the context to the customer service, the personal progress query cannot be started at all; if the context is transmitted, check whether the routing has identified "query this order"; if the routing is correct, check whether the refund interface is called and what it returns.

If the retrieval results or interface records are not kept in the logs, use the authorized test account and fixed order status to replay this question in the test environment, and fix the knowledge version, prompt words, model, and configuration. Replay can show whether the same phenomenon will still occur under the current configuration; if the online status has changed and the original configuration is not archived, it cannot prove the root cause at that time. You need to grasp this distinction accurately.

Is he asking for a rule, or the status of his own order

"How long does it take for the refund to arrive after approval" is asking for general rules; "When will my refund arrive" is checking his own order. These two questions are very similar, but their processing paths may be completely different. If the system can read the context of the order page, the context must be taken into account during classification; if the user enters from the public entrance, confirm the order object first, and then decide whether to query the real-time status.

For the intent recognition part, do not only look at the question expression, check the actual routing result, and then use a set of boundary similar questions to verify the classification:

"How long does it usually take for the refund to arrive?" — query general rules.

"After the refund is approved, how many days does it usually take to arrive?" — query rules, the response should explain the applicable conditions.

"Which step is my refund at now?" — query personal progress, which requires order context and business interface.

"Order number..., why hasn't this refund arrived yet?" — query personal progress and explain the current status; if the status cannot explain the reason, transfer to manual review.

This set of questions should be tested together with the entry conditions. Only adding the question expressions to the examples cannot prove that the classification is the root cause. You need to check the context at that time, the routing output, and whether the adjacent rule questions still follow the original path after modification.

If the routing is correct, then check the knowledge retrieval. Check the retrieval candidates, sorting, document version, and the final fragment injected into the model. If the correct document exists in the candidates but is ranked low, it is completely different from the situation that the correct content does not exist in the knowledge base at all. If two versions of rules (old and new) are retrieved, first confirm which one is valid, then adjust the version tag or retrieval configuration.

The knowledge base stores refund rules, application conditions, and handling instructions; the current progress of a certain order must be queried from the order or payment system. Sometimes the two participate in the response together: first check the order status, and then cite the rules to explain this status. During troubleshooting, you need to distinguish where the facts in the response come from respectively.

If the materials are correct, then check how the model generates the response

If the routing, retrieval candidates, and the context sent to the model all meet expectations, but the response still says "refund has arrived" instead of "review passed", then it is time to check the generation part.

Expand the content sent to the model in this session: what the user asked, what the order status and update time are, whether the retrieved fragments are complete, which version the prompt words and model configuration are, and what extra or missing content is in the final response. The correct retrieval result does not mean that the injected context is necessarily complete; the fragments may be truncated, and the meaning of the status field may be lost during splicing.

Put these information into an acceptance example:

Entry and context: Logged-in user, entering from the personal order detail page; order ownership verification passed. User question: "When will my refund arrive?" Interface return: Refund has been approved, refund instruction has not been issued; update time is October 8; no estimated arrival time. Retrieved content: Currently valid refund rules, explaining the subsequent processing links after approval. Expected response points: Explain that the review has been passed and the refund instruction has not been issued; inform the update time; do not fill in the specific arrival date; provide the manual review entrance. Record version: Routing configuration, retrieval configuration, prompt words, model version and interface return time.

If the "refund instruction has not been issued" is missing in the model context, check the splicing or truncation; if the context is complete but the response still claims that "the fund has arrived", check the generation instructions and model parameter changes; if the interface field itself mixes the review completion and refund completion, modify the business field definition first. The part to be modified must match the evidence.

After modifying one point, test all related links

The troubleshooting form can keep the problem as a reviewable record:

If one repair modifies both the knowledge content and the retrieval configuration at the same time, record these two items as a group of changes, compare the candidates and responses before and after the modification, and re-run the relevant core examples. If the prompt words, model or global configuration changes, run the complete core regression set to check whether other intents, statuses, and manual transfers are degraded. After the repair, record the example results, so that there is evidence to check when encountering similar problems next time.

This article is from the WeChat official account "Everyone is a Product Manager" (ID: woshipm), author: Wang Meng, published with authorization from 36Kr.