What the documents look like
Creator-exclusive sales campaigns run on external creator fulfilment and commission settlement rather than on internal brand scheduling. Brand business teams, MCN agencies and creator managers coordinate around four document types: creator cooperation agreements, commission setting sheets, sample shipment sheets and livestream performance reports. The after-sales question step answers two kinds of questions. Consumer questions cover shipping progress, returns and commission deductions. Internal handover questions cover whether a given after-sales case has been processed and what state a given material is in.
These materials update per session and per week, but update frequency does not change how multi-turn prompts are implemented. Three properties do. First, one after-sales case can appear at the same time in the after-sales clause of a creator cooperation agreement, the deduction basis of a commission setting sheet and the transaction detail of a livestream performance report; subject, period and field must align across all three before any judgement holds. Second, material states differ widely: an agreement may sit at pending review, a commission setting sheet may be only a quotation, and a sample shipment sheet may record dispatch alone. Third, multi-turn dialogue carries the previous turn's conclusion into the next turn; if an earlier turn treated pending review as approved, later follow-up questions keep building on that wrong premise.
Constraints at the multi-turn prompts step
Prompts need to state the document scope, the answering task and how to handle missing evidence, so the model does not write business facts on its own. History records need checking against the context actually carried in, distinguishing a new session from a continued session. Question optimisation in knowledge-base continuous dialogue requires checking reference resolution and question expansion rather than assuming every short question qualifies. Model and length settings require checking the context and reply configuration the model supports, and testing long documents against follow-up combinations. Reply format follows downstream consumption; choosing json_schema requires filling in the corresponding format requirement and verifying the returned structure.
A relevance score on a retrieval result does not carry permission or entity isolation duties. Retrieval itself is not authorisation. Forms collect values; business verification, approval, database writes and external synchronisation each need their own downstream implementation. Libraries built on different vector models cannot be associated together; verify identifiers first, exclude those that do not match, record what is actually observed, and do not infer missed recall or redundant results.
Hypothetical exercise sample
Material text for checking (hypothetical, not a real record):
- Creator cooperation agreement (No. HZ-2024-0311), clause 7: after-sales commission deduction follows refunds confirmed as complete in the store transaction detail; refunds are not counted toward deduction before confirmation.
- Commission setting sheet (No. YJ-2024-0311): this sheet is a quotation proposal, valid until 20 March 2024, effective after both parties confirm.
- Sample shipment sheet (No. YP-2024-0311): 2 samples dispatched on 8 March, receipt status not returned.
One handover request to be judged: an order applied for refund on 12 March, and the store transaction detail shows the refund under review. The proposed sentence reads: "The refund for this order is confirmed; commission deduction proceeds under clause 7 of the cooperation agreement, and the commission setting sheet is in effect."
Configuration and implementation checks
The table below covers the settings officially described for this feature and the implementation checks tied to the main task, using the sample above. Values are starting points for this hypothetical exercise only, with the reason for choosing them and the comparison object stated.
| Configuration item | Hypothetical starting point | Reason and comparison method |
|---|---|---|
| AI model | Choose a model documented as supporting tool calls and multimodal recognition | Livestream performance screenshots must be read; compare whether the model capability description lists the corresponding support |
| Memory turns | Keep a small number of history turns | After-sales answers need the previous turn's order number; compare whether that order number is still available when turns increase or decrease |
| Temperature | Lower | After-sales wording needs stability; compare whether repeated asking of the same question gives consistent answers |
| Reply format | Default | The current downstream has no fixed-structure read requirement; compare whether switching to json_schema requires adding a format requirement |
| Multimodal recognition | Enable image recognition | Performance screenshots must be read; compare whether the model can still answer values inside a screenshot after this is turned off |
| Hide AI thinking | Keep off for debugging | Intermediate judgement needs observation; compare whether the user side sees only the final answer after this is turned on |
Three common errors
- Treating pending review as approved. In the sample, the commission setting sheet states it becomes effective after both parties confirm. If the prompt does not require distinguishing pending review from effective, the model treats a quotation proposal as an effective basis. Check: input the three material texts above together with the proposed sentence, compare "in effect" in the proposed sentence against "effective after both parties confirm" in the commission setting sheet, and observe whether the model points out that this wording is unsupported.
- Treating a refund under review as a confirmed refund. Clause 7 of the cooperation agreement makes confirmed refund the precondition for deduction, and the proposed sentence writes "refund is confirmed." Check: input the refund-under-review status from the store transaction detail together with clause 7, compare the two, and observe whether the model states that the deduction condition is not yet met.
- Treating a retrieval result as authorisation. An after-sales answer may retrieve the cooperation agreement text, but retrieving it does not mean there is authority to execute a deduction. Check: input a context in which retrieval hits the cooperation agreement, compare whether the model gives a deduction execution conclusion directly, and observe whether it states that deduction requires downstream verification and writing.
How to verify the setup
- For the sample proposed sentence, input the three material texts and that sentence, compare the two expressions "in effect" and "confirmed" against the source states, and expect the model to point out that neither is supported while preserving the evidence gap, without supplying an authorisation or effective clause.
- For an empty retrieval result, input the explicit paper input
[]together with the downstream handling design, compare whether the downstream treats it as having no references, and expect the downstream not to claim that retrieval for a fictional rule necessarily returns empty. - For cross-model libraries, input two library identifiers on different vector models, compare whether they are associated together, and expect identifiers to be verified first with non-matching ones excluded, actual observations recorded, and no cross-model retrieval run to compare missed recall.
All of the above are paper checks. No deployment, approval or business action was carried out.