What the documents look like
A fresh-food concession counter in a hypermarket is often run by a supplier who is present on site and paid through a sales-share arrangement. Order fulfilment and after-sales questions therefore involve the store's fresh-food department, the concession supplier and the store manager at the same time. The working papers are the concession contract, the daily sales report, the loss sheet and the food purchase inspection record. These come from the POS system, supplier delivery notes, the food-safety ledger and store stocktaking. The material is updated daily or per batch, so a multi-turn conversation has to check the current day's documents against earlier follow-up questions inside one session. The prompt must state the document scope, the answering task and how to handle missing evidence, and it must not let the model write in business facts that the papers do not contain.
Constraints at the multi-turn prompts step
A multi-turn conversation has to check which context was actually carried in, and it has to separate a new session from a continued session. A session is tied together by chatId. When a non-empty chatId is passed, the system takes the session from the database and uses the last item of the messages array as the user question, ignoring the other messages. When chatId is not passed, the context is built entirely from the messages that are supplied. Memory turns control how many earlier rounds of chat the AI may reference. A value that is too small may fail to use earlier information; a value that is too large brings in more content, which can raise consumption and affect response speed. The prompt has to cover three kinds of follow-up: checking weighed sales, handling loss sharing, and inspecting purchase vouchers, and it has to state that gaps stay open when evidence is missing. The reply format is chosen according to what comes next. When json_schema is selected, the matching format requirement has to be filled in and the returned structure has to be checked.
Hypothetical exercise sample: a concession contract states "Party A is the fresh-food department of a certain hypermarket; Party B is a certain vegetable supplier; loss sharing is calculated at three percent of the daily sales report amount." A food purchase inspection record states "3 June 2025, batch A, supplying entity is a certain vegetable supplier, inspection status is registered." A draft sentence to be judged reads "Batch A has passed store acceptance, and the three percent loss is borne by the supplier." The contract states only the sharing ratio and does not state an acceptance conclusion for that batch, so the draft sentence goes beyond the material.
Configuration and implementation checks
The table below lists, around the sample above, the officially described settings or implementation checks that relate to this feature and the primary task. The values are starting points for this hypothetical trial, used for comparison with the sample text, and are not official default values.
| Configuration item | Hypothetical trial starting point | Reason and comparison object |
|---|---|---|
| AI model | Choose a model that supports the required context length | Compare with the combined length of the sample contract and inspection record to confirm a single request can reference them |
| Memory turns | Set to 3 turns | Compare with the earlier rounds the sample follow-up needs; too many brings in unrelated content |
| Reply cap | Turned on and set to a medium length | Compare with the length of the draft sentence; too low truncates it, too high raises consumption |
| Temperature | Set to a low value | Compare with the stable-answer requirement of after-sales questions; customer-service scenarios suit a low value |
| Reply format | Keep the default | Compare with what the downstream step needs; change to json_schema only when a fixed structure must be read |
| Multimodal recognition | Check against model capability whether to enable | Compare with whether the sample contains image, audio or video input; with no such input, leave it off |
Three common errors
- Treating a retrieval result as authorized execution. In the sample, the inspection record states only "registered," while the draft sentence writes "has passed store acceptance." The input is the inspection record text, the comparison object is the two states "registered" and "accepted," and the observable result is that the draft sentence contains an acceptance conclusion the text does not have. Retrieval and forms do not amount to authorization; business verification, approval and database writes each need their own downstream implementation.
- Treating a similarity score as a permission or entity filter. The input is a similarity score, the comparison object is the supplying entity and batch in the sample, and the observable result is that a high similarity does not exclude records of other entities. Relevance does not perform permission or entity isolation; identifiers have to be checked first and non-matching records excluded.
- Treating a pending review as already approved. The input is a pending-review status, the comparison object is the "registered" field in the sample, and the observable result is that pending review does not show a lack of operating permission and does not equal signing, a reached cooperation or an effective contract. Signing, a reached cooperation and an effective contract are three distinct facts.
How to verify the setup
- Context check. Input the sample contract text and the inspection record text, then raise a follow-up under the same chatId. Compare the history turns actually carried in with the set value, and observe whether the number of turns appearing in completeMessages or historyPreview matches the setting. A number above or below the setting does not meet the expectation.
- Draft-sentence check. Input the draft sentence to be judged, "Batch A has passed store acceptance, and the three percent loss is borne by the supplier," and compare it with the contract text and the inspection record text. Observe whether the answer restates only the sharing ratio and states that the acceptance conclusion lacks evidence; a direct assertion that acceptance has passed goes beyond the material.
- Empty-result handover check. Use an explicit paper input of [] as the retrieval return, compare it with the downstream node design, and observe whether the downstream handles the empty-result branch and keeps the gap open. Do not claim that a fictional rule retrieval necessarily returns []. Libraries built on different vector models cannot be associated together; check identifiers only, exclude non-matching records and record the actual observation.