Here's a recap of everything that happened this month!

## 💬 Introducing conversational search

[![Conversational search](https://unable-actionable-car.media.strapiapp.com/conversational_search_cb1af6a9e5.jpg)](https://www.meilisearch.com/docs/guides/ai/getting_started_with_chat)

Learn to build conversational search using Meilisearch's chat completions. 

[Read the guide](https://www.meilisearch.com/docs/guides/ai/getting_started_with_chat)

## 📰 In the news

### 🫣 Meilisearch 1.16 preview

Get a sneak peek at what's coming in v1.16—releasing August 4th.

[Read the changelog](https://github.com/meilisearch/meilisearch/releases)

### 💳 Same Meilisearch, new pricing

ICYMI, you can get early access to our resource-based model. Check it out!

[Discover new pricing](https://www.meilisearch.com/pricing/platform)

### 💥 Most personalized search experiences are a lie

How to implement search personalization the simple, effective way.

[Read the blog post](https://www.meilisearch.com/blog/personalized-search-experiences)

### 🔍 Mastering RAG: unleashing precision and recall

Enhance LLM accuracy using RAG with Meilisearch's hybrid search capabilities.

[Read the blog post](https://www.meilisearch.com/blog/mastering-rag)

### 🔥 How to implement search in Firebase

A short step-by-step tutorial to get you started with Firebase and Meilisearch.

[Read the tutorial](https://www.meilisearch.com/blog/firebase-search)

---

_We’re always looking to promote new projects from our [Discord community](https://dub.sh/meili-discord?utm_campaign=newsletter&utm_source=blog&utm_medium=july-25-updates). Share yours!_

---

Receive this updates in your inbox by subscribing to our [monthly newsletter](https://dub.sh/meili-newsletter?utm_campaign=newsletter&utm_source=blog&utm_medium=july-25-updates). To learn more about Meilisearch's future and help shape it, take a look at our [roadmap](https://roadmap.meilisearch.com/?utm_campaign=newsletter&utm_source=blog&utm_medium=july-25-updates) and participate in our [Product Discussions](https://github.com/orgs/meilisearch/discussions).

For anything else, join our developers community on [Discord](https://dub.sh/meili-discord?utm_campaign=newsletter&utm_source=blog&utm_medium=july-25-updates).

Meilisearch July updates

Semantic search vs Vector search: Key differences, uses, & more

Elasticsearch vs Typesense (vs Meilisearch): Which search engine actually fits your needs in 2025?

We’ve been handed an exciting dream—and it hasn't quite lived up to expectations. 

With the rapid growth of AI, big names like Google promised a revolution in how we discover information. 

Search was meant to become faster, smarter, and more tailored to us. 

Yet, here we are, still wading through unrelated suggestions and one-size-fits-all recommendations. 

Personalized search? Perhaps more like personalized guesswork. 

So, what went wrong? Let’s explore it together. 

## What most "personalized" search experiences actually do

Every rose has its thorn. And so do personalized search engines. 

What’s sold under the sweet sauce of “customization” is often just a simple data retrieval. 

And even then, chances are you won’t get what you’re looking for. 

Why does this happen?

Here are a few reasons:

### Reason #1: Words set in stone

Personalized search engines often follow a hard-coded word order, preconditioning the final results. 

The [Prozis e-commerce company](https://www.prozis.com/) search engine relies on this rule to search for products. 

For instance, if we search for “nut butter for keto diet,” the results are ordered as “hazelnut butter,” “pistachio butter,” and “almond butter.” 

![Prozis e-commerce company search engine.png](https://unable-actionable-car.media.strapiapp.com/Prozis_e_commerce_company_search_engine_b24a69f8dd.png)

Image Source: [Prozis](https://www.prozis.com/)

But here’s the problem.

Hazelnut and pistachio butters, listed as first and second, are not keto-friendly, while almond butter, which actually is ketogenic, comes in third. 

What you see here is relevance ranking. 

The order of words predetermines and prioritizes the search results that closely match the query. 

Yet, something crucial is missing in this case: user intent. 

The next point on our list is about the same issue. 

### Reason #2: All eggs in one basket 

Oftentimes, it’s not the word order that creates stumbling blocks in personalized search. 

It’s an oversimplified user segmentation. 

Personalized search engines often group users into broad categories (e.g., “tech shoppers”, “outdoors enthusiasts”). 

And let’s be honest, it’s easier that way. 

However, the outputs we get are inaccurate and irrelevant recommendations. 

After all, there are nuances in everything. Let’s say two people are outdoor enthusiasts; one loves hiking, but the other hates getting on the trail and prefers luxurious glamping. 

Both belong to the same group. But are they really the same?

Streaming services are guilty of this, and [Netflix](https://www.netflix.com/) is a good example. 

Upon registration, you must choose three movies/TV shows you like. 

![Netflix collecting user preferences.png](https://unable-actionable-car.media.strapiapp.com/Netflix_collecting_user_preferences_3e0362f5b3.png)

Image Source: [Netflix](https://www.netflix.com/)

If you go for a selection of medical shows and series about law and law enforcement, guess what you’ll get. 

![Netflix top pics for you.png](https://unable-actionable-car.media.strapiapp.com/Netflix_top_pics_for_you_ec86072c2b.png)

Image Source: [Netflix](https://www.netflix.com/)

But do these three picks truly reflect *all *of your viewing preferences?

Hardly. 

Yes, you might like some shows about law enforcement, but you might also hate watching *Dexter*—a crime show—because it’s too gruesome. 

That’s not all, though. 

If you look closer at the shows suggested in the image above, you’ll see that some of them have been around for a while (like *House, Prison Break, *or* Suits)*, and you may have seen them already.  

Thus, the Netflix algorithm is also guilty of the filter-bubble effect, meaning you won’t be exposed to anything except what you already engage with.

### Reason #3: Money talks

Personalization implies prioritization. 

In our case, the prioritization of the user’s search intent and their interests. 

Most search engines claim they honor this priority. 

But not before they honor their obligations to the advertisers. 

Many online marketplaces follow this logic, and [AliExpress](https://www.aliexpress.us) is a good example. 

When you search for a product, the platform gives you various options, but not until it shows you two rows worth of paid ads. 

![AliExpress product search.png](https://unable-actionable-car.media.strapiapp.com/Ali_Express_product_search_fef4e07fee.png)

Image Source: [AliExpress](https://www.aliexpress.us)

To be fair, marketplaces like AliExpress need to work with advertisers to sustain their business. 

However, overrunning the search results with ads contradicts AliExpress’s claim about curating “a selection of products tailored specifically to you,” as they claim at the bottom of their homepage. 

You can’t expect a user to be satisfied with product recommendations after scrolling through several rows of ads. 

That’s just not what personalization is about. 

## What is true personalization?

The answer seems simple: personalization is about deeply understanding the user's needs. 

The actual matter is, of course, more complex. 

The biggest obstacle to personalized search is analyzing massive amounts of user data to deliver the most relevant search results. 

Brands and marketplaces heavily rely on AI for this task, but it’s not always the answer. 

After all, AliExpress [uses AI to personalize search results](https://www.alibabacloud.com/blog/alibaba-cloud-ai-search-solution-explained-intelligent-search-driven-by-large-language-models-helping-enterprises-in-digital_601971), but its system is far from perfect. 

AI can be a solid foundation for personalizing search results, but this foundation only maintains its integrity if it stands on the following five pillars. 

### Pillar #1: Intent-based personalization

Personalization happens when the user and the service provider have a complete rapport. 

In our case, the key to building this rapport (since a search engine is a machine) lies in Natural Language Processing, or NLP. 

NLP algorithms use [semantic network models](https://www.meilisearch.com/blog/semantic-search) to understand user intent, which makes personalization possible.

How does it work?

Essentially, semantic search targets the context behind words and analyzes structured data to understand the semantic meaning of the query. 

Amazon’s A9 search engine is probably the best example of this model in action.

Let’s take the key phrase *book emotional intelligence toddler. *

The keyword here is *toddler*, meaning we are not searching for an emotional intelligence guide for adults. 

The search engine picks up on that and shares exactly what we need: several book options for kids to read. 

![Amazon book search.png](https://unable-actionable-car.media.strapiapp.com/Amazon_book_search_d9ec09968e.png)

Image Source: [Amazon](https://www.amazon.com/)

We also tested our previous peanut butter example, and Amazon’s search engine gave only keto-friendly products as top results. 

![Amazon peanut butter search.png](https://unable-actionable-car.media.strapiapp.com/Amazon_peanut_butter_search_9969618bac.png)

Image Source: [Amazon](https://www.amazon.com/)

But do you still get [personalized recommendations](https://www.meilisearch.com/blog/personalization-recommendations) if there’s a typo in your query?

Let’s talk about it next. 

### Pillar #2: Typo tolerance

It’s hardly a pleasant experience to have to retype your query simply because you made a typo and got the wrong results. 

Search engines use the [latent semantic indexing method](https://www.meilisearch.com/blog/latent-semantic-indexing) of information retrieval to minimize such occurrences. 

LSI is robust against typos because it relies on semantic meaning to understand hidden concepts. 

And that’s precisely what you need, especially if you have a wide-range product offering. 

[Minipouce](https://www.minipouce.fr/) is a good example. 

Below, we intentionally made a typo in the word *ring *but still got relevant results. 

![Minipounce typo in search.png](https://unable-actionable-car.media.strapiapp.com/Minipounce_typo_in_search_9add534c79.png)

Image Source: [Minipouce](https://www.minipouce.fr)

Many products in the company’s catalog have similar names, which only increases the chance of making a typo. So Minipouce [used Meilisearch’s open-source version](https://www.meilisearch.com/blog/minipouce-top-grade-customer-experience) to optimize the product search for relevant results every time. 

### Pillar #3: Real-time adaptive learning

The results for a query should change dynamically during the interaction between the user and the search engine rather than simply relying on static filters. 

Why?

Interaction of any kind is never static.

A user’s preferences and behavior may change while searching for the right product or information, and true personalization must take this into account. 

That’s why it’s essential for a search engine to employ real-time adaptive learning. See how it works in a Meilisearch-powered search engine below.

![dynamic search with AI.gif](https://unable-actionable-car.media.strapiapp.com/dynamic_search_with_AI_b553f2e7b8.gif)

How does it work?

It’s a complex process, but we can break it down to three main steps:

* **Collecting and analyzing user data.** A search engine first collects information on user searches and related interactions to lay the ground for future personalization. 
* **Adjusting the algorithm.** The collected data and its analysis impact the ranking, related searches, and other search algorithm elements to provide the results based on particular intent. 
* **Adapting the results.** As a user further interacts with a search engine, it adapts its behavior to generate and prioritize relevant results to suit the user’s changing preferences. 

Of course, user behavior is not the only factor impacting the relevance of search results. 

The content a search engine is working with also matters. 

Consequently, so does the information retrieval method it uses. 

Let’s talk about it next. 

### Pillar #4: Correct information retrieval method

Information retrieval (IR) refers to the process of finding and retrieving relevant data. 

This process consists of three steps, which you can see below. 

* **Step #1:** Analyzing unstructured data, such as web pages and text documents. 
* **Step #2:** Indexing the data to make it structured, then processing the query to match the index. 
* **Step #3:** Ranking the query results based on relevance. 

![Process behind information retrieval methods.png](https://unable-actionable-car.media.strapiapp.com/Process_behind_information_retrieval_methods_3bdeb3ac9b.png)

You are already familiar with some IR methods, such as LSI mentioned above. 

And, as you may have noticed, they interpret the content a bit differently. 

[Semantic search](https://www.meilisearch.com/blog/choosing-the-best-model-for-semantic-search) focuses on a query’s intent and contextual meaning, which makes it particularly great for web search. 

LSI is a variation of semantic search that finds hidden concepts in words and documents. Thus, it’s ideal for tasks such as document clustering.  

There’s also [neural search](https://www.meilisearch.com/blog/neural-search) that employs deep neural networks (DNNs) to understand the context behind a search query. 

Neural search differs from the above methods in its complexity. It explores contextual relations on a more nuanced level, which makes it better for search engines involving conversational queries. 

There is also [hybrid search](https://www.meilisearch.com/blog/hybrid-search), a blend of all aforementioned models, which is often used in enhanced information retrieval systems. 

What about more real-life uses for each of these IR methods?

Here are some suggestions. 

![Use cases for information retrieval systems.png](https://unable-actionable-car.media.strapiapp.com/Use_cases_for_information_retrieval_systems_df58d9c62f.png)

These are, of course, just a few examples, as IRs can have way more applications. 

But there’s one thing that unites all of them. 

No matter what IR a search engine uses, it deals with personal user data. 

And that calls for privacy concerns. 

Let’s talk about that next. 


### Pillar #5: Respect for privacy

It’s no secret that AI-powered search engines rely on machine learning to provide the most accurate results. 

This, of course, implies that they analyze data from millions of searches and have to examine user data.

But how can you ensure privacy while maintaining the search engine’s ability to provide top-tier personalization?

The following strategies help get this job done. 

* **Data encryption:** protecting the data from third parties by encrypting it at rest and in transit. 
* **Access controls:** introducing multi-factor authentication and role-based permissions. 
* **Limited data sharing:** regulating data sharing with third parties. 
* **Federated learning:** training AI to learn from new system updates instead of raw user data.
* **Effective anonymization:** preventing user de-anonymization by hiding personally identifiable information. 

The key point, of course, is to ask for user permission to use any data they share and, if they change their mind later, to give them complete control over how their information is processed. 

## Build a strong foundation for personalized search

True personalization isn’t just about serving the results that *seem* tailored. 

Most so-called personalized searches fall short because they prioritize static logic, broad segmentation, and advertiser interests instead of user intent. 

But not all is lost. 

Grounding personalization in NLP, using correct information retrieval methods, and, most importantly, respecting privacy are the keys to delivering search experiences that truly matter.

Most personalized search experiences are a lie

We've all marveled at the capabilities of large language models (LLMs) like ChatGPT, Gemini, or DeepSeek, witnessing their ability to generate coherent and often insightful text. However, alongside this power, we've also encountered their limitations, particularly their tendency to "hallucinate" or generate incorrect information. This isn't because they're designed to store facts, but rather because they're trained to predict the next word based on patterns in vast amounts of text, relying on a kind of "muscle memory" rather than a factual knowledge base.

## The problem of hallucination and limited context

Many known cases show that this is a problem that needs to be addressed. One of them was the real-world example of [lawyers](https://gunnercooke.com/ai-fake-cases-and-the-courts-a-cautionary-tale-for-the-legal-profession/) who, relying solely on an LLM, presented fabricated case citations in court, only to find out that all the information given to them by the LLM was false. This highlights the critical need for LLMs to access and accurately cite external, reliable information.

The recurring question then becomes: **how do we leverage the power of LLMs with our own domain-specific or business-specific data?**

One approach to connect LLMs with specific data is to provide them with context directly within the prompt. This is a good approach, although it can only go so far. While models like Google's Gemini are increasingly capable of handling larger contexts, there's a limit to how much information an LLM can effectively process and utilize within a single prompt. 

Another method is [fine-tuning](https://www.meilisearch.com/blog/fine-tuning-vs-rag), where you further train an LLM on your specific dataset. This is quite useful too, but unfortunately, fine-tuning is resource-intensive, requiring significant time and data, making it impractical for frequently updated information.

## The solution: retrieval-augmented generation (RAG)

The most effective solution to these challenges is Retrieval Augmented Generation (RAG). In short, RAG tells the model “before you start talking, search for the answer among these documents, and then talk”. Think of RAG as equipping your LLM with the skills of a librarian and providing it access to a comprehensive library (your knowledge base or database). Instead of generating responses purely from its training data, the LLM first "looks up" relevant information from your provided sources and then uses that information to formulate an educated answer. This process not only improves the accuracy of responses but also allows the LLM to provide sources, directly combating the issue of hallucination.

![Explanation of how search works with and without RAG](https://unable-actionable-car.media.strapiapp.com/image4_0863a743e6.png)
*Figure 1: With RAG, the model will first search for an answer to the user’s query in a database, and then it formulates a response using the query and the retrieved documents.*

The RAG workflow typically involves three key steps:

1. **Query Transformation**: The user's query is optimized into an effective search query.  
2. **Information Retrieval**: The transformed query is used to search a database for relevant information.  
3. **Response Generation**: The retrieved results, along with the original prompt, are fed to the LLM to generate an informed response.

As an example, if the query from the user is “Hmm, I’m trying to find out the best places to eat in Paris, any ideas?”, a good query transformation model (step 1\) would turn it into “Restaurants in Paris, highest quality”. The information retrieval system (step 2) would return a list of documents or links containing names and ratings of several restaurants in Paris. The LLM would then formulate a verbal response (step 3\) using the modified query and the list of restaurants. Think of it this way, imagine your friend calls you on the phone and asks you for good restaurants in Paris. You first turn their question into a Google query, search for it in Google, look at the first 4 or 5 results, and then respond to them with a sentence or two, giving them recommendations based on what you found. That is exactly the RAG process.

While many associate RAG with vector databases and a separate re-ranking step after retrieval, solutions like Meilisearch simplify this process by integrating the entire workflow and stack. This blog post will focus on the crucial second step (**how to search properly**), while the next blog post will delve deeper into the entire RAG pipeline and explore how Meilisearch simplifies its deployment and maintenance.

## The tools: full-text and semantic search

Effective searching within a text database is paramount for successful RAG. Two prominent methods stand out:

* [**Full-text search**](https://www.meilisearch.com/blog/how-full-text-search-engines-work): This method focuses on matching keywords present in your query with those found in the search results.  
* [**Semantic search**](https://www.meilisearch.com/blog/semantic-search): This approach retrieves documents that are conceptually closest to your query, understanding the meaning behind the words, not just the words themselves.

The best of both worlds is

* [**Hybrid search**](https://www.meilisearch.com/blog/hybrid-search), which, as the name suggests, combines the strengths of both full-text and semantic search. Let's examine when each method excels before diving into how they can be combined.

### When is semantic search better?

Semantic search shines when the combined meaning of words is more important than individual keyword matches. Consider the query "Book a trip".

* An article titled "Books about trips" might be highly ranked by full-text search due to keyword overlap, but it's likely not what the user intends.  
* An article stating "Schedule your travels with us" is semantically more relevant, even if it shares fewer exact keywords. Semantic search would prioritize the latter, providing a much better result.

### When is full-text search better?

Full-text search is superior when you need precise keyword matches, especially for technical terms or specific identifiers. For instance, if your query is "ISO 9001 certification process":

* An article titled "ISO 9001:2025 Certification Checklist" is a perfect match due to the specific terminology.  
* An article like "How to achieve quality management compliance" might be semantically similar, but lacks the direct keyword specificity.

Full-text search is also valuable in cases where semantic similarity doesn't equate to the correct answer. For example, if the question is "What color is an apple?", semantic search might return "What color is an orange" as the most similar sentence. While similar, it doesn't provide the direct answer to the original question.

## How to combine the results: hybrid search scoring

Once we have results from both full-text and semantic searches, the challenge lies in effectively combining them into a unified, fair ranking. Meilisearch addresses this by assigning and combining scores based on their relevance.

For semantic search, the score is directly based on **similarity**. Similarity is a measure that's high for closely related pieces of text and low for disparate ones, directly reflecting how well the results conceptually match the query. For example, the similarity between the sentences “hello, how are you” and “hi, how’s it going” is high. The similarity between the sentences “Hello, how are you?” and “I like apples” is low.

For full-text search, RAG methods often employ traditional algorithms like BM25 or TF-IDF to calculate a relevance score for each document, reflecting how well its keywords match the query. Meilisearch, on the other hand, employs another method, an algorithm called [**bucket sorting**](https://www.meilisearch.com/blog/bucket-sort-guide). 

This process involves organizing documents into progressively smaller "buckets" based on a set of defined ranking rules (such as a relevance score, number of typos, or word proximity), with each subsequent rule acting as a tie-breaker until a precise order is achieved.

A key aspect of Meilisearch's approach is normalizing these scores. Initial scores from full-text and semantic search often have different ranges. For example, BM25 scores might range from 0 to 1, while semantic similarity scores could be concentrated within a narrower band like 0.5 to 0.8. To ensure comparability, semantic search scores are stretched and centered (a process called an **affine transformation**), bringing them into the same 0-1 range as full-text scores (Figure 2). This normalization ensures consistency across both types of search results, allowing for a unified relevance score. In other words, this allows the results from both search methods to compete fairly.

![Graphic demonstrating how results from full-text and semantic search get combined in hybrid search](https://unable-actionable-car.media.strapiapp.com/image3_074aa973e2.png)
*Figure 2: The results from Semantic search are stretched (zoomed and centered) in order to combine them with the results of FullText search.*

This consistent scoring across both search types is crucial. It enables you to decide, at query time, the "semantic ratio", meaning how much weight you want to give to semantic results versus full-text results when combining them.

## Benefits of hybrid search: precision and recall

To understand the power of hybrid search, let's briefly review the concepts of precision and recall, two fundamental metrics in information retrieval. The importance of each metric varies depending on the specific problem.

Imagine you have an email spam filter:

* **Recall** measures the percentage of all truly spam emails that your filter successfully identified as spam (meaning that the number of actual spam emails that still landed in your inbox was small).  
* **Precision** measures, among the emails your filter flagged as spam, what percentage were actually spam (meaning that the number of legitimate emails mistakenly sent to your spam folder was small).

In the context of searching for answers to a query in a database:

* **Recall** measures the percentage of all relevant articles (those containing the answer) that we successfully retrieved.  
* **Precision** measures the percentage of retrieved articles that actually contain the answer.

Let's illustrate with a numerical example: Suppose we have 1000 articles, and 100 of them answer the query "What documents do I need to open a company?". Our search model retrieves 90 articles. And out of those 90 articles, 60 contained the answer to the query.

* If, out of the 100 relevant articles, our model successfully retrieved 60, then the **recall** is 60/100=60%.  
* If, out of the 90 retrieved articles, 60 contained the answer and the other 30 did not, then the **precision** is 60/90≈66.67%.

![How Precision and Recall are calculated](https://unable-actionable-car.media.strapiapp.com/image1_9d405f3289.png)
*Figure 3: Example of precision and recall.*

### Hybrid search and precision-recall

**Recall**: Hybrid search significantly enhances recall. If your initial search is poor, a re-ranking step cannot magically fix it; it can only reorder the results it's given. I like to think of this as "rearranging deck chairs on the Titanic", since no matter how well you rearrange the results, the result won’t be good. Hybrid search, by combining the strengths of full-text and semantic approaches, effectively expands the initial pool of relevant documents, building a much stronger ship.

**Precision**: Hybrid search also bolsters precision. Full-text search naturally promotes high precision for queries requiring specific keyword matches, as it's difficult for a document with many exact word overlaps to be irrelevant. For those trickier edge cases where a document might share many words with the query but be on a different topic, semantic search steps in, ensuring that only truly related articles are prioritized.

By intelligently combining the strengths of both full-text and semantic search, hybrid search offers a powerful approach to information retrieval, ensuring that RAG systems have access to the most relevant and accurate information for generating insightful and reliable responses. In our next blog post, we'll delve deeper into the entire RAG pipeline and explore how Meilisearch simplifies its deployment and maintenance.

## Optimizing performance: binary quantization and arroy

Beyond the core logic of hybrid search, efficient vector management is crucial for large-scale RAG systems. This is where [**Binary Quantization**](https://www.meilisearch.com/blog/meilisearch-indexes-embeddings-7x-faster-with-binary-quantization) (BQ) comes in. BQ dramatically shrinks vector embeddings by converting 32-bit floats to compact 1-bit representations, significantly reducing disk space and memory usage. In short, binary quantization simplifies a number by only taking its sign. For example, the numbers 0.4, \-0.5, and 0.6 will be turned into \+1, \-1, and \+1. While this looks like a broad oversimplification, when we’re dealing with really long vectors of hundreds or thousands of entries, BQ really speeds things up in similarity calculations, while keeping most of the information.

![Binary quantization](https://unable-actionable-car.media.strapiapp.com/image2_8c97776ee1.png)
*Figure 4: Binary quantization turns numbers into their sign, effectively pushing them to the corners of a square. Notice that the distance between points changes slightly, but the calculations become much simpler.*

Meilisearch also leverages **Arroy**, its Rust-based vector store designed for efficient Approximate Nearest Neighbors (ANN) search. Nearest neighbors search is very effective, but it can be really slow, as many distances between pieces of text in the embedding need to be compared. Arroy provides several speeding up techniques that help the model ‘guess’ where the closest articles are in the embedding.

![Regular nearest neighbors search vs Arroy](https://unable-actionable-car.media.strapiapp.com/image5_176e03d5cc.png)
*Figure 5: Regular nearest neighbors search is effective, but too many distances need to be calculated. Arroy uses different techniques to organize data, so that much fewer distances need to be calculated. In this example, a grid is used, and only the neighboring cells are searched, but in general, many other techniques, including tree-based techniques, are used to organize the data for effective and fast nearest neighbors search.*

This powerful combination of Binary Quantization and Arroy allows Meilisearch to handle vast knowledge bases with remarkable indexing speed and performance, ensuring your RAG system delivers fast, accurate answers even for high-dimensional embeddings. 

## Explore Meillsearch’s capabilities today! 

The power of RAG lies not just in the LLM's ability to generate text, but in its foundation of accurate and relevant information retrieval. As we've seen, embracing hybrid search, which skillfully blends the specificity of full-text search with the contextual understanding of semantic search, is key to overcoming the challenges of hallucination and delivering precise answers. With Meilisearch, implementing this crucial search layer into your RAG pipeline becomes remarkably straightforward, allowing you to focus on building truly intelligent applications. 

Ready to supercharge your RAG system with unparalleled search relevance? 

[Explore Meilisearch's capabilities today](https://www.meilisearch.com/cloud) and stay tuned for our next article, where we'll delve into building the complete RAG pipeline with Meilisearch, simplifying its deployment and maintenance.

Mastering RAG: unleashing precision and recall with Meilisearch's hybrid search

What is vector search? Complete guide [2025]

Personalized search is the key to keeping short-attention-span folks interested in your product or service. Users expect results that feel made for them, and personalized search is the key to meeting that expectation — and turning search into a conversion engine.

Here’s what we’ll cover:

* What personalized search means and how it’s different from traditional search.
* How it works behind the scenes: from data collection to result ranking.
* What types of data power it and why they matter.
* Benefits and challenges to consider before implementing it.
* Use cases across industries like e-commerce, streaming, and SaaS.
* Examples in action that demonstrate how personalized search is already everywhere.
* How to implement it using Meilisearch’s high-performance, developer-friendly toolkit.


## What is personalized search?

As the name suggests, personalized search is when search results are tailored to the searchers based on the latter’s unique characteristics, behaviors, and preferences. 

It refers to the search method where your demographics and behavior — past searches, purchases, browsing activity, location, and interests — are used to present the most relevant search results for a search query you initiate.

Unlike traditional search, which delivers the same results to everyone using the same query, personalized search relies on user data to adapt what each person sees in the results. 

You’ve likely seen this in action on platforms like Netflix (suggested titles based on your viewing history), Spotify (custom playlists tailored to your listening history), or Amazon (product recommendations based on your purchasing history).

Today, delivering generic results isn’t just outdated — it’s a missed opportunity. Users expect relevance as the default. 

The better you get at providing it, the more likely they are to click, buy, and stay.

## How does personalized search work?

Personalized search combines behavioral insights and machine learning to make real-time changes to what users see.

![How personalized search works.png](https://unable-actionable-car.media.strapiapp.com/How_personalized_search_works_14ee43ed10.png)

Here’s a high-level look at how [AI-powered personalized search](https://www.meilisearch.com/blog/ai-powered-search ) works:


### 1. Data collection

The system gathers user-specific signals, such as search history, clicks, the pages users visit, location, and past purchases.


### 2. User modeling

These signals are then used to build a user profile. This user profile could be:

* Session-based (just the current visit)
* Persistent (across different sessions)
* Anonymous or authenticated


### 3. Query handling

Once the user submits a search query, the algorithm interprets it within the context of the user’s profile created in the previous step, adjusting the results based on perceived preferences.


### 4. Ranking & re-ranking

Finally, the system layers personalization on top of relevance scoring. Even if a product matches a keyword exactly, its position can shift depending on what is most relevant *for that user*.

Behind the scenes, features such as collaborative filtering (recommending items based on similar users’ preferences), content-based filtering (suggesting items similar to past content the user has interacted with), and hybrid models determine what rises to the top. Many systems also employ heuristics to facilitate fast decision-making and predict user needs.

Meilisearch supports these processes through its flexible API, which allows the integration of user-specific filters and [vector-based recommendations](https://www.meilisearch.com/blog/personalization-recommendations ) without compromising on speed, even at scale.


## What data is used in personalized search?

Personalized search can draw from a wide range of data signals. Some are implicit (inferred through behavior) while others are explicit (user-defined preferences).

Here are the common types of data used:

* Search history, like past searches and interactions
* Click, browse, and time-spent-on behavior
* Device type and OS
* Geolocation for localized results
* Time of day/week
* Account information (if logged in)
* Language and filter preferences
* Social signals (likes, shares, follows)
* Interaction with filters, facets, or categories

The richness of your personalization depends on the data you can ethically and transparently collect without violating user trust or data privacy regulations. This user data then informs algorithms to deliver the best results for the highest user satisfaction.


## What is the difference between personalized and traditional search?

The main difference between personalized and traditional search is how results are selected and ranked.

Traditional search relies heavily — or entirely — on matching query terms with indexed content using a static algorithm. Everyone sees the same result for the same input. It’s predictable and uniform, but it's also less relevant.

Personalized search, by contrast, incorporates user data and adjusts results based on the individual user. This provides unique results and improves relevance, but adds complexity, especially around data management, compliance, and UX consistency.

Here’s a quick side-by-side comparison.

![What is the difference between personalized and traditional search_.png](https://unable-actionable-car.media.strapiapp.com/What_is_the_difference_between_personalized_and_traditional_search_b9f818eebf.png)

Personalized search’s reliance on user data introduces variability and complexity. 

Even though it may require more setup, it also returns more value, especially in customer-facing products and services.


## What are the benefits of personalized search?

Personalized search delivers measurable benefits across UX, engagement, revenue, and brand performance.

Here are the key advantages:

* **Higher customer engagement:** Users spend more time interacting with your site or product because of the greater relevance of search results.
* **Boosted revenue:** Relevant suggestions improve click-through rates and sales for most brands.
* **Lower bounce rates:** Users find what they’re looking for faster, so they stay on your site longer.
* **Surfaced niche content:** Personalization helps uncover niche or under-ranked content that users might otherwise miss.
* **Improved retention and loyalty:** A personalized experience builds long-term trust and brand affinity.
* **Better monetization opportunities:** You can highlight relevant high-margin or preferred content/products more effectively.

These benefits drive tangible business outcomes, resulting in a revenue boost of [up to 40%](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-value-of-getting-personalization-right-or-wrong-is-multiplying) for companies employing personalization. 


## What are the challenges of personalized search?

Personalized search is not without its drawbacks across user data privacy, scalability, and complexity.

![Challenges of personalized search.png](https://unable-actionable-car.media.strapiapp.com/Challenges_of_personalized_search_1b30b4a33b.png)

Implementing personalized search involves hurdles such as:


### 1. Data privacy and compliance

Personalized search often relies on collecting user data, raising GDPR, CCPA, and similar concerns.

Use opt-in consent, clearly communicate the type of data collected, and anonymize or aggregate data wherever possible. Consent management should be baked into your UX from day one.


### 2. Cold start problem

New users or fresh content lack enough data to be included in personalization, taking search back to its traditional state.

You can overcome this by combining contextual signals (e.g., from geolocation or device) with collaborative or content-based filtering. You can also use fallback strategies like popular or trending content to give your personalized search algorithm a foundation.


### 3. Performance and scalability

Real-time re-ranking and personalization at scale are computationally intensive, which raises concerns about costs and scalability.

Use caching, vector databases, or edge computing to maintain speed without sacrificing relevance.


### 4. Over-personalization

Too much personalization can trap users in a ‘filter bubble,’ where they're only shown results they’re likely to agree with, limiting content diversity and discovery.

A good solution for this would be to blend personalized and generic results. For example, use sections like ‘For You’ and ‘Trending Now.’ You could also allow manual user adjustment for a more human-in-the-loop approach.


### 5. Integration complexity

Personalization involves combining multiple data sources, APIs, systems, and service layers, which can be pretty complex.

Choose modular customizable tools like Meilisearch that make it easier to implement personalization in stages for streamlined integration.

Balancing the benefits and drawbacks of personalized search will take you beyond basic search into new realms of possibility.


## What are the use cases for search personalization?

Personalized search has different use cases and applications across various industries. 

![What are the use cases for search personalization_.png](https://unable-actionable-car.media.strapiapp.com/What_are_the_use_cases_for_search_personalization_dbdca13b7e.png)

Some areas where personalized search shines are:


### E-commerce

In e-commerce, personalized search helps users discover what they're likely to purchase. By analyzing previous purchases, browsing history, and the most frequently accessed categories or brands, marketplace search results prioritize items that match users' purchasing habits, thereby predicting their choices.

You can also include price sensitivity and availability to create more relevant, context-based product recommendations.


### Media streaming

Media platforms employ personalization to display content that users are likely to enjoy, based on their viewing history, preferred genres, or browsing behavior. 

For example, the platform could suggest a new period-piece series after the user completes a historical show, or optimize search results to highlight content with familiar actors or directors.

This approach reduces choice fatigue, improves user retention, and helps surface lesser-known but contextually relevant content that might otherwise be buried in extensive catalogs.


### Travel booking

Travel search personalization tailors results by analyzing details from previous searches, favorite spots, airlines, hotel categories, or even loyalty programs. 

For example, if you’re a frequent flyer, you might find business class options at the top of your search results. A returning user could be shown offers for destinations similar to those they’ve visited.


### SaaS platforms

Personalized search in SaaS applications can prioritize the most relevant documentation, feature, or dashboard based on a user's role, past use, or recent activity. 

For instance, developers might first receive content regarding API references, while analytics tools may be the most relevant content for marketers.

Such role-based tailoring speeds up onboarding, reduces support overhead, and enables users to derive value from the product sooner, thereby improving employee engagement and retention.


### Online education

Learning management systems and online learning platforms use personalized search to suggest courses, modules, or learning pathways to students based on their interests, skill levels, and learning history. Whether resuming a suspended course or exploring a new subject, students can use personalization to discover relevant resources, certifications, or subsequent modules.


## What is an example of personalized search?

Let’s bring personalized search use cases to life with some real-world examples.


### 1. ‘Pizza near me’

Let’s say you are searching for good pizza places in your location using the keyword ‘pizza near me.’

Without personalization, a system, such as a food delivery app or Google, will show all registered and available pizza places on the app. 

Limited personalization may result in filtering based on a 5- or 10-mile radius around your location, such as Google’s ‘See results closer to you.’

![Results closer to you Google feature.png](https://unable-actionable-car.media.strapiapp.com/Results_closer_to_you_Google_feature_e9aed062ff.png)

Source: [Google](https://www.google.com/?gl=us)

With actual real-time personalization, the app will show and rank pizzerias you’ve ordered from before, that are open now, and fit your exact delivery radius. 


### 2. Online shopping

Online marketplaces like Amazon and Trendyol aim to offer customers the widest selection of lifestyle products. First visitors will likely receive ‘random’ suggestions, perhaps only personalized to their device type or geolocation.

After a few rounds of online ‘window shopping’ or order placing, the results become more targeted, prioritizing your favorite categories, brands, preferred price range, or products you viewed last time.

![Marketplace product recommendations.png](https://unable-actionable-car.media.strapiapp.com/Marketplace_product_recommendations_b03c36171e.png)

Source: [Trendyol](https://www.trendyol.com/)

Personalization reduces friction, makes discovery intuitive, and accelerates action in every case. 

But how do you get all this for your system? 

Meilisearch makes it easy!


## How to implement search personalization

Now that we’ve covered the ‘why’ and ‘what,’ let’s look at the ‘how.’

With Meilisearch, real-time search, relevance tuning, and fast indexing enable personalized search through features like filters, [vector search](https://www.meilisearch.com/blog/what-is-vector-search), and multi-tenancy.

Here’s how to approach it:


### With localized content

Personalized search with localized content uses geosearch or filters to prioritize results based on user location, language, or locale. 

Meilisearch’s [sorting features](https://www.meilisearch.com/docs/learn/filtering_and_sorting/sort_search_results) and [geospatial search capabilities](https://www.meilisearch.com/docs/learn/filtering_and_sorting/geosearch) enable this.

For example, to sort correctly indexed restaurants based on their proximity to the Eiffel Tower, the following Python script for the `_geoPoint` sorting function may come in handy:


```python
client.index('restaurants').search('', {
  'sort': ['_geoPoint(48.8561446,2.2978204):asc', 'rating:desc']
})
```


For documents to be correctly sorted based on their geographic location, ensure they contain a valid `_geo` field.


### With recent searches

Perhaps the most widely used personalization criterion is the user’s past searches. Using the user’s recent activity in the search system, the application can suggest and provide the most relevant results. 


## Bringing it all together: personalized search for real impact

Personalized search is no longer a ‘nice-to-have’; it’s a competitive necessity.

It transforms users' interactions with and feelings about your platform by delivering natural, effortless, and uniquely relevant search results. 

The result? Higher engagement, better retention, and stronger conversion metrics.


Personalized search: Deliver ultra-relevant results that convert

How do you search in a database with LLMs?

Picture a customer support agent who can simultaneously analyze a blurry screenshot, decipher a frustrated voice message, and cross-reference technical documentation to deliver the perfect solution.

Traditional RAG systems have transformed AI’s ability to retrieve and process text. However, they struggle when customers interact using images, audio, or video.

Multimodal RAG shatters this limitation by creating unified vector spaces where a single query can pull insights from any combination of data types, transforming how we build intelligent applications. The result isn't just better search, it's AI that finally understands the world as humans experience it.

## What is multimodal RAG?

Life doesn’t provide information in neat, single streams. When troubleshooting a complex machine, you don’t just read a manual—you scan diagrams, listen to a technician’s voice note, and watch a video of the problem. Traditional search and AI systems, designed for text alone, often struggle with this mix.

### Understanding multimodal retrieval-augmented generation

Each piece is converted into a vector, a mathematical fingerprint. These vectors exist in a high-dimensional space, where connections form by capturing meaning across different formats, not just matching words.

For example, in customer support, a user might upload a blurry photo of an error screen, describe the issue in chat, and attach an audio clip of a strange noise. A multimodal RAG system retrieves relevant troubleshooting steps from a knowledge base containing annotated images, audio samples of faults, and text documents. It then crafts a response using all three sources.

### Key differences between multimodal RAG and traditional RAG

Traditional RAG systems work like expert librarians who only read books—great with text but unable to process other formats. Multimodal RAG acts like a detective: it reads, listens, and observes, piecing together clues from all sources.

- **Data types:** Traditional RAG handles only text. Multimodal RAG processes images, audio, video, and text simultaneously.
- **Embedding space:** Multimodal RAG projects all data types into a shared vector space, allowing a text query to retrieve images or audio clips.
- **Retrieval power:** It supports “any-to-any” retrieval. For example, a voice query can bring up a diagram, or a photo can retrieve a relevant manual paragraph.

In healthcare, multimodal RAG can analyze an X-ray, doctor’s notes, and a patient’s spoken symptoms together. Traditional RAG would only process the written report.

## How multimodal RAG works

Multimodal RAG works like a jazz ensemble: each part contributes its unique input, combining to create richer results than any single source alone. Imagine yourself as a developer building a search system that handles words, images, audio, and video seamlessly.

### The three stages of multimodal RAG: retrieval, fusion, and generation

![rag pipeline architecture diagram](https://unable-actionable-car.media.strapiapp.com/rag_pipeline_architecture_diagram_56e14cbdbd.avif)



While a text-only RAG system might struggle, a multimodal RAG pipeline handles the variety of data effectively through three stages:

1. **Embedding:** Before retrieval begins, the system preprocesses each input (whether text, image, audio, or video) by encoding it into a vector representation using [powerful multimodal embedding models](https://meilisearch.com/blog/choosing-the-best-model-for-semantic-search). These [embeddings](https://meilisearch.com/blog/what-are-vector-embeddings) capture the semantic and contextual essence of every asset to enable meaningful comparisons across data types.
2. **Storing:** Once the embeddings are created, they are stored in a [vector database](https://meilisearch.com/blog/what-is-a-vector-database) (like Meilisearch, FAISS, Milvus, or Pinecone) alongside document metadata or links to the original files. This step ensures that multimodal data can be efficiently indexed and retrieved by similarity, regardless of modality.
3. **Retrieval:** The system converts each query into a vector. It compares these vectors against a large library of encoded data. For example, Meilisearch stores and retrieves vectors for images, audio, and text. This allows a search like “a red button with a blinking light” to return both textual guides and annotated photos.
4. **Fusion:** After retrieval, the system combines information from different modalities. Cross-modal attention mechanisms align the meaning of a spoken description with visual details in a photo or technical language in a manual. This stage matches nuances, like pairing the melody of a song with the mood of a painting.
5. **Generation:** An LLM synthesizes a response using the fused context. The output might be a step-by-step troubleshooting guide referencing the user’s photo and a technical manual, or a property description blending listing photos with sales data.

**This process enables multimodal RAG to answer complex questions that text-only systems cannot.**

### Exploring the role of embeddings in multimodal search

Embeddings act as universal translators, converting text, images, audio, and video into points in a shared mathematical space. This allows a voice query to retrieve a relevant image or a photo to surface a matching product description.

Embeddings also excel in [federated search](https://meilisearch.com/blog/what-is-federated-search) scenarios. A query can merge results from image and text indexes, normalizing relevancy scores across modalities.

<Callout intent="note">
	
Meilisearch supports [user-provided embeddings](https://www.meilisearch.com/docs/learn/ai_powered_search/search_with_user_provided_embeddings), letting you use models like CLIP or LLaVA to generate vectors externally and index them with your documents.
	
Meilisearch’s hybrid search combines semantic similarity (via embeddings) with classic keyword matching. This ensures a search for “blue running shoes” returns both visually similar products and those with matching descriptions. **This approach creates a search experience that feels intuitive and precise, improving recall and relevance.**
	
</Callout>

## Building a multimodal RAG pipeline

Every strong system starts with a solid foundation. Building a multimodal RAG pipeline is more like conducting a jazz ensemble than laying bricks. Each data modality brings its own unique tone. The real value comes from how they interact.

Let’s explore the practical choreography of data, models, and search, where every step depends on trade-offs and the quirks of your data.

### Data preparation for multimodal RAG: preprocessing and embedding

Imagine a SaaS company with a vast knowledge base: product manuals in PDF, customer screenshots, audio logs from support calls, and video tutorials. The first challenge isn’t technical; it’s understanding the stories these artifacts tell and translating them into a language your AI can grasp.

- **Text:** Clean text and break into passages, then use a model like BERT or a sentence transformer to embed the text as vectors:

```python
from sentence_transformers import SentenceTransformer

model = SentenceTransformer('all-MiniLM-L6-v2')
passages = ["How to reset your dashboard", "Uploading CSV errors"]
# if saving to JSON:
vectors = model.encode(passages).tolist()
```

- **Images:** Convert images (screenshots, diagrams) into L2-normalized embeddings using CLIP (be sure to specify 'device' as a named argument):

```python
import clip
from PIL import Image
import torch

device = "cuda" if torch.cuda.is_available() else "cpu"
model, preprocess = clip.load("ViT-B/32", device=device)
model.eval()  # set eval mode

img = preprocess(Image.open("error_screenshot.png")).unsqueeze(0).to(device)
with torch.no_grad():
    emb = model.encode_image(img)
    emb = emb / emb.norm(dim=-1, keepdim=True)  # L2-normalize
# emb is a (1, 512) normalized tensor, ready for search/indexing
```

- **Audio:** Transcribe and embed support calls using Wav2Vec, making sure to move data to GPU (if available), and aggregate final features with mean-pooling and normalization:

```python
import torchaudio
import torch
from transformers import Wav2Vec2Processor, Wav2Vec2Model

device = "cuda" if torch.cuda.is_available() else "cpu"
processor = Wav2Vec2Processor.from_pretrained("facebook/wav2vec2-base-960h")
model = Wav2Vec2Model.from_pretrained("facebook/wav2vec2-base-960h").to(device)
model.eval()

waveform, rate = torchaudio.load("call.wav")  # [channels, samples]
inputs = processor(waveform.squeeze().numpy(), sampling_rate=rate, return_tensors="pt")
inputs = {k: v.to(device) for k, v in inputs.items()}

with torch.no_grad():
    hidden_states = model(**inputs).last_hidden_state    # (1, seq_len, hidden_size)
    audio_emb = hidden_states.mean(dim=1)                # (1, hidden_size)
    audio_emb = audio_emb / audio_emb.norm(dim=-1, keepdim=True)
# audio_emb is a pooled, normalized vector for each utterance
```

- **Video:** Extract informative frames, embed each with CLIP (as above). For summary-level retrieval, generate a transcript using an ASR engine and embed as text.

<Callout intent="tip">
	
	Automate enrichment (like tagging, timestamping, linking images to passages) as early as possible in the pipeline.
	
</Callout>

### Setting up the retrieval system: indexing and search optimization with Meilisearch

After embedding, leverage Meilisearch for unified indexing and rapid hybrid querying:

**1. Upload the documents with user-generated embeddings**:Each vector should be stored alongside its respective document.

```bash
curl -X POST 'http://localhost:7700/indexes/support_docs/documents' 
  -H 'Content-Type: application/json' 
  --data-binary @support_docs_with_embeddings.json
```

Each document in `support_docs_with_embeddings.json` should include a field like:

```json
{
  "id": "IMG_0474",
  "type": "image",
  "metadata": { "description": "error screenshot" },
  "vector": [0.348, 0.123, 0.582, ...]
}
```

**2. Configure a vector field in Meilisearch**Define your vector field in `vectorIndexes` (typical for Meilisearch ≥ v1.2):

```bash
curl -X PATCH 'http://localhost:7700/indexes/support_docs/settings' 
  -H 'Content-Type: application/json' 
  --data-binary '{
    "vectorIndexes": {
      "vector": {
        "type": "hnsw",
        "params": { "M": 8, "efConstruction": 64 }
      }
    }
  }'
```

**3. Prepare a hybrid search request:**

```bash
curl -X POST 'http://localhost:7700/indexes/support_docs/search' 
  -H 'Content-Type: application/json' 
  --data-binary '{
    "q": "dashboard spinning wheel",
    "vector": [0.032, 0.89, ...],
    "limit": 10
  }'
```

For pure vector search (no keyword text), pass `q` as an empty string:

```bash
curl -X POST 'http://localhost:7700/indexes/support_docs/search' 
  -H 'Content-Type: application/json' 
  --data-binary '{
    "q": "",
    "vector": [0.032, 0.89, ...],
    "limit": 10
  }'
```

For hybrid search using Meilisearch's internal embedder:

```bash
curl -X POST 'http://localhost:7700/indexes/support_docs/search' 
  -H 'Content-Type: application/json' 
  --data-binary '{
    "q": "dashboard spinning wheel",
    "hybrid": {
      "embedder": "your-embedder-name",
      "semanticRatio": 0.5
    },
    "limit": 10
  }'
```

<Callout intent="note">
	
	Meilisearch provides official SDKs and client libraries for most major programming languages and frameworks.
	
</Callout>

### Integrating the generation component: prompt engineering and model selection

With your most relevant (multimodal) evidence in hand, prepare a coherent prompt for your LLM. Here’s an illustrated example:

```python
# 1) retrieve (using SDK to make code shorter)
query_emb = embed_query(user_question)
results = meili.index("support_docs").search({
  "vector": query_emb,
  "limit": 5
})
# 2) build the context
context = "nn".join([hit["text"] for hit in results["hits"]])

# 3) call the LLM
prompt = f"""You are a helpful assistant. Use ONLY the following context to answer.

Context:
{context}

Question: {user_question}
Answer:"""

response = openai.ChatCompletion.create(
  model="gpt-4",
  messages=[{"role":"user","content":prompt}]
)
print(response.choices[0].message.content)
```

Order evidence for clarity (text → image → other media), trim any irrelevant details, and iteratively refine your prompt template for optimal results.

<Callout intent="tip">

Ready to supercharge your search experience? Deliver lightning-fast search results that will keep your users engaged and boost your conversion rates. 

[Explore Meilisearch Cloud](https://meilisearch.com/cloud)

</Callout>

## Choosing the right vector database for your multimodal application

Selecting a vector database is like picking the right vehicle for a cross-country journey. The terrain—your data, queries, and latency needs—guides the best choice. Here’s a quick comparison:

- **Meilisearch:** Combines [full-text and vector search](https://meilisearch.com/blog/full-text-search-vs-vector-search). Great for ecommerce, web apps, [enterprise search](https://meilisearch.com/blog/enterprise-search), and hybrid user experiences.
- **FAISS:** Blazing-fast, highly customizable, supports C++/Python. Ideal for research and large-scale retrieval.
- **Milvus:** Scalable, cloud-native, supports hybrid search. Suited for enterprise, IoT, and video search.
- **Pinecone:** Managed service, easy scaling, metadata filtering. Fits SaaS and production deployments.

A SaaS team building real-time product search might choose Meilisearch for its hybrid capabilities and developer-friendly API. A research lab processing petabytes of scientific images could rely on FAISS for its speed and flexibility. The decision shapes what’s possible for your users.

## Multimodal RAG: unlocking the future of intelligent, human-like search

Multimodal RAG represents more than just a technical advancement. It's a fundamental shift toward AI systems that understand information the way humans do, across all formats and contexts.

With Meilisearch's vector search capabilities and sub-20ms response times, you can start building these sophisticated multimodal experiences today.

The future of search isn't just about finding information; it's about understanding it completely, and that future is already within reach.



Multimodal RAG: A Simple Guide

Most developers spend weeks building retrieval systems from scratch, wrestling with vector databases and embedding models, only to discover their LLM still hallucinates answers.

The irony? While everyone talks about RAG as the solution to grounding AI responses in real data, the implementation complexity often defeats the purpose entirely.

[LlamaIndex](https://www.llamaindex.ai/) changes this equation by collapsing what used to be a month-long engineering project into a few dozen lines of code, without sacrificing the sophistication that makes retrieval-augmented generation actually work. Instead of building infrastructure, you can focus on what matters: turning your company's knowledge into intelligent, accurate responses that your users can trust.

## Understanding LlamaIndex and RAG for advanced search applications

LLMs are great at generating text, but they can make mistakes or use outdated info. RAG fixes this by connecting language models to up-to-date, relevant data.

### Introducing LlamaIndex: your toolkit for building RAG pipelines

If RAG is the strategy for smarter LLM applications, LlamaIndex is the toolkit that makes it happen. Building a [RAG system](https://www.meilisearch.com/blog/how-to-build-a-rag-pipepline) is like preparing a gourmet meal: you need quality ingredients (your data), the right tools (to process and understand that data), and a recipe (the workflow). LlamaIndex provides all of this.

Formerly GPT Index, LlamaIndex is an open-source framework that simplifies building RAG systems. It offers components that manage your data’s journey, from ingestion to indexing to integration with LLMs for answer generation.

### Core components of a LlamaIndex RAG system: from raw data to smart answers

![rag pipeline architecture diagram](https://unable-actionable-car.media.strapiapp.com/rag_pipeline_architecture_diagram_56e14cbdbd.avif)



Turning a raw document into a context-aware answer with LlamaIndex follows five clear stages:

- **Loading:** Bring your data into the system. LlamaIndex supports many document loaders, making it easy to import PDFs, text files, websites, APIs, and more.
- **Indexing:** Convert loaded documents into [vector embeddings](https://meilisearch.com/blog/what-are-vector-embeddings), numerical representations capturing the meaning of your text. This helps find relevant information even if queries use different words.
- **Storing:** Save your index and metadata to avoid reprocessing large datasets every time you start your application.
- **Querying:** When a user asks a question, LlamaIndex transforms the query into an embedding and searches the indexed data for the most relevant text chunks. It can also apply [advanced search strategies](https://meilisearch.com/blog/introducing-hybrid-search) to improve results.
- **Generation:** The retrieved context and user query go to an LLM, which crafts a human-like answer grounded in your specific data.

**This workflow ensures the LLM always accesses precise, relevant information.**

### Key benefits of using LlamaIndex for RAG development

Using LlamaIndex for RAG projects streamlines development. It simplifies complexity by abstracting data connection, transformation, and retrieval details. This lets developers build sophisticated RAG applications with less boilerplate code.

LlamaIndex’s modular design lets you swap components—embedding models, vector stores, or LLMs—to fit your needs and budget. This flexibility is crucial as AI technology evolves.

For tech leaders and developers, this means faster iteration, more reliable applications, and the ability to deliver intelligent, data-driven experiences.

## Building your foundational LlamaIndex RAG pipeline: a step-by-step guide

Let’s build a LlamaIndex RAG system that answers questions using your own documents. We’ll go step by step, from project setup to asking your first queries. This guide uses Meilisearch documentation files as an example, but you can apply these steps to any documents.

### Setting up your development environment for a LlamaIndex RAG project

Start by preparing a Node.js environment. Make sure you have **Node.js version 18 or higher (20+ recommended)**. Check your version with:

```bash
node -v
```

Create a new project directory and initialize it:

```bash
mkdir rag-tutorial
cd rag-tutorial
npm init -y
```

This creates a folder named `rag-tutorial`, moves you into it, and sets up a basic Node.js project.

Update your `package.json` to use modern JavaScript modules and TypeScript. It should include:

- `"type": "module"` for ES module syntax
- Scripts to run TypeScript files with `tsx`

Example:

```json
{
  "name": "rag-tutorial",
  "version": "1.0.0",
  "type": "module",
  "main": "rag-llamaindex.ts",
  "scripts": {
    "start": "tsx rag-llamaindex.ts",
    "interactive": "tsx interactive-rag.ts",
    "test-setup": "tsx test-setup.ts"
  }
}
```

Install the necessary npm packages:

```bash
npm install llamaindex @llamaindex/openai @llamaindex/readers dotenv tsx
```

<Callout intent="note">
	
	Starting with Node.js v23.6.0, developers can run TypeScript files directly without manual transpilation. This feature became default in v24.1.0.
	
	
</Callout>

Each package serves a purpose:

- `llamaindex`: Core LlamaIndex.TS library
- `@llamaindex/openai`: Connects to OpenAI models for text generation and embeddings
- `@llamaindex/readers`: Tools for reading data from various sources, including `SimpleDirectoryReader`
- `dotenv`: Loads environment variables from a `.env` file to keep API keys secure
- `tsx`: Runs TypeScript files directly in Node.js

Set up your OpenAI API key by creating a `.env` file in your project root:

```text
OPENAI_API_KEY=your_actual_openai_key_here
```

Replace the placeholder with your real key to keep credentials private.

Create folders for your data and index storage:

```bash
mkdir data storage
```

- `data` will hold your documents
- `storage` will save the processed index

Add a `tsconfig.json` file for TypeScript configuration:

```json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "strict": true,
    "skipLibCheck": true
  }
}
```

With this setup, your environment is ready. Next, bring in your data.

### Ingesting and loading diverse data sources effectively with LlamaIndex

Now, feed your LlamaIndex RAG system some knowledge. For this tutorial, we use Markdown (`.mdx`) files from Meilisearch documentation, but you can use PDFs, web pages, or database entries.

Copy your `.mdx` files into the `data` directory. For example:

```bash
# Copy documentation files to data directory
# find ../documentation -name "*.mdx" -exec cp {} ./data/ ;
```

Ensure your `data/` folder contains the files you want to index.

Use `SimpleDirectoryReader` from `@llamaindex/readers/directory` to read these files. In your main TypeScript file (e.g., `rag-llamaindex.ts`), import and use it like this:

```typescript
import "dotenv/config";
import { SimpleDirectoryReader } from "@llamaindex/readers/directory";

const reader = new SimpleDirectoryReader();
const documents = await reader.loadData("./data");
console.log(`📄 Loaded ${documents.length} documents.`);
```

Each file becomes a `Document` object containing its content and metadata.

LlamaIndex supports many data formats. You can combine multiple sources into a single index to create a comprehensive knowledge base.

With your documents loaded, you’re ready to index them.

### Indexing data for optimal retrieval: creating your first LlamaIndex vector store

Make your documents searchable by meaning, not just keywords. Vector indexing organizes text using numerical vectors that capture semantic meaning.

Set it up like this:

```typescript
import { VectorStoreIndex, storageContextFromDefaults, Settings } from "llamaindex";
import { openai, OpenAIEmbedding } from "@llamaindex/openai";
```

- `VectorStoreIndex`: Manages the vector index
- `storageContextFromDefaults`: Handles where your index is saved
- `Settings`: Configures language and embedding models
- `openai` and `OpenAIEmbedding`: Set up OpenAI’s LLM and embedding models

Configure your models:

```typescript
Settings.llm = openai({ 
  model: "gpt-4o",
  temperature: 0.0,
  maxTokens: 1024
});

Settings.embedModel = new OpenAIEmbedding({
  model: "text-embedding-ada-002",
});
```

This setup ensures **factual, focused answers and efficient embeddings**.

Build your index with:

```typescript
console.log("🔄 Creating vector embeddings... (this may take a few minutes)");
const storageContext = await storageContextFromDefaults({ persistDir: './storage' });
const index = await VectorStoreIndex.fromDocuments(documents, { storageContext });
console.log("💾 Index built and saved to storage.");
```

This process:

- Splits documents into smaller chunks for better retrieval
- Converts each chunk into a vector using the embedding model
- Stores vectors and text chunks in the index
- Saves the index to the `./storage` directory for future use

Depending on your data size, this may take a few minutes. Once done, your system can answer questions.

<Callout intent="success">
Looking for the best search experience in town? Deliver lightning-fast search results that will keep your users engaged and boost your conversion rates.
[Explore Meilisearch Cloud](https://meilisearch.com/cloud)
</Callout>

### Implementing the query engine and generating responses with your basic LlamaIndex RAG

With your data indexed, ask questions and get intelligent answers. LlamaIndex’s query engine handles this smoothly.

Get your `VectorStoreIndex` and create a query engine:

```typescript
const queryEngine = index.asQueryEngine({ 
  similarityTopK: 5
});
```

The `similarityTopK` parameter controls how many relevant chunks the engine retrieves per query.

Ask a question like this:

```typescript
const question = "What is Meilisearch and what are its main features?";
const result = await queryEngine.query({ query: question });

console.log("📖 Answer:");
console.log(result.toString());
```

Behind the scenes:

- Your question converts into a vector
- The engine finds the most relevant document chunks
- These chunks form the context
- LlamaIndex builds a prompt including your question and context
- The LLM generates an answer grounded in your data
- The answer is returned and displayed

Here is an example of the final result against the Meilisearch documentation:

![untitled](https://unable-actionable-car.media.strapiapp.com/untitled_361dc96a33.gif)



This ensures **answers are accurate and based on your documents, not just the LLM’s pre-trained knowledge**.

Now you have a working LlamaIndex RAG pipeline. Next, let’s improve efficiency for repeated use.

### Persisting and efficiently reusing your LlamaIndex for subsequent RAG operations

LlamaIndex can persist the index, saving time and cost. Indexing involves chunking documents and making API calls for embeddings, which can be resource-intensive. You don’t want to repeat this every time you run your app.

Persistence uses `storageContext` and a `loadOrBuildIndex` function. When building the index:

```typescript
const storageContext = await storageContextFromDefaults({ persistDir: './storage' });
const index = await VectorStoreIndex.fromDocuments(documents, { storageContext });
```

This saves the index to `./storage`.

On later runs, try loading the saved index first:

```typescript
try {
  const storageContext = await storageContextFromDefaults({ persistDir: './storage' });
  const index = await VectorStoreIndex.init({ storageContext });
  console.log("✅ Loaded existing index from storage.");
} catch (error) {
  console.log("📚 Building new index from documentation files...");
  // ...build logic
}
```

If a saved index exists, it loads instantly—no need to reprocess documents or embeddings.

Benefits include:

- **Cost savings** by avoiding repeated embedding API calls
- **Time savings** since loading is faster than rebuilding
- **Efficiency** as heavy processing happens only once
- **Automatic management** with minimal effort

This persistence makes your LlamaIndex RAG system practical and efficient, ensuring your initial processing investment pays off over time.

With these steps, you’ve built a foundational LlamaIndex RAG pipeline: from setup and data ingestion to indexing, querying, and efficient reuse. This base is ready for further enhancements as your needs grow.

## Optimizing your LlamaIndex RAG for production-level performance and relevance

You’ve built your foundational LlamaIndex RAG pipeline. Now, refine every step—from data preparation to delivering insights—to maximize performance, relevance, and efficiency. This process requires understanding how all components work together to create a system that is not only smart but truly effective.

### Master advanced data chunking strategies for superior LlamaIndex RAG context

Think of your documents as vast libraries and chunks as the pages or paragraphs your LLM reads. Giving the LLM an entire book for one question is overwhelming, but a single, out-of-context sentence isn’t enough. **Chunking finds the “just right” snippet for effective understanding.**

#### Summary retrieval

Default chunking (around 512 tokens) is a good start, but production systems need more nuance. One effective method is **decoupling retrieval and synthesis chunks**:

- Embed concise summaries of each feature section for broad retrieval.
- When a query matches a summary, pull detailed, sentence-level chunks from that section for the LLM to synthesize the answer.

This approach is like using a table of contents to find the right chapter, then reading specific paragraphs within it.

#### Structured retrieval

**Structured retrieval** adds another layer. If your data has metadata—such as product categories, version numbers, or author tags—use it to narrow the search space before semantic search begins. For example, if a user asks about a feature in “version 3.0,” filter to only v3.0 documents. This pre-filtering makes vector search faster and more focused.

Also, use **dynamic chunk retrieval**. Different questions require different amounts of context:

- Simple factual queries may need only a few small chunks.
- Complex comparative questions benefit from more or larger chunks.

Adjusting the number and size of retrieved chunks based on query complexity ensures the LLM gets the optimal context, improving answers and reducing token usage.

### Enhance LlamaIndex RAG retrieval with reranking and hybrid search techniques

After retrieving candidate chunks using vector similarity (often controlled by `similarityTopK`), the process isn’t complete. Vector search finds semantically similar content, but “similar” doesn’t always mean “most relevant.”

[**Hybrid search**](https://www.meilisearch.com/blog/hybrid-search) **combines semantic search with keyword-based search**. For example, if a user looks for documentation on a specific API error code like “ERR_CONN_RESET_005,” pure vector search might find general connection error documents. A hybrid approach uses the exact error code as a keyword to pinpoint documents containing that string, then applies semantic similarity to understand context. This blend often yields more precise results, especially for queries with specific entities or codes.

Refining the initial set of retrieved chunks is also important. After fetching the top K chunks, you can rerank them based on:

- Direct keyword overlaps.
- Scores from a smaller, faster model assessing relevance to the question.

This ensures the LLM receives the best possible context.

“Multi-step searches” further improve retrieval. An initial query identifies a broad topic or document set, then a focused follow-up query (possibly generated by the LLM) dives deeper into that subset. This coarse-to-fine approach enhances final context quality.

### Select optimal embedding models and LLMs for your specific LlamaIndex RAG use case

Choosing the [right embedding model](https://meilisearch.com/blog/choosing-the-best-model-for-semantic-search) and LLM is like selecting the engine and transmission for a car—it affects performance, cost, and suitability. There is no universal best; it depends on your needs.

Experiment with different embedding models and dimensionality. The `text-embedding-ada-002` model from OpenAI balances performance and cost well.

However, if your data is specialized—such as legal or medical texts—a domain-specific fine-tuned model may perform better. Higher-dimensional embeddings capture more nuance but increase computational and storage costs, so balance is key.

For the generative LLM, `gpt-4o` offers a strong mix of cost and quality. For high-volume, low-latency chatbots, smaller, faster, and cheaper LLMs may be more suitable, even if they sacrifice some response nuance. For complex research or analysis, investing in a top-tier model can be worthwhile. Adjust settings like `temperature` (e.g., `0.0` for factual Q&A) and `maxTokens` to fine-tune behavior and control costs.

Consider an ecommerce example:

- Use a fast, affordable LLM for simple product questions.
- Use a more powerful model and higher `similarityTopK` for complex comparisons.

Conditional model selection optimizes both user experience and operational costs.

### Evaluate your LlamaIndex RAG pipeline with key metrics and benchmarking for success

After refining chunking, retrieval, and model selection, evaluate your system regularly to ensure it performs well.

Focus on these key areas:

- **Retrieval quality**: Are retrieved chunks relevant? Use human evaluation to review top K documents for sample queries and check if they are on-topic and informative.
- **Generation quality**: Are LLM answers accurate, coherent, and faithful to context? Avoid hallucinations. Human judgment is crucial early on.
- **End-to-end performance**: How fast does the system respond? Include embedding, retrieval, and generation time. Latency matters for user-facing apps.
- **Cost-effectiveness**: Track API calls for embeddings and generation. Check if optimizations like chunking or `similarityTopK` tuning reduce costs without hurting quality.

For example, a RAG system helping developers navigate a codebase might succeed if:

- Developers spend less time searching for information.
- Answers to technical questions are more accurate.
- Users provide positive feedback.
- Fewer follow-up questions go to human colleagues.

Benchmark against a “golden dataset” of human-verified question-answer pairs to measure progress. Tweaking components like embedding models, chunk size, or prompts should improve these benchmarks.

## Your next steps in the RAG revolution

Building a production-ready LlamaIndex RAG system transforms how your applications handle knowledge retrieval and generation. It makes it move beyond static responses to dynamic, context-aware interactions with your data.

The combination of LlamaIndex's streamlined development experience with robust production patterns creates a foundation that scales from prototype to enterprise deployment.



Meilisearch latest news and company updates