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

Hoy, para aprobar o rechazar un pedido con IA, mucha gente levanta un LLM de 7 mil millones de parámetros, escribe un prompt de 40 líneas y reza para que el JSON vuelva válido. Ollaya aparece justamente para atacar ese exceso. La propuesta cabe en una frase: ser el "Ollama de los modelos de decisión open source". Descargas un modelo hecho para elegir, lo corres en local y recibes una decisión en lugar de un texto.

El nombre parece el primo de Ollama en el almuerzo del domingo, y es a propósito. La idea es heredar la experiencia que convirtió a Ollama en estándar: un comando para descargar, un comando para correr, una API local para consumir.

Qué es Ollaya, en la práctica

Ollama resolvió un problema molesto: correr un LLM en tu máquina sin pelearte con CUDA, cuantización y formatos de pesos. Escribes ollama run llama3 y listo. Por debajo, levanta un servidor en localhost:11434 que cualquier app puede llamar.

Ollaya aplica el mismo empaque a otra categoría de modelo. Un modelo de decisión es aquel que recibe un contexto y devuelve una elección dentro de un conjunto cerrado de opciones. Aprobar o rechazar. Enrutar al equipo A, B o C. Llamar a la herramienta X o no llamar a nada. La salida es estructurada por naturaleza, y no un párrafo que tienes que interpretar después.

El sitio describe estos modelos como "Jev-style". Es jerga del propio proyecto. Antes de adoptarlo, lee la documentación con calma para entender exactamente qué promete el término, porque un nombre bonito no sustituye una especificación.

Por qué los modelos de decisión importan a quien programa

Piensa en cuántas decisiones pequeñas toma tu backend al día. Clasificar un ticket de soporte. Marcar una transacción como sospechosa. Decidir si un comentario va a moderación. Elegir cuál de los cinco endpoints internos debe llamar un agente.

La solución de moda pasó a ser "tíralo a un LLM". Funciona, pero mira cómo queda el código con Ollama hoy:

const res = await fetch('http://localhost:11434/api/generate', {
  method: 'POST',
  body: JSON.stringify({
    model: 'llama3',
    prompt: `Clasifica el ticket en "billing", "bug" u "otro".
Responde solo 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, llanto
}

Fíjate en lo que está pasando. Usas un generador de texto para producir una sola palabra. Pagas latencia de generación, pagas la memoria de un modelo enorme y encima tienes que validar con Zod porque el modelo puede inventar una categoría "finanzas" que no existe.

Un modelo de decisión invierte esto. Las opciones forman parte del contrato, no del prompt. El modelo no tiene cómo responder fuera de ellas.

Si la respuesta cabe en un enum, no necesitas un modelo que escribe redacciones.

Qué cambia en tu código y en tu flujo

Si Ollaya cumple lo que promete, el código de arriba se convierte en algo parecido a esto. El formato de abajo es ilustrativo, revisa la API real en la doc del proyecto:

type Decision = {
  eleccion: 'billing' | 'bug' | 'otro'
  confianza: number
}

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

switch (decision.eleccion) {
  case 'billing': return colaFinanzas.add(ticket)
  case 'bug': return colaIngenieria.add(ticket)
  default: return colaGeneral.add(ticket)
}

Aquí aparecen tres ganancias concretas:

• Tipado de verdad. TypeScript conoce todas las salidas posibles. El switch queda exhaustivo y el compilador se queja si olvidas un caso.
• Confianza como número. Con un score, defines una regla simple: por debajo de 0.7, lo mandas a un humano. Con texto libre, eso se vuelve adivinanza.
• Costo predecible. Correr en local significa cero cobro por token y ningún dato del cliente saliendo de tu servidor.

Este último punto pesa más de lo que parece para quien trabaja con datos personales. Enviar el texto de un ticket con documento de identidad y dirección a una API externa solo para decidir una cola es el tipo de cosa que le da dolor de cabeza al equipo legal.

Cuáles son los riesgos de adoptarlo ahora

Aquí entra la parte honesta. Un proyecto nuevo tiene cara de proyecto nuevo, y vale la pena sopesar algunos puntos antes de entusiasmarse.

El catálogo es el producto. Ollama se hizo fuerte porque tiene cientos de modelos listos. Un runtime de modelos de decisión solo vale si existen buenos modelos para tus casos. Si el catálogo tiene tres modelos genéricos, vas a terminar entrenando el tuyo, y ahí el problema es otro.

Sin benchmark, no pasó. La precisión de un modelo de decisión se mide, no se siente. Busca números publicados por modelo: accuracy, dataset usado, matriz de confusión. Si no los hay, vas a tener que medirlo tú con tus propios datos.

La licencia de cada modelo. Que el runtime sea open source no garantiza que los pesos sean libres para uso comercial. Lee la licencia de cada modelo, uno por uno. Ya vi un proyecto ir a producción con un modelo "open" que prohibía el uso comercial en la letra pequeña.

La decisión automatizada tiene reglas. El artículo 20 de la LGPD, la ley brasileña de protección de datos, le da al titular el derecho a pedir la revisión de decisiones tomadas solo con base en tratamiento automatizado. Otras leyes, como el RGPD europeo, tienen reglas parecidas. Si el modelo rechaza un crédito o bloquea una cuenta, necesitas poder explicar el porqué y ofrecer revisión humana. Guarda el input, la versión del modelo, la elección y la confianza de cada decisión. Esto no es opcional.

Cómo probar Ollaya sin romper producción

Mi recomendación es el modo sombra. No cambias nada. Corres el modelo en paralelo con la regla actual y solo registras cuando los dos no coinciden.

const actual = reglaActual(ticket)

ollaya
  .decide({ model: 'ticket-router', input: ticket.texto, options: CATEGORIAS })
  .then((d) => {
    if (d.eleccion !== actual) {
      log.info('divergencia', { id: ticket.id, actual, modelo: d.eleccion, confianza: d.confianza })
    }
  })
  .catch((err) => log.warn('ollaya falló', err))

return actual

Déjalo corriendo dos semanas. Después toma 100 divergencias y revísalas a mano. Si el modelo acertó la mayoría de las veces en que no coincidió con la regla, tienes un argumento real para migrar. Si se equivocó, te ahorraste un incidente.

Fíjate en que la llamada no bloquea la respuesta y que el fallo del modelo no tumba nada. En modo sombra, el modelo nunca puede ser el motivo de un error 500.

Un detalle de infraestructura: corre el servidor de Ollaya como un servicio separado, con healthcheck, igual que harías con Ollama. No levantes el modelo dentro del proceso de tu API Node. Cuando consuma demasiada memoria, quieres reiniciar el modelo, no el backend entero.

¿Vale la pena seguirle la pista?

Sí, y el motivo no es el modelo en sí. Ollama no ganó porque tuviera los mejores pesos. Ganó porque convirtió "correr IA en local" en algo que un dev hace en una tarde. Un modelo que nadie logra correr en cinco minutos, en la práctica, no existe.

Mi opinión: pasamos dos años usando LLMs gigantes como martillo para todo clavo, incluso para clavos que eran un if con confianza. Los modelos de decisión pequeños, locales y tipados son el camino más sensato para buena parte de esos casos. Si Ollaya va a ser la herramienta que consolide esto, todavía no se puede saber. Depende del catálogo, de la comunidad y de benchmarks que el proyecto aún tiene que mostrar.

Por ahora, yo lo haría así: lo instalas, lo corres en un caso de bajo riesgo en modo sombra y mides. Si los números cuadran, ganas menor latencia, costo cero por llamada y un código más fácil de leer. Si no cuadran, perdiste una tarde y ganaste un dataset de divergencias que ya vale oro.

Si quieres ver cómo aplico IA en proyectos reales, sin hype, échale un vistazo a mis proyectos.

Hay devs levantando un LLM de 7 mil millones de parámetros solo para devolver una palabra.

Clasificar un ticket, aprobar un pedido, elegir una cola. Si la respuesta cabe en un enum, no necesitas un modelo que escribe redacciones.

Ollaya quiere ser el "Ollama de los modelos de decisión": lo descargas, corre en local y recibes una elección tipada con score de confianza, en lugar de un JSON que rezas para que llegue válido.

Ganancia real: switch exhaustivo en TypeScript, costo cero por token y ningún dato personal saliendo de tu servidor.

Pero un proyecto nuevo pide cautela: catálogo, benchmark, licencia de cada modelo y el artículo 20 de la LGPD.

Mi sugerencia es probarlo en modo sombra durante dos semanas y dejar que los números decidan.

Escribí el paso a paso completo en el blog. ¿Alguna vez usaste un LLM para algo que era solo un if?

#InteligenciaArtificial #TypeScript #OpenSource #LGPD #DesarrolloDeSoftware