What the documents look like
Platform refund and return handling runs order by order. A refund request, a return waybill, quality-inspection photos, and a refund approval are held in separate systems, and each order carries its own update cycle. Customer-service chat and the after-sales console record the stated reason; WMS receiving and inspection photos record the condition of the returned item; payment refund records carry the amount. At the document parsing and chunking step, each of these materials keeps its own document identity and version.
Chunking quality depends on data length, completeness, and diversity. If a conditional clause and an amount inside a refund request are split apart, or a waybill number and delivery status are separated, the retrieved fragment can lack its subject or its valid scope. Vector search recalls candidates by similarity, full-text search depends on keyword hits, the two are merged through RRF, and ReRank provides a second ordering. Refund amounts, waybill numbers, and approval status are exact fields, suited to full-text or hybrid search.
Constraints at the document chunking step
A chunk keeps its semantics complete and single. One data group can map to several vectors, and one chunk can carry several indexes; a hit on any one vector recalls that data group. Original data and retrieval indexes live in different stores. In MongoDB, the dataset.datas table holds the original data and an indexes array; in PostgresSQL, a vector field holds the vectors. Retrieval recalls vectors first, looks up the original data by vector ID, merges entries that resolve to the same data group, and takes the highest score.
Whether images participate in retrieval depends on the index built at ingestion and on model capability. With an ordinary vector model and no vision model, a pure image query is largely unusable; a vector model that supports image input can run image vector retrieval. The minimum relevance value takes effect only under semantic search or result reranking; it is a filter threshold and does not perform permission or entity isolation. The retrieval library and the vector model need to be consistent, and this requirement does not extend to external systems.
Hypothetical paper exercise sample. The source text of a platform after-sales ticket reads: "Order A-2201; the consumer applied for a refund on 12 March on the grounds of a scratch on the product surface; return waybill YT-8842 showed delivery on 15 March; inspection photos show the outer packaging intact and a scratch on the body; refund approval status is pending review." The draft sentence to be judged reads: "This order has completed refund approval and the refund has been agreed."
Configuration and implementation checks
| Configuration or check item | Material on this page | Setting or check action |
|---|---|---|
| Chunk completeness | Refund request, inspection photo description | Check whether conditions, amounts, and status sit in the same chunk as the content they constrain |
| Multi-vector mapping | Return waybill, refund approval | One data group can map to several indexes; a hit on any one recalls it |
| Search mode | Waybill number, order number | Use full-text or hybrid search for exact fields |
| Minimum relevance | Semantic recall candidates | Hypothetical starting value 0.3 for this exercise, compared with 0.5 to observe the filtered candidate range |
| Reference cap | Referenced content | Controlled by tokens, not by top k |
| Post-update review | Approval status change | Check the actual training and index state; a successful upload does not mean retrieval has updated |
The minimum relevance value of 0.3 is a hypothetical starting point for this exercise. It is chosen to observe the recall range for natural-language refund-reason questions and to compare, against 0.5, how the number of candidates changes after filtering.
Three common errors
- Treating refund approval status "pending review" as a completed refund. The source text records only pending review, while the draft sentence states that approval is complete and the refund agreed. This takes stage evidence that is not supported as a settled conclusion.
- Treating a successful upload as updated retrieval. After a material changes, the actual training and index state need to be checked; a form submission or successful upload does not support the inference that retrieval results have changed.
- Treating minimum relevance as a permission or entity filter. The value is a filter threshold; it does not exclude unrelated businesses or unauthorized records, and retrieval itself does not constitute authorization.
How to verify the setup
- Input the hypothetical sample source text and the draft sentence "This order has completed refund approval and the refund has been agreed." Compare the approval status field in the source text with the wording of the draft sentence, and observe whether the draft sentence goes beyond the status the source text records. If the source text states only pending review, the draft sentence does not meet the condition.
- Input waybill number YT-8842 and order number A-2201 into full-text search. Compare whether the returned fragments contain the corresponding numbers and delivery status, and observe whether the numbers are recalled correctly. If a returned fragment lacks the number or the status, check the chunking and the index.
- Input "refund reason is a scratch on the product surface" into semantic search. Compare whether the returned candidates contain that refund request source text, and observe whether it is recalled at minimum relevance 0.3. If it is not recalled, record the actual observation and do not infer that the rule necessarily fails.
For an empty-result handoff, a paper input of [] can be used to check the downstream design, without claiming that a fictional rule search necessarily returns empty. Image retrieval requires an image input and model capability; reranking requires a model and must be enabled by configuration. Optional paths in the overall flow do not mean every request executes all of them.