What the documents look like
Livestream after-sales work arrives in bursts after a single session. Refund requests, replacement orders and livestream order lists enter the queue in the same window, and the service team has to align what the host promised on air with the handling position actually recorded. The main sources named in the brief are the shop after-sales system, customer service IM, warehouse WMS and logistics tracking. Updates follow the rhythm of each session and each day.
Cross-border material adds a language dimension. One document set can contain a Chinese version and a target-market language version at the same time. A search has to match terminology and also match order or document numbers. The four document types in scope are livestream order lists, refund requests, replacement orders and script templates. Chunking decisions at this stage determine whether a retrieved fragment carries enough context to be judged, and whether a number can still be found exactly.
The brief rates its own confidence as broadly indicative, so the descriptions above are treated as a working picture rather than a verified fact set. Where a field is not provided, it stays unknown.
Constraints at the document chunking step
Chunking has to keep a condition together with the content that condition governs. If a promise condition inside a refund request is split away from the subject description, a retrieved fragment will lack the basis for judgement. The same applies to a replacement order: the reason and the status belong with the order reference.
Data and index are separate objects. One group of original data can map to more than one vector index. The index serves recall; the original data serves as the pointer back to the source text. This distinction matters when a chunk is retrieved, because the retrieved index is not itself the document.
Multilingual retrieval leans on the cross-language understanding of semantic retrieval and on the exact matching of full-text retrieval for numbers and model names. The two paths are merged through RRF, and a ReRank model can reorder the merged candidates. RRF is a fusion step in the retrieval pipeline, not a switch that is turned on.
Semantic recall and a relevance score do not act as permission or entity isolation. A returned fragment is a retrieval result. It does not carry an authorization to perform a refund or a replacement.
Hypothetical paper exercise sample. A livestream service agent receives a refund request dated 10 June 2025. The source text reads: "Order number A-20250610-07; the buyer applied for a refund after signing on 9 June, reason given as colour difference; the host stated during the 8 June livestream that 'a refund is available if not satisfied'." In the same batch there is a replacement order whose source text reads: "Replacement order B-20250610-03, corresponding to order A-20250610-07, replacement reason: missing accessory, status is awaiting warehouse confirmation." The draft sentence under review is: "This order has been approved for refund and a replacement has been arranged." The scope of comparison is limited to these two documents. The authorization boundary is that the agent can view the material and cannot directly execute a refund or a replacement.
Configuration and implementation checks
| Configuration item | Hypothetical starting value for this exercise | Reason and comparison object |
|---|---|---|
| Search mode | Hybrid retrieval | The sample needs both the colour-difference meaning and the order number; compare pure semantic and pure full-text recall |
| Citation limit | 2000 tokens | The sample texts are short; compare 1000 and 2000 for whether both documents are covered completely |
| Minimum relevance | 0.3 | Hypothetical starting value; compare 0.2 and 0.4 for whether unrelated fragments decrease |
| Question optimisation | Enabled | The sample question contains a reference; compare the search terms before and after to see whether the subject is completed |
| Result reordering | Enabled | Candidates come from several paths; compare the ordering before and after reordering against the source text |
| Image retrieval | Not enabled | The sample has no image input; compare whether enabling it produces unsupported recall |
The citation limit is expressed in tokens, which is the documented unit for this control. The minimum relevance value applies only under semantic retrieval or when result reordering is used, and it acts as a filter threshold rather than a final ranking rule. The image retrieval row is listed because the sample contains no image; the documented conditions for image retrieval require a corresponding image input and model capability.
Three common errors
- Treating "awaiting warehouse confirmation" as a completed replacement. The status field in the replacement order reads awaiting confirmation, while the draft sentence states that a replacement has been arranged. The check takes the replacement order source text as input, compares the status field against the draft sentence, and observes that when the status is awaiting confirmation the draft sentence should not contain a statement that a replacement has been arranged.
- Treating a refund request as an approved refund. The source text records only the buyer's application and the host's statement; it does not record approval of the refund. The check takes the refund request source text as input, compares whether an approval field is present, and observes that when no such field exists the draft sentence should not contain a statement that a refund has been approved.
- Treating a retrieval hit as an authorization to execute. A retrieved refund request fragment does not mean the agent holds refund operation permission. The check takes the retrieval result and the authorization boundary as input, compares whether an execution action appears, and observes that when the retrieval result contains no authorization field no executable action may be inferred.
How to verify the setup
- Input the refund request source text from the hypothetical sample together with the draft sentence "This order has been approved for refund and a replacement has been arranged." Compare whether the source text records refund approval and a completed replacement. Observe that the source text contains only an application and an awaiting-confirmation status, so the draft sentence does not match the source text. Record the draft as unsupported.
- Input the replacement order source text from the hypothetical sample together with the same draft sentence. Compare the replacement order status field. Observe that the status reads awaiting warehouse confirmation, so the statement in the draft sentence that a replacement has been arranged lacks a basis. Record it as pending verification.
- Input an empty-result downstream scenario, using the paper input [] to check the downstream design. Compare whether the downstream treats the empty result as containing no citation content. Observe that when the downstream does not interpret the empty result as an authorization or an execution, record it as meeting expectation; if an execution action appears downstream, record it as requiring a separate system implementation.
The checks above state expected observations. No test, deployment, approval, refund or replacement is claimed to have occurred. Where the source text does not record a field, the field remains unknown, and the correct outcome is unsupported or pending verification rather than a confirmed contradiction.