What the documents look like
Site selection and store opening work happens before a store begins trading, and its central transactions are lease negotiation and construction handover. The working materials are produced per store on an irregular schedule, not on a fixed cycle. Four document types form the main processing objects: site evaluation forms, letters of intent for lease, renovation budgets, and opening schedules. Source material includes trade-area footfall, map POI data, historical store-type POS records, and landlord documents.
These materials frequently carry cross-border entities, bilingual or multilingual clauses, and monetary and date ranges. A Chinese-language question matching a foreign-language knowledge point falls inside the cross-language understanding that semantic retrieval can reach, subject to how well the vector model was trained; accuracy is not stable. The document set is heterogeneous in structure, and that heterogeneity is what drives chunking decisions at this step.
Constraints at the document chunking step
Structural differences between document types determine how chunks are formed. In a letter of intent for lease, a condition and the rent clause it constrains belong together. When they are split apart, the single chunk is semantically incomplete and retrieval precision drops.
Within the knowledge base, one group of source data can map to multiple vectors. Retrieval that hits any one of those vectors recalls the whole group, and the vector score taken is the highest. Source data is stored in the dataset.datas table in MongoDB, where an indexes field records the corresponding vector IDs as an array. Vectors are stored in a vector field in PostgresSQL, with an HNSW index. During retrieval, vectors are recalled first, then source data is looked up by vector ID and merged. The smallest search unit is the knowledge base; a collection only classifies data and does not affect search results.
The following is a hypothetical paper exercise sample. A chain headquarters expansion department intends to sign a letter of intent for lease on an overseas retail unit. The material supplied for checking reads: "Party A is the property owner; Party B is the chain headquarters expansion department. This letter of intent takes effect on the date both parties sign, and is valid for ninety days. The deposit is three months' rent, payable within ten days of signing." The draft sentence to be judged reads: "Signing this letter of intent means the lease contract is formed, and the store may begin renovation once the deposit is paid." The draft sentence conflates three distinct facts: signing, contract formation, and site access. The material states only the effective date of the letter of intent and the deposit payment timing. It does not state the conditions for lease contract formation or any permission to enter the site. The draft sentence is therefore unsupported.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Basis and comparison method |
|---|---|---|
| Search mode | Hybrid retrieval | Numbers and proper nouns need full-text hits; natural-language questions need semantic recall; both are used together |
| Minimum relevance | Hypothetical starting value 0.5 | Takes effect only in semantic retrieval or with result reranking; adjusted after comparison with hit conditions in the sample retrieval |
| Reference limit | Hypothetical starting value 2000 tokens | Reference volume is controlled by tokens; compared against returned content length |
| Question optimization | Not enabled for now | The sample question has a complete subject; compared against latency and hits after enabling |
| Result reranking | Enabled when a model is available | Hybrid retrieval has a wide scope and cannot filter directly by similarity; filtering uses the rerank score |
| Chunk review | Performed manually | Check whether a conditional clause and the clause it constrains are in the same chunk; retain document identity and version |
Three common errors
- Treating a successful upload as an updated retrieval index. After material changes, the actual training and index state must be checked. Upload and index generation are two separate stages, and the upload action alone does not establish that retrieval reflects the new content.
- Treating minimum relevance as a permission or entity filter. That value is a filtering threshold. It does not exclude unrelated business lines or unauthorized records, and retrieval does not constitute authorization.
- Extending the cross-language capability of semantic retrieval into cross-model association. Knowledge bases built on different vector models cannot be associated together. The model identifier must be checked first, non-matching bases excluded, and the actual observation recorded.
How to verify the setup
- Input the sample material text and the draft sentence. Compare the contract formation and site access stated in the draft sentence against the effective date and deposit payment clauses recorded in the source text. When the source text does not state the conditions for contract formation or site access, the draft sentence is judged unsupported, and no authorization clause may be supplied to fill the gap.
- Input three kinds of retrieval terms: a term, an identifier, and a natural-language question. Compare whether the returned content covers the corresponding chunks, and observe whether the conditional clause and the clause it constrains are returned in the same chunk. An empty result is checked against the downstream design using an explicit paper input of []. No claim is made that a fictional rule necessarily returns empty.
- For a question containing an image, first confirm whether an image index was generated at ingestion and whether the model supports image input. Compare the returned differences between image description retrieval and image vector retrieval. When no visual model is configured and the vector model does not support images, image-to-image search is largely unavailable; record this as an observed result.