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

Quanto você já pagou em token para um modelo gigante responder "sim" ou "não"? Essa pergunta resume bem por que o Ollaya chamou minha atenção. O projeto se apresenta como "Ollama for open-source, Jev-style decision models". A ideia é ter um jeito simples de baixar e rodar localmente modelos de decisão open source, do mesmo jeito que o Ollama fez com os LLMs de chat. A fonte é o site oficial: ollaya.dev.

Vou separar o que a proposta promete, onde ela encaixa num backend de verdade e o que eu testaria antes de confiar nela.

O que é o Ollaya, em uma frase

Pense no que o Ollama fez por você. Antes dele, rodar um modelo local exigia baixar pesos na mão, brigar com dependência de Python e torcer para a GPU colaborar. Depois dele, ficou assim:

ollama pull qwen2.5:3b
ollama run qwen2.5:3b

Dois comandos e uma API HTTP local. Esse foi o grande mérito do Ollama: transformou um projeto de pesquisa em uma ferramenta de dev.

O Ollaya quer repetir essa experiência para outro tipo de modelo. O foco não é conversar nem escrever texto. É decidir. Um modelo de decisão recebe uma entrada e devolve uma escolha: aprovar ou bloquear, qual fila, qual rota, qual ação tomar em seguida.

Sobre o termo "Jev-style": é um rótulo do próprio projeto. Antes de sair repetindo, vale ler a documentação e entender o que exatamente ele define. Jargão novo é ótimo para marketing e péssimo para code review.

Por que modelos de decisão pequenos fazem sentido

A maior parte do uso de IA que eu vejo em produção não é chat. É decisão disfarçada de geração. Exemplos que todo mundo já escreveu:

• classificar um ticket de suporte em "cobrança", "bug" ou "dúvida";
• decidir se um comentário vai para moderação;
• escolher qual ferramenta um agente deve chamar;
• marcar uma transação como suspeita.

Em todos esses casos, a saída útil cabe em poucos bytes. Mesmo assim, muita gente manda a requisição para um modelo de fronteira, paga por milhares de tokens de raciocínio e espera um segundo ou dois pela resposta. É contratar um cirurgião para tirar farpa do dedo.

Um modelo pequeno e especializado, rodando na sua máquina ou no seu servidor, ganha em quatro pontos:

• Latência: sem ida e volta para uma API externa.
• Custo: o custo marginal vira CPU ou GPU que você já paga.
• Privacidade: o dado do cliente não sai da sua infraestrutura.
• Previsibilidade: saída restrita a um conjunto fechado de opções é mais fácil de testar.

Quando a resposta cabe em um enum, o modelo não precisa caber em um datacenter.

Como isso fica no código hoje

Para você ter uma referência concreta, olha como eu resolvo classificação local hoje com o Ollama. O truque é usar o campo format com um JSON Schema, que força a saída a respeitar a estrutura:

type Fila = 'cobranca' | 'bug' | 'duvida'

async function classificarTicket(texto: string): Promise<Fila> {
  const res = await fetch('http://localhost:11434/api/generate', {
    method: 'POST',
    body: JSON.stringify({
      model: 'qwen2.5:3b',
      prompt: `Classifique o ticket de suporte:\n\n${texto}`,
      stream: false,
      format: {
        type: 'object',
        properties: { fila: { enum: ['cobranca', 'bug', 'duvida'] } },
        required: ['fila'],
      },
    }),
  })

  const { response } = await res.json()
  return JSON.parse(response).fila
}

Funciona. Mas repara no que está acontecendo: eu pego um modelo generalista de linguagem e amarro ele com schema e prompt até ele se comportar como classificador. É um LLM fingindo ser modelo de decisão.

É exatamente essa lacuna que o Ollaya tenta ocupar. Em vez de domar um modelo de chat, você roda um modelo que já nasceu para escolher. Se a ferramenta entregar uma experiência parecida com a do Ollama (baixar, rodar, chamar por HTTP), a troca no seu código é pequena: muda o endpoint, muda o modelo, e a função classificarTicket continua com a mesma assinatura.

Esse é o ponto que mais me interessa. Se a sua lógica de decisão já está isolada atrás de uma função tipada, trocar o motor por baixo vira um detalhe de infraestrutura.

O que eu testaria antes de colocar em produção

Projeto novo de IA open source merece curiosidade e desconfiança na mesma medida. Antes de trocar qualquer coisa no meu backend, eu faria este roteiro:

1. Montar um conjunto de avaliação próprio. Separe 200 ou 300 casos reais, já rotulados, do seu domínio. Benchmark genérico não diz nada sobre os seus tickets.
2. Comparar com o que você já tem. Rode o mesmo conjunto no modelo atual (API externa ou LLM local) e no modelo servido pelo Ollaya. Meça acerto, latência no p95 e uso de memória.
3. Olhar a licença de cada modelo. A ferramenta ser open source não garante que todo peso distribuído por ela permita uso comercial. Isso pega muita gente.
4. Testar o comportamento na dúvida. O que acontece quando a entrada é ambígua? O modelo devolve alguma medida de confiança? Sem isso, você não consegue criar um fallback decente.
5. Ver quem mantém o projeto. Commits recentes, issues respondidas, releases com changelog. Ferramenta de infraestrutura abandonada vira dívida rápido.

O item 4 é o mais importante para mim. Decisão automatizada sem nível de confiança é perigosa. O padrão que eu uso é simples:

const { fila, confianca } = await decidir(texto)

if (confianca < 0.8) {
  return enviarParaHumano(texto)
}

return rotear(fila)

Se o modelo não te dá algo parecido com confianca, você está automatizando no escuro.

Onde o Ollaya não resolve seu problema

Vale ser honesto sobre os limites. Um runtime local de modelos de decisão não ajuda se:

• Você não tem dados para avaliar. Sem um conjunto rotulado, você não sabe se o modelo pequeno está acertando ou só parece estar.
• A decisão exige contexto aberto. Se para decidir o modelo precisa ler um contrato de 40 páginas e raciocinar sobre ele, um classificador compacto não é a ferramenta certa.
• Seu volume é baixo. Com 50 chamadas por dia, a conta da API externa é irrisória. Manter mais um serviço rodando pode custar mais em atenção do que economiza em dinheiro.
• Você roda em serverless puro. Modelo local pede um processo de vida longa com memória reservada. Em função que sobe e morre a cada request, isso vira cold start pesado.

Nenhum desses pontos é defeito do projeto. É só lembrar que "rodar local" é uma decisão de arquitetura, não um upgrade gratuito.

Vale ficar de olho no Ollaya?

Vale. Não porque a ferramenta vai mudar tudo amanhã, mas porque ela aposta numa direção que eu acho certa: usar o modelo do tamanho do problema. A indústria passou dois anos tentando resolver tudo com o maior modelo disponível. Agora a conta chegou, em latência, em custo e em dado sensível saindo da empresa.

Minha opinião direta: a maioria dos backends que usam IA hoje teria resultado igual ou melhor com um modelo pequeno, especializado e bem avaliado. O que faltava era uma forma tão simples de rodar esse tipo de modelo quanto o ollama run é para os LLMs. Se o Ollaya entregar isso com boa documentação e licenças claras, ele entra no meu kit.

Enquanto isso, a dica prática serve com ou sem Ollaya: isole cada decisão de IA atrás de uma função tipada, com saída fechada e um fallback para humano. Assim, trocar o motor vira detalhe. É assim que eu tenho estruturado os projetos que você encontra em meus projetos.

Quanto você já pagou em token para um modelo gigante responder "sim" ou "não"?

A maior parte da IA que vejo em produção não é chat. É decisão disfarçada de geração: classificar ticket, moderar comentário, escolher a próxima ação.

O Ollaya quer ser o Ollama dos modelos de decisão open source. Você baixa, roda local e chama por HTTP.

Quando a resposta cabe em um enum, o modelo não precisa caber em um datacenter.

Antes de confiar, eu testaria com dados reais do meu domínio, olharia a licença de cada modelo e exigiria um nível de confiança para mandar os casos duvidosos a um humano.

Escrevi no blog o roteiro completo e onde ele não resolve. O link está nos comentários.

#InteligenciaArtificial #OpenSource #Backend #LLM #DesenvolvimentoDeSoftware