What the documents look like
Promotion enrollment and price management for a marketplace store revolves around four working documents: the campaign enrollment form, the promotional price approval sheet, the inventory lock sheet, and the campaign review sheet. The data that matters is price, stock, and campaign cadence. In order fulfillment and after-sales question answering, a single customer question can span several of these documents at once. A buyer may ask how the final payable price of an order was composed, whether campaign stock has been locked, or what state an approval sheet is currently in. These fields sit in different documents, and their states change as a campaign progresses.
The role of multi-turn prompts at this step is to map a user follow-up onto the materials that already exist. The prompt must state the document scope, the answering task, and how to behave when evidence is missing, so the model does not fill in business facts on its own. Conversation history determines whether earlier context is carried in. A new session and a continued session accept different inputs, and any check must keep them separate.
Two category facts shape this task. First, the core objects are price, stock, and campaign rhythm rather than promotional wording, so a review that only inspects phrasing misses the point. Second, these fields change weekly and per campaign, so a state read from one document cannot be assumed to hold in another. The update frequency itself does not alter the prompt feature described here.
Constraints at the multi-turn prompts step
Price, stock, and approval status are business facts. A retrieval hit on a similar passage does not constitute authorization or execution. Forms collect values; business verification, approval, database writes, and external synchronization each require their own downstream implementation. A similarity score does not act as a category, entity, or permission filter.
Hypothetical drill sample. Material text for comparison: "In campaign enrollment form A-0715, product SKU-2201 has an enrollment price of 199 yuan and an enrollment status of submitted. Promotional price approval sheet P-0715-03 covers SKU-2201, its approval status is pending review, and the approver has not signed. Inventory lock sheet L-0715 records SKU-2201 with a locked quantity of 300 units and a lock status of locked." Draft sentence to be judged: "The promotional price of SKU-2201 has been approved, the campaign stock of 300 units is locked, and shipment can be promised externally."
That draft sentence turns a pending-review approval status into approved, which is unsupported. A pending review does not show that operating permission is absent; signing, reaching agreement, and contract effectiveness are three distinct facts. Lock status and approval status are separate fields in the same material and cannot be derived from each other.
The configuration popup shows only the options the current model supports. When a model does not support multimodal recognition, no such option appears; when it does not support thinking configuration, that option is hidden as well. Selecting json_schema also requires filling in the corresponding format requirement. None of these settings changes whether a retrieval result falls inside an authorized scope.
Configuration and implementation checks
The items below relate to this page's sample and cover only documented settings or implementation checks tied to this feature and primary task. The values are starting points for this hypothetical trial, used for comparison, and are not official defaults.
| Configuration item | Hypothetical trial starting value | Comparison method and reason |
|---|---|---|
| Memory rounds | Keep a small number of history rounds | Customer service and knowledge-base Q&A typically keep few; compare answers with and without carried context |
| Response limit | Lower as needed | Lower it when short answers are wanted; compare the truncation point against a complete explanation |
| Temperature | On the low side | Low is suggested for customer service and rule-clear scenarios; compare stability across repeated answers to one question |
| Response format | Keep default | Default suits ordinary Q&A; change only when a downstream flow must read a fixed structure |
| Multimodal recognition | Select by model capability | The popup shows options by model capability; compare image-input parsing before and after enabling |
| Thinking configuration | Default | Use the model default; if switching causes an error, revert to default |
Three common errors
- Treating a pending approval status as approved. The error is reading "approval status is pending review, approver has not signed" as already approved. Check: input the approval sheet text, compare the approval status field value against the draft sentence wording, and observe whether the two agree.
- Deriving an approval conclusion from inventory lock status. The error is taking "lock status is locked" as proof that approval passed. Check: input the inventory lock sheet text, compare the lock status field and the approval status field, and observe whether mutually exclusive values appear.
- Treating a retrieval hit as grounds for an external promise. The error is assuming that a similar retrieved passage permits a shipment promise. Check: input the retrieved text and the draft sentence, compare whether either contains an approval or authorization field, and observe whether the draft sentence has material support.
How to verify the setup
- For the draft sentence "The promotional price of SKU-2201 has been approved," input the approval sheet text above and compare the approval status field value against the wording "has been approved." Expected: when the approval status is pending review, that wording is unsupported, and the evidence gap must be recorded.
- For the draft sentence "the campaign stock of 300 units is locked, and shipment can be promised externally," input the inventory lock sheet text and the draft sentence, and compare the locked quantity and lock status against the shipment promise to see whether any approval or authorization field connects them. Expected: lock status and shipment promise are different facts, and any authorization not stated remains missing.
- For a continued-session scenario, input the prior turns and the follow-up under the same chatId, and compare the history rounds actually carried in against the answer content. Expected: a new session and a continued session accept different inputs and must be checked separately; an empty-result handoff can be checked with an explicit paper input of an empty array against the downstream design, without claiming that a fictional rule retrieval necessarily returns an empty array.
Libraries across different vector models cannot be associated together; verify identifiers first and exclude those that do not match. Retrieval checks record only observations and failure branches, without guaranteeing a first hit or full recall.