Chain-store site selection: document chunking for document comparison

Review document chunking for document comparison in Chain-store site selection. Check input mappings, source evidence and failure handling before use.

What the documents look like

Site selection and store opening work happens before a store begins trading. The core materials are lease and construction delivery documents. A chain headquarters expansion team handles site evaluation forms, letters of intent for lease, renovation budgets and opening schedules. These materials are produced per store and updated at irregular intervals, per store. Contract and transaction material comparison requires judging whether the letter of intent, the budget and the schedule agree on the same store, the same period and the same field. Once a document is split into chunks, a condition and the content it constrains can be separated, and the comparison loses its traceable textual basis.

The comparison task itself is narrow. It checks consistency across materials that describe the same store and the same period. It does not certify identity, does not approve spending and does not execute any business action.

Constraints at the document chunking step

In FastGPT, a knowledge base consists of library, collection and data. The smallest search unit is the library; collections only group data for management and do not affect search results. Vector original data is stored in the MongoDB dataset.datas table, where an indexes field records the corresponding vector IDs; one group of data can map to multiple vectors. PostgresSQL holds a vector field for vectors. Retrieval first recalls vectors, then uses the vector ID to find the original data in MongoDB; entries that map to the same original data are merged and the highest score is taken.

Chunking should keep a single, complete semantic unit. A condition, an amount, a date and the object it constrains should remain in the same data block. Retrieval is not authorization. A similarity score does not perform permission or entity isolation, and a relevance threshold is not a category, entity or permission filter. Form fields collect values; business verification, approval, database writes and external synchronization require their own downstream implementation.

Hypothetical paper test sample: a chain headquarters expansion staff member holds a letter of intent for lease. The source text reads: "Party A is a commercial management party; Party B is a chain brand party. The intent deposit is RMB 50,000, payable within ten working days from the date of signing. This letter of intent is valid for thirty days; if a formal lease contract is not signed before expiry, the intent deposit is refunded." A separate renovation budget source text reads: "The total renovation budget for this store is RMB 800,000, including fire-safety modification." The draft sentence to be judged is: "Both parties have signed the formal lease contract, and the intent deposit is converted into a security deposit." The comparison objects are the same store, the same period, and the fields of intent deposit payment and contract signing status.

Configuration and implementation checks

Configuration itemSetting for this pageBasis and checking method
Search modeHybrid searchSemantic and full-text recall are merged through RRF; suits clause numbers and natural language together
Result rerankingEnable ReRank as neededRerank produces a 0-1 score usable for filtering; requires an available model and the setting being enabled
Minimum relevanceHypothetical trial starting value 0.3This value takes effect only in semantic search or with result reranking; compare against observed hits and adjust
Reference limitSet by tokensOfficial control is by tokens, not top k, avoiding instability from differing chunk lengths
Chunking reviewManual reviewCheck whether condition, amount, date and constrained object remain in the same data block
Post-update recheckManual reviewAfter a material change, check actual training and index status; a successful upload does not mean retrieval is updated

Three common errors

  1. Treating "intent deposit payment" and "contract signing" as the same field. They are different facts. A payment obligation stated in the letter of intent does not mean the formal contract has been signed. The draft sentence records the signing status as completed, which is unsupported.
  2. Treating a retrieval hit as authorization. Retrieving the letter of intent text only shows the content was recalled. It does not show that signing, effectiveness or refund has occurred. Authorization status must be checked separately.
  3. Treating a successful upload as an updated index. After a material change, the actual training and index status must be checked. Without that check, the retrieval status of that data block is unknown.

How to verify the setup

  1. Input the letter of intent source text and the draft sentence from the hypothetical sample. Compare the draft's claim "both parties have signed the formal lease contract" against the source wording "valid for thirty days; if a formal lease contract is not signed before expiry, the intent deposit is refunded." The source does not state that signing occurred, so the judgment is unsupported. The support condition is met only if the source contains a record of completed signing for the same party, the same period and the same field.
  2. Input terms and amounts such as "intent deposit" and "RMB 50,000," and observe whether the recalled data block contains both the payment condition and the time limit. If the recalled block lacks the time limit or the constrained object, the chunking is incomplete and must be rechecked.
  3. Input the renovation budget source text and compare whether "including fire-safety modification" sits in the same data block as the total budget. If the two are separated, the comparison result cannot be traced back to the source. Use an explicit paper input of [] to check the downstream display design; do not claim that a fictional rule retrieval necessarily returns empty.