O número 0.70 decidiu que seu chatbot ia falhar

Imagine dois sistemas de IA idênticos. Mesmo modelo, mesma base de conhecimento, mesmo código. A única diferença entre eles é um número numa linha de configuração: 0.75 em um, 0.82 no outro. O primeiro atende bem. O segundo, diante das mesmas perguntas, ora inventa respostas, ora responde "não encontrei nada" para coisas que estão claramente na base. Mesmo sistema. Duas casas decimais de diferença. Dois destinos completamente distintos para o seu cliente.

Esse número tem nome: threshold de similaridade, o limiar de similaridade. É um dos parâmetros mais discretos e mais decisivos de qualquer sistema que busca informação por significado — e praticamente ninguém fora da engenharia sabe que ele existe. Vale entender o que ele faz, porque é ali que muitos projetos de IA silenciosamente fracassam.

De onde o número vem

Quando um sistema de IA busca informação por significado, ele não procura palavras — procura proximidade. Cada pergunta e cada trecho da base de conhecimento é convertido em um vetor, uma coordenada num espaço onde a distância representa semelhança de significado. Perguntar algo é lançar um ponto nesse espaço e olhar o que caiu por perto.

Mas "perto" é relativo. O sistema consegue medir, para cada trecho recuperado, um score de similaridade — geralmente um número entre 0 e 1, onde 1 seria um casamento perfeito e 0, nenhuma relação. A pergunta "quanto custa o plano anual?" pode retornar um trecho sobre preços com score 0.88, outro sobre formas de pagamento com 0.71, e um sobre política de cancelamento com 0.42. Todos foram encontrados. A questão é: quais deles o sistema deve confiar o suficiente para usar como base da resposta?

É exatamente para isso que existe o threshold. Ele é a linha de corte: "só considere trechos com score acima deste valor". Tudo acima entra na resposta. Tudo abaixo é descartado como ruído. Uma única régua, decidindo o que é sinal e o que é lixo.

O que acontece quando a régua está alta demais

Suponha que a equipe, querendo qualidade, coloque o threshold em 0.85 — só o que for muito, muito parecido passa. Parece prudente. Na prática, é a receita para o sistema virar um funcionário que responde "não sei" o tempo todo.

Porque a linguagem humana é bagunçada. O cliente raramente pergunta com as mesmas palavras que estão no documento. Ele pergunta "dá pra parcelar?" e o texto na base fala em "condições de pagamento em até 12x". Semanticamente próximos, mas talvez com score 0.79 — abaixo do corte. O trecho certo estava lá, foi encontrado, e foi descartado por um triz. O cliente recebe um "não encontrei essa informação" sobre algo que a empresa claramente oferece. A base estava correta. O threshold é que estava severo demais.

O que acontece quando a régua está baixa demais

O erro oposto é mais perigoso, porque não parece um erro. Baixe o threshold para 0.45 "para garantir que sempre ache alguma coisa", e o sistema passa a aceitar trechos vagamente relacionados como se fossem relevantes. Agora, quando o cliente pergunta sobre a garantia do produto A, o sistema recupera um trecho sobre a garantia do produto B — parecido o suficiente para passar na régua frouxa — e o modelo redige uma resposta confiante, fluente e errada.

Esse é o pior cenário possível: não o silêncio, mas a alucinação com aparência de competência. O cliente não recebe um "não sei" honesto; recebe uma informação incorreta entregue com total segurança. Ele age com base nela. E quando o erro aparece, já virou uma promessa quebrada, um pedido errado, uma reclamação. A régua baixa não faz o sistema falhar visivelmente — faz ele falhar de um jeito que ninguém percebe até ser tarde.

"O threshold de similaridade é uma escolha entre dois modos de errar. Alto demais, e o sistema fica mudo diante de perguntas que sabe responder. Baixo demais, e ele responde com confiança perguntas que não deveria. Calibrar esse número é escolher, deliberadamente, qual erro você tolera menos — e o ponto exato onde os dois se equilibram não está em nenhum manual."

Por que não existe um número mágico

A pergunta óbvia é: qual é o valor certo, então? E a resposta honesta — a que separa quem já fez isso de quem leu sobre isso — é que não existe um valor universal. O threshold ideal depende do modelo de embedding usado, da natureza da base de conhecimento, do estilo das perguntas que os clientes realmente fazem e do custo relativo dos dois tipos de erro no seu negócio específico.

Uma base jurídica, onde uma resposta errada é inaceitável, prefere errar para o lado do silêncio: threshold alto, e quando não tem certeza, escala para um humano. Um assistente de descoberta de produtos, onde sugerir algo aproximado é aceitável e até útil, tolera uma régua mais baixa. O mesmo número que é prudente num contexto é negligente no outro.

E o valor não se descobre no papel. Descobre-se observando: rodando perguntas reais, medindo onde o sistema acerta e onde erra, ajustando a régua, medindo de novo. É um trabalho empírico, iterativo e pouco glamoroso — o oposto de configurar uma vez e esquecer.

O parâmetro invisível que decide tudo

O que torna o threshold fascinante é a desproporção. É uma única casa decimal numa linha de configuração, invisível para o cliente, ausente de qualquer conversa comercial. E, no entanto, é ele quem decide, milhares de vezes por dia, se o seu cliente recebe a resposta certa, um silêncio frustrante ou uma mentira convincente.

Sistemas de IA não falham apenas nas grandes decisões de arquitetura. Falham — silenciosa e caramente — nesses parâmetros minúsculos que ninguém sabe que precisam ser calibrados. Saber que eles existem é o primeiro passo. Saber onde colocá-los, para cada negócio específico, é o que se aprende quebrando a cara em produção e consertando. É esse tipo de detalhe, invisível e decisivo, que faz a diferença entre uma IA que impressiona e uma que se pode confiar.