What the documents look like
Cross-border standalone-site payment risk work centres on card-network disputes and receiving accounts. The daily material set includes payment chargeback notices, fraudulent-order lists, invoices, and delivery signature proof. These materials arrive from separate places: Stripe or PayPal back ends, Shopify orders, carrier signature records, and customer-service email. A single document commonly carries an order number, an amount, a date, a party name, and a status description at the same time. Parsing and chunking therefore need to gather the fields of one transaction into one group of original data.
Material updates run daily and per order. That frequency means a chunk result should correspond to a single transaction. A successful upload only indicates that a file entered the system; training and index status require separate confirmation.
Two further characteristics shape this task. The material is dispute-oriented rather than fulfilment-oriented, so the fields that matter are chargeback reason, disputed amount, invoice reference, and signature date rather than parcel movement. The material is also multi-source, so the same order number may appear in a chargeback notice, an invoice, and a signature record with different surrounding wording. Chunking that keeps each source document intact but does not let a reader trace which transaction a block belongs to will make later comparison unreliable.
Constraints at the document chunking step
FastGPT separates the knowledge base into library, collection, and data. Search operates at the library level; collections only classify and manage data and do not affect search results. One group of data can map to multiple vectors, and the indexes field records an array of vector IDs. During segmentation, a condition, its explanation, and the content it constrains should stay in the same group. Splitting a chargeback reason away from the order amount, or a signature date away from the order number it belongs to, breaks the unit that comparison depends on.
The following is a hypothetical paper exercise used to describe the checking method on this page. It does not represent any real customer or any actual test.
Hypothetical paper exercise
Source text available for comparison (excerpt from a payment chargeback notice): "Order number SO-2041. The cardholder raised a chargeback on 12 March 2025, with the reason given as goods not received. This order corresponds to invoice INV-2041, amount 480 USD. The delivery signature record shows receipt by the recipient in person on 5 March 2025."
Draft sentence to be assessed: "Order SO-2041 has a chargeback reason of goods not received, and this order has no delivery signature record."
Comparison required for the judgment: the draft sentence states "no delivery signature record," while the source text states receipt by the recipient in person on 5 March 2025. The two take mutually exclusive values on the same order and the same field. The draft sentence conflicts with the source text.
Configuration and implementation checks
| Configuration item | Relevant value or check on this page | Correspondence with the exercise |
|---|---|---|
| Search mode | Semantic search, full-text search, hybrid search | Order number SO-2041 is an exact identifier, so full-text or hybrid search fits |
| Reference cap | Maximum tokens referenced per search | Hypothetical starting value for this exercise is 2000 tokens; the reason is that the sample source text is short and completeness of hits is compared when adjacent order material is referenced together |
| Minimum relevance | A 0–1 value, effective only in semantic search or with result reranking | Hypothetical starting value for this exercise is 0.4, compared against the number of recalled entries when no filter is set |
| Result reranking | Requires a ReRank model, enabled according to settings | Reranks text results a second time when candidates are numerous |
| Question optimisation | Coreference removal and question expansion before retrieval | A single clear question can leave it off; multi-turn follow-ups are compared for effect |
| Segmentation completeness check | Manual verification action | Checks whether the chargeback reason and the signature status remain in the same data block |
Three common errors
- Treating a successful upload as an updated index. Input is a changed chargeback notice; the comparison object is the actual training and index status; the observable result is whether retrieval hits the new content. Upload success and retrieval update are two separate stages.
- Using a similarity threshold in place of a permission judgment. Input is the minimum relevance setting; the comparison object is records with different authorisation scopes; the observable result is whether records outside the permitted scope are still recalled. Relevance is a filter threshold and does not carry entity or permission isolation.
- Writing the RRF fusion of hybrid search as a switch that can be turned on. Input is the search-mode selection; the comparison object is the recall paths listed in the documentation; the observable result is whether multi-path results are merged and ranked. RRF is a fusion process.
How to verify the setup
- Segmentation completeness verification. Input is the source text of the hypothetical paper exercise; the comparison object is the data-block boundaries after parsing; the observable result is whether the chargeback reason, the invoice amount, and the signature date fall inside the same group of original data. If a condition and the content it constrains are separated, segmentation needs adjustment.
- Draft-sentence comparison verification. Input is the draft sentence to be assessed, "Order SO-2041 has a chargeback reason of goods not received, and this order has no delivery signature record"; the comparison object is the signature record in the source text; the observable result is that the draft sentence and the source text take mutually exclusive values on the same order and the same field, and the draft sentence is judged to conflict.
- Retrieval coverage verification. Input is the term "chargeback," the identifier "SO-2041," and a natural-language question, taken separately; the comparison object is the returned content; the observable result is whether the identifier query hits the material for that order. If the identifier query returns nothing, record it as a miss and check the index status, without inferring a system error cause.
Authorisation boundary note: retrieval and form collection of values do not constitute authorised execution. A pending-review state does not indicate a lack of operating permission; signing, reaching cooperation, and contract effectiveness are three distinct facts. Business actions such as chargeback handling, refunds, and account operations require their corresponding downstream system implementation and are not completed at the retrieval step.