Building A Smarter Search with Hybrid RAG using Vector Databases

Beyond Keyword Matching

Imagine searching for a document using the phrase: "How can I improve application performance?"

You know the information exists, but the search system returns little or nothing useful because the document contains terms such as "latency optimization," "resource utilization," or "performance tuning" instead of the exact words used in the query.

The information is relevant. The wording is simply different.

This is one of the biggest limitations of traditional search systems, especially when working with large volumes of technical or domain-specific data.

Hybrid Retrieval-Augmented Generation (Hybrid RAG) systems address this problem by combining semantic understanding with keyword precision. By leveraging dense and sparse retrieval together, these systems improve the quality and relevance of retrieved information significantly.

During my internship, I had the opportunity to work on Hybrid RAG systems and experiment with different retrieval approaches to improve search quality. What started as an exploration of dense and sparse retrieval gradually evolved into working with vector databases, cloud deployments, indexing strategies, and retrieval optimization techniques. This blog shares some of the key challenges, observations, and lessons I gathered while working with vector databases, particularly Milvus and Qdrant, to build and optimize Hybrid RAG systems.

What I Was Building

I worked on building and experimenting with Hybrid Retrieval-Augmented Generation (Hybrid RAG) pipelines to improve information retrieval from large collections of documents. While traditional keyword-based search was effective for exact matches, it often struggled when queries and documents used different terminology to describe the same concept.

The objective was to create a retrieval system that could understand both the meaning behind a query and the importance of specific keywords. To achieve this, I explored a combination of dense retrieval, which focuses on semantic similarity, and sparse retrieval, which focuses on exact keyword matching.

As the project progressed, the work extended beyond retrieval itself. I found myself experimenting with chunking strategies, overlap configurations, reranking techniques, indexing approaches, and vector database selection. Small changes in these components often had a noticeable impact on the quality of retrieved results, making experimentation an important part of the development process.

Hybrid RAG Pipeline

A Hybrid RAG pipeline combines retrieval and generation to produce more accurate and context-aware responses.

When a user submits a query:

1. The system generates an embedding representation of the query.
2. The embedding then goes through both dense and sparse retrieval pipelines in parallel.
3. Dense retrieval identifies semantically similar content, while sparse retrieval focuses on exact keyword matches.
4. The retrieved results are combined, reranked, and passed to the language model as contextual information.
5. The language model then uses this context to generate a more relevant and grounded response.

This workflow helps reduce irrelevant results and improves the overall quality of retrieval in RAG-based applications.

Let’s Dive Deep into Retrieval

What is Hybrid Retrieval?

Traditional keyword-based retrieval performs well for exact matches but often struggles with semantic understanding. Hybrid Retrieval addresses this limitation by combining dense retrieval, which focuses on semantic similarity using embeddings, and sparse retrieval, which focuses on exact keyword matching.

By leveraging both approaches, Hybrid Retrieval improves search quality by balancing contextual understanding with keyword precision.

A simple way to think about this is searching for "places to stay during a vacation." A keyword-based system may only look for documents containing the exact words places, stay, or vacation. However, relevant results might instead contain terms such as hotel, resort, or accommodation. Semantic (dense) retrieval helps identify information with similar meaning, while keyword-based (sparse) retrieval ensures exact terms are not overlooked. Combining both approaches made the retrieval process more accurate and reliable.

Challenges Faced

As the retrieval pipeline grew more complex, so did the challenges associated with experimentation. What initially seemed like a straightforward retrieval task quickly expanded into managing embeddings, indexing workflows, retrieval tuning, and vector database operations.

Infrastructure Limitations

As the number of documents and embeddings increased, indexing operations became more resource-intensive and query execution times started becoming less predictable. Rebuilding indexes repeatedly while testing different retrieval configurations also slowed down experimentation.

Balancing Retrieval Quality and System Performance

Small changes in chunk size, overlap configuration, retrieval weights, or reranking strategies could produce noticeably different results. While some configurations improved relevance, others introduced duplicate chunks or reduced contextual accuracy.

Other Challenges

• Increased memory usage during vector indexing
• Slower query execution with larger embedding collections
• Frequent index rebuilding during retrieval tuning
• Balancing retrieval quality with system performance

These challenges highlighted that building an effective Hybrid RAG system involves much more than simply connecting a retriever to a language model. Continuous experimentation and optimization played a significant role in improving overall retrieval performance.

Solution

To address these challenges, I started exploring cloud-based deployment options for vector storage and retrieval. This allowed me to move beyond the limitations of local infrastructure and focus more on experimentation itself.

The shift proved particularly useful when working with larger embedding collections and testing multiple retrieval configurations. Tasks such as indexing, retrieval tuning, and database experimentation became more manageable, making it easier to iterate and compare results.

Some of the immediate improvements included:

• More stable indexing workflows
• Faster experimentation cycles
• Better handling of larger datasets
• Reduced dependence on local system resources

More importantly, cloud deployment allowed me to spend less time troubleshooting infrastructure constraints and more time understanding how different retrieval strategies affected overall search quality.

Through this process, I realized that building effective retrieval systems is not only about choosing the right models or databases - it is also about creating an environment that supports continuous experimentation and improvement.

Retrieval Quality

Retrieval quality depended heavily on tuning and experimentation rather than retrieval models alone.

Chunking Strategy

Consider a technical document containing an explanation of Hybrid Retrieval. If the content is split into very small chunks, the explanation of dense retrieval may end up in one chunk while sparse retrieval appears in another. When retrieved independently, important context can be lost.

Introducing appropriate chunk overlap helped preserve related information and improved retrieval consistency.

Balance of Dense and Sparse Retrieval

Balancing dense and sparse retrieval also improved result quality significantly.

Dense retrieval performed well for semantic similarity, while sparse retrieval improved exact keyword matching for technical terms and abbreviations.

Some common retrieval issues observed were:

• Semantically relevant but technically weak results
• Repetitive chunks from sparse retrieval
• Partially relevant rankings

Reranking Strategies

Applying reranking strategies helped improve:

• Retrieval precision
• Contextual relevance
• Consistency across technical queries

These optimizations made the Hybrid Retrieval pipeline significantly more reliable and context-aware.

Vector Databases

As the project progressed, I realized that Hybrid RAG systems require more than just embeddings and retrieval strategies. The embeddings also need to be stored, indexed, and searched efficiently, which is where vector databases become an essential part of the pipeline.

While exploring different solutions, I came across several vector databases designed specifically for semantic search and similarity retrieval. After comparing different options, I decided to experiment with Milvus and Qdrant, as both offered strong support for Hybrid RAG workflows while taking slightly different approaches to deployment, scalability, and developer experience.

This eventually became one of the most interesting parts of the project, as it gave me the opportunity to understand not only how vector databases work, but also how the choice of database can influence experimentation, indexing, and retrieval performance.

Working with Milvus and Qdrant

Implementing the same Hybrid Retrieval workflow on both Milvus and Qdrant revealed noticeable differences in development experience, deployment workflows, indexing behavior, and experimentation speed.

The comparison became less about identifying a “better” database and more about understanding which platform fit different retrieval requirements more effectively.

Both databases handled Hybrid Retrieval workflows effectively, but the overall interaction experience differed significantly.
Based on my experimentation and experience, Qdrant enabled faster experimentation and simplified development workflows, while Milvus provided greater flexibility for scalability-oriented retrieval systems and larger vector operations.

Final Takeaways

Hybrid Retrieval systems demonstrate that effective search is no longer just about matching keywords - it is about understanding both meaning and precision together.

Working with dense and sparse retrieval pipelines highlighted how retrieval quality depends heavily on infrastructure choices, indexing strategies, chunking decisions, reranking approaches, and continuous experimentation.

Exploring both Milvus and Qdrant also reinforced an important engineering insight: different vector databases are optimized for different workflows, and selecting the right platform depends strongly on scalability requirements, experimentation needs, and deployment goals.

As Hybrid RAG systems continue evolving, vector databases and retrieval optimization techniques will play an increasingly important role in building more accurate, context-aware, and reliable AI applications.