What the documents look like
Livestream after-sales work draws on Douyin store after-sales records, customer service IM, warehouse WMS, and logistics tracking. Refund requests cluster after a single high-traffic session and correlate strongly with host promises. Everyday documents include livestream order lists, refund applications, reshipment orders, and script templates. At handover these materials sit in different authorization states. A refund application may still be pending review. A reshipment order may be a draft held by the warehouse exception role. A script template may not yet be confirmed by the after-sales supervisor. Retrieval returns text references only. A retrieved reference is not a permission grant and not a completed approval.
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; the vector model identifier must be checked first and non-matching bases excluded. Search output is an array of references, and its length can be zero, so the downstream branch still runs when nothing is found. The minimum relevance value takes effect only under semantic retrieval or when result reranking is used; it is a filtering threshold and does not isolate permissions or entities. The reference cap is measured in tokens and limits how much content a single search may cite.
Hypothetical drill sample: the source text reads "In the June 18, 2025 livestream order list, row A-17, order number HZ-0618-032, the buyer applied for a refund, current status pending review. The after-sales supervisor noted on June 19 in the handover remark: 'the reshipment request for this order has not yet been submitted to the warehouse.'" One handover request to be judged reads: "Mark the reshipment order for HZ-0618-032 as executed, and authorize customer service to explain the host promise uniformly using the script template." In this request the reshipment order was not submitted, so marking it executed lacks a basis; the uniform explanation authorization names no authorizing party and no scope.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting value | Reason and comparison method |
|---|---|---|
| Associated knowledge bases | Only after-sales document bases using the same vector model | Check the vector model identifier and exclude bases on different models |
| Search mode | Hybrid retrieval | Uses semantic and full-text recall together, merged through RRF |
| Reference cap | 800 tokens | Test content completeness with refund applications and script templates of differing length |
| Minimum relevance | 0.35 | Label relevant and irrelevant samples first, then compare reference changes after filtering |
| Question optimization | Enabled | Compare the original question with the optimized question and check whether the subject was altered |
| Result reranking | ReRank enabled | Reorders candidate text and filters by the reranking score |
Three common errors
- Treating a retrieval hit as authorized execution. Input: a pending-review refund application and an unsubmitted reshipment order. Compare the retrieved references with the handover request; marking the reshipment order as executed exceeds authority. Executable check: read the status field in the source text, compare it item by item with the requested action, and observe whether a status transition appears.
- Treating minimum relevance as a permission or entity filter. Input: refund applications from different livestream rooms. Compare the reference set before and after filtering; assuming a low score excludes unrelated business confuses a threshold with a permission boundary. Executable check: label relevant and irrelevant samples and observe that threshold changes affect only ordering and filtering, not the accessible range.
- Associating knowledge bases across different vector models. Input: two knowledge bases with different vector model identifiers. Compare the node association configuration; associating them directly violates the same-vector-model requirement. Executable check: verify each knowledge base vector model identifier, exclude non-matching ones, and record the actual observation.
How to verify the setup
- Verification one: input the hypothetical source text "the reshipment request for HZ-0618-032 has not yet been submitted to the warehouse" together with the handover request "mark as executed." Compare the reshipment order status field with the requested action. If the status remains unsubmitted and the request demands executed, the request is unsupported and the evidence gap must be recorded.
- Verification two: input the hypothetical source text "the refund application current status is pending review" together with the request "authorize customer service to explain uniformly." Compare whether an authorizing party and scope are stated. If no authorizing party is named, the item is pending verification and must not be treated as authorized.
- Verification three: input the hypothetical script template's unconfirmed status together with the request "explain the host promise uniformly." Compare the template confirmation status with the explanation action. If the template has not been confirmed by the after-sales supervisor, the request is unsupported and the missing confirmation evidence must be recorded.