STT, LLM e TTS: como funciona a arquitetura de um agente de voz

STT transforma fala em texto

STT (speech-to-text) converte fala em texto; ASR (automatic speech recognition) é outro nome para reconhecimento automático de fala. Compare o áudio com a transcrição antes de avaliar a resposta. Ruído, nomes e vocabulário do serviço podem mudar um identificador antes mesmo de o modelo decidir qual ferramenta usar.

No Tigy, o transcritor é gerenciado pela plataforma. O dicionário pode fornecer termos relevantes ao reconhecimento; teste nomes de produtos e abreviações nas conversas do seu atendimento.

O LLM usa instruções e contexto

O modelo de linguagem interpreta a pergunta com as instruções do agente e a informação disponível. Uma base de conhecimento fornece documentos; uma ferramenta configurada permite consultar dados ou executar uma ação.

Se a fala foi reconhecida corretamente, mas a resposta está errada, examine fontes, instruções e retorno das ferramentas. Um modelo não conhece automaticamente as regras atuais da sua empresa.

TTS transforma a resposta em áudio

A síntese de fala converte o texto da resposta em som. Ouça como a voz apresenta valores, datas e nomes. Uma frase clara no texto pode exigir uma formulação mais simples para ser compreendida ao telefone.

O Tigy oferece vozes selecionadas e gerencia a síntese. O dicionário de reconhecimento não é um controle fonético de pronúncia; não espere que alterar termos de STT modifique a voz.

Localize a falha antes de ajustar

Se o agente responde antes do fim da pergunta, examine os controles de turno. Se uma consulta demora, verifique a ferramenta e o destino. Se o áudio está difícil de entender, compare a resposta escrita com a gravação disponível.

Repita o mesmo cenário depois de alterar uma configuração. Separar as etapas dá uma hipótese verificável para cada mudança e ajuda a evitar ajustes que escondem a causa original.

Avalie o caminho inteiro da resposta

O tempo entre o fim da fala e o primeiro áudio inclui reconhecimento, decisão, rede, ferramentas e geração da resposta. Uma especificação de inferência rápida não representa necessariamente a espera experimentada pelo cliente.

Teste perguntas respondidas por conhecimento e perguntas que exigem consulta. Se apenas a segunda categoria demora, investigue a integração e a maneira como a conversa trata essa espera. Reduzir o texto da resposta pode melhorar a duração total sem alterar o tempo até o início.

Registre condições do teste: canal, local de conexão, modelo configurado e presença de ferramentas. Compare recortes semelhantes e observe os casos lentos, além da média. O objetivo é uma interação previsível, com perguntas que a pessoa consegue entender e respostas apoiadas por fontes.

Escolha componentes pelo atendimento que precisa realizar

Use vocabulário representativo para avaliar transcrição, pedidos ambíguos para avaliar interpretação e frases reais para avaliar pronúncia. Uma demonstração de frase curta não comprova desempenho com códigos, siglas e interrupções.

Altere uma configuração disponível por vez, como instrução, fonte, ferramenta, voz selecionada ou controle de turno, mantendo os demais cenários constantes. STT e LLM são gerenciados pelo Tigy AI; este procedimento não inclui escolher provedores externos.

No Tigy, confira as opções disponíveis na configuração e teste o agente completo. Não suponha que a mesma combinação terá resultado idêntico em todos os idiomas e canais. A avaliação precisa representar a operação e continuar após mudanças nas dependências.

Reconstrua a passagem entre fala, decisão e áudio

Para entender uma falha de voz, acompanhe a informação em cada etapa. O cliente fala, a transcrição representa a mensagem, o modelo decide como responder ou usar ferramentas, e a voz sintetiza o texto. Uma resposta errada pode começar antes da decisão ou surgir depois dela. Examinar só a última frase não revela essa origem.

Considere um exemplo fictício de código. A pessoa diz “quarenta e sete”, mas a transcrição registra “quarenta e seis”. O modelo pode consultar corretamente o valor que recebeu, embora a tarefa termine no registro errado. Nesse caso, a explicação está coerente com o dado de entrada e ainda assim o atendimento falhou. A correção precisa alcançar reconhecimento e confirmação.

Em outro caso, a transcrição registra o código correto, mas o modelo chama uma ferramenta de alteração em vez de consulta. A origem está na decisão, descrição de ferramenta ou instrução, não na qualidade da voz. Em um terceiro, texto e consulta estão corretos, mas o áudio pronuncia uma data de forma confusa. A revisão precisa avaliar a saída ouvida.

Esse rastreamento ajuda a evitar mudanças amplas sem causa. Mantenha fala esperada, transcrição observada, ação e texto de resposta em um registro de ensaio. Quando houver áudio, escute o trecho relevante. A evidência permite selecionar a etapa que realmente precisa de ajuste.

Entenda o que está disponível para configurar no Tigy

A documentação atual do Tigy descreve STT e LLM gerenciados pela plataforma. Usuários não escolhem um provedor externo ou um modelo dessas etapas. Para voz, a plataforma oferece um conjunto selecionado de vozes Tigy; não é possível adicionar um identificador externo ou trocar livremente o provedor de síntese. Essa informação muda a orientação prática do artigo.

Em vez de recomendar uma combinação de fornecedores ao usuário, investigue os controles realmente disponíveis. Instruções, fontes, ferramentas e configurações da conversa influenciam o atendimento. O dicionário do agente pode fornecer termos relevantes ao reconhecimento quando usados pelo transcritor. Ele não é um dicionário fonético que modifica a pronúncia da voz.

Não confunda conhecimento geral sobre arquitetura com uma opção da interface. Uma explicação pode apresentar STT, LLM e TTS como componentes conceituais e ainda orientar a operação pelas capacidades gerenciadas. O usuário precisa saber qual ajuste pode realizar e qual problema exige investigação da plataforma ou de uma integração.

Revise instruções antigas que pedem escolher modelos externos. A configuração atual deve guiar exemplos e procedimentos. Quando um controle não está disponível, não transforme uma recomendação abstrata em passo de implementação. Explique a camada e teste o comportamento que a equipe consegue observar.

Teste reconhecimento com vocabulário do atendimento

Palavras comuns de demonstração não representam todos os desafios do domínio. Se o agente atende uma loja, inclua produtos, bairros e siglas. Se atende uma recepção, inclua especialidades, sobrenomes e datas. O objetivo é observar onde a transcrição muda uma informação que afeta a decisão.

Use termos do dicionário com propósito. A documentação informa que a lista separada por vírgulas é enviada como termos de apoio ao reconhecimento. Compare ensaios antes e depois com as mesmas frases. Não conclua que o recurso corrige todo nome parecido, e não o use como promessa de pronúncia em TTS.

Confirme campos importantes pela conversa. Um reconhecimento correto em um exemplo não elimina a necessidade de conferir códigos, datas ou identificadores quando a tarefa exige precisão. A confirmação deve permitir que a pessoa identifique o erro e o corrija. Depois verifique qual valor chegou à ferramenta.

Inclua uma frase com pausa no meio. Uma resposta antecipada pode cortar o dado antes de a transcrição completar. Nesse caso, revise reconhecimento de término de turno nas configurações da conversa. Alterar a redação da resposta não resolve necessariamente o momento em que o sistema deixou de ouvir.

Avalie decisões pelo contrato da tarefa

Na etapa de decisão, procure correspondência entre intenção, fonte e ação. O agente deve responder perguntas gerais pela informação aprovada, consultar dados individuais por ferramenta autorizada e reconhecer ações fora do escopo. Linguagem fluente não comprova que essa seleção está correta.

Teste informação ausente e pressão por confirmação. O cliente pode pedir certeza de uma previsão ou insistir em uma operação não disponível. O modelo precisa preservar o limite. O sistema externo deve manter autorização própria, porque o prompt não substitui controle de acesso.

Para ferramentas, confira descrição e parâmetros. Uma ação com nome amplo pode ser escolhida indevidamente, e um campo mal explicado pode receber valor errado. A interpretação de retorno também precisa de teste: aceitação não é conclusão, previsão não é garantia e ausência de registro não é prova de inexistência de problema.

Quando houver falha, altere a instrução relacionada à causa e repita casos próximos. Não corrija uma confirmação indevida com recusa de todas as consultas. A qualidade da decisão depende de distinguir condições, não de responder sempre com segurança ou sempre com cautela.

Ouça a resposta como parte do resultado

O texto de resposta precisa funcionar quando ouvido. Uma frase longa com várias condições pode ser correta e difícil de acompanhar. Organize resultado, condição importante e próximo passo em partes curtas. Não remova moeda, unidade ou palavra de previsão apenas para acelerar a fala.

Compare vozes disponíveis com o vocabulário real. Ouça nomes, datas, códigos e explicações de espera. Uma amostra inicial agradável não mostra como a voz se comporta no atendimento completo. Peça a alguém para repetir o dado ouvido e confira se a confirmação foi compreensível.

A resposta também deve permitir interrupção conforme a configuração. O cliente pode corrigir uma data durante a fala. Revise se o agente para, entende e retoma com o valor novo. Não trate silêncio após interrupção como prova de atualização; confira a ação seguinte.

Ao final, reúna evidências das etapas. A tarefa está correta quando entrada, decisão, efeito e explicação correspondem à intenção e ao contrato aprovado. A divisão em componentes ajuda a corrigir a causa; a experiência precisa ser validada como uma conversa completa.

Use o mesmo caso para localizar a diferença

Prepare uma frase de ensaio com resultado conhecido e mantenha as condições ao comparar um ajuste. Se você muda vocabulário, canal e tarefa ao mesmo tempo, não consegue atribuir a diferença a uma camada. Use texto para verificar decisão e voz para verificar entrada e saída, preservando os dados de negócio.

Registre o efeito observado em vez de generalizar por uma execução. Um nome reconhecido corretamente é evidência daquele caso; outros nomes e ambientes continuam exigindo teste. A investigação fica mais útil quando descreve o limite e o próximo caso relevante.