Como rodar o Jev em modo sombra ao lado de outra ferramenta para comparar em produção sem risco

Trocar a ferramenta que decide em produção sem prova é aposta

E o modo sombra transforma essa aposta em dado 🙂

Fala aí, beleza? A TypeSafe AI saiu do modo discreto em 15 de setembro de 2026 e lançou o Jev, um modelo de IA que NÃO gera texto nem código

Ele recebe o estado do seu programa e devolve uma decisão tipada, com a probabilidade de cada opção

E isso muda MUITO a forma de comparar: aqui é decisão contra decisão, não texto contra texto. Bora ver como rodar isso em produção reduzindo o risco ao máximo?

O que é modo sombra e por que ele combina com o Jev?

Modo sombra é rodar uma ferramenta nova ao lado da que já decide, só observando

A decisão real segue intacta, o usuário nem fica sabendo, e a sombra apenas registra o que ela TERIA respondido

É como colocar um estagiário pra anotar o que faria em cada caso, sem deixar ele mexer em nada haha

No fim do período você compara as anotações dele com o que realmente aconteceu

O roteiro de rollout começa pela sombra:

Existe uma ordem de rollout publicada para o Jev num guia prático no Hugging Face, e ela começa justamente pelo modo sombra:

1. shadow (rodar ao lado e só registrar)
2. label (rotular comparando com a verdade)
3. thresholds (definir limiares)
4. fallback (definir o plano B)
5. enforce (colocar em vigor)
6. monitor (seguir monitorando)

Se liga: essa ordem de etapas vem de um guia de terceiros, não da documentação oficial da TypeSafe

Por que a saída tipada facilita a comparação?

Nas respostas dos tipos Choice e Score, o Jev devolve um valor de confiança entre 0 e 1

Ou seja, cada resposta vira uma linha de log limpinha: qual opção, com quanta certeza

Nada de ficar interpretando parágrafo de LLM pra descobrir se "provavelmente sim, mas depende" conta como aprovado ou não xD

O que você precisa antes de começar:

Conta no console da TypeSafe

O cadastro e o console ficam em console.typesafe.ai

Desde 27/09/2026 o cadastro está aberto a todos, só que contas novas não recebem mais crédito grátis

Então já entra sabendo que a sombra vai custar desde a primeira chamada

SDK instalado

Em Python (exige Python 3.10 ou superior):

pip install typesafe-sdk

Ou, se tu usa uv:

uv add typesafe-sdk

Em JavaScript/TypeScript, o pacote é o @typesafe-ai/sdk

Chave de API e versão do modelo

O cliente lê a chave na variável de ambiente TYPESAFE_API_KEY e chama o jev-latest por padrão

Hoje o jev-latest aponta para o jev-1.13.0

Tome cuidado! Um alias "latest" pode passar a apontar pra outra versão no meio da sua observação

Por isso, registre a versão do modelo em TODA linha de log, assim tu sabe exatamente qual versão gerou cada decisão

Quanto custa a sombra?

O jev-latest cobra só pelos tokens de entrada: US$ 0,042 por milhão

Os tokens de saída são gratuitos

Como a sombra roda em cada requisição que você escolher espelhar, o custo acompanha o volume de entrada desse fluxo

E a privacidade?

A TypeSafe declara que o Jev não é treinado com requisições nem respostas dos clientes

Porém, a retenção zero de dados é oferecida só para clientes enterprise

Antes de mandar dado de produção pra sombra, avalia com calma o que está saindo do seu sistema, beleza?

Passo a passo para rodar o Jev em modo sombra em produção

1. Defina quem decide e quem é sombra

Primeiro de tudo: só UMA ferramenta decide

Se hoje a decisão vem da ferramenta atual, ela continua decidindo, e o Jev entra como sombra (ou o contrário, se o Jev já está em produção e o concorrente é o candidato)

A resposta da sombra vai pro log e para por aí

O erro comum deste passo: deixar as duas respostas afetarem o fluxo. Um if esquecido que usa a resposta da sombra como desempate já transforma o teste em produção de verdade

2. Chame a sombra em paralelo, sem bloquear a decisão real

Aqui mora o porquê de tudo: a sombra NUNCA pode deixar a requisição mais lenta nem derrubá-la

Segundo a TypeSafe, o Jev responde em 70 a 500 milissegundos. Mesmo rápido, ele roda fora do caminho crítico, com timeout próprio e erro isolado

O código abaixo é só a estrutura do wrapper, em pseudocódigo estilo Python. decisao_atual e consultar_sombra são funções suas (a segunda é onde você chama o SDK do jeito que a documentação mostra):

# pseudocódigo: estrutura do wrapper de modo sombra
async def decidir(requisicao_id, estado):
    # 1) a decisão real roda normalmente e é ela que vale
    decisao = await decisao_atual(estado)

    # 2) a sombra é disparada em segundo plano, sem await no fluxo principal
    disparar_em_background(rodar_sombra(requisicao_id, estado, decisao))

    return decisao


async def rodar_sombra(requisicao_id, estado, decisao_real):
    try:
        resposta = await com_timeout(consultar_sombra(estado), segundos=TIMEOUT_SOMBRA)
        registrar_log(requisicao_id, decisao_real, resposta)
    except Exception as erro:
        # falha da sombra vira log, nunca erro para o usuário
        registrar_falha_sombra(requisicao_id, erro)

Se o volume for alto, vale ler sobre como rodar decisões do Jev em paralelo sem travar a aplicação

O erro comum deste passo: a sombra cair (timeout, chave errada, rede) e levar a requisição junto. Já vi muito sistema "de teste" virar incidente por causa de um await no lugar errado 😛

3. Logue tudo, sempre

Cada requisição espelhada vira uma linha. Se liga nos campos:

O erro comum deste passo: logar só quando as duas divergem. Sem as concordâncias você não tem base pra calcular nada, e ainda perde os casos em que AS DUAS erraram juntas

4. Rotule comparando com a verdade

Depois que o desfecho real aparece (o cliente pagou ou não, o ticket era mesmo urgente, a transação era fraude ou não), você preenche esse campo no log

E se você já tem um histórico com desfecho conhecido, dá pra adiantar bastante coisa ao rodar o Jev em lote sobre essa base antes mesmo de ligar a sombra ao vivo

O erro comum deste passo: tratar a ferramenta atual como gabarito. Se o Jev discorda da atual, isso não quer dizer que o Jev errou. Quem arbitra é o desfecho real, não a ferramenta que está decidindo hoje

5. Analise a divergência por faixa de confiança

Aqui entra a etapa de limiares do roteiro (a ordem das etapas vem do guia de terceiros), e pra separar as faixas tem base oficial: a documentação da TypeSafe sugere 3 caminhos pela confiança:

• confiança alta: agir
• faixa do meio: revisar
• confiança baixa: mandar para um humano

Então quebra a análise nessas 3 faixas. A pergunta que importa é: quando o Jev está confiante, ele acerta?

Os pontos de corte de cada faixa quem define é você, olhando os seus dados rotulados

O erro comum deste passo: olhar só a média geral. Uma média ok pode esconder uma faixa alta muito confiável e uma faixa baixa péssima, e é exatamente essa separação que vai virar o seu limiar depois

6. Por quanto tempo observar?

Não existe prazo oficial, nem em dias nem em volume de amostras

O critério é qualitativo: observe até cobrir os ciclos normais do seu tráfego (dias de semana e fim de semana, início e fim de mês, sazonalidade do seu negócio) e até ter rótulo suficiente nos casos raros que importam

Se o seu caso crítico aparece pouco, a observação dura o tempo que ele leva pra aparecer o bastante

O erro comum deste passo: decidir com a primeira semana boa. Semana boa todo mundo tem… o que separa a ferramenta certa da errada costuma estar nos casos que ainda não apareceram

7. Que divergência justifica a troca?

Também não tem percentual mágico aqui, e desconfie de quem te der um

O critério que faz sentido é:

• o candidato acerta onde a ferramenta atual erra, de forma consistente e não por sorte
• ele não piora os casos críticos do seu negócio
• a faixa de confiança alta se mostra confiável nos dados rotulados

Bateu tudo? Antes de colocar em vigor, define os limiares (o que é "alta", "meio" e "baixa" pra você) e o fallback (o que acontece se o Jev falhar ou responder com confiança baixa)

Depois de trocar, a antiga pode até virar a sombra por um tempo, e o monitoramento continua

O erro comum deste passo: trocar sem fallback. Aí no primeiro timeout tu descobre na marra que não tinha plano B

Quando comparar o Jev com outra ferramenta faz sentido (e quando não)

Faz sentido quando o software precisa de uma decisão tipada

Classificar, escolher entre opções, pontuar

Se a saída que você quer cabe numa opção ou num score, a comparação em modo sombra é direta e o Jev joga no campo dele

Não faz sentido quando a tarefa é gerar texto ou código

O Jev não é chatbot nem modelo de código: não escreve respostas, explicações nem código

Comparar ele com um LLM numa tarefa de redigir resposta pro cliente ou escrever função não tem nem como dar empate haha

Às vezes o resultado é dividir, não trocar

Guias de terceiros posicionam o Jev como complemento do LLM, não substituto: LLM quando a tarefa exige linguagem ou raciocínio, Jev quando o software precisa de uma decisão tipada rápida e barata

Muitos sistemas usam os dois

Então não estranha se a conclusão da sua sombra for "o Jev decide, o LLM escreve", isso também é um resultado válido 😀

Próximo passo: da sombra para a decisão em vigor

Recapitulando a lógica toda: uma ferramenta decide, a outra registra, e a verdade rotulada arbitra

Você loga tudo (não só as divergências), analisa por faixa de confiança, observa até cobrir seus ciclos e só troca com limiares e fallback definidos

O próximo passo concreto é simples:

1. criar a conta no console.typesafe.ai
2. instalar o SDK (pip install typesafe-sdk, uv add typesafe-sdk ou @typesafe-ai/sdk)
3. configurar a TYPESAFE_API_KEY
4. ligar o Jev em modo sombra num ÚNICO fluxo de decisão de baixo risco antes de expandir

Começa pequeno, deixa os dados falarem e depois escala 🙂

Até o próximo post!