Vector databases store embeddings, numeric representations of text, images or other content, so AI systems can find items by meaning rather than exact words. They power semantic search, recommendations and retrieval-augmented generation (RAG). The most common mistakes are poor chunking, mixing embedding models, ignoring metadata, skipping evaluation and underestimating update and cost needs.
How do embeddings and vector databases work?
An embedding model, such as those offered by OpenAI, Google, Cohere or open-source projects, turns a piece of text into a long list of numbers. Texts with similar meaning end up close together in that numeric space. A vector database, such as Pinecone, Weaviate, Qdrant, Milvus or the pgvector extension for PostgreSQL, stores those vectors and finds the nearest ones to a query quickly.
In a RAG system, a user’s question is embedded, the closest content chunks are retrieved and a language model writes an answer using them. In marketing, the same mechanics power site search, content recommendations, product discovery and internal knowledge assistants.
Mistake 1: Chunking content badly
Documents must be split into chunks before embedding. Chunks that are too large blur several topics into one vector, so retrieval becomes vague. Chunks that are too small lose context, so the model receives fragments without meaning.
- Split along natural structure: headings, sections and paragraphs, not fixed character counts alone.
- Keep the section title with each chunk so it carries its context.
- Allow a small overlap between chunks where sentences depend on each other.
- Test several chunk sizes on real questions instead of choosing one by habit.
Mistake 2: Mixing embedding models
Vectors from different embedding models cannot be compared. If you embed half your content with one model and the rest with another, or switch models later without re-embedding everything, search results become random in ways that are hard to diagnose.
Record the model name and version with every index. When you change models, rebuild the index fully and test before switching traffic.
Mistake 3: Ignoring metadata
Pure similarity search returns the closest text, but not necessarily the right one. A question about current pricing might retrieve an old price list because the wording matches well.
Store useful fields
Save metadata such as language, publication date, content type, product line, region and access level with each vector.
Filter before ranking
Use filters so a German user only gets German content, a customer only sees public documents and outdated items are excluded. Most vector databases support metadata filtering for this.
Mistake 4: Relying only on vector search
Semantic search handles meaning well but can miss exact terms: product codes, model numbers, names and rare acronyms. Keyword search handles those well. Hybrid search, combining keyword scoring such as BM25 with vector similarity, often gives better results than either alone. Adding a reranking step, where a separate model reorders the top results, can improve precision further.
Mistake 5: Skipping evaluation
Many projects launch after a few impressive demos. Without a test set, nobody knows whether a change made things better or worse.
- Build a list of 50 to 200 real questions with the correct source documents.
- Measure how often the right document appears in the top results.
- For RAG, also check whether the final answers are correct and grounded in the sources.
- Rerun the test after every change to chunking, models or filters.
Mistake 6: Forgetting updates and deletions
Content changes. Products are discontinued, policies change and articles are rewritten. If the index is not updated, the system keeps retrieving old content. Deleted documents that remain in the index are a particular risk, especially if they contained sensitive or withdrawn information.
Connect indexing to your content workflow: when a page is published, updated or removed in the CMS, the index should follow. Schedule a periodic full comparison between source and index to catch gaps.
Mistake 7: Underestimating cost and scale
Embedding large libraries costs money through API calls, and storing millions of high-dimensional vectors costs memory. Query volume on a public site search adds more. Choose dimension sizes and index types that fit the use case, and estimate costs with real content volumes before committing to a hosted plan. For many small and mid-sized projects, pgvector in an existing PostgreSQL database is enough.
Mistake 8: Treating access control as an afterthought
An internal assistant built on a shared index can reveal documents to people who should not see them. Access rules must be stored as metadata and enforced at query time, matching the permissions in the source systems.
Mistake 9: Ignoring multilingual content
Sites and knowledge bases often hold content in several languages. Some embedding models handle many languages well; others are trained mainly on English and perform poorly elsewhere. Test retrieval in each language you support, with native speakers writing the test questions. Decide whether a question in one language may retrieve content in another, and store the language as metadata so you can filter or boost results consistently.
How Alien Road applies vector databases and embeddings
In a typical engagement, these tools appear in projects such as semantic site search, content recommendation and internal knowledge assistants, as well as in keyword and content clustering for SEO work. Discovery identifies the content sources, languages, access rules and the questions users actually ask, collected from search logs, support tickets or sales teams.
Setup chooses a vector store that fits the client’s stack, often pgvector when PostgreSQL is already in use, and an embedding model suited to the languages involved. Content is chunked along its structure, metadata is attached and hybrid search is configured where exact terms matter.
Measurement relies on a test set of real questions built with the client before launch. Reports show retrieval accuracy, answer quality checks, search usage and failed queries, and every change to the pipeline is compared against the previous result.
Where to start this week
Collect 50 real questions from your site search logs or support inbox and note the page or document that should answer each one. That list is the most valuable asset in any vector search project, because it lets you test chunking, models and filters with evidence. Build it before you choose a database.
Keep reading: AI Optimization · AI Optimization