What the documents look like
Wholesale market stall trading runs on on-site price negotiation and consigned shipping, so the working papers are fragmented and uneven. The everyday set includes purchase receipts, handwritten sales slips, stall lease contracts, and payment receipts. Stall owners, buyers, and shipping parties hand work over frequently, and most material survives as paper or a photograph, with fields completed to varying degrees. Retrieval has to gather these papers by knowledge base so that authorization status at handover can be quoted accurately. Retrieval itself does not change any authorization status.
Constraints at the retrieval step
The knowledge base search node can associate one or more knowledge bases that use the same vector model. Knowledge bases built on different vector models cannot be associated together. The output is an array of references and its length can be 0, so the output path still runs when nothing is retrieved. The minimum relevance value takes effect only in semantic retrieval or when result reranking is used; it is a filtering threshold and does not perform permission or entity isolation. The reference cap is measured in tokens and controls how much content each search cites. Question optimization performs coreference removal and question expansion, and it adds one model call before retrieval.
Hypothetical drill sample: a photocopy of a stall lease contract between a stall owner and a buyer states "Lessor: Stall A; Lessee: Buyer B; lease term: 1 March 2024 to 28 February 2025; monthly rent: 3000 yuan; signing date: 20 February 2024." The same batch contains a handwritten sales slip stating "10 April 2024, 30 boxes shipped, payment outstanding." A draft handover sentence awaiting review reads: "Buyer B's stall use permission for April 2024 continued because the contract took effect; retrieving this contract confirms it." That draft sentence merges two separate facts. The contract records a lease term; it does not state the operational permission status for April 2024. The outstanding payment does not show that the lessee lost stall use rights. Retrieving the contract returns the contract text only, and cannot return a conclusion that permission continued.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this page | Reason and comparison method |
|---|---|---|
| Associated knowledge bases | Stall lease contract base, sales slip base | The two bases can be associated only if they use the same vector model; check the vector model identifier first and exclude those that do not match |
| Search mode | Hybrid retrieval | Contract numbers and dates sit alongside natural language questions; compare semantic and full-text recall results |
| Reference cap | Hypothetical trial starting point of 2000 tokens for this page | Contracts and sales slips differ greatly in length; compare whether content stays complete using long and short actual material, then adjust |
| Minimum relevance | Hypothetical trial starting point of 0.4 for this page | Label relevant and irrelevant samples first, then adjust the threshold; the value takes effect only in semantic retrieval or result reranking |
| Question optimization | Enabled | Handover follow-up questions often contain references; compare the original question with the optimized question and check whether the subject was altered |
| Result reranking | Enabled according to configuration | Reranking requires a model and must be enabled in configuration; rerank scores can be used for filtering |
Three common errors
- Treating contract text returned by retrieval as a permission decision. The contract records a lease term, and retrieval can only return that passage. Whether permission continued requires separate checks against authorization material; retrieval does not execute authorization.
- Treating minimum relevance as an entity or permission filter. The value is a filtering threshold and does not exclude unrelated businesses or unauthorized records. A similarity setting does not provide isolation.
- Treating a handover request awaiting review as approved. Pending review does not show that operational permission is missing, and it does not show that authorization was granted. A status that is not recorded remains to be verified.
How to verify the setup
- Enter the hypothetical contract text above together with the draft sentence. Compare the returned content with the contract text. The condition is met when the returned content contains the contract text and no conclusion that permission continued. Record an exception when the returned content contains a statement that permission continued.
- Enter the hypothetical handwritten sales slip text above. Compare whether the retrieval result contains the field "payment outstanding." The condition is met when that field is present and no permission change conclusion is attached. Record the item as pending verification when the field is not returned.
- Use a clearly paper-based empty input array to check the downstream design. Compare whether the downstream node continues to execute on an empty reference. The condition is met when the downstream path runs and no fabricated reference is produced. Record the behavior as unsupported when a system error or an automatic business action appears.
A retrieval pass is not authorization. The same-vector-model requirement for associated knowledge bases does not extend to business registration sites or other external systems. Optional paths in the overall retrieval flow do not all run on every request: image retrieval requires an image input and the corresponding model capability, and reranking requires a model enabled in configuration. Where material does not record a status, that gap stays a gap.