system-one-design

Um passo faz a um modelo uma pergunta cuja resposta é um de poucos valores conhecidos — sim ou não, um de cinco rótulos, um nível de baixo a alto — e depois lê esse valor na prosa que ele escreveu. Ou a mesma pergunta é feita a centenas de itens. Isso é uma decisão tipada fantasiada de chat.

1. Faça-a como pergunta tipada (chimera decide, POST /api/decide ou a ferramenta decide): noul para sim/não, choice para um de um conjunto, score para níveis ordenados. Volta uma probabilidade.
2. Uma condição por pergunta. "É um erro e vem do banco de dados?" são duas perguntas; faça as duas e combine as respostas no código, onde a regra fica visível.
3. Dê às opções nomes que não carregam o veredito (nada de "yes", "safe", "pass") e ponha o significado nos critérios. Uma opção coringa ("other") não é confiável em nenhuma das duas direções — meça-a nos seus itens, dê a ela um critério estreito, ou troque-a por um noul por candidato quando rejeitar importa. Faça as primeiras palavras das opções diferirem: um modelo local lê o rótulo pelo primeiro token, então coding e coding_agent nunca se distinguem (24 dos 231 itens públicos do JevBench ficaram sem leitura assim). Sobre a opção coringa, medido em 1.000 assuntos de commit: um "other" amplo absorveu 78% dos itens que pertenciam a uma opção nomeada, e um estreito 58%; deixá-lo de fora elevou o F1 das classes nomeadas de 0,24 para 0,43, ao custo de os itens realmente fora do conjunto caírem numa opção nomeada. A opção coringa falha nos dois sentidos, conforme o modelo e a tarefa: aqui ela absorveu itens que não devia, enquanto um modelo de decisão hospedado escolheu "None/Other" em só 7% dos itens cuja resposta certa estava ausente (arXiv 2609.39496). Quando rejeitar importa, faça um noul por candidato (99% rejeitados lá) ou fixe um limiar na probabilidade da coringa a partir de exemplos rotulados (79% rejeitados, 97% dos itens respondíveis mantidos).
4. Mostre ao modelo só a coisa que está sendo julgada: não a saída de ferramenta em volta, não uma frase que defende uma resposta.
5. Escolha qualquer limiar a partir de exemplos rotulados, nunca de um palpite, e guarde o número ao lado da decisão que ele alimentou.
6. Deixe contas, datas e contagens no código: calcule o fato, coloque-o no estado e pergunte sobre ele. Um modelo de decisão lê; ele não calcula (no nível difícil do JevBench o modelo local acertou 1 de 15 itens de datas e números).

Uma resposta tipada parece mais certa que prosa, e não é: um modelo pequeno pode ordenar bem e ainda assim errar com confiança no meio da escala. Trate um número não calibrado como pista, registre-o e calibre com seus próprios rótulos antes que qualquer limiar signifique algo.