What the documents look like
Fruit-store procurement works from purchase orders, acceptance records, pesticide-residue test reports and shrinkage logs. The underlying data comes from wholesale-market quotations, supplier offers, store sales and test reports. Fruit buying depends on wholesale-market conditions and grade acceptance, and there is no head-office standard-meal wording that would give one shared vocabulary across stores. Grade judgments, quotation validity periods and acceptance conclusions for the same batch sit in separate materials. Materials update daily or per batch, so purchase and acceptance work depends on documents staying current and staying matched to the right batch. Product-information and selection questions need these materials organised into a searchable knowledge base that procurement staff and store fresh-produce supervisors can consult when checking a selection basis.
Constraints at the vector indexes step
In FastGPT a knowledge base is made of libraries, collections and data. The smallest search unit is the library; collections classify data and do not affect search results. Vector retrieval uses the PostgresSQL PG Vector extension with an HNSW index. MongoDB stores the original data, and the dataset.datas table holds an indexes field that records the corresponding vector IDs, so one data item can map to several vectors. Knowledge bases linked for retrieval must use the same vector model; check the actual model and supported input types first. Index content should be complete and focused, and retrieval coverage against index length has to be weighed against the sample at hand. Image retrieval also depends on whether image descriptions or image vectors were generated at ingestion, so the query side alone does not determine it. Semantic retrieval and the minimum relevance score are similarity filters; they do not perform permission or entity isolation. Whether a retrieval result can serve as an authorisation basis is decided by downstream business implementation.
Configuration and implementation checks
Hypothetical drill sample: a store fresh-produce supervisor submits a paper record whose original text reads, "On 10 March 2025, stall A supplied this store with 200 kg of mandarin oranges; the quotation is valid until 12 March 2025; acceptance record number YS-0310-02; pesticide-residue test report number JC-0310-07; conclusion: pass." The draft sentence to be judged reads, "This batch of mandarin oranges has completed acceptance and may be put on sale." The material states the acceptance record number and the test conclusion. It does not state an acceptance completion status or a listing authorisation, so the completion and authorisation wording in the draft is not supported.
| Configuration item | Hypothetical starting point for this drill | Reason and comparison method |
|---|---|---|
| Vector model | Matches the actual knowledge-base model | Linked knowledge bases must share one model; check identifiers one by one and exclude those that do not match |
| Index content | Chunked by purchase order, acceptance record, test report and shrinkage log | Compare against the sample text and confirm subject, batch and numbers are complete |
| Search mode | Hybrid search | Number-type queries rely on full-text recall; semantic recall supplements natural-language phrasing |
| Reference limit | Set in tokens | Compare against sample material length and observe whether references cover the key fields |
| Minimum relevance | 0-1 value; hypothetical starting point 0.4 for this drill | Compare against unfiltered results and observe whether low-relevance fragments are filtered out |
| Result reranking | ReRank enabled per configuration | Compare against unranked results and observe changes in candidate ordering |
Three common errors
- Linking libraries that use different vector models. Input: two knowledge bases whose model identifiers differ. Compare the model identifier fields and observe whether the mismatched one is excluded. Libraries on different models cannot be linked together; check identifiers only and record what is actually observed.
- Treating a semantic retrieval score as a permission or entity filter. Input: a high-similarity purchase record belonging to an unrelated store. Compare the retrieval result against the authorised scope and observe whether an out-of-scope reference appears. Similarity does not perform permission filtering.
- Treating a pending request as an approved execution. Input: a handover request reading "submit listing application." Compare the approval fields in the material and observe whether an approval record exists. Pending review does not demonstrate a lack of operating authority, and it is not approval.
How to verify the setup
- Input the hypothetical sample text and the draft sentence. Compare "has completed acceptance" and "may be put on sale" in the draft against the acceptance record number and test conclusion stated in the original, and observe whether the draft exceeds the original scope. The original does not state a completion status or an authorisation, so the finding is not supported.
- Input the purchase order, acceptance record and test report for the same batch. Compare subject, batch, date and number fields across the three materials and observe whether they point to the same object. Matching fields satisfy the check condition; missing fields are recorded as an evidence gap.
- Input one number query and one natural-language query. Compare the reference content returned under the two search modes and observe whether the number is hit by full-text recall and whether the natural-language phrasing is covered by semantic recall. For an empty result, check the downstream design against the paper input
[]; do not claim that a fabricated rule search necessarily returns[].