What the documents look like
Refund-only dispute handling centres on four document types: refund-only applications, dispatch evidence, signed-receipt proof and appeal materials. Compared with ordinary return-and-refund cases, these disputes usually have no returned-goods warehouse entry, so the evidence focus falls on dispatch and receipt facts and on statements of product value. Source material arrives from the platform after-sales backend, carrier tracking, customer-service chat and warehouse outbound records, updated per order and daily.
The copy-drafting step converts facts from those documents into product descriptions and promotional sentences usable in an appeal or an external explanation. Multi-turn prompts here constrain the model to organise wording only from the supplied material, without adding dispatch times, receipt status or product performance that the material does not record.
Constraints at the multi-turn prompts step
Multi-turn dialogue carries earlier turns forward. The memory-turn setting controls how many prior chat turns the reply may reference; a larger value makes earlier dialogue easier to reference but also brings in more content, which can raise consumption and affect response speed. Refund-only copy drafting often needs to continue an order scope confirmed in a previous turn, so the context actually carried in must be checked, and new-session input distinguished from continued-session input.
Prompts need to state the material scope, the answering task and how to handle missing evidence. Fields the material does not record remain unknown, and the model does not add business facts. Reply format follows the downstream consumer; selecting json_schema requires filling in the corresponding format requirement and verifying the returned structure. For model and length, the model's supported context and reply settings need checking, and long material combined with follow-up questions tested.
Hypothetical paper exercise sample (paper material, not a real record):
Material text one: "Order A-001, product is a stainless-steel vacuum flask, outbound quantity 2 units, outbound date 4 March 2025, carrier waybill SF-0001."
Material text two: "Carrier tracking shows delivery signed for on 6 March 2025; the signatory field is blank."
Material text three: "Buyer's refund-only application reason: goods not received."
Draft sentence to be judged: "This store's product was signed for by the buyer personally on 6 March; the product is intact, and the refund-only request is not accepted."
The draft sentence contains two items the material does not record: the signatory field is blank, so "signed for by the buyer personally" is unsupported; the material contains no description of the product being intact. The authorisation boundary is: draft appeal copy only, without submitting it and without changing order status.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point for this page | Reason for the choice and comparison method |
|---|---|---|
| AI model | Select a model supporting the required context length | Compare the model's maximum context with the combined length of material plus follow-up; switch model if it is exceeded |
| Memory turns | Set to 3 turns | Refund-only copy needs to continue the prior turn's order scope; compare with 1 turn and observe whether an order-number reference is lost |
| Reply cap | Enabled, set to a medium length | The copy needs to state the dispute point fully; compare with a lower value and observe whether the appeal reason is truncated |
| Temperature | Set to a lower value | Customer service and rule-defined scenarios favour stability; compare with a higher value and observe whether wording outside the material appears |
| Reply format | Keep the default | No downstream need to read a fixed structure; changing to json_schema requires filling in the format requirement and verifying the returned structure |
| Multimodal recognition | Decide whether to enable image recognition according to model capability | Enable when a product image or screenshot must be read; input of an unsupported type is not sent to the model |
The values above are hypothetical trial starting points for this page, used for comparison with adjacent values, and do not represent official defaults.
Three common errors
- Writing a signatory the material does not record as "signed for by the buyer personally". Material text two has a blank signatory field, yet the draft sentence asserts personal signing. Check: input material text two, compare whether the draft sentence introduces a subject the material does not record; if it does, the condition is not met.
- Treating a historical turn carried in by the model as a verified fact. If a previous turn contained an order number, the model may reuse it in the copy, while the material does not record that order's dispatch status. Check: input the context actually carried in, compare whether the order facts in the copy correspond to a field in the material text; if not, the condition is not met.
- Treating a retrieval result's relevance as a usable scope. Relevance is a similarity value and does not carry permission or entity isolation. Check: input one retrieval return list, compare whether the returned entry's dataset_id belongs to the target library; if it does not, it is not counted as usable material.
How to verify the setup
- Input material texts one, two and three together with the draft sentence, and compare whether the draft sentence contains "signed for by the buyer personally" or "the product is intact". Expected result: the draft sentence should be changed to "tracking shows signed for; the signatory is not recorded", and no statement of the product being intact should appear. A statement outside the material means the condition is not met.
- Input an empty retrieval result
[]and compare whether the downstream node handles it as having no reference material. Expected result: the downstream generates no quoted source and the copy cites no unreturned content. This paper input is used to check the downstream design and does not indicate that any rule retrieval returns empty. - Input one retrieval request covering two libraries with different vector models, and compare the returned entries' model identifiers. Expected result: only entries whose identifier matches the target library are kept; non-matching entries are excluded and the actual observation recorded. Libraries across different vector models cannot be associated together, and no inference about missed recall or redundancy is drawn from this.
All three are stated as expectations and were not actually executed. A pending review does not constitute approval, an unsigned termination does not constitute a completed termination, and fields the material does not record remain unknown.