What the documents look like
Returned-goods inspections handle inbound reverse parcels and assign a condition grade to each item. The operating object differs from outbound picking and packing: no new order is being fulfilled, and the material under review is a returned unit whose resale eligibility is still open. The data sources named for this category are the WMS returns module, platform after-sales records, carrier return parcels and the inspection station. The typical roles are the after-sales warehouse, the inspector and the inventory administrator. Errors in this category carry consequences such as resale of defective goods, refund disputes and inventory contamination. The daily documents are the return inbound note, inspection photographs, the grade determination sheet and the resale listing sheet. These materials update per item and per day.
This page covers document parsing and chunking for the inventory procurement and supplier materials task. The return inbound note records the returning party, the item object, the inbound status and the quantity scope. Inspection photographs record appearance state. The grade determination sheet states a grade conclusion. The resale listing sheet records the range eligible for resale. These four materials form a verification chain; when one is absent, an evidence gap remains. Chunking must preserve the document identity and version that allow a chunk to be traced back to its source, and conditions, notes and the content they constrain must not be split apart. One set of source data can map to multiple indexes, and source data must be distinguished from retrieval indexes. Retrieval does not carry authorization: semantic recall and relevance scores do not perform permission or entity isolation. Image retrieval requires an image input and model capability, reranking requires a model and must be enabled by configuration, and the optional paths shown in the overall document flow diagram do not all execute on every request. Libraries built on different vector models cannot be associated together; identifiers must be checked first and non-matching libraries excluded.
Hypothetical paper exercise sample: an after-sales warehouse received a return inbound note dated 10 March 2026 whose source text states "Returning party: after-sales warehouse A; item object: model X-100 small appliance, 3 units; inbound status is pending inspection; quantity scope: 3 units." The grade determination sheet source text states "Model X-100, 3 units total, appearance grade B, conclusion: eligible for resale." The draft sentence awaiting review reads "Model X-100, 3 units total, has completed resale listing, and the procurement replenishment request has been submitted." This draft exceeds the source materials: no resale listing sheet was provided, and no authorization basis exists for a procurement replenishment request.
Constraints at the document chunking step
The chunking step must keep the conditions, notes and constrained content together, and each chunk must retain the document identity and version that allow it to be traced back. The source data and the retrieval index are separate: one set of source data may correspond to multiple indexes, and a single chunk may carry multiple index entries. Retrieval is a lookup action, not an authorization action. A relevance score is a similarity value, not a category, entity or permission filter, and it does not exclude unrelated businesses or unauthorized records. The full-text retrieval path depends on the vector store: with Milvus (version 2.5.16 or above), full-text retrieval uses BM25 with vectors and full text stored together in the single modeldata_v2 table, and language identification defaults to lingua, switchable via MILVUS_LANGUAGE_IDENTIFIER=whatlang. With other vector stores (PG, OceanBase, SeekDB, openGauss), full-text retrieval uses MongoDB $text with jieba tokenization. Hybrid retrieval combines vector and full-text results through the RRF formula. Reranking produces a 0-1 score, and FastGPT merges rerank, vector and full-text results through RRF. The relevance floor applies only under semantic retrieval or when reranking is used. Image retrieval depends on whether the visual model or image-capable vector model is configured and whether an image index was generated at ingestion time.
For the sample, the return inbound note number is a precise identifier suited to full-text retrieval, while the item condition description is suited to semantic retrieval. The sample question is complete, so question optimization is not enabled, which keeps the extra model call and added latency out of the flow. The candidate count is small, so reranking is not enabled. The inspection photograph requires confirmation that an image index was generated at ingestion; without that index, retrieval will not match, and the missing index is recorded as an evidence gap rather than inferred image content.
Configuration and implementation checks
| Configuration item | Setting or check relevant to this page | Relation to the sample |
|---|---|---|
| Search mode | Semantic, full-text or hybrid retrieval selected by material type | Return inbound note number uses full-text; item condition description uses semantic |
| Reference cap | Each search references at most n tokens | Hypothetical trial starting value 800 tokens, chosen because each of the four materials carries little text, compared against 400 tokens to observe recall completeness |
| Relevance floor | A 0-1 value effective only under semantic retrieval or reranking | Hypothetical trial starting value 0.3, compared against 0.5 to observe filtering strength |
| Reranking | Requires a ReRank model and must be enabled by configuration | Used for secondary ordering when candidates are numerous; not enabled for this sample |
| Question optimization | Coreference resolution and question expansion before retrieval | Sample question is complete; not enabled to control latency |
| Image index | Whether an image description or image vector index was built at ingestion | Inspection photograph requires confirmation that ingestion built the index; otherwise retrieval cannot match |
Three common errors
- Treating a retrieval hit as authorization to execute. In the sample, retrieving the "eligible for resale" conclusion does not establish that resale listing was completed, and it does not establish that a procurement replenishment request was submitted. Retrieval is a lookup action; business execution requires a separate downstream system implementation.
- Writing a pending inspection status as a completed inspection. The sample source states the inbound status as "pending inspection," while the draft sentence writes "has completed resale listing," which advances the status beyond the source. A pending review does not show a lack of operating permission, and it does not equal approval.
- Associating libraries across different vector models. Knowledge bases built on different vector models cannot be associated together. Identifiers must be checked first and non-matching libraries excluded; a similarity score cannot be used to infer entity isolation or permission filtering.
How to verify the setup
- Input the sample return inbound note source text and the draft sentence, and compare whether the draft exceeds the status and scope stated in the source. The observable result is that the draft contains a resale listing sheet and a procurement replenishment request that were not provided; the draft is judged unsupported.
- Input the sample grade determination sheet source text, and compare whether "appearance grade B" and "eligible for resale" share the same subject, the same period and the same field. The observable result is that they belong to the same note and the same model, and the conclusion is consistent with no contradiction.
- Input the sample inspection photograph, and check whether ingestion generated an image index for that photograph. The observable result, when the index is missing, is that retrieval does not match; this is recorded as an evidence gap, and no image content is inferred.
When a knowledge base search returns an empty result, a clearly written paper input [] can be used to check the downstream design; no claim is made that a fictional rule retrieval necessarily returns an empty array. After materials change, the actual training and index state must be checked; a successful upload does not equal an updated retrieval state.