Veja o vídeo!

Você manda um ticket para algum serviço que assina: "me cobraram duas vezes esse mês, quero resolver isso hoje!"

O sistema de atendimento, que usa IA, respira fundo e começa:

"Claro! Analisando o sentimento do cliente, considerando o histórico de cobrança duplicada, eu acho que talvez seja um caso de blá blá blá e dá para resolver com blé blé blé ..."

Um monte de parágrafos e enquanto isso o ticket ainda está parado, talvez até na fila errada.

Aqui você vai conhecer uma IA que não escreve, não resume, não conversa, ela só decide! É isso aí, sem papo furado! Curta e grossa. Chama Jev.

Semana passada pessoal só falava nisso (até aparecer o DHH criando caso de novo). E tem gente já falando que o negócio já tá caducando (o Jev, não o DHH), menos de 1 semana depois! De qualquer forma, compensa entender os conceitos. A ferramenta pode até passar, mas os conceitos ficam.

Vamos conhecer a história, os três tipos que a ferramenta usa, e vamos ver um exemplo em Ruby com a RubyLLM (na versão atual 2.0.0, ainda sem os Judgments que virão na versão 2.1, não disponível ainda) que eu já uso e você pode usar facilmente. Mas mesmo se você não programa em Ruby, fique aí que vai entender o conceito todo da coisa e vai ver como é fácil usar isso em Ruby, com poucas linhas.

História e conceitos

Setembro de 2026. Diogo Almeida, o mesmo que trabalhou no RLHF do InstructGPT na OpenAI, sai do modo stealth ali com o anúncio da TypeSafe. Mas que diabos é InstructGPT e RLHF?

InstructGPT

O InstructGPT é do paper da OpenAI de 2022. O modelo pré-treinado só completa frase. Eles fizeram três voltas: primeiro o modelo imita resposta boa escrita por humano; depois humanos ranqueiam várias respostas e um segundo modelo aprende a dar nota; no fim um RL (algoritmo de reinforcement learning) empurra o LM (language model) pra nota alta. O nome disso é RLHF: Reinforcement Learning from Human Feedback.

O alvo da recompensa é texto que o avaliador gostou de ler, não probabilidade que fecha com o fato. Por isso um InstructGPT pequeno ganhou de um GPT-3 enorme em "obedece o pedido" e por isso a TypeSafe fala em RLCD (Reinforcement Learning for Calibrated Decisions): mesma família, recompensa na decisão calibrada, não no parágrafo.

Mas voltando ao Diogo Almeida. A pergunta dele: os modelos já são bons de conversa faz anos. A pergunta foi: cadê a automação? A resposta não foi “mais um chat”. Foi um modelo que entrega escolha tipada. Estado entra. Decisão sai.

Bem importante notar que o Jev não é ChatGPT barato. É outra forma de saída.

Você manda duas coisas:

1. O estado — o ticket, o JSON, o log, o e-mail.
2. As perguntas — com tipo fechado.

Ele devolve valor que o seu if entende. Sem regex no parágrafo. Sem “extraia o JSON, por favor”.

Tem 3 primitivas:

• Noul: “Isso é urgente?” Volta um Float de 0 a 1. Probabilidade de sim. Não tem campo confidence. Perto de 0.5 não é “médio”. É “sim e não empatados”.
• Choice: "Qual fila?” Você lista as opções. Volta a chave vencedora, um hash de probabilidades e um confidence. Ele não pode inventar uma quarta fila se você enviar 3.
• Score: "Quão puto está o cliente?" Você descreve níveis ordenados: calmo, frustrado, muito bravo. Volta um Float que pode cair entre os degraus, mais a legenda e a distribuição.

Em Ruby: Noul é Float. Choice é String/Symbol de um conjunto fechado. Score é Float sobre um Array.

Isso é chamado de Sistema 1, não é Sistema 2.

Sistema 1, Sistemas 2 e Kahneman

Daniel Kahneman

Daniel Kahneman foi um psicólogo israelense-americano, autor do livro "Rápido e Devagar: Duas formas de pensar", "só" prêmio Nobel de Economia em 2002, embora não fosse economista. Com Amos Tversky, mostrou que a gente não decide como a conta manda: usa atalho, e o atalho erra de jeito previsível.

O livro Rápido e Devagar: Duas formas de pensar (2011, Thinking, Fast and Slow) é o mapa disso. Sistema 1 é rápido, automático, o palpite. Sistema 2 é
lento, deliberado, o que você acha que está no comando. A TypeSafe pegou o 1 como nome da classe. Mas o nome do modelo, Jev, não é o Kahneman!

Ou seja:

• Sistema 1: rápido, automático, o palpite.
• Sistema 2: lento, deliberado, o raciocínio.

Uma LLM de fronteira é Sistema 2. Gera token, explica, demora segundos, minutos, horas. Custa o parágrafo inteiro e mais alguma coisa.

A TypeSafe batizou a classe de System One. A aposta: software quase nunca precisa de um ensaio pra mandar o ticket pra o setor correto. Precisa de uma escolha. Eles avisam o paralelo incômodo: no Kahneman o Sistema 1 também erra por atalho. A tese deles é calibrar o palpite, RLCD, "Reinforcement Learning for Calibrated Decisions", em vez de premiar texto que o humano gostou de ler.

Mas o nome Jev não é o Kahneman, veio do William Stanley Jevons.

William Stanley Jevons

William Stanley Jevons foi um economista e lógico inglês, nascido em 1835 e um
dos pais da teoria marginalista. A obra que interessa aqui é "The Coal Question" (1865), onde aparece o paradoxo de Jevons: quando o recurso fica mais barato, o uso explode.

Ele também escreveu "The Theory of Political Economy" em 1871 e "The Principles of Science" em 1874. A TypeSafe batizou o modelo por esse paradoxo: decisão a centavos, o código passa a perguntar mil vezes. E o Jevons foi devidamente homenageado na era da IA.

Aí você vê. Decisão a 4 centavos de dólar por milhão de tokens de entrada, a saída é grátis, não cobram igual os tokens de output. A ideia é o código passar
a perguntar mil vezes, não uma.

Exemplo em Ruby

Quem já usa RubyLLM 2 não troca de stack. Entra a gem comunitária ruby_llm-typesafe. Não é oficial da TypeSafe. Ruby 3.1+, RubyLLM >=
2.0.0.rc3. Se você está lendo isso e a versão 2.1 da RubyLLM já saiu, ela tem suporte para Judgments, que vai deixar o que está sendo demonstrado aqui de forma mais fácil, mas ainda assim vale esse exemplo para ver como são as internas de tudo que vimos até aqui.

Você tem que configurar a chave TYPESAFE_API_KEY no ambiente. A minha já está carregada aqui. Dá para criar ela no site da TypeSafe. Lógico que você vai ter que pagar ...

Aqui o código:

require "json"
require "ruby_llm"
require "ruby_llm-typesafe"

RubyLLM.configure do |config|
  config.typesafe_api_key = ENV["TYPESAFE_API_KEY"]
end

schema = RubyLLM::Providers::TypeSafe::Schema.new do |s|
  s.noul :is_urgent, instructions: "Isso é urgente?"
  s.choice :department,
           instructions: "Que departamento deve ser acionado?",
           criteria: {
             billing: "Pagamentos, faturas, estornos",
             technical: "Bugs, falhas, integrações",
             sales: "Preços, leads, novos cadastros"
           }
  s.score :frustration,
          instructions: "O cliente está bravo?",
          criteria: ["Calmo", "Frustrado", "MUITO PUTO"]
end

msg =<<~FIM
Pedi para o sistema de áudio do carro tocar "Circle of the Tyrants" e ficou
tocando "Circo do Pipoca", pelamor, vocês tem que deixar esse negócio mais
certeiro! Está horrível de tanto errar! Preciso do sistema mais inteligente
ainda hoje, para usar em uma viagem longa.
FIM

response = RubyLLM.chat(model: "jev-latest", provider: :typesafe)
                  .with_schema(schema)
                  .ask(msg)

answers = response.parsed
puts JSON.pretty_generate(answers)

Dando uma olhada no código ali acima. O ask é o estado. Sem schema, sem stream, sem tool. O Jev não escreve. A gem não finge que escreve.

Vamos rodar o bicho, e o resultado é algo como:

{
    "is_urgent" => {"type" => "noul", "noul" => 0.76},
    "department" =>
    {
        "type" => "choice",
        "choice" => "technical",
        "confidence" => 1.0,
        "probabilities" => {"sales" => 0.0, "billing" => 0.0, "technical" => 1.0}
    },
    "frustration" => {
        "type" => "score",
        "score" => 1.85,
        "confidence" => 0.77,
        "legend" => {
            "0" => "Calmo",
            "1" => "Frustrado",
            "2" => "MUITO PUTO"
        },
        "probabilities" => {
            "0" => 0.0,
            "1" => 0.15,
            "2" => 0.85
        }
    }
}

Ali em probabilities é o que o modelo pensa. confidence é o quão concentrada está a opinião, ali ele está bem certo que é a resposta correta. O limite
fica no seu código. Avalia com os dados no seu código antes de automatizar a fila.

Contraste: rápido não é determinístico

Aqui é o ponto que o marketing não coloca no slide.

Sistema 1, no Kahneman, é rápido e viesado. A TypeSafe diz que treinou pra calibrar o palpite. Ok, mas calibrado ainda é palpite.

Quando fazemos uma somatória em um banco SQL, tipo um SUM(pedidos.total), ele não tem confidence. Ou a soma está certa, ou o código está errado. Você confia porque o modelo mental é determinístico: mesma tabela, mesma conta, mesmos números, mesma massa de dados. Lembrando que não dá para confiar em operações aritméticas em modelos probabilísticos baseadas mesmo em tabelas de dados retornados para eles. Acreditem, eu vi, irmãos e irmãs.

O Jev não é isso. department = technical com 1.00 quer dizer: neste estado, nesta pergunta, o modelo inclinaria assim. Amanhã o peso muda. O ticket
vizinho, quase igual, pode ir pra billing. Não tem invariante. Não tem replay bit a bit.

Se o Sistema 1 for rápido e impreciso, você não ganhou automação. Ganhou um if que erra barato e rápido. Pior: erra com cara de tipo, fica chique. O String "technical" entra no case e o código segue como se alguém tivesse aprovado a fila.

Por isso o limite não é detalhe. É a única cerca.

• confidence baixo: manda para humano.
• Noul perto de 0.5: não é “mais ou menos urgente”. É empate. Empate não roteia sozinho.
• Choice com massa espalhada no hash não é decisão. É dúvida tipada.

O schema fecha alucinação de campo. Não fecha alucinação de juízo. Você ainda precisa medir no seu ticket real: quantos tickets o Jev mandou pra
technical? Sem essa conta, “calibrado” é papo de vendedor.

Usa onde o erro é barato e reversível. Não usa onde a soma da tabela ou algum resultado determinístico já resolve.

Conclusão

O Jev não substitui LLM. LLM escreve. Jev escolhe. Nenhum dos dois substitui determinístico.

Se o seu job é um case disfarçado de prompt, você estava pagando, talvez bastante, um Sistema 2 pra fazer Sistema 1. Se o job é um número que a tabela já tem, você nem deveria ter modelo no meio, tá fazendo o que? A firma tá te forçando usar IA mesmo quando não precisa? Tem muita aí fazendo isso. E se for eses o caso, o Aaron Patterson, o Tenderlove, deu uma idéia muito boa: vou começar a vender seguro para débito técnico, entra em contato se interessar.

E para pensar:

• Você deixaria o Jev rotear ticket sozinho, ou só com confidence alto?
• Com Noul perto de 0.5: trata como não, ou manda pra humano?
• Qual decisão do seu sistema nunca deveria sair de um palpite, por mais calibrado que ele seja?