# Colocando um modelo System One em produção

> Um modelo que devolve probabilidades calibradas em vez de texto muda as perguntas operacionais, não só o código. O que conectar, o que colocar atrás de um portão, o que auditar, e o que acontece no dia em que o provedor cai.

2026-09-20 · https://synsema.com/pt/blog/colocar-um-modelo-system-one-em-producao


Um modelo System One — o **Jev**, da TypeSafe, é o primeiro — responde perguntas tipadas sobre um estado com probabilidades calibradas em vez de prosa. Para a metade de um agente que decide em vez de escrever, isso elimina de uma vez o parser, o laço de retentativas e a confiança inventada.

Isso também muda a conversa operacional, e essa é a parte que uma plataforma precisa responder. É isto que colocar um em produção realmente envolve.

## Dois slots, não uma troca

O juiz não substitui o modelo de linguagem. Ele fica ao lado: o juiz decide, o LLM escreve, e a configuração normal tem os dois conectados. Na plataforma são duas configurações independentes (`SYNSEMA_JUDGE_*` ao lado de `SYNSEMA_LLM_*`), dois conjuntos de credenciais e dois orçamentos.

Essa separação também é um limite de permissão, e é a primeira coisa que uma revisão de segurança vai notar:

```synsema
require judge      -- pode classificar
require llm        -- pode gerar
```

Nenhum concede o outro. Um serviço implantado com `judge` e sem `llm` é um serviço que consegue medir e não consegue escrever — não dá para convencê-lo a emitir texto livre, nem exfiltrar por ali. Para as partes de roteamento, triagem e elegibilidade de um produto, isso é bem menos coisa para defender.

## A chave nunca chega ao programa

`TYPESAFE_API_KEY` entra como um segredo selado, como qualquer outro: guardado no plano de controle, injetado quando o contêiner sobe, exibido no dashboard como nome e impressão digital. O programa não consegue imprimi-la, logá-la, concatená-la nem devolvê-la por uma rota, e o host para onde a chamada vai é fixado pelo runtime — um `.syn` implantado não consegue redirecionar seus julgamentos para outro lugar.

Cada verificação de capacidade que o runtime faz cai na trilha de auditoria, então "esse serviço classificou alguma coisa ontem à noite, e quanto gastou nisso?" é uma consulta, e não uma investigação.

## Um preflight que cabe no deploy

A falha mais sem graça em produção é um serviço que sobe bem e para de julgar em silêncio porque uma chave nunca chegou ao ambiente. A CLI responde isso antes de o processo subir, sem tocar a rede:

```
$ synsema judge status
Key         TYPESAFE_API_KEY             ✗ FALTANDO
Model       jev-latest                   (SYNSEMA_JUDGE_MODEL, default)
Base URL    https://api.typesafe.ai      (SYNSEMA_JUDGE_BASE_URL, default)
Budget      (sem teto)                   (SYNSEMA_JUDGE_BUDGET, default)
decide      LLM (default)                (SYNSEMA_JUDGE_DECIDE)
```

Sai 0 quando está no ar e 1 quando não está, então `synsema judge status && synsema serve app.syn` é um portão e não um ritual. A chave é reportada por presença; o valor nunca aparece.

## O dia em que o provedor cai

Esta é a pergunta que vale resolver antes do incidente, porque a alternativa a uma boa resposta é um sistema que continua respondendo com segurança, com números que ele inventou.

Sem chave, acima do orçamento ou depois de uma falha de rede, toda resposta volta com `available: false`, `confidence: 0` e o valor principal em `nothing`. Um aviso vai para o stderr e o programa continua rodando. Uma probabilidade inventada nunca é devolvida — e isso importa mais do que parece, porque uma frase inventada aparece na sua saída e uma probabilidade inventada não: ela apenas se multiplica, quieta, até virar um reembolso, um roteamento, um pagamento.

A consequência útil é que a degradação cai no ramo que você já escreveu. Um portão de confiança em 0,9 não é satisfeito por uma confiança de 0, então cada ticket vai sozinho para o caminho humano:

```synsema
when v.team.available and confidence of v.team >= 0.9
    route(v.team.choice)
otherwise
    approve "Route to " + text(v.team.choice) + "?"
```

Na plataforma esse `approve` é uma fila de verdade: a aprovação aparece no dashboard e na API, avisada por webhook assinado e respondida com um token de uso único. Uma queda do provedor vira uma caixa de entrada mais cheia por algumas horas, e não uma decisão errada em escala.

## Um orçamento é um botão, não uma planilha

`SYNSEMA_JUDGE_BUDGET` é um teto rígido de tokens de entrada por processo. No teto, as respostas degradam para `available: false` **sem tocar a rede** — o gasto para num número que você escolheu, não no fim do mês. Defina um por serviço, do mesmo jeito que você define memória.

## Fixe a versão contra a qual seus limiares foram calibrados

`judge_model()` devolve o id versionado que respondeu a última chamada (`jev-1.13.0`), nunca o alias, e isso é proposital: fornecedores mexem no `latest`. Um limiar de 0,9 é um número ajustado contra um modelo específico, então fixe `SYNSEMA_JUDGE_MODEL` numa versão em produção e volte a medir seus portões quando mudar — a mesma disciplina que você aplicaria a um modelo de score treinado por você.

Mais duas coisas que vale saber antes do primeiro rollout: requisições idênticas variam por alguns centésimos (0,72 → 0,69), então os testes afirmam vencedores e faixas, nunca igualdade; e `SYNSEMA_JUDGE_PROVIDER=mock` responde de forma determinística sem rede e sem conta, que é como isso pertence ao CI.

## O que isso substitui

Para trabalho com formato de classificação, substitui uma chamada de chat mais um parser mais uma retentativa mais uma confiança que você inventou. Para o resto — a resposta que o cliente lê, o resumo, a explicação — o modelo de linguagem continua sendo a ferramenta certa, e os dois ficam conectados ao mesmo tempo.

O guia do lado do desenvolvimento é [How to use Jev from Synsema](https://synsema.org/blog/how-to-use-jev-the-judge-block); a página do manual é [Judge](https://synsema.dev/en/0.6.x/54-judge). O próximo post é sobre o que o time financeiro vai perguntar: quanto isso custa comparado com o que você faz hoje.

