Vector Search Development
Semantic search that still finds exact part numbers and error codes, built with hybrid retrieval, reranking and recall measured on your own data.
Vector search is not a replacement for keyword search
Embeddings are extraordinary at meaning and unreliable at exactness. Ask a pure vector index for "error E4021" and it will happily return passages about errors in general, because the number carries almost no semantic weight. Users searching technical content notice this immediately.
Production search is nearly always hybrid: a keyword pass for precision, a vector pass for meaning, fused and then reranked. That architecture is more work than dropping documents into a vector database, and it is the difference between a demo and a search people trust.
We also treat filtering as a first-class concern. Tenancy, permissions and recency have to be applied at retrieval time, not after, or you will either leak documents or lose relevance.
Teams that start here often pair it with RAG architecture, MySQL to PostgreSQL migration and custom AI chatbots.
Ask a pure vector index for an exact error code and it returns passages about errors in general. That is not a tuning problem, it is the wrong architecture.
Where vector search disappoints in production
Four problems that surface once real users query real content.
Part numbers, SKUs and error codes carry little semantic signal, so pure embedding search buries the one document that matters.
First-stage candidates go straight to the user, so a loosely related passage outranks the precise one and relevance feels random.
Permissions and tenancy are applied after retrieval, so results are either wrong or thin once the filter removes most of them.
No labelled query set, so every tuning change is guesswork and regressions ship unnoticed.
What a vector search engagement delivers
A hybrid index, tuned ranking, and the harness to prove it works.
Chunking, embedding model and dimensionality chosen against measured recall on your corpus rather than benchmark defaults.
BM25 and dense vector passes fused, so exact identifiers and conceptual queries both work.
A cross-encoder pass over first-stage candidates, typically the largest single relevance improvement available.
Tenancy, permissions and recency applied inside the query, so filtering never effort relevance or leaks documents.
Labelled queries with expected results, reporting recall and precision in CI so tuning is measurable.
Change-data-capture pipelines so new and updated content is searchable in seconds rather than after a nightly rebuild.
From corpus to measured search through controlled rollout
Relevance proven with numbers before launch.
Document types, structure and update patterns reviewed, plus a labelled query set built with your subject experts.
Chunking and embedding tuned against the labelled set, with recall reported at each iteration.
Keyword and vector passes combined and weighted, then reranked, measuring the gain at each stage.
Permission and tenancy filters pushed into the query plan and load tested at realistic index size.
Live behind monitoring for latency and zero-result rate, with a relevance report your team can keep running.
The stack behind our search systems
Postgres until the numbers say otherwise.
pgvector next to relational data keeps permissions, joins and reporting simple at most realistic scales.
Keyword and dense passes fused, because neither alone covers real query patterns.
A cross-encoder reranker over a small candidate set, tuned for the latency scope.
Incremental indexing so the index reflects the source within seconds.
What this looks like in production
Fixing search that could not find a product by its own SKU
A retailer replaced keyword search with a vector-only implementation and saw conversion drop. Semantic queries worked beautifully; searching a SKU, a brand code or an exact model name returned near-random results.
We reintroduced a keyword pass, fused it with the vector results and added a reranker over the combined candidates. Filters for stock status and category moved into the query rather than being applied afterwards.
Zero-result searches fell by four fifths and conversion recovered past its pre-migration baseline, because customers could now search by concept and by code.
Search relevance treated as a measurable property
We build a labelled query set before we tune anything, because relevance improvements that are not measured are just opinions with a deployment attached.
Keyword and vector retrieval together, because production queries contain both meaning and exact identifiers.
A working demo and a written note every Friday covering what shipped, what slipped and what it means for the date. No status theatre.
Nothing goes live in one jump. We run in parallel or behind a flag until the numbers say it is safe to switch over.
