What the documents look like
Product data and selection questions draw on the customer-service system, product detail pages, after-sales question statistics and quality spot checks. The daily material covers FAQ entries, script templates, product parameter tables and escalation tickets. Updates move weekly or monthly, and the time-consuming work sits in consolidating frequent questions, rewriting standard replies and synchronising new-product parameters. Knowledge-base maintenance is preparatory question-and-answer material work; it does not approve refunds directly. Failures show up as answers that miss the question, escalated complaints or failed agent training.
Parameter tables usually carry model numbers, codes and proper nouns, while selection questions rely on natural-language descriptions of usage scenarios. The vector-model and index step therefore handles two input types at once: exact codes suit the full-text retrieval path, and scenario descriptions suit the semantic path. The completeness, length and diversity of the source text affect recall quality, and retrieval-term quality needs checking alongside data quality.
Constraints at the vector indexes step
Knowledge bases linked for retrieval must use the same vector model, so the actual model and input type are checked first. One source data block can be associated with several indexes, and each index is checked separately against the source content. Index content should be complete and focused; retrieval coverage and index length are weighed against the sample. Adding multiple indexes to one data block raises the chance of a hit and also increases the number of vectors.
Image retrieval additionally depends on whether an image-description index or an image-vector index was generated at ingestion time. Uploading an image on the query side does not by itself make that image retrievable. The documented retrieval flow includes question optimisation, semantic retrieval, full-text retrieval, hybrid retrieval, RRF fusion, ReRank second-pass ordering, similarity filtering and reference-token trimming. These paths combine according to input content and search parameters; the flow does not mean every request executes all of them. The reference limit uses tokens as its unit. The minimum relevance value takes effect only under semantic retrieval or when result reordering is used, and it is a filtering threshold rather than a final ordering rule. Semantic recall and relevance scores do not carry permission or entity-isolation duties, and retrieval itself is not authorisation.
Hypothetical exercise sample: a customer-service knowledge-base operator is preparing a product parameter table. The source text reads: "Model X200 cordless vacuum, rated power 120W, runtime 40 minutes, suitable for homes up to 60 square metres. Filter model F-200, recommended replacement every three months." The draft sentence under review is: "The X200 runs 40 minutes and suits large homes." The check is limited to the source text and draft sentence above and does not involve real customers or real companies.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this feature and primary task, tied to the sample. The numbers are starting points for this hypothetical exercise, used for comparison against the sample's actual fields; they are not official defaults.
| Configuration item | Setting or check on this page | Relation to the sample |
|---|---|---|
| Vector model | Check whether linked knowledge bases use the same vector model | The sample's knowledge base must share a model identifier with other bases before joint linking |
| Index content | Build complete and focused index text for the parameter table | The index must cover model, power, runtime and applicable-area fields |
| Multi-vector mapping | One source data block can link several indexes | A long parameter table can be split into several index groups, each checked against the source |
| Search mode | Semantic retrieval, full-text retrieval or hybrid retrieval | Model and filter codes suit full-text retrieval; scenario descriptions suit semantic retrieval |
| Reference limit | Reference-content limit measured in tokens | This hypothetical exercise starts at 2000 tokens, adjusted after comparison with the sample parameter table's length |
| Minimum relevance | Value from 0 to 1, effective only under semantic retrieval or result reordering | This hypothetical exercise starts at 0.3, adjusted after comparison with the sample's recall results |
The hypothetical starting points need stated reasons: the sample parameter table runs to a few hundred characters, so 2000 tokens can hold several reference passages; 0.3 is used to observe candidate differences before and after filtering. Both are starting points for this exercise, not official defaults.
Three common errors
- Treating an image uploaded on the query side as an image already retrieved. The erroneous input is uploading one product image and expecting a knowledge-base image hit; the comparison object is whether an image-description index or image-vector index was generated at ingestion; the observable result is an empty reference set or only text fragments returned. The documentation states that whether an image can be retrieved depends on whether a corresponding index was built at ingestion.
- Treating minimum relevance as a permission or entity filter. The erroneous input is expecting the minimum relevance setting to exclude material from other business lines; the comparison object is whether unrelated business content still appears in recall results; the observable result is unrelated content remaining in the candidate set. The documentation states that minimum relevance is a filtering threshold and does not perform permission isolation.
- Linking knowledge bases that use different vector models. The erroneous input is selecting two knowledge bases with different model identifiers; the comparison object is the node requirement that vector models match; the observable result is that the identifier mismatch is visible at the configuration-check stage, so the non-conforming base is excluded and recorded, without running a cross-model retrieval to compare missed recalls.
How to verify the setup
- For the hypothetical sample source text and draft sentence, input the draft sentence "The X200 runs 40 minutes and suits large homes." Compare the draft against the source field "suitable for homes up to 60 square metres." The source does not support "large homes," so the observable result is that the draft sentence is unsupported by the source and needs rewriting or added evidence.
- For the model and filter codes in the sample parameter table, input "F-200 filter replacement interval" and compare whether the full-text retrieval path hits "recommended replacement every three months." The condition is met when the reference content contains that sentence; if it does not hit, record that observation without inferring a necessary cause.
- For empty-result continuation, use the explicit paper input
[]to check the downstream design and compare whether the downstream node continues when the reference-content length is 0. The documentation states that the output path still runs even when no content is found. The condition is met when the downstream does not stop on the empty array; no claim is made that a fictional rule retrieval necessarily returns[].
This page addresses only customer-service knowledge-base maintenance, product data and selection questions, and vector models and indexes. When operations hand over material, the authorisation state of the material, actions and requests must be stated; retrieval and forms are not authorisation to execute.