What the documents look like
Warehouse picking, checking and packing runs on outbound orders. The working documents are wave picking lists, checking records, shipping labels and packaging consumable sheets. These come from the WMS, the order system, the electronic shipping label platform and weighing equipment. This differs from inbound put-away, which handles supplier arrivals. In this category, procurement and supplier reference material enters the knowledge base as background that pickers, checkers and packing supervisors look up while they work.
A wave picking list carries a wave number, order numbers, SKUs, quantities and pick locations. A checking record carries the checker, the time and any discrepancy items. A shipping label carries the carrier and waybill number. A packaging consumable sheet carries consumable codes and specifications. When these documents are split into chunks, a condition, its explanation and the content it constrains need to stay in the same segment. Codes and proper nouns need to keep an identity that points back to the original text. One set of source data can map to several indexes, and the source data and the retrieval indexes live in separate storage. Semantic recall and relevance scores affect candidate ordering. They do not perform permission or entity isolation.
Assumed paper exercise sample. Source text for checking: "Supplier code SUP-0007, supply scope covers cartons and bubble wrap, quotation valid until 30 June 2025, cooperation status pending review." Draft sentence to be judged: "SUP-0007 has been granted supply authorization and can supply long term." The source text gives only a quotation validity date. It states no supply term and no review conclusion. The draft sentence lacks support.
Constraints at the document chunking step
The chunking step inherits several conditions from how these documents are structured. A wave picking list ties a wave number to several orders and several SKUs, so a chunk that keeps the wave number but drops the order lines loses the reference the picker needs. A checking record ties a discrepancy to one checker and one time, so splitting the discrepancy from its checker breaks the record. A shipping label and a packaging consumable sheet are short, but their codes and specifications are exact identifiers, and full-text recall handles those better than semantic recall.
The documented retrieval design matters here. FastGPT stores vector data in PostgresSQL with the PG Vector extension and an HNSW index, and stores other data in MongoDB. In the MongoDB dataset.datas table, an indexes field records the vector IDs for a piece of source data, and that field is an array, so one set of data can correspond to multiple vectors. During retrieval, vectors are recalled first, then the vector ID is used to find the original content in MongoDB. If several vectors map to the same source data, the results merge and the highest score is kept. This is why one chunk can carry more than one index without duplicating the source record.
Semantic recall, full-text recall and hybrid recall behave differently on these documents. Full-text recall suits exact queries such as a wave number, a waybill number or a consumable code. Semantic recall suits a natural-language question. Hybrid recall uses both and merges them with RRF, and the documentation notes that after hybrid recall the result set is large and cannot be filtered directly by similarity, so a rerank model is usually applied and its score used for filtering. A relevance score is a filtering threshold. It is not a category filter, an entity filter or a permission filter, and retrieval does not perform authorization.
The reference limit is expressed in tokens, not in a top-k item count. The documentation explains this choice: in a mixed knowledge base, chunk lengths differ widely, so a top-k limit produces unstable results, and a token limit is used instead. The minimum relevance value is a number between 0 and 1 and only takes effect under semantic retrieval or when reranking is used.
Configuration and implementation checks
| Configuration or check item | Value or action on this page | Basis and explanation |
|---|---|---|
| Search mode | Hybrid retrieval | Code queries rely on full-text recall, natural-language queries rely on semantic recall |
| Reference limit | Assumed trial starting point 3000 tokens for this paper exercise | A paper starting point, to be compared against 2000 and 4000 before adjusting |
| Minimum relevance | Assumed trial starting point 0.4 for this paper exercise | Compared against 0.3 and 0.5 to observe whether unrelated fragments decrease |
| Question optimization | Check whether it is enabled for multi-turn follow-up | The documentation states it adds one model call and increases latency |
| Chunk check | Inspect segment by segment whether a condition and its constraint share a chunk | Segment completeness affects retrieval hits |
| Post-update review | After material changes, check the actual training and index state | A successful upload does not mean retrieval has updated |
Three common errors
- Treating a quotation validity date as a supply term. The input is the SUP-0007 source page, the compared fields are "quotation valid until" and "supply term," these are not the same field, the source states no supply term, and the draft claim is judged unsupported.
- Treating a pending-review status as granted authorization. The input is the cooperation status field, the comparison is between "pending review" and "authorized," these are mutually exclusive values for the same field, the source value is pending review, and the authorization conclusion in the draft does not hold.
- Treating a retrieval hit as a permission confirmation. The input is one retrieval return, the comparison is between the returned content and an authorization record, retrieval performs no authorization judgment, and the authorization state still requires separate verification.
How to verify the setup
- Code retrieval check. Input "SUP-0007." Compare whether the returned passage contains that code together with the quotation validity sentence from the source. If the passage contains the code and keeps the validity sentence, the chunk meets the back-reference requirement. If the passage contains only the code and no validity sentence, record it as incomplete chunking.
- Draft sentence judgment check. Input the draft sentence "SUP-0007 has been granted supply authorization and can supply long term." Compare it against the source line "cooperation status pending review." The two share the same subject and the same field with mutually exclusive values, so the draft sentence is judged unsupported. If the source later shows an explicit review-passed record, reclassify it as pending verification.
- Empty result check. Input the paper retrieval term []. Compare whether the downstream design handles it as an empty reference. The expected behavior is a return with no reference content. Do not infer from this that any rule necessarily returns an empty result.
Libraries built on different vector models cannot be associated together. Check the model identifier first and exclude those that do not match, then record what is actually observed. Do not infer missed recall or redundant results from the association itself.