Decidir ficou quase de graça. Escolher o ponto de corte, não

Entre setembro e outubro de 2026, três lançamentos apresentaram um tipo de modelo de IA que não escreve resposta nenhuma. Ele recebe um texto ou uma imagem, uma pergunta e uma lista de respostas possíveis, e devolve a probabilidade de cada uma. A TypeSafe AI lançou o Jev em 15 de setembro, o projeto Strands Agents publicou em código aberto o Decider 2B em 1º de outubro, e a OpenAI colocou em beta público a Decisions API, que, segundo a documentação, deve ficar disponível para todos nas próximas semanas. A leitura corrente é de preço e velocidade: decidir ficou muito mais barato. A premissa escondida está numa frase da documentação da OpenAI: quem escolhe a partir de que probabilidade agir é você. ^{[1] afirmação da fonte original[2] afirmação da fonte original[3] afirmação da fonte original}

O exemplo do projeto Strands mostra o formato. O texto de entrada é “Socorro! Meus pagamentos estão falhando há 3 dias!” (tradução nossa) e a pergunta é “qual equipe deve cuidar disso?”, com três opções: cobrança (billing), vendas (sales) e varejo (retail). A resposta vem como a probabilidade de cada uma: 0,845 para cobrança, 0,091 para varejo e 0,064 para vendas, mais um campo de confiança de 0,768. ^{[2] afirmação da fonte original} A documentação da OpenAI descreve três tipos de pergunta: a probabilidade de uma condição ser verdadeira (sim ou não), a escolha de uma opção entre várias, e uma nota contra uma escala (a gravidade de um problema, por exemplo). ^{[1] afirmação da fonte original}

Os números de fornecedor vêm com ressalvas que os próprios fornecedores fazem. A TypeSafe diz que o Jev responde em 70 a 500 milissegundos e que é 193,6 vezes mais rápido e 444,6 vezes mais barato que modelos de ponta nos quatro testes que a própria empresa montou, e escreve que esses múltiplos estão “no extremo superior dos ganhos do mundo real” (tradução nossa). Nesses testes, “acerto” significa concordar com a média das respostas de dois modelos de ponta, e o Jev fica em torno de 68%, no mesmo nível de dois modelos de texto bem mais caros. ^{[3] afirmação da fonte original} A Strands informa que o Decider 2B, com 2 bilhões de parâmetros, roda em computador comum e decide em cerca de 115 milissegundos, mediana medida numa placa de vídeo de uso doméstico. ^{[2] afirmação da fonte original}

Preço de entrada

US$ 0,10

Por milhão de tokens (pedaços de texto, em média menores que uma palavra) enviados ao modelo gpt-6-luna na Decisions API, sem cobrança pela resposta. Conta nossa: mil decisões de mil tokens cada somam um milhão de tokens, ou US$ 0,10. Não é o preço de nenhum produto da Invisible Work.

Velocidade declarada

10 vezes

Quanto a OpenAI diz que a Decisions API é mais rápida que a Responses API, a de texto livre. É afirmação do fornecedor, sem medição independente neste texto.

Uma resposta do exemplo

84,5%

A probabilidade que o Decider 2B atribui a “cobrança” no chamado dos pagamentos que falham. É a estimativa do modelo para aquele caso. Não é a taxa de acerto do modelo, e não diz quantos chamados parecidos de uma empresa de verdade ele acertaria.

A conversa pública gira em torno de preço, velocidade e concorrência. No Hacker News, na discussão da Decisions API (299 pontos em 6 de outubro), os comentários com mais respostas dizem que a OpenAI não tem fosso (vantagem difícil de copiar) e que o Jev fez da IA uma mercadoria, comparam latência em testes próprios e perguntam se a Anthropic fará o mesmo. ^{[4] afirmação da fonte original} Nos doze comentários com mais respostas que li, nenhum pergunta quem decide a partir de que probabilidade agir. Isso não prova que ninguém discute o assunto em outro lugar, só que não é o centro da conversa.

Mas as documentações dizem, com todas as letras, que a decisão não está no modelo. A da OpenAI, sobre a pergunta de sim ou não: a probabilidade serve “para sinalizar fotos para revisão com base em um ponto de corte que você escolhe”. Sobre as demais respostas: “use exemplos rotulados da sua aplicação para definir os pontos de corte de roteamento, filtragem ou revisão. Escolha os pontos de corte com base no custo de falsos positivos e falsos negativos” (tradução nossa). ^{[1] afirmação da fonte original} O texto da Strands fecha o mesmo círculo: no exemplo de um agente que chuta uma cidade para consultar o tempo, o modelo responde a duas perguntas de sim ou não, e “algumas linhas de Python transformam as previsões em uma decisão” (tradução nossa). ^{[2] afirmação da fonte original}

Em outras palavras, o modelo estima, e a decisão é uma linha de código que compara a estimativa com um número. Também não está no modelo a certeza da resposta: os modelos dessa classe, diz a Strands, “sempre produzem uma resposta entre as opções selecionadas” (tradução nossa), e a OpenAI recomenda incluir uma opção como “outro” quando a lista não cobre todos os casos. ^{[2] afirmação da fonte original[1] afirmação da fonte original} O “não sei” só existe se alguém o escrever na lista ou o derivar de uma faixa de probabilidade.

Há ainda um limite que o The Register lembra, segundo o resumo da NYU Shanghai: o formato nunca erra (a resposta sempre está na lista), mas isso é uma garantia de formato, não de correção. Uma resposta bem formada pode estar errada, e a probabilidade só vale o que a calibração vale. ^{[3] afirmação da fonte original} O resumo da NYU Shanghai diz que essa é a promessa que as equipes precisarão verificar com os próprios dados antes de confiar nas probabilidades em produção.

Comece pelo mais simples. Agir só vale se o custo esperado de agir for menor que o de não agir. Chame de a o custo de agir sem precisar e de b o custo de deixar de agir quando devia. Com uma probabilidade p de que a ação fosse necessária, agir custa (1 − p) × a em média e não agir custa p × b. Agir compensa quando p passa de a ÷ (a + b). A conta é da Invisible Work, e é a mesma que a literatura de aprendizado de máquina sensível a custo chama de decisão ótima: o ponto de corte sai da matriz de custos, e a probabilidade do modelo entra depois. ^{[6] afirmação da fonte original}

Dois exemplos hipotéticos, com valores inventados por nós. Num centro de distribuição, o modelo olha a foto do pacote e responde à pergunta “há dano visível?”. Segurar um pacote bom para reinspeção custa R$ 5 (a). Enviar um pacote danificado custa R$ 120 (b), com frete de volta, troca e atendimento. O ponto de corte é 5 ÷ 125, 4%: basta o modelo achar que há 4% de chance de dano para segurar o pacote. No segundo exemplo, a pergunta é “este reembolso é legítimo?”, e a ação é aprovar sem passar por uma pessoa. Aprovar um pedido indevido custa R$ 300 (a). Mandar um pedido legítimo para análise humana custa R$ 15 (b). O ponto de corte é 300 ÷ 315, 95%.

Segurar pacote

4%

Ponto de corte do primeiro exemplo: 5 ÷ (5 + 120). Valores hipotéticos nossos. Quer dizer: com 4% de chance de dano, já compensa segurar o pacote.

Aprovar reembolso sozinho

95%

Ponto de corte do segundo exemplo: 300 ÷ (300 + 15), arredondado. Valores hipotéticos nossos. Quer dizer: só compensa aprovar sem pessoa quando o modelo estiver quase certo de que o pedido é legítimo.

Perda por pacote

R$ 32,50

Se o ponto de corte do primeiro exemplo fosse 50% e um pacote tivesse 30% de chance de dano, ele seria enviado. O custo esperado de enviar é 0,30 × 120 = R$ 36,00 e o de segurar é 0,70 × 5 = R$ 3,50. Diferença: R$ 32,50 por pacote nessa situação. Conta nossa.

Com a mesma estimativa de 30%, as duas empresas deveriam fazer o oposto: segurar o pacote e não aprovar o reembolso sozinha. Nenhuma está errada. O que muda é o custo de cada erro, e esse número não está no modelo, nem no fornecedor, nem no código de exemplo.

A medicina tem a mesma estrutura. Em 1980, Stephen Pauker e Jerome Kassirer propuseram no New England Journal of Medicine a abordagem dos pontos de corte: a estimativa do médico de que o paciente tem uma doença é o fator principal para decidir entre não tratar, pedir mais exames ou tratar sem exame. Eles derivam dois pontos de corte, a partir da confiabilidade e do risco do exame e dos benefícios e riscos do tratamento. Abaixo do primeiro, não se trata. Acima do segundo, trata-se. Entre os dois, faz-se o exame. ^{[5] afirmação da fonte original} A terceira faixa é o ponto que a leitura corrente esquece: quando há dois pontos de corte, o meio é o trabalho humano.

1. 1

   Decidir passa a custar quase nada, e as perguntas se multiplicam

   Verificações caras demais para rodar em cada item (uma checagem em cada ação de um agente, uma nota para cada linha de uma base) passam a caber no orçamento, observa o resumo da NYU Shanghai. Cada uma dessas verificações exige um ponto de corte.

2. 2

   Cada pergunta e cada lista de opções vira uma política escrita

   O exemplo da própria OpenAI pergunta se o produto tem “dano visível, como rachadura, rasgo ou amassado”, mandando ignorar sombras e danos à embalagem. Antes, o que contava como dano ficava na cabeça de quem inspecionava. Agora está numa frase que alguém escreveu, e que pode ser lida, testada e cobrada.

3. 3

   O ponto de corte passa a decidir quanto erro a empresa aceita

   Com o mesmo modelo, um ponto de corte baixo segura mais pacotes bons e deixa passar menos danificados. Um alto faz o contrário. A escolha é uma decisão de negócio, só que tomada em uma linha de código.

4. 4

   A faixa do meio vira uma fila de pessoas

   Em 10 mil decisões por dia, se 6% caírem entre os dois pontos de corte, são 600 casos por dia para uma pessoa olhar (conta nossa, valores hipotéticos). Quanto mais estreita a faixa, mais erro automático. Quanto mais larga, mais gente. A capacidade humana de revisar entra na conta do erro aceito.

Se a decisão está no ponto de corte e não no modelo, três coisas mudam para quem responde por resultado. São hipóteses da Invisible Work, derivadas do raciocínio acima, e não resultados medidos.

1. 01

   O ponto de corte tende a ser escolhido por quem não conhece o custo do erro

   A frase da documentação (“escolha com base no custo de falsos positivos e falsos negativos”) pressupõe que alguém sabe esses custos. Quem escreve a linha de código raramente sabe quanto custa um cliente irritado ou um pacote devolvido. Hipótese: o valor que entra ali costuma ser o primeiro que funciona no teste, e nenhuma fonte deste texto mede isso.

2. 02

   A probabilidade que o fornecedor informa não é a da sua operação

   A calibração dos modelos de decisão é medida pelos próprios fornecedores em bases públicas ou em testes que eles montaram (o Decider 2B é medido na base pública de testes do Jev, a JevBench, e a TypeSafe escreveu os próprios testes). A mistura de casos da sua empresa é outra. Hipótese: um “90%” que acerta 9 em cada 10 no teste do fornecedor pode acertar bem menos nos seus chamados, nas suas fotos e nos seus contratos, e só os seus casos já resolvidos dizem quanto.

3. 03

   A capacidade de revisão humana decide o erro que você aceita

   Se o ponto de corte é escolhido para que a fila de revisão caiba no time, a empresa está escolhendo quanto erro automático tolera sem ter feito essa conta. Hipótese: a faixa do meio tende a ser dimensionada pelo número de pessoas disponíveis, e não pelo custo de errar.

O método abaixo é da Invisible Work e cabe numa conversa de uma hora com o dono do processo e a área que mede o erro, antes de ligar uma decisão automática ou de revisar uma que já roda.

1. 01

   Qual é a ação e quanto custa errar para cada lado?

   Escreva a ação (segurar, aprovar, escalar) e dê um valor em reais para agir sem precisar e para deixar de agir quando devia. Não precisa ser exato: a razão entre os dois já mostra se o ponto de corte deve estar perto de 5% ou de 95%.

2. 02

   Onde está o ponto de corte hoje e quem o escolheu?

   Procure o número no código ou na configuração. Se ninguém souber dizer, ou a resposta for “veio no exemplo”, a decisão está sendo tomada por padrão.

3. 03

   A probabilidade confere com os seus casos?

   Separe casos já resolvidos, com a resposta certa conhecida, rode o modelo neles e agrupe por faixa: dos que receberam entre 80% e 90%, quantos estavam de fato certos? É o que a documentação chama de exemplos rotulados, e é o mesmo raciocínio de um teste de avaliação (guia sobre evals). Se a faixa de 90% acerta bem menos que 90%, o ponto de corte precisa subir, ou o modelo, mudar.

4. 04

   O que acontece na faixa do meio e quem tem capacidade para isso?

   Defina dois pontos de corte em vez de um, diga quantos casos por dia cairão entre eles e quem os revisa. Se a conta não fecha, o problema é de capacidade, e esconder o problema com um ponto de corte mais folgado transfere o custo para o cliente ou para o caixa.

Os números de velocidade, preço e acerto do Jev são da TypeSafe, medidos em testes que a própria empresa montou, e chegam aqui pelo resumo de um serviço de pesquisa da NYU Shanghai, que informa ter sido redigido com apoio de IA e revisado pela equipe; o anúncio original da TypeSafe, as reportagens do The Register e da Every que o resumo cita não foram abertas. A documentação da OpenAI, o preço e o “10 vezes” são de uma parte interessada, e a Decisions API estava em beta no dia da leitura. O anúncio da Strands é de quem construiu o modelo. A discussão do Hacker News é uma amostra de doze comentários, não uma pesquisa. Não há aqui dado sobre empresas brasileiras, nem medição de como as empresas escolhem pontos de corte. Pauker e Kassirer foram lidos só pelo resumo. Os exemplos de pacote e de reembolso, os valores em reais e a faixa de 6% são hipotéticos. A fórmula do ponto de corte é elementar e a deduzimos nós, no mesmo espírito da literatura, mas vale apenas quando os custos de erro são conhecidos e constantes. As três consequências e o método de quatro perguntas são hipóteses da Invisible Work.

Seis perguntas para quem responde por resultado, por orçamento ou por operação.