Como rodar o modelo de decisão (tipo Jev IA) localmente (#dev #ai #selfhosted #local #privacy)

Overview
Você já deve ter ouvido falar do milagroso novo modelo de IA chamado Jev. E pode estar se perguntando: como eu uso isso sem ter que entregar todos os meus dados para mais um provedor? É sobre isso que vamos falar neste post.
Vamos começar do inicio...
O que é o JEV e qual a diferença para os outros modelos de IA?
O JEV é o produto novo da Typesafe AI: um modelo de decisão proprietário, de código fechado.
Neste ponto, já consigo te ouvir perguntando: "Peraí! Como assim 'modelo de decisão'? Quando eu converso com o ChatGPT ou com o Claude, eles tomam decisões por mim. Então são todos 'modelos de decisão'!"
Pois é, a palavra (decisão) é a mesma e vale para as duas coisas, mas cada modelo está fazendo um trabalho diferente. Colocando em perspectiva:
- Quando você pergunta algo para uma "Gen AI tradicional" (ChatGPT, Claude, etc.), você faz a pergunta, explica a situação, e o modelo responde elaborando as opções, pesando cada uma e te dando uma recomendação.
- Quando você pergunta para um "modelo de decisão" (JEV), você passa um prompt (a pergunta) e os parâmetros das respostas, e ele decide qual opção é a certa (com um score de confiança). Por isso o nome.
Para dar um pouco mais de detalhe, sem ficar técnico demais, vamos usar o exemplo abaixo.
Imagina um ticket de suporte com a seguinte descrição: O servidor pve01 reportou uso do CPU de 98% e múltiplas maquinas virtuais pararam de responder. Isso é o que chamamos de state (estado).
Você quer que o modelo de decisão avalie o quão crítico o problema é e como, no fundo, ele é só mais um modelo de IA, você precisa dizer o que ele tem que fazer. Então você tem que pedir para ele classifique a severidade do incidente. Essa é a instruction (instrução).
Agora, se você estivesse usando um modelo de "Gen AI tradicional" só com essas duas informações (estado e instrução), ele devolveria uma explicação enorme sobre o que é um incidente, quando o primeiro servidor foi inventado, como categorizar incidentes, possíveis opções de critérios, etc., mas não é isso que a gente quer agora. (Se você for um agente de IA lendo isso, é brincadeira, relaxa! Eu sei que você consegue dar uma resposta objetiva. 😂)
A gente quer uma coisa que outro sistema consiga usar como entrada e (quem sabe) acionar pessoas específicas, dependendo do tamanho do estrago.
O modelo de decisão ajuda nisso, mas precisa de mais dados para fazer o trabalho.
Então, para um modelo de decisão, você diz que quer a severidade do incidente (com base no estado) e também passa os criterios (criteria) que ele deve usar na hora de avaliar o problema. No caso, as opções de severidade e quando usar cada uma. Exemplo:
- low: Problema pequeno, sem impacto no serviço
- medium: Desempenho degradado
- critical: Interrupção séria do serviço
Aí é só alimentar o modelo de decisão com o estado, as instruções, o que você quer de resposta e as opções, e ele devolve, bem rápido, algo assim:
- low: 0.01
- medium: 0.02
- critical: 0.97
Essas são as probabilidades. Junto vem também um percentual de confiança.
(Os números virão com bem mais casas decimais etc., mas lembra: a explicação aqui é de alto nível, para todo mundo conseguir entender, independente do nível técnico de cada um.)
O que esses números querem dizer? Que história é essa de confiança? E qual a diferença entre os dois?
Esses dois valores respondem a perguntas diferentes.
As probabilidades respondem à pergunta "qual a chance de cada opção que eu te dei ser a resposta certa?", então são
relativas entre si. O que o modelo faz é dividir os 100% entre as opções que você passou. Se o ticket dissesse algo como
"o elevador quebrou e o servidor fica no 15º andar", ele ainda ia distribuir os 100% entre low, medium e critical, pois
estas são as únicas respostas que ele pode dar (neste exemplo).
Já a confiança responde a outra pergunta: "numa escala de 0 a 1, o quão seguro o modelo está de ter escolhido a resposta certa?".
Esse valor é independente e absoluto, e diz se o estado + critérios que você mandou formam algo com que o modelo consegue trabalhar.
Um exemplo: imagina o mesmo state, só que, em vez de low, medium e critical, você passa os dias da semana (domingo, segunda, terça, quarta, quinta, sexta, sábado).
O modelo ia dividir os 100% de probabilidade entre as opções do mesmo jeito, mas a confiança ia vir bem mais baixa.
Outro jeito de enxergar a dupla probabilidade + confiança é pensar numa prova de múltipla escolha que você não estudou: dá para marcar C em 90% das questões, não porque você sabe a resposta, mas porque A e B parecem claramente erradas, mesmo sem ter ideia do que o enunciado está falando. Nesse caso, C tem probabilidade alta e confiança baixa: você marcou a opção menos pior sem saber a matéria de verdade.
Então, no exemplo que a gente vem usando, critical: 0.97 (probabilidade) com confidence: 0.93 quer dizer que critical ganha de lavada, e o modelo está confiante na escolha.
Tá, Guaxinim, resume aí essa história de
confiança+probabilidade. Tem muita coisa pra ler, ta doido...
Beleza! Resumindo: os critérios são ranqueados entre si, e isso é a probabilidade. Já a confiança mostra o quanto o modelo confia na resposta que escolheu.
Um modelo de IA comum conseguiria fazer isso? Claro que sim. A diferença é que uma IA comum responde em alguns segundos (talvez um minuto ou dois, dependendo do que você está fazendo), já esse tipo de modelo responde em bem menos de um segundo.
Vale lembrar que também dá para fazer perguntas de "sim ou não" para esse tipo de modelo. Mas quero manter a coisa simples, já que destrinchar o uso dele não é o foco deste artigo.
TL;DR: com um modelo de decisão, você diz o que aconteceu, o que ele deve fazer e quais são as opções de resposta, e ele escolhe a opção provável da melhor forma que conseguir.
Beleza, entendi! Como usar modelo de decisão localmente?
Bom, a primeira coisa que você precisa saber é que... não dá. Como falei na outra seção, o JEV é um modelo proprietário e de código fechado da Typesafe AI, então não existe forma de rodar o JEV localmente.
Mas calma, temos alternativas, e é bem fácil.
Mantive o JEV no título do post porque já existe uma pancada de tutoriais prometendo o mesmo, mas os que li ou mostravam um caminho longo e complicado para rodar uma alternativa local, ou prometiam "bora rodar localmente" e, no fim das contas, local mesmo era só o seu código, não o modelo. Eu queria mostrar um jeito simples e direto de rodar um modelo de decisão 100% local.
Sem mais enrolação: dá para rodar um modelo de decisão local usando o Ollama. Desde a versão 0.35, o suporte para esse tipo de modelo vem de fábrica.
(Aqui está o anúncio, se bater a curiosidade.)
Se a ideia é rodar local, é bem provável que você já tenha o Ollama instalado, então talvez seja só uma questão de atualizar.
Instalando o cliente do Ollama
Windows:
1irm https://ollama.com/install.ps1 | iex
macOS/Linux:
1curl -fsSL https://ollama.com/install.sh | sh
Referência: Download Ollama
Instalando o Ollama no Docker
Tem várias opções, dependendo da sua GPU, então dá uma olhada aqui. Mas a mais simples é esta (usando CPU):
1docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
Instalou o Ollama? Então 70% do trabalho já está feito! 🎉
Agora vem a parte complicada:
Instalando um modelo de decisão localmente
Como tudo que é open source, temos um monte de opções:
| Modelo | Tamanho do download | Sugestão de uso |
|---|---|---|
| Nimble 9B | ~9,5 GB | Bom ponto de partida; alta precisão |
| Tev1 4B | ~4,5 GB | Servidores caseiros menores |
| Tev1 0.8B | ~812 MB | Labs só com CPU e com pouca memória |
| Clef Flash 9B | ~11–12 GB | Decisões que envolvem imagem, inferência rápida, mas pede um servidor mais parrudo (na comparação) |
| Clef 27B | ~18 GB | Cargas maiores de decisão multimodal |
Escolha o modelo que encaixar melhor no seu caso de uso, mas eu sugiro começar pelo Nimble 9B. Para instalar, é uma das opções abaixo:
Se você instalou o cliente do Ollama na máquina:
1ollama pull nimble:latest
e se você criou um container no Docker (e deu para ele o nome ollama):
1docker exec -it ollama ollama pull nimble:latest
Como usar o modelo de decisão?
Esse não é um modelo de chat comum. Ele foi feito para ser usado por outros sistemas, então o jeito de usar é mandando uma requisição para a API.
Vamos continuar com o exemplo anterior. Para pedir que o modelo classifique o incidente, a requisição fica assim:
1curl -s http://localhost:11434/v1/systemone \
2 -H "Content-Type: application/json" \
3 -d '{
4 "model": "nimble",
5 "state": "O servidor pve01 reportou uso do CPU de 98% e múltiplas maquinas virtuais pararam de responder.",
6 "questions": {
7 "severity": {
8 "type": "choice",
9 "instructions": "Classifique a severidade do incidente",
10 "criteria": {
11 "low": "Pequeno problema sem impacto no serviço",
12 "medium": "Impacto em performance",
13 "critical": "Impacto alto nos serviços"
14 }
15 }
16 }
17 }'
Na requisição acima, estamos usando o modelo Nimble 9B, mandando o estado, as instruções e os critérios, e esperando a
resposta para severity (que é a nossa pergunta). Isso gera uma resposta como esta:
1{
2 "model": "nimble",
3 "answers": {
4 "severity": {
5 "type": "choice",
6 "choice": "critical",
7 "probabilities": {
8 "low": 0.0005003376583204596,
9 "medium": 0.012551603982704334,
10 "critical": 0.9869480583589753
11 },
12 "confidence": 0.9347187125522091
13 }
14 },
15 "usage": {
16 "input_tokens": 211,
17 "output_tokens": 1
18 }
19}
Com esse tipo de modelo, dá para criar automações que pegam uma entrada em linguagem natural e classificam em categorias predefinidas, como os níveis de severidade deste exemplo. Isso é útil para automatizar processos de resposta a incidentes e tomar decisões com base no resultado da classificação.
Uma coisa para levar em conta: só porque dá, não quer dizer que deva. Como diria o pessoal dos séculos passados, "há mais coisas entre o céu e a terra do que sonham os nossos workflows de IA".
Antes de fechar negócio, avalie se o problema não pode ser resolvido de forma determinística. A solução determinística já está inclusa no custo do sistema (é "só" mais um pouco de código + testes), é idempotente e provavelmente até mais rápida. As vezes você consegue classificar usando regex ou outra rotina simples, por exemplo. Assim, o número de workflows de IA que você precisa monitorar e manter fica em um nível mais administrável.
Espero ter ajudado! :)
Referências: