What the documents look like
Customer-service knowledge base maintenance works on front-line answer materials: FAQ entries, reply templates, product parameter tables and escalation tickets. These materials come from the customer-service system, product detail pages, after-sales issue statistics and quality spot checks. The typical roles involved are customer-service supervisors, knowledge base operators and product operators. This page covers the store-service and internal-training task, where retrieval and recall exist so that store staff and trainees receive answer material that matches the question in front of them.
The distinguishing point of this category is that knowledge base maintenance is preparatory answer work. It does not approve refunds directly. When the material is wrong, the visible results are answers that miss the question, escalated complaints or failed training. Retrieval therefore has to let a reviewer compare recalled content against the original material.
A hypothetical drill sample: a store customer-service supervisor prepared an internal-training FAQ entry. The original text reads: "Q: A customer asks to return an A-type rice cooker on day 8 after purchase. How should the store reply? A: The store first registers a ticket, and the after-sales team contacts the customer within 2 working days after receiving the ticket. This entry applies to store service and internal training and is not used for external commitments." A draft sentence awaiting judgment reads: "The customer asks to return on day 8; the store may agree to the refund directly." The sample subject is the store customer-service supervisor, the object is an A-type rice cooker return inquiry, the state is ticket registered and awaiting after-sales contact, and the effective scope is store service and internal training.
Constraints at the retrieval step
A knowledge base is made of libraries, collections and data. The smallest search unit is the library; collections only classify data and do not affect search results. One group of data can map to multiple vectors. During retrieval, vectors are recalled first, then the vector ID is used to find the original data in the MongoDB dataset.datas table. When the same original data is hit by more than one route, the results are merged and the vector score takes the highest value. The knowledge base search node can associate one or more knowledge bases that use the same vector model. Libraries using different vector models cannot be associated together.
Retrieval does not perform authorization judgment. Semantic similarity and the minimum relevance value are filtering thresholds; they do not act as entity isolation or permission filters. A retrieved item does not mean the caller has the right to use it. In store service and internal training, handover materials, operation requests and authorization states each need separate verification. A retrieval action or a filled form does not constitute authorization execution.
The citation output is an array and its length can be 0. Even when nothing is found, the output link still runs through. Image retrieval is not a separate capability outside the knowledge base; it adds an image input path to the existing search chain, and it depends on whether a vision model is configured or whether the vector model supports image vectors, plus whether an image index was built at ingestion time.
Configuration and implementation checks
The table below lists settings already described in the official documentation, or implementation check items, around this sample. The values are hypothetical trial starting points for this exercise, used for comparison against another value. They are not official defaults.
| Configuration item | Hypothetical trial starting point | Reason and comparison method |
|---|---|---|
| Associated knowledge bases | Associate only the single library holding the FAQ entry | Check that its vector model identifier matches the product parameter library; exclude mismatched libraries and do not run cross-model retrieval |
| Search mode | Run semantic search and full-text search separately | Use the same test question to compare the two recall sets, then decide whether to use hybrid search with RRF |
| Citation limit | Set to a token amount that covers one complete FAQ entry | Test with materials of different lengths to see whether cited content stays complete, then adjust the limit |
| Minimum relevance | Label related and unrelated samples first, then set a threshold | This value takes effect only in semantic search or when result reranking is used; compare filtering against the labeled results |
| Question optimization | Enable for multi-turn follow-ups and short questions | Compare the original question with the optimized question and check whether the subject was altered |
| Result reranking | Enable ReRank when candidates are numerous | Rerank scores fall in the 0-1 range; compare filtering by score; when no rerank model is configured, do not enable it |
Three common errors
- Treating a retrieval hit as authorization approval. The input is the sample FAQ entry above; the comparison object is the draft sentence "the store may agree to the refund directly"; the observable result is that the draft conflicts with the original text "the after-sales team contacts the customer within 2 working days after receiving the ticket." The original text does not state that the store may refund directly. The draft is unsupported and cannot be used to execute a refund.
- Associating knowledge bases across vector models. The input is the vector model identifier of the FAQ library and of the product parameter library; the comparison is whether the two identifiers match; the observable result is that a mismatched library is excluded and no joint association is performed. The documentation does not state what happens after a joint association, so actual observation must be recorded rather than inferred.
- Treating a pending request as an approved operation. The input is an operations handover request whose state is pending review; the comparison object is signed or effective authorization material; the observable result is that pending review neither demonstrates a lack of operating permission nor constitutes approval. Signing, reaching cooperation and contract effectiveness are three separate facts and must be checked separately.
How to verify the setup
- Check the hypothetical sample original text against the draft sentence. The input is the sample FAQ original text and the draft sentence; the comparison is whether subject, object, state and effective scope agree; the observable result is that a draft missing the after-sales confirmation step is judged unsupported. The expectation is that the draft does not pass. No claim is made that this was actually tested.
- Check downstream handling with a paper input of an empty array. The input is citation output
[]; the comparison is whether the downstream node continues along the documented path where length can be 0; the observable result is that the condition is met when downstream can accept an empty citation. No claim is made that a fictional-rule retrieval necessarily returns[]. - Check consistency using mutually exclusive values in the same field. The input is the effective-scope field of the same FAQ entry in two versions; the comparison is whether the values are clearly mutually exclusive; the observable result is that clearly mutually exclusive values in the same field are judged contradictory, while an unstated value or evidence covering only a related stage is judged pending verification. The expectation is field-by-field checking without inventing authorization or effectiveness clauses.