What the documents look like
Central procurement and distribution comparison draws on materials from the headquarters purchasing and delivery chain. Framework procurement contracts record the supplier, material, price and delivery arrangement. Replenishment plans, distribution notes and store requisition forms record the quantities and dates that actually occurred. These materials update daily or weekly. The same material reappears across contracts and transaction documents, and field names look similar while their meaning is layered: the contract states what was agreed, the transaction document states what was executed.
The comparison task is therefore not single-document question answering. One reconciliation pass needs the contract clause, the planned quantity, the distribution actuals and the store request together, and the model must complete a field-level comparison inside a limited context. Material length varies sharply. Contract paragraphs run long, distribution note lines run short, and cutting by item count readily drops a key line.
Constraints at the context limits step
The reference cap is controlled by tokens, not by item count. In a mixed knowledge base, chunk lengths differ widely, so taking content by top k produces unstable results; reference content must be arranged against a token budget. The context window and the reply cap are two independent settings. The reply cap controls output length and cannot be used as the full context capacity.
At the retrieval stage, semantic recall, full-text recall, RRF fusion and ReRank belong to candidate content organisation and do not perform permission decisions. A retrieval result shows that content was recalled; it does not show that the current operator is entitled to view or execute the business action attached to that material. Number and model fields suit full-text or hybrid retrieval, while natural-language descriptions suit semantic retrieval.
Hypothetical drill sample: a chain enterprise supply chain centre reconciles one framework procurement contract against a batch of distribution materials in March 2025. The contract text reads: "Party A: the supply chain centre of a North China chain enterprise; Party B: a food supplier; material: frozen dough type A; agreed unit price 12.00 yuan; supply period 1 March 2025 to 31 March 2025; monthly planned quantity 500 cases." The distribution note text reads: "Distribution date 18 March 2025; material: frozen dough type A; actual distributed quantity 120 cases; receiving store: Store No. 3." The draft sentence to be judged reads: "The supplier completed the 500-case supply for March under the contract." The reconciliation request reads: "Please confirm whether this draft sentence is supported by the materials."
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this page's primary task, using the sample above. The values are starting points for this hypothetical trial, used to explain the reason for the choice and the comparison object; they are not official default values.
| Configuration or check item | Starting point for this trial | Reason and comparison object |
|---|---|---|
| Reference cap | Set to a token amount covering the contract clause paragraph and the distribution note line | Compared with the total length of the sample materials, to confirm key fields are not clipped |
| Minimum relevance | Not raised for now | Compared with recalled content, to avoid filtering out the distribution note line |
| Search mode | Hybrid retrieval | Material name and number need full-text hits, while clauses need vector recall |
| Reply format | Keep default | The draft sentence judgement does not need fixed-structure output |
| Memory turns | Keep a small number of prior turns | Compared with an empty-history input, to rule out differences carried in from earlier turns |
| Reply cap | Enough to write the judgement and its basis | Compared with the draft sentence length, to avoid the judgement being truncated |
Three common errors
- Treating the reply cap as the context window. The input is the reply cap setting value; the comparison object is the content length the model can actually reference; the observable result is whether long materials are clipped at the input stage. These are not the same setting.
- Treating a retrieval hit as authorisation. The input is one recall result; the comparison object is the current operator's material access scope; the observable result is whether unauthorised materials appear among the candidate content. Retrieval does not perform permission filtering.
- Treating a pending review request as approved supply. The input is the reconciliation request in the sample; the comparison object is the quantity and status recorded in the contract and the distribution note; the observable result is whether the completed supply claimed in the draft sentence has corresponding actual distribution records. The request is in a pending-judgement state.
How to verify the setup
- Verification one: input the sample contract text and distribution note text, compare the quantity and status in the draft sentence "The supplier completed the 500-case supply for March under the contract", and observe that the contract agreed quantity is 500 cases while the distribution note actual quantity is 120 cases. The completed supply claimed in the draft sentence is not supported by the materials and remains to be verified; it does not constitute a contradiction, because the distribution note records only one delivery.
- Verification two: input the same question under an empty-history condition and a with-history condition, compare whether the reference content sent to the model is the same in both, and observe whether the memory turns setting changed the recall scope. If the two reference contents differ, record the context difference and do not use it to decide which result is correct.
- Verification three: input an explicit paper empty-result downstream scenario, compare the downstream node's output design when the reference content is empty, and observe whether the downstream handles it as empty input. This check does not claim that a fictional rule retrieval necessarily returns an empty result.
Libraries across different vector models cannot be associated together. During reconciliation, check the library identifier first and exclude those that do not match, record the actual observation, and do not infer a runtime result. Image retrieval needs the corresponding image input and model capability, and reranking needs an available model enabled by settings; these paths do not execute automatically because of this page's configuration.