Colocando um modelo System One em produção

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:

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:

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; a página do manual é Judge. O próximo post é sobre o que o time financeiro vai perguntar: quanto isso custa comparado com o que você faz hoje.