Franchise fee settlement: retrieval for document comparison

Review retrieval for document comparison in Franchise fee settlement. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

Franchise fee and deposit settlement centres on money received and paid out, together with deductions for breach. The work does not cover government franchise filing. The main sources are the finance system, franchise contracts, bank statements and store violation records. Day-to-day materials include franchise fee invoices, deposit ledgers, deduction notices and contract payment schedules. These materials update monthly and on each deduction.

Contract-to-transaction comparison requires the same counterparty, the same period and the same field. A contract payment schedule and a bank statement must point to the same franchisee, the same instalment and the same amount field. Knowledge base retrieval in this setting returns the above materials as reference content for human comparison. Retrieval itself does not constitute authorisation and does not replace finance write-off.

Constraints at the retrieval step

The knowledge base search node can associate one or more knowledge bases that use the same vector model. Bases with different vector models cannot be associated together. Reference content is output as an array and its length can be zero, which means the output path still runs when nothing is retrieved.

Search parameters include semantic retrieval, full-text retrieval, hybrid retrieval, result reranking, reference limit, minimum relevance and question optimisation. Minimum relevance takes effect only under semantic retrieval or when result reranking is used; it is a filter threshold, not the final ranking rule. Hybrid retrieval merges multiple result paths through RRF, and RRF is a fusion process with no corresponding switch. Image retrieval requires image input and model capability, and reranking requires a model and must be enabled by configuration. Neither runs on every request by necessity. Semantic recall and relevance scores do not carry permission or entity isolation, and the same-vector-model requirement for associated bases does not extend to external systems such as business registration portals.

Configuration and implementation checks

The settings below relate to a hypothetical drill sample and list only documented settings or implementation checks.

Configuration itemHypothetical starting point for this drillReason and comparison object
Associated knowledge basesAssociate only bases holding settlement materialsCheck the vector model identifier of each base first and exclude those that do not match
Search modeHybrid retrievalCompare recall differences against semantic retrieval alone and full-text retrieval alone
Reference limitHypothetical starting point of 1500 tokens for this drillTest content completeness using contract payment schedules and ledgers of different lengths
Minimum relevanceHypothetical starting point of 0.35 for this drillLabel relevant and irrelevant samples first, then compare filtering against 0.5
Question optimisationOff initiallyCompare with the enabled state to check whether the counterparty is altered incorrectly
Result rerankingNot enabled initiallyCompare candidate ordering with the enabled state; reranking requires a model and must be enabled by configuration

Three common errors

  1. Treating a retrieval hit as an authorisation or write-off basis. Retrieval returns reference content only; business write-off and authorisation require downstream implementation. The input is the retrieval result, the comparison object is the authorisation record, and the observable result is that no authorisation conclusion appears in the reference content.
  2. Treating minimum relevance as a permission or entity filter. It filters low-relevance results only. The input is the threshold and the candidates, the comparison object is all candidates, and the observable result is that records for unrelated counterparties can still be recalled.
  3. Treating RRF as a switch that can be turned on. RRF is the result fusion process of hybrid retrieval. The input is the multiple recall paths, the comparison object is a single path, and the observable result is that no such switch exists in the configuration interface.

How to verify the setup

Hypothetical drill sample: the source material reads, "Party A, XX Chain Management Co., Ltd., and Party B, a franchisee, signed a franchise contract in March 2024, agreeing that the franchise fee of 30,000 yuan is payable within ten days of signing and the deposit of 20,000 yuan is payable before opening." The proposed sentence reads, "Party B paid the franchise fee of 30,000 yuan in March 2024." The request to be judged reads, "Please confirm, based on the retrieved materials, that this franchise fee has been settled."

  1. Input the proposed sentence and the source material, compare the counterparty, the period and the field, and observe that the source material records no actual payment, so the proposed sentence is unsupported.
  2. Input the request to be judged, compare the retrieval result against the authorisation boundary, and observe that the reference content contains no settlement conclusion, so the request must be passed to manual checking against the bank statement.
  3. Input a query concerning the deposit ledger only, compare the returned references against the question, and observe that the reference content contains no conclusion about franchise fee payment, since deposit records cannot support a franchise fee judgement.

Paper-based empty-result check: use an explicit empty array as input to the downstream design and check whether the downstream treats it as no reference, without asserting that a fictional rule will necessarily return an empty array.