Cross-border payment reviews: vector indexes for product questions

Review vector indexes for product questions in Cross-border payment reviews. Check sources, input boundaries, error handling and repeatable test evidence.

What the documents look like

Cross-border standalone-site payment risk work turns on card-network disputes and receiving accounts. The material set named in the brief is payment chargeback notices, fraudulent order lists, invoices and carrier proof of delivery. These records update daily and per order. A single order may carry an order number, a dispute reason code, an amount, an invoice number and a signed delivery date, each arriving from a different source. Shopify order records, Stripe or PayPal back-office views, carrier signatures and customer service email all contribute fragments.

Product documentation and selection questions in this setting ask whether a given payment tool or risk-control option fits the current business. Any answer has to rest on text that can be checked against the source documents. Record length varies widely: one line may hold only an order number, while a dispute explanation can run for a full paragraph. That spread is what determines how indexing and chunking behave at this step.

Constraints at the vector indexes step

A vector model converts text into an array of numbers, and a smaller distance between two arrays means greater similarity. The documented factors affecting vector search accuracy are the quality of the vector model, the quality of the data (length, completeness, diversity) and the precision of the retriever, which trades speed against accuracy.

FastGPT stores knowledge in a library, collections and data, and the smallest search unit is the library. Retrieval runs against the whole library; collections only group data and do not affect search results. PostgresSQL with the PG Vector extension acts as the vector retriever with an HNSW index, and PostgresSQL is used only for vector retrieval. MongoDB holds other data. In the dataset.datas table, the original data is stored together with an indexes field recording the vector IDs it maps to. That field is an array, so one data item can correspond to several vectors. During retrieval, vectors are recalled first, then their IDs are used to find the original content in MongoDB; items mapping to the same original data are merged and the highest vector score is kept.

Multiple vectors exist because length and semantic richness in one vector pull against each other. Mapping one data item to several vectors preserves both completeness and richness, and a hit on any one vector recalls the data. Beyond the default text index, image description indexes or image vector indexes can be generated when the model supports it.

Knowledge libraries associated for search must use the same vector model. The actual model and its input type are checked first, and libraries on different models are excluded from joint association. Semantic search depends on vector distance, full-text search depends on keyword hits, and hybrid search merges both through RRF. Image retrieval depends on whether an image description or image vector index was created at ingestion time; uploading an image at query time is not sufficient. A similarity score measures relevance and does not act as a permission or entity filter, and a retrieval result is not an authorization.

Configuration and implementation checks

The table below covers settings and implementation checks tied to this page's sample.

Configuration itemValue or state for this pageBasis and boundary for checking
Vector modelLibraries associated for search share one modelCheck the model identifier and input type first; exclude libraries on other models
Index contentEach chunk keeps a complete, single meaningCompleteness and focus are weighed against the sample; no length is preset
Index countOne data item can carry several indexesindexes is an array; check against what was actually ingested
Search modeIdentifier-type questions use full-text or hybridSemantic search matches precise identifiers weakly
Reference capMeasured in tokensNot top k; more stable when chunk lengths differ
Minimum relevanceA 0-1 threshold, effective only for semantic search or rerankingA filter threshold, not a final ordering rule

Three common errors

  1. Treating a similarity score as a permission or entity filter. Observable form: assuming that raising the minimum relevance excludes other merchants or unauthorized records. Executable check: input the source text of a chargeback notice belonging to another entity, compare whether that entity's identifier appears in the returned references, and observe whether it is still recalled.
  2. Treating an image uploaded at query time as an existing image index. Observable form: when image-to-image search returns nothing, adjusting only the search parameters. Executable check: inspect the ingestion record to see whether an image description or image vector index was generated for that image, compare the query-side input with the ingestion-side index state, and observe whether the two sides agree.
  3. Treating RRF as a switch that can be turned on. Observable form: looking for an enable setting for RRF in the configuration. Executable check: confirm whether hybrid search runs both semantic and full-text recall, compare whether both candidate sets enter the merge, and observe whether the final references come from more than one path.

How to verify the setup

The following is a hypothetical paper exercise used to validate this page's primary task. It does not represent a real record or an operation that was carried out.

Sample source text: "Order A-1042 was signed for on 5 March 2026, carrier proof of delivery number POD-7781. The cardholder initiated a chargeback on the same order on 12 March 2026, reason code 13.1, amount 268 US dollars. Invoice number INV-3310 for this order was issued on 6 March 2026."

Proposed sentence to be judged: "The chargeback dispute for order A-1042 is supported by proof of delivery and can be submitted for defense directly."

  • Verification one: input the source text above together with the proposed sentence, and compare whether the claim "can be submitted for defense directly" has a basis in the source text. The source text states only the signing and chargeback dates, the identifiers and the amount; it does not state whether a defense has been authorized or submitted. Observed result: the wording is not supported by the source text and remains to be confirmed.
  • Verification two: use the proposed sentence as a retrieval input and compare whether the returned references contain the three identifiers A-1042, POD-7781 and 13.1. Observed result: when all three identifiers appear together in the references, the retrieval can be confirmed to have hit that source text; if any identifier is missing, record it as a miss and do not infer a cause.
  • Verification three: input a query containing none of this sample's identifiers and compare the returned reference content. Observed result: when an empty array is returned, check downstream handling against the documented output design whose length may be 0; when a non-empty result is returned, check each referenced source text against the query one by one, without presuming that an unrelated query must return nothing.

After any change to the model or the index, compare referenced source text using the same set of questions. A pending review status does not indicate a lack of operating permission, and a retrieval hit does not indicate that a business action has been approved.