Consider this scenario: one of your customers asks a customer support bot about a newly purchased product. Instead of being helpful, it returns a three-paragraph answer about something completely unrelated.

The customer is confused, still unsure of their answer, and probably also losing trust in your business.

That is what happens when AI generates answers just from its training data rather than also retrieving relevant information from external knowledge sources.

That is why using a [RAG-based AI system](https://www.meilisearch.com/blog/what-is-rag) for customer support is recommended.

In this article, you will learn that:

- Retrieval-augmented generation (RAG) for customer support is crucial because it grounds every AI response in an external knowledge base.
- A RAG pipeline moves through five stages: ingestion, indexing, retrieval, augmentation, and generation.
- RAG for customer support improves support accuracy and reduces ticket volume.
- Agentic RAG works through a problem step by step until it gets a complete answer.

And we’ll show you how to determine if your organization is ready for RAG and, if so, how to build it.

Let’s break down how RAG works in customer support and what it takes to implement it properly.

## What is RAG in customer support?

RAG in customer support is a framework that gives AI systems access to accurate, up-to-date information before generating a response. Answers to customer queries come from an external knowledge base rather than from the model’s training data alone.

For instance, when a customer asks a question, a RAG system first retrieves the most relevant documents. It then adds the documents to the initial question and generates an answer based on its findings.

This process eliminates problems with outdated answers or outright hallucinations.

## How does RAG improve customer support accuracy?

RAG improves customer support accuracy by reducing the model's reliance on memory. A generative AI model that returns its answers solely from memory risks returning outdated information.

With RAG, the model uses data from integrated knowledge bases to answer the question. Here is what changes specifically:

- **Grounded responses:** RAG draws directly from documentation and internal knowledge bases before generating any responses. This means the answer comes from a source you can control.
- **Fewer hallucinations:** Hallucinations occur when a model generates answers without information retrieval. RAG fixes this by ensuring it first retrieves any relevant information from the knowledge base before generating an answer.
- **Consistent and relevant answers:** Without RAG, two customers can ask the same question in slightly different ways and receive very different answers. But with RAG, the retrieved information is always anchored to the same source. This ensures consistency in responses.

## Why use RAG for support automation?

Using RAG for support automation improves the overall customer experience. That is critical for any business.

RAG chatbots can use artificial intelligence to instantly generate answers from your help articles, so your customers quickly get solutions to their problems.

Also, RAG systems ultimately help reduce ticket volume. Your human agents do not need to be present to address FAQs. The AI system handles that. They can focus on more complicated questions that require a human touch.

Another advantage is scalability. Because RAG works with your datasets, the AI assistant gets smarter as you add more help articles. Whether it receives one support ticket or a thousand, the AI assistant can handle all without breaking a sweat.

You can keep your customers happy without significantly increasing resources.

## What are RAG use cases in customer support?

The use cases of RAG in the customer support workflow vary. Let’s see some of the most important ones:

![A graph listing the different RAG use cases in customer support.](https://unable-actionable-car.media.strapiapp.com/rag_for_customer_support_2_47532d78fe.png)

- **Customer-facing chatbots:** A customer asks a question; the RAG system retrieves relevant information from a knowledge base and generates a direct answer.
- **Agent assist:** Human agents do not always have all the answers, especially for complex products. They might not be able to find the document that contains the answer. RAG helps agents get the information they need, making them more efficient.
- **Knowledge base search:** A traditional keyword search breaks down the customer's query word by word. But RAG tries to understand the intent behind a query. This means that relevant articles can be found even when the phrasing does not match any keyword within that article.
- **Ticket summarization:** In large companies, long support tickets are common, and they can carry a lot of noise. RAG can extract what really matters in a summarized text. Before a human opens the message, they already have a good understanding of the ticket.

## How does a RAG pipeline work in customer service?

Here is how a RAG pipeline turns a customer request into an accurate answer.

1.  **Ingestion:** Supporting content is loaded into the RAG system. These are the data sources used to augment the AI responses, for example, your policy documents or product guides.
2.  **Indexing:** The ingested data gets converted into [vector embeddings](https://www.meilisearch.com/blog/what-are-vector-embeddings) and stored in a vector database.
3.  **Querying:** A user poses a question to the customer support system.
4.  **Retrieval:** The RAG system searches the database it has access to and returns the most relevant documents based on the query's meaning.
5.  **Augmentation:** The retrieved documents are combined with the original user question into a single prompt. The AI model now has relevant context to work with.
6.  **Generation:** The large language model (LLM) reads the augmented prompt and produces a grounded response in real time. That is the text the customer sees.

Note that the relevance of the answer and, consequently, customer satisfaction will depend on how effectively each step is carried out.

Let’s zoom in on the key steps.

### How is support data indexed?

Support data is indexed by transforming it into a format that AI models can understand.

First, the documents are broken down into smaller ‘chunks.’ Each chunk is then converted into a numerical representation called an embedding. These embeddings are stored in a specialized vector database and can be retrieved during [semantic search](https://www.meilisearch.com/blog/semantic-search).

Meilisearch excels at performing fast semantic search on this vectorized data. It instantly finds the chunks that are contextually similar to a user's query.

### How does retrieval select relevant context?

Retrieval selects context by finding the documents that are closest in meaning to the query. This process is called semantic search.

For example, imagine a customer searching for ‘a quiet place to stay near Barcelona.’ A simple keyword search might show only the closest hotels, regardless of noise levels.

Semantic search, however, understands the user's intent as ‘tranquility.’ It then analyzes hotel reviews and descriptions for concepts related to ‘peace and tranquility’ before recommending.

### How does generation produce final answers?

Generation produces the final answer by giving the LLM a prompt containing relevant information.

This process begins with prompt construction. The system creates a detailed set of instructions for the LLM. After this, both the user's query and the retrieved document chunks are injected into the prompt. This is known as context injection.

The LLM then reads the constructed prompt and generates a context-aware answer. If this is done right, there will be few or no hallucinations.

Generation is the final output your customer sees.

## Which AI is best for customer support?

The right AI system for customer support is the one that meets your specific requirements. Here are some criteria to consider when choosing:

- **LLM quality:** The model needs to handle poorly phrased customer questions and still produce accurate answers. Test to confirm that the LLM you choose performs well for your use case. Do not rely on benchmark scores alone. A model can top every score and still struggle with the questions that your customers ask.
- **Integration flexibility:** When selecting an AI model, ensure it seamlessly integrates with your tools. It needs to be able to connect to your knowledge base and communication channels.
- **Cost:** Most API-based models charge per token. As you scale up, the costs can add up faster than expected. Always factor in retrieval and generation costs together before starting.
- **Security:** Customer data is sensitive data. The AI handling it needs to meet your security or compliance requirements. In enterprise support, for instance, confirm that the system is compliant with data residency rules.

## When should companies implement RAG?

Companies should implement RAG to optimize their customer experiences with AI. The right time is when the cost of not having it exceeds [the cost of building it](https://www.meilisearch.com/blog/how-to-build-rag).

That time varies from company to company. But here are signs to determine how ready you are:

- **Data maturity:** RAG is only as good as the knowledge base behind it. It works best when it has reliable data sources to draw from. So if your data is not available, you are simply not ready for RAG. If it is messy, you need to clean it first before implementing RAG.
- **Ticket volume:** When repetitive questions consume a good amount of your support team's time, that is a sign. If these queries can be answered using existing documents, RAG can provide automated responses with a human feel.
- **Automation goals:** If you have a [clear business goal](https://www.meilisearch.com/blog/rag-for-business), you might use RAG to achieve it. But you have to be specific in what you want to use RAG for.
- **Technical capacity:** RAG requires engineering investment. Vector databases. Retrieval pipelines. LLM integration. None of that runs itself. You need technical expertise to set up and maintain the system.

## Frequently Asked Questions (FAQs)

### What are RAG pipeline components?

A RAG pipeline has five core components:

1.  The embedding model that converts text into vectors.
2.  The vector store that holds those vectors for fast search.
3.  The retriever that finds the most relevant chunks at query time.
4.  The generator (or the LLM) that produces the final response.
5.  The orchestration layer that ties it all together and manages the flow between steps.

### What is agentic RAG for support?

[Agentic RAG](https://www.meilisearch.com/blog/agentic-rag) is a type of RAG that can reason through a problem and take multiple steps to achieve a goal.

Basic RAG retrieves once and generates once. Agentic RAG performs multiple actions until it has a sufficiently good answer.

### What’s the difference between RAG and fine-tuning?

The main difference between [RAG and fine-tuning](https://www.meilisearch.com/blog/fine-tuning-vs-rag) is how the AI model learns and uses information.

RAG retrieves information at query time, keeping knowledge fresh without retraining. Fine-tuning permanently teaches a model new knowledge by retraining it on a static dataset.

RAG is cheaper to maintain and easier to update. On the other hand, fine-tuning gives you more control over how the model behaves. The trade-off is that keeping it current is expensive.

## Why RAG for customer support is becoming essential

Providing immediate, accurate answers in customer support is now the baseline for businesses.

RAG for customer support is what makes that baseline achievable at scale. It provides teams with a system that gets better as its knowledge base improves.


How RAG for customer support improves accuracy at scale

Did you ever search your computer for a document and couldn’t find it? This happens quite often, especially in large organizations with tons of resources.

AI-powered workplace search is a new search approach that can solve this.

In this article, you will learn that:

- AI workplace search connects all your tools and data sources into one intelligent search interface.
- It uses RAG (retrieval-augmented generation) to find relevant information and generate helpful answers for businesses.
- The main difference between an AI workplace search and a traditional search is that an AI workplace search understands the context of the search query.
- Using an AI workplace search helps address knowledge silos that affect modern organizations.
- Large enterprises and fast-growing companies benefit the most from using AI workspace search.
- The timing of implementing the search matters. Businesses should consider using AI-powered workplace search when their tool sprawl becomes complex.

Let’s explore how it works and why organizations are quick to adopt it.

## What is an AI-powered workplace search?

[AI-powered workplace search](https://www.meilisearch.com/blog/ai-powered-search) helps employees find information they need across all the company's tools. It is an intelligent system that uses natural language to understand user intent and return relevant results.

Imagine you are looking for a document in your organization, but have forgotten its name and where you saved it.

With traditional search, the chances of finding this document are extremely low.

AI-powered search goes beyond a basic [internal search](https://www.meilisearch.com/blog/internal-search) that relies on keyword matching. It understands intent and context and is, therefore, more likely to surface the document you’re looking for.

## How does an AI-powered workplace search work?

AI-powered workplace search connects all available data sources and uses them as the search resource. Because it is AI-driven, it understands employee queries and returns the most precise answers.

Under the hood, it works like this:

1.  The system first indexes content from every tool your team uses.
2.  When a search query is made, AI-powered workplace search uses natural language processing to understand the user’s intent.
3.  Ranking results by relevance ensures the most relevant answers appear first.

In more sophisticated applications, you can use pattern recognition models to improve the results based on what answers people click on the most.

### How is workplace data indexed?

Workplace data is indexed by using connectors to pull content from its source. The source could be Google Drive, Slack, Confluence, SharePoint, Jira, Salesforce, and so on.

The connectors may behave differently across platforms. Some use APIs to access files in real time, while others sync periodically.

Real-time indexing ensures employees receive the most up-to-date information, and it can be expensive.

Batch indexing, on the other hand, is cheaper but may return stale results if documents have since been updated.

### How does AI understand search intent?

AI understands search intent through natural language processing (NLP). NLP is a machine learning technique that helps computers understand the meaning of texts.

For instance, when an employee types ‘refund policy for enterprise customers,’ NLP breaks this down. It identifies ‘refund policy’ as the main topic and ‘enterprise customers’ as a qualifier. It understands that this is a request for specific policy information about refunds.

It then uses semantic search to understand the query's relationships with a matching document.

For example, the system knows ‘refund policy’ is related to ‘return procedures’ and ‘money-back guarantees.’ So even if your actual document is named ‘Enterprise Return Procedures,’ the search finds it.

AI-powered search also intelligently interprets queries from context. If someone from the sales team types ‘commission structure,’ the system ranks sales compensation documents ahead of technical architecture documents with the same term.

## What are the benefits of an AI workplace search?

Here are the key benefits of implementing AI workplace search:

- **Saving time:** Employees spend less time looking for information and more time working. In time-sensitive environments, such as in customer support, the time saved can be valuable.
- **Better decisions:** AI-powered search helps users find the relevant context and data they need to make work-related decisions.
- **Knowledge discovery:** Since the search system uses machine learning, it can connect the dots and return results the user did not anticipate but that are highly useful. For instance, someone researching a new market might discover that a colleague has done a comparative analysis that includes the new market.
- **Improved employee experience:** With information now at everyone’s fingertips, a new employee no longer has to constantly interrupt colleagues to find what they need. Additionally, people feel more confident in their work when verifiable information is readily accessible.

## What problems does workplace search solve?

Workplace search tackles key challenges that large organizations face today. Let’s explore some of them.

![A graphic listing the three key problems an AI-powered workplace search can solve.](https://unable-actionable-car.media.strapiapp.com/Problems_that_an_AI_powered_workplace_search_solves_d5e4401590.png)

### Knowledge silos

Knowledge silos occur when information is trapped in separate tools. For instance, the marketing team keeps their research in Word Documents and PowerPoint slides, while the engineering team stores their technical docs in Confluence pages.

A workplace search solution removes the disconnect between different platforms by providing a unified search across all content. Any employee search returns results from all available sources.

### Time wasted searching

Time wasted searching undermines productivity in every organization. According to McKinsey, [employees waste 20% of their workweek](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-social-economy) searching for internal information they are unlikely to find.

AI-powered search capabilities eliminate this waste by delivering answers in seconds.

### Duplicated work

Duplicated work can occur when employees cannot retrieve data efficiently.

Imagine a scenario in which someone spends two weeks conducting market research on a product, only to realize that another colleague has completed a similar analysis, saved in a different tool or with a different name.

AI-powered search prevents this by automatically surfacing related work. When someone begins researching a topic, the system suggests relevant documents and prior projects from across the organization.

## Who should use AI workplace search?

An AI workplace search benefits any business audience that needs to find information across multiple systems to complete their work:

- **Large enterprises:** Companies that operate multiple platforms often have fragmented knowledge. With AI workplace search, a single search bar can access all repositories.
- **Remote teams:** Remote workers often struggle to find information because there is no colleague nearby to ask. Using an AI-powered workplace search can reduce help requests.
- **Fast-growing companies:** When an organization is growing rapidly, onboarding chaos is likely to occur. New hires often bombard senior staff with basic questions, which can slow down work. With generative AI-powered search, newcomers can quickly find verified information and work more independently.
- **Knowledge-intensive industries:** In industries such as law and consulting, accessing the right knowledge is critical. An AI-powered search delivers just the right information, providing a competitive edge.

## When should companies implement workplace search?

Companies must be proactive in implementing workplace search. Let’s discuss the telltale signs that you need it:

- **Tool sprawl is out of control:** You started your business using only email and file storage. But you have now grown to using Slack, Notion, Confluence, and Salesforce. Using an AI platform that connects all the tools together should be the next consideration.
- **Rapidly scaling teams:** Scaling your business workforce can create knowledge gaps across teams. Providing an AI-powered workplace search helps them find answers independently.
- **When key people leave:** If a senior team member leaves, their knowledge and experience go with them. Implementing an artificial intelligence search enables you to preserve what matters while making it easy to retrieve.

## How does AI workplace search compare to traditional search?

The main difference between AI workplace search and traditional search is how they interpret user intent.

Traditional search treats queries as a string of keywords to match against documents.

AI workplace search lets people ask questions naturally and then understands the context of their queries.

![A graphic listing the key differences between an AI workplace search and a traditional workplace search.](https://unable-actionable-car.media.strapiapp.com/AI_workplace_search_vs_Traditional_workplace_search_66e2a9a904.png)

With traditional search, employees think like machines. They are forced to remember keywords and file locations.

An AI workplace search makes the search more flexible.

Let's now see how Meilisearch can be used to implement an AI workplace search.

## How to implement AI-powered workplace search using Meilisearch

Meilisearch provides the search infrastructure to help you build an AI-powered workspace.

In this section, you will learn how to use Meilisearch to power such search engines.

### 1\. Install and launch Meilisearch

If you do not have Meilisearch installed, install it using:

```
# Install Meilisearch

curl -L https://install.meilisearch.com | sh 
```

If Meilisearch is already installed, launch the server using:

```
# Launch Meilisearch

./meilisearch --master-key="aSampleMasterKey"
```

### 2\. Connect Meilisearch with OpenAI API

To enable the search engine's AI capabilities, we will use the OpenAI API.

In a .env file, add your OPENAI_API_KEY, MEILI_URL, and MEILI_KEY.

We will also define an index name to index our documents.

```
import os

from dotenv import load_dotenv

import meilisearch

from openai import OpenAI

load_dotenv()

meili = meilisearch.Client(

os.environ.get("MEILI_URL", "http://localhost:7700"),

os.environ.get("MEILI_KEY", "aSampleMasterKey"),

)

openai = OpenAI(api_key=os.environ\["OPENAI_API_KEY"\])

INDEX = "company_docs"
```

### 3\. Define your documents

In a company, documents are typically sourced from APIs, Google Drive exports, databases, and other sources.

For our demonstration, we will use a simple JSON that contains several business documents. To demonstrate how to include access control in a search, each document item contains a role key.

```
DOCUMENTS = \[

{

"id": "1",

"title": "Parental Leave Policy",

"content": "All engineers get 16 weeks of fully paid parental leave. "

"Notify HR at least 8 weeks before your leave starts.",

"source": "notion",

"role": "engineering",

"url": "https://example.com/notion/parental-leave-policy",

},

{

"id": "2",

"title": "Q3 Engineering Roadmap",

"content": "This quarter we are migrating to PostgreSQL 16, "

"rolling out feature flags, and launching the new API gateway.",

"source": "notion",

"role": "engineering",

"url": "https://example.com/notion/q3-engineering-

roadmap",

},

{

"id": "3",

"title": "Postmortem: Outage on June 12",

"content": "A 45-minute outage was caused by a misconfigured nginx timeout "

"after the CDN migration. Fix: reverted timeout, added monitoring.",

"source": "slack",

"role": "engineering",

"url": "https://example.com/slack/postmortem-june-12",

},

{

"id": "4",

"title": "Customer-Facing Outage: June 12 Summary",

"content": "On June 12, customers experienced login failures for approximately "

"45 minutes. The issue has been resolved. Sales team may reference "

"this summary when following up with affected accounts.",

"source": "notion",

"role": "sales",

"url": "https://example.com/notion/outage-june-12-sales",

}

]
```

### 4\. Configure your index

Before adding the documents, we need to configure the Meilisearch index. An index is where your documents are stored in Meilisearch.

When indexing, we tell Meilisearch which fields to index, which to filter for, and how to handle vectors.

Meilisearch also allows you to configure your embedding to add [semantic search capabilities](https://www.meilisearch.com/blog/semantic-search). We generated our embeddings using OpenAI's text-embedding-3-small, which produces 1536-dimensional vectors.

```
def configure_index():

\# Delete old index (so reruns don't mix old schema/docs)

try:

task = meili.delete_index(INDEX)

meili.wait_for_task(task.task_uid)

except Exception:

pass

\# Create index (async) -> wait -> then fetch the index object

task = meili.create_index(INDEX, {"primaryKey": "id"})

meili.wait_for_task(task.task_uid)

index = meili.index(INDEX)

task = index.update_settings({

"filterableAttributes": \["role", "source"\],

"searchableAttributes": \["title", "content"\],

"embedders": {

"openai": {

"source": "userProvided",

"dimensions": 1536,

}

},

})

meili.wait_for_task(task.task_uid)

print("Index configured")

return index
```

### 5\. Index documents with embeddings

Meilisearch’s built-in search is keyword-based. To enable AI-powered search, we need to include embeddings in the index. This ensures that Meilisearch understands the meaning of the documents.

We first generate embeddings for the title and content using OpenAI's embeddings.create. This ensures the model can understand the document as a whole.

Then, we add the index, containing the documents and embeddings, to Meilisearch.

```
def index_documents(index):

texts = \[f"{doc\['title'\]}\\n{doc\['content'\]}" for doc in DOCUMENTS\]

\# One API call for all documents

response = openai.embeddings.create(

model="text-embedding-3-small",

input=texts,

)

docs_with_vectors = \[\]

for doc, embedding_obj in zip(DOCUMENTS, response.data):

docs_with_vectors.append({

\*\*doc,

"\_vectors": {"openai": embedding_obj.embedding},

})

task = index.add_documents(docs_with_vectors)

meili.wait_for_task(task.task_uid)

print(f"{len(DOCUMENTS)} documents indexed\\n")
```

### 6\. Putting it all together

When a user enters a search query, it is converted into a vector using the same model we used for the documents.

We implement access control using filters so users only see documents they are allowed to access.

Finally, we send both the text query and the query vector to Meilisearch. We can define how Meilisearch blends keyword matching and semantic similarity using the semanticRatio function.

```
def search(query, user_role="all"):

response = openai.embeddings.create(

model="text-embedding-3-small",

input=query,

)

query_vector = response.data\[0\].embedding

\# Users only see docs matching their role, or docs open to everyone.

\# In production, user_role comes from your auth token — never from the client.

role_filter = f'role = "{user_role}" OR role = "all"'

index = meili.index(INDEX)

results = index.search(query, {

"filter": role_filter,

"hybrid": {

"embedder": "openai",

"semanticRatio": 0.6, # 0 = pure keyword, 1 = pure semantic

},

"vector": query_vector,

"limit": 1,

})

return results\["hits"\]
```

### 7\. Test with a search

We can run the file and print the results.

In the first query, we are searching for ‘What caused the outage?’ from an engineering role.

In the second test, we search for the same query from a sales role.

```
def print_results(hits):

if not hits:

print(" No results.\\n")

return

for hit in hits:

print(f" \[{hit\['source'\].upper()}\] {hit\['title'\]}")

print(f" {hit\['content'\]\[:100\]}...")

print(f" {hit\['url'\]}\\n")

if \__name__ == "\__main_\_":

index = configure_index()

index_documents(index)

print("Query: 'what caused the outage?' (role: engineering)")

print_results(search("what caused the outage?", user_role="engineering"))

print("Query: 'what caused the outage?' (role: sales)")

print_results(search("what caused the outage?", user_role="sales"))
```

In the first result, the search returns a document meant for engineers, while in the second, the same search query returns a document for the sales role.

![An example of an AI-powered workplace search for the query 'What caused the outage?'](https://unable-actionable-car.media.strapiapp.com/AI_workplace_search_example_2_178ab3f758.png)

To test its AI capabilities, we can ask, ‘What are our family benefits?’ Note that none of the documents contain family benefits in the title.

However, the search engine correctly returns the document on ‘Parental leave policy.’

![An example of an AI-powered workplace search for the query 'What is our family benefits?'](https://unable-actionable-car.media.strapiapp.com/AI_workplace_search_example_9c013f7ea9.png)

## Frequently Asked Questions (FAQs)

Here are some FAQs and their answers about the AI workplace search.

### Where does a workplace search pull data from?

Workplace search pulls data from any tool your team uses: Google Drive for documents, Slack for conversations, Confluence for wikis, Gmail and Microsoft Outlook for email, Jira for project tracking, Salesforce for customer data, etc.

The system connects to these tools using pre-built integrations. This creates a single searchable index across all connected platforms.

### Is AI workplace search secure?

Yes, if implemented properly. AI workplace search respects the existing permissions from your source systems. This means employees can only see results for documents they have access to.

### What metrics measure workplace search success?

To determine whether you have successfully implemented workplace search, monitor the following metrics:

- **Search success rate:** The percentage of queries in which your users get their answers in the first few results. A good workplace search should have a success rate over 80%.
- **Time saved per search:** The average number of minutes your employees spend finding information before and after implementation.
- **User adoption rate:** How many employees actually use the search tool versus going directly to the individual apps? High adoption means the system delivers good value.
- **Reduction in support tickets:** Customer support teams and IT helpdesks track how many ‘where do I find…’ tickets disappear when search works properly.
- **Query refinement rate:** How often your employees need to rephrase searches to find answers. Lower rates indicate better understanding by the LLMs powering the search.

### How accurate is AI-powered workplace search?

The accuracy of an AI-powered workplace search depends on how it was implemented.

A good workplace search should use relevance scoring to determine useful information.

It should combine semantic query understanding with user behavior, and learn from which results users click on and how long they engage with the surfaced documents.

## The future of AI-powered workplace search in modern organizations

The future of [AI-powered enterprise search](https://www.meilisearch.com/blog/enterprise-search) is bright, as it is now becoming an essential part of modern organizations.

Because large organizations generate a large volume of knowledge, they cannot operate effectively if employees spend too much time searching for information.

By using AI-powered search, they have a competitive advantage over those still using traditional search platforms.

AI-powered workplace search: how it works, benefits, and more

*Meilisearch [Launch Week](https://www.meilisearch.com/launch-week-q1-2026) April 2026: that's a wrap.*

---

Another Launch Week done. Five days, multiple releases across scaling, enterprise security, AI, observability, and search relevance. We shipped for platform teams scaling past a single node, for enterprise buyers with an IT checklist, for developers building AI-powered search, for anyone who has stared at a slow query wondering which step was costing them latency, and for marketing teams running seasonal campaigns.

Taken together, this is the shape of a search engine built for production at scale: scalable, secure, AI-ready, observable, and flexible enough to let you shape results on your terms.

Here's what was covered [last week](https://www.meilisearch.com/launch-week-q1-2026).

## Day 1, Monday: Sharding & Replication, self-serve

[Sharding and replication](https://www.meilisearch.com/docs/resources/self_hosting/sharding/overview) are now available on Meilisearch Cloud, composable, and built for production at scale.

Three use cases, three reasons to care:

1. **Horizontal scaling.** Your dataset no longer fits on a single machine. Shard it across nodes.
2. **High availability.** You can't afford the blip when an instance restarts. Replicate, and fail over.
3. **Geographic replication.** Place instances closer to your global users to reduce response time. Available today with replication alone; combining geo-replication with sharding is possible, but optimal distribution across regions is still being worked on.

Sharding and replication compose. You can have multiple replicated shards, a replicated single-node setup, or whatever shape your workload needs. Scalability is the direction we're taking Meilisearch as a whole., as customers have been running production workloads on sharded Meilisearch for months. This release brings that capability to every team on Cloud. 

→ [Reach out](https://cloud.meilisearch.com/) to get set up for your workload

→ [Read the full Sharding & Replication announcement](https://www.meilisearch.com/blog/sharding-replication)

## Day 2, Tuesday: Enterprise SSO/SAML, plus MFA for everyone

Enterprise-grade authentication is here, with a security upgrade for everyone else on the platform.

Enterprise Single Sign-On with SCIM-based user lifecycle management is now live. Your identity provider (Okta, Azure AD, Google Workspace, Auth0, anything SAML 2.0 or OIDC compliant) becomes the source of truth for user identity. Meilisearch controls what those users can access inside the product.

What this gets you:

- **Auto-provisioning.** first-time SSO users are created automatically and added to a default team. No manual invites.
- **SCIM-driven lifecycle.** when someone is removed in your IdP, their access is revoked in Meilisearch immediately. Tokens revoked, org memberships cleared. No stale access.
- **Mixed membership.** a user can belong to an SSO-enforced org and a non-SSO org at the same time. Login routing handles both gracefully.

And alongside SSO, MFA shipped for every account, free, on every plan. If your security team cares about the difference between "SSO is enforced" and "most people have MFA turned on," you now have both levers.

This is the feature your security team will want first. Now it's there before they have to ask.

→ [Read the docs](https://www.meilisearch.com/docs/capabilities/teams/how_to/configure_sso_for_team) and [reach out](https://cloud.meilisearch.com/) to configure SSO.

## Day 3, Wednesday: Chat UI in your Cloud dashboard

We launched the `/chat` endpoint in October: a single API call that handles the full RAG workflow on top of your Meilisearch data. On Wednesday, we made it point-and-click. Open your Cloud dashboard, select an index, and the setup is done for you. The system prompt is generated from your actual documents. Guardrails are set. There's an inspector tab so you can see every tool call and raw LLM message, and an integrate page with ready-to-use code snippets for wiring it into your app.

Who this is for: anyone building chat experiences where users should get a direct answer, not a list of links. Support portals, internal knowledge bases, documentation sites, product catalogues.

→ [Read the full Chat UI announcement](https://www.meilisearch.com/blog/chat-ui)

## Day 4, Thursday: Search Performance Inspector

See exactly where your search time goes.

The Search Performance Inspector gives you a full breakdown of every query: keyword search, semantic search, filtering, facet distribution, formatting, the embedder. It's the same view our engineering team uses internally to debug customer performance issues, now in your Search Preview tab.

The headline use case: you notice half your query time is going to facet distribution, realize you don't actually need facet counts on that endpoint, and cut your latency in half. Or you catch formatting doing more work than it should and adjust your highlight and crop parameters accordingly.

Developer-facing by design. Instead of opening a support ticket with "it feels slow," you come in with the actual trace.

→ Free for all Cloud users. [Try it now](https://cloud.meilisearch.com/)
## Day 5, Friday: Document Joins and Dynamic Search Rules

Two beta releases, one day, both about relevance.

###  Experimental feature: Document Joins

You have movies. You have actors. You put them in separate indexes and link them, because you don't want to duplicate every actor's biography inside every movie document.

What you couldn't do until now: filter movies by a property of their actors. "Find all the movies where an actor is under 40 and French" meant either denormalizing your data (painful) or doing a two-step search in your application code (also painful, and fragile).

The new `_foreign` filter keyword changes that. You can write a filter on the movies index that references the actors index directly. Meilisearch runs the filter on the foreign index, gets the matching documents, and uses those to filter your current index, all in one query.

It also solves a subtler problem: filtering "employees named Maya with surname Shin" inside a single document that contains multiple employees can't guarantee you're matching on the same employee. The foreign filter can, because it filters on the actual subdocuments in the linked index first.

Document hydration, inlining the full actor data into your movie results, has been there. Document Joins is the filtering layer that makes the relationship fully usable in search.

### Experimental feature: Dynamic Search Rules (pinning)

Relevance is great. Relevance is also not always what you want.

Sometimes you want the fridge pinned at position 2 for all of summer, because it's on promotion. Sometimes you want a specific laptop to show up when someone types "computer," because you know your customers. Sometimes you want a support article pinned at the top of results during a known product incident.

[Dynamic search rules](https://www.meilisearch.com/docs/capabilities/search_rules/overview) let you do that. You define activation conditions (what triggers the rule, for example "query contains 'computer'"), and Meilisearch inserts the pinned document at the exact position you specify, after the engine has done its normal ranking work. If the pinned document fails the active filters (out of stock, wrong region), it won't be inserted. If the conditions don't match, the rule does nothing, and you get organic results.

A few things worth knowing:

- Pinning works across regular, federated, and hybrid search.
- It overrides the ranking engine for that one slot. This is intentional. Guaranteeing an exact position is something pure ranking cannot do.
- It targets the whole user base, not individual users. For user-level personalization, we have a separate feature (still in beta).

This is the first step in a full merchandising toolkit. Promoting and demoting (boosting and burying) ship next.

→ [Try both today - free](cloud.meilisearch.com)

## What's coming next

A preview of what's already in motion:

- Promoting and demoting for dynamic search rules, completing the merchandising toolkit.
- Better dashboard visibility for sharded projects: aggregated task views across nodes, unified monitoring.
- A full overhaul of the chat route: unified agent configuration, parallel multi-search, deeper guardrails, and observability.
- Richer inspector tooling in Chat UI, with more granular guardrail configuration.

→ Keep an eye on our [public roadmap](https://www.notion.so/Public-Meilisearch-Roadmap-2cb4b06b651f80868508c2c1409c1b10?pvs=21).

---

## Browse every release

Everything from this week, in one place:

→ [Meilisearch Launch Week April 2026](https://www.meilisearch.com/launch-week-q1-2026)

Thanks for following along this week. Docs and guides for every release are linked from the launch week page. Want to talk through what's relevant for your stack? Our team is here.

Happy searching.

---

*Questions? Drop by our [Discord](https://discord.meilisearch.com) or check out the [documentation](#).*

Launch Week wrap-up: everything that shipped in five days, April 2026

*Day 3 of Meilisearch [Launch Week](https://www.meilisearch.com/launch-week-q1-2026). New releases dropping every day - keep reading to the end to see what is coming tomorrow.* 

**Prefer to watch instead of read? [See the full setup walkthrough →](https://www.loom.com/share/b615d1c451fa438e968f36d463d3cc69)**

---

At our last Launch Week in October, we shipped [Meilisearch Chat](https://www.meilisearch.com/blog/meilisearch-chat) - a single `/chat` endpoint that handles the full RAG workflow on top of your Meilisearch data. No separate vector database, no custom LLM orchestration. One API call, grounded in your index.

The feedback since then was consistent: the endpoint worked, but getting it production-ready still took effort. Writing a system prompt from scratch. Deciding what guardrails to apply. Building something to inspect what the model was actually doing at runtime - because when a response goes wrong, the pipeline gives you nothing to work with.

Today we are closing that gap. Open your Cloud dashboard, select an index, and the initial setup is done for you. The system prompt is generated from your actual documents. Guardrails are set. There is an inspector tab so you can see every tool call and raw LLM message before you ship anything, and an integrate page with ready-to-use code snippets for wiring it into your app.

This is Meilisearch Chat in the Cloud UI:

## What happens when you select an index
![CHATUI1gif.gif](https://unable-actionable-car.media.strapiapp.com/CHATUI_1gif_71793a500a.gif)
The first time you open the Chat section in your Cloud dashboard and pick an index, Meilisearch does a few things automatically:

1. It samples documents from your index to understand the structure and content. 
2. Based on that, it generates a system prompt - not a generic one, but one grounded in what your data actually contains. 
3. It also writes a search description that tells the model how and when to invoke search, and
4. Sets default guardrails that keep the chat scoped to your index rather than letting it wander into general LLM territory.


## Auto-generated system prompts and guardrails

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

The result is a grounded chat experience from the first message. You do not need to write a single line of prompt engineering to get something functional.

From there, everything is configurable. If the default system prompt is close but not quite right, you can refine it. If the guardrails are too tight for your use case, you can adjust them. But the starting point is already wired up and working, which is what usually takes the most time.

## The 'inspector' tab

The hardest part of debugging RAG is that failures are usually invisible.

A user asks a question. The model gives a wrong or irrelevant answer. You do not know if search was called. You do not know what query it ran. You do not know what documents came back or how the model used them. You are debugging a black box.

The inspector tab changes that. Every tool call, every raw LLM message, in sequence - exactly as it happened. If the model called search, you see the query it used and the results it got. If it hallucinated something it should have searched for, that is visible too.

![CHAT inspect tab.gif](https://unable-actionable-car.media.strapiapp.com/CHAT_inspect_tab_82fd91b9bc.gif)

This ships as the default in Cloud, not an opt-in debugging mode, because it is what you need when something goes wrong - and something always goes wrong at least once before you ship.

## The ‘integrate’ tab

Once your chat is working the way you want, the integrate page gives you ready-to-use code snippets for connecting it to AI tools and assistants. Copy and paste into your app, your support portal, your internal tool - wherever this needs to live.
![CHAT integrate tab.gif](https://unable-actionable-car.media.strapiapp.com/CHAT_integrate_tab_20790e395c.gif)

## Who this is for

The most obvious use cases are the ones where users should get a direct answer, not a list of links: support portals, internal knowledge bases, documentation sites, product catalogues.

If someone asks your support chat "how do I reset my password on mobile," they want an answer. A list of five help articles is a worse experience, even if it is technically correct.

Meilisearch Chat is grounded in your index by default. It searches your documents, synthesizes a response, and stays within scope. It is not a general-purpose LLM interface, and that is deliberate. A grounded chat that answers your users' actual questions is more useful than a capable model with no constraints.


>**Try it yourself**
We've set up a live demo using real vacation rental data so you can experience Meilisearch Chat firsthand - no configuration needed. Ask it anything: find a beachfront property under a certain budget, a cabin in the mountains, a pet-friendly place in Europe. 
[Open the demo →](https://lodging-lark.lovable.app/)


## What is coming next

This release covers chat for a single index. Here is what is already in progress:

- **Multi-index chat** - query across more than one index in a single chat session
- **More granular guardrail configuration** - fine-grained control over how the model behaves at the edges of your data
- **Richer inspector tooling** - deeper visibility into ranking scores, retrieved documents, and why the model made the choices it did

→ [Keep an eye](https://www.notion.so/Public-Meilisearch-Roadmap-2cb4b06b651f80868508c2c1409c1b10?pvs=21) on our public roadmap.

## Part of something bigger

This is Day 3 of [Meilisearch Launch Week](https://www.meilisearch.com/launch-week-q1-2026). Every day this week, we are shipping something new.

Tomorrow, a new feature drops - and it is free for all Cloud users. If you have ever wondered exactly which part of your search pipeline is eating your speed, you will get some answers 👀

Conversational search, out of the box: Meilisearch Chat in Cloud UI

*Day 1 of [Meilisearch Launch Week](https://www.meilisearch.com/launch-week-q1-2026). New releases dropping every day - keep reading to the end to see what else is coming.*

---

Every search deployment eventually hits a wall.

Maybe your index has grown to a size where a single instance starts struggling to keep up. Maybe you have just shipped a product to users across three continents and you are watching latency climb on one end. Or maybe your on-call team gets paged every time you push a Meilisearch update because there is no failover during the restart window.

These are real, painful problems. And up until now, solving them on Meilisearch Cloud meant contacting us and waiting.

Today, that changes. **Sharding and replication are now available on Meilisearch Cloud** -- letting your search infrastructure grow horizontally, stay available, and serve users from the nearest node, all configured and managed by our team so you do not have to handle the infra yourself.


## Two problems, two solutions

Scaling search is not one problem - it is two distinct ones, and they need different answers.

**Too much data** is a sharding problem. When a single instance no longer has the capacity to index and serve your full dataset at the response times you need, you need to distribute the data across multiple nodes. Each node holds a slice (a "shard") of the full index, and queries fan out across all of them before results are merged.

**Too much risk** is a replication problem. When you cannot afford for search to go down - even for the ten seconds it takes Meilisearch to restart during an update - you need multiple nodes holding identical copies of your data. If one goes down, traffic shifts to another instantly.

Meilisearch Cloud now handles both.

## Sharding: horizontal scaling for large datasets

Sharding distributes your data across multiple Cloud nodes. Each node holds a shard - a portion of the total index - and all nodes work in parallel to handle queries and indexing.

**When should you shard?** When your dataset has grown beyond what a single instance can handle at acceptable performance. Not sure where that line is? We help you figure it out. Running scale tests together and determining the right shard count before configuring your cluster is part of how we work with teams today.

**How queries work:** when a search request comes in, it fans out to all shard nodes. Each node searches its slice, returns results, and the leader merges and ranks them before responding. The latency impact is minimal; the parallelism is the point.

**An important nuance on migrations:** sharding does not require a full data migration. When a remote is added, a partial migration is involved - but you are not starting from scratch. This is what allows you to address bigger datasets as you grow, without a forced reindex of everything.

One thing sharding does not solve: availability. If one shard node goes down, you lose access to part of your data. For that, you need replication - or a combination of both.

## Replication: high read availability and geo-distribution

Replication keeps multiple nodes in sync with the same complete dataset. When one goes down, the others keep serving reads seamlessly.

**Architecture:** Meilisearch Cloud uses a static leader-based model. Configuration changes go to the leader node, which proxies them automatically to all remotes. This keeps the cluster consistent and predictable.

A note on scope: replication today covers high *read* availability. *Write* high availability - eliminating the leader as a single point of failure for writes - is not included in this release.

**Three use cases replication covers:**

**1. High read availability - failover during updates**

When Meilisearch restarts during an upgrade, the window is short (typically around ten seconds), but it is enough to interrupt user-facing search. With replication, traffic shifts to another node automatically. Users keep getting results throughout.

**2. Geo-replication - serve users from the nearest instance**

Distribute nodes across regions and route each user to the one that will respond fastest. This is live for replication-only setups today. Optimal geo-routing with sharding combined is on the roadmap.

**3. The combination - scale and availability together**

Sharding and replication are fully composable. If your dataset is too large for a single instance *and* you need high read availability, you can run both simultaneously.

## Composability: running both at once

One of the design principles behind this release is that sharding and replication are not mutually exclusive modes -- they are composable building blocks.

Here is what that looks like in practice:

- **Sharding only:** split a large dataset across multiple nodes, each holding a fraction of the total index. Scale horizontal query and indexing throughput.
- **Replication only:** two or three nodes all holding the same data. High read availability, automatic failover, geo-routing.
- **Sharding and replication:** 5 shards x 2 replicas = 10 nodes. Every shard is replicated. You get scale *and* availability.

Billing follows the same logic: you pay for the number of nodes you run. Two replicas means twice the machines, roughly twice the cost - the same model you would see from most cloud infrastructure providers.


## What this looks like in practice

One enterprise team we worked with recently had reached a point where their index had grown past 100 million documents. A single instance was no longer meeting their performance targets.

Together, we ran a scale test to identify where a single node saturated. Based on those results, we determined the right number of shards - more than our initial estimate, once we saw the actual load profile. We configured the cluster, validated performance, and they were live.

For monitoring, they set up webhooks to track indexing task success across all nodes. When a task failed on one instance, their system detected it and knew to requeue. A single webhook server receives events from every node, giving a natural aggregate view of the whole cluster's health without anything custom.

This kind of setup -- 100M+ documents distributed across multiple shards, monitored via webhooks -- is exactly what our team configures for enterprise customers today. If your needs look similar, that is a good reason to get in touch.

## Who is this for?

**You need sharding if:**

- Your dataset is large enough that a single instance is noticeably slow, or you are approaching index size limits
- You need more indexing throughput than one node can provide
- You are planning for data growth and want headroom without a forced migration later

**You need replication if:**

- You have an uptime requirement that cannot tolerate even brief search interruptions during updates
- Your users are distributed geographically and latency varies noticeably by region
- You want a reliable failover safety net for production

**You need both if:**

- You have a large dataset *and* a high read availability requirement
- You are running an enterprise-grade, always-on search deployment

If you are not sure - starting with a single Cloud instance is completely fine. When the time comes, we will help you figure out the right architecture and handle the setup for you.

## What is coming next

This release is the foundation. Here is what is already in progress:

- **True optimal geo-replication** - combining sharding and replication for globally distributed routing, so each user always hits the nearest node regardless of how the data is sharded
- **Self-serve replication UI** - configure replication directly from the Cloud dashboard, no need to contact us
- **Improved cluster observability** - an aggregated task view across all nodes in your cluster, so you can monitor the health of your sharded or replicated setup without tracking each remote individually

## Part of something bigger

This is Day 1 of [Meilisearch Launch Week](https://www.meilisearch.com/launch-week-q1-2026). Every day this week, we are shipping something new - from features that change how you configure and monitor Meilisearch Cloud, to improvements deeper in the engine. Stay tuned.

## Ready to scale?

Sharding and replication on Meilisearch Cloud are available today as an enterprise add-on, configured by our team based on your specific setup and scale requirements. If your team is hitting data volume or availability limits, get in touch and we will help you figure out the right architecture.

[→ Get in touch](https://meet.meilisearch.com/meetings/cloud/presentation)


*Have questions about how sharding or replication works under the hood? Drop by our [Discord](https://discord.meilisearch.com) or check out the [documentation](https://www.meilisearch.com/docs/resources/self_hosting/sharding/overview).*

Scale without limits: introducing sharding & replication in Meilisearch Cloud

RAG-as-a-Service: what it is, use cases, providers & more

# How Touchless powers instant, scalable vehicle search for large dealer groups

**The company uses Meilisearch to deliver fast, faceted inventory search across multi-location dealer marketplaces - without fighting the tool.**

[Auto Genius](https://www.autogenius.io/) is the market-facing brand of [Touchless](https://www.touchless.io/), a Toronto-based technology company building performance infrastructure for automotive retail. Touchless has two main products powered by its proprietary technology platform. 

- The first, Speed Layer, uses the EXO tunnel system to make any existing dealer website dramatically faster, with no replatform needed, and is currently deployed across 1,000 domains. This product does not interact with Meilisearch at present, though there is potential for stack consolidation in the future.
- The second is the marketplace platform, primarily serving large auto dealer groups. This proprietary product is built on the EXO rendering system (ERS), which powers full vehicle inventory search and discovery. Meilisearch is at the core of that marketplace experience, delivering a modern, fast, and centralized brand experience for large dealer groups.

## **The challenge: large dealer groups need a different kind of search**

Most dealer websites are slow, cluttered, and built on legacy infrastructure - a far cry from the experience car buyers now expect. The Touchless’ marketplace platform is designed to fix that, serving **larger dealer groups** with multiple locations each, and inventories that typically range from 3,000 to 9,000 vehicles.

In the automotive industry, every vehicle is unique, identified by a VIN (vehicle identification number), with its own make, model, year, trim, mileage, fuel type, transmission, color, and price. Buyers navigate that complexity almost entirely through [faceted search](https://www.meilisearch.com/docs/learn/filtering_and_sorting/search_with_facet_filters), and a search experience that is slow, rigid, or hard to filter doesn't just frustrate - it sends shoppers to a competitor.

This is why large dealer groups come to Touchless - for a **modernized, centralized brand experience** across their locations and **higher conversion rates**. That means speed and design are non-negotiable: first page load, interactivity, filter response, and infinite scroll all need to be exceptionally fast.

Touchless had built its own EXO rendering system - a custom stack leveraging Cloudflare edge workers and web sockets for near-instant page delivery. But to make vehicle search itself feel effortless, they needed a search engine that could keep pace and integrate cleanly with that architecture.

## The solution: Meilisearch via the EXO platform

The Touchless team had previously used **Algolia**, but switched to Meilisearch for three core reasons: **API flexibility**, **integration with edge infrastructure**, and **cost-efficiency**.

Stefan Šoć-McLeod, Chief Software Engineer at Touchless, puts it plainly: 

> *"Meilisearch is API-first, which means the team could build exactly the product they wanted on top of it. For a team running a custom rendering engine, indexing strategy, and recommendation logic, that flexibility was essential."*
> 

Meilisearch also proved a natural fit for the EXO stack. The EXO rendering system - a custom rendering and routing layer - runs on Cloudflare edge workers and web sockets. Meilisearch's API topology connects cleanly to that kind of architecture, enabling search queries to be resolved at the edge with low latency. The two technologies are, in Stefan's words, *"married really nicely."*

The pricing model also made Meilisearch a more sustainable foundation for a multi-tenant product at scale. That becomes especially meaningful when the cost of search compounds across dozens of dealer indexes.

## **Implementation: from raw dealer data to live search in 20 minutes**

Onboarding a new dealer group starts with data ingestion. Automotive data arrives from multiple third-party sources - and from dealers who simply drop files onto an FTP server - in inconsistent, poorly formatted shapes. The team runs this through a normalization pipeline that standardizes the data, loads it into [**Sanity**](https://www.sanity.io/), which functions as a database, and then populates Meilisearch from there.

Each dealer group gets its own dedicated Meilisearch index. Spinning up a new one takes around 100 milliseconds. Once the team has the client's data, they can have a live preview with full search and vehicle detail pages ready in **20 minutes**.

Today, Meilisearch powers both the **search and filter experience** and **infinite scroll** across the marketplace sites for 13 dealer groups, with each group having up to 9,000 vehicles in its inventory and totaling about 100 locations. As a buyer navigates, filtering by body style, setting a price range, narrowing by mileage — results respond instantly without a page reload. The scroll never catches up. It's a qualitative step change from what most dealer sites serve today.

> Kyle Mountsier - Co-founder/COO, says:
”*With Meilisearch, you get a modern experience of instant interactivity, and you get an infinite scroll that you can barely catch.”*
> 

![Touchless x Meilisearch powered search for Casa Auto Group car dealershio](https://unable-actionable-car.media.strapiapp.com/Screen_Recording2026_03_19at10_48_04_ezgif_com_video_to_gif_converter_2c3a52d187.gif)
Source: https://www.casaautogroup.com/shop

## **The results: a search experience that sells**

Touchless’ marketplace sites are among the most performant car-shopping experiences available to dealer groups today. The proprietary EXO system as a whole, with Meilisearch as the search layer, delivers the kind of **instant interactivity** that large dealer groups use to drive brand consistency and conversion across all their locations.

The impact is visible in the product: filter latency that feels instantaneous, infinite scroll that moves faster than a shopper can reasonably keep up with, and a search experience that surfaces the right car quickly.

## **Conclusion: the API-first search engine for specialist platforms**

Touchless is building a highly custom product for a highly specific market. That demands infrastructure that stays out of the way and connects where needed, not tools that dictate how you build.

Meilisearch fits that bill. Its API flexibility lets the team at Touchless build a custom indexing strategy, a bespoke recommendation layer, and tight integration with Cloudflare edge infrastructure, without fighting the tool. For SaaS teams building multi-tenant, performance-critical products on modern stacks, that kind of interoperability is the difference between a search layer that limits you and one that frees you to focus on what actually differentiates your product.

How Touchless powers instant, scalable vehicle search for large dealer groups

Self-reflective retrieval-augmented generation (self-RAG) introduces self-reflection into large language models (LLMs) so they can evaluate their outputs and decide how to act on them, such as by retrieving additional context or improving factual accuracy.

This is your complete guide on self-RAG and what it entails. We will cover:

- What self-RAG is and how it is a step-up from standard RAG.
- How the internal workings of self-RAG use special tokens, such as retrieval, reflection, and critique tokens.
- What specific problems self-RAG solves.
- The main benefits of self-RAG, especially in question-answering, fact verification, and generation quality.
- Limitations of self-RAG, including but not limited to cost, complexity, optimization, and efficiency.
- The proper way to implement self-RAG, through embeddings, APIs, and other [RAG tools](https://www.meilisearch.com/blog/rag-tools) like LangChain and Hugging Face.
- Where Meilisearch fits as a high-performance retrieval engine in self-RAG systems.

Let’s start by defining self-RAG.

## What is self-RAG?

Self-RAG is an evolution of [retrieval-augmented generation](https://www.meilisearch.com/blog/what-is-rag) (RAG) that enables models to self-reflect and determine whether their outputs are satisfactory or require additional context.

Self-RAG adds introspective cycles on top of standard RAG to achieve higher factual accuracy and more reliable responses.

## Why was self-RAG introduced?

Traditional RAG relies on a single, fixed retrieval step, even when retrieved documents are incomplete or irrelevant. This leads the AI model to generate inaccurate answers or rely on unreliable citations – resulting in what we call AI hallucinations.

Self-RAG was introduced as a way to combat those hallucinations.

Through self-reflection, the model can evaluate its output impartially and determine what changes are needed to generate a better response.

## How does self-RAG work?

Self-RAG adds an additional loop on top of the standard RAG, similar to [corrective RAG](https://www.meilisearch.com/blog/corrective-rag).

After the initial retrieval of chunks and response generation, the system steps back and evaluates its output.

This evaluation enables the system to determine whether the generated answer meets its requirements.

![A flowchart depicting how Self-RAG works.](https://unable-actionable-car.media.strapiapp.com/How_Self_RAG_Works_dd40ecc945.png)

If the system detects gaps in the answer, a low confidence score, or missing citations, it re-triggers retrieval. The newly retrieved passages are added, and generation continues with significantly improved context.

## What problems does self-RAG solve?

Self-RAG addresses the following problems:

- **Hallucination in LLM outputs:** Standard RAG systems still generate answers when retrieved documents are weak or incomplete. Self-RAG addresses this by retriggering retrieval when grounding is insufficient.
- **Irrelevant or low-quality retrievals:** Traditional RAG often overlooks quality, not by choice, but because the retrieved context is not enough. Self-RAG doesn’t move to the final generation unless the context is deemed healthy.
- **Lack of self-evaluation:** Many RAG systems generate answers without checking accuracy or citation quality. Self-RAG, by contrast, introduces explicit self-critique and self-evaluation mechanisms.
- **Weak handling of complex queries:** Long-form or multi-step questions often require multiple retrieval passes. Self-RAG handles these cases through reiteration and refinement before the final response. This is similar to [speculative RAG](https://www.meilisearch.com/blog/speculative-rag), a smarter approach to retrieving information from knowledge bases and generating responses.

Now, let’s look at the benefits of self-RAG.

## What are the benefits of self-RAG?

The key benefits of self-RAG are the following:

- **Higher factual accuracy:** More retrieval layers improve factual accuracy, as the model can verify whether the answer is supported by the documents or requires fine-tuning with additional context.
- **Improved efficiency:** There’s a common objection related to the ‘added’ retrieval steps and wasted computation in self-RAG. Self-RAG addresses this objection by retrieving additional context only when necessary.
- **Better handling of complex queries:** Multi-step and long-form questions benefit from iterative retrieval and refinement instead of a single-pass response.
- **Greater controllability:** Based on self-reflection signals, developers can control when retrieval occurs and how much iteration is allowed.

## What are the limitations of self-RAG?

Self-RAG improves factual grounding and response reliability, but, as always, there’s a trade-off.

Teams need to account for the following limitations before committing to self-RAG:

- **Higher compute cost:** As the retrieval and generation counts increase, so does the compute cost. Although self-RAG is efficient, it remains more expensive than standard RAG.
- **Increased system complexity:** Adding self-reflection and critique logic introduces more moving parts that require specialized design and maintenance.
- **Latency overhead:** With multiple layers, response time can be significantly delayed.
- **More demanding tuning requirements:** Effective self-RAG often relies on high-quality engineering efforts. Fine-tuning, reflection tokens, and specialized prompt engineering are all a part of these efforts.
- **More challenging debugging:** Multi-step generation paths make it harder to trace errors and explain system behavior.

Keep these limitations in mind when you next want to balance accuracy gains against performance, complexity, and computational cost.

## How is self-RAG different from RAG?

Standard RAG is basically an end-to-end one-pass pipeline. It performs a single retrieval step and generates an answer immediately.

Self-RAG is the opposite. It evaluates its own generations and checks whether the retrieved documents are sufficient. If not, it decides when to retrieve again.

In standard RAG, retrieval is fixed, and errors in context often lead directly to hallucinations or weak grounding.

Self-RAG introduces iterative retrieval, enabling the system to refine context on demand.

## How is self-RAG different from agentic RAG?

Self-RAG focuses on introspection and iterative retrieval. The response is generated only when the system is satisfied with the factual accuracy and relevancy of the retrieved documents.

[Agentic RAG](https://www.meilisearch.com/blog/agentic-rag) is completely different.

It delegates actions to external AI agents, tools, or sub-systems to complete multi-step tasks. In agentic RAG, the system executes a sequence of tool calls or workflows to satisfy user intent, often involving planning, execution, and result aggregation.

Compared with agentic RAG, self-RAG remains within the core retrieval-generation loop and adds self-critique, rather than breaking down tasks or assigning them to external tools.

## How is self-RAG different from modular RAG?

Self-RAG adds self-reflective loops to retrieval-augmented generation, enabling the AI model to evaluate its own output and retrieve additional context when needed.

[Modular RAG](https://www.meilisearch.com/blog/modular-rag) is unique because it breaks the RAG pipeline into interchangeable components that can be independently developed, swapped, and optimized.

Modular RAG decouples retrieval, ranking, and LLM generation into discrete modules, often with separate APIs or microservices.

Compared with modular RAG, self-RAG emphasizes self-reflection, iteration, and critique within the same generation loop.

## When should you use self-RAG?

Whenever you’re in a situation where the overall quality of answers matters more than response speed, self-RAG is the way to go.

To be precise, you should use self-RAG in:

- **Question answering systems:** Self-RAG is useful when there is no compromise on answers being grounded in retrieved documents.
- **Research and analysis workflows:** When models need to synthesize information from multiple sources and refine outputs iteratively, it becomes a no-brainer.
- **High-stakes domains:** When accuracy can be literally life-saving, such as in healthcare or the legal industry, self-RAG is far superior to standard RAG.
- **Long-form or complex queries:** You need self-RAG when questions require multiple retrieval steps or deeper reasoning beyond one context pass.
- **Dynamic knowledge environments:** When training data or the actual dataset changes frequently, models must continually reassess whether the retrieved context is sufficient.

In these cases, self-RAG provides stronger control and more reliable outputs than standard RAG approaches.

## Who should use self-RAG?

The obvious answer is engineering teams that depend on factually accurate and vetted responses. Self-RAG is most relevant for machine learning engineers and AI researchers working on retrieval-augmented generation, long-form question answering, or self-evaluating models.

Platform and infrastructure teams can also benefit from building shared RAG services that require stronger guarantees regarding the grounding and reliability of responses.

Self-RAG is especially useful for teams that are currently experimenting with new RAG architecture, evaluating generation quality at scale, or pushing beyond the limits of standard RAG pipelines.

## How to implement self-RAG

Self-RAG combines standard RAG building blocks with a self-assessment layer.

In practice, the first step is to implement a retrieval workflow. To follow up, add reflection signals and iterate until the output meets the task requirements.

### 1\. Build a baseline RAG retrieval layer

This first step creates the retrieval foundation that returns relevant documents for user queries. You need it because self-RAG can only self-correct when it can retrieve a better context.

A fast retrieval layer also matters because self-RAG may retrieve multiple times per request.

Meilisearch fits here as a low-latency retrieval engine that supports [hybrid search](https://www.meilisearch.com/blog/hybrid-search-rag) and filtering, which helps control which documents enter the loop.

### 2\. Add self-reflection and critique signals

This step adds reflection tokens or critique mechanisms that enable the model to evaluate its own generated outputs.

Self-RAG uses this layer to determine whether the current context is sufficient, whether citations are missing, and whether the factual grounding is strong enough to proceed.

### 3\. Implement a retrieve-critique-regenerate loop

The last major step connects retrieval, generation, self-evaluation, and re-retrieval into a repeatable workflow.

## What is the future of self-RAG?

The future of self-RAG is undoubtedly heading toward a more [adaptive retrieval](https://www.meilisearch.com/blog/adaptive-rag) and self-evaluating AI systems that can reason about their own outputs in real time.

The current research focuses on optimizing self-RAG output, costs, and complexity.

Plus, [conversational search](https://meilisearch.com/docs/learn/chat/conversational_search) and retrieval engines will play a larger role in enabling low-latency, iterative retrieval.

Over time, self-RAG may become a default pattern for building reliable, grounded AI systems rather than a specialized research technique.

## Why self-RAG matters for the future of retrieval-augmented generation

Self-RAG is more than just a new framework in AI and NLP. It is a complete shift in how retrieval-augmented generation systems are designed and evaluated.

Instead of assuming that a single retrieval step is sufficient, self-RAG treats generation as something that should be questioned and improved repeatedly.

With the aim of reducing hallucinations and producing relevant, factually accurate responses, self-RAG is likely to become a standard component rather than an optional enhancement.

Self-RAG explained: how self-reflective retrieval boosts AI outputs

# The Good, the Bad, and the Leaky: jemalloc, bumpalo, and mimalloc in Meilisearch

This post was originally published on [Clément Renault's blog](https://blog.kerollmops.com/patching-lmdb-how-we-made-meilisearch-s-vector-store-333-faster).

---
It's been some time since a couple of open-source users reported that Meilisearch is leaking memory. I spent time reviewing the codebase to see where a leak could have hidden, but I never found anything suspicious enough. I was also very suspicious of those claims, as we are running multiple thousand Meilisearch instances on our Cloud and have never had any leaking issues that caused instances to be killed by the OS...

...actually, yes, we had a leak in v1.25, but it was related to an LMDB feature I was developing back then, and I talked about this in [another blog post](#). This is fixed now, and it was entirely my fault for diving into a complex C codebase and deploying a tricky change without extensive testing.

I also investigated Meilisearch on the Cloud and always found that Meilisearch wasn't leaking memory in any way. As you can see below, this is the memory usage of a customer who is heavily indexing embeddings and keywords. No apparent leak while they have tens of millions of documents on this machine (part of a sharded cluster).

![memory-leak-investigation1.png](https://unable-actionable-car.media.strapiapp.com/memory_leak_investigation1_b7e3f0942a.png)

But one day, I noticed something similar to what was reported: Meilisearch was using more and more resident memory. Resident memory, also known as RSS, is the memory allocated by the OS that resides in RAM, unlike virtual (VRT) memory, which often comes from memory-mapped files and is allocated on demand. RSS memory comes from calls to the `mmap` syscall with the `MAP_ANONYMOUS` option. That's what your allocator does when you `malloc` something if there are no pages already allocated.

![memory-leak-investigation2.png](https://unable-actionable-car.media.strapiapp.com/memory_leak_investigation2_a9fc3ba1ff.png)

That's what I saw when indexing millions of small documents in Meilisearch. So I decided to dive into the rabbit hole and find this leak. In Rust, I thought it was very easy to detect leaks because they often come from explicit calls to the `mem::forget` function. Unfortunately, we don't have any explicit call to it.

## Jemalloc to the rescue

We used jemalloc for a long time before we switched to mimalloc. The main reason was performance and Windows and macOS compatibility. We thought mimalloc would work better with Windows, as it is a Microsoft project, but we were eventually proven wrong and disabled mimalloc on Windows. Still, we were able to use mimalloc on macOS this time. The story repeats itself, and on Windows, Meilisearch uses the default allocator.

However, jemalloc is a very performant allocator – better in every way than macOS's default allocator, for sure 👓 – and, most importantly, it has very helpful tools to track leaks and heap allocations. I changed Meilisearch's global allocator back to jemalloc, enabled the profiling feature, and generated a couple (too many) SVG outputs of memory tracking.

The SVG showed around 100 MiB being leaked in some part of the code I recently modified. New code is often the source of new bugs, so I reviewed my code more thoroughly – and I invite you to do the same, because I am very proud of it. Long story short, there was no memory leak introduced in my PR, yet the report still referenced this code.

I am not a very prominent user of AI agents. I use [Zed](https://zed.dev) – not for its AI-related features, but more because I love Rust, and this editor is quite good. As the Zed team uses Zed to work on the Zed codebase, they've worked hard on the Rust analyzer integration and the debugger. That's a breeze compared to Sublime Text's bad Rust integration and VSCode's browser slowness and resource usage.

End of digression. I still decided to get a little help from an LLM to see where it could lead me. I generated a text report from a jemalloc heap analysis and gave it to my Zed Claude Sonnet 4.5 agent... It impressively found multiple leaks in the codebase – approximately four. Rest assured, only one was an actual leak, yes... AI, you know. Still, the one it found was a real one.

## The trap of bumpalo

You may know about [Bumpalo](https://docs.rs/bumpalo/latest/bumpalo/). It's a bump allocator library. The main goal is to reduce pressure on allocators (e.g., mimalloc, jemalloc) by allocating memory chunks that are freed only when the `Bump` object is dropped. We use this in Meilisearch to perform many small allocations (e.g., document IDs, field names) and retain them throughout indexation, avoiding numerous small, scattered allocations that could lead to cache-unfriendly patterns and slowness.

The main trap with bumpalo is our use of [`bumpalo::Vec::into_bump_slice`](https://docs.rs/bumpalo/latest/bumpalo/collections/vec/struct.Vec.html#method.into_bump_slice). This method takes an allocated vector and converts it into the underlying slice. This slice can be used safely and is not even considered a leak, since its lifetime is the `Bump` one – which means the slice will be deallocated when the underlying memory chunk owned by the `Bump` is dropped. However, there is a catch here. When converting a `bumpalo::Vec` to a slice, the slice never runs the drop glue, and we were storing a global-allocator-backed data structure – i.e., an `std::Vec` – in this `bumpalo::Vec`. What a mistake. You can review [the patch for the AI-assisted-discovered leak](#).

I felt relieved after finally fixing this longstanding bug. It had been there since v1.12 – approximately 1.5 years ago. All that time, and nobody noticed. We wondered whether bumpalo was "at fault" here and whether `bumpalo::Vec` should only accept storing structures that implement a specific `bumpalo::Drop` trait. However, implementing that seemed very complex. So, I started measuring Meilisearch's memory usage again with the clear leak fixed...

![memory-leak-investigation3.png](https://unable-actionable-car.media.strapiapp.com/memory_leak_investigation3_30dd8a6635.png)

What the heck?! I checked whether I was using a pre-patch binary – and no, there was still a huge increase in memory usage. My patch had actually changed nothing. Someone could easily lose their mind over this, but I cooled down and tried using my "super-powered" AI agent again. This time, it found nothing.

## The downsides of using non-Rust dependencies

Meilisearch uses [LMDB](https://www.symas.com/lmdb), a lightning-fast memory-mapped key-value store, to store and operate its internal indexes. We store the inverted index for our search engine to serve search requests, and thanks to its implementation of multi-version concurrency control (MVCC), we can serve search requests while updating the internal data structures. It's probably the most important dependency in the engine, and we put a lot of pressure on it. Note that this library is in C.

In C, you said? Yes – and that's part of the answer to our memory leak. Meilisearch is statically linked with LMDB, and Meilisearch also uses mimalloc as the global allocator. But LMDB doesn't use mimalloc and relies on the default allocator – the system allocator. Long story short, LMDB is allocating and deallocating pages that Meilisearch cannot reuse because both allocators are not cooperating, and that's the main clue to this mystery.

I decided to remove the custom global allocator in Meilisearch and set `LD_PRELOAD` (an environment variable used to load shared libraries before others – in this case, to replace the allocator) with jemalloc and profiling enabled, so I could get a good report to feed to my "super-powered" AI agent. I had already dived into LMDB before, and some allocation-related parts looked quite spooky to me. I tend not to like this kind of unbounded linked list of page-size allocations.

![memory-leak-investigation4.png](https://unable-actionable-car.media.strapiapp.com/memory_leak_investigation4_2d8851cb4b.png)

Wow! The goal wasn't to drastically reduce memory allocations by using jemalloc, but rather to extract a report. This is very interesting – when using jemalloc, we can clearly see that no leak appears. The main change here was to use a single memory allocator for both Meilisearch and LMDB to enable LMDB auditing, since I was only enabling jemalloc profiling for the Meilisearch application before. It seems that the leak was resolved by unifying them. I extracted a report, and it didn't even show the spooky linked list I mentioned before – no actual leak of any kind.

## Using mimalloc everywhere

So, I tried using mimalloc instead of jemalloc to see how Meilisearch behaves when it shares its allocations with LMDB, and... the result wasn't very convincing – the leak is back. The issue seemed to arise only with mimalloc, not with jemalloc. I looked it up and found out that the amazing team behind mimalloc was actually working on a v3. We were using v2, the version available on main.

![memory-leak-investigation5.png](https://unable-actionable-car.media.strapiapp.com/memory_leak_investigation5_adb3432bf7.png)

I compiled mimalloc v3 and `LD_PRELOAD`ed it in Meilisearch, and the result was much, much better. As you can see, it is now close to jemalloc's memory usage. I found out later that [mimalloc's override feature](https://github.com/microsoft/mimalloc#overriding-malloc) existed, and its goal was to force every allocator call to link to mimalloc and enable it. I also used the `nm` command to verify that the different malloc symbols pointed to the `mi_malloc` symbols.

![memory-leak-investigation6.png](https://unable-actionable-car.media.strapiapp.com/memory_leak_investigation6_868d0347e8.png)

According to the documentation, mimalloc v3 is much better at sharing memory between threads and promises a (much) lower memory usage for certain large workloads. I think indexing documents with Meilisearch falls into this category. We also probably benefit from other features, such as the simplified lock-free design and support for true first-class heaps. I don't know what the latter two features do, but they seem very beneficial to our workload.

We ran some benchmarks to see if everything was good, and the results showed very good performance gains. We had some gains of about 13% and some losses of about 9%, but those are necessary tradeoffs. Note that those benchmarks are run on a dedicated NVMe machine. In the Cloud, most of our customers use network disks, and performance gains will be even more visible with higher-latency disks, e.g., AWS EBS.

The most important thing is that the memory usage is much lower than before. Our systems have limited RAM, and the disks are slow (especially network disks). You'd rather not fetch from disk every time you access a page and instead rely on the page cache. That's why reducing our RSS frees up more memory for the page cache and reduces disk reads, ultimately improving performance. There is still a tradeoff between `munmap`ping memory too often or too early versus keeping it, but mimalloc v3 seems very efficient at managing this tradeoff.

![memory-leak-investigation7.png](https://unable-actionable-car.media.strapiapp.com/memory_leak_investigation7_25b9117aad.png)

After testing the engine for some time with mimalloc v3, I still see some spikes in particularly heavy-indexing parts, but it's much easier to see where we can improve the engine without the RSS noise we had before. The story continues – but it will mostly focus on engine-side optimizations to reduce allocation loads rather than "meta" changes to the engine.

*This blog post has been crafted using my own wording and thoughts 🌱*

The Good, the Bad, and the Leaky: jemalloc, bumpalo, and mimalloc in Meilisearch

# Roadmap roundup: where Meilisearch is heading

We’ve been thinking a lot about where Meilisearch needs to go next. Not incremental improvements, but fundamental shifts in what Meilisearch can do, who it can serve, and how it fits into the modern AI stack.

Today, we’re sharing our updated roadmap. It’s organized around four themes:

- Meilisearch for any workload
- Hybrid by default
- From API to platform
- RAG at scale

Here’s the full picture:

## **Meilisearch for any workload**

Meilisearch works great for most use cases today. But there’s a growing segment we want to serve better: large SaaS platforms with millions of tenants that need per-tenant search isolation. The economics simply don’t work when every tenant, active or not, requires dedicated compute.

We’re solving this with two complementary efforts:

### 1. Distributed search

We're well into this one already. [Sharding](https://github.com/meilisearch/meilisearch/releases/tag/v1.37.0) lets Meilisearch distribute indexes across multiple nodes, breaking through the single-machine ceiling that currently limits dataset size. Replication ensures [high availability:](https://www.meilisearch.com/blog/horizontal-scaling-with-sharding) if a node goes down, search continues to work.

For our [customers](https://www.meilisearch.com/customers), this means Meilisearch can handle datasets that were previously too large. For [SaaS companies](https://www.meilisearch.com/solutions/SaaS), it means they can finally trust Meilisearch as the backbone for search at real scale.

### 2. Serverless indexes

This is the bigger bet. The idea: indexes that aren’t being queried should cost almost nothing.

Today, whether an index serves 10,000 queries per second or zero, it allocates the same compute and memory. That’s wasteful. With serverless, inactive indexes get moved to cheap object storage (like S3) and only spin back up when a query arrives. Active indexes behave exactly as they do today, no performance compromise.

We're targeting Q3 2026 for the first release of serverless indexes, starting with Cloud.

What this unlocks is significant. A SaaS with 1 million tenants, of which only 5% are active at any given time, would pay for 50,000 warm indexes instead of 1 million. The other 950,000 sit on S3 for fractions of a cent. Per-tenant search isolation becomes affordable at any scale.

It also unlocks something we’ve long wanted: **a real free tier**. Today, offering free plans means provisioning compute for users who may never come back. With serverless, a dormant free user’s index costs us almost nothing in storage. When they return, it wakes up and works. We can finally offer a generous free plan without burning money on idle infrastructure.

Serverless also compounds beautifully with geo-replication. Without it, replicating across five regions would cost 5x as much. With serverless, replicas in low-traffic regions scale to zero and only wake when needed. Global distribution becomes affordable instead of multiplicatively expensive.

---

## Hybrid by default

Meilisearch already supports [hybrid search](https://www.meilisearch.com/solutions/hybrid-search), combining keyword matching with semantic understanding powered by AI embeddings. But setting it up requires too many decisions, too much configuration, and too much reliance on third-party providers. We want to change that.

This initiative is about making hybrid search the default, effortless experience, and building a genuine quality moat around it.

### Simpler setup for embeddings and reranking

Today, [getting semantic search](https://www.meilisearch.com/docs/learn/ai_powered_search/getting_started_with_ai_search) working requires choosing a provider, picking a model, understanding dimensions, and writing a document template. Most developers just want to “make my search smarter.”

We’re building a guided setup in the Cloud dashboard that walks you through enabling semantic search in under two minutes. Sensible defaults at every step. We’re also adding AI-generated document templates: Meilisearch samples your documents, analyzes them, and automatically generates the optimal template. No more guessing what text to embed.

On the reranking side, we’re opening support for more providers beyond Cohere (Jina, Voyage, and a generic REST option), and making the composite embedder pattern (a fast local model for queries, a high-quality remote model for indexing) a simple toggle rather than a manual configuration.

### A unified AI Gateway

Every embedding and reranking call currently goes directly to a third-party provider. Meilisearch has zero visibility: no cost tracking, no caching, no fallback when a provider goes down.

We’re building an AI gateway that sits between Meilisearch and all AI providers. It handles provider translation, retry with fallback, authentication, metering, and most importantly, aggressive caching. Embedding the same text always produces the same vector, so the gateway caches duplicate requests instead of paying for them again. This is especially valuable during re-indexing.

For Cloud users, this becomes the default. You enable semantic search, pick "meilisearch" as a source, and everything just works. No provider API keys needed. For self-hosted users, the gateway is available as a paid API with the same benefits. Switching providers becomes a configuration change; no re-indexing is required.

### Our own models

This is the long-term play. We’re training and hosting our own embedding and reranking models, purpose-built for search.

General-purpose models from OpenAI or Cohere are trained for broad similarity tasks. They often duplicate what keyword search already does well, instead of filling in what keywords miss. Our models will be trained specifically to complement Meilisearch’s keyword engine, using co-optimization techniques that teach the model to capture semantic meaning where keyword search falls short.

We’re planning multiple tiers (small, large, multilingual) and a local reranking model that runs inside the Meilisearch binary itself. No external API calls, no network latency.

The quality bar: match established providers on standard benchmarks within 5%, and outperform all general-purpose models on Meilisearch’s hybrid search quality. We’ll publish these benchmarks openly. This creates a real moat: models co-optimized with Meilisearch’s ranking pipeline deliver results that competitors can’t replicate by just calling the same API.

---

## **From API to Platform**

Meilisearch has grown far beyond a simple search engine. It supports sharding, index swaps, webhooks, document functions, detailed performance profiling, and more. But many of these capabilities are invisible in the Cloud dashboard. A feature that can’t be found might as well not exist.

This initiative is about closing the gap between what the engine can do and what customers can actually access, configure, and debug from the UI.

### Full engine access from the dashboard

We’re surfacing the full power of the Meilisearch engine in the Cloud dashboard. Many features exist in the engine today but have no UI: shard management, index swaps for zero-downtime reindexing, webhook configuration, data transfer between projects, document functions (in-place transforms via code), search performance breakdowns, and proper index management with disk usage and compaction.

All of these will get first-class dashboard interfaces. The goal is that everything you can do via the API can also be done from the Cloud UI, with visual feedback and safety checks built in.

### Built-in debugging and observability

Today, when something goes wrong, most customers file a support ticket. We want to change that by giving them the same tools our internal team uses.

The biggest one: we’re opening up our internal “top 50 slowest requests” dashboard to customers. It’s the same tool our team reaches for first when something feels slow. It will come with pattern detection and optimization suggestions for each slow query.

This builds on the per-request performance tracing we already shipped in [v1.35.0](https://github.com/meilisearch/meilisearch/releases/tag/v1.35.0), where adding `showPerformanceDetails: true` to any search query returns a full breakdown of where time is spent: tokenization, keyword search, semantic search, formatting, and more. If you've used the search preview in the Cloud dashboard, you've already seen this in action.

Beyond that, we’re building a better batch view (structured debugging instead of raw JSON), full engine telemetry with configurable alerts (latency percentiles, throughput, resource usage), an AI diagnostic helper that can analyze a slow request and explain what’s going on in plain language, an auto-optimize tool that suggests settings changes based on your data and usage patterns, and snapshot management for backups and point-in-time restore.

Together, these tools transform the [Cloud](https://www.meilisearch.com/cloud) dashboard from a basic management interface into a full observability and operations platform.

---

## **RAG at scale**

Since launching [Meilisearch Chat](https://www.meilisearch.com/solutions/rag) to general availability [last year](https://www.meilisearch.com/launch-week-q3-2025), we've seen strong adoption and learned a lot about what teams actually need when putting conversational search in front of real users. This next phase is squarely focused on experience: making it faster to configure Chat directly from the Cloud UI, reducing the setup friction that still requires touching code, and giving teams more control over how their *chat interface looks and behaves* directly from the dashboard.

### A smarter chat engine

The engine-level changes make the chat feature fundamentally more capable.

The biggest win is **parallel multi-search**. Today, the LLM must make sequential tool calls, one round-trip at a time. For a question like “compare Nike and Adidas running shoes under $150,” that means search, wait, search again, wait again. We’re replacing this with a single tool call that fires multiple searches in parallel. All results come back at once.

We’re also simplifying configuration dramatically. Today, setting up a chat agent requires N+1 API calls across two separate levels. We’re merging everything into a single agent configuration: provider, system prompt, guardrails, few-shot examples, and per-index search parameters in one call.

Other key improvements include dynamic facet discovery (the LLM explores filterable attributes on demand instead of relying on static data baked into the prompt), external tool calling (pass your own tools alongside Meilisearch search for complex agent workflows), conversational memory (the LLM stores and retrieves user preferences across sessions, scoped by tenant token), and better source attribution with real-time citation events streamed alongside the answer.

### From API to product

The engine improvements above mean nothing if developers can’t discover and use them.

We’re building a chat playground in the Cloud dashboard where you can test your agent, see which documents were retrieved, and watch the LLM’s internal tool calls in real-time. No code required to start experimenting.

The second big piece is auto-generation. Meilisearch already knows your data. We’ll use AI to analyze sample documents and automatically generate optimal configurations: system prompts, index descriptions, document templates, search parameters, guardrails, and few-shot examples. A developer should go from “I have indexed data” to “I have a working chat agent” in under five minutes.

We’re also building a Chat UI starter kit: a code generator that produces a complete, working chat component for your framework of choice (React, Vue, Next.js, Vanilla JS, Svelte), pre-wired to your Meilisearch endpoint. Copy, paste, ship. And comprehensive [documentation](https://www.meilisearch.com/docs/home) covering the full RAG pipeline, prompt design, and integration patterns.

### Multi-provider LLM infrastructure

Chat V1 relies on a single hardcoded LLM provider. Any outage means chat is down, any price increase hits margins directly, and customers with specific compliance requirements can’t be served.

We’re building an AI gateway, an internal Rust service deployed as a sidecar on each Cloud region, that sits between Meilisearch and all LLM providers. One unified OpenAI-compatible interface with support for OpenAI, Anthropic, Mistral, Cohere, Google Vertex, AWS Bedrock, and self-hosted models via Ollama.

The gateway provides fallback chains (if one provider fails, the next picks up transparently), per-tenant billing via metering, Bring Your Own Key for enterprise customers, per-tenant cost controls, and prompt optimization to reduce token usage. It’s invisible infrastructure: users interact with Meilisearch’s [Chat API](https://www.meilisearch.com/docs/reference/api/settings/get-chat), and the gateway handles everything behind the scenes.

---

## The bigger picture

These four themes aren’t isolated. They reinforce each other.

Serverless indexes make the AI gateway economically viable at scale. Millions of tenants can each have their own search and chat agents without burning compute on idle infrastructure. The AI gateway makes our own models reachable as the distribution channel for embeddings, reranking, and LLM access. Our models make hybrid search a genuine differentiator: purpose-built models that outperform generic alternatives. The platform improvements make everything accessible: debugging tools, observability, and a dashboard that surfaces the full power of the engine.

Together, they transform Meilisearch from a search engine into a complete information retrieval platform: search, hybrid AI, RAG-powered chat, and the infrastructure to run it all at any scale.

We’re incredibly excited about what’s ahead. As always, Meilisearch remains [open source](https://github.com/meilisearch/meilisearch) at its core, and we’ll share progress as we build. If any of this particularly interests you, or if you’re facing a problem that it would solve, we’d love to hear from you.

Stay tuned.

Want to stay up to date on our priorities and direction? Check out our [public roadmap](https://www.notion.so/Replication-system-2cb4b06b651f811d9457e961f80676ee?pvs=21) or sign up for the [Meilisearch newsletter](https://www.meilisearch.com/).

Meilisearch latest news and company updates