What the documents look like
Fresh-food supplier claims pursue quality responsibility for goods at arrival. This work is separate from near-expiry markdown handling, which addresses natural in-store loss. Claims materials include quality exception forms, photographic evidence, deduction notices and claim reconciliation statements. Sources span the quality inspection system, WMS receiving records, supplier contracts and finance reconciliation.
Each arriving batch produces one group of materials. Each month produces a reconciliation scope. Materials therefore exist at two granularities: batch and month. This shape drives chunking requirements. A chunk must retain the batch identifier, the supplier entity, the receiving date and the quantity scope. When any of these is split away from the content it constrains, later verification loses its traceable link to the source text.
The materials differ in structure. A quality exception form carries an entity, a batch, an exception description and a determination conclusion. Photographic evidence carries a photographed object and a time. A deduction notice carries an amount basis and a referenced clause. A claim reconciliation statement carries a period and line-by-line detail. Segmentation should keep a condition, its explanation and the content it constrains in the same segment. A claim amount should not be separated from the batch to which it applies.
Original data and retrieval indexes are distinct. One group of original data can map to multiple indexes. A retrieval hit on any one index recalls that group of original data. Retrieval is a lookup action. It does not perform authorization checks. A similarity setting does not exclude unrelated suppliers or unauthorized records.
Constraints at the document chunking step
The chunking step must preserve the identities listed above. Batch identifiers, supplier entities, receiving dates and quantity scopes are the fields that connect a claim to its evidence. When a chunk loses one of these, downstream reconciliation cannot point back to the exact source passage.
The step must also respect the difference between original data and indexes. FastGPT stores vector source data in the MongoDB dataset.datas table, with an indexes field recording the vector IDs it maps to. That field is an array, so one group of data can correspond to multiple vectors. In PostgresSQL, a vector field stores the vector. During retrieval, vectors are recalled first, then the vector ID is used to find the original content in MongoDB. If the same group of original data is matched, the results are merged and the highest vector score is taken.
A hypothetical paper exercise sample follows. The source material reads: "Supplier: Qinghe Vegetable Cooperative; Batch: arrived 2025-04-12; Object: Shanghai bok choy, 320 kg; Quality conclusion: leaf wilting ratio exceeds standard, deduction determined; Basis clause: Contract Appendix 3, Clause 2." The draft sentence to be assessed reads: "Qinghe Vegetable Cooperative's 2025-04-12 batch of Shanghai bok choy has completed deduction under Contract Appendix 3, Clause 2." The source states only that a deduction was determined. It does not state that the deduction was executed. The draft sentence is unsupported.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this page, tied to the sample above. The values are hypothetical starting points for this exercise. The reason and comparison method are stated for each.
| Configuration item | Hypothetical starting point | Reason and comparison method |
|---|---|---|
| Search mode | Hybrid search | The sample contains a batch number and natural-language description; compare recall completeness against semantic search alone |
| Reference limit | Measured in tokens; starting point set to cover all materials for one batch | Compare against a shorter limit covering only the exception form; observe whether reconciliation line items are truncated |
| Minimum relevance | A 0-1 value; starting point at the midpoint | Compare against a higher and a lower setting; observe whether unrelated batches enter the reference |
| Result reranking | ReRank enabled per settings | Compare candidate ordering against reranking disabled; the rerank score is 0-1 |
| Question optimization | Enabled based on observed effect | Compare recall on follow-up questions against disabled; note the additional model call latency |
| Index creation | Confirm indexes were generated at ingestion | Compare against an uploaded-but-untrained state; observe whether retrieval results differ |
Three common errors
- Treating "deduction determined" as "deduction executed." The sample source states only the quality conclusion and the basis clause. The draft sentence adds a completion status. Check: input the draft sentence and the source, compare the entity, batch and status fields. When the source contains no execution record, the sentence does not hold.
- Treating a retrieval hit as an authorization pass. Retrieval returns reference content only. It does not verify whether the operator is authorized to handle that supplier claim. Check: input a retrieval request, compare the returned content against the permission list. When the returned content contains no authorization conclusion, no executable action can be inferred.
- Treating a successful upload as an updated index. After material changes, the actual training and index state must be checked. Check: input the changed material, compare the upload record against the retrieval result. When retrieval still returns old content, the index has not been updated.
How to verify the setup
- Verification one: input the sample source and the draft sentence. Compare the field difference between "deduction determined" and "deduction completed." When the source does not state execution, the draft sentence is judged unsupported. The condition is met when a field-by-field comparison confirms the status field is absent.
- Verification two: input the batch number "2025-04-12" and the natural-language query "Shanghai bok choy deduction basis." Compare the material groups returned by the two retrieval paths. The condition is met when both can point back to the same group of original data and the reference does not exceed the configured limit.
- Verification three: input an empty-result scenario, using the paper input [] to check downstream design. Compare the system return against the expected empty set. The condition is met when downstream handles it as an empty set and produces no fabricated reference. All of the above are paper expectations and were not actually executed. The index state after material changes, whether the deduction was executed, and whether authorization passed are all unsupported or pending verification. The evidence gaps remain.