What the documents look like
Payment risk control in this category centres on card-scheme disputes and receiving accounts. The working materials are chargeback notices, fraud order lists, invoices and proof of delivery. These differ from parcel-status records, because the question under review is whether a disputed amount can be evidenced, not where a shipment currently sits. Typical roles include independent-store merchants, risk specialists and finance settlement staff. The stated consequences of error are chargeback losses, frozen accounts and interrupted ad campaigns. Materials update daily and per order. Retrieval itself only needs to match the actual content of a document; no synchronisation mechanism is described here.
For store service and internal training, frontline staff often answer handover questions from these materials. A retrieved passage can be mistaken for an authorised action. Retrieval and similarity scores do not perform permission or entity isolation, and a search result does not constitute authorisation. This page covers one task only: knowledge-base retrieval and recall for cross-border independent-store payment risk control, in store service and internal training. It does not decide whether a chargeback is closed, whether funds may be released, or whether a form submission has been approved.
Constraints at the retrieval step
The knowledge-base search node can link one or more knowledge bases that use the same vector model. Knowledge bases with different vector models cannot be linked together. Check the model identifier first and exclude any knowledge base that does not match; do not run a cross-model retrieval to compare missed recalls. Reference content is output as an array and its length may be zero, so the downstream chain still runs when nothing is found.
The minimum relevance value is a 0–1 number and takes effect only under semantic retrieval or when result reranking is used. It is a filter threshold, not a final ordering rule. The reference limit is expressed in tokens per search, not as a top-k item count. Question optimisation performs coreference resolution and question expansion before retrieval and adds one model call. RRF is the fusion step that combines multiple recall paths; it is not a switch. Reranking requires a rerank model and must be enabled in the settings. Image retrieval requires image input and matching model capability, and it depends on whether an image index was built at ingestion time.
Hypothetical drill sample, clearly labelled as constructed for this page and not drawn from any real record:
Source text for comparison: "Chargeback notice DN-2031 states: the cardholder raised a dispute on 5 March 2026 regarding order A-77; the merchant has not yet submitted proof of delivery; the current status is awaiting evidence."
Draft sentence to be assessed: "This order's chargeback is closed and no further materials are needed."
The two statements share the same subject, the same period and the same status field. The source gives the status as awaiting evidence, and "closed" is a mutually exclusive value in that same field. The draft sentence is therefore not supported by the source text. No authorisation, approval or closure can be inferred from retrieval of the notice.
Configuration and implementation checks
| Configuration item | Value or check for this page | Basis and explanation |
|---|---|---|
| Linked knowledge bases | Select only bases whose vector model identifier matches | Knowledge bases must share the same vector model to be linked together |
| Search mode | Compare semantic, full-text and hybrid retrieval against the drill question | No single mode is assumed to suit every material type |
| Reference limit | Starting value for this hypothetical trial: 2000 tokens, compared with 4000 tokens for content completeness | The starting value is a hypothetical trial value, not an official default |
| Minimum relevance | Label relevant and irrelevant samples first, then adjust the threshold | Takes effect only under semantic retrieval or reranking |
| Question optimisation | Compare the original question with the optimised question and check whether the subject was altered | Used for coreference resolution and question expansion |
| Result reranking | Used when a rerank model is available and enabled in the settings | Enabling depends on the model and the setting |
Three common errors
- Treating a retrieval hit as authorisation. Input the drill source text above and the draft sentence. Compare the returned passage with the draft claim. Retrieving the chargeback notice does not mean the dispute is closed; the awaiting-evidence status still requires verification. A satisfied check records the gap rather than asserting closure.
- Linking knowledge bases with different vector models. Input two knowledge bases with different vector model identifiers. Compare the identifiers. The correct action is to exclude the non-matching base and record the actual observation. Do not infer missed recalls, redundant returns or unpredictable behaviour from a cross-model link, because the documented rule is only that such bases cannot be linked together.
- Treating an empty reference array as a rule-based empty result. Input a paper-level empty array [] and compare whether the downstream design accepts it. Do not claim that a fictional rule-based search necessarily returns []. The documented fact is only that the output array may have length zero and the chain still runs.
How to verify the setup
- Input the drill source text and the draft sentence. Compare the status field in the source with the value in the draft sentence. When the two values are mutually exclusive in the same field, the draft sentence is not supported. The check is satisfied when the gap is explicitly recorded and no closure is asserted.
- Input two knowledge bases with different vector model identifiers. Compare the identifiers. The check is satisfied when the non-matching base is excluded and the observation is recorded, without running a cross-model retrieval to compare missed recalls.
- Input a paper-level empty array []. Compare whether the downstream node accepts it. The check is satisfied when the downstream continues with the empty array and any unsupported information remains missing rather than being filled in.
Across all three checks, observation and failure branches are recorded without guaranteeing a first hit, full recall or an empty result for unrelated queries. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination. Where the source does not state a field, the value remains unknown.