synsema

Todos os posts · · 5 min de leitura

Um juiz sem fornecedor

A probabilidade calibrada que decide o que uma pessoa vê já não precisa vir de uma API. Um checkpoint System One open source no seu próprio disco responde as mesmas perguntas tipadas sem chave, sem rede e sem custo por token — e o mesmo programa roda contra qualquer um dos dois.

system-onelayajudgeopen-sourcecomputação-confidencial

O argumento a favor de um modelo System One é que uma probabilidade calibrada é o controle necessário para automatizar uma decisão: acima do limiar a máquina age, abaixo dele uma pessoa olha. Fizemos esse caso com Jev, o primeiro modelo da classe, e o lado operacional em Colocando um modelo System One em produção.

Voltaram duas objeções, que são a mesma objeção duas vezes. Esses tickets a gente não pode mandar para um terceiro. E: não vamos colocar uma decisão que roteia nossa fila atrás da API de um único fornecedor.

Desde o motor v0.6.27 a resposta para as duas é uma mudança de configuração. O slot do juiz aceita um terceiro backend: um checkpoint open source num disco que você controla, respondendo as mesmas três perguntas tipadas — isto é verdade, qual destas, onde nesta escala — sem chave, sem rede e sem custo por token. O programa não muda. Nenhuma linha.

O que é o modelo§

Laya, da Convai Innovations, Apache 2.0: um backbone ModernBERT de 421M de parâmetros com uma cabeça de decisão que pontua perguntas tipadas sobre um estado numa única passagem. É a mesma classe de modelo que o Jev, publicado com uma licença que permite colocar os pesos dentro da sua própria implantação, na sua própria região, dentro do seu próprio enclave.

Concretamente: o checkpoint tem cerca de 843 MB, roda em CPU, e o motor já vem com a capacidade de lê-lo — então conectá-lo são duas variáveis de ambiente: qual backend, e onde está o checkpoint. Nada é baixado automaticamente; os pesos são provisionados como qualquer outro artefato.

Como isso fica em produção§

O mesmo bloco que fazia quatro perguntas sobre um ticket de suporte através da API respondeu contra um checkpoint local num notebook sem GPU: pedido de reembolso em 0,86, o time certo (billing) mas com a massa espalhada — 0,36 de confiança — então o portão mandou o ticket para uma pessoa, e uma mensagem fora do assunto corretamente não combinou com nenhuma opção, em 0,86. Cinco perguntas em dois blocos levaram 7,9 segundos de relógio com o carregamento do modelo incluído; uma única pergunta num processo novo leva 2,5 segundos. Três execuções deram números idênticos até a quarta decimal.

Leia essas duas frases juntas, porque a troca está toda aí num parágrafo. Você abre mão dos 70–500 ms do fornecedor e recebe segundos numa CPU. Em troca, o estado nunca sai da máquina, o custo por token é zero, e não existe um fornecedor cuja queda seja a sua queda. Para uma fila triada em lotes, ou um agente que decide uma vez por documento, alguns segundos são invisíveis. Para um caminho síncrono na frente de alguém digitando, não — e aí o modelo hospedado continua sendo a escolha certa.

O mesmo botão que faz o decide ser respondido pelo juiz funciona aqui também, e isso significa uma primitiva de decisão que roda sem nenhuma capacidade de rede concedida: o processo tem o direito de julgar e nenhum direito de fazer um request. Não há nada para negar, porque não há quem chamar.

Duas coisas para fazer antes de trocar§

Meça seu limiar de novo. Um portão em 0,9 é um número ajustado contra um modelo específico. Jev e Laya são modelos diferentes — a forma da resposta é idêntica, a calibração não necessariamente. Passe uma semana de tráfego pelos dois, compare cada resposta com o que a pessoa acabou fazendo, e fixe o número a partir disso. É a mesma disciplina que você aplicaria a qualquer modelo de scoring que trocasse, e é a única forma honesta de mexer nele.

Conheça a janela. O checkpoint local lê 512 tokens: a pergunta, as opções e depois todo o estado que couber. Uma thread longa perde a cauda, em silêncio, porque um estado truncado ainda produz uma resposta perfeitamente plausível. Julgue os campos que importam — a última mensagem do cliente, o assunto, o valor — em vez do objeto inteiro. Contra a API isso também é boa prática; aqui é obrigatório.

O que você não precisa temer é um número inventado. Quando o juiz não está disponível, passou do orçamento ou não está conectado, cada resposta volta marcada como indisponível, com confiança 0 e sem valor — então o portão que você já escreveu manda a fila para as pessoas por conta própria. Uma frase inventada aparece na sua saída; uma probabilidade inventada não, e ela se multiplica até virar dinheiro.

Por que isso faz valer a pena construir sobre o slot§

Um backend de juiz é um protocolo, não um produto. Isso foi uma decisão de design da linguagem quando ainda não havia outro lugar para apontá-lo, e hoje é uma propriedade de portabilidade que se pode verificar: o mesmo programa, o mesmo bloco, o mesmo portão, rodando contra uma API hospedada numa implantação e contra um arquivo em disco na seguinte. O cliente que não pode te mandar os dados e o cliente que quer a menor latência são atendidos pelo mesmo caminho de código.

Também responde a pergunta de compras que não tem boa resposta quando existe um único fornecedor. O que acontece com esse recurso se aquela empresa mudar seus preços, seus termos ou de ideia? Você move uma variável. As decisões continuam sendo tomadas, no seu próprio datacenter, com pesos cuja licença você já tem.

O guia para quem programa, verbo por verbo e com os números, é Run the judge locally with Laya. A metade generativa do mesmo release — um modelo no seu processo, sem egress — é Inferência que não sai da sua máquina.