What the documents look like
Marketplace promotion enrollment and price management turns on price, inventory and campaign rhythm. The working materials are the campaign enrollment form, the promotional price approval sheet, the inventory lock table and the campaign review sheet. Document comparison for contracts and transaction materials checks whether the same subject, the same period and the same field carry consistent values across these materials. Historical transaction prices and the promotional price approval sheet commonly differ in field definitions, and the quantity ranges in the inventory lock table against the campaign enrollment form need item-by-item checking. Retrieval references should keep document and field traces so each item can be compared. Data updates weekly or per campaign, so version timeliness matters at retrieval time.
A hypothetical paper exercise sample is used throughout this page. On 10 June 2025 a marketplace campaign operator submits a promotional price approval sheet reading: "Subject: a brand flagship store; Object: summer campaign; Promotional price: 199 yuan; Validity: 15 June 2025 to 20 June 2025; Status is pending review." A separate inventory lock table reads: "Subject: a brand flagship store; Object: summer campaign; Locked quantity: 500 units; Lock period: 15 June 2025 to 20 June 2025." The draft sentence to be judged is: "The brand flagship store's summer campaign promotional price has been approved and inventory has been locked." Comparison requires checking the approval sheet status field against the draft's "has been approved", and checking whether the lock period and the campaign period fall in the same range.
Constraints at the retrieval step
The knowledge base search node can associate one or more knowledge bases that use the same vector model. Bases using different vector models cannot be associated together; identify the model and exclude non-matching bases first. Semantic retrieval relies on vector distance, full-text retrieval relies on keyword hits, and hybrid retrieval merges the two result paths through RRF. The minimum relevance value takes effect only under semantic retrieval or when result reranking is used; it is a filter threshold and does not perform permission or entity isolation. The reference limit is measured in tokens and controls how much content each search returns. When question optimization is enabled by configuration, it performs coreference resolution and question expansion and adds one model call. Image retrieval requires corresponding image input and model capability, and reranking requires a model and must be enabled by configuration. An empty result is output as an array whose length can be 0, and the downstream chain still runs.
Configuration and implementation checks
| Configuration item | Setting for this page | How to check |
|---|---|---|
| Associated knowledge bases | Select bases containing the campaign enrollment form, promotional price approval sheet and inventory lock table; confirm each base uses the same vector model | Inspect the vector model identifier of each base; exclude those that differ |
| Search mode | Use full-text or hybrid retrieval for status words such as "pending review" and "approved" | Test with the status words in the sample and observe whether the approval sheet text is hit |
| Reference limit | For this exercise, a starting value of 2000 tokens, chosen to compare reference completeness across two materials | Measure segments with the selected model first, then compare against 1000 and 3000; no length measurement exists yet |
| Minimum relevance | For this exercise, a starting value of 0.5, chosen to compare against lower and higher thresholds | Label relevant and irrelevant segments first, then check retained and filtered results; activity and permission are checked separately |
| Question optimization | Enable for "the brand flagship store's summer campaign promotional price has been approved" to complete subject and object | Compare whether the optimized question keeps the original subject and campaign name |
| Result reranking | Enable when candidate results are numerous, using rerank scores to assist ordering | Observe whether the rerank score places the approval sheet text ahead |
Three common errors
- Treating a pending-review status as approved. In the sample the approval sheet status field reads "pending review" while the draft sentence says "has been approved"; the two values are mutually exclusive in the same field and form a contradiction. To check, input the approval sheet text and the draft sentence, compare the status field, and observe whether "pending review" and "has been approved" appear together.
- Treating a retrieval hit as authorized execution. Retrieving the approval sheet text does not mean approval is complete, and does not mean the inventory lock has been executed. To check, input the retrieval result and the business action record, compare whether an independent record of completed approval or inventory lock exists, and observe whether only a retrieval result appears with no execution evidence.
- Associating bases that use different vector models. If candidate bases use different vector models, exclude non-matching ones before association. To check, input the vector model identifier of each base, compare whether they match, and observe whether bases with differing identifiers are selected at the same time.
How to verify the setup
- Input the approval sheet text and the draft sentence from the sample, compare the status field values, and observe whether the contradiction between "pending review" and "has been approved" is identified. The expected result is that the contradiction is identified and marked for verification.
- Input the sample inventory lock table and promotional price approval sheet, and check the subject, campaign name and period in both materials. Both texts name the flagship store's summer campaign and 15 to 20 June, so the periods match; the price approval status remains pending review and is recorded separately.
- Use an explicit paper input of an empty reference array [] to check the downstream design, examining whether a branch handles empty results. This checks design only; it does not claim execution, and does not presume a real query must return an empty array.