What the documents look like
Inventory procurement and supplier records for a Tmall flagship store sit across product listing pages, brand authorization letters, delivery commitment records, and after-sales tickets. Brand authorization and flagship store identity are hard constraints for this category, so supplier material that drifts outside the authorized scope directly affects whether a product can remain listed. These records update at daily and per-order frequency, and any knowledge base connection depends on first confirming which records belong to a library sharing the same vector model.
A knowledge base uses the library as its smallest search unit. A collection only classifies data and does not affect search results. One original data block can link to multiple indexes, and index content is checked against the original text separately. Libraries associated for retrieval must use the same vector model; cross-model association is not allowed, so the actual model identifier is checked first and non-matching libraries are excluded. Image retrieval also depends on whether an image description or image vector was generated at ingestion time; uploading an image at query time does not create an index. Semantic retrieval and the minimum relevance value act only as similarity filtering and do not provide permission or entity isolation, so a retrieval result is not an authorization result.
Constraints at the vector indexes step
The following hypothetical drill sample is used throughout this page. It is a paper exercise and does not describe a real customer, a real authorization, or a completed action.
Sample source text A: “Supplier A, brand authorization letter number A-001, authorization valid until December 31, 2025, authorized product category is home storage.”
Sample source text B: “Purchase order P-100, Supplier A, home storage category, order date March 10, 2025, quantity 500 units.”
Pending handover request for review: “Please add Supplier A’s records to the procurement knowledge base and allow the procurement team to retrieve them.”
This request contains two actions: authorization and ingestion. The source material supports only that the authorization letter exists and that the purchase order exists. It does not state who holds retrieval permission, so the permission question is pending verification. The authorization letter number A-001 and the purchase order number P-100 are different fields under different subjects, and the material does not state that they belong to the same original data block.
Configuration and implementation checks
The table lists documented settings or implementation checks relevant to this page. The starting values are hypothetical test starting points for this exercise, not official defaults.
| Check item | Hypothetical starting point for this exercise | Comparison and reason |
|---|---|---|
| Vector model identifier | Recorded as model M1 | Compare with the actual model identifier of the target library; association requires a match |
| Index content | Authorization letter number, validity period, category | Compare word by word with the source text; confirm the index stays within the authorized scope |
| Image index | Sample contains no image | With no image input, do not check image description or image vector |
| Reference limit | Starting point 2000 tokens | Compare with the sample source length; confirm the reference does not truncate key fields |
| Minimum relevance | Starting point 0.5 | Compare with semantic retrieval or rerank score; it is a filtering threshold only |
| Search mode | Hybrid retrieval | Compare with exact fields such as number and category; confirm full-text recall covers them |
Hybrid retrieval combines vector retrieval and full-text retrieval through the RRF formula. RRF is a fusion process for mixed results, not a switch to turn on. Rerank requires a rerank model and must be enabled according to settings; it produces a 0-1 score for relevance. The reference limit controls how many tokens are cited per search. The minimum relevance value applies only in semantic retrieval or when result reranking is used, and it is a filtering threshold rather than a final ordering rule.
Three common errors
- Treating authorization letter A-001 and purchase order P-100 as one index. Input both source passages, compare their subjects and fields, and observe whether they are merged into the same original data block. The material does not state that they share an original data block, so a merge would not be supported.
- Reading “allow the procurement team to retrieve” as an authorization already granted and executing ingestion. Input the pending request, compare whether the material states who holds retrieval permission, and observe whether an authorization field appears. When the material does not state it, record the permission question as pending verification and do not perform ingestion.
- Using minimum relevance 0.5 to infer that unrelated suppliers are excluded. Input a semantic retrieval score, compare the threshold’s documented effect, and observe whether non-target suppliers still appear in the references. The threshold filters by similarity only; it does not isolate entities or enforce permissions.
How to verify the setup
- Input the two sample source passages and model identifier M1. Compare M1 with the actual model identifier of the target library. Association is permitted only when the two identifiers match; when they do not match, exclude that library and record the observation. Do not run cross-model retrieval to compare missed recalls.
- Input the pending request “Please add Supplier A’s records to the procurement knowledge base and allow the procurement team to retrieve them.” Compare whether the material states retrieval permission. When the authorization field is absent, record the request as pending verification and do not execute ingestion. A pending request is not approval, and an offered option is not execution.
- Input the reference limit of 2000 tokens and the sample source text. Compare whether the returned references include the authorization letter number, validity period, and category, and observe whether the key fields are returned completely. If the result is empty, check the downstream design against the explicit paper input
[]; do not infer that retrieval must return empty. A retrieval result is not an authorization result, and the empty-reference output can still pass through the downstream chain.