What the documents look like
Platform refunds and returns arise order by order across the ordinary marketplace flow, and a given refund does not necessarily tie back to a promise made in one live-stream session. For product information and selection questions, the retrieval layer therefore works across four recurring record types: refund applications, return logistics documents, quality-inspection photographs, and refund approvals. These materials come from the platform after-sales console, customer-service chat, warehouse receiving, and payment refund records, and they refresh per order or per day.
Most of the material is text. Inspection photographs may carry a generated image description index or an image vector index, and whether a photograph can be retrieved depends on whether the corresponding index was created at ingestion time. Customer-service questions frequently contain pronouns and model numbers, so the quality of the search query directly affects what is recalled.
Constraints at the retrieval step
The knowledge-base search node can associate one or more knowledge bases that use the same vector model. Knowledge bases built on different vector models cannot be associated together; the practical step is to check each vector-model identifier and exclude those that do not match, rather than attempting a cross-model search to compare recall.
Search mode is compared, not assumed. Semantic search relies on vector distance and suits natural-language questions and semantically close content. Full-text search relies on keyword matches and suits identifiers, model numbers, proper nouns, and error codes. Hybrid search uses both and merges the paths through RRF. Re-ranking requires a ReRank model and must be enabled according to the configuration; it produces a 0–1 score that can be used for filtering.
The reference cap is expressed in tokens per search, not in a top-k item count. The minimum relevance value is a 0–1 threshold and takes effect only under semantic search or when result re-ranking is used. Question optimization performs coreference resolution and question expansion before retrieval and adds one model call. Reference content is output as an array whose length may be zero, and the downstream chain still runs on an empty result.
Retrieval does not perform authorization. A similarity score is not a category, entity, or permission filter, and it does not exclude unrelated businesses or unauthorized records. Business verification, approval, database writes, and external synchronization require their own downstream implementation.
Hypothetical paper test case: the source material reads, "Refund application R-2024-0517, order item is a filter cartridge for a given water-purifier model; the return logistics document shows warehouse receipt on 20 May 2024; the inspection photograph records outer packaging damage with the cartridge body unopened. The refund approval field status is pending review." The draft sentence to be judged is, "This order has completed its refund, and responsibility lies with the consumer." This sample is used to check whether the retrieved content and the draft sentence agree.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this feature and the product-information and selection-question task, using the sample above. The numeric values are hypothetical starting points for this paper exercise, chosen so that a second value can be compared against them.
| Setting or check | Hypothetical starting point and reason | Comparison and observation |
|---|---|---|
| Associated knowledge bases | Select one knowledge base with a matching vector model, containing refund applications and inspection material | Check each knowledge base vector-model identifier and exclude non-matching ones |
| Search mode | Test semantic search and full-text search separately first | Use the same question and compare the recalled content of the two paths |
| Reference cap | Hypothetical starting point 2000 tokens, to cover a longer inspection description | Compare with 1000 tokens and observe whether content is truncated |
| Minimum relevance | Hypothetical starting point 0.4, after labelling relevant and irrelevant samples | Compare with 0.6 and observe whether irrelevant fragments decrease |
| Question optimization | Enable for follow-up questions containing "this order" | Compare the original question and the optimized question and check whether the subject was altered |
| Result re-ranking | Enable when a ReRank model is available and observe the score | Compare ordering and filtering before and after re-ranking |
Three common errors
- Associating knowledge bases that use different vector models. The input is two knowledge bases with different vector-model identifiers; the comparison is whether the identifiers match; the observable result is that they cannot be associated together, so the non-matching base is excluded and the actual observation is recorded.
- Treating minimum relevance as a permission or entity filter. The input is a similarity score together with an unauthorized record; the comparison is whether the setting changes the record scope; the observable result is that the record scope is unchanged, and unauthorized records still require downstream authorization control.
- Treating a retrieval hit or an empty result as a business conclusion. The input is the sample source text and the draft sentence "refund completed"; the comparison is the approval status field "pending review" against "completed"; the observable result is that the draft sentence is not supported, because pending review does not constitute a completed refund.
How to verify the setup
- Verification one: input the sample source text with the question "What is the refund status of this order"; compare whether the recalled content includes the "pending review" field; the observable result is that the reference content contains that field and does not contain the wording "refund completed". This is the expectation, not an actual test.
- Verification two: input the draft sentence "responsibility lies with the consumer"; compare whether the source text states a responsibility-determination field; the observable result is that the source text does not state one, so the sentence remains to be verified and must not be recorded as a denial or a conflict.
- Verification three: input an empty reference array []; compare whether the downstream design accepts an output of length zero; the observable result is that the chain runs through and the downstream does not treat the empty result as a business rejection. This is the expectation, not an actual test.
At handover, distinguish between behavior the node already has, fields that are actually configurable, manual checking actions, and business actions that require a separate system implementation. Retrieval, forms, and similarity scores do not constitute authorization for refund approval, responsibility determination, or external synchronization.