What the documents look like
Rating maintenance material comes from consumer feedback after post-sale fulfilment. The typical sources named in the category brief are Douyin Shop experience score, Tmall service indicators, JD after-sales reviews and the customer service system. Day-to-day documents include negative review handling records, experience score breakdowns, service diagnostic reports and rectification ledgers, with update frequency of daily or weekly.
For this page the relevant point is what these documents are used for during handover. Handover parties place negative review handling records and rectification ledgers into a knowledge base, and once a record is retrieved they may treat the retrieval itself as evidence that the counterparty already holds the corresponding operating permission. Retrieval shows that material was recalled. Authorization status needs separate verification. Phrases such as pending review, submitted and signed describe different factual stages, and a retrieval hit does not change any of those stages.
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 built on different vector models cannot be associated together. Identifiers should be checked and non-matching ones excluded, with the actual observation recorded; cross-model retrieval is not performed in order to compare missed recalls.
Referenced content is output as an array and its length can be zero. When nothing is found, the output path still completes. An empty output only means this retrieval returned no references. It does not mean the material does not exist, and it does not mean permission was denied.
Minimum relevance takes effect only in semantic retrieval or when result re-ranking is used. It is a filtering threshold and does not perform permission or entity isolation. Hybrid retrieval merges multiple result paths through RRF, and ReRank performs a second ordering of candidate text; both require the corresponding model and must be enabled by configuration. Optional paths shown in the overall process diagram do not mean every request executes all of them. Question optimization performs coreference resolution and question expansion and makes an additional model call.
Hypothetical paper exercise sample: within one shop's operations handover material, a passage of ledger text reads: "March 2025 negative review handling record: for order A, the customer service supervisor submitted a rectification statement on 12 March, status pending review; for order B in the same month, the rectification statement has not yet been submitted." A separate draft sentence reads: "Order A's rectification has been approved, and after handover the receiving party directly executes subsequent operations." Verification uses this source text and this draft sentence as inputs, with retrieval scoped to the knowledge base containing that ledger passage.
Configuration and implementation checks
| Configuration item | Value or check on this page | Basis and explanation |
|---|---|---|
| Associated knowledge bases | Associate only one or more bases using the same vector model | The node input requires the same vector model; cross-model association is not performed |
| Search mode | Hypothetical starting point for this exercise is hybrid retrieval | The ledger contains order numbers and natural language description; hybrid retrieval uses semantic and full-text recall together |
| Reference upper limit | Hypothetical starting point for this exercise is 800 tokens | Ledger passages vary in length; observe whether short and long passages are both referenced completely, then compare with adjacent values |
| Minimum relevance | Hypothetical starting point for this exercise is 0.4 | Takes effect only in semantic retrieval or result re-ranking; label relevant and irrelevant samples before adjusting the threshold |
| Question optimization | Enable as needed | Used for coreference resolution and question expansion; compare the original question with the optimized question and check whether the subject was changed |
| Result re-ranking | Enable as needed | Requires a re-ranking model; the re-ranking score can be used for filtering and does not perform permission judgement |
Three common errors
- Treating a retrieval hit as completed authorization. The input is the ledger source text and the draft sentence above. Concluding that order A "has been approved" merely because the order A record was retrieved treats recall as approval. The source status is pending review, and the draft sentence's "has been approved" is unsupported.
- Treating an empty reference output as material non-existence or permission denial. The input is the same ledger source text. When retrieval returns an empty array, record only that this retrieval returned no references; permission status remains to be verified.
- Associating knowledge bases that use different vector models. The input is two knowledge base identifiers with different vector models. Check the identifiers first and exclude the non-matching one, recording the actual observation. Do not infer missed recall or redundant results from this.
How to verify the setup
- Input the ledger source text and the draft sentence above, and retrieve within the same knowledge base scope. Compare whether the draft sentence's "has been approved" and the source text's "pending review" point to the same subject, the same order and the same field. The source text does not record an approval fact, so the draft sentence is unsupported; it must not be judged as approved, and subsequent operations must not be executed on that basis.
- Input the same ledger source text together with the order B portion, and retrieve whether order B's rectification statement was submitted. Compare the source text's "has not yet been submitted" with any statement claiming submission. The source text states this field as not submitted; if a draft sentence claims submission, it contradicts the source. If retrieval returns no order B content, record it as not recalled this time and keep the evidence gap.
- Input two knowledge base identifiers that use different vector models, and check whether the identifiers match. If they do not match, exclude the non-matching one and record the actual observation; do not perform cross-model retrieval and do not infer a runtime result. If they do match, then verify referenced content and authorization status using the earlier sample.
Retrieval checks record observations and failure branches only. They do not guarantee a first hit, complete recall, or that an unrelated query returns empty. An empty result can be used with an explicit paper input of [] to check the downstream design; no claim is made that a fictional rule retrieval necessarily returns []. Retrieval or form collection does not constitute authorized execution; approval, database writes and external synchronization each require their own downstream implementation.