What the documents look like
In the foreign-exchange settlement and trade directory category, contract and transaction material comparison works across receipt vouchers, trade contracts, invoices, and FX business registration records. The comparison checks whether the counterparty, amount, currency, goods description, and registration status agree across those materials. Material updates follow a per-transaction and monthly rhythm, and each comparison conclusion is formed document by document. Bank rejection, an abnormal FX classification, and funds that cannot be credited are the common consequences of an error, so any comparison needs to keep traceable source wording.
Two features shape this task. First, settlement review focuses on the authenticity of FX funds and the trade background; it does not review a full set of letter-of-credit documents. Second, the comparison subject is a set of related materials rather than one instrument, so the model must hold a contract, a receipt voucher, an invoice, and registration data in one request while preserving the exact names and amounts that the conclusion depends on.
Constraints at the context limits step
The maximum context of a model sets how much content a single request can reference. The reply limit constrains output length only, and the two cannot substitute for each other. The knowledge-base reference limit is controlled by tokens, so a long single material may be trimmed, and the reference content must be checked against a question sample for completeness. Memory turns set how many earlier chat turns are referenced, so the same question submitted with empty history and with history produces different input, and the context difference must be confirmed before comparison. When a fixed reply format such as json_schema is selected, field completeness and successful parsing must be verified; checking text length alone does not confirm that the structure is usable.
Hypothetical paper exercise sample. The source materials read: "Domestic company A signed a goods export contract with overseas company B on 10 March 2026, contract number HT-2026-0310, amount USD 120,000, settlement by telegraphic transfer. On 18 March 2026 company A received a bank receipt voucher; the payer is overseas company C, amount USD 120,000, and the remark states that it corresponds to contract HT-2026-0310." A second material is an invoice stating that the buyer is overseas company B and the amount is USD 120,000. The draft sentence to be judged is: "The receiving party and the contract signing party are consistent, and the trade background has been verified." This draft sentence involves a counterparty consistency judgment. The voucher payer and the contract signing party have different names, so it must be checked whether they belong to the same group or to a payment-on-behalf arrangement. The materials do not state such an arrangement, so that point remains unverified. The draft sentence asserts consistency directly, which the source wording does not support.
Configuration and implementation checks
| Configuration item | Hypothetical starting value for this exercise | Reason and comparison object |
|---|---|---|
| AI model | A model that supports a long context | Compared with the total length of the contract and voucher source text, to confirm one request can hold both |
| Memory turns | 2 turns | Compared with the prior context needed for a single comparison, to avoid carrying unrelated history |
| Reply limit | A medium length | Compared with the evidence explanation the draft sentence needs, keeping counterparty, amount, and status fields |
| Reference limit | A medium token value | Compared with the length of a single material, to check whether the voucher and contract are referenced in full |
| Reply format | json_schema | Compared with the downstream field parsing requirement, to confirm counterparty, amount, and status fields are present |
| Minimum relevance | Keep the default | Compared with semantic retrieval results, to observe whether low-relevance fragments are filtered |
The minimum relevance value is a filter threshold, not a final ranking rule. It applies only under semantic retrieval or when result reranking is used. A relevance score is not a category, entity, or permission filter, and it does not exclude unrelated businesses or unauthorized records. Retrieval is not authorization. RRF is a fusion step for mixed results, not a standalone switch. The thinking budget controls model reasoning intensity and is unrelated to the reference token limit. A pending review state does not show that an operation permission is missing, and signing, cooperation being reached, and contract effectiveness are three different facts.
Three common errors
- Treating the reply limit as the full context window, so a long contract is truncated and the judgment still proceeds as if the material were complete. Check: submit the full contract text and the full voucher text, compare the tokens actually included in the request with the total tokens of the materials, and observe whether truncation appears. The observable result is a request that omits part of the contract or voucher wording.
- Submitting the same question with empty history and with history without confirming the context difference, then treating the two conclusions as identical. Check: submit the same comparison question once with empty history and once with two prior turns, compare the two inputs, and observe whether the conclusion changes because of the historical content. The observable result is a different input set between the two submissions.
- Using a fixed reply format and checking only text length, without verifying field completeness and successful parsing. Check: submit the draft-sentence generation request, compare the counterparty, amount, and status fields in the returned structure, and observe whether parsing succeeds. The observable result is a returned structure that is missing a required field or that fails to parse.
How to verify the setup
- Input the contract source text, the voucher source text, and the draft sentence from the hypothetical sample. Compare the draft sentence claim that the receiving party and the contract signing party are consistent against the payer company C and the signing party company B in the source text. Observe whether a counterparty inconsistency notice appears. If the draft sentence directly asserts consistency, the condition is not met.
- Input the same material set, set the reference limit to a smaller value, and submit again. Compare the reference content returned in the two submissions and observe whether the contract number in the voucher remark is still included. If the contract number is missing, the reference was trimmed and the limit needs adjustment.
- Input an empty-result scenario using the explicit paper input
[]and check the downstream handling design. Compare the downstream node output when no reference content is present and observe whether an unsupported conclusion appears. If the downstream still generates a counterparty consistency judgment, the handling design needs correction.
For the empty-result case, the design must be checked against the stated paper input rather than assumed to occur from a rule. The comparison must use the same counterparty, the same period, and the same field; only mutually exclusive values in the same field constitute a contradiction. A value that is not stated, or that has only related-stage evidence, remains unsupported or pending verification. Evidence gaps must be preserved as gaps.