What the documents look like
Payment risk control for cross-border standalone stores operates around card network disputes and receiving accounts. The materials handled here are chargeback notices, fraudulent order lists, invoices and carrier proof of delivery. These materials come from different sources: chargeback notices and fraud lists from Stripe or PayPal back offices, order information from Shopify, delivery evidence from carriers, and communication records scattered across customer service email. For a single transaction, the subject, object, amount, time and status fields across these four material types must be aligned item by item. The retrieval step first recalls candidate materials, and a human then performs the comparison.
Materials update daily and per order. The retrieval configuration itself does not change because of update frequency, and this page does not derive batch synchronization, real-time triggering or full-refresh mechanisms from that frequency.
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 identifier must be checked first and non-conforming bases excluded. Retrieval searches the entire base; collections serve only to classify and manage data and are unrelated to search effectiveness. Quoted content is output as an array, and its length can be 0, meaning that even when no content is found, the output chain still runs through.
Semantic retrieval depends on vector distance, full-text retrieval depends on keyword hits, hybrid retrieval merges the two paths through RRF, and reranking performs a second ordering of candidate text and produces a 0-1 score. The minimum relevance value takes effect only under semantic retrieval or when result reranking is used; it is a filtering threshold and does not perform entity isolation or permission filtering. Retrieval results do not constitute authorization. Whether a material can be used for a given operation depends on the status and authorization boundary stated in the material itself.
Hypothetical paper exercise sample: the knowledge base holds an invoice original whose content is "Invoice number INV-2024-0731, issuer is a standalone store merchant, buyer is an overseas consumer, goods are 200 units of wireless earphones, invoice date 31 July 2024, payment status field is empty." A chargeback notice original states "Dispute number CB-2024-0812, transaction date 2 August 2024, dispute amount 4,800 US dollars, reason code 13.1, handling status is pending evidence submission." The draft sentence to be judged is "INV-2024-0731 has proven that this transaction was paid in full and can be used directly for evidence submission in CB-2024-0812." The comparison requires the same subject, the same period and the same field. The invoice payment status field is empty, which counts as not stated, so the draft sentence's claim of proven payment is unsupported. The chargeback notice handling status is pending evidence submission, which counts as pending review and does not indicate that evidence has been submitted or approved.
Configuration and implementation checks
| Configuration item | Assumed starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Associated knowledge bases | Associate only the base holding the invoice and the chargeback notice | Both bases use the same vector model; check identifiers before associating. A base using a different vector model is not associated together with them |
| Search mode | First take candidates by semantic retrieval, then take candidates by full-text retrieval | Run the same batch of test questions through each path and compare whether the two candidate sets cover the invoice number and the dispute number |
| Reference limit | For this exercise, set a starting value covering one invoice plus one chargeback notice | The unit is tokens; test with materials of different lengths to see whether content stays complete, then adjust |
| Minimum relevance | First label relevant and irrelevant samples, then tune the threshold against those samples | This value takes effect only under semantic retrieval or result reranking; compare candidates before and after filtering |
| Question optimization | Enable for follow-up questions containing references; disable for questions that are already explicit | Compare the original question with the optimized question and check whether the subject was altered incorrectly |
| Result reranking | Use when a rerank model is available and enabled per the setting | Compare candidate order and the 0-1 score before and after reranking, and observe the filtering effect against the score |
Three common errors
- Treating a retrieval hit as an authorization basis. The input is the draft sentence "INV-2024-0731 has proven that this transaction was paid in full." The comparison object is the invoice original's payment status field, which is empty and therefore not stated. A retrieval hit on that invoice does not mean the payment fact holds, nor that the invoice can be used for evidence submission. Executable check: compare the draft sentence with the original word by word, and record any field not stated in the original as unsupported.
- Reading a pending-review status as completed. The input is the chargeback notice original's handling status "pending evidence submission." The comparison object is completed-state values such as "submitted" or "approved." Pending evidence submission counts as pending review and does not indicate that evidence has been submitted or approved. Executable check: list all values of that field and confirm that the value used in the draft sentence matches the original.
- Associating bases that use different vector models together. The input is two knowledge base identifiers. The comparison object is each base's vector model identifier. When the identifiers differ, exclude that base and do not run cross-model retrieval to compare missed recalls. Executable check: record the vector model identifiers of both bases; if they differ, associate only the conforming one and record the actual observation.
How to verify the setup
- Use the hypothetical sample's invoice original and the draft sentence as input. Compare the draft sentence's claim of proven full payment with the empty value in the original's payment status field. The observed result is that the field is not stated, so the claim is judged unsupported and the evidence gap must be retained. If retrieval does not return that invoice, record an empty result and check the downstream design against the chain whose output length is 0.
- Use the hypothetical sample's chargeback notice original and the phrase "can be used directly for evidence submission" as input. Compare the original's handling status "pending evidence submission" with completed-state values. The observed result is that the status counts as pending review and does not constitute submitted or approved evidence. If the draft sentence is changed to say "submitted," it then conflicts with the original value and is judged contradictory.
- Use two knowledge base identifiers as input. Compare their respective vector model identifiers. The observed result is that when the identifiers match, the bases can be associated together; when they differ, exclude that base and record the actual observation, without inferring the runtime result of a cross-model association.