What the documents look like
Supplier entry settlement for supermarkets relies on purchase contracts, delivery acceptance notes, rebate agreements and reconciliation statements. The data comes from ERP purchasing, supplier portals, POS sales and finance systems, and it updates weekly or monthly. Settlement in this category usually runs as purchase-sale or consignment accounts payable, and a supplier may have no on-site operation at the store. That separates it from a large-format joint-operation counter, where on-site trading is typical. Reconciliation, rebate deduction calculation and return-difference handling are the most time-consuming daily steps, and account disputes can affect a supplier's willingness to keep supplying. A multi-turn conversation in this setting has to let follow-up questions reference earlier material inside the same session, while the model refrains from writing business facts that the documents do not contain.
Constraints at the multi-turn prompts step
Materials are spread across contracts, acceptance notes, rebate agreements and statements, and the same account item can carry different field conventions in different documents. During follow-up turns, a model can carry an amount, period or party mentioned in an earlier turn into the next one and produce a conclusion that no document supports. Memory turns determine how much prior context is carried in; a large value pulls in earlier content and raises consumption, while a small value leaves prior information unused. Reply format follows the downstream consumer, and only a later flow that reads a fixed structure calls for json_schema together with the matching format requirement. Retrieval is a recall process and does not perform authorization or party isolation; a similarity score does not separate suppliers or stores, so it cannot be used to decide that a record belongs to the current party. The interactive node configuration returned by the interface is a display configuration containing type and params; a form collects values, and business verification, approval, database writes and external synchronization each need their own downstream implementation.
Configuration and implementation checks
The settings below serve this page's documents and the order-fulfilment after-sales task. The values are hypothetical starting points for this exercise, not official defaults.
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| AI model | A model whose displayed maximum context covers the combined sample material | Compare the maximum context shown in the dialog against the combined length of the sample documents; change model when it is insufficient |
| Memory turns | 3 turns | Compare against 1 turn and 6 turns, and observe whether a follow-up still references the statement period |
| Temperature | Low | Compare against the default value and check the stability of two answers to the same question |
| Reply format | Default | Switch to json_schema and fill in the format requirement only when a downstream node reads fixed fields |
| Multimodal recognition | Image recognition enabled only if the dialog shows the capability | Check whether the dialog displays the capability; leave it off when it is not shown |
| Thinking configuration | Default | Compare against the no-thinking option and observe the response on a simple follow-up |
Three common errors
- Treating a similarity score as a party or permission filter. The
scorereturned by retrieval only expresses recall relevance, and the same question can produce close scores across materials from different suppliers. The comparison should checkdataset_idand source identifiers, because the score itself does not establish attribution. - Treating a larger memory-turn value as a way to raise accuracy. A larger value carries in more prior content. Compared with a smaller value, the check is whether an answer references content outside the current material range, while also watching for a change in answer length.
- Treating a display configuration returned by an interactive node as an executed action. The returned
interactivecontains onlytypeandparams, and a form collects values. Business verification and writes require a separate downstream implementation, so receiving the configuration does not mean an approval is complete.
How to verify the setup
Hypothetical paper exercise sample: the source material reads "Supplier A signed a purchase-sale contract with Store B, with a monthly settlement cycle of 30 days; the March 2025 delivery acceptance note records an accepted quantity of 120 pieces; the rebate agreement sets a rebate of 2% for this category." The draft sentence to be judged is "Supplier A completed settlement for March 2025 under the contract, and the rebate has been deducted." The question is whether the draft sentence is supported by the material.
- Input the source material above together with the draft sentence, and compare the settlement-completed status in the draft against the three fields the material lists: contract settlement cycle, accepted quantity and rebate rate. The material states only the agreed terms and the accepted quantity, and does not state that settlement is complete. The observable result is that the draft sentence goes beyond the material, so it is judged unsupported.
- Input consecutive follow-ups under the same
chatId, and compare the period referenced in the second answer against the material period in the first turn. If the second turn introduces a month or amount not listed in the material, the observable result is that context has carried in out-of-range content, and the memory-turn value should be lowered before retesting. - Input an empty retrieval result and the downstream handover design, and compare whether the downstream branches on an empty result. If the downstream still outputs a business conclusion when no quote exists, the handling for the missing-evidence case needs to be added. All of the above are paper checks and were not executed.