Wholesale stall trading: retrieval for after-sales questions

Review retrieval for after-sales questions in Wholesale stall trading. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

Wholesale market stall trading is fragmented. Prices are negotiated in person, and goods move by consignment. The records for one deal are rarely kept in one place. Purchase slips, handwritten sales notes, stall lease contracts, and payment receipts each sit with a different person or in a different stack. A single buyer may collect goods in several trips and pay in several installments, so a fulfilment or after-sales question usually comes down to three things: which slip this batch of goods belongs to, whether the balance is settled, and who arranged the consignment.

Documents update daily or per order. That frequency does not change how retrieval is configured. Handwriting, abbreviations, and spoken agreements make wording differ from buyer to buyer, which affects semantic matching. Receipts and sales notes are often stored apart, so matching them depends on an order number or a date used in full-text search. A stall lease contract and a single transaction are different objects. Retrieval must not treat a lease contract as evidence for one order's fulfilment.

Constraints at the retrieval step

The knowledge base search node can link one or more knowledge bases that use the same vector model. Knowledge bases with different vector models cannot be linked together. Check each base's vector model identifier first, exclude those that do not match, and do not run a cross-model search to compare missed recalls. Referenced content is returned as an array, and its length can be zero, meaning the downstream chain still runs when nothing is found.

Minimum relevance applies only under semantic retrieval or when result reranking is used. It is a filter threshold. It does not act as a permission or entity boundary. The same-vector-model requirement for linked bases does not extend to external systems such as business registration sites. RRF is the fusion step for mixed retrieval results, not a switch. Image retrieval requires an image input and the corresponding model capability. Reranking requires a model and must be enabled by configuration. Optional paths in the overall flow diagram do not mean every request runs all of them.

Hypothetical paper test case: the source material reads, "On 12 March 2025, stall A issued handwritten sales note S-0312 to buyer Jia for 80 spring coats, with the balance of 4,000 yuan agreed to be settled within seven days of pickup; on the same day receipt R-0312 recorded receipt of a 1,000 yuan deposit." The proposed sentence to assess is, "Buyer Jia settled the full amount of S-0312 on 12 March 2025." This sentence conflicts with the 1,000 yuan deposit recorded on receipt R-0312 on the same field, and is unsupported.

Configuration and implementation checks

Configuration itemHypothetical starting point for this trialReason and comparison method
Linked knowledge basesLink only the stall trading base that uses the same vector modelCheck each base's vector model identifier first, exclude mismatches, and do not run cross-model retrieval
Search modeTest semantic retrieval first, then full-text retrievalUse the sample question to observe hit differences between order number S-0312 and a natural-language phrasing
Reference limitStart at a token amount that can hold one sales note plus one receiptTest with materials of different lengths to see whether content stays complete, then adjust the limit
Minimum relevanceStart at a middle valueLabel relevant and irrelevant samples first, then compare results before and after filtering
Question optimizationOff first, then on for follow-up questionsCompare the original question with the optimized question to check whether the subject was altered
Result rerankingNot enabled firstWith a model available and enabled by configuration, compare the rerank score with the vector score

These values are hypothetical starting points for this trial, not official defaults.

Three common errors

  1. Treating a retrieval hit as authorization or proof of settlement. The input is the proposed sentence, "Buyer Jia settled the full amount of S-0312 on 12 March 2025." Compare it with the 1,000 yuan deposit on receipt R-0312. The two values conflict on the same field, so the sentence is unsupported. Retrieval similarity does not change that conclusion.
  2. Linking knowledge bases that use different vector models. The input is two base identifiers with different vector model values. Compare the identifiers, exclude the mismatched base, and record what was observed. Do not infer missed recalls or redundant results from the linking attempt.
  3. Treating RRF as a switch that can be turned on, or treating the thinking budget as the reference token limit. The input is the node's parameter table. Compare field names with the documented descriptions. Neither item has a corresponding field.

How to verify the setup

  1. Input the sample source text and the proposed sentence. Compare the amount field on receipt R-0312 with the "settled" wording. When mutually exclusive values appear on the same field, judge the sentence unsupported and keep the evidence gap open.
  2. Input a pure image query together with a base configuration that has no vision model. Compare the stored index and the model capability, and observe whether the image path is skipped. Do not expect a first-hit guarantee.
  3. Input an explicit paper empty-result array []. Compare how the downstream node is designed to receive it, and check whether the empty chain runs. Do not claim that a fictional rule search always returns [].