What the documents look like
Pinduoduo low-price campaign operations revolve around campaign resource slots, campaign inventory and refund-rate swings. The working materials for order fulfilment and after-sales answering are campaign registration forms, product cost calculation sheets, after-sales refund slips and platform in-app messages. In this setting a conversation log is not a general chat archive. It is the trace that lets one operator hand a case to another and confirm which reply belongs to which session and which turn.
Two facts shape that trace. First, sessions and turns carry separate identifiers: a session is identified by chatId, and a turn inside it by dataId. The link between those identifiers and a business slip such as a refund form is established by manual comparison, not by the log itself. Second, the conversation interface, when chatId is a non-empty string, reads the session from the FastGPT database and uses the last element of the messages array as the user question, ignoring the remaining messages. An operator who needs intermediate values sets detail=true; in non-stream responses those values are held in responseData. Fields that the log does not return are simply not provided, and their absence does not show that the underlying business record was fully retained. Retrieval and similarity scores do not perform permission checks, and the same-vector-model requirement for a retrieval set does not extend to outside systems. Reconciliation, retention and compliance are handled by a separate full business arrangement.
Constraints at the conversation logs step
The step has a narrow scope: keep a checkable record of the session and the interface return so a handover can confirm which reply corresponds to which session and turn. It does not authorise refunds, does not confirm that a refund slip was processed, and does not turn a retrieval hit into evidence of ownership.
An interactive node illustrates the boundary. When a workflow reaches an interactive node, the interface returns immediately. With detail=true and stream=true, the display configuration is available from the interactive field of the data attached to event=interactive; with stream=false it appears as an element inside choices[].message.content. That returned object is a display configuration containing type and params. Internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs and nodeResponseId are not returned. Receiving the configuration is a waiting state. Continuing the workflow requires a further request that carries the user's selection or form values, with chatId kept consistent. A pending request is not approval, and an offered option is not execution.
A hypothetical paper exercise sample, used only for this page. A shop finishes a low-price campaign on 12 March. The handover packet contains two source sentences: "After-sales refund slip number A-0312-07, status is awaiting merchant handling, item: campaign short-sleeve, quantity 2, application time 12 March" and "Platform in-app message: inventory check for this campaign resource slot closes 13 March at 18:00." The draft sentence to be judged is "A-0312-07 has been fully handled and the buyer has received the refund." The comparison subject is the status field of that refund slip against the completion wording of the draft. The subject is the same refund slip; the period is 12 to 13 March.
Configuration and implementation checks
| Check item | Hypothetical trial starting point | Comparison method and basis |
|---|---|---|
| Session identifier chatId | The session identifier recorded on the handover sheet | Compare character by character with the chatId returned by the interface to confirm the same session |
| Turn identifier dataId | Taken from the session record list | Compare with the dataId used in the getResData request to confirm the same turn |
| detail value | Set to true when run details are needed | Inspect the non-stream response for responseData; when it is not set, this item is unknown |
| Response message identifier responseChatItemId | Starting point is the value recorded on the handover sheet | Compare uniqueness within the same chatId; a duplicate is recorded as pending verification |
| Intermediate values and final answer | Taken from responseData and choices respectively | Compare field by field; fields not returned remain missing |
| Session source source | Set to api for handover checking | Compare with the session source returned in the history list; page sessions are outside this scope |
These values are starting points for this paper exercise. The reason for choosing them is that they can be compared literally. The comparison target is the field actually returned by the interface. They are not stated as default values.
Three common errors
- Treating a similarity score or a retrieval result as a permission decision, and inferring from a high score that a record belongs to this shop or has been authorised. Check: the input is one retrieval return carrying a score; the comparison object is that record's datasetId against the business ownership register; the observable result is whether the two agree. When they disagree, record the item as pending verification.
- Writing a refund slip whose status reads "awaiting merchant handling" as fully handled. Check: the input is the literal status field of refund slip A-0312-07; the comparison object is the completion wording in the draft sentence; the observable result is whether the status value and the completion wording are mutually exclusive. When they are, the draft sentence is unsupported.
- Treating the display configuration of an interactive node as a submitted answer. Check: the input is the type and params returned with event=interactive; the comparison object is whether a further session request carrying the selection was later issued; the observable result is whether that request exists. When only the configuration has been received, record the state as waiting.
How to verify the setup
- Verification one: input the draft sentence "A-0312-07 has been fully handled and the buyer has received the refund"; compare it with the refund slip status field "awaiting merchant handling"; observe whether the two are mutually exclusive. When they are, the draft sentence is unsupported, and the status gap must be kept open rather than filled with an invented authorisation or handling record.
- Verification two: input one session request with a non-empty chatId and one question as the last element of messages; compare it with the session record returned for that chatId; observe whether the question and the record point to the same turn. Whether the remaining messages were ignored is determined by the actual return, not assumed.
- Verification three: input one non-stream request with detail=true; compare the responseData and choices portions of the response; observe whether run-detail fields appear. When they do not appear, that item is unknown. Do not infer a cause, and do not assert a particular error code or automatic action.
These checks test the named task: whether a proposed answer sentence is supported by the supplied source wording and its stated limits. They do not test identity certification, report analysis or any other task. The paper exercise above is hypothetical and no test, deployment, approval, refund or other business action is claimed to have occurred.