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.

LlamaIndex RAG tutorial: step-by-step implementation

Here's a counterintuitive truth about modern AI development: the most sophisticated language models often perform worse than simpler alternatives when deployed in production.

Companies spend thousands of dollars fine-tuning state-of-the-art models, only to discover that a lightweight approach using RAG delivers better results at a fraction of the cost.

The fine-tuning vs RAG debate isn't just about technical preferences. It's about understanding when complexity becomes your enemy and when simplicity scales. Most teams make this choice based on outdated assumptions about what "better AI" actually means in real-world applications.

## Fine-tuning vs RAG: understanding the key differences

Deciding how to adapt a LLM involves choosing between fine-tuning, which builds deep expertise into the model, and Retrieval-Augmented Generation (RAG), which links the LLM to the latest relevant information. Both aim to enhance the LLM’s capabilities but use different approaches.

### What is retrieval-augmented generation?

Imagine a top student, not going back to class, but instead gaining access to an endless, well-organized library and a team of expert researchers. That’s the idea behind RAG.

Instead of embedding all knowledge within the model, RAG lets the LLM pull relevant information from external sources right before responding. These sources can include your company’s knowledge base, real-time news feeds, or large document collections.

![RAG workflow diagram explanation](https://unable-actionable-car.media.strapiapp.com/RAG_workflow_diagram_explanation_53f23eb06c.avif)

RAG works by:

- Breaking external data into manageable pieces and converting each into a numerical “embedding” that captures its meaning.
- Storing these [embeddings](https://meilisearch.com/blog/what-are-vector-embeddings) in a specialized [vector database](https://meilisearch.com/blog/what-is-a-vector-database) designed for fast searches.
- Turning the user’s query into an embedding.
- [Searching the database](https://www.meilisearch.com/blog/how-do-you-search-in-a-database-with-llm) to find the most relevant information.
- Including this retrieved data in the prompt given to the LLM, providing up-to-date, contextual knowledge.
- Having the LLM craft a response using both its built-in understanding and the freshly retrieved information.

<Callout intent="note">
	Keep in mind that RAG responses may take a bit longer to generate as the system needs time to search through external databases and retrieve relevant information before the LLM can craft its response. The exact delay depends on your RAG system's architecture and the size of your knowledge base.	
</Callout>

**RAG grounds responses in specific, current, and verifiable facts, reducing the risk of outdated or inaccurate answers.** It updates knowledge in real time without changing the model itself.

<Callout intent="note">
	Curious about implementing a RAG workflow in practice? Explore this step-by-step guide on [how to build a RAG pipeline](https://www.meilisearch.com/blog/how-to-build-a-rag-pipepline).	
</Callout>

### What is fine-tuning?

Take the same highly educated graduate. Fine-tuning sends him to a specialized training program. You take a pre-trained model and train it further on a smaller, carefully chosen dataset tailored to your field or task. This could include areas such as legal analysis, medical interpretation, or your company’s unique language.

The goal is not just to add facts, but to adjust the model’s internal workings so it becomes an expert in your area. This process involves providing targeted examples and tweaking its internal settings while preserving its broad knowledge. The result is a model that understands the subtle details of its specialty, often improving accuracy significantly.

It is especially powerful for **shaping the model’s output style, tone, and formatting rules**, enabling consistent answers. Fine-tuning also leads to low-latency inference: because curated knowledge is baked directly into the model, there’s no delay from pulling external data.

Additionally, fine-tuned models operate independently of external databases, **providing advantages in privacy, offline capability, and cost-effective serving at scale**. If you need your AI to “think and speak” like an expert, or to deliver high precision on repetitive, clearly defined tasks, fine-tuning delivers that lasting edge.

<Callout intent="note">	
	Looking for an easy way to start fine-tuning your own OpenAI models? Check out [OpenAI’s fine-tuning guide](https://platform.openai.com/docs/guides/fine-tuning) for straightforward, step-by-step instructions and best practices to optimize your models for your unique use case.
</Callout>

## Choosing the right approach: fine-tuning or RAG?

Deciding between fine-tuning and Retrieval-Augmented Generation (RAG) means selecting the best tool for your specific challenge. Each method has strengths that fit different scenarios. Consider these key factors to choose the best approach (or a combination) for your project and users.

![](https://unable-actionable-car.media.strapiapp.com/fine_tuning_versus_rag_50c84257a9.avif)

### Data freshness and update frequency

If your AI assistant discusses stable topics like historical events, fine-tuning on curated texts creates a consistent, knowledgeable expert. The information becomes part of the model.

For real-time tasks like stock market analysis or breaking news summaries, the data changes constantly. Fine-tuning would require frequent retraining, which is impractical. RAG excels here by connecting to dynamic external databases. It pulls the latest articles, market data, or updates as they happen. **RAG keeps information current without constant retraining, making it ideal for applications needing up-to-the-minute data.**

### Domain specificity and task complexity

Consider how specialized your AI must be. For a virtual legal aide needing deep contract law knowledge, fine-tuning is best. It helps the model absorb proprietary data, jargon, and reasoning patterns. This creates an expert that understands facts, style, tone, and domain rules.

**Fine-tuning suits tasks requiring high precision in stable, complex fields like medical text interpretation or compliance.**

RAG works well for broader domains or when expertise involves gathering information from many sources. For example, a customer support bot for a fast-changing SaaS product benefits from RAG. It accesses the latest FAQs, troubleshooting guides, and community discussions, providing relevant answers even for new issues.

**RAG focuses on finding the right information rather than becoming the ultimate expert.**

### Cost and resource considerations

Fine-tuning large models demands a significant upfront investment (a bunch of GPU computes time for each training). It also requires careful curation, cleaning, and annotation of high-quality, domain-specific datasets, which can slow progress. However, once fine-tuned, the model runs efficiently without relying on external retrieval.

RAG lowers the barrier to entry by starting with a pre-trained base model. The main costs involve building and maintaining retrieval infrastructure like vector databases and indexing pipelines. While it avoids frequent retraining, ongoing inference costs may be higher due to retrieval steps. Fine-tuned models risk becoming outdated as base LLMs improve, requiring further investment. **RAG offers flexibility and long-term efficiency in fast-changing environments.**

### Data governance and security implications

Data location and access matter, especially in regulated industries or with sensitive information.

Fine-tuning simplifies data governance and privacy. The entire process can stay within your infrastructure, embedding knowledge in the model. Once deployed, it can operate offline without external access. This helps comply with regulations like GDPR or HIPAA and gives tighter data control.

RAG interacts with external knowledge bases, which introduces privacy and security concerns. You must ensure retrieval doesn’t expose sensitive data and that external sources are secure and compliant. Using third-party APIs or databases subjects you to their security and data policies. **RAG requires robust retrieval pipelines and careful data residency and access controls to maintain security.**

### Performance, latency, and scalability

User experience depends on response speed and accuracy. Fine-tuned models deliver **faster responses** because answers come directly from internal knowledge. This low latency suits real-time applications like chatbots or instant translation. Fine-tuned models also offer high precision for trained tasks.

RAG adds a retrieval step before generating responses, which increases delay. Even with fast search engines, RAG responses can be 30-50% slower than fine-tuned models. This delay may be acceptable for detailed reports or research but can hinder real-time use. Scaling RAG requires managing both the LLM and retrieval system, including vector databases and indexing.

## Hybrid approaches: combining fine-tuning and RAG

**Combining fine-tuning and RAG creates a more powerful system** that leverages the strengths of both approaches.

Fine-tuning provides deep domain expertise and specialized language understanding, while RAG ensures access to current, relevant information. This hybrid approach delivers enhanced contextual understanding, improved accuracy, and more nuanced outputs. For example, a financial advisory bot can combine expert knowledge with real-time market data.

**Implementing hybrid systems requires careful design,** beyond simply adding RAG to a fine-tuned model. Emerging strategies include Domain-Adaptive Pre-training (DAP), Retrieval Augmented Fine-Tuning (RAFT), and Hybrid Instruction-Retrieval Fine-Tuning.

Real-world applications, such as Document Retrieval-Augmented Fine-Tuning (DRAFT) for compliance assessment, show promising results with 7% improved correctness over baseline models.

<Callout intent="note">
	Success depends on preventing fine-tuned models from over-relying on internal knowledge while ignoring retrieved information.
</Callout>

## Making the right choice for your AI strategy

The fine-tuning vs RAG decision ultimately comes down to understanding your specific use case, data requirements, and long-term goals.

While fine-tuning excels in static domains requiring deep expertise and consistent outputs, RAG shines when you need dynamic, up-to-date information with transparent sourcing.

Fine-tuning vs RAG: Choosing the right approach

How to build a RAG pipeline: А step-by-step guide

[In Meilisearch v1.6](https://www.meilisearch.com/blog/meilisearch-1-6), we revolutionized search by combining the precision of full-text search with the intelligence of AI. This hybrid approach isn't just another feature—it's a fundamental reimagining of how search should work. Today, we'll pull back the curtain on our implementation and show why Meilisearch's unique approach to hybrid search delivers superior results.

Join us as we explore the mechanics of hybrid search, examine conventional implementation methods, and reveal how Meilisearch's innovative solution raises the bar for search relevance.

## What is hybrid search?

Search is always about finding the documents that are the most relevant to a user’s query.

Hybrid search is about combining the results of two complementary approaches to search: full-text search and semantic search.

[Full-text search](https://www.meilisearch.com/blog/how-full-text-search-engines-work) analyzes the words that appear in a query in a lexical manner, excelling at correcting typos and completing incomplete queries. It is also fast, and its results are easy to understand in retrospect.

[Semantic search](https://www.meilisearch.com/blog/semantic-search) leverages Large Language Model (LLM) technology to understand the meaning of words in the query. It excels at finding documents that contain synonyms to the user’s query and other similar concepts.

Both search approaches build a list of relevant documents according to their respective methods. Hybrid search combines these lists to produce a final list of results.

The golden question is, how to combine them?

![Diagram containing two lists of documents as shapes (squares for full-text, diamonds or triangles for semantic), and an arrow with an interrogation mark that produces a new list of documents containing both kinds of shapes](https://unable-actionable-car.media.strapiapp.com/how_to_merge_55aea77e87.png)

## The traditional way of mixing results is flawed

The traditional method of mixing the results from both lists is called [_Reciprocal Rank Fusion_ (RRF)](https://medium.com/@devalshah1619/mathematical-intuition-behind-reciprocal-rank-fusion-rrf-explained-in-2-mins-002df0cc5e2a), because it considers the **rank** of the documents in each list of results, and uses that as a basis to compute the final list of results.

In this context, the rank of the document refers to its position in the list of results, indicating how close it appears to the top.

For example, in a list of 20 documents, the result ranked first can be attributed 20 points. RRF can then attribute points to documents in each of the lists, sum the points for each document, and reorder the documents accordingly. Here’s a [detailed explanation](https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking) about an implementation of RRF on Azure AI Search.

However, this method of mixing results is flawed, because to function properly, it assumes that documents from all the lists of results are of comparable relevance: that is, all the documents in all lists are “good documents” that we want to return.

![Keyword search. Pikachu uses "imprecise query". It's super effective!](https://unable-actionable-car.media.strapiapp.com/pikachu_hybrid_search_f4f9e6c29f.jpg)

But, like Pokémons, each search method is vulnerable to different types of search queries. Covering for the weakness of the other method is the whole point of mixing them!

So let’s say you’re using a query that is fine for semantic search, but gives underwhelming results for keyword search. Using RRF, you might get some variant of the following:

![Illustrated example of the downfall of rank fusion](https://unable-actionable-car.media.strapiapp.com/RFF_merge_789ff4e216.png)

Recursive rank fusion is like wasting fine chocolate by mixing it with spoiled milk!

To address this issue, we require additional information about the documents listed in our results.

## Ranking is not enough: Scoring documents

The main idea is that you can score _how_ relevant a document is from 0 (not relevant at all) to 1 ("perfect” match), independently of its rank in the list.

Naturally, documents closer to the top of the list are more relevant, but the first document might be anywhere between 0 and 1. Then, you compare the scores in both lists and rank the documents across both lists that way.

Fortunately, Meilisearch already scores documents for full-text search (for more details about this, refer to [our previous article about scoring](https://www.meilisearch.com/blog/from-ranking-to-scoring)), and semantic search natively ranks documents depending on how similar they are to the query (although the details are complicated).

So we have a score for both full-text search and semantic search, but can we compare them?

## Making the scores comparable

When you have two scores ranging from 0.0 to 1.0, it can be tempting to compare them, but for this to work, similarly relevant documents must be scored similarly with both methods.

One difficulty that arises when performing this comparison is that the models used in semantic search tend to use only a portion of the full vector space they could use, resulting in vectors that have a similarity of at least 0.5 even for texts that appear entirely dissimilar. Furthermore, even very similar texts might be capped in similarity around 0.7, which will cause them to rank lower than good full-text results.

Fortunately, Meilisearch provides the tools to solve that particular problem. Meilisearch allows you to perform an affine transformation to the scores of the semantic search, so that the scores can be offset by the observed mean similarity between vectors, and the results that are packed around that mean similarity can be spread more in the 0.0, 1.0 space. For more details, refer to [the documentation on the](https://www.meilisearch.com/docs/reference/api/settings#distribution) `distribution` [field](https://www.meilisearch.com/docs/reference/api/settings#distribution).

For models known to Meilisearch (such as OpenAI models), a suitable default distribution is already applied to configured embedders, so users don’t have to configure it themselves!

With this operation, our scores are comparable, and depending on the query, the method that produces the most relevant documents will be favored by the hybrid search

![Failing example, running with Meilisearch, yields better results](https://unable-actionable-car.media.strapiapp.com/meili_merge_9bb48a7b7d.png)

## What else goes into making hybrid search right?

Scoring documents is a decisive relevancy advantage of Meilisearch over the traditional approach based on Reciprocal Rank Fusion, but there are a lot more aspects involved in making hybrid search right:

- We developed our bespoke vector store, [arroy](https://github.com/meilisearch/arroy), to leverage our database backend (LMDB) and meet our performance target. Arroy supports Approximate Nearest Neighbor search, multiple distances, native document filters, and binary quantization. Arroy doesn’t block a reader while writing or a writer while reading, and allows for incremental updates.
- We kept flexibility in mind with the mantra of making easy things simple, and hard things possible: users that are new to hybrid search can quickly setup an embedder with our default provider and configuration, but users can also carefully optimize their embedding process with multiple supported provider (or even the ability to provide your own with [REST embedders](https://www.meilisearch.com/docs/learn/ai_powered_search/configure_rest_embedder) and [user-provided embeddings](https://www.meilisearch.com/docs/learn/ai_powered_search/search_with_user_provided_embeddings)) and [document templates](%5B%3Chttps://www.meilisearch.com/docs/learn/ai_powered_search/document_template_best_practices%3E%5D(%3Chttps://www.meilisearch.com/docs/learn/ai_powered_search/document_template_best_practices#sample-document%3E)) to customize how documents are turned into text to embed.
- Best-in-class full-text search engine, seamlessly integrated with semantic search, with support for efficient and expressive [sorting and filtering](https://www.meilisearch.com/docs/learn/filtering_and_sorting/working_with_dates) of documents.

Search is foundational; it needs to be rock solid to reliably serve the needs of your application. Meilisearch’s hybrid search implementation scores documents to merge results while preserving their relevancy. Scores also power the [federated search](https://www.meilisearch.com/docs/learn/multi_search/multi_search_vs_federated_search#what-is-federated-search%3F), a generalized version of semantic search that unifies results from multiple lists of intermediate hits.

Our users use federated search to perform hybrid searches across multiple vector stores, frequently combining image and text search requests.

## Why Meilisearch's hybrid search stands apart

Meilisearch's innovative approach to hybrid search goes beyond simply combining full-text and semantic search results.

By implementing a sophisticated scoring system instead of traditional rank fusion, carefully calibrating score comparability, and building a robust technical foundation with arroy, we've created a hybrid search solution that consistently delivers more relevant results.

This thoughtful implementation ensures that the strengths of each search method are preserved while compensating for their weaknesses, setting a new standard for search relevance in modern applications.

Why traditional hybrid search falls short (and how we fixed it)

When we discovered that 70% of our team was already using AI tools daily—but with wildly varying results—we knew we needed a systematic approach. Not another vague "AI transformation" initiative, but a practical framework for separating AI hype from real value.

Here's the concrete system we developed to evaluate and implement AI tools across our company and what we've learned so far.

## The surprising reality we uncovered

When we began our AI journey at Meilisearch, we expected to find pockets of adoption. Instead, we discovered something more interesting: **universal experimentation but inconsistent value**.

### The adoption paradox

Our company-wide assessment revealed that every single team member had already experimented with AI tools, with an impressive 70% incorporating them into daily workflows.

![image.png](https://unable-actionable-car.media.strapiapp.com/image_40601b4a7c.png)

![image2.png](https://unable-actionable-car.media.strapiapp.com/image2_a867a1c935.png)

But the numbers told only half the story:

Despite high adoption rates, team sentiment about AI's value showed surprising variation. Many were using the tools but questioning whether they were truly beneficial or just creating a new kind of busywork.

![image3.png](https://unable-actionable-car.media.strapiapp.com/image3_67ad5244d9.png)

![image4.png](https://unable-actionable-car.media.strapiapp.com/image4_4a6d31dcca.png)

This gap between usage and perceived value became our first critical insight.

### Four critical insights that changed our approach

<Callout intent="note">

**Previously Shared Insights:**

- 🧠 [𝐃𝐨𝐞𝐬 𝐀𝐈 𝐛𝐞𝐜𝐨𝐦𝐞 𝐥𝐞𝐬𝐬 𝐯𝐚𝐥𝐮𝐚𝐛𝐥𝐞 𝐚𝐬 𝐲𝐨𝐮𝐫 𝐞𝐱𝐩𝐞𝐫𝐭𝐢𝐬𝐞 𝐠𝐫𝐨𝐰𝐬?](https://www.linkedin.com/posts/gillianmcauliffe_aitransformation-professionalgrowth-futureofwork-activity-7292477225889660928-7UXm/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAXkmQUBijf17cl9IKQZhMWLN67r9deqvAc) How your relationship with AI changes at different levels of expertise.
- 🔍 [**Unlocking Our AI Knowledge-Sharing Blueprint:**](https://www.linkedin.com/posts/gillianmcauliffe_aitransformation-futureofwork-knowledgesharing-activity-7290061146634485762-fm1D/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAXkmQUBijf17cl9IKQZhMWLN67r9deqvAc) Understanding what people want to know to get started.
- 🤝 [Preserving Human Connection in an AI-Enhanced Workplace](https://www.linkedin.com/posts/gillianmcauliffe_aitransformation-teamwork-futureofwork-activity-7287036478092632066-boTG/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAXkmQUBijf17cl9IKQZhMWLN67r9deqvAc): Will we lose what's special about our teams by bringing in AI?

</Callout>

Through in-depth interviews across all departments, we uncovered patterns that wouldn't have appeared in simple usage statistics:

1. 🌿 **Environmental impact:** Our teams have raised thoughtful concerns about the environmental impact of AI.
2. **🤔 The expertise paradox:** As team members' domain expertise increases, their perception of AI's value often follows a U-curve. Beginners find AI helpful for learning, experts leverage it as a powerful accelerator, but those in the middle sometimes find it more hindrance than help.
3. **🎯 The trust dilemma:** AI's "inconsistent brilliance" creates a fundamental trust issue—sometimes transformative, sometimes bafflingly off-target—making teams reluctant to integrate it into mission-critical processes.
4. **✨ Creative acceleration:** Despite skepticism, nearly everyone reported dramatic improvements in creative processes—from eliminating writer's block to transforming editing workflows.
5. 🔭 **Prompt sophistication gap:** Most team members were still using basic prompting techniques, unaware of how dramatically their results could improve with more advanced approaches.

This investigation revealed we weren't facing an adoption problem but a **value extraction challenge**. People were using AI tools but were not consistently getting meaningful results. We needed a framework to help teams identify where AI could actually create value—and where it was just adding complexity.

## ⚖️ Our solution: the AI value scoring matrix

Based on these insights, we developed a systematic framework to cut through the AI hype cycle. Rather than chasing the latest tools or models, we created a data-driven method to identify where AI could create genuine value for our specific context.

**The value scoring matrix:** Each potential AI use case is evaluated across multiple weighted dimensions aligned with our organizational priorities. This transforms the abstract question of "where should we use AI?" into a concrete, comparable set of scores.

**Our Six Critical Dimensions:**

| **Dimension** | **Weight** | **What We Assess** | **Why It Matters** |
|--------------------|------------|--------------------------------------------------------------------|----------------------------------------------------------------------------------|
| Feasibility | 20% | Implementation difficulty with current skills/resources | Prevents us from chasing technically impressive but impractical applications |
| Revenue Impact | 25% | Potential to increase top-line growth | Ensures AI initiatives contribute to business success |
| Data Readiness | 15% | Availability and quality of necessary data | Many AI projects fail due to data issues, not technology limitations |
| Time to Value | 15% | Speed to tangible results | Builds momentum with quick wins |
| Risk | 10% | Potential challenges or downsides | Protects against unintended consequences |
| Internal Impact | 15% | Number of people/teams benefiting | Prioritizes broad improvements over narrow optimizations |

Here's how we applied this framework to evaluate potential AI initiatives:

This systematic approach cut through subjective debates about which AI tools to adopt, replacing them with evidence-based decisions that aligned with our strategic priorities.

## Early results: beyond the AI hype cycle

Our scoring matrix has already transformed how we approach AI at Meilisearch:

### 1\. From endless options to strategic focus

Instead of drowning in the constant stream of new AI products, our teams now have a clear filter: "Does this tool address one of our high-scoring use cases?" This has dramatically reduced distractions and FOMO while increasing meaningful adoption.

### 2\. Balanced investment: "Ferraris" and "cargo ships"

We're strategically balancing our implementation:

- **"Ferrari" projects:** Quick wins that generate excitement and momentum (e.g., automating our internal documentation updates)
- **"Cargo ship" initiatives:** Substantial efforts with transformative potential (e.g., reimagining our customer support workflow with AI assistance)

### 3\. Creating a dedicated space for experimentation

One crucial lesson: AI adoption requires protected time. We've integrated dedicated "AI exploration blocks" into our work schedules and upcoming offsite, focusing specifically on our highest-scoring use cases.

### 4\. Addressing real concerns

The scoring matrix naturally incorporates ethical considerations through the risk dimension. We've operationalized this by:

- Favoring smaller, more efficient models when possible
- Prioritizing open-source options that allow us to run models locally
- Building in time for human review of AI-generated content

## The framework in action: a case study

After applying our scoring matrix to use cases identified through internal discussions, we quickly surfaced high-impact opportunities. One standout example was improving our code review process—specifically, reducing time to first review for pull requests (PRs).

This use case scored highly across multiple dimensions:

- High feasibility with existing tools
- Direct impact on development velocity
- Clear time-to-value metrics
- Broad internal impact across engineering teams

We implemented CodeRabbit, an AI-powered code review assistant that provides immediate PR feedback. While maintaining our essential human review process, the tool identifies common issues and provides automated PR descriptions. After a two-week trial period, we measured both quantitative metrics and gathered team feedback.

The results validated our scoring framework's prediction:

- Decreased average time to first review
- Improved PR documentation quality
- Positive team adoption and engagement
- Cumulative time savings across the engineering organization

## What's next: your turn

We're sharing this framework because we believe it can help other organizations cut through AI hype and focus on value creation.

The key to successful AI adoption isn't about having the fanciest tools—it's about having the clearest framework for identifying where AI truly adds value in your specific context.

🚀 How we're making AI work at Meilisearch

## What is RAG, and why should you care?

Every day, millions of people interact with ChatGPT, Claude, and other large language models, fundamentally changing how we interact with computers. The appeal is obvious: instead of learning specific interfaces, users can simply communicate in natural language. The machine adapts to the human, not the other way around.

This shift has organizations scrambling to create similar experiences with their own data. Whether it's building a support chatbot that understands product documentation, crafting an assistant that writes personalized emails, or developing an internal tool to help employees access company knowledge, they all require the same foundation: giving LLMs access to proprietary information.

Enter Retrieval Augmented Generation (RAG), a workflow that's deceptively simple in concept:

1. User asks a question
2. The system retrieves relevant documents based on that question
3. LLM generates an answer using those retrieved documents as context

When implemented correctly, RAG provides more accurate, up-to-date responses while reducing hallucinations. But here's where most engineers go wrong: they default to vector databases without considering whether that's actually the optimal approach.

## The engineer's shortcut: Vector databases

The typical RAG implementation looks something like this:

```
User Question → Convert to Embedding → Query Vector DB → Retrieve Similar Documents → Generate Answer

```

It makes intuitive sense. Vector embeddings capture semantic meaning, so similar concepts cluster together in the vector space. By converting questions and documents to the same embedding space, you can find relevant information even when the exact keywords don't match.

Engineers love this approach because it seems elegant. You don't need complex query parsing or keyword matching – just transform everything to vectors and let similarity algorithms do the work.

But this shortcut creates two critical problems that significantly degrade the quality of the results.

## Problem 1: Unrefined queries lead to irrelevant results

The first major issue occurs at the initial step: we take the raw user query, convert it directly to an embedding, and use that to retrieve documents.

Think about what happens when you use Google. You don't always search with your actual question – you distill it to key terms that are more likely to yield relevant results. If you want to know "What's the best way to organize React components in a large project?", you might search for "React component organization best practices large applications."

LLMs excel at this kind of query refinement, but in the standard vector DB approach, we skip this crucial step. The embedding captures the semantic meaning of the original question, but that doesn't always align with the optimal search query.

## Problem 2: Vector search sacrifices precision for recall

The second problem is more fundamental: vector similarity search is strong at recall but often weaker at precision compared to traditional full-text search.

Vector search excels at finding conceptually related content (recall) - documents that discuss similar topics, even if they use different terminology. However, it's less effective at pinpointing exactly what you need (precision).

Full-text search, on the other hand, prioritizes precision. When exact keyword matches exist, they're usually highly relevant. The trade-off is that full-text search might miss conceptually similar content that uses different terminology.

This explains why many RAG systems that rely exclusively on vector databases end up implementing additional re-ranking steps after initial retrieval. It's also why vector databases increasingly add full-text capabilities – they recognize the inherent limitations of pure vector search.

## A more human approach to RAG

Since we're trying to build systems that mimic human intelligence, shouldn't we structure our RAG pipelines to mirror how humans actually search for information?

When people need to find information, they:

1. Reframe their question into effective search terms
2. Use search engines optimized for retrieving relevant information
3. Scan results to identify the most useful content

A better RAG design would follow this pattern:

```
User Question → LLM Refines Into Search Query → Hybrid Search (Combining Full-text and Semantic) → Retrieve Relevant Documents → LLM Generates Answer

```

This approach addresses both problems:

1. The LLM refines the user's original question into an optimized search query
2. Hybrid search combines the precision of full-text search with the recall of semantic search

## The solution: Simpler (and better) RAG with search engines

Here's my contrarian take: instead of jumping to vector databases for RAG, start with a quality search engine that combines full-text and semantic capabilities.

Modern search engines like Meilisearch offer hybrid search functionality that delivers better overall relevance than pure vector retrieval. They're also:

- Easier to deploy and maintain
- Optimized for fast queries at scale
- Designed with relevance as the primary objective
- More intuitive for debugging search results

For most RAG applications, the workflow becomes much simpler:

1. The user submits a question
2. LLM transforms that question into an effective search query
3. The search engine retrieves relevant documents using hybrid search
4. LLM generates a response using those documents as context

This approach aligns with how humans actually search for information, leveraging the strengths of both LLMs and search technology while avoiding unnecessary complexity.

## The power of simplicity in RAG: Back to search basics

Vector databases certainly have their place in the machine learning ecosystem, but they're not always the best foundation for RAG systems. By taking a step back and considering how humans search for information, we can build more effective, simpler RAG architectures.

The next time you're designing a RAG system, consider whether a good search engine might be the better choice. Your users (and your future self maintaining the system) will thank you.

Why you shouldn't use vector databases for RAG

AI-powered search: What you need to know [2025]

The 10 best AI enterprise search tools and platforms [2025]

When [Bookshop.org](http://Bookshop.org)'s small engineering team struggled to push past a 14% search conversion rate, they faced a familiar dilemma. Despite having Elasticsearch—a powerful but complex search solution—their eight-person team was spending more time maintaining search infrastructure than improving their core platform. They needed something different: a solution that could deliver better results with less overhead.

Their challenge reflects a broader reality in modern software development. Every click, every search query, and every page load directly impact business metrics, yet the tools meant to optimize these experiences often become bottlenecks themselves. For engineering teams, especially smaller ones, the complexity of search infrastructure can become a _hidden tax_ on innovation and growth.

This is where Meilisearch comes in. Built to work seamlessly out of the box, it's the solution that lets developers focus on building rather than maintaining. Today, we're taking that mission further with [the launch of Meilisearch AI](https://www.meilisearch.com/launch-week)—our next step in making it radically easier for developers to build world-class search experiences.

In this article, we'll explore how modern search has evolved beyond simple queries, examine the technical challenges facing development teams, and introduce Meilisearch's innovative solutions—including our new AI capabilities. You'll learn how our approach to developer experience is transforming search implementation, and discover our roadmap for making advanced search features accessible to teams of all sizes.

## Redefining modern search

Modern search experiences extend far beyond the traditional search bar, encompassing two key facets: search and discovery. 

Search can take the appearance of inputs, menus, filters, or the trending UX of conversational search (i.e. chatbots). Discovery, on the other hand, plays a key role in navigating content and suggesting recommendations.

Across industries, we see search and discovery most prevalent as follows:

- **Traditional full-text search & semantic search:** standard in all industries ranging from SaaS to ecommerce, marketplaces, and content platforms
- **Conversational search:** prominent in RAG (Retrieval-Augmented Generation) and AI-enhanced search interfaces like Perplexity
- **Discovery for navigation:** common in social media and content platforms where a feed is the primary navigation
- **Recommendations:** tie in more critically with business value in ecommerce and content platforms

For early-stage startups and SMBs, implementing these search capabilities presents significant technical challenges. The complexity multiplies when adding AI integration and personalization layers. Addressing these pain points diverts the workforce from building core product value. Meilisearch is here to relieve you from this burden, allowing you to focus on what really matters. 

We want Meilisearch built-ins to handle modern use cases like [document embedding](https://www.meilisearch.com/docs/learn/ai_powered_search/document_template_best_practices). Complex setups—such as managing [heavyweight solutions like Elasticsearch](https://www.meilisearch.com/blog/meilisearch-vs-elasticsearch), [tweaking a Postgres instance](https://www.meilisearch.com/blog/postgres-full-text-search-limitations), or handling hybrid search—are additional integration burdens. This ignores the security consideration related to exposing front-end accessible APIs or the analytics necessary to collect business KPIs—things that don’t come packaged with custom-made solutions.

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

These DX considerations impact business metrics down the road as engineering bottlenecks lead to longer time-to-market, hindering growth for companies that want to move fast. In ecommerce, for example, search accuracy directly translates to conversion rate, as shown by how we helped [Bookshop increase search-based purchases by 43%](https://www.meilisearch.com/blog/bookshop-increases-search-based-purchases). On SaaS and content platforms, discovery enables engagement and adoption growth, both of which are key to keeping churn in check. 

## Leveraging DX to move mountains

Meilisearch is a no-configuration, plug-and-play solution that you can install and forget. At the heart of any search tool—and often the biggest challenge for developers—is ensuring relevant results. **CascadeRank** is our answer to [relevancy fine-tuning](https://www.meilisearch.com/docs/learn/relevancy/relevancy). Our algorithm uses human-readable ranking rules that enable configuration and easy customization. With Meilisearch, simplicity is key, allowing you to set up and focus on your core tasks. 

Though customization is easy, Meilisearch comes with strong defaults to handle common requirements out of the box—things like being typo-tolerant and prioritizing word proximity. Indeed, we’ve seen [Minipouce get better relevancy with Meilisearch’s default configuration than their previous Typesense setup](https://www.meilisearch.com/blog/minipouce-top-grade-customer-experience), leading to a 5x search volume increase. 

Scalability is a concern for small teams and enterprises alike. Performance is the name of the game for user-facing search—both for search latency and indexing time. As demonstrated by [Podscan.fm](http://Podscan.fm) [searching across 600GB of data](https://x.com/arvidkahl/status/1807889668748275802), search remains fast against large datasets. Our [next-generation indexer boasts 4x faster updates](https://www.meilisearch.com/blog/introducing-indexer-2024), making Meilisearch suitable at scale for write-intensive workflows, too.

[![arvid-kahl-tweet.png](https://unable-actionable-car.media.strapiapp.com/arvid_kahl_tweet_0c41da4824.png)
](https://x.com/arvidkahl/status/1807889668748275802)

When it comes to security, no compromise is possible. So Meilisearch provides fundamental security features to handle simple and complex use cases. Meilisearch facilitates [API key management](https://www.meilisearch.com/docs/learn/security/basic_security) to facilitate multi-environments. The built-in [multi-tenancy features](https://www.meilisearch.com/docs/learn/security/multitenancy_tenant_tokens) also enable more advanced security patterns, allowing developers to customize their access rules.

Using our expertise in search requirements across various customers, we built [Meilisearch Cloud](https://www.meilisearch.com/cloud). It’s the quickest way to get started. In addition to freeing teams from managing infrastructure, it integrates analytics and monitoring, making it [the preferred production platform for companies like HitPay](https://www.meilisearch.com/blog/hitpay-streamlines-search). Open-source Meilisearch can be self-hosted via Docker and a plethora of hosting platforms. 

This feature set positions Meilisearch well as a simple solution to get the best of modern search experience. This includes benefiting from an easy LLM integration to leverage AI-powered solutions.

## Future-proofing your search strategy

With native [hybrid and vector search](https://www.meilisearch.com/docs/learn/ai_powered_search/getting_started_with_ai_search) integration, Meilisearch makes it simple to implement AI-powered search capabilities. But we’re not stopping there—our 2025 roadmap is packed with features enabling businesses to uncover more value from AI while sustaining performance and scalability.

### Improved conversions with personalization

[Our research shows that personalization significantly improves conversion rates](https://www.meilisearch.com/blog/personalization-recommendations) across diverse business types. We aim to release a personalization framework enabling the collection of end-user context on each request. This comprehensive context management system allows developers to leverage user preferences, recent interactions, and behavioral patterns to further customize the relevancy of results on a per-user basis. 

### Retrieval augmented generation without overhead 

Although Meilisearch already enables [building retrieval-augmented generation (RAG)](https://www.meilisearch.com/blog/how-to-build-rag), we want to integrate built-in RAG capabilities in the engine, seamlessly combining full-text search, vector search, and LLM interaction. Then, we want to tackle inherent problems in state-of-the-art RAG applications by tackling the orchestration of filtering, ranking, and results merging in RAG scenarios. Of course, we want this to come with strong defaults, making it easy for developers to get started.

### Advanced ranking integrations

Our goal is to provide a native way for users to leverage AI reranking models to improve the relevancy of results. This provides a more flexible approach to configuring result relevancy by allowing real-time results reranking based on user context and behavior. We also want to enable organizations to integrate with their own custom ranking models to allow for further dynamic adjustment of results based on hand-picked factors.

### Reliability as you scale

We also plan to improve Meilisearch’s infrastructure to handle additional use cases better. In particular, we want to continue improving the distributed system capabilities for better scaling and high availability by building upon our sharding experiments with [federated remote search](https://www.meilisearch.com/docs/learn/multi_search/implement_sharding). Another layer of performance is integrating more sophisticated caching mechanisms to improve out-of-the-box performance. Monitoring and observability are also continuously improved based on user feedback.

## Meilisearch AI, refreshingly simple search DX

The release of Meilisearch AI marks a new age for Meilisearch users, fully integrating with the modern landscape of AI-powered applications. But it’s also a continuous fulfillment of our core value—making good search UX easy to build. We believe focusing on developer experience enables engineers to achieve faster time-to-value and maintain focus on their core business.

Meilisearch ships frequently to keep packaging built-in features, enabling fast-shipping companies to do what they do best. For more information on the Meilisearch AI release, consult our [launch week page](https://www.meilisearch.com/launch-week). 

Start with a [14-day free trial of Meilisearch Cloud](https://cloud.meilisearch.com/) or [request a demo](https://dub.sh/meili-sales) to discuss your needs with our search experts.

Meilisearch latest news and company updates