What the documents look like
Regional dealer stock replenishment runs as a daily rolling order flow, which differs from seasonal centralized ordering events. The working documents are replenishment requests, inventory turnover sheets, outbound delivery notes and payment collection plans, updated weekly or monthly. They arrive from dealer ERP systems, brand ordering systems, warehouse stock records and sales collection records, and they are continuous in time while scattered in origin. Brand channel managers and sales back-office staff must reconcile records across those sources.
For document parsing and chunking, this means one replenishment file often carries the requested quantity, the current stock position and the payment arrangement together. Parsing must preserve the document identity and version that allow a chunk to be traced back to its source text, and chunking must avoid separating a constraint from the content it constrains. After a document is updated, a successful upload does not mean retrieval has been updated; the actual training and index state needs a separate check.
Constraints at the document chunking step
This page covers document parsing and chunking only, for the inventory procurement and supplier materials task. Retrieval involves three levels: library, collection and data. The smallest search unit is the library; collections serve classification management only. One data group can map to multiple vectors, held in the indexes field as an array. Vector source data is stored in MongoDB under dataset.datas, and the vector itself is stored in the PostgresSQL vector field.
Semantic retrieval relies on vector distance, full-text retrieval relies on keyword hits, hybrid retrieval merges multiple result paths through RRF, and Rerank reorders candidate text. The minimum relevance score takes effect only in semantic retrieval or when result reranking is used; it is a filter threshold and does not perform permission or entity isolation. A same-vector-model requirement for a retrieval library applies only within that retrieval scope and cannot be extended to external systems.
Hypothetical exercise sample: the source material for checking consists of three sentences. "Replenishment request number BC-2025-0417, requesting party a dealer in the East China region, request object replenishment quantity of 200 units of model A, request date 17 April 2025." "This dealer's April 2025 inventory turnover sheet shows closing stock of 80 units of model A and turnover days of 12." "The payment collection plan states that this dealer owes 150,000 yuan for April 2025, with collection planned before 30 April." The draft sentence to be assessed is: "This dealer's model A replenishment request has been approved by the brand, and shipment will occur on 25 April." That draft asserts two facts, approval and shipment, which the material does not state.
Configuration and implementation checks
| Configuration or check item | Hypothetical starting point for this exercise | Reason and comparison object |
|---|---|---|
| Search mode | Hybrid retrieval | Replenishment material contains model codes and numbers, needing both keyword and semantic coverage; compare recall scope against semantic retrieval alone |
| Minimum relevance score | Hypothetical starting point 0.3 | Used to filter low-relevance fragments; compare against 0.5 to observe whether irrelevant fragments decrease |
| Reference limit | Hypothetical starting point 2000 tokens | Upper bound on referenced content per search; compare against 1000 tokens to observe whether references cover complete clauses |
| Question optimization | Not enabled for now | Replenishment questions usually have a clear subject; enabling adds one model call, so compare elapsed time against the enabled state |
| Segmentation completeness check | Check separately by replenishment request, turnover sheet and payment plan | Verify whether a condition and the content it constrains stay in the same segment; compare trace-back quality against unsplit whole documents |
| Post-update recheck | Check training and index state after material changes | A successful upload does not mean retrieval has updated; compare retrieval results against those before the change |
Three common errors
- Treating "has been approved, will ship on 25 April" in the draft sentence as a fact stated in the material. The material states only the request number, quantity, stock position and payment plan; approval and shipment do not appear. The check compares the draft sentence against the source text and leaves unsupported parts as pending verification.
- Treating the minimum relevance score as a permission or entity filter. That value is a filter threshold affecting only result selection after semantic retrieval or reranking. Isolating different dealers' materials requires a separate check of retrieval scope and access permissions, not a similarity setting.
- Treating a successful upload as retrieval having updated. After a material change, the actual training and index state must be checked by comparing retrieval results for the same question before and after the change; until that check, the state remains unknown.
How to verify the setup
- Input the three source sentences and the draft sentence from the hypothetical sample, and compare whether the draft contains approval and shipment statements absent from the source. If the draft shows "has been approved" or "will ship on 25 April," it exceeds the source basis and should be marked pending verification.
- Search using "BC-2025-0417," "model A" and "replenishment request" separately, and compare whether returned fragments retain the request number, model and requested quantity. If a fragment lacks the number or quantity, segmentation has not preserved the complete constraint and chunking needs adjustment.
- After a material change, run the same question once before and once after, and compare whether returned content reflects the new version. If both results match and neither contains the changed content, the index has not updated and the training state needs checking. An empty result can be checked against an explicit paper input
[]to verify downstream design, without claiming that a fictional rule search necessarily returns an empty array.