Group-buy presale orders: document chunking for product questions

Review document chunking for product questions in Group-buy presale orders. Check sources, input boundaries, error handling and repeatable test evidence.

What the documents look like

Presale group-buy collection takes orders first and organizes procurement and fulfillment afterward. Product reference and selection questions in this category draw on presale product tables, collection results, procurement plans, and cut-off notices. Operations and procurement planning staff confirm product specifications, suppliers, and supply scope before the cut-off. The quality of document parsing and chunking determines whether a question can locate the correct entry.

Materials update daily or per session. The same product can change specification, supplier, and cut-off time across sessions, so chunks need to retain session and validity information. Document sources include mini-program orders, supplier inventory, group-leader feedback, and warehouse routing. Parsing must separate order facts from planning intent.

Constraints at the document chunking step

A FastGPT 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. Vector storage uses the PostgresSQL PG Vector plugin with an HNSW index. MongoDB stores original data in the dataset.datas table together with an indexes field, so one data group can map to multiple vectors.

During retrieval, vectors are recalled first, then the vector ID is used to find original data in MongoDB. Records corresponding to the same original data are merged and the highest score is kept. Multi-vector mapping balances content length against semantic richness; one data block can carry multiple indexes. Hybrid search merges semantic and full-text results through RRF. A ReRank model produces a 0-1 score that can be used for filtering. The minimum relevance value takes effect only in semantic search or when result reranking is used. The reference limit is controlled by tokens. Retrieval does not perform authorization, and a similarity score does not establish permission or entity isolation.

Hypothetical paper test case: the source material reads, "For the session on 12 March 2025, the leafy vegetable supplied by Supplier A is Shanghai bok choy, 500 g per portion; the cut-off time is 11 March 20:00; supply scope is limited to the Chengdong warehouse." A draft sentence reads, "For this session, the leafy vegetable is supplied by Supplier B, and the cut-off time is 12 March 20:00." The task is to determine whether the draft agrees with the source on the supplier field and the cut-off time field.

Configuration and implementation checks

Configuration itemHypothetical starting point for this trialReason and comparison method
Search modeHybrid searchProduct names and supplier names need both semantic and keyword coverage; compare recall coverage against semantic search alone
Reference limitHypothetical starting point of 2000 tokensPresale product table entries are short; compare against 4000 tokens to see whether unrelated entries are pulled in
Minimum relevanceHypothetical starting point of 0.3Compare against 0.5 and observe whether cut-off notice entries are over-filtered
Question optimizationEnabledCompletes references during follow-up questions about session and supplier; compare first-round hit behavior against disabled
Chunk granularitySplit by session and product entryCompare against splitting by whole table; check whether cut-off time stays in the same chunk as the product entry
Index annotationAnnotate product name and supplier name on the same data blockCompare against a single index; check recall differences for terminology and number queries

These values are hypothetical starting points for this paper trial and are not official defaults. RRF is the result fusion process for hybrid search and is not a separate switch. Image retrieval requires image input and corresponding model capability. Reranking requires a configured model and must be enabled through settings.

Three common errors

  1. Treating a successful upload as an updated index. After material changes, the actual training and index state need to be checked; the upload action and retrieval taking effect are two separate stages.
  2. Treating the minimum relevance value as a permission or entity filter. This value only filters low-relevance results; it does not exclude unauthorized records or unrelated suppliers.
  3. Splitting a cut-off notice and the product table into different chunks. When a condition, its description, and the content it constrains are separated, a question may return an outdated cut-off time.

How to verify the setup

  1. Input the hypothetical source material and draft sentence, then compare the supplier field. The source states Supplier A; the draft states Supplier B. For the same session and same product, the field values are mutually exclusive, so the result is a contradiction.
  2. Input the hypothetical source material and draft sentence, then compare the cut-off time field. The source states 11 March 20:00; the draft states 12 March 20:00. For the same session, the field values are mutually exclusive, so the result is a contradiction.
  3. Search the product name "Shanghai bok choy" and the supplier name "Supplier A" separately, then observe whether returned entries include the cut-off time and supply scope for the same session. If the cut-off time is not returned in the same chunk as the product entry, record this as a chunking gap rather than a retrieval failure cause. An empty result can be checked against downstream design using the explicit paper input []. A claim that a fictional rule search must return empty is not made. Cross-model retrieval cannot be jointly associated; check identifiers first, exclude non-matching entries, and record the actual observation.