MLOps

Los modelos son software. Operarlos como tal.

El piloto funcionó; producción es otro deporte. Construimos la capa de operación —despliegue, monitoreo, evaluación, reentrenamiento— que mantiene honestos a los modelos y a las aplicaciones con LLM después del lanzamiento.

Qué construimos

  • Pipelines de despliegue para modelos y aplicaciones con LLM
  • Monitoreo en producción: calidad, drift, latencia y costo
  • Evaluación como rutina, no como ceremonia
  • Ciclos de actualización y reentrenamiento con revisión humana donde importa

Pruebas

Nuestra propia contratación

El agente que escribe los perfiles de nuestros candidatos lleva un año en producción sin cambios: instrumentado, evaluado sobre su salida real y dejado en paz porque el log se mantuvo en silencio.

Leer la nota
Un año en producción
Sin cambios necesarios

Cuándo nos buscan los equipos

  • Un modelo que funciona en un notebook que nadie se atreve a desplegar
  • Calidad que se degrada en silencio hasta que lo nota un cliente
  • Costos de IA que sorprenden a finanzas todos los meses

Cómo lo construimos

  1. Línea base y métricas

    definir qué significa "bueno" antes de tocar nada

  2. Pipeline de despliegue

    los modelos y las aplicaciones con LLM se liberan como software

  3. Monitorear lo que importa

    calidad, drift, latencia, costo

  4. Ciclo de actualización

    reentrenamiento y cambios de prompt con revisión humana

Qué se degrada en silencio

Nada en producción se rompe a los gritos. Deriva:

Calidad

las entradas cambian y el modelo no. Una versión del producto cambia lo que dicen los tickets; una temporada cambia lo que ve la cámara. La precisión decae mientras el dashboard sigue en verde, porque nadie está comparando las salidas contra una muestra de la verdad cada semana.

Prompts y versiones

un prompt editado para arreglar un caso rompe otros tres; un proveedor actualiza un modelo bajo el mismo nombre. Sin un conjunto de evaluación que corra en cada cambio, "parece estar bien" es la única señal, y no es una señal.

Latencia

una funcionalidad que respondía en dos segundos ahora tarda seis, un paso de recuperación a la vez. Los usuarios dejan de usarla antes de que alguien abra un ticket.

Costo

el precio por llamada escala con el éxito. La funcionalidad que funciona es la que sorprende a finanzas, y el arreglo es un presupuesto por tenant que el producto respeta, no una planilla a destiempo.

El piloto prueba que el modelo puede funcionar. Operarlo es probar, cada semana, que sigue funcionando.

Cómo se ve operarlo bien

Todo modelo o aplicación con LLM que operamos tiene las mismas cuatro cosas atadas, y están atadas antes del lanzamiento, no después del primer incidente: un conjunto de evaluación de casos reales con respuestas conocidas, que corre automáticamente en cada cambio de prompt, de modelo o de datos; un pipeline de despliegue donde una versión del modelo se libera como una liberación de código —revisada, etiquetada, reversible—; monitoreo sobre las cuatro cosas que se degradan, con umbrales decididos junto al equipo que va a recibir la alerta; y un ciclo de actualización donde el reentrenamiento o un cambio de prompt pasa por una persona antes de llegar a producción.

La verdad poco glamorosa es que casi todo esto es disciplina ordinaria de software aplicada a un componente que resulta ser probabilístico. Los equipos que ya liberan software bien tienen la mayor parte del camino hecho; lo que suele faltar es el conjunto de evaluación: el único artefacto que nadie construye en el piloto y que todos necesitan en producción.

Funciona bien con

Y todo modelo que construimos nosotros, o ustedes.

Preguntas frecuentes

  • Solo usamos APIs de LLM: ¿igual necesitamos esto?

    Sí: los prompts, las versiones, las evaluaciones y los costos también se degradan en silencio.

  • ¿Pueden operar modelos que construyó nuestro equipo?

    Caso común: primero instrumentamos, después mejoramos.

  • ¿Cuánto cuesta operar IA?

    Depende del volumen: la práctica es hacer el costo visible y revisarlo como código, para que la respuesta nunca sea una sorpresa.

  • ¿Qué es un conjunto de evaluación y por qué todo vuelve a él?

    Entre unas decenas y unos cientos de entradas reales con la respuesta que daría una persona competente, guardadas junto al código y ejecutadas en cada cambio. Es la única forma de saber si un cambio mejoró el sistema o movió las fallas a un lugar donde no estabas mirando. Sin él, cada edición de un prompt es una corazonada.

  • ¿Cuánto cuesta operar el monitoreo?

    Una fracción del costo del modelo: el muestreo que detecta el drift compara una porción de las salidas contra la verdad, no cada llamada. Lo caro no es el monitoreo: es el cliente que se da cuenta primero.

  • ¿Trabajan con modelos de pesos abiertos en nuestra infraestructura?

    Sí, y la capa de operación tiene la misma forma en cualquiera de los dos casos: versiones, evaluación, monitoreo, un pipeline reversible. Lo que cambia es que el costo se vuelve una decisión de capacidad en lugar de una por llamada, y que el modelo se puede actualizar según tu calendario y no el de un proveedor.

Que tu IA siga siendo honesta en producción.