Del prototipo a producción: un pipeline de LLMOps

El prototipo de IA suele quedar listo en una semana. La distancia entre ese prototipo y algo que corre en producción con usuarios reales es donde mueren la mayoría de los proyectos, y rara vez es culpa del modelo.

Qué cambia cuando no entrenas el modelo

La disciplina de MLOps se construyó alrededor de un pipeline que termina en entrenamiento y despliegue de modelo. Buena parte de los proyectos de IA generativa no entrena nada: consume un modelo por API.

Eso elimina algunas etapas y crea otras. Desaparece el reentrenamiento periódico. Aparecen la gestión de prompts, la gestión de contexto, el control de costo por llamada y la dependencia de un proveedor que actualiza el modelo sin pedir permiso.

Lo que sigue valiendo del MLOps clásico es la columna vertebral: versionar todo lo que influye en el resultado, automatizar el camino a producción y monitorear de forma continua después. La guía de MLOps de Google Cloud describe esa progresión en niveles de madurez, y casi toda aplica aquí.

Versiona lo que de verdad cambia la respuesta

En una aplicación con LLM, el artefacto no es solo el código. La salida cambia si cambia cualquiera de estos:

• el prompt, incluidas las instrucciones de sistema;
• el modelo y su versión;
• los parámetros de generación;
• la base de conocimiento indexada y la configuración de recuperación;
• las definiciones de herramientas disponibles.

Si alguno vive fuera del control de versiones, no puedes reproducir un incidente. Un prompt en una variable de entorno editada desde un panel es el error más común, y el más caro el día en que la respuesta empeore sin que nadie haya desplegado.

El entrelazamiento es el problema difícil

Un estudio de caso de Microsoft sobre ingeniería de software para aprendizaje automático identificó una diferencia estructural con el software tradicional: los componentes de IA son más difíciles de tratar como módulos aislados, porque quedan entrelazados de formas no obvias.

En la práctica eso significa que el cambio que parece local no lo es. Ajustar el prompt para mejorar un tipo de pregunta degrada otro. Cambiar el modelo de embedding invalida el índice entero. Mover la temperatura cambia la tasa de invocación de herramientas.

Por eso la suite de evaluación tiene que correr sobre el conjunto completo de escenarios en cada cambio, y no solo sobre el escenario que motivó el cambio.

Un pipeline mínimo que ya es serio

Cuatro etapas cubren la mayor parte del riesgo:

1. Desarrollo. Prompts y configuración versionados junto al código. Evaluación local rápida antes de abrir el PR.
2. Integración. Evaluación determinista en CI, más el conjunto dorado. Un fallo bloquea el merge.
3. Despliegue progresivo. La versión nueva detrás de un flag, liberada a una fracción del tráfico, comparando calidad y costo contra la versión actual.
4. Observación. Registro de entrada, salida, versión de prompt, latencia, costo y feedback del usuario, con muestreo para revisión humana.

La etapa 3 es la que más falta en los proyectos que veo, y es la que convierte un error grande en uno pequeño.

El costo es un requisito, no un reporte

En un sistema tradicional, el costo aparece en la factura a fin de mes. En una aplicación con LLM, el costo es función directa de decisiones de diseño: tamaño del contexto, cantidad de llamadas por interacción, modelo elegido por ruta.

Trata el costo por interacción como un SLO. Define el techo aceptable, mídelo en producción por ruta y alerta cuando se supere. Sin eso, la optimización solo ocurre después del susto en la factura, y ahí suele hacerse con prisa y sin evaluación, degradando la calidad.

El fallback tiene que existir antes de necesitarlo

Depender de una API externa significa indisponibilidad fuera de tu control. Define el comportamiento de antemano: respuesta en caché, modelo alternativo, degradación explícita para el usuario o cola para procesar después.

Elegir eso durante el incidente es como elegir el plan de rollback durante el rollback.

Qué significa esto para tu equipo

Empieza sacando el prompt de cualquier lugar que no sea el repositorio. Es el cambio más barato con mayor efecto sobre la reproducibilidad.

Después, agrega el despliegue progresivo. No necesita una plataforma sofisticada: un flag de configuración, una fracción de tráfico y un panel comparando calidad y costo entre versiones ya alcanza.

Y define el techo de costo por interacción junto al requisito funcional, en la misma conversación. Sale más barato que descubrir tres meses después que la arquitectura elegida no cierra la cuenta.