What the documents look like
Seller ratings and experience score maintenance follows consumer feedback after fulfilment and after-sales service. The work draws on platform experience scores, service indicators, after-sales reviews and customer service systems. The documents handled day to day are negative review handling records, experience score breakdowns, service diagnosis reports and rectification ledgers. This page is limited to one subcategory: inventory procurement and supplier materials. The materials to be parsed here include purchase orders, supplier qualification files, incoming batch records and return or exchange vouchers.
These materials differ in structure. A purchase order carries an order number and a date. A qualification file carries a subject and a validity scope. A batch record carries a quantity and a status. Document parsing and chunking must preserve the document identity and version that allow a chunk to be traced back to the source text. Paragraphs are checked against the structure of the specific material so that conditions, notes and the content they constrain are not split apart. Source data updates daily or weekly, and after a material change the actual training and index state is checked.
Constraints at the document chunking step
A FastGPT knowledge base is made of library, collection and data. The smallest search unit is the library. Vector storage uses the PostgresSQL PG Vector plugin with an HNSW index, while the MongoDB dataset.datas table stores vector source data and an indexes field records the corresponding vector IDs. One set of source data can map to multiple vectors. Chunking must distinguish source data from retrieval indexes, and a long text can receive several vector indexes to improve recall precision. Under a PG vector store, full-text retrieval uses MongoDB $text with jieba tokenisation. Hybrid retrieval merges semantic and full-text results through RRF, and reranking requires a model and must be enabled in settings. The reference limit is controlled in tokens. Minimum relevance takes effect only in semantic retrieval or when result reranking is used. Retrieval or a form does not constitute an authorisation to execute.
Configuration and implementation checks
Hypothetical drill sample: the source text for comparison reads, "Supplier A submitted an incoming record for batch number B20250301 on 1 March 2025, quantity 200 units, status pending quality inspection. This batch corresponds to purchase order PO-2025-0301, which states a delivery date of 10 March 2025." A draft sentence to be judged reads, "This batch has completed quality inspection and been put into storage." This sample is used only for the checks on this page and does not refer to a real entity.
| Configuration item | Hypothetical starting point for this drill | Reason and comparison method |
|---|---|---|
| Chunking method | Split by order number and batch number | Compare whether the correspondence between order number and batch number is preserved after chunking |
| Number of vector indexes | One vector per chunk | Compare whether retrieval results still contain the original chunk after adding indexes |
| Search mode | Hybrid retrieval | Compare whether semantic and full-text recall both cover number-type queries |
| Reference limit | Set to 2000 tokens as the hypothetical starting point for this drill | Compare whether returned content fully contains the condition sentence under different limits |
| Minimum relevance | Set to 0.3 as the hypothetical starting point for this drill | Compare whether filtering removes unrelated fragments while keeping the relevant chunk |
| Post-update review | Check training state after a material change | Compare the difference between a successful upload and an actual retrieval update |
Three common errors
- Treating a successful upload as proof that retrieval has updated. The input is a changed supplier qualification file; the comparison is between the upload time and the content returned by retrieval; the observable result is whether the returned content is still the old version. Without checking the training state, retrieval may still point to the old index.
- Splitting a condition away from what it constrains during chunking. The input is a batch record containing the status "pending quality inspection"; the comparison is whether the status field stays in the same chunk as the quantity and batch number; the observable result is whether retrieval returns a fragment missing the status.
- Treating a retrieval result as the basis for authorisation. The input is a retrieval request for a purchase order; the comparison is between the returned content and the approval status field; the observable result is whether an order still under review is misread as approved. Retrieval does not perform permission filtering, and a pending review does not demonstrate that operating permission is absent.
How to verify the setup
- Input the hypothetical source text above together with the draft sentence "This batch has completed quality inspection and been put into storage." Compare the status field "pending quality inspection" in the source with the "completed quality inspection" claimed in the draft. Observe whether the two conflict. If the status field values are explicitly mutually exclusive, the draft sentence is unsupported.
- Input batch number B20250301 for full-text retrieval. Compare whether the returned content contains that number and the corresponding status field. Observe whether a number-type query is matched. If it is not matched, check whether chunking preserved the same-chunk relationship between the number and the status.
- Input purchase order PO-2025-0301 and the delivery date 10 March 2025. Compare the delivery date stated in the order with the actual date field in the batch record. Observe whether the two agree. If the batch record does not state an actual storage date, this item remains to be verified and the evidence gap is preserved.