What the documents look like
Receiving and putaway covers the first physical-versus-record confirmation when goods enter the warehouse. The working data comes from WMS, ERP purchasing, supplier delivery notes and barcode scanning. The daily documents are purchase arrival notes, receiving inspection sheets, putaway tasks and discrepancy reports. Counting arrived quantities, printing barcodes and assigning storage locations consume the most time. Errors here produce inventory that does not match physical stock, later picking mistakes and disputes with suppliers.
For store service and internal training, a multi-turn conversation has to stay anchored to these documents. 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 does not carry. Because receiving and putaway confirm the first record of goods entering the warehouse, training material that overstates a verification status can mislead staff about what has actually been confirmed.
Constraints at the multi-turn prompts step
Multi-turn conversation depends on the context carried in from history. When chatId is supplied, FastGPT reads the session from its database and uses the last item of the messages array as the user question; the remaining messages are ignored. When chatId is not supplied, the platform context is not used and the context is built entirely from the passed messages. Checking which context is actually carried in, and distinguishing a new session from a continued session, is the basic action at this step. Reply format follows the downstream consumer: when json_schema is selected, the corresponding format requirements must be filled in and the returned structure checked. For model and length, check the context and reply limits the model supports, and test long-document and follow-up combinations.
Hypothetical drill sample: a receiving clerk submits internal training material. The source text reads: "Purchase arrival note PO-2024-0517 records 120 units arrived; the receiving inspection sheet shows 118 units actually received; the discrepancy report records a shortage of 2 units, with status pending verification." A proposed sentence reads: "This batch has been fully inspected as qualified and put away." The subject here is the receiving clerk, the objects are the purchase arrival note and the receiving inspection sheet, the status is pending verification, and the valid scope is limited to this batch. Judging requires the same subject, the same period and the same field: the source carries only a pending verification status and does not state that inspection passed or that putaway was completed, so the proposed sentence is not supported.
Configuration and implementation checks
The settings below relate to the sample above and cover only officially described settings or implementation checks tied to this feature and the primary task.
| Configuration item | Assumed starting point for this drill | Reason and comparison method |
|---|---|---|
| Memory turns | Keep a small number of history turns | Training needs prior document context; compare against the no-chatId case where context is built entirely from messages |
| Reply limit | Lower as needed to keep replies short | Training answers should be brief; compare truncation against a longer explanation scenario |
| Temperature | Lower | Rule-bound document checking is more stable; compare against a creative writing scenario |
| Reply format | Default, unless downstream reads a fixed structure | If downstream needs it, switch to json_schema, fill in format requirements and check the returned structure |
| Stop sequence | Not set | Ordinary conversation does not need a fixed end marker; compare against a scenario that does |
| Multimodal recognition | Enable image recognition if the model supports it | If the sample includes an arrival note screenshot, check whether the model supports image input |
Three common errors
- Treating a pending verification status as inspection passed. In the sample, the source status is pending verification while the proposed sentence says inspection passed. The input comparison is between mutually exclusive values of the same field, and the observable result is that the two do not match.
- Treating retrieval or a form as authorized execution. In the sample the receiving clerk submits material and the retrieval library returns related content; neither constitutes putaway authorization. The observable result is that an authorization record is absent.
- Treating
messagesas full history whenchatIdis not passed. If the sample request omitschatId, only the last content item is used as the question. The observable result is that earlier content is not carried in.
How to verify the setup
- Input the sample source text and the proposed sentence, compare the status field, and observe whether the result is that pending verification and inspection passed do not match. If they match, this check is not satisfied.
- Input the sample request and the authorization record, compare whether authorization exists, and observe whether the result is that authorization is absent. If authorization exists, this check is not satisfied.
- Input a request without
chatId, compare the context carried in, and observe whether the result is that only the last content item is used. If earlier content is carried in, this check is not satisfied.
These checks describe what to compare and what remains unknown. They do not assert that any test was run, that any configuration was approved, or that any business action occurred. Where the source material does not state a fact, the gap stays open and is recorded as missing evidence rather than filled in.