What the documents look like
This page covers one category: foreign-exchange receipt and settlement plus trade directory administration. The working materials are receipt vouchers, trade contracts, invoices and foreign-exchange business registration records. Compared with letter-of-credit document examination, this category centres on the authenticity of foreign-exchange funds and the underlying trade background, and it does not examine a full set of letter-of-credit documents. The fields that matter at parsing and chunking time are therefore the receiving entity, the amount, the contract number and the registration status.
Materials update per transaction and per month. A single receipt voucher and its corresponding contract and invoice need to be recallable inside the same search scope. Multilingual materials mix Chinese and English terminology, so a chunk that separates a subject or a status from the content it constrains will not support later verification. The stated consequences of error are bank return of documents, abnormal foreign-exchange classification and funds that cannot be booked.
Constraints at the document chunking step
Chunk completeness requires splitting by the actual structure of each material type. Conditions, explanations and the content they constrain stay inside one data block. Data and indexes are distinct: original data is stored in the MongoDB dataset.datas table, and the indexes field records the corresponding vector IDs, so one set of original data can map to multiple vectors. Vectors are stored in the PostgresSQL vector field with an HNSW index. At retrieval time vectors are recalled first, then the vector IDs are used to find the original data in MongoDB; entries corresponding to the same set of original data are merged and the highest score is taken. Multi-vector mapping lets a longer text carry several vectors, and recall of any one of them recalls that data.
Semantic retrieval supports cross-language understanding. Full-text retrieval suits numbers and proper nouns. Hybrid retrieval merges results through RRF. ReRank produces a 0-1 score used for filtering. The minimum relevance value takes effect only in semantic retrieval or when result reranking is used. The reference limit is controlled in tokens. Retrieval and similarity scores do not carry authorization or entity-isolation functions, and libraries built on different vector models cannot be associated together.
Hypothetical exercise sample: the source material reads "Party A: Company A; Party B: Company B; Contract No.: HX-2024-017; Receipt amount: USD 52,000; Receipt date: 5 November 2024; Corresponding invoice No.: FP-2024-1105; Foreign-exchange business registration status: registered." The draft sentence to be judged is "Company B completed settlement of USD 52,000 under contract HX-2024-017 on 5 November 2024." The draft treats the receipt date and completed settlement as one fact. The source states the receipt and the registration status only, and does not state that settlement was completed.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Search mode | Hybrid retrieval | The sample contains a contract number and a natural-language question; compare recalled content against semantic retrieval alone and full-text retrieval alone |
| Minimum relevance | Hypothetical starting point 0.3 | This value takes effect only in semantic retrieval or result reranking; compare against 0.2 and 0.4 by number of recalled items and observe whether fragments with a mismatched subject are filtered out |
| Reference limit | Hypothetical starting point 2000 tokens | Controlled in tokens; compare against 1000 and 3000 and observe whether the contract number and status field enter the referenced content intact |
| Question optimisation | Enabled | The sample contains a reference and mixed languages; compare recalled content for the same question with the setting disabled |
| Rerank | Enabled | When candidates are numerous, apply a second ordering by 0-1 score; compare ranking positions with the setting disabled |
| Chunk verification | Manual check against material structure | Check whether subject, contract number and status sit in the same data block as the content they constrain |
Three common errors
- Treating the receipt date as the settlement completion date. Input: the sample source text above and the draft sentence. Compare the "receipt date" field with "settlement completed". The source does not state that settlement was completed, so the draft sentence is unsupported.
- Treating a successful upload as an updated retrieval index. Input: the material change record and the training status. Compare the upload time with the index creation status. While training is incomplete, retrieval results still reflect the old content.
- Treating a similarity score as a permission filter. Input: a cross-entity query and the returned fragments. Compare the returned content with the querying entity. A high or low score does not exclude records of an unrelated entity.
How to verify the setup
- Input the sample source text and the draft sentence. Compare the date, amount and contract number in the draft against the same fields in the source. When the source does not state that settlement was completed, record the draft as unsupported and record the evidence gap.
- Input the contract number "HX-2024-017" and a natural-language question. Compare whether the recalled fragments for both inputs contain the subject, the amount and the registration status. If any one is missing, record a chunking problem.
- Input an empty-result handover case, using a paper input of an empty list to check the downstream design, and observe whether the downstream handles it as a gap. Do not claim that a fictional rule search necessarily returns an empty list. For a cross-model case, first check the identifier and exclude non-matching libraries, then record the actual observation.