Um agente que responde “acho que é seguro fazer o deploy, pois os testes passaram” está resolvendo o problema certo com a abstração errada. A pergunta tinha três respostas possíveis — deploy, hold, escalate — e mesmo assim pedimos a um modelo que escrevesse uma frase, para depois outro componente tentar descobrir o que a frase quis dizer.

Na última semana, a TypeSafe AI lançou um modelo que parte exatamente dessa crítica. Vale olhar com atenção, mas não pelo motivo que o marketing sugere.

O que foi lançado

Em 15 de setembro, a TypeSafe saiu do modo stealth e apresentou o Jev, o primeiro do que chama de System One Models: modelos que recebem estado não estruturado e devolvem decisões tipadas com probabilidades, em vez de texto. O fundador, Diogo Almeida, trabalhou na OpenAI na linha de pesquisa que levou a RLHF e ao ChatGPT.

Os traços principais, segundo a documentação e o post de lançamento:

  • Três primitivas: choice (escolher entre opções), score (nota em níveis ordenados) e noul (probabilidade de uma proposição ser verdadeira).
  • Saída sempre dentro do schema. O modelo não gera strings; as respostas possíveis são definidas antes da chamada.
  • Todas as perguntas sobre o mesmo estado em uma passada paralela, com latência declarada entre 70 e 500 ms.
  • Treino por RLCD (Reinforcement Learning for Calibrated Decisions), cujo objetivo é que a probabilidade reportada corresponda à frequência real de acerto.
  • Preço: US$ 0,042 por milhão de tokens de entrada; saída gratuita.
  • Só texto por enquanto: strings, JSON e arrays. Nada de imagem ou áudio.

O nome da categoria vem do Sistema 1 de Kahneman. O nome do modelo vem de William Stanley Jevons — o do paradoxo em que eficiência maior aumenta o consumo total. Guarde esse detalhe; ele volta no final.

A ideia que importa

A contribuição mais interessante do Jev não é o modelo. É a fronteira que ele força no desenho do sistema.

Em boa parte dos agentes que vejo, geração, decisão e execução estão empilhadas no mesmo prompt. O LLM investiga, planeja, escolhe a ferramenta, decide se é seguro e ainda escreve a justificativa. Quando algo dá errado, não há uma unidade observável para culpar: há um parágrafo.

A proposta é separar três papéis:

Contexto e objetivo
        │
        ├── LLM generativo: investigar, planejar, propor opções
        ▼
Alternativas fechadas + política + evidências
        │
        ├── Modelo de decisão: escolher / pontuar / rejeitar
        ▼
Executor determinístico: aplica política, age e registra

A unidade de controle deixa de ser texto livre e passa a ser uma ação enumerada. Isso muda o que dá para fazer com o sistema: impor política antes da ferramenta agir, logar opções, probabilidades, limiar e decisão, e medir coisas como acerto de roteamento, falsa aprovação e custo por ação. Decisão vira interface — e interface se testa.

Nada disso exige o Jev. Um LLM com saída estruturada, um classificador fine-tuned ou regras bem escritas ocupam o mesmo lugar. O Jev só torna esse lugar barato o suficiente para ser usado em todo ponto de decisão, não apenas nos críticos.

O que a primeira semana mostrou

O ecossistema reagiu rápido, e os projetos são mais instrutivos que o anúncio porque mostram onde a interface cabe:

  • Roteamento entre modelos. Um demo descartável encaminha tarefas de código entre Grok Build e Codex Astra. A LangChain publicou middlewares oficiais: ModelRouterMiddleware, que escolhe o modelo por critérios declarados, e AutoModeMiddleware, que avalia chamadas de ferramenta arriscadas e as bloqueia antes da execução.
  • Segurança como classificação contextual. O is-malicious envia código, configuração, build e CI ao Jev em busca de comportamento enganoso ou exfiltrador, com os limiares de severidade no próprio código. O README é honesto: arquivos pulados não aparecem na análise, a ferramenta não isola a execução e um relatório limpo não prova segurança.
  • Mascaramento de PII sensível ao conteúdo. O pg-redact usa o Jev na ingestão para rotular trechos de texto (nome, email, telefone…) e guarda esses trechos como JSONB ao lado da mensagem. O Postgres então aplica a máscara por papel via uma função redact(). O detalhe arquitetural é bom: o modelo classifica uma vez; o banco aplica a política de forma determinística a cada leitura.
  • Agentes com ação delimitada. O S1Code deixa planejamento e escrita com o modelo generativo e usa o Jev, opcionalmente, para decidir quais evidências permanecem no contexto ativo. O próprio projeto avisa que não faz afirmações de desempenho.
  • Reproduções abertas. O jevlike reconstrói a interface — contexto mais lista de opções, uma probabilidade por opção — com um scorer pequeno sobre um encoder. A família Laya, da Convai, faz o mesmo sobre ModernBERT e publica checkpoints abertos.

O padrão comum não é “todos implementam o Jev”. É que todos tratam decisão como saída nativa, e deixam limiar, política e efeito colateral no código.

Lendo os números com cuidado

A TypeSafe merece crédito: o post de lançamento traz ressalvas que muito anúncio não traz. Justamente por isso, vale lê-las.

“Não alucina” significa “não sai do schema”. A garantia é que a resposta pertence ao conjunto de valores permitidos. Isso elimina erro de tipo e parsing, e é valioso. Não elimina a decisão errada dentro do conjunto. Um deploy confiante e incorreto é perfeitamente type-safe.

A referência de acerto é outro modelo. As avaliações de workflow usam como gabarito a média das previsões de GPT-6 Astra e Fable 5.1, não rótulos humanos. O que se mede, portanto, é concordância com modelos de fronteira — e a própria empresa reconhece o viés. A análise da DataCamp resume o resultado em cerca de 68% nesse benchmark, perto de modelos intermediários, com custo e latência muito menores.

Os workflows foram escritos pelo time. Não estavam no treino, segundo a empresa, mas foram criados por quem trabalha no modelo. E os ganhos de 193x em velocidade e 444x em custo são descritos por ela mesma como o topo do que se deve esperar.

Velocidade e preço têm asterisco. As medições de latência foram feitas a partir de laptops na Costa Oeste americana, onde o serviço roda. Sobre o preço, a TypeSafe admite que não tem como provar que não é subsidiado.

Nada disso invalida o produto. Invalida tratar os números de lançamento como números de produção.

Calibração é o produto

Se o modelo devolve probabilidades, o valor está em elas significarem alguma coisa: das decisões que saem com 0,9, cerca de 90% devem estar certas, na distribuição que você tem em produção. Sem isso, a probabilidade é só um número decorativo ao lado da resposta.

As reproduções abertas mostram que isso não vem de graça. O model card do Laya é exemplarmente franco: o checkpoint que supera o Jev no benchmark foi fine-tuned no split de treino do próprio benchmark; em zero-shot, a acurácia fica abaixo de simplesmente escolher a classe majoritária; e o erro de calibração cai de 0,466 para 0,081 só depois de reajustar uma temperatura por tipo de pergunta. No jevlike, a comunidade encontrou em dias um vazamento no controle experimental e um carregamento inseguro de checkpoints.

Isso não é crítica aos autores — é o processo funcionando. Mas deixa claro que “escolher rápido” é a parte fácil. “Saber quando não confiar na escolha” é o trabalho.

O que eu levaria para um projeto

Com ou sem Jev, a camada de decisão tem um contrato que dá para escrever antes de escolher o modelo:

from enum import StrEnum

from pydantic import BaseModel, Field


class DeployAction(StrEnum):
    DEPLOY = "deploy"
    HOLD = "hold"
    ESCALATE = "escalate"


class DecisionRecord(BaseModel):
    """Registro auditável de uma decisão tipada.

    Guarda o suficiente para reproduzir o porquê da ação,
    não só a ação.
    """

    decision_id: str
    model_version: str
    options: list[DeployAction]
    probabilities: dict[DeployAction, float]
    confidence: float = Field(ge=0.0, le=1.0)
    threshold: float = Field(ge=0.0, le=1.0)
    chosen: DeployAction
    executed: bool  # False quando a política exigiu aprovação humana
    evidence_refs: list[str] = Field(default_factory=list)


IRREVERSIBLE = {DeployAction.DEPLOY}


def apply_policy(
    probabilities: dict[DeployAction, float],
    confidence: float,
    threshold: float,
) -> tuple[DeployAction, bool]:
    """Converte a saída probabilística em ação sob política determinística.

    A decisão do modelo é recomendação; quem autoriza é o código.
    """
    chosen = max(probabilities, key=probabilities.__getitem__)
    if confidence < threshold:
        return DeployAction.ESCALATE, False
    # Ação irreversível nunca executa só com base na probabilidade.
    return chosen, chosen not in IRREVERSIBLE

Por trás desse código, cinco regras:

  1. O código enumera as opções. O espaço de opções é parte do modelo. Decidir bem entre três alternativas não resolve ter omitido a quarta.
  2. Limiar e efeito colateral ficam fora do modelo. O modelo recomenda; a política autoriza.
  3. Ação irreversível passa por humano. Pagamento, exclusão, deploy, acesso a dados: a probabilidade alimenta a fila de aprovação, não a execução.
  4. Avalie com seus rótulos, não com o benchmark de lançamento. Monte um conjunto com decisões reais do seu domínio e meça calibração, não só acurácia.
  5. Logue a decisão, não a resposta. Observabilidade de agente costuma registrar texto. Registre opções, probabilidades, limiar e o que de fato foi executado.

Jevons de novo

O nome é uma aposta honesta: se o custo de uma decisão cai duas ordens de grandeza, vamos tomar muito mais decisões automatizadas. É provável que aconteça.

O paradoxo tem o outro lado. Se o espaço de opções estiver mal especificado, se a calibração não se sustentar fora do benchmark, se a política estiver no prompt e não no código, uma decisão barata e rápida só produz mais erros, mais rápido, a um custo menor por erro.

O avanço não é trocar LLMs por classificadores velozes. É parar de pedir que um modelo gere texto para escolher uma ação que o sistema já deveria ter especificado — e ter a disciplina de especificar.

Fontes