We build and measure embedding-based search for websites, product catalogues, helpdesks and internal documents, so the right answer appears even when the words do not match.
Keyword search is precise and brittle. Semantic search is forgiving and occasionally vague. The job is to get the best of both, measured on your own queries.
You are a good fit if people search your site, catalogue, helpdesk or intranet and leave empty-handed because they phrase things differently from your content. Typical starting points: a catalogue where "waterproof jacket for cycling" returns nothing, or a support centre where "card declined" misses the article titled "Payment failures", or a policy library where staff search by situation rather than by document title.
Queries phrased as problems rather than product names
Content written by many authors with inconsistent vocabulary
Users searching in one language for content written in another
A search log full of zero-result queries nobody has mined
Outcome
Fewer zero-result searches
Paraphrases, synonyms and misspellings land on the right page instead of an empty state.
Outcome
A number you can defend
Recall@k and MRR on a labelled test set, re-run on every change, so improvements are visible and regressions are caught.
Outcome
A foundation for RAG
The same index later powers an AI knowledge base that answers questions with citations.
How it works
Documents and queries become points in the same space
An embedding model turns text into a list of numbers. Texts with similar meaning land close together. Search becomes "find the nearest points to the query".
The query "can I send it back?" is embedded and lands beside the returns documents. The three nearest points are returned, ranked by distance, with no shared keyword.
Three decisions shape the result: which embedding model and chunking strategy you use, how the index is built, and what happens after retrieval. The last step matters more than people expect. A reranker that reads the query and each candidate together fixes most of the "close but wrong" results that pure distance ranking produces.
Honest comparison
Where keyword search fails, and where semantic search fails
Neither approach wins everywhere. Knowing the failure modes tells you which parts to combine.
Situation
Keyword search
Semantic search
What we do about it
Synonyms and paraphrase ("send it back" vs "returns")
If your users type codes, names or exact phrases a meaningful share of the time, plan for hybrid from day one. If they mostly type questions and descriptions, pure semantic search with a reranker is usually enough to start.
What we deliver
What a finished search system includes
Content pipeline
Connectors to your CMS, catalogue, helpdesk or file store. Cleaning, chunking, metadata extraction and incremental re-indexing when content changes.
Retrieval service
A small API that embeds the query, searches the index, applies filters and returns ranked results with snippets. Hybrid and reranking are switchable.
Evaluation harness
A labelled query set, scoring scripts and a report that runs on every change. Hand-over includes the data, so your team can keep measuring.
Front-end integration
Search box, results page, facets and "did you mean" wired into your existing site or app. Mobile and keyboard behaviour included.
Vector store set-up
Index configuration, filtering, backups and capacity planning on pgvector, Milvus or a managed service.
Monitoring and feedback
Query logs, zero-result tracking, click-through on results and a feedback loop into the test set. See LLMOps and monitoring.
How we measure it
Two numbers, explained in plain words
Recall@k asks: for each test query, is at least one correct document in the top k results? Average that across the test set. Recall@10 of 0.9 means nine queries in ten had a right answer somewhere on the first page.
MRR (mean reciprocal rank) asks where the first correct result sits. Rank one scores 1, rank two scores ½, rank three scores ⅓. Average the scores. MRR rewards putting the right answer at the top; a correct result low on the page scores less.
Both need a labelled test set. We build one from your search logs: 100–300 real queries. Someone who knows the content tags each one with the one to three documents that should come back. It takes a domain expert a day or two and pays for itself on the first regression it catches.
Query
First correct result at rank
Reciprocal rank
"can I send it back"
1
1.00
"card keeps getting declined"
2
0.50
"change delivery address"
4
0.25
"cancel but keep points"
not in top 10
0.00
MRR
0.44
Illustrative example. The last row is the number that improves or regresses when you change a model or a chunking rule.
Process
From search logs to a measured launch
Discover (week 1)
Mine the search log, list zero-result queries, inventory the content and pick the store that fits your stack.
Index (weeks 2–3)
Build connectors, chunk and embed the content, attach metadata, set up incremental sync.
Retrieve (weeks 3–5)
Query pipeline, filters, hybrid fusion where needed, reranking, and integration into the UI.
Evaluate (weeks 5–6)
Label the test set, score recall@k and MRR, tune chunking, model and ranking until the numbers hold.
Launch and learn (weeks 6–8)
Shadow or A/B rollout, monitoring, and a feedback loop that grows the test set from real traffic.
Ranges assume one primary content source and an existing front end. Permission-aware search across several systems, or search that must also feed a RAG pipeline, extends the middle phases.
What is the difference between semantic search and keyword search?
Keyword search matches the words in the query against the words in the document. Semantic search converts both into embeddings and matches by meaning, so "can I send it back?" finds your returns policy even though the word "return" never appears in the query. See the glossary definition for a short explanation.
Do we need to replace our existing search engine?
Usually not. Most of our builds keep the existing keyword engine and add a vector retriever beside it, then fuse the two result lists. That hybrid approach keeps exact matches for codes and names while adding meaning-based recall.
How long does a semantic search build take?
A focused build over one content source typically takes four to eight weeks, including the labelled test set and evaluation. Multi-source builds with permissions and live synchronisation take longer. Ask for a scoping call and we will give you a range for your case.
Which vector database do you use for semantic search?
It depends on what you already run. PostgreSQL with pgvector is our default when Postgres is in place; Milvus when scale or GPU indexing matters; a managed service when there is no operations team. Our selection guide walks through the choice.
How do you prove that search actually improved?
We build a labelled query set from your real search logs and score recall@k and MRR before and after every change. The numbers decide whether a new embedding model or chunking rule ships.
Talk to us about your AI project
Tell us what you are trying to do, which systems are involved and what is in the way. We reply within one business day with an opinion and a suggested next step.