What the documents look like
Trade return and claim work handles reverse logistics and liability determination after export. Materials arrive from customer email, quality inspection reports, customs systems and insurer claim systems. The documents handled day to day are return agreements, claim letters, quality reports and return customs declarations. These materials update irregularly, case by case. A single shipment may carry a return agreement, a claim letter and a customs declaration at the same time, and the parties, cargo object, quantity and time range across those three documents need cross-checking.
Document parsing and chunking must preserve document identity and version so that any chunk can be traced back to its source text. Without that anchor, comparison loses its reference point. The feature described here is contract and transaction material comparison, and the step in scope is document parsing and chunking. This page does not build business functions that lack a documented basis.
Constraints at the document chunking step
Chunking must follow the structure of the specific material and check paragraphs accordingly, so that conditions, explanations and the content they constrain are not split apart. Original data and retrieval indexes are distinct: one group of original data can map to multiple indexes, and an index being recalled does not mean the original data has been authorized. Semantic recall and relevance affect ordering only; they do not carry permission or entity isolation. The association between a retrieval library and a vector model cannot be extended to mean that external systems use the same model.
Hypothetical paper exercise sample: one Return Agreement states, "Party A agrees that Party B may return 120 units of batch A-001; the return reason is subject to the quality report; this agreement takes effect on the date both parties sign." A Claim Letter dated the same day states, "A claim is raised for 120 units of batch A-001; the amount is subject to confirmation by the quality inspection report." One draft sentence awaiting judgment reads, "Both parties have completed the return of 120 units of batch A-001 and confirmed the claim amount." The completed return and the confirmed amount asserted in the draft sentence appear nowhere in the source text, so the draft sentence is unsupported.
The stage here is the point after parsing and chunking, before any comparison output is treated as established. The authorization boundary is that retrieval returns candidate content; it does not confirm that a return was executed, that an amount was agreed, or that any party approved anything.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Search mode | Hybrid retrieval | Materials contain both identifiers and natural language, so both query types need coverage |
| Reference limit | Hypothetical starting value 3000 tokens | A starting value for this exercise only; compared against actual reference length after chunking |
| Minimum relevance | Hypothetical starting value 0.3 | A starting value for this exercise only; compared against the score distribution of recalled results |
| Question optimization | Enabled | Multi-turn follow-up needs coreference completion; compared against retrieval results with it disabled |
| Result reranking | ReRank enabled | Secondary ordering when candidates are numerous; compared against ordering before reranking |
| Chunking basis | By document structure and clause boundaries | Compared against the effect of fixed-length splitting |
The reference limit is expressed in tokens, the documented unit. Minimum relevance is a 0-1 value that applies only under semantic retrieval or when result reranking is used. It is a filter threshold, not a final ordering rule. RRF is a fusion step for combining multiple retrieval channels; it is not a switch to be turned on. Image retrieval paths require an image input and matching model capability, and reranking requires a model plus an enabled setting; neither runs on every request.
Three common errors
- Treating an index recall as authorization of the original data. Input: an index entry returned by retrieval. Comparison: the correspondence between that index entry and its original data record. Observable result: a judgment that treats the material as valid on the strength of the index alone.
- Treating a pending state as completed. Input: the Claim Letter stating the amount is subject to confirmation by the quality inspection report. Comparison: the draft sentence "the claim amount has been confirmed." Observable result: a pending item written as confirmed.
- Associating libraries across different vector models. Input: two library identifiers annotated with different vector models. Comparison: whether the identifiers match. Observable result: a cross-library retrieval executed even though the identifiers do not match.
How to verify the setup
- Input the Return Agreement text from the hypothetical sample and the draft sentence. Compare the "completed return" asserted in the draft sentence against the source wording "agrees that Party B may return." The condition is met when the draft sentence is marked unsupported because the source text does not state a completed status. A signature date and an effective date are separate facts from completion of the return.
- Input the Claim Letter text from the hypothetical sample and the draft sentence. Compare "amount subject to confirmation" against "amount confirmed." The condition is met when the pending item is marked pending verification rather than confirmed.
- Input two libraries carrying different vector model identifiers. Compare whether the identifiers match. The condition is met when, on a mismatch, the setup records the exclusion and does not execute cross-model retrieval. No recall outcome is asserted for a cross-model association, because the documented material does not describe one.
For an empty-result case, a paper input of an empty list can be used to check downstream handling; the documented material does not state that any particular query returns an empty list. Where a required material is absent from the accessible retrieval scope or from a defined manual input, the gap is recorded as a gap. Upload success is not the same as retrieval having updated; after a material changes, the actual training and index state need checking.