Author Introduction
I’m Gaurav Bhanudas Navghare , currently a computer science student who spends a lot of time building small systems just to understand how they work under the hood. Most of my interest lies in learning new things day by day and getting more knowledge about new things especially the parts that quietly power everyday experiences, like search bars. I recently won my first hackathon so today I am happy .
This project started with something very simple. I was building a small product search feature for a college assignment. I assumed search was “solved.” You type words, the system matches them, and that’s it. But once I began testing real queries, I noticed something strange. The system wasn’t wrong . It was just… shallow. It matched words, not meaning. That small realization pulled me into the world of semantic search and eventually Elasticsearch’s vector capabilities.
Abstract
Keyword search often fails when users phrase queries differently from stored documents. I built a semantic search system using Elasticsearch and vector embeddings to bridge that gap. In this blog, I’ll walk through how it works, how I implemented it, and what changed when search started understanding meaning instead of just words.
The Problem I Didn’t Notice at First
At first, I thought traditional keyword search was enough. It works by matching terms between a user query and stored documents. If a document contains the same words, it ranks higher. Simple and efficient.
But then I tested this query:
“Affordable laptop for students”
In my dataset, I had a product titled:
“Budget notebook with 8GB RAM for college use”
To a human, these are clearly related. “Affordable” and “budget” mean the same thing. “Laptop” and “notebook” are often interchangeable. “Students” and “college use” are strongly connected.
But the search engine didn’t see it that way.
The product either ranked very low or didn’t appear at all. The words didn’t match exactly, so the system didn’t think they were related.
I noticed that even when the meaning was identical, the search results depended heavily on exact vocabulary. That felt limiting. Real users don’t think in keywords. They think in ideas.
That’s when I started wondering: what if search compared meaning instead of words?
Understanding Semantic Search
Semantic search sounds complex, but the core idea is surprisingly intuitive.
Instead of storing text as just text, we convert it into numbers. These numbers are called embeddings. An embedding is simply a list of values that represents the meaning of a sentence.
For example, the sentence:
“Affordable laptop for students”
gets converted into something like:
[0.021, -0.134, 0.889, ...]
Those numbers by themselves don’t mean much. But when two sentences have similar meaning, their number patterns are close to each other in mathematical space.
In Elasticsearch, we store these numbers using a special field type called dense_vector. Each document has its own vector.
To compare vectors, we use cosine similarity. You can think of it as measuring how aligned two vectors are. If the angle between them is small, they’re similar in meaning.
Then comes k-nearest neighbors (kNN). Given a query vector, Elasticsearch finds the closest stored vectors. Those are considered the most relevant results.
Instead of asking, “Does this document contain the same words?”
We ask, “Is this document semantically close to the query?”
That shift changes the entire behavior of search.
How the System Works
The flow of the system is straightforward once you break it down.When a user enters a query, the system first converts that query into an embedding using a transformer model. This happens in real time.Meanwhile, all documents in Elasticsearch already have embeddings stored. I generated those during indexing and saved them in a dense_vector field.
Elasticsearch then runs a kNN search. It compares the query vector against all stored vectors using cosine similarity and retrieves the closest matches.
Finally, the most semantically similar documents are returned to the user.It sounds advanced, but conceptually it’s just comparing distances in a high-dimensional space.
Building It Step by Step
I deployed Elasticsearch using Elastic Cloud. I considered running it locally, but using the managed service made setup much faster. Within minutes, I had a cluster running and accessible through Kibana and the Python client.
The first important step was creating the index mapping. Since I was storing embeddings, I defined a dense_vector field with 384 dimensions. I chose 384 because the embedding model I used the all-MiniLM-L6-v2 sentence transformer outputs vectors of that size.
I actually made a mistake here at first. I accidentally configured the mapping with the wrong dimension count. Elasticsearch immediately rejected the documents. That was my first lesson: vector dimensions must match exactly. There’s no flexibility there.
For generating embeddings, I used the sentence-transformers library in Python. I chose all-MiniLM-L6-v2 because it’s lightweight and fast while still producing strong semantic representations. For a small-to-medium dataset, it felt like the right balance between performance and quality.
When indexing documents, I combined the product title and description into a single text string. I passed that text into the model, generated the embedding, and attached the vector to the document before indexing it into Elasticsearch.
For searching, I tried two approaches.
The first was a traditional keyword match query. It was fast and simple but struggled with synonym-heavy queries.The second was a kNN vector query. I generated an embedding for the user query in real time and passed it to Elasticsearch’s kNN search. The difference in relevance was noticeable almost immediately.
Comparing the Results
Here’s a simplified comparison of what I observed:
Keyword search was slightly faster. That’s expected. But vector search was consistently more aligned with intent. Latency was slightly higher for kNN queries, but still within acceptable limits for my dataset size. With tuning, especially adjusting num candidates, performance improved further.
What stood out most wasn’t speed it was relevance. The system finally understood synonyms and contextual meaning.
Challenges That Taught Me the Most
This project wasn’t perfectly smooth.
Besides the dimension mismatch issue, I also ran into a problem where I wanted to modify the index mapping after creation. Elasticsearch doesn’t allow changing vector dimensions once an index is created. I had to delete the index and rebuild everything. I also noticed slower queries initially. It turned out I hadn’t tuned kNN parameters properly. After reducing unnecessary candidate checks, the performance improved significantly.
These weren’t major roadblocks, but they forced me to understand how Elasticsearch handles vectors internally.
Thinking About Real-World Usage
If this were a production system, I wouldn’t rely purely on vector search. Hybrid search combining keyword matching and vector similarity would probably give the best balance of precision and recall. Elastic Cloud makes scaling much easier, especially for workloads that require distributed search.
I can easily imagine this approach being used in e-commerce, FAQ retrieval systems, knowledge bases, and support bots. Anywhere users describe what they want in natural language, semantic search adds real value.
Conclusion
This project began with a small frustration: search results that technically worked but didn’t feel intelligent. By adding vector search to Elasticsearch, I built a system that understands meaning rather than just word overlap. The improvement wasn’t dramatic in appearance. It was subtle but important. Results felt more aligned with user intent.
I learned that embeddings are powerful, but they require careful configuration. Small setup mistakes can break everything. I also realized that relevance is more than just matching text It’s about interpreting intent.
If you’re building search systems today, relying only on keywords might not be enough. Once you see how semantic search improves results, it’s hard to ignore the difference. And honestly, that realization alone made this project worth building.
Top comments (1)
This blog post was submitted to the Elastic Blogathon Contest and is eligible to win a prize.