What the documents look like
Ordinary platform refunds and returns occur continuously per order and are not necessarily tied to a single livestream commitment. For inventory procurement and supplier records, this means retrieval operates over materials that accumulate order by order from several sources: the platform after-sales backend, customer service chat, WMS receiving, and payment refund records. The documents handled day to day include refund applications, return logistics notes, quality inspection photos, and refund approvals. These materials are produced by customer service agents, after-sales specialists, and warehouse inspectors, so the procurement batch, supplier name, inspection conclusion, and refund amount for one return may sit in different documents. The retrieval step recalls material relevant to the current question for human comparison; the recall result itself does not constitute a liability determination or a refund authorization.
Because refunds arrive per order, the retrieval step faces a mix of short and long chunks. A refund application may be brief, while a quality inspection conclusion plus approval status may be a longer passage. The reference limit is measured in tokens rather than a fixed item count for this reason, and the choice of search mode should follow the question type rather than a single default for all supplier material.
Constraints at the retrieval step
When linking knowledge bases, only knowledge bases that use the same vector model can be selected. The knowledge base search node can link one or more knowledge bases, and bases with different vector models cannot be linked together. In practice, check the vector model identifier first, exclude any base that does not match, and record what was observed; do not run a cross-model search to compare missed recalls. Reference content is output as an array and its length can be 0. When nothing is retrieved, that output path still completes, so an empty result can feed downstream design, but this does not establish that any particular virtual rule will return an empty array.
Search mode needs to be compared across semantic search, full-text search, and hybrid search according to the test question, without assuming one mode suits all material. Hybrid search merges multiple result paths through RRF; RRF is a fusion process and should not be described as a standalone switch. The minimum relevance value takes effect only in semantic search or when result reranking is used. It is a filter threshold, not a final ordering rule, and it does not perform permission or entity isolation; a similarity setting cannot exclude unrelated businesses or unauthorized records, and retrieval is not authorization. The reference limit is measured in tokens; test whether content stays complete using actual material of different lengths before adjusting it. Question optimization performs coreference resolution and question expansion, so compare the original question with the optimized question and check whether the subject was altered. Image retrieval requires corresponding image input and model capability, and reranking requires a model and must be enabled by configuration. The optional paths shown in the documented flow diagram do not mean every request executes all of them.
Hypothetical paper exercise sample: one passage in a supplier record base reads, "Supplier A, March 2026 batch return, inspection conclusion is outer packaging damage, liability attribution pending confirmation by the after-sales specialist, refund approval status pending review." Another passage reads, "Supplier A, March 2026 batch return, inspection conclusion is outer packaging damage, refund approval status approved." The draft sentence to be assessed is, "Supplier A's March 2026 batch return has passed refund approval, and liability attribution is confirmed." This draft sentence has a mutually exclusive value against the first passage on the refund approval status field, and against the second passage it lacks any recorded liability attribution, so it is unsupported or pending verification.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Linked knowledge bases | Include only inventory procurement and supplier record bases whose vector model identifier matches | Check identifiers and exclude non-matching bases; do not run cross-model retrieval |
| Search mode | For questions containing batch numbers or supplier names, compare full-text search and hybrid search | Compare hit situations per test question; do not assume a single mode |
| Reference limit | A provisional token value, used to cover one complete inspection conclusion plus approval status | Test content completeness with actual material of different lengths, then compare with adjacent values |
| Minimum relevance | A provisional value between 0 and 1, after labeling relevant and irrelevant samples | Takes effect only in semantic search or reranking; adjust by sample filtering behavior |
| Question optimization | For multi-turn follow-ups containing references, compare the question before and after optimization | Check whether the subject was altered; observe short-question cases separately |
| Result reranking | When candidates are numerous, compare ordering before and after enabling | Reranking requires a model and must be enabled by configuration; the score is used for filtering |
The values above are hypothetical starting points for this exercise. They do not come from official default values and do not represent actual testing.
Three common errors
- Treating retrieval recall as authorization. Input a refund application that is pending review, compare the retrieval result with the refund approval status field, and conclude that the refund has been approved because retrieval hit the application. This is an error; pending review does not demonstrate approval, and it does not demonstrate a lack of operating permission.
- Linking knowledge bases with different vector models. Input two bases with different vector model identifiers, compare the identifiers, and still link them together while inferring missed recalls or redundancy. This is an error; the correct action is to check identifiers, exclude non-matching bases, and record actual observations.
- Treating minimum relevance as a permission filter. Input a record that is semantically close to the question but belongs to another supplier, compare the filter threshold with that record's permission ownership, and conclude that the record is accessible because its score is high. This is an error; a relevance score does not perform entity or permission isolation.
How to verify the setup
- Input the first passage of the hypothetical sample and the draft sentence, and compare the refund approval status field. The expected observation is that the two values are mutually exclusive on that field, so the draft sentence is unsupported there; if the draft sentence is judged as approved, the condition is not met.
- Input the second passage of the hypothetical sample and the draft sentence, and compare the liability attribution field. The expected observation is that the passage records no liability attribution conclusion, so that part of the draft sentence is pending verification; if the draft sentence claims liability is confirmed, the condition is not met.
- Input a reference content array [] explicitly labeled as paper input, and compare how the downstream design handles that empty result. The expected observation is that the path still completes and no assertion is made that a particular virtual rule necessarily returns an empty array; if the empty result is taken as retrieval failure or as proof that the business action did not occur, the condition is not met.
This page addresses only marketplace refund and return handling for inventory procurement and supplier records at the knowledge base retrieval and recall step. Whether materials, operations, or requests are in a given authorization state during an operational handover cannot be established by retrieval or by a form.