Ollaya: un Ollama para modelos de decisión open source

¿Cuánto has pagado ya en tokens para que un modelo gigante responda "sí" o "no"? Esa pregunta resume bien por qué Ollaya me llamó la atención. El proyecto se presenta como "Ollama for open-source, Jev-style decision models". La idea es tener una forma sencilla de descargar y correr en local modelos de decisión open source, igual que Ollama hizo con los LLMs de chat. La fuente es el sitio oficial: ollaya.dev.

Voy a separar lo que promete la propuesta, dónde encaja en un backend de verdad y qué probaría antes de confiar en ella.

Qué es Ollaya, en una frase

Piensa en lo que Ollama hizo por ti. Antes, correr un modelo en local exigía descargar pesos a mano, pelearse con dependencias de Python y rezar para que la GPU colaborara. Después, quedó así:

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

Dos comandos y una API HTTP local. Ese fue el gran mérito de Ollama: convirtió un proyecto de investigación en una herramienta de desarrollo.

Ollaya quiere repetir esa experiencia con otro tipo de modelo. El foco no es conversar ni escribir texto. Es decidir. Un modelo de decisión recibe una entrada y devuelve una elección: aprobar o bloquear, qué cola, qué ruta, qué acción tomar después.

Sobre el término "Jev-style": es una etiqueta del propio proyecto. Antes de repetirlo por ahí, conviene leer la documentación y entender qué define exactamente. La jerga nueva es genial para el marketing y pésima para el code review.

Por qué tienen sentido los modelos de decisión pequeños

La mayor parte del uso de IA que veo en producción no es chat. Es decisión disfrazada de generación. Ejemplos que todos hemos escrito alguna vez:

• clasificar un ticket de soporte en "cobro", "bug" o "duda";
• decidir si un comentario va a moderación;
• elegir qué herramienta debe llamar un agente;
• marcar una transacción como sospechosa.

En todos estos casos, la salida útil cabe en pocos bytes. Aun así, mucha gente manda la petición a un modelo de frontera, paga miles de tokens de razonamiento y espera uno o dos segundos por la respuesta. Es como contratar a un cirujano para sacar una astilla del dedo.

Un modelo pequeño y especializado, corriendo en tu máquina o en tu servidor, gana en cuatro puntos:

• Latencia: sin ida y vuelta a una API externa.
• Costo: el costo marginal pasa a ser CPU o GPU que ya pagas.
• Privacidad: los datos del cliente no salen de tu infraestructura.
• Previsibilidad: una salida limitada a un conjunto cerrado de opciones es más fácil de probar.

Cuando la respuesta cabe en un enum, el modelo no necesita caber en un datacenter.

Cómo se ve esto en el código hoy

Para que tengas una referencia concreta, mira cómo resuelvo hoy la clasificación en local con Ollama. El truco es usar el campo format con un JSON Schema, que obliga a la salida a respetar la estructura:

type Cola = 'cobro' | 'bug' | 'duda'

async function clasificarTicket(texto: string): Promise<Cola> {
  const res = await fetch('http://localhost:11434/api/generate', {
    method: 'POST',
    body: JSON.stringify({
      model: 'qwen2.5:3b',
      prompt: `Clasifica el ticket de soporte:\n\n${texto}`,
      stream: false,
      format: {
        type: 'object',
        properties: { cola: { enum: ['cobro', 'bug', 'duda'] } },
        required: ['cola'],
      },
    }),
  })

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

Funciona. Pero fíjate en lo que está pasando: tomo un modelo de lenguaje generalista y lo ato con schema y prompt hasta que se comporta como clasificador. Es un LLM fingiendo ser un modelo de decisión.

Justo ese hueco es el que Ollaya intenta ocupar. En lugar de domar un modelo de chat, corres un modelo que ya nació para elegir. Si la herramienta ofrece una experiencia parecida a la de Ollama (descargar, correr, llamar por HTTP), el cambio en tu código es pequeño: cambia el endpoint, cambia el modelo, y la función clasificarTicket mantiene la misma firma.

Ese es el punto que más me interesa. Si tu lógica de decisión ya está aislada detrás de una función tipada, cambiar el motor de abajo se vuelve un detalle de infraestructura.

Qué probaría antes de llevarlo a producción

Un proyecto nuevo de IA open source merece curiosidad y desconfianza a partes iguales. Antes de cambiar nada en mi backend, seguiría esta guía:

1. Armar un conjunto de evaluación propio. Separa 200 o 300 casos reales de tu dominio, ya etiquetados. Un benchmark genérico no dice nada sobre tus tickets.
2. Comparar con lo que ya tienes. Corre el mismo conjunto en el modelo actual (API externa o LLM local) y en el modelo servido por Ollaya. Mide aciertos, latencia en el p95 y uso de memoria.
3. Revisar la licencia de cada modelo. Que la herramienta sea open source no garantiza que todos los pesos que distribuye permitan uso comercial. Esto atrapa a mucha gente.
4. Probar el comportamiento ante la duda. ¿Qué pasa cuando la entrada es ambigua? ¿El modelo devuelve alguna medida de confianza? Sin eso, no puedes crear un fallback decente.
5. Ver quién mantiene el proyecto. Commits recientes, issues respondidas, releases con changelog. Una herramienta de infraestructura abandonada se vuelve deuda muy rápido.

El punto 4 es el más importante para mí. Una decisión automatizada sin nivel de confianza es peligrosa. El patrón que uso es simple:

const { cola, confianza } = await decidir(texto)

if (confianza < 0.8) {
  return enviarAHumano(texto)
}

return enrutar(cola)

Si el modelo no te da algo parecido a confianza, estás automatizando a ciegas.

Dónde Ollaya no resuelve tu problema

Conviene ser honesto sobre los límites. Un runtime local de modelos de decisión no ayuda si:

• No tienes datos para evaluar. Sin un conjunto etiquetado, no sabes si el modelo pequeño acierta o solo lo parece.
• La decisión exige contexto abierto. Si para decidir el modelo necesita leer un contrato de 40 páginas y razonar sobre él, un clasificador compacto no es la herramienta adecuada.
• Tu volumen es bajo. Con 50 llamadas al día, la factura de la API externa es irrisoria. Mantener otro servicio corriendo puede costar más en atención de lo que ahorra en dinero.
• Corres en serverless puro. Un modelo local pide un proceso de larga duración con memoria reservada. En una función que arranca y muere en cada request, eso se convierte en un cold start pesado.

Ninguno de estos puntos es un defecto del proyecto. Solo hay que recordar que "correr en local" es una decisión de arquitectura, no una mejora gratuita.

¿Vale la pena seguirle la pista a Ollaya?

Sí. No porque la herramienta vaya a cambiarlo todo mañana, sino porque apuesta por una dirección que creo correcta: usar un modelo del tamaño del problema. La industria pasó dos años intentando resolverlo todo con el modelo más grande disponible. Ahora llegó la factura, en latencia, en costo y en datos sensibles saliendo de la empresa.

Mi opinión directa: la mayoría de los backends que usan IA hoy tendrían un resultado igual o mejor con un modelo pequeño, especializado y bien evaluado. Lo que faltaba era una forma de correr este tipo de modelo tan simple como ollama run lo es para los LLMs. Si Ollaya lo logra con buena documentación y licencias claras, entra en mi kit.

Mientras tanto, el consejo práctico sirve con o sin Ollaya: aísla cada decisión de IA detrás de una función tipada, con salida cerrada y un fallback a un humano. Así, cambiar el motor se vuelve un detalle. Así estructuro los proyectos que encuentras en mis proyectos.

¿Cuánto has pagado ya en tokens para que un modelo gigante responda "sí" o "no"?

La mayor parte de la IA que veo en producción no es chat. Es decisión disfrazada de generación: clasificar tickets, moderar comentarios, elegir la siguiente acción.

Ollaya quiere ser el Ollama de los modelos de decisión open source. Lo descargas, lo corres en local y lo llamas por HTTP.

Cuando la respuesta cabe en un enum, el modelo no necesita caber en un datacenter.

Antes de confiar en él, lo probaría con datos reales de mi dominio, revisaría la licencia de cada modelo y exigiría un nivel de confianza para mandar los casos dudosos a un humano.

Escribí en el blog la guía completa y dónde no resuelve el problema. El enlace está en los comentarios.

#InteligenciaArtificial #OpenSource #Backend #LLM #DesarrolloDeSoftware