Vector databases and embeddings carry four main risks for a marketing team: private data that becomes searchable by the wrong people, retrieval that returns plausible but wrong passages, embeddings that go stale when content changes, and costs that climb quietly as the index grows. Governance means deciding what may be embedded, who can query it, how often it is refreshed and how answers are checked.
An embedding is a list of numbers that represents the meaning of a piece of text, an image or a product record. A vector database such as Pinecone, Weaviate, Qdrant, Milvus or the pgvector extension for PostgreSQL stores those lists and finds the nearest ones to a query. That nearest-neighbour search is what sits behind most retrieval-augmented generation (RAG) chatbots, semantic site search and “similar products” widgets.
The technology is useful and fairly mature. The trouble is that it feels like a search box, so teams treat it like one. It behaves differently, and the rules have to reflect that.
What makes vector search different from keyword search?
Keyword search fails loudly. If the word is not in the document, nothing comes back, and someone notices. Vector search almost never returns nothing. It always finds the closest match, even when the closest match is a weak one, and it ranks that weak match with the same confidence as a strong one.
For a chatbot built on RAG, this is the root of most bad answers. The language model receives three passages that are “nearest” to the question and writes a fluent reply from them. If none of the passages actually answers the question, the model still tends to produce something that sounds right.
A second difference: meaning is fuzzy. An embedding model may place “cancel my subscription” close to “pause my subscription”, which is fine for discovery and wrong for a policy answer. Exact terms such as product codes, prices and legal clauses are where pure vector search is weakest.
Which risks should you plan for before launch?
Data exposure through retrieval
The most serious risk is access. When a team embeds a shared drive, the vector index usually inherits none of the original folder permissions. An intern’s question to the internal assistant can retrieve a passage from a salary sheet or an unreleased pricing deck, because the index only knows that the passage is semantically close.
Embeddings themselves are also not a safe form of anonymisation. Research on embedding inversion has shown that a good deal of the original text can be reconstructed from vectors in some settings. Treat stored vectors as sensitive as the source text.
Stale and duplicated content
A page about last year’s shipping policy stays in the index until someone deletes its vectors. If the new policy page is also embedded, both are retrieved, and the model may blend them. Marketing sites change often, with campaign pages, seasonal offers and retired services, so staleness is the default state unless a refresh job exists.
Silent quality drift
Changing the embedding model, the chunk size or the similarity metric changes which passages come back. Mixing vectors from two different embedding models in one index produces nonsense rankings, because the two models do not share a coordinate space. None of this throws an error.
Cost growth
Managed vector services typically charge by stored vectors, dimensions, read and write units, or a mix. Re-embedding an entire site after a model change has its own API cost. A small pilot is cheap; an index of every PDF the company has ever produced is not.
What are the technical limits worth knowing?
Most vector databases use approximate nearest neighbour (ANN) indexes such as HNSW or IVF. “Approximate” is literal: for speed, the index can miss the true closest match. Tuning parameters like ef_search in HNSW trade recall for latency.
- Chunking decides quality more than the database brand. A 2,000-word page embedded as one vector loses detail; split into 300-word pieces with a small overlap, it usually retrieves better.
- Metadata filtering (by language, date, product line, access level) is supported by most engines, but filtered search can be slower or less accurate on some index types.
- Multilingual content needs a multilingual embedding model, otherwise a Turkish question may not find the English page that answers it.
- Hybrid search, combining BM25 keyword scoring with vectors, is the usual fix for codes, names and exact phrases. Weaviate, Qdrant, Elasticsearch and OpenSearch all offer some form of it.
Governance rules to set first
Write these down before the first document is embedded. They are short, and they prevent most of the incidents above.
- Source list: name the folders, CMS post types or databases that may be embedded. Everything else is excluded by default.
- Access mirroring: store an access label with every chunk and filter on it at query time, so a user only retrieves what they could already open.
- Exclusion rules: no personal data, contracts, payroll or credentials in the index. Scan for email addresses and ID numbers before embedding.
- One model per index: record the embedding model name and version in the index metadata. A model change means a new index, not a partial update.
- Refresh schedule: re-embed changed content on publish, and run a weekly job that deletes vectors for unpublished or deleted pages.
- Citation requirement: every chatbot answer shows the source passages it used, so users and reviewers can check them.
- Owner: one named person approves new sources and reviews the evaluation results each month.
How do you test retrieval quality?
Build a small evaluation set before launch. Thirty to fifty real questions, each paired with the page that should answer it, is enough for a marketing site. Run them after every change to chunking, model or index settings and record how often the right page appears in the top three results.
Add a similarity floor. If the best match scores below a threshold you set from the evaluation set, the assistant should say it does not know and offer a contact route, rather than improvise. This single rule removes a large share of confident wrong answers.
Finally, read logs. Weekly, sample twenty real queries and their retrieved chunks. Patterns appear quickly: a page that keeps surfacing for unrelated questions, or a topic with no good source at all, which is a content gap rather than a database problem.
How Alien Road applies vector databases and embeddings
In a typical engagement the work starts with a content inventory rather than a database choice. We list what the client publishes, in which languages, and which pages are allowed to answer customer questions. Pricing, legal and campaign pages get a separate label, because they change most and carry the most risk.
Setup usually means pgvector inside an existing PostgreSQL instance for smaller sites, or a managed service when the index is large or multi-tenant. Chunks carry metadata for language, post type, publish date and access level, and a publish hook re-embeds a page whenever it changes. Hybrid search is switched on from day one for product names and service codes.
Measurement uses the evaluation set described above plus two live signals: the share of chatbot sessions that end in a “did not know” reply and the share that click a cited source. Monthly reports show both, list the questions without a good source and recommend the content to write next. That last list is often the most useful output for the marketing team.
Where to start this week
Pick one narrow use case, such as answering shipping and returns questions, and embed only the pages that cover it. Write the seven governance rules above into a one-page document and assign an owner. Then collect thirty real customer questions from support tickets or chat logs and use them as your first test set.
Once that small index answers reliably, with sources shown and a clear “I do not know” path, expand one source at a time. Growing slowly is what keeps a vector database a help desk rather than a liability.
Keep reading: AI Optimization · AI Optimization