What the documents look like
On-demand retail fulfillment processes online orders at minute-level cadence, one order at a time. The materials relevant to cross-border reference and multilingual retrieval are immediate orders, picking lists, out-of-stock reports and delivery exception forms. These documents are generated per order, and within one order the picking list, the out-of-stock report and the delivery exception form exist as separate materials. Parsing and chunking must preserve the document identity and version that allow a retrieved fragment to be traced back to its source.
Some materials may be submitted by cross-border stores in a language other than Chinese. Semantic retrieval has documented cross-language understanding: a Chinese question can match an English knowledge point, and this depends on the vector model. Full-text retrieval depends on keyword hits. These two recall paths place different requirements on how one material is split.
Constraints at the document chunking step
Chunking must follow the actual structure of each material type. Conditions, explanations and the content they constrain cannot be separated across chunks. A longer passage can be given multiple vectors, and one set of source data can correspond to multiple vectors; during retrieval, a hit on any one of those vectors recalls that set of source data.
Source data and retrieval index are distinct. In MongoDB, the dataset.datas table stores the source data of vectors, and the indexes field records the corresponding vector IDs. Semantic retrieval and result reranking produce relevance scores. A relevance score does not perform permission filtering or entity isolation, and retrieval itself does not constitute authorization.
After a material changes, the actual training and index state must be checked. A successful upload does not mean retrieval has been updated.
Configuration and implementation checks
The following table lists documented settings or implementation check items relevant to this feature, organized around a hypothetical paper exercise sample. All values marked as a starting point are set for this exercise only and are not official defaults.
| Configuration or check item | Starting point for this exercise | Reason and comparison object |
|---|---|---|
| Search mode | Semantic retrieval | The sample contains multilingual materials; compare semantic retrieval against full-text retrieval on the same term |
| Reference limit | A tokens value set for this exercise | This parameter controls referenced content by tokens; compare stability against counting chunks as top k |
| Minimum relevance | A 0-1 value set for this exercise | This value takes effect only under semantic retrieval or result reranking; compare against the recall range with no threshold |
| Result reranking | Enabled or not according to settings | Reranking requires a model; compare ordering with and without it |
| Chunk completeness | Checked paragraph by paragraph against material structure | Verify whether a condition and the content it constrains stay in one chunk; compare against the recall result after separation |
| Index state after update | Check actual training and index state | Compare against confirming only that the upload succeeded |
Three common errors
- Treating a successful upload as an updated retrieval index. Input is a changed picking list; compare the upload record against the actual training and index state, and observe whether retrieval still returns the previous version.
- Treating a relevance score as a permission filter. Input is a low-relevance out-of-stock report that belongs to the target store; compare the score against record ownership, and observe whether the record is misjudged as unauthorized because its score is low.
- Splitting a condition and the content it constrains into different chunks. Input is the original text of an out-of-stock report containing a substitution condition; compare the chunk result against the original structure, and observe whether the recalled content lacks the constraint after the condition becomes a separate chunk.
How to verify the setup
Hypothetical paper exercise sample. The source text is three sentences: "This order is an immediate order for cross-border store A, and the picking list contains two items." "Store A reports the second item out of stock and requests substitution with an item of the same specification." "This substitution request is still awaiting confirmation by the store duty staff, and substitution is not executed before approval." The draft sentence to be judged is: "Store A's substitution request has been approved, and picking may proceed according to the substituted list."
- Verification one: Input the three source sentences above and the draft sentence; compare "still awaiting confirmation, not approved" against "has been approved." The draft sentence does not match the source status, so the condition is not satisfied and the item is recorded as unsupported.
- Verification two: Input the second and third source sentences; compare the substitution request against the approval status, and observe whether the two sentences are recalled as one group after chunking. Separation of the condition from its constraint does not satisfy the condition.
- Verification three: Input a changed picking list; compare the upload record against the actual training and index state, and observe whether the retrieved content matches the changed source text. Upload success alone with an unchanged index does not satisfy the condition.
All of the above are paper checks and do not indicate that testing has been performed. An empty-result scenario can be checked against a downstream design using the explicit paper input []; this does not support a claim that a particular rule necessarily returns an empty result. Libraries built on different vector models cannot be associated together; check the identifier first, exclude those that do not match, and record the actual observation.