What the documents look like
Cold-chain receiving records are generated per delivery batch. Each batch carries a cold-chain temperature record, an arrival acceptance form, a rejection form and a supplier delivery note. These materials commonly exist in Chinese, English or the destination-country language at the same time, and within one batch the temperature record and the acceptance form may be held in different languages. The receiving step has to line up the arrival batch, the temperature range, the sampling conclusion and the rejection reason. A missing field in any one of them leaves later disputes without a basis. The brief states that these materials update per batch and per day; retrieval only needs to pull back the materials belonging to a given batch scope.
A hypothetical paper sample, labelled as such and not drawn from any real record: the arrival acceptance form reads "Batch number LC-2401, arrival date 12 March 2024, carriage temperature record range 2 to 6 degrees Celsius, sampling conclusion pass, acceptance status received." The rejection form for the same batch reads "Batch number LC-2401, rejection reason recorded as outer packaging damaged, handling status pending supplier confirmation." A draft sentence reads "Batch LC-2401 has completed rejection and is closed." Judging that draft sentence requires comparing the same batch and the same field: the rejection form handling status is pending supplier confirmation, which does not agree with "completed rejection and closed." The draft sentence is unsupported by the supplied material.
Constraints at the retrieval step
The knowledge base search node can associate one or more knowledge bases that use the same vector model. Knowledge bases built on different vector models cannot be associated together. Implementation first checks the vector model identifier, excludes those that do not match, and records what was actually observed; it does not run cross-model retrieval to compare missed recalls. Retrieval operates on the whole library. A collection is only a way of classifying data and has no bearing on search results. Cited content is output as an array whose length can be 0, so the downstream path still runs when nothing is found.
The minimum relevance value is a 0–1 number that filters out low-relevance results. It takes effect only in semantic retrieval or when result reranking is used. It is a filter threshold, not a final ordering rule, and it does not perform permission or entity isolation. RRF is the fusion step that combines results from multiple retrieval paths in hybrid retrieval; it is not described as a standalone switch. Image retrieval requires image input and the corresponding model capability. Reranking requires a rerank model and must be enabled according to settings. The optional paths shown in the overall flow diagram do not mean every request executes all of them.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this trial | Reason and comparison method |
|---|---|---|
| Associated knowledge base | Select one library that uses the same vector model | Check the vector model identifier first, exclude libraries that differ, then compare whether retrieved content covers the four material types for the batch |
| Search mode | Test semantic retrieval first, then hybrid retrieval | Compare retrieved content under each mode against the test question; do not presume one mode suits all materials |
| Citation limit | Hypothetical starting value 2000 tokens | This is a trial starting value; test with materials of different lengths to see whether content stays complete, then compare with adjacent values |
| Minimum relevance | Hypothetical starting value 0.4 | Label relevant and irrelevant samples first, then adjust the threshold and compare whether filtered citations still contain the needed fields |
| Question optimization | Enable for multi-turn follow-ups that contain references | Compare the original question with the optimized question and check whether the subject was altered; clear questions may leave it off |
| Result reranking | Enable when candidates are numerous and a rerank model is available | Compare ordering before and after reranking, filter by the rerank score, and confirm whether candidates are sufficient |
Three common errors
- Treating a retrieval hit as completed authorization. The input is the rejection form above with handling status pending supplier confirmation; the comparison object is the "received" acceptance status against the "pending supplier confirmation" handling status. Outputting a closure conclusion mixes retrieval with business authorization. Executable check: take the rejection form text, compare the handling status field value, and observe whether the output preserves the pending status.
- Associating knowledge bases that use different vector models. The input is two libraries with different vector model identifiers; the comparison object is the model identifier. Associating them and comparing recall counts goes beyond what the documents describe. Executable check: read each library's vector model identifier, exclude those that do not match, and record the actual observation without inferring a runtime result.
- Treating minimum relevance as an entity or permission filter. The input is a low-relevance acceptance record that belongs to another store; the comparison object is the relevance score and the record's ownership. Assuming the threshold has excluded unrelated records misreads what the parameter does. Executable check: label relevant and irrelevant samples, compare whether filtered citations still contain out-of-scope records, and record the gap when the ownership field is absent.
How to verify the setup
- Verification one: input the arrival acceptance form and rejection form from the hypothetical sample above, together with the draft sentence "Batch LC-2401 has completed rejection and is closed." Compare the handling status field value on the rejection form for the same batch. The condition is met when the output states that the draft sentence disagrees with the pending supplier confirmation status and keeps the conclusion pending verification.
- Verification two: input a multi-turn follow-up that contains a reference. Compare the retrieval terms before and after question optimization. The condition is met when the optimized question keeps the same subject as the original batch object and introduces no new subject. If the subject is replaced after optimization, record that observation.
- Verification three: input a query for which no corresponding material exists. Compare the cited content array. The condition is met when the output is an empty array and the downstream path still accepts it normally. Do not claim that a fabricated rule search necessarily returns empty. All verifications are paper expectations and were not actually executed.