# Limiar de confiança em assistentes de voz

> Published 2026-09-15T21:26:02.588Z on https://www.crazystack.com.br/pt/p/limiar-de-confianca-em-assistentes-de-voz/
> Source video: https://www.youtube.com/watch?v=Zd5b40Jbp_k

O limiar de confiança é o corte que decide quando o assistente de voz age, quando pergunta e quando fica quieto. Amit Desai, que já trabalhou na Alexa e na Roku, mostrou no AI Engineer que é possível reduzir o atrito sem perder acurácia: basta calibrar esse corte pelo custo de cada erro.

Em 2023, ele comparou limiares fixos com limiares ajustados por contexto e viu o usuário repetir menos o comando. Desde 2024, esse ajuste fino virou prática comum em assistentes que lidam com pagamentos e dados sensíveis.

## O limiar de confiança em assistentes de voz muda o custo do erro

O limiar de confiança em assistentes de voz é o corte que define quando o sistema age, quando confirma e quando para. Amit Desai, especialista em interface de voz com passagens por Alexa e Roku, defendeu no [AI Engineer](https://www.aiengineer.community/) que esse corte deve ser otimizado pelo custo do erro para o usuário, não só pela acurácia do modelo.

A palestra parte de um exemplo simples: um alto-falante inteligente que só toca música. Em 1.000 pedidos falados, 790 acertos e 210 erros. A acurácia é 79%, e o caminho tradicional é subir esse número, camada por camada. Desai chama isso de primeiro botão.

O segundo botão mantém a acurácia intacta e muda o que o sistema faz sob incerteza. Em vez de tocar sempre, ele pode parar e pedir repetição, ou confirmar a hipótese antes de executar. A pergunta deixa de ser "como acerto mais?" e passa a ser "como erro de forma mais barata?".

Essa distinção importa porque o custo do erro não é simétrico. Para o usuário, ouvir a música errada custa mais que ouvir "não entendi". O [material de referência do AI Engineer](https://www.aiengineer.community/) aponta a mesma lógica: comportamento sob incerteza é um eixo de projeto, não um detalhe de implementação.

## Como definir a acurácia sem esconder os erros

Para tratar acurácia como métrica, é preciso medir a mesma coisa em todos os casos. O método de Desai: pegar 1.000 pedidos falados, observar entrada e saída, rotular manualmente e contar acertos. O resultado do exemplo foi 79% de acerto, ou 790 pedidos com a música correta.

O número 79% não é um argumento publicitário nem uma meta. Ele é o ponto de partida para comparar sistemas diferentes sob o mesmo conjunto de pedidos. Sem essa base, qualquer discussão sobre limiar de confiança vira opinião.

Um sistema em cascata tem várias camadas onde o erro pode nascer: reconhecimento de palavra de ativação, transcrição automática, classificação de intenção, extração de entidade e detecção de atividade de voz. Cada uma pode contribuir para o erro final.

O erro de 21% não é homogêneo. Parte vem de pedidos ambíguos, parte de nomes próprios, parte de ruído. Separar os tipos de erro ajuda a decidir qual comportamento corrige cada um sem inflar a promessa de acurácia.

## O que muda quando o sistema aprende a parar

Adicionar a opção de parar já melhora a experiência do usuário sem qualquer ganho de acurácia. O sistema que antes tocava sempre passa a responder "não entendi" ou "pode repetir?" quando a confiança da hipótese fica abaixo de um limite t. É o segundo nível de sofisticação descrito na palestra.

O problema é escolher t. Desai mostra que o chute de 65% parece razoável e produz alguma melhora, mas não é o ponto ótimo. Otimizar sobre a distribuição de confiança dos 1.000 pedidos leva a 43%, com custo médio de 1,27 "ouch points" por turno, contra 1,9 do chute inicial.

O nome do modelo é Outcome User Cost Heuristic, ou OUCH. A sigla é uma brincadeira de quem trabalha com voz, mas o mecanismo é sério: cada desfecho tem um custo unitário, e o objetivo é minimizar a soma desses custos ao longo dos turnos.

A curva de custo tem um vale visível quando se plota o custo total em função de t. Um usuário que só olha o gráfico entende por que o chute de 65% é pior que o corte calculado. A diferença entre os dois é de cerca de 33% no custo médio por turno.

## Confirmar custa menos que agir errado

A confirmação é um terceiro comportamento e exige dois limiares, t1 e t2, que separam a operação em três faixas: parar, confirmar e agir. Na faixa intermediária, o sistema pergunta "você quis dizer Prince ou Chris Brown?" em vez de tocar direto.

Confirmar também tem custo. Ouvir a pergunta e responder "sim" demora cerca de 2 segundos, segundo a estimativa usada na palestra. Já ouvir uma pergunta errada e precisar reformular custa 6 segundos. São valores diferentes dentro do mesmo comportamento confirmatório.

Com dois limiares e três faixas, o custo médio cai para 1,46 "ouch points" por turno, contra 1,27 da versão que só para. O ganho existe, mas depende de a distribuição de confiança separar bem os casos corretos dos incorretos.

Se o custo do erro é mais alto, o desenho muda. Desai aponta que elevar o custo de agir errado para 20 segundos empurra os limiares e altera o ponto ótimo. Isso mostra que a calibração é sensível aos valores atribuídos a cada desfecho.

## Comparação entre os estágios de decisão

A tabela abaixo resume a evolução do exemplo. Os números vêm da palestra e servem para comparar estágios do mesmo experimento, não para prever resultados em outro produto.

| Estágio | Comportamentos | Custo por turno | Observação |
| --- | --- | --- | --- |
| Sistema inicial | agir | 2,10 | Toca sempre, certo ou errado |
| Parar com corte 65% | agir, parar | 1,90 | Chute intuitivo |
| Parar com corte 43% | agir, parar | 1,27 | Ponto ótimo da curva |
| Parar e confirmar | agir, confirmar, parar | 1,46 | Dois limiares, três faixas |

Três observações ajudam a ler a tabela. A primeira: a ordenação dos custos depende dos pesos atribuídos aos desfechos. A segunda: o mesmo conjunto de 1.000 pedidos alimenta todos os estágios. A terceira: a acurácia permanece 79% em todos eles.

O resultado de parar e confirmar ser maior que o de parar com t ótimo não invalida o comportamento. Significa apenas que, naquele conjunto de valores, a confirmação não compensou. Em outro contexto, como uma TV, a conta pode virar.

## O que muda em TV, dispositivos vestíveis e robôs

O mesmo princípio pode ser aplicado em qualquer superfície de voz, com valores e formatos diferentes. Em uma TV, o sistema pode exibir opções em vez de falar. Em um relógio, a restrição de tela muda o custo de confirmar. Em um robô, o custo de um ato errado cresce muito.

Quando o assistente age no mundo físico, a assimetria entre parar e agir errado fica extrema. Desai usa o exemplo do robô que joga um relógio no lixo. Errar a música é recuperável; errar uma ação física pode não ser.

Em uma TV, o canal favorito aparece na tela e a seleção pode ser feita com o controle remoto. Confirmar por voz custa mais que confirmar visualmente. Se trocar de canal interrompe o estado atual, o custo de um ato errado sobe. O limiar precisa refletir isso.

Por isso a palestra trata os valores como heurística. Não existe um conjunto universal de pesos. O que existe é um método para escolher o limiar de confiança em assistentes de voz com base no contexto de uso e no custo percebido pelo usuário.

## Onde esse desenho encosta em ferramentas de automação

Sistemas que executam ações em nome do usuário enfrentam a mesma pergunta. O [Zapier](https://zapier.com/), plataforma de automação entre aplicativos, precisa decidir quando uma etapa deve rodar sem intervenção. A diferença é que o custo do erro ali costuma ser reversível, o que muda os pesos.

A comparação serve para mostrar que o problema não é exclusivo de voz. Sempre que o sistema tem uma ação e uma confiança, existe um limiar. A decisão de usar esse limiar de forma explícita é o que separa um fluxo previsível de um fluxo surpreendente.

O mesmo vale para assistentes de código. O [Cursor](https://cursor.com/), editor de código com IA, precisa decidir quando aplicar uma alteração e quando pedir confirmação. O custo de uma edição errada é diferente do de uma música errada, e o limiar deveria acompanhar essa diferença.

## Informação adicional: como reconstruir o experimento

O experimento da palestra é reproduzível em um caso pequeno. Você precisa de três ingredientes: um conjunto rotulado de pedidos, uma pontuação de confiança por hipótese e uma tabela de custo por desfecho. Sem os três, qualquer limiar é chute.

O primeiro passo é coletar e anotar. Para cada pedido, registre o que o usuário disse, o que o sistema gerou e se o resultado foi correto. Uma amostra de algumas centenas já revela a forma das distribuições.

O segundo passo é atribuir custos. Meça quanto tempo, em segundos, o usuário leva para voltar ao objetivo depois de cada tipo de erro. Use os valores como heurística e revise quando tiver dados melhores.

O terceiro passo é varrer o limiar. Plote o custo total para cada valor de t e escolha o mínimo. Se um sistema em produção acompanhar a distribuição real, o limiar pode ser ajustado com dados em vez de intuição.

## Perguntas frequentes sobre limiar de confiança

- **O que é o limiar de confiança em um assistente de voz?** É o valor de corte aplicado à pontuação de confiança de uma hipótese. Abaixo dele, o sistema para ou confirma; acima, ele executa a ação. O limiar controla o comportamento sob incerteza, não a acurácia do modelo.

- **Por que não basta melhorar a acurácia do modelo?** Porque o custo dos erros não é simétrico. Ouvir a música errada custa mais ao usuário que ouvir uma pergunta de confirmação. Agir sempre no maior nível de confiança pode aumentar o atrito mesmo com acurácia alta.

- **Qual é a heurística OUCH?** É a Outcome User Cost Heuristic, que soma o custo de cada desfecho multiplicado pela frequência com que ele ocorre. O objetivo é minimizar esse custo total escolhendo os limiares de decisão. O nome é uma brincadeira com a dor do usuário.

- **Como escolher os valores de custo?** Estime quantos segundos o usuário precisa para voltar ao objetivo depois de cada erro. Use esses tempos como pesos relativos. Revise os valores quando tiver medições reais de uso.

- **O experimento da palestra usou quantos pedidos?** Foram 1.000 pedidos falados, com 790 acertos e 210 erros, o que dá 79% de acurácia. Esses mesmos dados alimentaram todos os estágios de decisão comparados.

- **Qual foi o melhor resultado no exemplo?** O limiar de 43% com comportamento de parar produziu 1,27 ouch points por turno. O chute de 65% produzia 1,90, e o sistema que agia sempre ficava em 2,10.

- **Adicionar confirmação sempre melhora o resultado?** Não necessariamente. No exemplo, parar e confirmar ficou em 1,46, acima do 1,27 de parar com o limiar ótimo. O ganho depende dos pesos atribuídos a cada desfecho.

- **O mesmo limiar funciona em qualquer dispositivo?** Não. TV, relógio e robô têm custos diferentes para parar, confirmar e errar. A TV pode mostrar opções na tela, o robô pode causar dano físico. O método é o mesmo, os valores não.

- **Esse método já é padrão na indústria?** A palestra apresenta a abordagem como uma área promissora, não como padrão consolidado. Os números vêm de um exemplo didático com um alto-falante inteligente hipotético, não de um estudo independente em produção.

## Do vídeo ao artigo com o Skala Blog

A ideia central da palestra é simples: medir o custo do erro antes de decidir o que fazer. Quem produz conteúdo técnico enfrenta um problema parecido. Existe muito conhecimento gravado em vídeo, mas ele não circula bem em texto, e parte do valor fica presa na fala.

Se você tem aulas, entrevistas ou explicações sobre arquitetura de voz e comportamento sob incerteza, esse material pode virar artigo. O [Skala Blog](https://skalablog.com) recebe o link do vídeo, transcreve o conteúdo e gera um artigo para revisão.

[Source video](https://www.youtube.com/watch?v=Zd5b40Jbp_k)