When the right model writes nothing at all

O reflexo da indústria, desde que os modelos de linguagem ficaram bons, é usar um para tudo. Classificar um pedido, decidir para onde encaminhar um atendimento, julgar se dois registros falam da mesma coisa, medir o risco de uma conta: tudo virou prompt, e a resposta volta como texto que alguém precisa interpretar de novo antes de usar.

Funciona. Mas quando a gente olhou com calma para o que a plataforma realmente faz o dia inteiro, uma parte grande não era escrita. Era julgamento fechado, com resposta dentro de um conjunto conhecido, cujo destino não eram os olhos de ninguém e sim a próxima linha de código.

Gerar e decidir são trabalhos diferentes

A pergunta que passamos a fazer em cada chamada de modelo é simples: o que volta daqui vai para uma pessoa ler ou vai para um if?

Quando vai para uma pessoa ler, o modelo de linguagem é insubstituível. Escrever o resumo de uma reunião, redigir a passagem de bastão entre pré-vendas e vendas, propor o email de retomada. Isso é redação, e redação exige um modelo que redija.

Quando vai para um if, o cenário é outro. Ali o texto é embalagem: o sistema quer a decisão, não a prosa em volta dela. E pedir a decisão a um modelo de linguagem tem um custo que não é óbvio. Ele raciocina antes de responder, e esse raciocínio é cobrado como saída, que é a parte cara da conta. A gente estava pagando preço de redação por respostas que cabiam em uma palavra.

O que um modelo de decisão devolve

Modelos de decisão, às vezes chamados de System One por analogia com o pensamento rápido, atacam exatamente esse recorte. A Flunora adotou o Jev, da TypeSafe, ao lado dos modelos de linguagem que já operavam na plataforma.

A mecânica é diferente da de um chat. Em vez de um prompt aberto, a chamada leva um estado e um conjunto de perguntas tipadas. Cada pergunta declara a forma da resposta antes de existir resposta: escolher uma opção entre as que foram listadas, situar algo numa régua de níveis descritos, ou estimar se uma afirmação é verdadeira. O que volta não é texto pedindo para ser interpretado, é o valor já na forma que o código espera, acompanhado da probabilidade de cada saída possível.

Três consequências práticas. A resposta chega em uma fração do tempo de uma geração completa, o que importa quando a decisão está no caminho de algo que alguém está esperando na tela. Não há saída malformada para tratar, porque a forma é parte da pergunta. E como o modelo não gera texto, não há token de saída para cobrar.

A confiança virou um portão

A parte que mais mudou o produto não foi o custo. Foi a probabilidade.

Um modelo de linguagem responde com a mesma firmeza quando sabe e quando está preenchendo lacuna. Um modelo de decisão calibrado devolve, junto da resposta, o quanto a distribuição está concentrada nela. Uma resposta com 0,97 e uma com 0,41 podem ser a mesma palavra, e são coisas completamente diferentes para quem vai agir em cima delas.

Isso se encaixou com uma decisão de produto que já era nossa: o que a inteligência da plataforma faz sozinha tem que ser reversível e ficar à vista, e o que tem consequência vira proposta para uma pessoa decidir. A confiança transformou essa regra, que era uma escolha de design, numa medida. Acima de uma régua, a plataforma resolve sozinha e deixa o registro visível com a evidência ao lado. Abaixo dela, a mesma conclusão vira sugestão, ou simplesmente não acontece. A régua sobe conforme a consequência: ação que mexe na ficha de um cliente exige muito mais certeza do que ação que só organiza uma fila.

O prompt que funciona num LLM não funciona aqui

Essa foi a lição mais cara e a mais útil da adoção, e vale para quem for pelo mesmo caminho.

A primeira tentativa foi óbvia e errada: pegamos um julgamento que já rodava num modelo de linguagem e copiamos o mesmo texto para o modelo de decisão. O resultado foi medíocre, com concordância baixa e certeza baixa quase em toda parte. A conclusão fácil seria que o modelo não dava conta do português, ou da tarefa.

Não era isso. Prompt escrito para modelo de linguagem conta com um leitor que preenche lacuna sozinho, entende o espírito da instrução e perdoa a categoria vaga. Um modelo de decisão lê ao pé da letra: ele responde exatamente a pergunta escrita, não a pretendida. Reescrevemos os critérios descrevendo situações concretas em vez de graus de intensidade, e declaramos por extenso o caso de fronteira que confundia os dois lados. Mesmo modelo, mesma tarefa, mesmos dados. A concordância foi para o topo e a certeza subiu junto.

A diferença entre os dois resultados não estava no modelo. Estava em nós.

O que o código decide antes de perguntar

Um modelo de decisão é bom em julgamento e ruim em aritmética, comparação de datas e contagem. A documentação do fornecedor diz isso com todas as letras, o que já é um bom sinal sobre a seriedade de quem publica.

Em vez de tratar isso como limitação, tratamos como divisão de trabalho. Tudo o que é regra determinística acontece antes da pergunta e define quais opções sequer existem: ordem cronológica, procedência, permissão de quem está perguntando, restrições do processo. O modelo recebe um conjunto em que toda resposta possível já é uma resposta legítima, e só lhe cabe a parte que exige julgamento semântico.

O ganho aqui é mais qualidade do que economia. Uma regra aplicada depois da resposta descarta trabalho já pago. A mesma regra aplicada antes torna o erro impossível de acontecer.

Sombra antes de troca

Nada disso entrou em produção porque pareceu melhor em uma planilha.

Cada julgamento que consideramos mover roda primeiro em modo sombra: o modelo de decisão responde em paralelo com o caminho que já existe, a resposta dele é gravada e deliberadamente não é usada. Ninguém que opera a plataforma percebe diferença. O que se acumula é a comparação entre os dois, decisão a decisão, com a certeza reportada ao lado de cada uma.

Só depois disso a troca vira uma conversa sobre dados em vez de uma aposta. E há uma honestidade necessária aqui, que preferimos escrever do que esconder: concordância entre dois caminhos não é acerto. Se o caminho antigo erra, o novo pode estar concordando com o erro. Por isso o que se compara não é só uma coisa com a outra, e sim as duas com o veredito de quem conhece a operação, registrado na própria interface, na hora em que a pessoa revisa o que a plataforma concluiu.

O que sobra para quem usa

Nada disso aparece na tela, e de novo essa é a intenção. O que se vê é uma fila que já chega classificada, um contexto que se atualiza sem ninguém alimentar planilha, uma pendência que some quando a conversa prova que ela foi resolvida, e a evidência ao lado em todos os casos.

O que existe por baixo é uma escolha de arquitetura que a gente sustenta: usar o modelo certo para cada natureza de trabalho, deixar o julgamento fechado com quem devolve probabilidade calibrada, deixar a redação com quem redige, e manter a regra determinística no código, onde ela pertence. Modelo de fronteira qualquer um liga. O que decide o resultado é onde cada um deles é usado, e o que o sistema exige de certeza antes de agir.

A Flunora está em acesso por solicitação. Se a sua operação deveria rodar sobre contexto e evidência, solicite acesso.