What the documents look like
Low-price campaign operations on Pinduoduo revolve around campaign resource slots, campaign inventory, and refund-rate swings. The working materials for order fulfilment and after-sales answering are the campaign registration form, the product cost calculation sheet, the after-sales refund slip, and platform in-site messages. Each carries a different kind of evidence. The campaign registration form states the campaign price, the inventory range, and the registration deadline. The product cost calculation sheet states cost and gross-margin conventions. The after-sales refund slip states the refund reason and the handling status. Platform in-site messages state platform notices and time limits. These materials update daily and per campaign.
For multi-turn prompts this matters because a conversation that continues an earlier session draws on stored history, while a new session relies only on the current input. 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 no document supports.
Constraints at the multi-turn prompts step
The prompt must fix the material scope, the answering task, and the missing-evidence rule. History handling requires checking what context is actually carried in, and distinguishing a new session from a continued one. Question optimisation for knowledge-base continuous dialogue requires checking reference resolution and question expansion, without assuming every short question qualifies. Model and length handling requires checking the context and reply settings the model supports, and testing long documents combined with follow-up questions. Reply format follows what the downstream step needs to read; when json_schema is selected, the corresponding format requirement must be filled in and the returned structure verified. A relevance score from retrieval is a similarity measure, and it does not serve as a business permission or entity-isolation basis; retrieval by itself is not authorisation.
Hypothetical paper exercise. The campaign registration form reads: "Campaign price 9.9 yuan, campaign inventory 500 units, registration deadline 10 June." The after-sales refund slip reads: "Order number A123, refund reason: size mismatch, handling status is pending review." The platform in-site message reads: "Please confirm campaign inventory before 12 June." The draft sentence to be judged is: "This order's refund has been approved; a replacement can be arranged." Checking subject, object, status, and validity scope, the refund slip's handling status is pending review, so the draft's "has been approved" is unsupported, and the replacement action lacks an effective handling basis.
Configuration and implementation checks
The following settings relate to this function and primary task, using the documented options or implementation checks.
| Configuration item | Hypothetical trial starting point | Reason and comparison method |
|---|---|---|
| Memory turns | Keep a small number of history turns | Customer-service and knowledge-base answering applications usually keep a small number of history turns; compare with the number of context turns actually carried into a continued session |
| Temperature | Lower | Customer service and knowledge-base answering suggest a lower value; compare reply stability against the same prompt at a higher setting |
| Reply format | Default | Ordinary customer-service answering keeps the default; change to json_schema and fill the format requirement only when a downstream step reads a fixed structure |
| Reply cap | Lower as needed | A shorter answer can be produced by lowering it; compare against truncation and completeness of content |
| Multimodal recognition | Enable according to model capability | Selectable types depend on the model's own capability; compare with the capability shown in the configuration dialog |
| Hide AI output | Enable as needed | When on, generated content is not shown directly but can still pass to later nodes through the AI reply output; compare with whether later nodes can read the output |
Three common errors
- Treating a retrieval relevance score as a business permission or entity-isolation basis. The input is a similarity score, the comparison object is the business authorisation scope, and the observable result is whether returned records fall inside the accessible range; the score level does not change authorisation status.
- Treating "refund has been approved" in a draft sentence as a fact that occurred. The input is the refund slip's handling status "pending review", the comparison object is the status stated in the draft, and the observable result is whether the two agree; pending review does not constitute approval.
- Treating the interactive node's returned display configuration as internal runtime state. The input is the
interactivefield returned to the external caller, the comparison object is the documented display scope, and the observable result is whether internal fields such asentryNodeIds,memoryEdges,nodeOutputs, andnodeResponseIdappear in the returned content.
How to verify the setup
- Input the campaign registration form text above together with the draft sentence "This order's refund has been approved; a replacement can be arranged". Compare the refund status stated in the draft against the handling-status field in the after-sales refund slip text. The observable result is that when the draft and the source status disagree, the draft is judged unsupported.
- Input the platform in-site message text above together with a draft sentence "Inventory confirmation is complete". Compare the completion status stated in the draft against the time limit in the in-site message text. The observable result is that when the source states only a confirmation deadline and no completion, the draft is judged pending verification.
- Input the campaign registration form text above together with a follow-up question "Has campaign inventory been synced to the ERP". Compare the sync action in the question against the inventory quantity range stated in the source. The observable result is that when the source states no sync status, the item is judged an evidence gap and the missing record is retained.