What the documents look like
Store counts and loss control work from book-to-physical variance and shrinkage. This category does not process supplier payables, which separates it from supplier settlement work. The data sources named for the category are POS inventory, WMS, monitoring systems and the SB/T count specification. The documents that arrive at the chunking step are count sheets, variance analyses, damage write-off approvals and monitoring retrieval records. Monthly and quarterly update rhythms mean one SKU can appear in several periods, so a chunking setup has to keep period, store, quantity and approval state together rather than treating a single appearance as the whole record.
The consequences of getting this wrong are inventory distortion, overstated gross margin and employee fraud. Those consequences shape what a chunk must preserve. A count sheet carries SKU, book quantity, physical quantity and variance reason in table form. A damage write-off approval carries application, review and approval as distinct states. If chunking separates the state from the quantity it constrains, a later retrieval can return a number without the condition that governs it.
Constraints at the document chunking step
FastGPT stores one data set that can map to several vectors. The indexes field in the MongoDB dataset.datas table records the corresponding vector IDs as an array, so one data set can correspond to multiple vectors. At retrieval time the system recalls vectors first, then uses the vector IDs to find the original content in MongoDB. When several vectors resolve to the same original data set, the results merge and the highest score is used. This matters for count documents because a long count table can be split into several vectors while remaining one original data set.
Chunking therefore has to keep a condition, its explanation and the content it constrains inside the same verifiable unit. A damage write-off approval state and the quantity it applies to belong together. A variance reason and the SKU and period it describes belong together.
Hypothetical paper exercise sample. The material text supplied for comparison reads: "Store A, March 2025 count sheet: SKU-1001 book quantity 120 units, physical count 108 units, variance -12 units, variance reason pending investigation. Damage write-off approval form: the applicant has submitted a write-off application for 12 units, approval state is pending review." One draft sentence to be judged reads: "The store's 12-unit variance has completed damage write-off approval." Judging requires the same subject, the same period and the same field. In the material the approval state is pending review; the draft sentence states completed approval. These are mutually exclusive values on the same field, so the draft sentence is not supported by the material. The material does not state whether approval authority exists, and that gap stays open.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Search mode | Hybrid search | Count sheets contain SKU identifiers and natural-language variance reasons, so both query types need coverage; compare hit results against semantic search alone |
| Reference limit | Token value to be determined | The documented unit for the reference limit is tokens; estimate a starting point from the length of one count-sheet chunk and compare against actual returned content length |
| Minimum relevance | 0-1 value to be determined | This value takes effect only under semantic search or when result reranking is used; compare a starting point against the relevance of recalled content before adjusting |
| Question optimization | Decide from observed effect | The documentation states it adds one model call and improves multi-turn retrieval; compare against response time |
| Result reranking | Enable when a model is available | Rerank produces a 0-1 score usable for filtering; compare against ordering without reranking |
| Image index | Check against what was actually generated at ingestion | Whether an image can be retrieved depends on whether the corresponding index was built at ingestion; verify the actual index state |
RRF is a merge process for combining multiple recall paths, not a switch. Image retrieval requires an image input and a model capable of handling it. Reranking requires a model and must be enabled by configuration. The optional paths in the overall retrieval flow do not all execute on every request.
Three common errors
- Treating pending review as completed approval. In the sample, the write-off approval state is pending review. A draft sentence that states completed approval converts an unfinished state into an executed result. The check is to input the approval form text, compare the approval state field, and observe whether the output still preserves the pending-review wording.
- Treating a successful upload as an updated retrieval index. After material changes, the actual training and index state must be checked. The upload action itself does not indicate the index was rebuilt. The check is to search after the change using a term, an identifier and a natural-language question, and observe whether returned content corresponds to the new document version.
- Treating a similarity score as a permission or entity filter. Minimum relevance is a filtering threshold. It does not exclude unrelated business lines or unauthorized records. The check is to input a cross-store query, compare returned content for records outside the target store, and observe whether additional business verification is required.
How to verify the setup
- Input the sample material text and the draft sentence given above. Compare the approval state field. The condition is met when the output identifies that pending review and completed approval are mutually exclusive on the same field and preserves the evidence gap rather than resolving it.
- Input the identifier SKU-1001 as a query. Compare whether the returned chunk contains quantity, store, period and variance reason. The condition is met when the chunk keeps these inside one verifiable unit.
- Input a query unrelated to store counts. Compare the returned results and observe whether clearly unrelated content appears. For an empty result, check the downstream design against the paper input []. Do not assume a fabricated rule necessarily returns an empty result.
Retrieval is not authorization. Forms collect values; business verification, approval, database writes and external synchronization require their stated downstream implementation. A pending request is not an approval, an offered option is not execution, and an unsigned termination is not a completed termination. Where the material does not state a field, that field remains unknown.