Complaints and official replies: retrieval for document comparison

Review retrieval for document comparison in Complaints and official replies. Check sources, input boundaries, error handling and repeatable test evidence.

What the documents look like

Complaint and regulatory reply work draws on the 12315 platform, platform complaint centers, customer service chat logs, and the order system. The people handling it are customer service supervisors, legal and compliance staff, and store owners. Compared with after-sales repair or reshipment categories, this work faces a platform or a regulator, so it depends on formal evidence and rectification language. An error can lead to an administrative investigation, a platform penalty, or reputational fallout. The everyday documents are complaint tickets, regulatory inquiry letters, order evidence, and rectification reports. The most time-consuming steps are reconstructing the transaction, assembling the evidence package, and submitting the rectification reply. These materials update irregularly, case by case.

For retrieval and recall, this means comparison has to stay within one case, one transaction party, and one field definition. Retrieval returns reference content by input question. It does not perform permission or entity isolation, and a similarity score is not a business entity filter. The knowledge base search node can link one or more knowledge bases that use the same vector model; bases with different vector models cannot be linked together. The output references are an array, and the length can be 0, so the downstream path still runs when nothing is found. Search modes are semantic search, full-text search, and hybrid search, and hybrid search merges results through RRF. The minimum relevance value takes effect only in semantic search or when result reranking is used. The reference cap is measured in tokens. Question optimization performs coreference resolution and question expansion and adds one model call. Image retrieval and reranking are optional paths that require the corresponding input and model capability. A retrieval result does not constitute proof of authorization, approval, or contract effectiveness.

Hypothetical paper test case: a store receives a complaint ticket forwarded from 12315. The complainant states that order A was signed for on March 5, 2025, and no invoice was received. The order evidence text reads: "Order A, buyer Zhang, order date March 1, 2025, signed date March 5, 2025, invoice status: not issued." A customer service handover request draft sentence reads: "The invoice for this order has been issued and mailed; please reply to the regulator on this basis." The question to decide is whether that draft sentence agrees with the order evidence text. The source text does not state an invoicing time, a mailing record, or an authorized reply person, so those facts remain unsupported.

Constraints at the retrieval step

The search node links knowledge bases that share one vector model. Linking across different vector models is not available, so the vector model identifier of each base is checked first and non-matching bases are excluded before any retrieval is run. The complaint ticket base and the order evidence base in this case are assumed to use the same vector model.

Search mode selection depends on the material. Complaint materials mix case numbers and natural language, so semantic recall and full-text recall can run in parallel through hybrid search. Full-text search suits exact numbers, model codes, proper nouns, and error codes. Semantic search suits natural language questions and semantically close content. Hybrid search merges both through RRF, and RRF is a fusion process inside hybrid search rather than a separate switch. The minimum relevance value is a filter threshold, not a final ordering rule, and it applies only in semantic search or with reranking. The reference cap limits how many tokens of content are cited per search. Question optimization runs before retrieval and adds a model call; it helps with multi-turn follow-ups that contain references, and it can be compared against the original question to check whether the subject was altered.

Image retrieval is not a separate capability outside the knowledge base search chain. It requires an image input and a model that supports image description or image vectors. Reranking requires a rerank model and is enabled according to settings. Neither path runs on every request. A retrieval hit is not an authorization, an approval, or a completed business action. A pending review status is not evidence that an operator lacks reply permission. An offered option is not execution, and an unsigned termination is not a completed termination.

Configuration and implementation checks

Configuration itemSetting on this pageNote
Linked knowledge basesComplaint ticket base, order evidence baseBoth bases use the same vector model; bases with different vector models are not linked together
Search modeHybrid searchComplaint materials contain case numbers and natural language, so semantic and full-text recall run in parallel
Reference capHypothetical trial starting point of 800 tokensEvidence paragraphs vary in length; compare against 600 and 1000 for content completeness
Minimum relevanceHypothetical trial starting point of 0.5Label relevant and irrelevant samples first, then compare against 0.4 and 0.6 for filter effect
Question optimizationEnabledMulti-turn follow-ups contain references; compare the original question with the optimized question to see whether the subject was altered
Result rerankingEnabled when a model is availableRerank score is 0-1 and is used for filtering candidate text according to settings

Three common errors

  1. Treating a retrieval hit as granted authorization. Error: the recalled order evidence is used directly in a regulatory reply without checking the reply person's authorization status. Check: input the handover request draft sentence, compare it with the order evidence text, and observe whether "issued" and "not issued" appear as mutually exclusive values in the same field. The source text does not state an invoicing record, so the draft sentence is unsupported and the evidence gap is kept.
  2. Treating a pending review as missing operating permission. Error: when the ticket is in pending review status, the operator is judged to have no reply permission. Check: input the ticket status field, compare the status value with the permission record, and observe whether an explicit grant or denial field exists. When it is not stated, record it as pending verification.
  3. Linking knowledge bases across different vector models. Error: two bases that use different vector models are linked together and retrieval is run. Check: input the vector model identifier of each base, compare whether the identifiers match, exclude the non-matching ones, and record the actual observation. Do not infer a run result from the mismatch.

How to verify the setup

  1. Input the order evidence text and the draft sentence. Compare "invoice status: not issued" with "has been issued and mailed," and observe whether the two are mutually exclusive on the same order and the same field. If the source text does not state an invoicing record, the draft sentence is judged unsupported and the evidence gap is preserved.
  2. Input the handover request. Compare whether the request states an authorized reply person and the scope of authorization, and observe whether an authorization field exists. When it is missing, record it as pending verification and do not treat the retrieval result as an executed authorization.
  3. Input a pure image query and a pure text query. Compare the output reference array lengths, and observe whether the image path did not run because the image input or model capability was absent. For an empty result, check the downstream design against the paper input []; do not claim that a fictional rule necessarily returns [].