What the documents look like
Fresh-food supplier claims pursue responsibility for quality problems found at goods receipt. They are accounted for separately from ordinary store-level shrinkage. A single delivery batch can generate several document types: a quality exception note, photographic evidence, a deduction notice, and a claim reconciliation statement. The underlying data comes from the quality inspection system, WMS receiving records, the supplier contract, and financial reconciliation.
In a cross-border setting, one batch may carry a Chinese-language quality exception note, a supplier contract in another language, and a bilingual deduction notice at the same time. Retrieval work therefore has to check each material type on its own terms rather than treating the batch as one uniform record. The confidence level attached to this category description is approximate, so the document mix above is a working expectation rather than a fixed inventory.
The quality exception note typically holds a batch number, an acceptance date, an exception quantity, and a handling conclusion. The photographic evidence enters the knowledge base as images. The deduction notice and the claim reconciliation statement carry amounts and periods. These differences matter at the chunking step, because a chunk that separates a conclusion from the condition it depends on will not answer a question about that condition.
Constraints at the document chunking step
Chunking for this category has to keep fields that belong to the same finding inside the same segment. For the quality exception note, the batch number, acceptance date, exception quantity, and handling conclusion should stay together. For the deduction notice and the claim reconciliation statement, the chunk should preserve the subject, the object, the status, and the effective scope, because a claim question usually turns on which party, which batch, and which period a statement covers.
Photographic evidence is a separate case. Whether a photo can be retrieved depends on whether an image description index or an image vector index was built when the image was stored. The documented storage structure keeps original data in the MongoDB dataset.datas table, with an indexes field recording the vector IDs that point to it. One set of original data can map to more than one vector. If no image index was generated at intake, the photo is present in storage but not reachable through image retrieval, and the search parameters alone will not change that.
Multilingual retrieval rests on two different mechanisms. Semantic retrieval depends on the vector model's cross-language understanding, so a Chinese question can match an English knowledge point when the model supports it. Full-text retrieval depends on tokenization and language identification instead. Hybrid retrieval runs both and merges the results through RRF. The documented conditions for full-text retrieval differ by vector store: with Milvus at version 2.5.16 or above, BM25 is used with lingua as the default language identifier, switchable to whatlang; with PG, OceanBase, SeekDB, or openGauss, full-text retrieval goes through MongoDB $text with jieba tokenization. The brief does not state which store a given deployment uses, so that remains an implementation check rather than an assumption.
A hypothetical paper exercise sample is set out here for illustration only. The contract excerpt reads: "Party A received the goods acceptance record for batch A-0310 on 10 March 2025; the quality inspection conclusion was non-conforming, covering 200 boxes. Party B shall confirm within fifteen days of receiving the deduction notice." The sentence proposed for assessment reads: "The claim for this batch has been confirmed by Party B." That sentence lacks evidence of any confirmation act by Party B, so the assessment is unsupported on the material provided. No real customer, company, or identity number is involved.
Configuration and implementation checks
| Check item | Documented setting or implementation check relevant to this page | Hypothetical starting value and comparison method for this exercise |
|---|---|---|
| Search mode | Semantic retrieval, full-text retrieval, or hybrid retrieval | Hybrid retrieval is the starting point because the sample mixes a batch number with natural language; compare batch-number hits against a semantic-only run |
| Reference cap | Maximum tokens cited per search | 3000 tokens as a starting point because the three sample passages total roughly 800 characters; compare completeness against a 1500-token run |
| Minimum relevance | A 0-1 value, effective only under semantic retrieval or reranking | 0.4 as a starting point because the sample carries an explicit batch number; compare the count of unrelated fragments against a 0.6 run |
| Question optimisation | Coreference removal and question expansion before retrieval | Off as a starting point because the sample question is complete; compare latency and recall against an enabled run |
| Index creation | Whether image intake produced an image description index or an image vector index | Check whether the indexes field is non-empty after the photographic evidence is stored |
| Training state | Whether the data has completed training | Check the actual training and index state after upload |
These values are exercise starting points chosen for the sample, not official defaults. The reference cap uses tokens rather than a top-k count because chunk lengths vary widely across mixed knowledge bases. The minimum relevance value is a filter threshold, not a final ranking rule. RRF is the merge process applied to hybrid results, not a switch that is turned on.
Three common errors
- Treating a successful upload as proof that retrieval has updated. After upload, the training and index state still needs to be checked. In the sample, if the deduction notice has not finished training, a search may return an older version of that content.
- Treating a similarity score as a permission filter. The minimum relevance setting filters low-relevance results; it does not exclude records the requester is not authorised to see. In the sample, Party B's confirmation status still requires manual checking against the source material.
- Treating the RRF-merged output of hybrid retrieval as a single vector ranking. In the sample, the batch number may be recalled by the full-text path while the natural-language portion is recalled by the semantic path, so the final order depends on how the multiple paths are merged.
How to verify the setup
- Enter the three sample passages and the proposed sentence, then compare whether the retrieved result contains batch number A-0310 together with the inspection conclusion. If the returned content omits the inspection conclusion, chunking may have separated the condition from the conclusion.
- Enter the proposed sentence "The claim for this batch has been confirmed by Party B" and compare whether the returned content contains evidence of a confirmation act by Party B. If only the deduction notice text is returned, the confirmation fact remains unsupported.
- Enter a paper input of [] to check how the downstream design handles an empty result. If the downstream interprets an empty result as meaning no claim record exists, record that interpretation as unverified against business rules. An empty result does not by itself establish absence of a claim.
Retrieval is not authorisation. Forms collect values; business verification, approval, database writes, and external synchronisation require their own stated downstream implementation. Where a document field was not provided, it remains unknown.