What the documents look like
Convenience-store fresh food is ordered by the store at high frequency against short shelf life, and it is not handled as a joint-operation revenue share in the way a hypermarket fresh counter might be. The working documents for this page are the fresh-food order sheet, the shrinkage report, the near-expiry handling sheet, and the temperature record. Supporting data comes from POS sales, the headquarters ordering system, store inventory, and cold-chain temperature logs, updated by day and by shift.
Store managers, fresh-food buyers, and regional supervisors work from these four documents. Errors in this area carry consequences such as sales of expired product, stockout losses, and food-safety complaints. The multi-turn prompt task in store service and internal training therefore concentrates on producing checkable statements about the day's order sheet, shrinkage report, near-expiry sheet, and temperature record. It does not replace the ordering decision itself.
A hypothetical paper exercise sample is used throughout this page. The source text is: "The store's 12 March fresh-food order sheet lists 40 rice balls and 25 sandwiches; the temperature record for the same day shows the refrigerated case at 4°C; the shrinkage report lists 3 rice balls as shrinkage, with the reason column left blank." The draft sentence to be judged is: "The reason for the store's 12 March shrinkage was damage on arrival." The comparison object is the reason column of the shrinkage report. That column is blank, and the reason stated in the draft sentence does not appear in the source material.
Constraints at the multi-turn prompts step
Multi-turn context comes from the history that is actually carried in. A new session and a continued session receive different input, so the prompt must state the document scope, the answering task, and how to handle missing evidence, and must not let the model write in business facts.
Where a knowledge base is used for continuous conversation, check coreference resolution and question expansion. Whether a short question is suitable has to be judged case by case. Model and length settings need to be checked against the context and reply settings the model supports, and long-document plus follow-up combinations need to be tested. Reply format is chosen according to what the next step consumes; when json_schema is selected, the corresponding format requirement is filled in and the returned structure is checked.
For the hypothetical sample, the scope statement in the prompt would name the order sheet, shrinkage report, near-expiry sheet, and temperature record as the only permitted sources. The draft sentence about arrival damage falls outside what the reason column supports, so the expected handling is to record the gap rather than complete the reason.
Configuration and implementation checks
| Configuration item | Value or check item on this page | Basis and comparison method |
|---|---|---|
| Prompt task scope | State that answers rely only on the order sheet, shrinkage report, near-expiry sheet, and temperature record | Compare sentence by sentence against the sample material; content beyond that scope is not written in |
| Memory turns | For this hypothetical trial, the starting point is a small number of history turns | This starting point is chosen for this trial, to compare whether a follow-up carries the previous turn's material |
| Reply cap | For this hypothetical trial, the starting point is a short reply | Compare against the length of the sample draft sentence to observe whether truncation occurs |
| Temperature | A lower setting is chosen for service and rule-bound scenarios | Compare against the default to observe answer stability for the same input |
| Reply format | Ordinary question answering keeps the default | When a downstream node needs a fixed structure, switch to json_schema and fill in the format requirement |
| Multimodal recognition | Enabled only when the model supports it and image input actually exists | Compare against the displayed model capability; unsupported types are not sent |
These are implementation checks tied to this page's documents, not documented default values. The memory-turn and reply-cap starting points are trial choices for the hypothetical exercise, and each has a stated comparison method.
Three common errors
- Treating retrieval or a form as authorization. Retrieval results and values collected by a form supply information only. Business verification, approval, database writes, and external synchronization each need their own downstream implementation. In the sample, the shrinkage reason column is blank, and a retrieval hit cannot be used to infer that the reason has been confirmed.
- Treating a similarity score as a permission or entity filter. A relevance score does not exclude unrelated businesses or unauthorized records, and retrieval does not constitute authorization.
- Treating an unstated field as a negative conclusion. The blank reason column in the sample shrinkage report is unsupported, and it cannot be written as either the absence of a reason or a conflict about the reason.
How to verify the setup
- Input the sample source text and the draft sentence, then compare the reason stated in the draft sentence against the reason column of the shrinkage report. When the reason column is blank, the expected output is unsupported, with the gap preserved and no reason written in.
- Input two consecutive follow-up turns under the same
chatId, then compare whether the second turn carries the first turn's material. The expectation is that the previous turn's content is carried in, and follow-ups beyond the material scope are recorded as gaps. - Input an explicit paper empty result and compare how the downstream design handles it. The expectation is that it is handled as an empty result, without claiming that a rule-based retrieval necessarily returns empty.