Ollaya: um Ollama para modelos de decisão open source

Hoje, para aprovar ou recusar um pedido com IA, muita gente sobe um LLM de 7 bilhões de parâmetros, escreve um prompt de 40 linhas e reza para o JSON voltar válido. O Ollaya aparece justamente para atacar esse exagero. A proposta cabe numa frase: ser o "Ollama dos modelos de decisão open source". Você baixa um modelo feito para escolher, roda local e recebe uma decisão em vez de um texto.

O nome parece primo do Ollama no almoço de domingo, e é de propósito. A ideia é herdar a experiência que fez o Ollama virar padrão: um comando para baixar, um comando para rodar, uma API local para consumir.

O que é o Ollaya, na prática

O Ollama resolveu um problema chato: rodar LLM na sua máquina sem brigar com CUDA, quantização e formato de pesos. Você digita ollama run llama3 e pronto. Por baixo, sobe um servidor em localhost:11434 que qualquer app consegue chamar.

O Ollaya aplica a mesma embalagem a outra categoria de modelo. Modelo de decisão é aquele que recebe um contexto e devolve uma escolha dentro de um conjunto fechado de opções. Aprovar ou recusar. Rotear para o time A, B ou C. Chamar a ferramenta X ou não chamar nada. A saída é estruturada por natureza, e não um parágrafo que você precisa interpretar depois.

O site descreve esses modelos como "Jev-style". É jargão do próprio projeto. Antes de adotar, leia a documentação com calma para entender exatamente o que o termo promete, porque nome bonito não substitui especificação.

Por que modelo de decisão importa para quem programa

Pense em quantas decisões pequenas o seu backend toma por dia. Classificar um ticket de suporte. Marcar uma transação como suspeita. Decidir se um comentário vai para moderação. Escolher qual dos cinco endpoints internos um agente deve chamar.

A solução da moda virou "joga num LLM". Funciona, mas olha como fica o código com o Ollama hoje:

const res = await fetch('http://localhost:11434/api/generate', {
  method: 'POST',
  body: JSON.stringify({
    model: 'llama3',
    prompt: `Classifique o ticket em "billing", "bug" ou "outro".
Responda só JSON: {"categoria": "..."}

Ticket: ${ticket.texto}`,
    format: 'json',
    stream: false,
  }),
})

const { response } = await res.json()
const parsed = TicketSchema.safeParse(JSON.parse(response))

if (!parsed.success) {
  // retry, fallback, log, choro
}

Repare no que está acontecendo. Você usa um gerador de texto para produzir uma única palavra. Paga latência de geração, paga memória de um modelo enorme e ainda precisa validar com Zod porque o modelo pode inventar uma categoria "financeiro" que não existe.

Um modelo de decisão inverte isso. As opções fazem parte do contrato, não do prompt. O modelo não tem como responder fora delas.

Se a resposta cabe num enum, você não precisa de um modelo que escreve redação.

O que muda no seu código e no seu fluxo

Se o Ollaya entregar o que promete, o código acima vira algo parecido com isto. O formato abaixo é ilustrativo, confira a API real na doc do projeto:

type Decisao = {
  escolha: 'billing' | 'bug' | 'outro'
  confianca: number
}

const decisao: Decisao = await ollaya.decide({
  model: 'ticket-router',
  input: ticket.texto,
  options: ['billing', 'bug', 'outro'],
})

switch (decisao.escolha) {
  case 'billing': return filaFinanceiro.add(ticket)
  case 'bug': return filaEngenharia.add(ticket)
  default: return filaGeral.add(ticket)
}

Três ganhos concretos aparecem aqui:

• Tipagem de verdade. O TypeScript conhece todas as saídas possíveis. O switch fica exaustivo e o compilador reclama se você esquecer um caso.
• Confiança como número. Com um score, você define uma regra simples: abaixo de 0.7, manda para um humano. Com texto livre, isso vira adivinhação.
• Custo previsível. Rodar local significa zero cobrança por token e nenhum dado do cliente saindo do seu servidor.

Esse último ponto pesa mais do que parece para quem trabalha com dados no Brasil. Mandar o texto de um ticket com CPF e endereço para uma API externa só para decidir uma fila é o tipo de coisa que dá dor de cabeça no jurídico.

Quais são os riscos de adotar agora

Aqui entra a parte honesta. Projeto novo tem cara de projeto novo, e vale pesar alguns pontos antes de empolgar.

O catálogo é o produto. O Ollama ficou forte porque tem centenas de modelos prontos. Um runtime de modelos de decisão só vale se existirem modelos bons para os seus casos. Se o catálogo tiver três modelos genéricos, você vai acabar treinando o seu, e aí o problema é outro.

Benchmark ou não aconteceu. Precisão de modelo de decisão se mede, não se sente. Procure números publicados por modelo: acurácia, dataset usado, matriz de confusão. Se não tiver, você mesmo vai ter que medir com os seus dados.

Licença de cada modelo. O runtime ser open source não garante que os pesos sejam livres para uso comercial. Leia a licença de cada modelo, um por um. Já vi projeto ir para produção com modelo "open" que proibia uso comercial na letra miúda.

Decisão automatizada tem regra. O artigo 20 da LGPD dá ao titular o direito de pedir revisão de decisões tomadas só com base em tratamento automatizado. Se o modelo recusa crédito ou bloqueia uma conta, você precisa conseguir explicar o porquê e oferecer revisão humana. Guarde input, versão do modelo, escolha e confiança de cada decisão. Isso não é opcional.

Como testar o Ollaya sem quebrar produção

Minha recomendação é o modo sombra. Você não troca nada. Roda o modelo em paralelo com a regra atual e só registra quando os dois discordam.

const atual = regraAtual(ticket)

ollaya
  .decide({ model: 'ticket-router', input: ticket.texto, options: CATEGORIAS })
  .then((d) => {
    if (d.escolha !== atual) {
      log.info('divergencia', { id: ticket.id, atual, modelo: d.escolha, confianca: d.confianca })
    }
  })
  .catch((err) => log.warn('ollaya falhou', err))

return atual

Deixa isso rodando duas semanas. Depois pega 100 divergências e revisa na mão. Se o modelo acertou a maioria das vezes em que discordou da regra, você tem um argumento real para migrar. Se errou, você economizou um incidente.

Repare que a chamada não bloqueia a resposta e que a falha do modelo não derruba nada. Em modo sombra, o modelo nunca pode ser o motivo de um erro 500.

Um detalhe de infraestrutura: rode o servidor do Ollaya como um serviço separado, com healthcheck, igual você faria com o Ollama. Não suba o modelo dentro do processo da sua API Node. Quando ele consumir memória demais, você quer reiniciar o modelo, não o backend inteiro.

Vale a pena ficar de olho?

Vale, e o motivo não é o modelo em si. O Ollama não ganhou porque tinha os melhores pesos. Ganhou porque transformou "rodar IA local" em algo que um dev faz numa tarde. Modelo que ninguém consegue rodar em cinco minutos, na prática, não existe.

Minha opinião: a gente passou dois anos usando LLM gigante como martelo para todo prego, inclusive para prego que era um if com confiança. Modelos de decisão pequenos, locais e tipados são o caminho mais sensato para boa parte desses casos. Se o Ollaya vai ser a ferramenta que consolida isso, ainda não dá para saber. Depende de catálogo, de comunidade e de benchmarks que o projeto ainda precisa mostrar.

Por enquanto, eu faria assim: instala, roda num caso de baixo risco em modo sombra e mede. Se os números baterem, você ganha latência menor, custo zero por chamada e um código mais fácil de ler. Se não baterem, você perdeu uma tarde e ganhou um dataset de divergências que já vale ouro.

Se quiser ver como eu aplico IA em projetos reais, sem hype, dá uma olhada nos meus projetos.

Tem dev subindo um LLM de 7 bilhões de parâmetros só para devolver uma palavra.

Classificar um ticket, aprovar um pedido, escolher uma fila. Se a resposta cabe num enum, você não precisa de um modelo que escreve redação.

O Ollaya quer ser o "Ollama dos modelos de decisão": baixa, roda local e recebe uma escolha tipada com score de confiança, em vez de um JSON que você reza para vir válido.

Ganho real: switch exaustivo no TypeScript, custo zero por token e nenhum CPF saindo do seu servidor.

Mas projeto novo pede cautela: catálogo, benchmark, licença de cada modelo e o artigo 20 da LGPD.

Minha sugestão é testar em modo sombra por duas semanas e deixar os números decidirem.

Escrevi o passo a passo completo no blog. Você já usou LLM para algo que era só um if?

#InteligenciaArtificial #TypeScript #OpenSource #LGPD #DesenvolvimentoDeSoftware