Vector Database

A vector database is the index behind retrieval-augmented generation. When a customer asks 'do you do emergency callouts on Sundays', no keyword in the question needs to appear in the policy document for the right paragraph to be found; the vector index finds it by meaning. In a voice or chat agent it sits between the knowledge base and the model, answering one question thousands of times a day: which passages are most relevant to this message.

How it works. At ingestion, each document is split into passages, and an embedding model converts each passage into a vector, a list of a few hundred to a few thousand numbers that encodes its meaning. The vectors are stored with metadata: source document, section, effective date, language, which agent may use it. At query time the customer's message is embedded with the same model and the database returns the nearest vectors by cosine similarity, filtered by metadata, typically in tens of milliseconds. The output is a ranked list of passages with scores; the agent passes the top few to the language model. Many production setups combine vector search with keyword search so that exact strings such as product codes are not missed.

Why it matters for answer quality and speed. Retrieval quality is bounded by the index. If passages are chunked badly, the right answer is split across two vectors and neither ranks highly. If metadata is missing, the retriever cannot restrict a dental agent to dental documents, and a question about 'cleaning' returns a carpet-cleaning passage from another client's data. For a buyer the relevant questions are not which database vendor but whether chunking, filtering, multi-tenancy and latency are handled, and whether the setup can show which passages produced each answer.

Example. An e-commerce brand uploads 400 product pages, a shipping policy and a size guide. A customer writes on Instagram, 'will the linen shirt shrink if i machine wash it'. The embedded question lands near the care-instructions paragraph of the linen shirt page and near the general fabric-care section of the size guide. Both are returned, filtered to the brand's own index, in a few tens of milliseconds. The model answers from the product-specific passage, and mentions the general advice to wash cold. A keyword search on 'shrink' would have missed the page entirely, because it says 'may reduce in size'.

Vector database vs knowledge base. The knowledge base is the content: the documents your team owns and edits. The vector database is one way of indexing that content for retrieval. You maintain the knowledge base; the platform maintains the index. If an answer is wrong because the document is wrong, fix the knowledge base; if an answer is wrong because the right document exists but was not found, the problem is chunking, embedding or filtering in the index.

Common pitfalls.

• Chunks that cut a table or a numbered list in half.
• One shared index across customers or agents without strict metadata filtering.
• Changing the embedding model without re-indexing everything, which makes old and new vectors incomparable.
• Retrieving by similarity alone when an exact match (order ID, SKU, part number) is what the customer typed.

Botcadence agents retrieve from uploaded documents and crawled pages, with data encrypted with AES-256 at rest and TLS 1.2+ in transit; see chat agents and RAG.