O limiar é do código; o modelo só dá uma probabilidade

Coloque algumas centenas de projetos reais lado a lado e o traço comum mais estável é este:

O modelo responde “quão provável”. Seu código responde “isso basta”.

Isso não é uma preferência de estilo. É a única conclusão segura a tirar do fato de que a confiança autorrelatada não pode ser confiada — e há medição independente por trás disso em É possível confiar nas probabilidades.

Como isso é na prática

Choice e Score retornam uma resposta com uma confidence anexada; Noul retorna uma probabilidade de 0 a 1 diretamente. A própria interface não faz nenhum julgamento por você — o limiar é seu. Em projetos reais, isso se transforma em algo bem específico:

Um filtro de palavrões rodando num Cloudflare Worker mantém seu limiar, sua política de agregação max() e seu schema OpenAPI público, tudo no próprio código do Worker. O modelo é apenas uma função que ele chama.
Uma extensão de navegador que oculta comentários mantém 0.85 / 0.7 / 0.5 fixos na extensão, e permanece oculta quando a verificação falha — essa preferência também faz parte da política de limiar.
Uma ferramenta de triagem de incidentes define “paginar alguém” como P(SEV1) + P(SEV2) ≥ 0.80, e esse 0.80 vive na própria configuração dela, não no modelo.

Os três compartilham uma propriedade: troque o modelo e o limiar não se move; reajuste o limiar e o modelo não se move. Entregue o limiar ao modelo e essas duas coisas viram uma — e aí “ajustar meu limiar” passa a significar editar um prompt.

Por que o princípio importa

Porque ele mantém dois tipos de falha separados:

O modelo respondeu mal — mude a pergunta, mude o estado, mude o modelo.
O limiar está mal definido — mude o número no código.

Misture os dois e “a precisão não está boa o suficiente” pode ser qualquer um deles, sem como dizer qual. A ferramenta de triagem pode colocar 0.80 direto na configuração precisamente porque esse número pode ser revisado por si só.

O contraexemplo que você precisa conhecer

O princípio se apoia numa suposição: que o número que você recebe é uma probabilidade calibrada.

Uma recomputação independente descobriu que a confidence retornada para perguntas Score é frequentemente apenas a parte fracionária do score, com essas saídas fortemente agrupadas (121 delas). Isso não é “o modelo está confiante” — parece um valor derivado do próprio score.

A diferença importa:

Se for uma probabilidade calibrada, 0.85 sustenta raciocínio como “vou acertar em cerca de 85% dos casos como este”.
Se for uma função do score, 0.85 significa apenas “este teve uma pontuação alta” e não diz nada sobre com que frequência acerta — e definir um limiar sobre ele significa definir uma barra para um número sem significado probabilístico.

Separadamente, um relatório de medição independente verificou os campos autorrelatados do modelo contra a verdade de referência e descobriu que os valores são muito menos granulares do que a descrição sugere (veja Críticas públicas).

O que fazer em vez disso

Três passos, e a ordem importa:

Use o limiar de forma operacional, não semântica. Se 0.8 significa “80% correto” é irrelevante. O que importa é se, nos seus dados, os casos acima de 0.8 são mensuravelmente mais precisos. Isso você consegue verificar contra um conjunto de validação.
Ajuste o limiar sobre os seus próprios rótulos. Existe ferramenta exatamente para isso: pegue seus dados rotulados, ajuste o limiar por pergunta que atinge a precisão desejada, valide num conjunto de validação — e falhe o CI quando uma atualização do modelo quebra um limiar travado.
Coloque o limiar no código e dê a ele uma data de revisão. Limiares expiram com as versões do modelo, como os preços. É algo que uma pessoa tem que olhar de novo, não algo que você define uma vez.

Em uma frase

A confiabilidade do modelo deveria aparecer no seu limiar, não no próprio número que ele relata. Você pode medir a primeira nos seus próprios dados; não pode medir a segunda.