What the documents look like
Daily Tmall flagship store operations produce a document set that includes product listing pages, brand authorization letters, dispatch commitment records and after-sales work orders. A brand authorization letter normally states the authorizing party, the authorized store, the authorized product scope and the validity period. Product listing pages carry category, attribute and commitment information. Dispatch commitment records and after-sales work orders are produced per order, with the brief describing their update frequency as daily or per order.
Cross-border material and multilingual retrieval requires these materials to be split at ingestion into fragments that can be traced back to the source text. Chinese questions and English materials are matched through vector semantics, which the official documentation describes as cross-language understanding under semantic retrieval.
Three industry facts shape this page. Authorized scope, validity period and authorized party in an authorization letter form one semantic unit, so chunking that separates a condition from what it constrains leaves a retrieved fragment without its basis for judgement. A single group of source data can map to multiple indexes, and a shorter, more precise index raises retrieval precision while narrowing retrieval range. Full-text retrieval suits numbers, model designations and proper nouns, while semantic retrieval suits natural-language and cross-language questions. Retrieval is a lookup action and does not perform authorization judgement.
Constraints at the document chunking step
The authorization scope, validity period and authorized party of an authorization letter belong to one semantic unit. If chunking splits the condition from the content it constrains, a retrieved fragment lacks the basis for judgement. The category and attributes on a product listing page, and the time-limit wording in dispatch commitments, likewise need to stay complete.
The official documentation states that one group of source data can correspond to multiple vectors, and that retrieval recalls a vector first, then locates the source content in MongoDB by vector ID; when several vectors map to the same source data, the results merge and the highest score is taken. Reducing the content of an index raises retrieval precision but sacrifices some retrieval range, which suits scenarios with strict answers.
Full-text retrieval suits numbers, model designations and proper nouns. Semantic retrieval suits natural-language and cross-language questions. Hybrid retrieval uses both and merges them through RRF. Rerank produces a score between 0 and 1 that represents the relevance of retrieved content to the question, and this score is usually more precise than a vector score and can be used for filtering. The minimum relevance setting applies only under semantic retrieval or when result reranking is used, and it is a filtering threshold rather than a final ordering rule. The reference cap limits each search to at most n tokens of content.
A hypothetical paper test case follows. The source text for comparison is: "Party A authorizes Party B on 1 January 2025 to sell Category A goods in the Tmall flagship store, with an authorization validity period ending 31 December 2025; the authorized scope excludes Category B goods." The draft sentence to be assessed is: "Party B may sell Category B goods in this store until 31 December 2025." The subject, object and period in this draft sentence can all be compared against the source text, and the authorized scope explicitly excludes Category B.
Configuration and implementation checks
| Configuration or check item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Search mode | Hybrid retrieval | The authorization letter contains party names and dates, requiring semantic and keyword recall together |
| Reference cap | Hypothetical starting point of 3000 tokens | A starting point for this exercise only; compare against the actual length returned by retrieval and adjust |
| Minimum relevance | Hypothetical starting point of 0.3 | A starting point for this exercise only; compare against the actual score distribution of returned fragments |
| Question optimization | Enabled for multi-turn follow-up questions | A single clear question can be compared with it disabled, comparing the returned differences between the two settings |
| Result reranking | Enabled when candidates are numerous | Requires a rerank model; compare ordering before and after reranking |
| Chunking check | Split by authorized scope and validity period | Check whether the condition and the content it constrains remain in the same fragment |
The reference cap uses tokens rather than top k, because in a mixed knowledge base the chunk lengths differ greatly and top k results become unstable. The minimum relevance value is a filtering threshold, not a final ordering rule. Enabling question optimization adds one model call before retrieval, which usually improves multi-turn retrieval but also increases overall latency. Image retrieval requires image input and a model with the corresponding capability, and reranking requires a rerank model that is enabled by configuration. These optional paths in the overall retrieval flow are not executed on every request.
Three common errors
- Splitting the validity period and the authorized scope of an authorization letter into different chunks. A retrieval hit on the validity period fragment then lacks the scope constraint, and the draft sentence exceeds the authorized object. Check: input the two source sentences, compare whether the returned fragment contains the party, the object and the period together, and observe whether a fragment containing only the date appears.
- Treating a retrieval result as an authorization conclusion. Retrieval returns relevant fragments only; whether authorization holds requires manual comparison against the source text. Check: input the draft sentence, compare the returned content against the authorized scope field in the source text, and observe whether an output treating Category B goods as sellable appears.
- Treating a successful upload as an updated index. After material changes, the actual training and index state needs to be checked. Check: input the changed term, compare whether retrieval still returns the old fragment, and observe whether old and new content appear together.
How to verify the setup
- Verification one: input the hypothetical authorization letter source text and the draft sentence, compare the authorized object in the draft sentence against the authorized scope field in the source text. If the returned fragment clearly shows the scope excludes Category B, the draft sentence is judged unsupported by the source text. If the returned fragment omits the scope field, record it as an evidence gap.
- Verification two: use the Category A goods name as the retrieval term, compare whether the returned fragment contains the authorized party and the validity period. If the fragment contains the party, the object and the period together, chunking is treated as preserving semantic completeness. If only the date is returned, record chunking as pending adjustment.
- Verification three: use an empty array as a paper input to check the downstream design, and observe how the downstream handles content with no references. Do not claim that a retrieval of fictional rules necessarily returns an empty result. Libraries across different vector models cannot be associated together; check the model identifier first and exclude those that do not match, without running a cross-model retrieval to compare missed recalls.
The authorization status of materials, operations and requests during operational handover cannot be treated as executed by retrieval or by a form. A pending review does not show a lack of operating authority, and an unsigned termination is not a completed termination. Where the source text does not state a field, the value remains unknown and the evidence gap is preserved.