1 pontos por GN⁺ 2024-06-28 | 1 comentários | Compartilhar no WhatsApp
  • A IA de voz precisa responder imediatamente, como em uma conversa normal, para soar natural, por isso esta demo tem como meta uma resposta voz-a-voz de 500 ms
  • O principal desafio é reduzir a latência percebida pelo usuário, já que tanto a rede quanto o tempo de processamento do modelo influenciam nisso
  • A demo mostra até onde é possível chegar com interações de LLM de baixa latência por meio de otimização e estratégias de implantação
  • A implementação usa o framework open source Pipecat para IA conversacional de voz e multimodal
  • Para criar um bot de voz conversacional em nível de produto real, é importante gerenciar a latência de todo o caminho de chamada, e não apenas o desempenho do modelo

Demo voltada a respostas de voz em 500 ms

  • The World's Fastest Voice Bot Demo é uma demonstração de quão rapidamente um chatbot de IA baseado em voz pode responder
  • O objetivo é alcançar um tempo de resposta voz-a-voz de 500 ms
  • Como as pessoas esperam respostas rápidas em conversas normais, a velocidade se torna um fator central de qualidade em interfaces de IA por voz

Direção de implementação para reduzir a latência

  • A demo é estruturada em torno de interações de LLM de baixa latência
  • Ela mostra o potencial de chatbots de IA por voz otimizados e implantados para minimizar a latência de rede e do modelo
  • O bot foi criado com Pipecat
    • Pipecat é um framework open source para IA conversacional de voz e multimodal

1 comentários

 
GN⁺ 2024-06-28
Opiniões no Hacker News
  • Muito rápido. Excelente e limpo. Dá a sensação de que a velocidade supera todo o resto. Só depois de ler os comentários é que percebi a voz meio robótica.
    Já criei uma IA para atendimento ao cliente, e o tempo médio de resposta caiu de 24–48 horas para alguns segundos.
    Uma mensagem como “Hello Bitch, your package will be picked up by USPS today...” foi enviada a uma cliente, e ela respondeu “thank you so much” e deu nota máxima no CSAT. Mesmo com um erro tão grave, a velocidade supera tudo.

    • Acho que nem todo mundo reagiria assim. Para algumas pessoas, chamar umas às outras de bitch faz parte do jeito cotidiano de falar e pode ter entrado nos dados de treinamento, mas para outras pode não ter nada a ver.
    • O engraçado é que corrigiram esse problema adicionando uma tag #profanity e encaminhando a mensagem para o próximo atendente.
      Só que o engenheiro de vendas mais ativo deixou de conseguir fazer demos para prospects. Havia muitas chamadas constrangedoras em que a IA simplesmente não respondia, porque o sobrenome dele era Dick.
    • Uma solução talvez fosse passar a mensagem por outro LLM para remover palavrões e deixá-la o mais educada possível. Mas acho que o custo de execução ficaria mais que o dobro.
    • Talvez esse fosse o nome da cliente. Ou pelo menos o nome que ela digitou.
  • Muito, muito bom. Se entendi corretamente, parece um app teaser para mostrar o Cerebrium, mas tem grande potencial de killer app. Testei no iPad, e a latência reportada ficou entre 1400 ms e 400 ms; no extremo mais baixo, parecia muito fluido.
    Com esse nível de velocidade, em alguns fluxos de chat uma abordagem em várias etapas deve se tornar necessária ou possível. Primeiro responder rapidamente enquanto uma consulta mais longa de dados/informações/RAG roda em separado, e depois um resultado informativo assume a conversa.
    Humanos também funcionam assim. Começamos a responder e usamos vários marcadores de preenchimento enquanto organizamos os pensamentos.
    Hoje, na maioria das vezes, ou se manda um prompt de uma vez, ou se faz parsing → consulta → geração em segundo plano; mas, quando respostas de baixa latência forem possíveis, um fluxo melhor provavelmente será algo como “[Llama 8B por 3 segundos no ouvido] → consulta → [55 segundos de Llama 70B/GPT-4 etc. refletindo o resultado da consulta]”.

    • Sou do Cerebrium. Muito obrigado pelo feedback, e fico feliz que a experiência tenha sido boa.
      Esta aplicação é fácil de ampliar ou implementar, então você pode modificá-la como quiser. Dá para trocar por outro LLM, reconhecimento de fala ou modelo de síntese de voz, mudar o prompt e também implementar coisas como RAG.
      Junto com a Daily, focamos em engenheiros. Tentamos permitir que a aplicação seja alterada de forma muito flexível para se adequar ao caso de uso e às preferências, enquanto tiramos da frente a parte chata de configurar infraestrutura.
      Você pode ver mais sobre como expandi-la aqui: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
    • Eu também estava curioso sobre isso. Será que é possível ter um LLM pequeno e eficiente capaz de estimar a complexidade da tarefa em termos gerais sem executar a carga de trabalho completa de fato?
      Se der para pontuar a complexidade como um valor contínuo, dá para saber se é melhor enviar primeiro uma resposta como “sim, só um instante. Vou verificar” em vez de esperar por uma ida e volta longa.
  • Como módulo de detecção de atividade de voz para navegadores cross-platform, existe https://github.com/ricky0123/vad. É um porte da rede VAD da Silero para ONNX. Cross-platform aqui significa que também funciona no Firefox. É mais simples porque só precisa de acesso ao microfone, sem uma sessão WebRTC. Também tenho curiosidade de ver navegadores oferecendo esse recurso como opção nativa.
    Também existem motores de texto para fala baseados no navegador, e eles estão ficando cada vez mais rápidos e com melhor qualidade. Seria bom se os navegadores viessem com um ótimo TTS nativo.
    O GPT-4o colocou reconhecimento automático de fala, compreensão e geração de resposta por voz em um único modelo para baixa latência, o que parece uma ideia bem boa. Como ainda não foi lançado, parece haver algum problema de escalabilidade ou qualidade, de uma forma ou de outra.
    Da mesma forma, deve haver gente criando modelos grandes de linguagem multimodais integrados e abertos, com entrada/saída de áudio e até entrada visual.
    Tenho curiosidade sobre quanto um modelo único acoplado é necessário e ideal em termos de otimização de latência e custo.
    A decomposição fornecida é interessante. Se possível, parece melhor rodar mais modelos no dispositivo, como geração de voz e talvez até transcrição ou compreensão de fala no início. Quem quer ficar esperando STUN?

    • Acho que ambientes de desktop deveriam oferecer conversão de fala em texto como um serviço com uma interface padrão. Algo parecido com stdin, mas separado para voz.
      Os apps, por padrão, não estariam ouvindo, então ignorariam; mas o transcritor poderia ser substituído e usado por todos os apps.
    • Pelos números, mesmo processando reconhecimento de fala e síntese de voz no dispositivo, se o restante ficar igual isso só reduziria 120 ms. Os 639 ms restantes ficam em latência de hardware e rede, além de mover dados para dentro e para fora do LLM. Ainda assim é mais lento do que o desejado.
      Logicamente, é preciso pensar em nível de fonemas. A saída do LLM precisa alcançar o último fonema rápido o suficiente para responder “imediatamente” no momento em que o fim da fala é detectado, e para isso toda a cadeia precisa ter uma latência fim a fim de cerca de 200 ms.
      Para chegar perto disso, acho que seria necessária uma arquitetura diferente. Algo parecido com o processamento de fala humano: avançar o stream de áudio com base em fonemas previstos antes de eles chegarem, e usar o áudio recebido de fato apenas como um sinal leve de confirmação para decidir se esvazia o buffer de saída atual ou reprocessa.
      Com speculative decoding dá para ir até certo ponto, mas com um pipeline misturando áudio/texto parece difícil. Para começo de conversa, é muito melhor não converter áudio em texto e depois voltar para áudio.
    • Embora este anúncio tenha ofuscado completamente o que eu estava criando, tenho uma implementação simples de assistente usando rick0123/VAD e WebSocket.
      https://github.com/charlesyu108/voiceai-js-starter
  • Usei diretamente e achei divertido. No começo desta semana, experimentei o june-va, mas o tempo de resposta longo reduzia bastante a utilidade. Respostas rápidas são um ótimo recurso, e isto parece muito mais uma conversa
    O engraçado é que pedi para ele me contar uma história e ele respondia só uma frase por vez, então eu precisava dizer “yes”, “aha”, “please continue” para ouvir a próxima linha
    Aí tivemos esta conversa: “Ah, acho que descobri o seu segredo!” “Por favor, diga” “Você consegue tempos de resposta curtos mantendo um contexto curto” “Exatamente”

    • Sinceramente, esse método é bom. Além de contexto curto, respostas curtas são definitivamente boas. Contrasta com o modo de voz atual do ChatGPT, que quando você pergunta algo entrega um discurso de 1 minuto no estilo GPT
  • Muito impressionante. É extremamente rápido, talvez até rápido demais, mas parece que esse é o ponto. O mais impressionante é como o VAD e o tratamento de interrupções foram ajustados. Foi, de longe, a conversa com agente que soou mais natural até agora. Quando for lançado, com certeza quero experimentar

  • No marketing está escrito 500, mas o cálculo dá 759

    • Isso se chama marketing
    • No meu teste houve um outlier de 1400 ms, e umas 10 vezes ficaram entre 400 e 500 ms. O número de marketing me pareceu justo
    • 500 é para as etapas de transcrição/LLM/TTS, ou seja, o tempo desde que os dados chegam ao servidor até a resposta ser enviada de volta. O restante parece ser várias latências adicionais não relacionadas a IA, como codificação e tráfego de rede
    • As latências da tabela se baseiam em heurísticas observadas ou médias. Na prática, dependendo da conversa, alguns dos componentes de latência maiores podem ser bem menores
  • Eu também estou ansioso por inferência por voz. Antes do lançamento do GPT-4o da OpenAI, implementei por conta própria uma versão do Faster Whisper baseada em WebSocket. Minhas implementações do conceito de coach de entrevistas https://intervu.trueforma.ai e do coach de pitch de vendas https://sales.trueforma.ai acabaram ficando para trás deles
    Não consegui fazer o VAD funcionar de forma estável, então deixei push-to-talk como padrão. Tudo roda em um LattePanda. Eu pretendia conectar o Whisper hospedado da Groq
    Cansado de conversas corporativas entediantes, gostei da ideia de usar o Llama3 sem censura da Groq como LLM. Quero reduzir a latência e aprender com os exemplos. Também quero testar a demo, mas parece estar sobrecarregada demais, então não consigo entrar em uma conversa com o bot
    Acho que, se apenas 3 pessoas tentarem inferência ao mesmo tempo, meu LattePanda vai derreter

  • Pessoalmente, uso https://github.com/foges/whisper-dictation junto com o llama-70b da Groq
    Quando começo a falar, navego até o site e, quando termina de carregar e eu seleciono o llama-70b, também já terminei de falar, então a latência adicional é zero. Como ler é muito mais rápido do que ouvir, isso funciona perfeitamente para mim

  • Ainda uso Firefox

    • Criei esta UI de cliente e queria muito dar suporte ao Firefox
      Precisávamos de uma forma de medir a latência de voz para voz do ponto de vista do usuário final, e consideramos que a detecção de atividade de voz Silero (https://github.com/snakers4/silero-vad) era a mais confiável para detectar quando o usuário para de falar, iniciar o temporizador e pará-lo quando o áudio chega do bot
      O Silero roda com onnx-runtime e wasm. No Firefox ele até funciona em certa medida, mas o VAD falha com mais frequência do que o esperado, então os números de latência ficam bem estranhos. Ainda assim, quero muito fazer funcionar e continuo tentando
      O código do VAD da UI está aqui: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
    • Você não precisa acreditar só na mensagem de aviso. Funciona bem no Firefox mais recente. A demo também é bacana
    • Odeio que todo mundo desenvolva só mirando Chromium
    • Acho que há bastante gente no HN que usa Firefox
    • Funciona perfeitamente no Firefox 127
  • Realmente impressionante
    A Siri da Apple ainda só permite uma conversa em que vocês se atropelam, ela para, falha, e no fim você fica torcendo para conseguir ao menos uma resposta mínima