Dealer ordering events: document chunking for document comparison

Review document chunking for document comparison in Dealer ordering events. Check sources, input boundaries, error handling and repeatable test evidence.

What the documents look like

Brand dealer ordering events serve offline dealer reservations and do not directly manage platform storefronts. The materials handled in this category include ordering handbooks, ordering contracts, sample lists and credit approvals. Supporting data arrives from the ordering event system, historical sales, dealer inventory and financial credit. These materials carry party identities, objects, quantities, amounts and validity scopes, and the comparison task depends on keeping each condition attached to the content it constrains.

In FastGPT, a knowledge base consists of libraries, collections and data. The smallest search unit is the library; collections only classify data and do not affect search results. A single data group can map to multiple vectors. During retrieval, vectors are recalled first, then the vector IDs are used to locate the original data in the MongoDB dataset.datas table; entries that resolve to the same original data are merged and the highest score is kept. Full-text search uses Milvus BM25 with the modeldata_v2 single table when the vector store is Milvus 2.5.16 or above, and MongoDB $text with jieba tokenization for other vector stores. Hybrid search merges results through RRF, and ReRank can perform a second ordering. Image retrieval requires an image input and matching model capability, and reranking requires a rerank model enabled in the settings.

A hypothetical drill sample is used below. The ordering contract text supplied for checking reads: "Party A is a brand channel department; Party B is a dealer in the East China region. The ordered quantity under this contract is 800 units at a unit price of 120 yuan, with a validity scope of the 2025 autumn ordering event. The credit approval status is pending review." The draft sentence to be judged reads: "This contract has received credit approval, and the ordered quantity of 800 units has taken effect." Comparing the draft against the source: the credit approval status is pending review and no approval is recorded; the contract effectiveness status is not recorded. The draft turns pending review into approved and turns an unrecorded status into effective. Neither claim is supported by the source text.

Constraints at the document chunking step

Ordering materials often place subject, object, quantity, amount and validity scope in the same passage. When chunking, a condition statement must remain in the same data group as the content it constrains, so that the parsed result can point back to the document identity and version of the source. A data group may correspond to multiple vectors; retrieval recalls vectors first and then looks up the original data by vector ID, merging entries that resolve to the same original data and keeping the highest score. Full-text search on Milvus 2.5.16 and above uses BM25 with the modeldata_v2 single table, while other vector stores rely on MongoDB $text with jieba tokenization. Hybrid search combines semantic and full-text recall through RRF, and ReRank can reorder candidates with a 0-1 score. Image retrieval requires an image input and a model that supports it; reranking requires a rerank model enabled in the settings. The minimum relevance value only applies to semantic search or when result reranking is used, and it acts as a filter threshold rather than a final ordering rule. The reference cap limits how many tokens of content are cited per search.

These constraints matter for contract and transaction material comparison because a chunk that splits a condition from its constrained content can make a pending approval look like a completed one, or make an unrecorded effectiveness status look like a confirmed one. Retrieval only recalls content; it does not authorize, approve or execute anything.

Configuration and implementation checks

Configuration or check itemValue or action on this pageBasis and notes
Search modeHybrid searchMaterials contain identifiers and natural language, so semantic and full-text recall are used together
Reference capHypothetical trial starting point of 3000 tokensOrdering contract passages are long; this starting point is compared against 1500 tokens
Minimum relevanceHypothetical trial starting point of 0.4Filters low-relevance fragments; compared against 0.6
Question optimizationDecide whether to enable based on actual resultsA clear question can leave it off; enabling adds a model call
Chunk reviewManually check whether conditions and constraints stay in the same groupPreserves document identity and version
Training status checkVerify actual training and index status after uploadA successful upload does not mean retrieval has been updated

Three common errors

  1. Treating pending review as approved. The sample source states the credit approval status is pending review, while the draft says credit approval has been received. The input is the source text and the draft sentence; the comparison is the value of the same field; pending review and approved are mutually exclusive; the observable result is a contradiction.
  2. Treating an unrecorded status as effective. The sample source does not record the contract effectiveness status, while the draft says it has taken effect. The input is the source text and the draft sentence; the comparison is the same field; the source has no value for that field; the observable result is unsupported, and the evidence gap must be recorded.
  3. Treating retrieval as authorization. In the sample, credit approval is pending review; retrieval can recall that passage, which does not mean credit has been approved or the contract has taken effect. The input is the retrieval result and the business status; the comparison is between the two; the observable result is that a retrieval hit does not change the authorization status.

How to verify the setup

  1. Input the sample source text and the draft sentence, compare the credit approval field value, and when the draft says approved while the source says pending review, judge it as a contradiction and output the source quotation for that field.
  2. Input the sample source text and the draft sentence, compare the contract effectiveness field, and when the source does not record it while the draft says it has taken effect, judge it as unsupported, keep the evidence gap, and do not invent an effectiveness clause.
  3. Input the sample source text, search separately by term and by identifier, and observe whether chunking preserves subject, object, quantity and validity scope; a retrieval hit only means the content was recalled, not that approval or effectiveness has been completed. An empty result can be checked against the downstream design using the paper input []; do not claim that a fictional rule search necessarily returns []. Cross-model association is not possible; check identifiers first and exclude those that do not match.