Este artigo foi atualizado em julho de 2025

Resumo

Este artigo explora métodos para reduzir a latência em sistemas de Geração Aumentada por Recuperação (RAG), especialmente em interações de voz em tempo real para aplicações na área de atendimento e suporte ao cliente.

Introdução

Com a adoção da Geração Aumentada por Recuperação (RAG), muitas organizações consideram mais fácil acessar os recursos generativos dos Grandes Modelos de Linguagem (LLMs) sem recorrer a métodos de treinamento caros ou complexos, como pré-treinamento, ajuste fino, RLHF ou adaptadores. O RAG permite que as organizações criem bases de conhecimento contendo grandes quantidades de informações e recuperem apenas as partes relevantes, fornecendo aos LLMs uma resposta abrangente sem incorporar as informações diretamente no LLM.

O que é RAG?

No RAG, um modelo recupera documentos ou informações relevantes de um grande banco de dados e, em seguida, gera uma resposta utilizando essas informações recuperadas. O RAG normalmente utiliza um sistema composto por duas partes: um recuperador e um gerador. O recuperador busca documentos ou trechos relevantes com base em uma consulta, frequentemente utilizando métodos como recuperação esparsa, densa e híbrida, sendo que a busca semântica (baseada em vetores) é comumente usada para obter resultados rápidos e contextualmente precisos. O gerador (geralmente um modelo como o GPT) sintetiza as informações recuperadas para gerar a resposta final. Isso permite que o modelo forneça respostas mais precisas e factualmente corretas.

Dois dos casos de uso mais populares do RAG são:

1. Atendimento ao Cliente: Divulgar informações externas e internas de uma empresa em um formato coloquial, utilizando agentes virtuais, assistentes e chatbots para os usuários finais, além de automatizar as seções de perguntas frequentes e módulos de perguntas e respostas, resultando em uma alta taxa de retenção.

2. Pesquisa Corporativa: Tornar as informações privadas da organização pesquisáveis e fornecer respostas mais precisas por meio da conexão com fontes de dados como Google Drive, Confluence, JIRA, Zendesk, sites, arquivos estáticos etc.

Voice e latência conversacional aceitável

Ao utilizar o RAG para atendimento ao cliente, a recuperação de informações ou as conversas com LLMs geralmente ocorrem em canais de voz ou digitais (como a web, o WhatsApp, SMS etc.). A latência é um fator crítico nas comunicações em tempo real, pois pode afetar significativamente a qualidade e a eficácia da conversa. Na comunicação em tempo real, a latência se refere ao atraso entre o momento em que um som é produzido pelo locutor e o momento em que é ouvido pelo ouvinte.

O canal de voz tem baixa tolerância à latência, e o ITU-T (Setor de Padronização das Telecomunicações da União Internacional de Telecomunicações) recomenda uma latência unidirecional de 100 ms para tarefas interativas e de 150 ms para casos de uso conversacionais envolvendo pessoas em ambas as extremidades. Os canais digitais geralmente apresentam níveis de tolerância mais elevados em comparação com os canais de voz. Este artigo analisa especificamente a latência do canal de voz ao utilizar RAG para interações entre pessoas e assistentes virtuais, agentes ou chatbots.

Alcançar uma latência unidirecional de 150 ms é quase impossível em uma arquitetura do tipo RAG, na qual vários componentes estão envolvidos no processamento de voz. No entanto, é possível proporcionar experiências quase em tempo real com a otimização correta da lógica de processamento de voz e dos modelos de IA. Os usuários finais de assistentes virtuais, agentes virtuais e chatbots são mais tolerantes a atrasos em comparação com conversas entre pessoas, que são altamente sensíveis à latência.

Visão completa de uma chamada de voz

End-to-end view of a voice call

Um fluxo de chamadas de voz com RAG pode ser dividido em vários componentes. Normalmente, ele começa com uma conversa iniciada pelo usuário final em um aplicativo web ou por telefone, com a latência da rede se acumulando até que a voz chegue ao serviço. Assim que a voz chega ao serviço, a primeira etapa envolve convertê-la em texto usando um serviço de conversão de fala em texto (STT). O texto transcrito é então usado para a recuperação de informações, e o contexto recuperado é passado para um LLM (modelo de linguagem grande) para gerar uma resposta. Essa resposta gerada é então enviada a um serviço de conversão de texto em fala (TTS), que converte o texto de volta em voz. Por fim, a voz é transmitida de volta ao aplicativo web ou ao telefone pela rede para ser reproduzida para o usuário final.

Dispositivo/Aplicativo/Navegador

Uma conversa do usuário final geralmente começa com um dispositivo/aplicativo/navegador conectado à Internet. O dispositivo/aplicativo/navegador do usuário final desempenha um papel crucial na latência, pois captura o áudio e realiza a codificação. Ele também lida com a resposta, recebendo o áudio e decodificando-o.

Normalmente, você tem três opções de dispositivos finais:

1. Telefone PSTN : Se os usuários finais discarem números físicos em vez de usar a função de chamada dentro do aplicativo ou do navegador da web, o áudio precisa ser enviado a um gateway PSTN antes de ser encaminhado ao serviço de conversão de fala em texto ou ASR para transcrição.

2. Applications móveis : Os aplicativos móveis podem transmitir áudio por meio de WebSockets ou WebRTC. No entanto, os WebSockets, que são baseados no protocolo TCP, podem apresentar problemas de desempenho em redes de alta latência.

3. Navegador da Web : Atualmente, os navegadores da Web estão equipados com WebRTC para comunicação em tempo real, permitindo streaming de mídia com baixa latência baseado no protocolo UDP.

Recomendação: A baixa latência é melhor alcançada se o aplicativo for baseado em WebRTC.

Rede de uplink e downlink

As condições de latência das redes de uplink e downlink são variadas e imprevisíveis para os usuários finais, o que torna difícil oferecer recomendações específicas neste contexto.

Serviço de conversão de fala em texto

Essa etapa é crucial, pois o serviço converte a fala em texto para processamento posterior. É importante alcançar alta precisão com baixa latência, já que a precisão dessa etapa afeta a eficiência geral do fluxo de respostas. Vários provedores, como Speechmatics, Deepgram, Google ASR e AWS Transcribe, oferecem serviços de conversão de fala em texto. Estão disponíveis dois modos:

1. Processamento pré-gravado (em lote) : Um buffer ou arquivo de áudio gravado é enviado ao provedor de conversão de fala em texto em partes. Essa abordagem geralmente envolve aguardar um período de silêncio antes do processamento, o que aumenta a latência.

2. Transmissão em tempo real : As falas do usuário final são enviadas ao serviço de reconhecimento de fala (STT) assim que são recebidas, o que permite uma transcrição mais rápida, mas pode causar problemas de precisão. A detecção eficiente de atividade de voz (VAD) é essencial na transmissão em tempo real.

Recomendação: É mais fácil obter baixa latência com streaming em tempo real do que com processamento em lote nos serviços de conversão de fala em texto.

A partir de 2025, também estão disponíveis opções mais recentes, como o AssemblyAI e a API OpenAI Whisper (beta), muitas das quais oferecem suporte à integração com endpoints em tempo real já pronta para uso, a fim de melhorar a capacidade de resposta.

Recuperação de Informações

Os métodos de busca utilizados no RAG são cruciais para recuperar documentos ou trechos relevantes e de alta qualidade que o modelo generativo possa utilizar para produzir respostas informativas. A escolha do método de recuperação — seja ele esparso, denso ou híbrido — depende de fatores como a precisão das respostas, a latência e as restrições computacionais. Os métodos de recuperação híbridos, que combinam técnicas esparsas e densas, estão ganhando popularidade por sua capacidade de aliar precisão e recall, tornando-os altamente eficazes em sistemas RAG.

A pesquisa vetorial, também conhecida como pesquisa semântica, normalmente utiliza embeddings (representações vetoriais) de texto e, em seguida, realiza a pesquisa nessas representações para encontrar os resultados mais semelhantes. A latência da pesquisa vetorial pode ser reduzida com o uso de vetores de incorporação mais curtos (mas ainda assim contextualmente precisos) e algoritmos de reavaliação mais rápidos para filtrar o contexto irrelevante. A implementação de cache e de bancos de dados vetoriais locais também pode melhorar a latência da pesquisa.

Recomendação: Para conversas em tempo real, a pesquisa semântica geralmente é a melhor opção devido à sua velocidade e eficiência. Ela permite uma recuperação quase instantânea, o que é essencial para manter o fluxo das interações ao vivo.

Embora o MongoDB Atlas Search agora ofereça suporte à pesquisa vetorial, para aplicações que exigem menor latência e em tempo real, bancos de dados vetoriais dedicados, como Weaviate, Qdrant, Pinecone ou FAISS, geralmente apresentam melhor desempenho.

Processamento de LLM

A parte de geração do sistema RAG utiliza um LLM para produzir respostas coerentes e contextualmente relevantes com base nas informações recuperadas e na consulta do usuário. O Tempo até o Primeiro Token (TTFT) é uma importante métrica de desempenho. Refere-se ao tempo que um modelo leva para gerar o primeiro token de saída após receber um prompt. Essa métrica é crucial em aplicações interativas, como chatbots, assistentes virtuais e geração de conteúdo em tempo real.

Em modelos de processamento em lote, como o Google Chat Bison, o TTFT geralmente se refere ao tempo necessário para gerar a resposta completa, o que pode causar atrasos, já que o serviço de conversão de texto em fala (TTS) precisa aguardar a geração da resposta completa antes de processá-la. Em contrapartida, modelos de streaming como o Gemini 1.5 Pro permitem que o TTFT seja medido a partir do momento em que o primeiro token é gerado, possibilitando uma saída imediata. Isso significa que o serviço de TTS pode começar a processar e entregar partes da resposta à medida que elas ficam disponíveis, melhorando significativamente a experiência do usuário ao reduzir a latência percebida.

O futuro do RAG poderá trazer avanços em que o componente de recuperação seja minimizado ou totalmente eliminado, por meio de modelos mais sofisticados com janelas de contexto maiores, como a família de modelos Google Vertex Gemini. Vários outros fatores também afetam a geração de respostas pelos LLMs, e otimizações como a redução do tamanho do prompt ou o uso armazenamento em cache de contexto podem reduzir a latência. Em alguns casos, você pode optar por um Modelo de Linguagem Pequeno (SLM) em vez de um LLM, trocando um pouco de precisão por tempos de resposta mais rápidos. Provedores como FireworksAI se concentram em otimizar modelos especificamente para a latência. Pequenos modelos de linguagem, como o Claude 3 Haiku ou o Mistral 7B Instruct, também estão ganhando popularidade para aplicações em que a latência é crítica e o raciocínio de um LLM em escala total é desnecessário.

Recomendação: A saída do LLM no modo de streaming pode reduzir significativamente a latência, permitindo que o TTS reproduza a resposta gerada mais rapidamente. Além disso, considere modelos mais rápidos, como o Google Gemini Flash 8B, que oferecem latências mais baixas.

Serviço de conversão de texto em fala

Essa etapa é fundamental, pois o serviço converte o texto em fala para que seja reproduzido ou transmitido. Provedores como Amazon Polly, Google TTS e Eleven Labs oferecem serviços de conversão de texto em fala, geralmente em dois modos:

1. Processamento pré-gravado (em lote) : Converte grandes quantidades de texto em fala em uma única operação assíncrona. Isso é útil para aplicações em que o processamento em tempo real não é essencial, como na geração de áudio para e-books, podcasts ou anúncios pré-gravados.

2. Transmissão em tempo real : Essencial para aplicativos que exigem saída de voz imediata, como assistentes virtuais, sistemas de resposta de voz interativa (IVR) e ferramentas de comunicação em tempo real.

Recomendação: A transmissão em tempo real é preferível para obter baixa latência em comparação com o processamento em lote.

Conclusão

A latência em aplicativos de voz em tempo real que utilizam RAG é influenciada por diversos fatores, e várias técnicas de otimização podem ajudar a controlá-la. A tabela abaixo resume a latência bidirecional máxima esperada em diferentes fases da comunicação de Voice. Com otimizações, é possível esperar melhorias significativas na latência. A tabela não inclui as latências causadas pelo dispositivo e pelas redes de uplink/downlink.

1. Pesquisa semântica — O banco de dados vetorial é baseado no MongoDB

2. LLM — sem classificação por nível 

3. LLM — com streaming 

Ao implementar essas estratégias de otimização, é possível reduzir drasticamente a latência em aplicativos de voz que utilizam o pipeline RAG, garantindo conversas em tempo real mais fluidas e eficientes. 

Entre em contato

Confira nosso Vonage AI Studio para criar conversas de voz com baixa latência ou entre em contato pela Slack da Comunidade Vonage ou envie uma mensagem para nós no X.