Dealer ordering events: document chunking for multilingual work

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

What the documents look like

Ordering events serve offline dealer reservations. They do not directly manage platform storefronts. The working materials are ordering handbooks, ordering contracts, sample lists, and credit approvals, and they are refreshed by quarter or by year.

In a cross-border setting, one ordering handbook commonly exists in several language versions, including Chinese and English. Dealers ask questions in different languages, so retrieval has to reach the same passage of source text across languages. Structurally, contract clauses, sample numbers, and credit terms are often written continuously with explanatory prose. When chunking separates a condition from the content it governs, the recalled fragment loses the context a reader needs in order to judge it.

These characteristics set the scope of this page: implementation conditions, document differences, and checking steps for document parsing and chunking only. Retrieval is a separate step from authorization. A collected form value does not mean business verification, approval, a database write, or external synchronization has been completed. A pending review does not show that an operating permission is absent, and signing, reaching cooperation, and contract effectiveness are three distinct facts.

Constraints at the document chunking step

In FastGPT, a knowledge base consists of libraries, collections, and data. The smallest search unit is the library; a search runs across the whole library, while collections only classify and manage data and do not affect search results. Vectors are stored in a PostgresSQL vector field with an HNSW index. The MongoDB dataset.datas table stores the original data and includes an indexes field recording vector IDs, so one group of data can map to multiple vectors. Retrieval first recalls vectors, then uses the vector IDs to find the original data in MongoDB. Entries that correspond to the same group of original data are merged, and the vector score takes the highest score. Multi-vector mapping balances content length against semantic richness, and one chunk can carry several index groups. Cross-language hits depend on semantic retrieval, while exact queries for numbers and models fit full-text or hybrid retrieval better. Semantic retrieval and the minimum relevance value affect recall and filtering only; they do not perform permission or entity isolation. Libraries built on different vector models cannot be associated together, so identifiers are checked first and non-matching items are excluded.

Hypothetical paper exercise sample: a brand channel department intends to check the chunking of one ordering handbook. The source text provided for checking reads: "This section applies to the 2025 autumn ordering event. A dealer may submit order quantities only after credit approval has passed. Numbers in the sample list follow the English version." A draft sentence to be judged reads: "After a dealer submits order quantities, credit approval passes automatically." The draft sentence conflicts with the source text on the order of credit approval and order submission; the source text requires approval to pass first, while the draft places submission first and adds automatic passage, which the source text does not support. Here the subject is the dealer, the object is order quantities and credit approval, the state is approval passed, and the effective scope is the 2025 autumn ordering event.

Configuration and implementation checks

The table below centers on the sample above and lists documented settings or implementation checks relevant to this feature and primary task. The hypothetical starting values are chosen only for this check, for comparison against another value, and are not official defaults.

Configuration or check itemHypothetical starting value and reasonComparison method and observation target
Search modeRun semantic retrieval and full-text retrieval once each; the sample contains numbers and natural languageCompare whether returned fragments cover the conditional sentence in the source text under each mode
Reference limitSet a token amount that covers the three source sentencesCompare against a smaller value and observe whether the conditional sentence is trimmed away
Minimum relevanceTake a middle value and observe whether the conditional sentence survives filteringCompare against a lower value for returned count and relevance
Question optimizationThe sample question is complete; run once with it off and once onCompare whether enabling it changes recall of the conditional sentence
Result rerankingEnable once when a rerank model is availableCompare the ranking position of the conditional sentence before and after reranking
Post-update reviewAfter material changes, check training and index statusCompare upload success against whether retrieval actually hits the content

Three common errors

  1. Splitting a condition from the content it governs into different chunks. In the sample, if "a dealer may submit order quantities only after credit approval has passed" is split apart, the recalled fragment keeps only "submit order quantities," and judgment loses its premise. Check: input that conditional sentence, compare whether the returned fragment contains both the approval state and the submission action, and observe whether the condition stays complete.
  2. Treating upload success as retrieval already updated. When material changes without checking training and index status, retrieval still returns the old fragment. Check: input the new wording after the change, compare the returned content against the pre-change source text, and observe whether the old sentence is still hit.
  3. Using semantic similarity in place of an authorization judgment. A retrieval hit on the credit approval passage does not mean that dealer has received approval. Check: input the draft sentence, compare the approval state in the source text against the wording of the draft sentence, and observe whether "after approval has passed" is misread as "passes automatically."

How to verify the setup

The following checks all use the full hypothetical source text, draft sentence, and requests given above. Each states the input, the comparison, and the condition for satisfaction. These are expectations and do not claim that testing has been performed.

  1. Input the three source sentences and the draft sentence, then compare the draft sentence "after a dealer submits order quantities, credit approval passes automatically" against the source text "a dealer may submit order quantities only after credit approval has passed." If the two differ on the order of approval and submission, judge the draft sentence as unsupported by the source text, keep the evidence gap open, and do not supply an authorization clause.
  2. Input "a dealer may submit order quantities only after credit approval has passed" as a retrieval request, then compare whether the returned fragment contains both the approval state and the submission action. If the conditional sentence stays complete, chunking meets the requirement; if only the submission action remains, record it as a chunking defect.
  3. Input a query containing only a sample number, then compare the returns from full-text retrieval and semantic retrieval. If the number query hits more precisely under full-text retrieval, use full-text or hybrid retrieval for exact numbers. For the empty-result case, a downstream design can be checked against the explicit paper input [], without claiming that a fictional rule always returns [].

Retrieval is an independent step outside authorization. A pending review does not show that an operating permission is absent. Signing, reaching cooperation, and contract effectiveness are three distinct facts. Fields not stated in the source text remain unknown.