Dealer ordering events: vector indexes for multilingual work

Review vector indexes for multilingual work in Dealer ordering events. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

Dealer ordering events rely on ordering handbooks, order contracts, sample lists, and credit approvals. These materials update by quarter or year. Brand channel teams, regional dealers, and merchandise planning staff work across them, and the same document set often mixes Chinese and English contract clauses, model numbers, and sample specifications.

Two features of this material shape the vector index step. First, exact identifiers such as model numbers and proper nouns appear alongside natural-language clauses, so semantic retrieval and full-text retrieval serve different query types. Semantic retrieval can match a Chinese question to an English knowledge point; full-text retrieval suits model numbers and proper nouns. Second, image material such as sample photos may enter the same knowledge base, and whether an image can be retrieved depends on whether an image description or image vector index was built at ingestion time, not only on what the query sends.

Retrieval quality depends on vector model quality, data completeness, and query quality. These are the conditions this page addresses.

Constraints at the vector indexes step

In FastGPT, a knowledge base consists of libraries, collections, and data. The smallest search unit is the library; collections classify data and do not affect search results. Vector storage uses the PostgresSQL PG Vector plugin with an HNSW index. PostgresSQL holds vectors only, and MongoDB stores other data. The MongoDB dataset.datas table stores vector source data and an indexes field that records corresponding vector IDs as an array, so one data item can map to multiple vectors. If the model supports it, images can generate image description indexes or image vector indexes in addition to the default text index.

A knowledge base search node can select one or more knowledge bases that use the same vector model. The actual model and input type must be checked first. The overall retrieval path combines problem optimization, semantic retrieval, full-text retrieval, or hybrid retrieval, image description or image vector retrieval when the input contains images and the model supports it, RRF fusion, ReRank reordering, similarity filtering, and reference cap trimming. RRF is the fusion step for hybrid results; ReRank is a second-pass ordering. The minimum relevance value applies only under semantic retrieval or result reordering. The reference cap is measured in tokens.

Retrieval and similarity scores do not carry authorization or entity-isolation duties. A relevance threshold is a filter value, not a permission or category filter.

Configuration and implementation checks

The following table ties each item to this page's documents and the sample below. Values marked as hypothetical are starting points for this paper exercise, not official defaults.

Configuration or check itemValue or practice for this pageBasis and notes
Linked knowledge basesSelect only knowledge bases whose vector model identifiers matchThe node requires the same vector model; verify identifiers first and exclude non-matching ones
Indexes and source dataCheck the correspondence between the indexes array and the source data blockIn MongoDB dataset.datas, one data item can map to multiple vectors
Index content lengthHypothetical starting point for this exercise: focused short sentences, compared against a full-paragraph sample for recall coverageShorter, more precise index content trades away some retrieval range; weigh against the sample
Image indexCheck whether an image description or image vector was generated at ingestionWhether an image can be retrieved depends on the ingestion index, not only the query side
Search modeUse full-text or hybrid retrieval for model-number and part-number queriesFull-text retrieval suits exact queries; hybrid retrieval fuses results through RRF
Result reviewCompare cited originals using the same question setAfter model or index changes, review citations; do not promise outcomes from vector scores alone

A hypothetical paper exercise sample is provided for checking. The source material is an English ordering handbook excerpt: "Dealer order quantities are confirmed only after the credit approval is signed by the regional manager." A draft sentence to be checked is: "Dealer order quantities are confirmed after the regional manager signs the credit approval." The subjects are the dealer and the regional manager; the object is order quantity and credit approval; the state is pending review; the valid scope is limited to this handbook excerpt. No real customer or identifier is involved.

Three common errors

  1. Treating semantic retrieval or a similarity score as a permission or entity-isolation mechanism. Input: a credit approval document restricted to specific regional dealers. Comparison: the retrieval result versus the access scope. If a low relevance setting is treated as the basis for excluding unrelated businesses or unauthorized records, the configuration understanding is incorrect. Executable check: confirm that retrieval scope and authorization scope are managed by separate mechanisms, and record the actual observation.
  2. Linking knowledge bases that use different vector models. Input: two knowledge bases with non-matching vector model identifiers. Comparison: the library identifiers the node permits. If they are forced into a shared link and a recall gap or redundancy is inferred from that, the claim exceeds the documented behavior. Executable check: verify identifiers first, exclude non-matching ones, and do not run a cross-model retrieval comparison.
  3. Describing RRF or ReRank as an independent toggle switch. Input: hybrid retrieval parameter configuration. Comparison: the retrieval chain listed in the documentation. If RRF is described as a switch or a first-hit guarantee is promised, the description does not match the documentation. Executable check: review the actual settings for hybrid retrieval and result reordering, and record the observation.

How to verify the setup

  1. Use the hypothetical sample source text and draft sentence above. Input: the English handbook excerpt and the Chinese draft sentence. Comparison: whether the draft sentence matches the source on subject, object, and state. If the source states only that order quantities are confirmed after the credit approval is signed, and the draft sentence stays within that scope, the check condition is met. If the draft sentence adds an effective clause not present in the source, record it as unsupported.
  2. Use an empty-result continuation. Input: an explicit paper input of []. Comparison: whether the downstream design handles an array length of zero. If the citation output path completes without fabricating a rule that retrieval must return [], the condition is met.
  3. Use a model-number query. Input: a model string from the sample list. Comparison: whether the recalled content from full-text or hybrid retrieval contains that model string. If the cited content matches the model number, the condition is met. If only semantic retrieval was used and no match appeared, record it as pending verification and do not infer a model defect.

These checks test the named primary task: matching proposed copy against supplied source wording and its limits. They do not test identity certification, report analysis, or any other task. Missing evidence remains missing. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination.