GPTunneL levou o assistente de voz GROM a uma transmissão ao vivo: o que quebrou em 3 horas de hackathon

Um assistente de voz à mesa comum é uma ideia fácil de entender, até chegar a uma transmissão ao vivo. A equipe da GPTunneL a testou no hackathon «Novas Cidades» no «Grande Fizteh»: por três horas o GROM ouviu especialistas, escolares e estudantes que projetavam uma vila do futuro, e respondeu a perguntas em voz alta. O resultado não foi perfeito, mas a análise é honesta.

Como funciona

Não houve palavra de ativação. A fala do microfone era reconhecida, olhava-se a primeira palavra de cada fala e, se fosse «Grom», o texto seguia para o modelo. A resposta era narrada pela voz sintética de Filipp, desenvolvida pela própria equipe. No ensaio, o GROM se intrometia na conversa por conta própria e interrompia ideias, por isso, para a transmissão, foi colocado no modo «fala só se for chamado».

A principal dificuldade é que as pessoas passam quase o tempo todo conversando entre si, e não com o assistente. Para que o GROM soubesse o que havia sido combinado, a transmissão era processada por um pipeline separado. O vMix salvava um arquivo de vídeo a cada cinco minutos, o Resilio o transferia para um segundo computador, um Whisper local fazia a transcrição e o Claude Sonnet atualizava um resumo: quem propôs o quê, o que foi decidido, o que ficou em aberto. O resumo atualizado era inserido na instrução de sistema do GROM. O Sonnet foi escolhido porque a equipe já havia verificado seus resumos muitas vezes.

Onde tudo desandou

A primeira falha foram quinze minutos perdidos. Quando vários arquivos chegavam ao mesmo tempo, o processador pegava o mais recente e não tinha fila. Depois do oitavo arquivo veio o décimo segundo, e os fragmentos do nono ao décimo primeiro tiveram de ser processados à mão.

A segunda foram os nomes. O Whisper não recebeu uma lista de nomes, e GPTunneL virou GPTanal. Pior foi a marcação de falantes: em cada arquivo a numeração recomeçava, e o «Falante 1» em fragmentos vizinhos podia ser duas pessoas diferentes.

A terceira foi o contexto. Uma longa discussão sobre se o mentor teria barba entupiu o histórico do diálogo. Nove minutos depois, diante da pergunta se uma pessoa pode viver menos sem convívio, o GROM voltou a falar da barba. Um engenheiro limpou o histórico em plena transmissão, e a decisão sobre a aparência do personagem permaneceu no resumo separado, então, em essência, o assistente não perdeu nada.

O que anotar

Para os desenvolvedores, a lição é esta: a memória longa de um assistente não é um contexto grande, e sim disciplina. O diálogo bruto deve ser separado do extrato de decisões: o histórico pode ser limpo, o resumo permanece. É uma técnica barata e funcionou ao vivo.

Um pipeline feito de pedaços precisa de fila, e não da lógica de «pegar o último». Para o reconhecimento é preciso um dicionário de nomes e termos antes do início. Para vários falantes é preciso identificação contínua de falantes: a equipe pretende testar embeddings de voz e comparar o resultado com a marcação manual.

As limitações também são visíveis. É um piloto em um único evento, não há métricas de qualidade das respostas, parte do trabalho foi manual, e o modelo de vídeo nunca gerou a inscrição no dirigível: ela foi adicionada na edição. As respostas foram ao ar sem edição, por isso o infeliz momento da barba ficou na gravação aos 55:03.

Os planos: em novembro, voltar a eventos presenciais com fila e dicionário, conectar o assistente ao editor Workflow para poder dizer «Grom, refaça a cena da noite» e buscar recursos para rodar em dispositivos. Para isso são necessárias placas de vídeo e equipamento para testes, e a equipe conversa sobre isso com investidores. Para os product managers a conclusão é simples: o valor de uma interface de voz numa conversa em grupo não está em responder a uma pergunta, mas em conhecer o contexto de toda a reunião. É essa parte que vale construir primeiro.