What the documents look like
Customer-service knowledge base maintenance covers FAQ entries, reply templates, product specification tables and escalation tickets. The work is upstream question-and-answer preparation. It does not approve refunds or returns, and a retrieval hit is not an approval, a signature or a completed business action.
The material comes from the customer-service system, product detail pages, after-sales issue statistics and quality-inspection sampling. Customer-service supervisors, knowledge base operators and product operators maintain it together, with updates on a weekly or monthly rhythm. In an operating review or an exception review, the retrieval step decides which FAQ wording, template text, specification values and ticket states are pulled into the review discussion. A retrieved passage that is treated as a finished conclusion, when the underlying ticket is still pending, produces a review record that overstates what happened.
The retrieval step also sits before any business verification. The knowledge base search node returns reference content; it does not check whether a refund was approved, whether a signature exists, or whether a downstream system was updated. Those remain separate implementation concerns.
Constraints at the retrieval step
The knowledge base search node can associate one or more knowledge bases that use the same vector model. Knowledge bases on different vector models cannot be associated together. The check here is to read the vector model identifier on each knowledge base, exclude the ones that do not match, and record what was observed. A cross-model retrieval run is not performed to compare recall.
Search modes are semantic retrieval, full-text retrieval and hybrid retrieval. Hybrid retrieval merges the two result sets through RRF. Rerank performs a second ordering of candidates and produces a score between 0 and 1. The minimum relevance value takes effect only under semantic retrieval or when result reranking is used. It is a filter threshold, not a final ordering rule, and it does not filter by business ownership, entity or access permission.
The reference cap is expressed in tokens per search, not as a fixed item count. Question optimization performs coreference removal and question expansion before retrieval and adds one model call. Reference content is output as an array whose length can be zero, and the downstream chain still runs when the length is zero.
Image retrieval is an optional path. It requires image input and the relevant model capability, and whether an image is found also depends on whether an index was built at ingestion time. Rerank requires a rerank model and is used according to configuration. These paths are not executed on every request.
A hypothetical paper exercise sample is set out here for illustration only. A knowledge base operator prepares a monthly review and holds one FAQ entry whose source text reads: "After a return request is submitted, the merchant reviews it within 48 hours; after approval the item enters the return-shipment stage, and the return address is the one shown on the ticket page. This entry applies to requests submitted between 1 March 2025 and 31 March 2025." In the same batch, an escalation ticket record shows: "Ticket status is pending review." The record has no reviewer signature field and no approved or rejected conclusion. A proposed review sentence reads: "This entry confirms that the return requests were all approved and entered the return-shipment stage."
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Associated knowledge bases | Associate only the FAQ knowledge base that uses the same vector model | Read the vector model identifier on each knowledge base, exclude those that do not match, and do not run cross-model retrieval to compare recall |
| Search mode | Observe semantic retrieval and full-text retrieval separately first | Run the same test question through both modes and compare the returned content; no single mode is assumed to suit all material |
| Reference cap | Hypothetical starting point of 2000 tokens | Test with actual material of different lengths, compare whether content stays complete against a shorter cap, then adjust |
| Minimum relevance | Hypothetical starting point of 0.4 | Label relevant and irrelevant samples first, compare results before and after filtering, and note that it applies only under semantic retrieval or reranking |
| Question optimization | Enabled for short questions and multi-turn follow-ups | Compare the original question with the optimized question and check whether the subject was altered |
| Rerank | Enabled when a rerank model is available and configured | Compare candidate order before and after reranking and confirm the candidate set is sufficient |
Three common errors
- Treating a retrieval hit as an authorization conclusion. The input is the FAQ entry source text above together with the pending-review ticket record. The comparison is between the review process described in the entry and the actual status field on the ticket. The observable result is that the ticket carries only a pending-review status with no signature field and no conclusion field, so the proposed sentence claiming that all requests were approved and entered the return-shipment stage is not supported by the source text.
- Treating minimum relevance as an entity or permission filter. The input is the same test question and two labelled sample sets. The comparison is between the semantic or rerank score and the filter threshold. The observable result is that low-scoring content is filtered out; this is unrelated to business ownership or access permission, and no statement can be made that unrelated businesses were excluded.
- Treating an empty reference output as a business failure. The input is an explicit paper array [] and a downstream reference-handling design. The comparison is between the node output length and the downstream handling logic. The observable result is that the chain still runs at length zero. No claim can be made that a retrieval rule must return an empty result.
How to verify the setup
- Input the FAQ entry source text above and the proposed review sentence. Compare the entry's applicable period, its description of the review process and the ticket status field. Observe whether the proposed sentence goes beyond what the source text supports. If it states that all requests were approved while the ticket remains pending review, record the sentence as unsupported.
- Input the same test question and run semantic retrieval and full-text retrieval separately. Compare the returned content from each path and the minimum-relevance filtering result. Observe whether there is a difference in hits for numbers or proper nouns. If full-text retrieval returns a hit and semantic retrieval does not, record this as a mode difference and do not label it as a missed recall.
- Input an explicit paper array []. Compare the reference-content output length of the knowledge base search node with the downstream chain. Observe whether the chain runs at length zero. If the downstream design does not handle an empty array, record this as a design gap to be filled, and do not claim that actual retrieval must return an empty result.