What the documents look like
Fruit-store procurement draws on wholesale market pricing, supplier quotations, store sales and inspection reports. The working documents are purchase orders, acceptance sheets, pesticide-residue test reports and loss records, produced daily or per batch. In the store-service and internal-training task, these materials are retrieved to answer questions about acceptance grades, loss-registration conventions and how test reports are filed. Update frequency is high, and one batch may correspond to several documents, so retrieval has to separate batch, store and date scope.
The category differs from convenience-store prepared-food ordering: fruit buying depends more on wholesale market conditions and grade-based acceptance than on a headquarters standard menu.
Constraints at the retrieval step
The knowledge-base search node can associate one or more knowledge bases that use the same vector model; bases built on different vector models cannot be associated together. The node outputs cited content as an array, and the length may be 0, meaning the output path still runs when nothing is found. The minimum relevance value takes effect only under semantic retrieval or when result reranking is used; it is a filtering threshold and does not perform permission or entity isolation. Hybrid retrieval merges multiple result channels through RRF. Reranking requires a model and runs according to its settings. Image retrieval requires an image input and matching model capability, and does not execute on every request.
Hypothetical drill sample: a store fresh-produce supervisor submits an internal training document whose source text reads: "On 10 March 2025, Store A accepted a batch of apples, acceptance sheet number YS-0310, grade first-class, pesticide-residue test report number JC-0310, conclusion qualified." The proposed handover request reads: "Please retrieve and confirm the acceptance grade and test conclusion for this apple batch, for use as a training example." The request covers subject Store A, object the apple batch, date 10 March 2025, and the fields acceptance grade and test conclusion. The material does not state a loss record or a purchase order number; that part remains unsupported.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this trial | Reason for the choice and comparison method |
|---|---|---|
| Associated knowledge bases | Associate only the one base holding this store's procurement and acceptance material and using the same vector model | Check the vector model identifier first, and exclude bases on different models |
| Search mode | Use semantic retrieval and full-text retrieval together | Compare hit differences between number-type queries and natural-language queries |
| Citation limit | Set a hypothetical starting point that covers the complete acceptance-sheet and test-report passages in tokens | Test with actual material of different lengths to see whether content stays complete, then adjust |
| Minimum relevance | Take a hypothetical starting point at a middle value | Label relevant and irrelevant samples first, then compare filtered results |
| Question optimization | Enabled | Compare the original question with the optimized question and check whether the subject was altered |
| Result reranking | Enabled according to settings | Compare candidate ordering before and after reranking, and confirm question completeness |
Three common errors
- Treating minimum relevance as a permission or entity filter. Input a cross-store query, compare whether returned content includes records from a non-authorized store, and observe whether unrelated store data still appears. A relevance score does not enforce permission isolation.
- Forcing knowledge bases on different vector models into one association. Input two knowledge-base identifiers on different vector models, compare whether they are allowed to be selected together, and observe whether the association is rejected. The documentation states that only knowledge bases on the same vector model can be associated.
- Treating a pending handover request as already approved and executed. Input the proposed handover request, compare whether a signature or approval record exists, and observe that authorization evidence is absent. A pending review does not demonstrate that operating permission has been granted.
How to verify the setup
- Input the hypothetical sample source text and the proposed handover request, compare whether the retrieved acceptance grade and test conclusion match the source text, and observe whether the cited content contains the fields corresponding to YS-0310 and JC-0310. The expectation is consistency; no live test is claimed.
- Input a cross-store query, compare whether the returned results include records from a non-authorized store, and observe whether the minimum relevance setting is being mistaken for a permission filter. The expectation is that relevance does not carry permission isolation, and authorization scope must be checked separately.
- Input an empty-result case, compare whether the output citation array is [], and observe whether the downstream path still runs. The documented condition is that the length may be 0; no claim is made that a fabricated rule search must return [].