What the documents look like
Platform refunds and returns arise order by order, which separates this work from after-sales handling tied to a single livestream commitment. A refund request may carry no link to any livestream promise at all. The material comes from the platform after-sales backend, customer service chat, WMS receiving, and payment refund records. Daily documents include refund applications, return shipping labels, quality inspection photos, and refund approvals. E-commerce agents, after-sales specialists, and warehouse inspectors each produce part of this material, and it updates per order and per day.
For retrieval, this means the same order can sit at different processing stages in different systems. A refund application may exist while the return parcel is still in transit, and an inspection photo may arrive before any approval decision. The retrieval step therefore has to work with records whose status fields are scattered and whose completeness varies from order to order.
Hypothetical walkthrough sample: a platform after-sales knowledge base holds one refund application whose source text reads "Order A submitted a refund application on 10 March; the return shipping label shows delivery signed on 12 March; the quality inspection photo notes outer packaging damage; the refund approval status is pending review." A separate customer service chat record reads "The consumer asked about refund progress; the agent replied that it has been submitted for approval." The draft sentence to be checked is "This order's refund has completed approval and been refunded." Checking uses the refund application and the refund approval as the two source materials, comparing the approval status field. The source states pending review, so the draft sentence's claim of completed approval and refund is not supported.
Constraints at the retrieval step
The knowledge base search node can associate one or more knowledge bases that use the same vector model. Bases using different vector models cannot be associated together; the model identifier must be checked first and non-matching bases excluded. Retrieval output is an array of references whose length can be zero, and the output path still runs even when nothing is retrieved.
Semantic search computes similarity from vector distance. Full-text search depends on keyword hits. Hybrid search merges the two paths through RRF. RRF is a fusion process for mixed results and is not described as a standalone switch. The minimum relevance value is a filter threshold that takes effect only under semantic search or when result reranking is used; it does not perform permission or entity isolation. The reference limit is measured in tokens and controls how much content each search may cite. When question optimization is enabled by configuration, it performs coreference resolution and question expansion and adds one model call before retrieval.
Reranking requires a rerank model and must be enabled by configuration; image retrieval requires an actual image input and the corresponding model capability. The optional paths in the overall retrieval flow are not all executed on every request. When full-text search runs on Milvus 2.5.16 or above, it uses BM25 with vectors and full text stored in the single modeldata_v2 table; other vector stores route full-text search through MongoDB $text with jieba tokenization.
Configuration and implementation checks
| Configuration item | Hypothetical starting value for this exercise | Reason and comparison method |
|---|---|---|
| Associated knowledge bases | One refund after-sales knowledge base using a single vector model | Compare vector model identifiers across bases and exclude any that do not match |
| Search mode | Start with hybrid search | Compare recalled content for the same question against semantic search and full-text search separately |
| Reference limit | 3000 tokens | Compare against 1500 and 5000 tokens and observe whether cited content stays complete |
| Minimum relevance | 0.4 | Compare against 0.2 and 0.6 and observe whether unrelated fragments are filtered |
| Question optimization | Enabled first | Compare the same follow-up question with optimization off and check whether the subject is altered |
| Result reranking | Enabled first | Compare candidate ordering with reranking off and observe changes in relevance scores |
These values are starting points for this hypothetical exercise, used to compare against adjacent values; they are not official defaults. The table lists only settings or implementation checks relevant to the retrieval task on this page.
Three common errors
- Treating a pending-review status as completed approval. The input is the refund approval status field; compare the status stated in the draft sentence against the source value and observe whether the same field carries mutually exclusive values. Pending review does not demonstrate that approval was completed, and it does not demonstrate that operating permission is absent.
- Treating a retrieval similarity score as a permission filter. The input is the minimum relevance setting; compare the returned references against the intended retrieval scope and observe whether unrelated business records are excluded by the similarity setting. A similarity setting does not perform entity isolation.
- Associating knowledge bases that use different vector models. The input is each base's vector model identifier; compare the identifiers and observe whether any do not match. Bases across different models cannot be associated together; check identifiers first and exclude non-matching bases rather than running a cross-model search to compare missed recalls.
How to verify the setup
- Input the refund application and refund approval from the hypothetical sample, and compare the approval status field value against the status stated in the draft sentence. The source states pending review, so the draft sentence's claim of completed approval and refund is not supported; this outcome satisfies the condition.
- Input the same refund question and run semantic search and full-text search separately, then compare the references returned by each path. Observe whether full-text search hits exact fields such as the order number and whether semantic search recalls semantically similar content. Record each path's references and the approval status of the same order without assuming the two paths must differ; record a reference gap when nothing is hit.
- Input one explicit question and one follow-up containing a reference, run each with question optimization enabled and disabled, and compare the subject of the optimized question against the original. Observe whether optimization completes the reference without changing the subject; a consistent subject satisfies the condition. For empty-result handling, use an explicit paper input of an empty array to check the downstream design, without asserting that a fictional rule search must return an empty array.