Una aplicación clásica cambia cuando su código o su configuración evoluciona. Una aplicación generativa también cambia cuando el proveedor actualiza un modelo, se modifica un prompt, un documento entra en el índice o una herramienta expone un nuevo esquema. Sin trazabilidad, dos respuestas diferentes pueden parecer inexplicables.
El LLMOps reúne las prácticas que permiten evaluar, desplegar, observar y hacer evolucionar estos sistemas. Extiende el DevOps y el MLOps con las especificidades de los modelos generativos, del RAG, de los agentes y del juicio cualitativo.
Definir la unidad de producción
El producto no es solo un modelo. Incluye:
- aplicación ;
- instrucciones ;
- modelo y parámetros;
- fuentes ;
- tubería de ingestión ;
- índice ;
- herramientas;
- políticas;
- formato de salida ;
- evaluaciones;
- infraestructura.
Una versión entregada debe identificar este conjunto. Cambiar un solo elemento puede modificar la calidad, el costo o la seguridad.
Los nueve objetos a versionar
1. Código
La orquestación, la API, la interfaz y los posprocesamientos siguen el ciclo de software habitual.
2. Indicaciones e instrucciones
Se almacenan como código, se revisan, prueban y se vinculan a los casos de evaluación.
3. Modelos
Proveedor, identificador exacto, fecha, parámetros y opciones están registrados. Un alias « latest » no es suficiente para reproducir.
4. Datos fuente
Los documentos y registros poseen identificador, versión y estado.
5. Canal de ingestión
Extractor, segmentación, embeddings, metadatos y filtros están versionados.
6. Índice
Una versión de índice corresponde a fuentes y un flujo de trabajo. Puede coexistir con la anterior durante una validación.
7. Herramientas
El esquema, el comportamiento, los permisos y la versión de las API son conocidos.
8. Políticas
Enrutamiento, rechazos, límites, aprobaciones y reglas de datos están versionados.
9. Evaluaciones
Los juegos de casos, secciones, jueces y umbrales evolucionan con el producto.
Rastreo de una respuesta de IA hasta la versión del código, del prompt, del modelo, del índice, de las fuentes, de las herramientas y de las políticas.
Entornos
Desarrollo, prueba, preproducción y producción deben aislar datos, claves, cuotas y herramientas. Los entornos no productivos utilizan conjuntos permitidos y acciones simuladas.
Los modelos externos pueden diferir según el entorno en cuanto al costo, pero la validación final debe utilizar la configuración objetivo. Las desviaciones están documentadas.
Una cadena de suministro
Un cambio desencadena:
- controles estáticos y esquemas;
- pruebas deterministas ;
- evaluaciones rápidas;
- pruebas de seguridad ;
- comparación con la línea base;
- revista ;
- despliegue progresivo;
- observación ;
- promoción o retorno.
Los umbrales críticos bloquean. Una excepción tiene un propietario y una duración.
Desplegar progresivamente
Se puede activar una nueva configuración para un equipo, una parte del tráfico o un tipo de tarea. El enrutamiento conserva la versión utilizada para comparar.
El canario satisface la calidad de proxy, errores, latencia, costo y retroalimentación. Para los usos de riesgo, se activa temporalmente una revisión humana adicional.
El rollback debe incluir el modelo, el prompt, el índice y las herramientas compatibles, no solo el código.
Dibujar sin guardar todo
Un rastro útil contiene:
- identificador de solicitud;
- usuario o seudónimo según necesidad;
- versiones ;
- etapas y duraciones;
- herramientas;
- documentos identificados;
- tokens y coste;
- errores;
- resultado de la validación;
- retroalimentación.
No conserva automáticamente indicaciones completas, documentos sensibles o razonamiento privado. Se definen la minimización, el enmascaramiento, los derechos y la retención.
Observabilidad técnica
Seguir la disponibilidad, errores, tiempos de espera, cuotas, colas, tiempo de cada etapa, tamaño del contexto, caché y recursos. Las trazas distribuidas conectan API, búsqueda, modelo y herramientas.
Los objetivos de servicio se centran en el recorrido: tiempo hasta el resultado, tasa de tarea completada y modo degradado.
Observabilidad de calidad
La calidad no se mide únicamente por registros técnicos. Señales incluyen:
- rechazo ;
- ausencia de fuente;
- error de formato;
- correcciones ;
- escaladas ;
- herramientas rechazadas;
- respuestas abandonadas ;
- caso centinelas;
- muestras revisadas.
Los comentarios se categorizan y se añaden al conjunto de regresión después de la validación.
Costo
El seguimiento asigna costo y tokens por equipo, caso de uso, versión y etapa. Los presupuestos activan alerta, enrutamiento o límite.
El costo por solicitud se complementa con el costo por tarea exitosa y el costo de la validación humana. Una reducción de precio no justifica una disminución de calidad.
Linaje
Para una respuesta dada, el equipo debe encontrar:
- código ;
- prompt ;
- modelo ;
- índice ;
- fuentes ;
- herramientas;
- política ;
- resultado;
- evaluaciones asociadas.
Esta trazabilidad permite una investigación, una reproducción aproximada y una notificación dirigida si una fuente fuera errónea. No requiere almacenar una cadena de pensamiento.
Gestión de cambios de proveedor
Un proveedor puede modificar un modelo, límites o una tarifa. Las versiones fijadas, pruebas periódicas y alertas contractuales reducen las sorpresas.
Una capa de enrutamiento permite probar otro modelo. Las diferencias de formatos y capacidades permanecen explícitas en lugar de ocultas.
Gestión de índices
Un nuevo embedding o segmentación a menudo requiere una reconstrucción. El índice se crea junto al antiguo, se alimenta, se evalúa y luego se activa. La reversión sigue siendo posible.
Se hace un seguimiento de los errores de ingestión, retrasos y eliminaciones. Una fuente no indexada no debe pasar desapercibida.
Gestión de solicitudes
Los prompts tienen un propietario, una intención, pruebas y una documentación de las variables. Evitan los secretos y los datos codificados.
Un estudio de prompts puede facilitar la edición, pero la fuente de la verdad sigue estando versionada y revisada. Los cambios en producción sin historial están prohibidos.
Gestión de incidentes de IA
Un incidente puede ser:
- fuga ;
- acción no autorizada ;
- respuesta peligrosa;
- modelo no disponible;
- costo anormal;
- deriva de calidad;
- fuente caducada;
- índice incompleto.
El plan prevé corte, modo degradado, revocación, análisis, corrección, evaluación y comunicación. Los responsables de producto, seguridad, datos y técnica colaboran.
RACI y propiedad
Cada sistema tiene:
- propietario del producto;
- responsable técnico;
- propietarios de los datos;
- seguridad;
- conformidad;
- soporte ;
- presupuesto ;
- decisor de lanzamiento.
Una plataforma central puede proporcionar los cimientos, mientras que cada caso de uso asume sus datos y su calidad.
Empezar pequeño
Un socle mínimo comprende control de versiones, conjunto de evaluación, trazas correlacionadas, seguimiento de costos, despliegue progresivo y reversión. Una plataforma compleja solo es necesaria a medida que los equipos y los usos se multiplican.
Las herramientas deben servir al proceso, no reemplazarlo. Una convención simple y automatizada vale más que un catálogo sofisticado que no se mantiene.
Explotar la IA como un producto
El LLMOps transforma una configuración cambiante en un producto observable. Permite saber qué ha cambiado, qué ha mejorado y cómo volver atrás.
Partitech puede diseñar el pipeline, las evaluaciones, los rastros, la gestión de versiones y la explotación de los RAG y agentes. El objetivo es entregar con frecuencia sin perder el control de la calidad, del costo y del riesgo.
Hablemos de su proyecto
Industrialice sus aplicaciones de IA y su observabilidad con Partitech. Contacte a Partitech.