Hybrid RAG: combining semantic and keyword search without invented answers
Published on 2026-10-26 by frfrand
Hybrid search, filters, and citations for AI assistants with documents
Your assistant answers general questions very well, but fails when asked for the exact number of an invoice or the name of a function. Semantic search is good for meaning; exact-word search resolves other cases. Combining them usually works better.
Let's bring it down to earth: what it means, how to test it, and what happens when you use it with clients or real information. Most problems aren't fixed with a magic button, but with steps you can repeat and measure.
What hybrid RAG is and why it matters
RAG retrieves relevant documents and uses them as context to answer. Hybrid search combines lexical signals (for example BM25) and vector signals, and can use reranking and permission filters. Retrieving text does not guarantee that the model cites it or interprets it correctly.
One thing is for a demo to work for five minutes and another is to sustain a service every day. For that you need limits, permissions, activity logs, and procedures to resolve failures without improvising.
Example implementation or diagnosis
// Flujo conceptual
pregunta
-> aplicar filtro de Empresa/cliente permitido
-> buscar BM25 por palabras exactas
-> buscar embeddings por similitud semántica
-> fusionar y reordenar resultados
-> pasar fragmentos citables al modelo
-> verificar que la respuesta corresponde a fuentes autorizadasIt is a didactic reference, not a template you should blindly run in production. Replace the example values, choose identities with minimal permissions, and make sure no sensitive key ends up in a log or repository.
How I would put it to work
- Prepare clean documents with identifier, date, origin, and permissions.
- Index content for lexical and vector search, saving references.
- Test difficult queries: exact names, IDs, and semantic questions.
- Merge results and show the model fragments with clear sources.
- Evaluate correct answers, hallucinations, and leaks between clients.
After each step, verify a concrete result: an authorized action, an HTTP status, a processed task, a recorded cost, or an established metric. If something does not work, check what the first failure was before retrying in a loop.
An example that may appear in a real project
An agency wants an agent to consult documentation from several projects. If client A asks about their own API, the search engine must not retrieve internal fragments from client B even if they are semantically similar.
If that application has multiple clients, separate contexts and resources. It is especially important when a chatbot or an agent can query data: the ease of connecting tools must not bypass privacy and authorization limits.
The most common mistake
Do not put the permission filter only after generating the response. Private documents must stay out of unauthorized retrieval from the start.
A configuration with good defaults helps, but it does not eliminate the need for testing. For services that write data or trigger actions, consider retries, duplicates, and mid-process failures.
Where does ArduMaker come in?
You can deploy a RAG backend and PostgreSQL on ArduMaker, and integrate it with MCP or Router IA if the design requires it. Quality depends on data, permissions, and evaluation, not just on changing the model.
With ArduMaker you can host the backend on a VPS, deploy from Git, configure an HTTPS domain, and use database, service, and MCP tools according to the project. This makes it easier to bring operations together in one environment, although business and security rules remain the responsibility of the software.
What I would measure to know if it improved
I would not measure only "works/doesn't work." I would also review resource consumption, errors, response times, or API spending, depending on the functionality. Define a success metric before the change and compare it with the same scenario afterward.
If a piece of data seems strange, check the sample and the time window. An average can hide extreme cases, and a single successful execution does not prove that an automation can handle thousands of requests.
Frequently asked questions
Do I need a large infrastructure to get started? Not necessarily. First solve the problem with a simple architecture and measure the point where it starts to fall short.
What happens if the external provider fails? You need timeouts, a retry policy, and a useful response for the user. Do not assume external APIs are always available.
How do I maintain control? Log important events, separate permissions, and keep a proven procedure to undo changes or recover information.
References to follow
The final idea: automating and measuring is worth it when you also know how to detect an error, limit its effects, and recover.