Vector Databases & Semantic Search
Semantic search that finds by meaning rather than keyword — Qdrant and pgvector, tuned and measured on your own data.
Keyword search fails on the way people actually ask. Someone searching "won't turn on" never matches an article titled "Power supply troubleshooting", and every one of those misses is a support ticket you did not need. Semantic search matches on meaning — and the best implementations keep keyword matching alongside it, because exact codes, part numbers and names still need exact matching.
Who this is for
Products whose search users have quietly stopped trusting. Companies with large document, ticket or product catalogues where the right item exists but cannot be found. Any team building retrieval for an AI assistant, where search quality sets the ceiling on answer quality.
Problems we solve
- Vocabulary mismatch. Customers and documentation using different words for the same thing.
- Semantic search that lost exact matching. Vector-only systems that can no longer find a specific SKU.
- Relevant but not right. Topically similar results ranked above the actually correct one.
- Slow queries at scale. Index parameters left at defaults as the corpus grew.
- Unmeasured quality. No relevance benchmark, so nobody can tell whether a change helped.
What we build
- Vector indexes in Qdrant, pgvector or Pinecone, sized and tuned for your corpus
- Hybrid search combining semantic similarity with keyword matching and fusion ranking
- Metadata filtering, so results respect category, date, tenant and permissions
- Re-ranking to reorder candidates by genuine relevance
- Embedding pipelines with incremental updates as content changes
- Relevance benchmarks that run in CI, so search quality is a tracked number
How we work
We build a labelled relevance set from your real queries first — the questions people actually type, with the results that should come back. Everything after that is measured against it: embedding model choice, chunking, hybrid weighting, re-ranking. Without that set, search tuning is opinion. We also benchmark embedding models on your domain rather than trusting general leaderboards, because domain vocabulary changes the ranking considerably.
Technologies we use
Qdrant for dedicated vector workloads, pgvector where Postgres is already in the stack and the scale suits it, Pinecone where a managed service fits better. OpenAI, Nomic and self-hosted Ollama embedding models. Redis for query caching, with hybrid retrieval and cross-encoder re-ranking on top.
Business benefits
- Users find what they need on the first search rather than the third
- Support volume falls when self-service search actually works
- Better retrieval directly raises the accuracy of any AI assistant built on it
- Relevance becomes measurable, so improvements are provable
Where it pays off
- Help centre and documentation search
- Product catalogue search with natural-language queries
- Retrieval layers underneath RAG assistants
- Finding similar past tickets, cases or contracts
- Deduplicating records that differ in wording but not in meaning
Common questions
Qdrant or pgvector?
If Postgres is already in your stack and the corpus is moderate, pgvector avoids running another service and keeps filtering simple. At larger scale, or where you need advanced quantisation and payload filtering, Qdrant is the stronger choice. We size it against your actual corpus rather than defaulting.
Do we have to replace our existing search?
Usually not. Hybrid search puts semantic retrieval alongside what you already have, which typically outperforms either alone.
How much does it cost to run?
Embedding is a one-off cost per document plus a small ongoing cost for changes. Self-hosted embedding models remove the per-token cost entirely. We model this before you commit.
Is your search quietly failing users? Send us your top queries and we will show you what it is missing.