What the documents look like
Dealer rebate calculation takes place after sales, and its core concerns are policy interpretation and financial treatment. The main data sources are ERP sales records, dealer remittances, contract ledgers and the finance system. The documents handled day to day are rebate policies, sales achievement statements, reconciliation statements and red-letter invoices. This page is limited to the inventory procurement and supplier materials task, at the vector model and index step. What matters here is whether these documents can be retrieved after they are stored, at what granularity indexes are built, and whether the model identifier is consistent when knowledge bases are associated.
The rebate calculation cycle is monthly or quarterly. That cadence does not change the retrieval behavior described on this page, so it is not expanded here.
Two features of this category shape the retrieval step. First, rebate conclusions depend on matching a policy threshold against an achievement rate and a reconciliation figure, so a retrieved reference must carry the subject, the period and the specific field, not only a topical match. Second, red-letter invoice numbers and dealer identifiers are exact strings, which behave differently from natural-language policy clauses in retrieval.
Constraints at the vector indexes step
Knowledge bases associated for retrieval must use the same vector model. The actual model and the input type are checked first. One original data block can be associated with multiple indexes, and the index content is checked separately from the original text content. Index content is best kept complete and focused; retrieval coverage and index length are weighed against the sample at hand. Image retrieval also depends on whether an image description or image vector was generated at storage time, and the query side alone does not determine this. After a model or index change, the same set of questions is used to compare against the cited original text, and vector scores alone do not support a claim about the result.
Hypothetical paper exercise sample: a brand finance reviewer is checking July 2024 rebates and stores three materials. Original text one: "July 2024 sales achievement statement, Dealer A, achievement rate 92%, return amount 30,000 yuan." Original text two: "July 2024 reconciliation statement, Dealer A, rebate due 80,000 yuan, red-letter invoice issued 20,000 yuan." Original text three: "Rebate policy clause 4: where the achievement rate is below 95%, 80% of the rebate due applies." Draft sentence to be assessed: "Dealer A's July 2024 rebate has been fully confirmed at 80,000 yuan." The subject, period and fields in this sentence can be compared against the three original texts, and the question is whether the original texts support it.
Configuration and implementation checks
| Configuration item | Setting or check | Relation to the sample |
|---|---|---|
| Associated knowledge base | Select rebate document bases that use the same vector model | The three materials must be stored under one model |
| Index building | Build separate indexes for policy, achievement and reconciliation | Allows retrieval by field |
| Search mode | Semantic or hybrid search; identifiers use full-text search | Red-letter invoice numbers and dealer identifiers suit full-text |
| Reference limit | Hypothetical exercise starting point: the token volume needed to cover all three materials, chosen because all three must take part in the comparison, against a smaller value covering only one material | Determines whether the cited content is complete |
| Minimum relevance | Hypothetical exercise starting point: 0.5, compared against a run with no threshold | Filters low-relevance fragments; it is not a permission filter |
| Result reranking | Used when a rerank model is available and enabled per the setting | Assists ordering when candidates are numerous |
Three common errors
- Associating knowledge bases that use different vector models. Input: two bases with different model identifiers. Compare the model identifiers. Observable result: when the identifiers do not match, exclude that base and do not run cross-model retrieval.
- Treating minimum relevance as a permission or entity filter. Input: a base containing Dealer A and Dealer B. Compare the recalled set before and after a threshold change. Observable result: the threshold changes relevance filtering only and does not exclude unauthorized records.
- Treating a retrieval hit as a confirmed rebate. Input: the draft sentence and the three original texts. Compare "fully confirmed" against policy clause 4's 80% rule. Observable result: the original texts do not support full confirmation; the claim is unsupported.
How to verify the setup
- Input original text one and the draft sentence. Compare the 92% achievement rate against the 95% threshold in policy clause 4. Observable result: the draft sentence is unsupported; record the evidence gap.
- Input original text two. Compare the rebate due of 80,000 yuan against the red-letter invoice of 20,000 yuan. Observable result: the two fields can be retrieved separately, and the cited content contains both original passages.
- Input a question containing no rebate field. Compare the returned result against an empty reference. Observable result: when the reference array length is 0, the downstream path still runs; do not claim that retrieval necessarily returns empty.
All of the above is paper checking. No actual retrieval, deployment or approval has been carried out.