What the documents look like
Livestream after-sales work concentrates after a single traffic event, and the promises made by the host during that event shape what buyers ask afterward. The working materials are livestream order lists, refund applications, reshipment orders, and script templates. These come from shop after-sales systems, customer service IM, warehouse management systems, and logistics tracking. Updates follow a per-session and daily rhythm. Customer service agents and after-sales supervisors work the same conversation to chase an order number, a refund status, and a reshipment progress in sequence.
For the multi-turn prompts step, the task is narrow. The prompt must state the material scope, the answering task, and how to behave when evidence is missing, so the model does not write business facts that the source material does not contain. Retrieval and forms collect values; they do not authorize refunds, reshipments, or approvals. Those actions need their stated downstream implementation.
Constraints at the multi-turn prompts step
The prompt text needs to name the material scope, the answering task, and the handling of missing evidence. For history, check what context is actually carried in, and separate a new session from a continued session. Question optimization belongs here only when knowledge-base continuous dialogue is required; check pronoun resolution and question expansion, and do not assume every short question needs it. For model and length, check the context the model supports and the reply settings. Reply format follows the downstream consumer; choosing json_schema requires filling in the corresponding format requirement and checking the returned structure.
A hypothetical paper exercise sample: one source line reads "After-sales order A-01, order number D-1001, buyer applied for refund, refund application status is pending review, no refund confirmation signed." A second line reads "Reshipment order B-02, order number D-1001, reshipment status is arranged, warehouse has not shipped." The draft sentence to be judged is "Order D-1001 refund approved, reshipment sent." The check points: the refund application status field is pending review, the reshipment status field is arranged and not shipped, and the draft sentence states statuses that the source does not support.
Configuration and implementation checks
| Configuration item | Relevant setting or check for this page | Relation to the sample |
|---|---|---|
| Prompt | State material scope, answering task, and missing-evidence handling | When the sample status field is pending review or absent, the answer must say the claim is unsupported |
| Memory turns | Controls how many prior chat turns are referenced | Hypothetical starting point for this exercise: a small number of turns, compared against the default value |
| Reply cap | Limits model reply length | Hypothetical starting point for this exercise: a short length, compared against truncation behavior |
| Temperature | Lower values give steadier answers | After-sales service suggests a low value, compared against divergent answers |
| Reply format | Default for ordinary Q&A; use json_schema with a format requirement when a fixed structure is needed | The sample draft sentence is free text, so the default format applies |
| Multimodal recognition | Depends on model capability; the dialog shows available options per model | The sample material is text and does not involve images, audio, or video |
Three common errors
- Writing pending review as approved. In the sample, the refund application status field is pending review, and the draft sentence says approved. The input and the comparison object are the same refund status field, and the observed result is that the two values do not match.
- Writing arranged as sent. In the sample, the reshipment status field is arranged with the warehouse not yet shipped, and the draft sentence says sent. The input and the comparison object are the same reshipment status field, and the observed result is that the two values do not match.
- Treating a retrieval result as authorization. In the sample, retrieving a refund application record does not mean the refund action was executed. The input is the retrieval return, the comparison object is the authorization status field, and the observed result is that no authorization record exists.
How to verify the setup
- Input the sample source lines and the draft sentence, then compare the refund status field values. The condition is met only when the draft sentence matches the source. If the source is pending review and the draft sentence is approved, the condition is not met.
- Input the sample source lines and the draft sentence, then compare the reshipment status field values. The condition is met only when the draft sentence matches the source. If the source is arranged and not shipped and the draft sentence is sent, the condition is not met.
- Input the sample source lines and a request containing only a retrieval result, then compare whether an authorization field is present. The condition is met only when an authorization record exists. With only a retrieval result, the condition is not met, and the evidence gap must be recorded.
These three checks use the hypothetical source lines and draft sentence given above. They state expected outcomes and do not claim that any test was run.