Peak-sale fulfillment: document chunking for product questions

Review document chunking for product questions in Peak-sale fulfillment. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

Peak-sale fulfillment scheduling centers on short-term peak capacity and the arrangement of people, vehicles, and space. The main data sources are historical peak-sale orders, platform campaign registrations, WMS capacity, and courier pickup capability. The documents handled day to day include peak-sale forecast tables, staff rosters, courier assurance plans, and exception daily reports. The product-question task requires parsing retrievable passages out of these documents so that scheduling staff can look up specific products, staffing, or vehicle arrangements.

A peak-sale forecast table typically gives an order-volume range and a category distribution by campaign session and date. A staff roster lists shifts and posts by day. A courier assurance plan states the carrier and pickup window. An exception daily report records that day's deviations. These documents update per session or per day, so parsing and chunking need to preserve document identity and version, letting retrieval results point back to the source text. If chunking separates a forecast condition from the quantity it governs, the retrieved fragment loses its basis for judgment.

Constraints at the document chunking step

The quality of parsing and chunking depends on whether segmentation keeps structure and semantics intact. When a passage is structurally and semantically complete and single in meaning, vector retrieval precision is higher. One set of source data can map to multiple vectors, and the same data chunk can carry multiple indexes; a hit on any one index recalls that data. Source data is stored in the MongoDB dataset.datas table, where the indexes field records the corresponding vector IDs. Vectors are stored in the PostgresSQL vector field. During retrieval, vectors are recalled first, then the original data is fetched from MongoDB by vector ID; records that map to the same source data are merged and the highest score is kept.

Numbers, models, and proper nouns in peak-sale documents suit full-text retrieval, while natural-language descriptions suit semantic retrieval. Hybrid retrieval fuses multiple result paths through RRF, and a ReRank model can reorder candidate text and produce a 0-1 score. The minimum relevance value takes effect only under semantic retrieval or when result reranking is used; it is a filter threshold and does not perform permission or entity isolation. A search library is not the same as an authorization scope, and retrieval itself does not constitute approval of a scheduling action.

Hypothetical drill sample: a warehouse's "Peak-Sale Forecast Table" source text reads: "Campaign session A is effective from June 1 00:00 to June 3 24:00. The forecast order-volume range is 80,000 to 100,000 orders. The applicable category is daily necessities." A draft sentence to be judged reads: "Campaign session A has a forecast order volume of 90,000 orders and applies to all categories." The draft sentence disagrees with the source on both the order-volume value and the applicable category: the source gives a range and a limited category, while the draft writes a single point value and widens the scope.

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. Values are hypothetical starting points for this drill, with the reason for choosing them and the comparison object noted.

Configuration itemHypothetical starting point for this drillReason and comparison method
Search modeHybrid retrievalThe sample contains a session identifier and a category description, so both exact terms and semantics need coverage; compare against semantic retrieval alone
Reference limitHypothetically set to 3000 tokensThe sample passages are short; a smaller value shows whether a conditional clause is truncated; compare against a setting of 6000 tokens
Minimum relevanceHypothetically set to 0.4The sample question is explicit; a mid value shows the filtering effect; compare against 0.2 and 0.6
Question optimizationHypothetically off for this drillThe sample question is complete on its own; leaving it off shows raw retrieval behavior; compare against results with it on
Result rerankingHypothetically enabled for this drillCandidates include similar session descriptions; enabling it shows ranking changes; compare against ranking without it
Chunking checkSplit at paragraph boundariesCheck whether condition, quantity, and category stay in one chunk; compare against fixed-length splitting

Three common errors

  1. Writing a forecast range as a single point value. The sample source gives 80,000 to 100,000 orders; if parsing or drafting outputs 90,000 orders, the input is the source range, the comparison object is the draft single value, and the observable result is that the two values disagree, which is a rewrite beyond the source scope.
  2. Widening a limited category to all categories. The sample source limits the category to daily necessities, while the draft sentence says all categories; the input is the source category field, the comparison object is the draft category wording, and the observable result is that the applicable object has been widened, an extension without source support.
  3. Treating a successful upload as an updated index. After a material change, the actual training and index state needs checking; the input is the changed document, the comparison object is the retrieval return content, and the observable result is that retrieval still returns the old passage, indicating the index has not been updated.

How to verify the setup

  1. Input the three source sentences and the draft sentence, compare the draft's order-volume value and category scope against the source, and observe whether the draft shows a single point value and all categories; if either appears, record it as inconsistent.
  2. Input the sample source, retrieve separately with "campaign session A applicable category" and "campaign session A order-volume range," compare whether the returned passages contain the complete condition and quantity, and observe whether the return keeps the source subject, period, and range; if any item is missing, record it as incomplete chunking.
  3. Input a query unrelated to the sample, compare the relevance of the return against the sample topic, and observe whether the sample passage is returned; if it is, record that the chunk boundary or filter setting needs review. For the empty-result case, a clearly labelled paper input can be used to check the downstream design, without claiming that a fictional rule must return an empty result.

Libraries built on different vector models cannot be associated together; verify the identifier first and exclude non-matching ones, record the actual observation, and do not run cross-model retrieval to compare missed recalls. Retrieval and form value collection do not constitute authorization; scheduling operations, approval, and external synchronization each need their own downstream implementation.