What the documents look like
Marketplace refund and return handling occurs order by order. It does not depend on a single livestream commitment, which distinguishes it from after-sales work that is concentrated around one broadcast. The materials used in the inventory procurement and supplier records task include refund applications, return logistics notes, quality inspection photos, and refund approvals. Each material has its own subject, object, stage, and valid scope. A refund application states the order and item. A return logistics note states that the returned parcel is in transit or has been signed for. A quality inspection photo reflects the condition of the item. A refund approval records an amount and an approval status. The update frequency is per order and daily. That frequency affects the correspondence between indexed chunks and source text. It does not imply batch synchronization, full synchronization, real-time processing, or transaction-triggered mechanisms.
Because these materials move through different stages, the chunking step has to keep stages separate. A refund application that is still pending review, a parcel that has been signed for, and a photo showing a scratch are three different facts. They can belong to the same order and the same item, and they still do not replace one another. The chunking step preserves that separation so that later retrieval returns the material that actually answers the question, rather than a neighboring fact from the same order.
Constraints at the document chunking step
A FastGPT knowledge base consists of libraries, collections, and data. The smallest search unit is the library. Collections classify data and do not affect search results. One group of data can map to multiple vectors, and when vectors resolve to the same source data, the highest score is taken. During chunking, each group of data should hold a complete and single meaning. Conditions, explanations, and the content they constrain should not be split apart.
Source data and retrieval indexes are distinct. The dataset.datas table in MongoDB stores source data information, and its indexes field records the corresponding vector IDs. During retrieval, vectors are recalled first, then the vector IDs are used to find source data in MongoDB. When the same source data is hit, the results are merged. Full-text retrieval uses MongoDB $text with jieba tokenization on vector stores such as PG, and uses BM25 on Milvus. Hybrid retrieval merges multiple result paths through RRF. ReRank performs a second ordering of candidate text and returns a score between 0 and 1. The citation limit is controlled by tokens. The minimum relevance value applies only during semantic retrieval or when result reranking is used. Image retrieval requires a corresponding index to be built at ingestion time and requires the relevant model capability. It is not a path that runs on every request.
Hypothetical paper exercise sample: the source text reads "Refund application A-001, order 2024-0301, item is a folding table, application date March 5, application status is pending review. Return logistics note L-778, same order, signed for on March 8. Quality inspection photo P-12, same order, shows a scratch on the tabletop." The proposed handover request reads "Please confirm, based on the materials above, whether the refund application for this order has been approved, and arrange the refund." In this request, the pending review status, the signed-for parcel, and the inspection photo are separate facts. The authorization boundary is to check materials only, not to execute a refund.
Configuration and implementation checks
| Configuration or check item | Purpose on this page | Basis and explanation |
|---|---|---|
| Library and collection division | Organize inventory procurement and supplier records by library, with collections used for classification | The documentation states the smallest search unit is the library, and collections do not affect search results |
| Chunk completeness check | Check that conditions and the content they constrain in refund applications, logistics notes, and inspection photos are not split apart | The documentation advises keeping each group of data complete with a single meaning |
| Source data and index distinction | Check the correspondence between the indexes field in dataset.datas and vector IDs | The documentation states one group of data can map to multiple vectors |
| Retrieval mode selection | Use full-text or hybrid retrieval for identifier queries, semantic retrieval for natural language queries | The documentation describes the applicable scenarios for each mode |
| Citation limit and minimum relevance | Control citation volume by tokens, filter by a threshold between 0 and 1 | The documentation states minimum relevance applies only during semantic retrieval or reranking |
| Post-update training status check | After material changes, check the actual training and index status | The documentation states a successful upload does not mean retrieval has been updated |
Three common errors
- Treating a pending review status as approved. In the sample, refund application A-001 has an application status of pending review, and the proposed handover request asks for confirmation of whether it has been approved. The error is equating pending review with approval, or treating a signed-for parcel as a completed refund approval. The check compares the value of the same field for the same order. Pending review and approved are mutually exclusive values. The sample contains no approval record, so the claim is unsupported.
- Treating a retrieval result as authorization to execute. Finding a refund application or an approval record does not mean authorization to execute a refund has been obtained. The authorization boundary in the sample is to check materials only. A refund is a business action that requires a separate system implementation. Retrieval and forms do not carry authorization.
- Associating libraries that use different vector models. The documentation states that libraries using different vector models cannot be associated together. The check is to verify identifiers first and exclude those that do not match, then record what is actually observed. It does not infer missed recalls or redundant results as runtime outcomes.
How to verify the setup
- Input the sample source text and the proposed handover request, and compare the application status field and the approval record of refund application A-001. The expected observation is that when the sample contains no approval record, the result is judged unsupported, and no approved conclusion is output.
- Input the signed-for status of return logistics note L-778 and the scratch description in quality inspection photo P-12, and compare whether both point to the same order and the same item. The expected observation is that under the same order, a signed-for parcel and a scratch found in inspection are separate facts and cannot substitute for each other in determining refund responsibility.
- Input a paper-based input that carries an empty result, and check whether the downstream design distinguishes an empty result from an unsupported claim. The expected observation is that an empty result is handled as missing evidence. The check does not claim that a fabricated rule retrieval always returns an empty array, and does not interpret an empty result as a denial.
All three verification items use the sample source text and request given above, and each states the input, the comparison object, and the condition for satisfaction. They do not claim to have been tested. Semantic recall and relevance do not carry permission or entity isolation functions. The same-vector-model requirement for retrieval libraries does not extend to external systems.