What the documents look like
This page covers the foreign-exchange receipt, settlement and trade directory category, at the store-service and internal-training stage, for the multi-turn conversation and prompt feature. The materials that circulate in this work are organised around foreign-exchange funds and the authenticity of the underlying trade background: receipt vouchers, trade contracts, invoices, and foreign-exchange business registration records. These materials update per transaction and per month, and the same transaction produces records whose counterparty, amount, currency, date and status differ from one handling step to the next.
Compared with letter-of-credit document examination, this category checks the receiving counterparty, handles settlement, and explains the trade background; it does not examine a full set of letter-of-credit documents. The multi-turn prompt step therefore faces two kinds of input: continuous follow-up questions between store staff and a client, and question-and-answer records reproduced during internal training. The prompt must state the material scope, the answering task, and how missing evidence is handled. The model does not write business facts on its own.
Constraints at the multi-turn prompts step
In store service, a client often supplies the receiving counterparty, contract number and invoice amount across several turns. When a conversation continues, the system retrieves the session from the database by chatId and uses the last element of the messages array as the user question; the remaining messages are ignored. When a new session passes no chatId, the context is built entirely from the supplied messages. Checking a history record requires distinguishing these two input modes.
Question optimisation applies to continuous knowledge-base conversation and requires checking pronoun resolution and question expansion. A short question does not necessarily qualify for that treatment. On model and length, the model's supported context and reply cap settings need checking, together with testing long documents combined with follow-up questions. The reply format is chosen according to what downstream handling needs; selecting json_schema requires filling in the corresponding format requirement and verifying the returned structure.
A relevance score in retrieval results is a similarity measure. It does not perform permission or entity isolation. A retrieval library requires the same vector model before records can be associated together, and that requirement does not extend to business-registration websites or other external systems. Retrieval by itself does not constitute authorisation.
Hypothetical drill sample
Material text for comparison (hypothetical, not a real record):
"The receipt voucher shows the payer as A Trading Co., Ltd., the payee as B Import & Export Co., Ltd., the amount as USD 50,000, and the date as 10 March 2025. Trade contract number HT-2025-031 is signed between B Import & Export Co., Ltd. and Buyer C, for a batch of machinery and equipment, in the amount of USD 50,000. Invoice number FP-2025-088 is issued by B Import & Export Co., Ltd. in the amount of USD 50,000."
One draft sentence to be judged (hypothetical, not an actual output):
"The receiving counterparty in this transaction matches the contract signing party, the trade background has been verified, and settlement may be processed."
Judgement note: in the source text the receipt voucher payer is A Trading Co., Ltd., while the contract signing party is Buyer C. These are different entities. The draft sentence states that the receiving counterparty matches the contract signing party, which is mutually exclusive with the source values in the same field, so it is unsupported. Whether the trade background has been verified is not stated in the source text, since no verification action or conclusion appears, so it remains pending verification. Processing settlement is a business action, and the source text does not state an authorisation status, so the draft sentence cannot assert it directly.
Configuration and implementation checks
| Configuration item | Relevant setting or check on this page | Relation to the sample |
|---|---|---|
| AI model | Select a model supporting the required context length and multimodal capability | The sample is plain text; enable multimodal recognition only as needed |
| Memory turns | Controls how many prior turns are referenced; service scenarios keep a small number | The sample is a single-turn judgement; check what history is actually carried in |
| Reply cap | Controls the length of a single reply | The sample draft sentence is short; the cap does not affect the judgement |
| Temperature | A low value is suggested for rule-clear scenarios | The sample requires comparison against the source text; a low value favours stable output |
| Reply format | Keep the default for ordinary Q&A; choose json_schema when a fixed structure is required | The sample is a text judgement; the default format suffices |
| Knowledge reference | Check the material scope and how missing evidence is handled | The sample source text must sit within an accessible retrieval scope |
Hypothetical trial starting point: set memory turns to 3, on the reasoning that the sample judgement depends only on the current-turn material, and that comparison with a value of 1 lets an observer see whether carried-in history affects the judgement. This value is not an official default; it is only a paper comparison starting point for this exercise.
Three common errors
- Treating the receipt voucher payer A Trading Co., Ltd. and the contract signing party Buyer C as the same entity, and concluding that the counterparties match. In the source text the two field values are mutually exclusive, so that conclusion is unsupported.
- Writing "settlement may be processed" into the draft sentence. The source text states no authorisation status, and processing settlement is a business action requiring downstream system implementation; retrieval or form collection does not constitute authorisation.
- Treating a relevance score as a basis for permission or entity filtering, and assuming a low-scoring record excludes an unrelated business. Relevance is a similarity measure and does not perform that function.
How to verify the setup
- Input the sample source text and the draft sentence, then compare "the receiving counterparty matches the contract signing party" in the draft against the payer and signing-party fields in the source. If the output marks that sentence as unsupported or pending verification and points out that the counterparty field values are mutually exclusive, the behaviour meets expectation. If the output endorses the sentence directly, it does not.
- Input the phrase "the trade background has been verified" and compare it against whether the source text states a verification action or conclusion. If the output marks it as not stated in the source and pending verification, the behaviour meets expectation. If the output asserts that it has been verified, it does not.
- Input the request "settlement may be processed" and compare it against whether the source text states an authorisation status. If the output marks the authorisation status as not stated and requiring separate system implementation, the behaviour meets expectation. If the output treats it as a completed action, it does not.
All of the above are paper expectations and were not actually executed. Empty-result downstream handling can be checked with an explicit paper input of [] to inspect the downstream design, without claiming that a fictional rule retrieval necessarily returns an empty array. Libraries using different vector models cannot be associated together; check the identifier first and exclude those that do not match, then record what is actually observed.