RAG en agentes de voz: descartarlo o implementarlo

Durante mucho tiempo he sido muy hater del RAG en los agentes de voz. Cuando se trata de sistemas que necesitan una respuesta casi en tiempo real, los sistemas de RAG, por lo general, no suelen funcionar muy bien. Por ello, cuando hace un tiempo nos planteamos si desarrollar un sistema de RAG en nuestra plataforma yo dije claramente que no. Finalmente, lo hemos acabado implementando y en este artículo quiero hablar sobre los sistemas RAG, las limitaciones de latencia en Voice AI y que enfoque hemos acabado tomando nosotros para incorporar un sistema de RAG que fuese útil.

Qué es el RAG

Antes de nada, RAG (Retrieval-Augmented Generation) es un sistema que consiste en recuperar información de fuentes externas (PDFs, webs y en general cualquier cosa que lleve texto) y pasársela como contexto a un LLM para que genere respuestas sobre un dominio concreto sobre el que no ha sido entrenado. En lugar de depender solo de lo que el modelo ya sabe, le damos la información que necesita en cada momento. Si quieres profundizar, te recomiendo este video donde lo explican en detalle.

Mi primer contacto con el RAG fue hace ya dos años, en un curso de DeepLearning.ai donde te enseñaban a montarlo con LlamaIndex. Desde entonces el mundo del RAG ha cambiado muchísimo. Han salido nuevas técnicas que hacen que funcione mucho mejor. De hecho, si entras a LinkedIn, cada día encontrarás una nueva ;). Sin embargo, cuando se trata de voice AI, todas estas técnicas se vienen abajo por varios problemas.

Los problemas del RAG en Voice AI

Cuando hablamos por un chat todo es más sencillo. Las nuevas técnicas de RAG funcionan porque en el mundo del chat podemos aplicar distintas técnicas y trucos y hacer al usuario esperar mientras se le devuelve una respuesta. Al usuario no le importa esperar 2-3 segundos más si eso le devuelve la respuesta correcta.

Sin embargo, en la voz la cosa cambia. En la vida real, cuando hablas con una persona, esperas que te responda al instante. Sería muy raro que en cada interacción se quedase pensando unos segundos antes de contestarte, y en voice AI eso es exactamente lo que tenemos que tratar de imitar. Cada 100ms cuentan (literalmente) y no nos podemos permitir quedarnos un rato buscando información.

El problema es que los sistemas RAG en 2025 están convergiendo hacia arquitecturas agénticas con autorreflexión. El Agentic RAG, el GraphRAG..., sistemas que funcionan muy bien, pero tienen una latencia demasiado alta para voz. Eso nos deja con el enfoque más tradicional de RAG: en base a la pregunta del usuario, obtenemos unos fragmentos de texto y se los pasamos al LLM.

Pero hay otro problema que no se suele mencionar: las transcripciones. A día de hoy, los sistemas de voice AI pasan por un flujo de tres pasos (ya hablaremos de los modelos multimodales otro día):

STT (habla a texto) → LLM (genera respuesta) → TTS (texto a habla)

Durante el paso de STT, muchas veces no se recoge correctamente lo que ha dicho el usuario. Por ejemplo, no es lo mismo "me duele el hombro" que "me duele el hongo". Un LLM probablemente entendería por contexto que el usuario quiere decir "hombro", pero cuando usamos esa transcripción tal cual para buscar en el RAG, "me duele el hongo" devuelve resultados completamente distintos. El LLM sabe interpretar errores de transcripción; la búsqueda vectorial, no.

Qué enfoque hemos seguido nosotros

Al contrario de mi pensamiento respecto al RAG cuando hablamos por primera vez sobre si implementar el RAG en Diga, hoy tengo una visión algo distinta. Tras analizar el problema, hemos llegado a una solución que acaba en cierta medida con algunos de los problemas de este sistema.

El procesamiento

Muchas veces hablamos del RAG como algo que ocurre solo cuando el usuario hace una pregunta, pero una de las partes más importantes es lo que pasa antes, es la parte de cómo procesamos los documentos.

Cada documento es un mundo: unos llevan tablas, otros tienen secciones separadas que deberían ir juntas, otros son webs con un formato completamente distinto... No podemos simplemente cortar el texto en bloques de 500 palabras y esperar que funcione. Es como si cortases un libro por la mitad de cada página, perderías el hilo constantemente. Nuestro sistema entiende la estructura del documento (títulos, secciones, tablas) y corta respetándola, de forma que cada fragmento tenga sentido por sí solo.

Con las webs la cosa se complica más. Hoy en día muchas páginas renderizan el contenido con JavaScript, así que un simple "descargar el HTML" no sirve. Necesitamos un navegador real que renderice la página, haga scroll y hasta haga click en los acordeones para extraer todo el contenido.

El rewriter

Como comentaba antes, el texto que nos llega del STT muchas veces no se puede usar directamente para buscar. A veces el usuario dice "hombro" y el STT entiende "hongo", y otras veces dice "cuéntame más sobre eso" y necesitamos saber qué es "eso".

Aquí es donde entra el rewriter. Es un modelo pequeño que toma los últimos mensajes de la conversación y genera una query mejorada. Si se ha estado hablando de un "programa de partners" (por cierto, aún nos queda hueco en el nuestro, ¡¡háblanos a contact@diga.io si te interesa!!) y el usuario pregunta "¿y cuáles son los precios de eso?", el rewriter genera algo como "precios del programa de partners". Una query contextualizada que además evita problemas como el del "hongo" ya que se sabe de lo que está hablando.

Además, si el usuario simplemente dice "hola" o "gracias", el rewriter lo detecta y nos ahorramos una búsqueda innecesaria. Todo esto con un modelo muy pequeñito que evita que la latencia suba más de 150-200ms.

La búsqueda

La búsqueda combina dos enfoques en paralelo. Una búsqueda semántica (que entiende el significado) y una búsqueda léxica (que busca coincidencias exactas de palabras). Es como tener a dos personas buscando: una que entiende de qué va la pregunta y otra que busca las palabras exactas. Entre las dos, cubres muchos más casos.

De ahí sacamos 10 candidatos que después pasan por un reranker, un segundo modelo que puntúa cada fragmento en relación a la query, y nos quedamos con los 5 más relevantes.

Los límites del RAG (y los nuestros)

Nuestro sistema no es infalible; sigue habiendo casos donde no se comporta como esperamos. Pero creemos que mejora bastante lo que se hace hoy en día, con una condición básica: que la conversación se siga sintiendo natural.

Dicho esto, hay una pregunta que me hago muy a menudo: ¿estamos seguros de que esto debería ser un RAG?

A veces intentamos meter en el RAG cosas que no tienen sentido ahí. Un caso que me viene a la mente es la búsqueda de referencias de productos. Imagina un archivo con miles de líneas como estas:

Lo subimos y esperamos que el RAG nos devuelva el resultado correcto al instante. Pero piénsalo: si le pidieras esto a una persona, lo primero que haría sería pedirte que le repitieras cada letra y después buscarlo en una base de datos. Si una persona lo busca en una base de datos, ¿por qué no pedirle a nuestro agente que haga lo mismo mediante una llamada a función?

En el otro extremo, a veces el RAG es demasiado para lo que necesitas. Si quieres que el agente conozca el menú de un restaurante o unas reglas básicas de comportamiento (los guardrails), muchas veces tiene más sentido meterlo directamente en el prompt del modelo.

En general, creo que debemos reconocer que hay sitios donde el RAG no es la mejor opción. Y también es que quizás la respuesta no sea "RAG sí o RAG no", sino saber distinguir qué tipo de búsqueda necesita cada pregunta. De hecho, ese es un trabajo que debemos hacer nosotros personalmente: nuestro objetivo debe ser que la plataforma sea capaz de clasificar automáticamente los distintos contenidos y decidir dónde debería ir cada uno, para que tú simplemente te preocupes de subir tu información y ya. Hasta entonces, vosotros, como integradores sois los que debéis decidir en que parte deberá ir cada información.

Así que a pesar de que al principio decía que no a implementar el RAG en IA de voz, he acabado escribiendo un post sobre cómo lo hemos implementado. Las cosas cambian cuando te sientas a resolver los problemas en lugar de descartarlos.

Esta es la primera entrada de lo que esperamos sean muchas, donde iremos compartiendo lo que nos encontramos en el día a día y algunos de los debates que tenemos en Diga.