What the documents look like
Brand after-sales repair work centers on warranty responsibility and physical repair outlets. The daily data comes from the after-sales system, store orders, and repair outlet feedback. For the inventory procurement and supplier materials task, the common documents are purchase request forms, supplier quotation sheets, spare-part inbound receipts, warranty cards, and repair work orders. These materials arrive as scanned files or electronic documents, and the fields that parsing must retain include dates, document numbers, spare-part model numbers, supplier names, and authorization status. Materials update per order or per day. Parsing and chunking must keep the condition statements of one document together with the content those conditions govern.
These documents carry a document identity and version that allow a retrieved chunk to point back to its source. A supplier name, a quotation validity date, and a spare-part model number belong to the same commercial condition set. Splitting them across separate data blocks weakens the ability to check a later statement against the original text.
Constraints at the document chunking step
In FastGPT, the whole knowledge base is made up of library, collection, and data. The smallest search unit is the library; a search runs across the whole library, and collections only classify data for management without affecting search results. One group of data can map to multiple vectors, and the indexes field records an array of vector IDs. When the same original data is recalled through several paths, the vectors merge and the highest score is taken.
Chunking must preserve the document identity and version that let a chunk refer back to the source text. It must avoid placing a supplier name, a quotation validity period, and a spare-part model number in different data blocks. Semantic retrieval relies on vector distance, while full-text retrieval relies on keyword hits. Model numbers, part numbers, and proper nouns suit full-text or hybrid retrieval. The minimum relevance value takes effect only under semantic retrieval or result reranking, and it acts as a filtering threshold. It does not isolate permissions or separate business entities.
Where libraries use different vector models, they cannot be associated together. The identifier must be checked first and non-matching libraries excluded. Retrieval is not authorization. A form collects values, and business verification, approval, database writes, and external synchronization each require their own downstream implementation.
Configuration and implementation checks
Hypothetical paper test case. A paper “Spare Part Purchase Request Form” reads: “Requesting entity: East China Region After-Sales Spare Parts Warehouse; Supplier: Example Supplier A; Spare part model: A-102; Requested quantity: 30 units; Quotation valid until June 30, 2025; Authorization status is Pending operations supervisor review.” A proposed draft sentence reads: “Example Supplier A has confirmed supply of the 30 units at the above quotation within the validity period.” The task is to judge whether the proposed sentence is supported by the source text.
| Configuration item | Hypothetical starting value for this exercise | Reason for the choice and the comparison object |
|---|---|---|
| Search mode | Hybrid retrieval | The sample contains model A-102 and natural-language description, so keyword and semantic coverage are both needed |
| Minimum relevance | 0.4 | Hypothetical starting value, compared with the recall range when no value is set, to observe whether the model-number hit is filtered out |
| Reference limit | 800 tokens | Hypothetical starting value, compared with the actual token count of the parsed single purchase request form |
| Question optimization | Off | The sample question has a clear subject, compared with the added latency and coreference resolution when it is on |
| Chunking method | Segmentation by document structure | Compared with fixed-length splitting, to check whether the quotation validity date stays in the same block as the model number |
| Training status check | Manual confirmation after upload | Compared with the uploaded-but-untrained state, to confirm whether the index has been built |
Three common errors
- Treating a successful upload as proof that retrieval has updated. Upload, training, and index building are separate stages. The actual training status must be checked before judging whether retrieval is available.
- Reading the minimum relevance value as a permission or entity filter. That value only filters low-relevance results. It does not exclude unrelated suppliers or unauthorized records, and retrieval itself does not constitute authorization.
- Reading a pending-review status as approved supply. In the sample, the authorization status is pending operations supervisor review, while the proposed sentence claims confirmed supply. The subject and field differ, so the claim is unsupported.
How to verify the setup
- Input the sample source text and the proposed draft sentence. Compare “has confirmed supply” in the draft against “Pending operations supervisor review” in the source. If the retrieval result returns only the pending-review status and no confirmed-supply wording appears, the draft sentence is unsupported and the evidence gap must be recorded.
- Input the model number “A-102” and run full-text retrieval. Compare whether the returned data block contains that model number together with its quotation validity date. If the model number and the validity date appear in the same data block, the chunking meets the condition. If they are split apart, the segmentation method needs adjustment.
- Input the empty query
[]and compare how the downstream design handles empty references. If the system returns an empty result and generates no fabricated content, the empty-reference path behaves as expected. If it returns non-empty content, record the actual observation without inferring a specific cause.