What the documents look like
Closure and liquidation work handles exit and asset recovery, and it runs in the opposite direction from head-office site selection and store opening. The materials for this category are generated per store and per event, and they are updated on an irregular schedule rather than on a fixed cadence. The main documents are closure approvals, inventory clearance forms, lease termination agreements, and asset count sheets. Source systems named in the brief are POS inventory, the fixed-asset system, lease contracts, and the finance ledger. The task on this page is inventory procurement and supplier records: the supplier names, purchase batches, return quantities, and settlement statuses that appear in clearance forms and count sheets. Parsed output needs to point back to the document identity and version of the original text.
These materials differ from one another in structure. A clearance form is often tabular. A count sheet carries hierarchy. A lease termination agreement is a long clause-based document. The three most time-consuming steps in this category are counting inventory and assets, negotiating the lease exit, and settling employee and franchise amounts. Each of those steps consumes the parsed output described here.
Constraints at the document chunking step
Chunking has to follow the structure of each material. Conditions, explanations, and the content they constrain cannot be split apart. In FastGPT, a knowledge base consists of libraries, collections, and data. A collection can be understood as a file. A library can contain multiple collections, and a collection can contain multiple groups of data. The smallest search unit is the library, so a knowledge base search runs across the whole library, and collections serve only to classify and manage data; they do not affect search results.
One group of data can map to multiple vectors. Original data is stored in the dataset.datas table in MongoDB, and an indexes field records the corresponding vector IDs as an array. Vectors are stored in a vector field in PostgresSQL, with an HNSW index. During retrieval, vectors are recalled first, and the original data is then located in MongoDB by vector ID. Records that correspond to the same group of original data are merged, and the highest score is taken. Beyond the default text index, if the model supports it, image content can also produce an image description index or an image vector index.
Semantic search relies on vector distance. Full-text search relies on keyword hits. Hybrid search uses both and merges the two result sets through RRF. Rerank applies a model to reorder candidates and produces a score between 0 and 1 that represents relevance between the searched content and the question. The minimum relevance value is a filter threshold and takes effect only in semantic search or when result reranking is used. The citation limit controls how many tokens of content are cited per search, up to n tokens. Semantic recall and relevance scores do not perform permission or entity isolation, and retrieval itself does not constitute authorization. A relevance score is not a category, entity, or permission filter, and a similarity setting does not exclude unrelated businesses or unauthorized records.
Configuration and implementation checks
The following is a hypothetical paper exercise used to explain the checking method. It does not represent a real record or an executed test. Hypothetical source text: "In March 2024, a franchise store in the East China region submitted a closure approval. The attachment includes the March inventory clearance form, supplier Jia Logistics, return batch A-03, quantity 120 items, status pending settlement. The lease termination agreement signature date is 10 April 2024, and the effective date is 1 May 2024." Draft sentence to be assessed: "The store's return batch A-03 has completed settlement, and the lease termination agreement has taken effect."
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison object |
|---|---|---|
| Search mode | Hybrid search | Supplier names and batch numbers need keyword hits, while return status descriptions need semantic matching; compared with semantic search alone |
| Minimum relevance | Hypothetical starting point 0.3 | Used to filter low-relevance fragments; compared against the explicit term hits in the sample |
| Citation limit | Hypothetical starting point 2000 tokens | Needs to hold clearance form and agreement clause fragments; compared against the actual length of a single material |
| Question optimization | Enabled | The sample question contains a reference; compared against retrieval results with it disabled |
| Result reranking | Enabled | Second-pass ordering when candidates are numerous; compared against RRF fusion results alone |
| Segmentation method | Segment by material structure | Tables and clauses handled separately; compared against leaving the whole document unsegmented |
Three common errors
- Parsing "pending settlement" as "completed settlement." The input is the status field of the clearance form, the comparison object is the source text "pending settlement," and the observable result is that the draft sentence disagrees with the source status. Pending settlement means settlement is not yet complete; it does not mean settlement is complete.
- Treating the signature date of 10 April 2024 as equivalent to having taken effect. The input is the two fields for signature and effective date, the comparison object is the two dates in the source text, and the observable result is that the draft sentence treats signature as effectiveness. Signature and effectiveness are different facts, and the sample gives an effective date of 1 May 2024.
- Treating a retrieval score as a basis for permission. The input is a user query request, the comparison object is the returned fragment and the access permission, and the observable result is that a retrieval hit does not change the authorization state. Retrieval is not authorization, and a pending review does not demonstrate the absence of an operating permission.
How to verify the setup
- Verification one: input the hypothetical source text and the draft sentence "the store's return batch A-03 has completed settlement." Compare the source status field "pending settlement" against the draft sentence. The condition is satisfied when the retrieval result returns a fragment containing "pending settlement" and the draft sentence is marked as unsupported by the source.
- Verification two: input the hypothetical source text and the draft sentence "the lease termination agreement has taken effect." Compare the signature date field and the effective date field. The condition is satisfied when the retrieval result returns both dates and the draft sentence is marked as treating signature as effectiveness.
- Verification three: input an empty-result continuation scenario, with a paper input of
[]. Compare the downstream design's handling of an empty citation. The condition is satisfied when the system returns[]and does not fabricate content. If retrieval does not return the expected fragment, record it as a miss and do not infer that the rule does not exist. After a material change, the actual training and index state must be checked; a successful upload does not mean retrieval has been updated.