Store price and display checks: document chunking for product questions

Review document chunking for product questions in Store price and display checks. Check input mappings, source evidence and failure handling before use.

What the documents look like

Price and display auditing happens during ordinary trading periods, and the working material is dominated by store visit photographs, price tag lists, display standards, and rectification notices, refreshed weekly or monthly. The confidence level for this category is broadly as described, so field-level detail depends on the material actually on hand.

Material form shapes the chunking decisions. Price tag lists usually carry item numbers and price fields, so segmenting by row or by small table keeps a number and its price inside one data block. Display standards combine conditional statements with illustrations, so a condition sentence and the shelf, tier, or item it constrains need to stay in the same block. Rectification notices carry store, problem item, deadline, and status, and the subject and status fields should not be separated.

FastGPT treats the library as the smallest search unit; a collection is only a classification container and does not affect search results. Vector original data sits in the MongoDB dataset.datas table, where the indexes field records the corresponding vector IDs as an array, so one data group can map to several vectors. Vectors are stored in the PostgresSQL vector field with an HNSW index. Retrieval recalls vectors first, looks the original data back up by vector ID, merges records belonging to the same data group, and takes the highest score. Segment integrity therefore matters: when a condition, an explanation, and the content it constrains are split apart, the recalled block may lack the fields needed for a judgement.

Exact lookups such as item numbers and model numbers suit full-text search or hybrid search, while natural language questions suit semantic search or hybrid search. Hybrid search merges multiple result paths through RRF, and ReRank performs a second ordering with a 0–1 score. The minimum relevance value applies only under semantic search or when result reranking is used, and it is a filter threshold that does not perform permission or entity isolation. The reference cap is measured in tokens, not in item counts.

Constraints at the document chunking step

A hypothetical paper exercise sample is set out here for illustration only. A chain brand head office operations department publishes a hypothetical "Store Price Tag and Display Audit Standard (hypothetical version)" dated 10 June 2025. Two sentences from the source read: "Category A shelf price tags in a store must match the POS price of the day, and any discrepancy must be corrected within 24 hours." and "A rectification notice must state the store name, the problem item, the rectification deadline and the status, where status is either pending rectification or completed." A draft sentence awaiting adjudication reads: "Store A has completed the price tag correction to standard, and the rectification status is completed." The checking material contains only a store visit photograph dated 12 June 2025 showing that price tags match the price tag list, and no completion record for a rectification notice.

The chunking constraint follows directly. The standard sentence joins a shelf category to a price requirement and a time limit; if the block splits them, a retrieval hit may return the deadline without the object it applies to. The notice requirement joins a store name to a status field with two mutually exclusive values; a block missing the completion record cannot support a completed status. The draft sentence asserts a status value, while the checking material covers a different evidence type and a different date.

Configuration and implementation checks

The table below covers only settings or implementation checks that are documented or explicitly named for this page's feature and primary task, tied to the sample above. Each numeric value is a hypothetical starting point for this exercise, chosen for comparison against other values, and does not represent an official default.

Configuration or check itemHypothetical starting pointReason and comparison object
Search modeHybrid searchSample contains item numbers and natural language questions; compare against semantic search alone
Minimum relevanceHypothetical starting point 0.4Compare with 0.2 and 0.6 to observe candidate block counts; applies only under semantic search or reranking
Reference capHypothetical starting point 1500 tokensCompare with 800 and 2500 to observe whether price tag rows and condition sentences are truncated
Segmentation methodSegment by price tag row and condition sentenceCompare with a single whole-page block to check whether item number and price stay together
Question optimizationEnabled for short follow-up questionsCompare with disabled to observe recall differences on follow-ups such as "status of this store"
Training and index checkVerify actual training status after uploadCompare with checking upload success alone, to confirm whether the index has updated

Three common errors

  1. Treating a pending rectification status as completed. The input is the draft sentence stating that rectification status is completed, together with the checking material list. The comparison object is the standard's requirement that status is either pending rectification or completed, together with the completion record. The observable result is that the completion record is absent, so the draft sentence is not supported.
  2. Treating a similarity threshold as a permission or entity filter. The input is a retrieval question about Store A. The comparison object is the documented scope of the minimum relevance setting. The observable result is that the setting only filters low-relevance content and does not exclude records of other stores; store scope must be bounded by the retrieval range or by explicit human input.
  3. Treating upload success as retrieval being updated. The input is the hypothetical standard dated 10 June 2025. The comparison object is the actual training and index status. The observable result is that upload success and index availability are two separate facts, and retrieval results remain unknown until training status is checked.

How to verify the setup

  1. Price tag row integrity check. The input is the sample sentence "Category A shelf price tags in a store must match the POS price of the day". The comparison object is whether the recalled block contains both the shelf category and the price requirement. The observable result is that both appearing in one block satisfies the condition; if they are split apart, record the segmentation gap.
  2. Status field check. The input is the draft sentence "rectification status is completed" together with the material list. The comparison object is the status field listed in the standard and the completion record. The observable result is that an absent completion record yields a judgement of not supported, not of conflict.
  3. Empty result handling check. The input is a paper empty result []. The comparison object is the downstream design for displaying and recording empty results. The observable result is that the downstream treats it as an empty result. This does not permit an inference that a particular fictional rule will always return []. Libraries built on different vector models cannot be associated together; verify the identifier first and exclude non-conforming ones, record the actual observation, and do not run cross-model retrieval to compare missed recalls.