Retrieval happens before generation

For a customer question, the server searches eligible saved knowledge belonging to the intended workspace. The language model is given a bounded selection of that material. This retrieval-augmented generation process is different from asking a model to invent a shop answer from its training. It is also different from performing an unrestricted web search for every message.

Semantic and lexical lookup

Semantic lookup compares a question vector with stored chunk vectors using cosine distance in PostgreSQL/pgvector. Similarity is derived as one minus distance; it is a ranking signal, not the probability that an answer is true. Lexical lookup finds textual and identity matches and provides a fallback when embeddings are unavailable. Candidate eligibility still checks ownership, ready state, canonical status, and exclusions.

Example
Simplified retrieval model, not a public API
question + relevant conversation context
  -> authorised, eligible source candidates
  -> lexical and/or vector ranking
  -> product and attribute refinement
  -> bounded source passages with URLs
  -> answer generation and output checks

Product identity comes before generic similarity

Distinctive model tokens and product names help locate the intended product. A revision token alone is weaker evidence than the full model identity. Accessories can be appropriate for a fit question but inappropriate for a request to buy the main product. The retrieval layer refines candidates using the actual question, including bilingual attribute terms. This reduces the chance that a similarly named keyboard, case, or switch supplies the wrong specification.

Specifications, compatibility, and policy lookups

A compatibility restriction may live late in a product FAQ, outside the first semantic matches. Saved product-page lookups can recover that passage without a new network crawl. Policy and contact lookups also serve a different purpose from product recommendations: a returns page should remain useful for a returns question even when it is excluded from the product candidate pool. Source selection therefore depends on the requested fact, not just one universal similarity score.

Conversation history is a query aid

A follow-up such as 'does the tall one fit?' needs the previous product and variant context. History helps identify that referent. It does not convert an earlier assistant statement into verified product knowledge. When the variant is ambiguous, ask for the missing detail; when a source already states the restriction, answer it directly and explain the supported alternative.

The context budget is finite

The reviewed knowledge-context formatter defaults to an 18,000-character budget and distributes available space across useful matches. Character budget is not the same as the provider's token limit. A large catalogue is not sent in full to every response. Retrieval limits, source diversity, policy passages, and product-specific lookups determine which facts reach the model. This explains why adding many duplicate pages can reduce usefulness rather than improve coverage.

Strict sources and general knowledge

In strict mode, approved shop knowledge constrains the factual answer. When general knowledge is enabled, stable technical background can supplement it, but shop prices, stock, offered editions, and merchant policies still require shop evidence. A manufacturer's general bundle contents do not prove what the merchant's particular edition includes. General knowledge is not permission to present an unsupported current availability claim.

Output checks and their limits

The server checks links against allowed evidence and assesses signals such as uncertainty and grounding. These are guardrails, not a calibrated confidence percentage or a guarantee that every statement is correct. Review a saved conversation against the retrieved source. Correct missing knowledge or a wrong identity before trying to solve every failure by making the prompt more forceful.