Este artículo se actualizó en julio de 2025

TL;DR

Este artículo explora los métodos para reducir la latencia en los sistemas de Generación Aumentada de Recuperación (RAG), en particular en las interacciones de voz en tiempo real para aplicaciones de servicio/soporte al cliente.

Introducción

Con la adopción de la Generación Aumentada por Recuperación (RAG), a muchas organizaciones les resulta más fácil acceder a las capacidades generativas de los Grandes Modelos Lingüísticos (LLM) sin recurrir a costosos o complejos modos de entrenamiento, como el pre-entrenamiento, el ajuste fino, el RLHF o los adaptadores. La RAG permite a las organizaciones construir bases de conocimiento que contengan grandes cantidades de información y recuperar sólo las partes relevantes, proporcionando a los LLM una respuesta completa sin incorporar la información directamente al LLM.

¿Qué es el GAR?

En la GAR, un modelo recupera documentos o información relevante de una gran base de datos y, a continuación, genera una respuesta utilizando esa información recuperada. La GAR suele utilizar un sistema de dos partes: un recuperador y un generador. El recuperador busca documentos o pasajes relevantes a partir de una consulta, a menudo utilizando métodos como la recuperación dispersa, densa e híbrida, siendo la búsqueda semántica (basada en vectores) la más utilizada para obtener resultados rápidos y contextualmente precisos. El generador (a menudo un modelo como GPT) sintetiza la información recuperada para generar la respuesta final. De este modo, el modelo puede ofrecer respuestas más precisas y objetivamente correctas.

Dos de los casos de uso más populares del GAR son:

1. Atención al cliente: Exponer la información externa/interna de una empresa en un formato conversacional utilizando agentes virtuales/asistentes/chatbots para los usuarios finales y automatizando las preguntas frecuentes y los módulos de preguntas y respuestas, lo que se traduce en una alta tasa de contención.

2. Búsqueda de empresas: Hacer que la información privada de la organización sea consultable y proporcionar respuestas más precisas mediante la conexión a fuentes de datos como Google Drive, Confluence, JIRA, Zendesk, sitios web, archivos estáticos, etc.

Voice y latencia conversacional aceptable

Cuando se utiliza el GAR para la atención al cliente, la recuperación de información o las conversaciones con los LLM suelen producirse en canales de voz o digitales (como la web, WhatsApp, SMS, etc.). La latencia es un factor crítico en las comunicaciones en tiempo real, ya que puede afectar significativamente a la calidad y eficacia de la conversación. En la comunicación en tiempo real, la latencia se refiere al retardo entre el momento en que un sonido es producido por el hablante y el momento en que es escuchado por el oyente.

El canal de voz tiene una baja tolerancia a la latencia, y el UIT-T (Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones) recomienda una latencia unidireccional de 100 ms para tareas interactivas y de 150 ms para casos de uso conversacional en los que intervienen seres humanos en ambos extremos. Los canales digitales suelen tener mayores niveles de tolerancia que los de voz. Este artículo analiza específicamente la latencia de los canales de voz cuando se utiliza la GAR para interacciones entre humanos, asistentes virtuales, agentes y chatbots.

Conseguir una latencia unidireccional de 150 ms es casi imposible con una arquitectura tipo RAG en la que intervienen varios componentes en el procesamiento de la voz. Sin embargo, pueden lograrse experiencias cercanas al tiempo real con la optimización correcta de la lógica de procesamiento de voz y los modelos de IA. Los usuarios finales de asistentes virtuales/agentes/chatbots son más tolerantes a los retrasos en comparación con las conversaciones entre humanos, que son muy sensibles a la latencia.

Vista de extremo a extremo de una llamada de Voice

End-to-end view of a voice call

Un canal de llamadas de voz con RAG puede dividirse en varios componentes. Normalmente comienza con una conversación iniciada en una aplicación web o por teléfono por el usuario final, con latencia de red acumulada hasta que la voz llega al servicio. Una vez que la voz llega al servicio, el primer paso consiste en convertirla en texto mediante un servicio de conversión de voz en texto (STT). A continuación, el texto transcrito se utiliza para recuperar información, y el contexto recuperado se transmite a un LLM para generar una respuesta. La respuesta generada se envía a un servicio de conversión de texto a voz (TTS), que vuelve a convertir el texto en voz. Por último, la voz se transmite a la aplicación web o al teléfono a través de la red para que el usuario la escuche.

Dispositivo/aplicación/navegador

Una conversación del usuario final suele comenzar con un dispositivo/aplicación/navegador conectado a Internet. El dispositivo/aplicación/navegador del usuario final desempeña un papel crucial en la latencia, ya que captura el audio y realiza la codificación. También gestiona la respuesta recibiendo el audio y descodificándolo.

Normalmente tienes tres opciones para los dispositivos finales:

1. Teléfono RTC Teléfono PSTN : Si los usuarios finales marcan números físicos en lugar de utilizar la función de llamada dentro de la aplicación o el navegador web, es necesario enviar el audio a una pasarela PSTN antes de enviarlo al servicio de voz a texto o ASR para su transcripción.

2. Aplicaciones Móviles Las aplicaciones móviles pueden transmitir audio a través de WebSockets o WebRTC. Sin embargo, los WebSockets, que se basan en TCP, pueden sufrir problemas de rendimiento en redes de alta latencia.

3. Navegador web : Los navegadores web ya están equipados con WebRTC para la comunicación en tiempo real, lo que permite una transmisión multimedia de baja latencia basada en UDP.

Recomendación: La latencia baja se consigue mejor si la aplicación se basa en WebRTC.

Red de enlace ascendente y descendente

Las condiciones de latencia de las redes de enlace ascendente y descendente son variadas e impredecibles para los usuarios finales, por lo que resulta difícil ofrecer aquí recomendaciones específicas.

Servicio de voz a texto

Este paso es crucial, ya que el servicio convierte el habla en texto para su posterior procesamiento. Es importante lograr una alta precisión con baja latencia, ya que la precisión de este paso afecta a la eficiencia general del canal de respuesta. Varios proveedores, como Speechmatics, Deepgram, Google ASR y AWS Transcribe, ofrecen servicios de conversión de voz a texto. Hay dos modos disponibles:

1. Procesamiento pregrabado (por lotes) Un búfer o archivo de audio grabado se envía al proveedor de voz a texto por lotes. Este método suele implicar la espera del silencio antes del procesamiento, lo que añade latencia.

2. Transmisión en tiempo real Transmisión en tiempo real : Las expresiones del usuario final se envían al servicio STT a medida que se reciben, lo que permite una transcripción más rápida pero puede introducir problemas de precisión. Una detección eficaz de la actividad vocal (VAD) es esencial para la transmisión en tiempo real.

Recomendación: La baja latencia se consigue mejor con el streaming en tiempo real que con el procesamiento por lotes en los servicios de voz a texto.

A partir de 2025, también están disponibles opciones más recientes como AssemblyAI y OpenAI Whisper API (beta), muchas de las cuales admiten endpoints en tiempo real para mejorar la capacidad de respuesta.

Recuperación de información

Los métodos de búsqueda utilizados en la GAR son cruciales para recuperar documentos o pasajes relevantes y de alta calidad que el modelo generativo pueda utilizar para producir respuestas informativas. La elección del método de recuperación, ya sea disperso, denso o híbrido, depende de factores como la precisión de las respuestas, la latencia y las limitaciones computacionales. Los métodos de recuperación híbridos, que combinan técnicas dispersas y densas, están ganando popularidad por su capacidad para combinar precisión y recuperación, lo que los hace muy eficaces en los sistemas GAR.

La búsqueda vectorial, también conocida como búsqueda semántica, suele utilizar incrustaciones (representaciones vectoriales) de texto y luego busca sobre esas incrustaciones para encontrar los resultados más similares. La latencia de la búsqueda vectorial puede reducirse utilizando vectores de incrustación más cortos (pero contextualmente precisos) y algoritmos de revalorización más rápidos para filtrar el contexto irrelevante. El almacenamiento en caché y las bases de datos vectoriales locales también pueden mejorar la latencia de la búsqueda.

Recomendación: Para las conversaciones en tiempo real, la búsqueda semántica es generalmente una mejor opción debido a su velocidad y eficiencia. Permite una recuperación casi instantánea, esencial para mantener el flujo de las interacciones en directo.

Aunque MongoDB Atlas Search ahora admite la búsqueda vectorial, para aplicaciones de latencia más baja y en tiempo real, las bases de datos vectoriales dedicadas como Weaviate, Qdrant, Pinecone o FAISS suelen ser más eficaces.

Procesamiento LLM

La parte de generación del sistema RAG utiliza un LLM para producir respuestas coherentes y contextualmente relevantes basadas en la información recuperada y la consulta del usuario. El tiempo transcurrido hasta el primer token (TTFT) es una importante medida de rendimiento. Se refiere al tiempo que tarda un modelo en generar el primer token de salida tras recibir una petición. Esta métrica es crucial en aplicaciones interactivas como chatbots, asistentes virtuales y generación de contenidos en tiempo real.

En los modelos de procesamiento por lotes como Google Chat Bison, TTFT se refiere generalmente al tiempo que se tarda en generar la respuesta completa, lo que puede causar retrasos ya que el servicio de texto a voz (TTS) debe esperar a que se genere la respuesta completa antes de procesarla. En cambio, los modelos de streaming como Gemini 1.5 Pro permiten medir el TTFT desde el momento en que se genera el primer token, lo que permite una salida inmediata. Esto significa que el servicio TTS puede empezar a procesar y entregar partes de la respuesta a medida que están disponibles, lo que mejora significativamente la experiencia del usuario al reducir la latencia percibida.

Es posible que en el futuro se produzcan avances en los que el componente recuperador se minimice o elimine por completo, lo que se conseguirá mediante modelos más sofisticados con ventanas contextuales más grandes, como la familia de modelos Google Vertex Gemini. Hay otros factores que también afectan a la generación de respuestas LLM, y optimizaciones como la reducción del tamaño de la solicitud o el uso de caché de contexto pueden reducir la latencia. En algunos casos, puede optar por un Small Language Model (SLM) en lugar de un LLM, cambiando algo de precisión por tiempos de respuesta más rápidos. Proveedores como FireworksAI se centran en optimizar los modelos específicamente para la latencia. Los modelos de lenguaje pequeños, como Claude 3 Haiku o Mistral 7B Instruct, también están ganando popularidad para aplicaciones de latencia crítica en las que no es necesario un razonamiento LLM a gran escala.

Recomendación: La salida LLM en modo streaming puede reducir significativamente la latencia, permitiendo al TTS reproducir antes la respuesta generada. Además, considere modelos más rápidos como Google Gemini Flash 8B, que ofrecen latencias más bajas.

Servicio de texto a voz

Este paso es crucial, ya que el servicio convierte el texto en voz para reproducirlo o transmitirlo. Proveedores como Amazon Polly, Google TTS y Eleven Labs ofrecen servicios de conversión de texto a voz, normalmente en dos modos:

1. Procesamiento pregrabado (por lotes) Convierte grandes cantidades de texto en voz en una sola operación asíncrona. Resulta útil para aplicaciones en las que el procesamiento en tiempo real no es crítico, como la generación de audio para libros electrónicos, podcasts o anuncios pregrabados.

2. Streaming en tiempo real Voice : Esencial para aplicaciones que requieren salida de voz inmediata, como asistentes virtuales, sistemas de respuesta de voz interactiva (IVR) y herramientas de comunicación en tiempo real.

Recomendación: El streaming en tiempo real es preferible para lograr una baja latencia en comparación con el procesamiento por lotes.

Conclusión

En la latencia de las aplicaciones de voz en tiempo real que utilizan GAR influyen muchos factores, y varias técnicas de optimización pueden ayudar a controlarla. La tabla siguiente resume la latencia bidireccional máxima prevista en distintas fases de la comunicación de voz. Con optimizaciones, se pueden esperar mejoras significativas en la latencia. La tabla excluye las latencias introducidas por el dispositivo y las redes de enlace ascendente/descendente.

1. Búsqueda semántica - La base de datos vectorial se basa en MongoDB

2. LLM - sin streaming

3. LLM - con streaming

Mediante la aplicación de estas estrategias de optimización, puede reducir drásticamente la latencia en las aplicaciones de voz que utilizan la canalización RAG, garantizando conversaciones en tiempo real más fluidas y eficaces.

Póngase en contacto

Echa un vistazo a nuestro Vonage AI Studio para crear conversaciones de voz de baja latencia o ponte en contacto a través de Slack de la comunidad de Vonage o envíanos un mensaje en X.