Despliegues graduales de IA: cómo lanzar cambios de modelo, prompt o herramienta sin convertir a los usuarios en el experimento

Un cambio de IA no es solo cambiar un modelo

En una aplicación con IA en producción, una modificación puede estar en el identificador o versión del modelo, el prompt de sistema, los ejemplos incluidos, los parámetros de generación, la cadena de orquestación, la política de recuperación de información, el índice consultado, la definición de una herramienta externa, los permisos concedidos a esa herramienta o la lógica de reintentos. Aunque el cambio parezca local, puede alterar la respuesta final, el coste, la latencia, el comportamiento de seguridad y la probabilidad de ejecutar una acción externa.

La unidad que se debe desplegar y evaluar no es necesariamente el modelo aislado. En una aplicación generativa, el comportamiento resulta de la combinación de modelo, instrucciones, contexto recuperado, herramientas y reglas de aplicación. Por ejemplo, sustituir un modelo en un asistente con recuperación puede modificar cómo interpreta las instrucciones y cómo utiliza los documentos recuperados. Cambiar el esquema de una herramienta puede hacer que una respuesta antes válida deje de ser ejecutable aunque el texto generado parezca correcto.

Por ello, el objetivo de un despliegue gradual no es demostrar que una versión nueva funciona en algunos casos. Es reducir la incertidumbre antes de exponer a una población amplia a una regresión. El equipo formula una hipótesis verificable, compara la variante con una línea base congelada, limita inicialmente el radio de impacto y toma decisiones predefinidas con datos operativos y evaluación de calidad.

Esta guía se ocupa del cambio controlado una vez que la aplicación ya opera. No reemplaza el diseño de un conjunto de evaluación, la instrumentación inicial de observabilidad ni la selección estratégica de un proveedor o de un modelo. Es útil como complemento de los recursos de aprendizaje, comparación y descubrimiento disponibles en las rutas internas learn.index, compare.index y discover.index.

Antes de mover tráfico: hipótesis, línea base y tipos de métricas

Un canary no corrige una decisión mal planteada. Antes de activarlo, describa el cambio de forma concreta: qué artefactos cambian, qué se mantiene fijo, qué población podría verse afectada y qué resultado se espera mejorar. Una hipótesis útil evita expresiones como «el modelo será mejor». En su lugar: «la variante B aumentará la tasa de resolución validada en consultas de facturación sin elevar la tasa de llamadas erróneas a la herramienta ni superar el presupuesto de latencia».

Después, congele una línea base. Registre una ventana temporal, el tráfico incluido, las versiones exactas de la configuración y los indicadores observados. Si se comparan datos de periodos con demanda, mezcla de casos o disponibilidad de herramientas muy diferentes, atribuir un resultado al cambio será incierto. Cuando sea posible, asigne control y tratamiento simultáneamente para reducir esa diferencia; cuando no sea posible, declare la limitación y use una interpretación prudente.

Clasifique las métricas en tres grupos. Las métricas de promoción determinan si puede crecer el tráfico: por ejemplo, éxito validado por tarea, cumplimiento de un formato o exactitud revisada en una muestra. Las métricas de vigilancia detectan efectos que no deberían empeorar de forma relevante, como latencia de cola, coste por tarea completada, abandono o tasa de fallback. Las métricas de reversión son límites de seguridad, privacidad, acciones incorrectas o degradación operativa que obligan a parar sin esperar a que termine el análisis estadístico.

No use una media global como único criterio. Una mejora agregada puede ocultar un deterioro grave en consultas largas, idiomas menos frecuentes, cuentas con permisos limitados o tareas que invocan una herramienta. Desglose las métricas por segmento de uso, complejidad, ruta de herramienta y resultado. La necesidad de participación representativa y la cautela al extrapolar resultados de evaluación al contexto real son especialmente relevantes en IA generativa.

Clasifique el cambio antes de escoger el mecanismo

La clasificación no pretende certificar que un cambio es seguro; sirve para decidir cuánta evidencia adicional se necesita. Una modificación menor conserva el modelo, el contrato de entrada y salida, las herramientas, los permisos y la fuente de contexto, y modifica un aspecto acotado, como una instrucción de formato. Puede avanzar con replay offline, una muestra de revisión y un canary pequeño si no toca acciones sensibles.

Un cambio comparable sustituye un componente, pero conserva una tarea, una interfaz, un conjunto de permisos y una definición de éxito equivalentes. Un modelo alternativo para resumir documentos, con el mismo prompt, recuperación y salida estructurada, puede entrar en esta categoría. Aun así, el equipo debe medir coste, latencia, variación y fallos de formato; la equivalencia es una hipótesis que debe contrastarse, no una propiedad declarada por el proveedor.

Un cambio que exige evaluación nueva modifica lo que el sistema puede hacer, la información a la que accede o el daño potencial. Incluye añadir una herramienta que crea tickets, ampliar permisos, cambiar a un corpus con datos distintos, permitir acciones irreversibles, alterar la población atendida o introducir una política de recuperación que transforma material sensible. En estos casos, el tráfico aleatorizado puede ser insuficiente o inadecuado. Puede requerirse aprobación específica, pruebas controladas sin efectos externos y revisión de los requisitos aplicables.

La documentación de los artefactos es parte de la clasificación. Para cada paquete conserve el identificador de modelo, prompt y plantillas, parámetros de inferencia, versión de código, cadena de orquestación, configuración de recuperación e índice o instantánea del corpus, definición y versión de cada herramienta, permisos, esquemas de entrada y salida, política de reintentos y reglas del feature flag. Sin esta información no es posible reproducir de forma razonable una respuesta ni confirmar qué se revirtió.

Elija replay, shadow, canary, A/B o despliegue por segmentos

El replay offline vuelve a ejecutar solicitudes históricas, con las debidas restricciones de privacidad, contra la variante candidata. Es barato y reproducible para comparar formato, recuperación, coste estimado y decisiones de enrutamiento. No reproduce perfectamente la interacción real, los cambios de estado ni el comportamiento de herramientas externas. Debe usarse para descartar fallos evidentes, no para declarar que el impacto en producción está demostrado.

En shadow mode, la variante recibe una copia de solicitudes reales, pero su resultado no se muestra al usuario ni ejecuta efectos externos. Es apropiado para observar latencia, coste, estabilidad de salida, selección de herramientas y divergencia respecto al sistema activo. Para conservar seguridad, las llamadas a herramientas deben simularse, redirigirse a un entorno aislado o bloquearse. El shadow deja de ser representativo si el usuario habría aportado una aclaración tras ver la respuesta, si la variante necesita un contexto que no recibe en paralelo o si una herramienta depende de estado mutable creado durante la conversación.

Un canary dirige una fracción limitada de tráfico a la versión nueva y la incrementa por fases si se cumplen verificaciones. Es útil cuando la respuesta puede presentarse al usuario con un riesgo acotado y existe un camino de reversión rápido. El tamaño inicial no debe fijarse por costumbre: debe permitir detectar señales operativas relevantes dentro de un límite de exposición aceptable. La duración debe cubrir patrones representativos, incluidas horas de alta carga, sin mantener el experimento abierto más tiempo del necesario ante una señal adversa.

Una prueba A/B puede estimar diferencias entre variantes si la asignación es estable, las poblaciones son comparables y la métrica está bien definida. No es sinónimo de canary: un canary prioriza limitar riesgo durante la entrega, mientras que un A/B busca atribuir una diferencia a una variante. Pueden combinarse, pero no hace falta forzar aleatorización cuando hay restricciones éticas, regulatorias o de seguridad. El despliegue por segmentos, por su parte, permite empezar por casos de menor criticidad o usuarios internos, pero puede introducir sesgo: un buen resultado allí no garantiza el mismo resultado en el resto de la población.

Diseñe un canary que produzca evidencia y limite el daño

Antes de comenzar, defina quién puede iniciar, pausar, promover y revertir. Establezca una guardia responsable durante cada fase y un canal de escalado. Cada incremento de tráfico debe tener una ventana de observación, comprobaciones automáticas y una revisión explícita de las señales relevantes. No promueva automáticamente solo porque no haya alertas: la ausencia de una alerta puede reflejar una métrica mal instrumentada, volumen insuficiente o falta de cobertura de un segmento importante.

La asignación debe ser estable para una misma unidad, como cuenta, organización o conversación, salvo que haya una razón documentada para usar otra. Cambiar de variante en medio de una conversación complica la experiencia y el diagnóstico. Asimismo, evite incluir inicialmente poblaciones vulnerables, procesos de alto impacto o cuentas cuya configuración haga imposible una reversión limpia. Esa exclusión reduce exposición, pero también reduce representatividad; el plan debe indicar cuándo y bajo qué controles se evaluarán esos segmentos.

Defina límites de gasto y capacidad. Una variante puede generar respuestas más largas, efectuar más llamadas o activar reintentos que eleven el coste aunque la calidad aparente mejore. Observe tanto el coste por solicitud como el coste por tarea completada, pues reducir el coste unitario a costa de más abandonos no constituye necesariamente una mejora. Mida también colas, errores de dependencias, latencia en percentiles altos y saturación de servicios de recuperación o herramientas.

En sistemas no deterministas, una sola ejecución no basta para caracterizar un caso crítico. Repita un subconjunto de entradas con la misma configuración y mida la dispersión de resultados relevantes: validez de estructura, decisión de usar una herramienta, cumplimiento de políticas o puntuación humana. No se debe interpretar esa dispersión como una probabilidad exacta si el muestreo es pequeño o las condiciones cambian; sirve como señal para ampliar pruebas y fijar salvaguardas.

Promover, pausar, revertir o retirar: decisiones explícitas

Promover no significa declarar que el cambio es universalmente mejor. Significa que, para el segmento y la fase observados, la evidencia cumple los umbrales definidos y no hay señales que aconsejen detenerse. Registre qué datos se revisaron, qué segmentos faltan y qué incertidumbres se aceptan. Esto evita que una promoción gradual se convierta, por inercia, en una expansión sin dueño.

Pause cuando haya una señal ambigua: volumen insuficiente, distribución de tráfico inesperada, indisponibilidad de una dependencia o una diferencia que requiere revisión humana. Pausar conserva el límite de exposición mientras se aclara la causa. No debe usarse para ignorar una alerta de alto impacto; ante un umbral de reversión, la acción es revertir o desactivar la capacidad afectada.

Un rollback efectivo se ejecuta mediante una referencia conocida y probada al paquete anterior, no reconstruyendo prompts o configuraciones bajo presión. La reversión debe abarcar todos los componentes vinculados: modelo, prompt, parámetros, recuperación, herramientas, esquemas, permisos, reglas de reintento y flag. Si una migración de datos o una acción externa no puede deshacerse, esa irreversibilidad debe formar parte del análisis anterior al despliegue y de los controles de aprobación.

Tras revertir, conserve evidencia suficiente para investigar: versión asignada, hora, segmento, solicitud con minimización o seudonimización apropiada, contexto de recuperación permitido, salida, llamadas a herramientas, resultado de validadores, latencia, coste y decisión tomada. El acceso a esos registros debe respetar los controles de seguridad y retención aplicables. Registrar más datos de los necesarios puede crear riesgos de privacidad; registrar menos puede impedir el diagnóstico.

La retirada definitiva de una variante también es una decisión válida. Si el cambio no demuestra beneficio operativo, incrementa de manera persistente el riesgo o exige controles desproporcionados, documente el resultado y cierre el experimento. El aprendizaje útil incluye saber qué hipótesis no se sostuvo.

Límites y preguntas que deben permanecer abiertas

Ningún protocolo elimina la incertidumbre propia de una aplicación generativa. Los resultados de un canary pueden no generalizar a periodos de mayor carga, nuevos tipos de consulta, idiomas distintos o cambios posteriores en dependencias. Los benchmarks y las pruebas internas tampoco sustituyen la observación en el contexto operativo. Por eso conviene mantener monitorización y capacidad de rollback después de llegar al cien por cien del tráfico.

La significación estadística, cuando se aplique, no reemplaza el juicio operativo. Un cambio pequeño pero estadísticamente detectable puede carecer de importancia práctica; un evento raro de seguridad puede exigir reversión aun sin volumen suficiente para cálculos concluyentes. Los umbrales deben reflejar la severidad del daño, la reversibilidad y el contexto de uso, no solo una diferencia numérica.

También hay incertidumbre sobre el comportamiento de servicios y modelos gestionados por terceros: actualizaciones, límites de capacidad, cambios en latencia o variación de salidas pueden influir en el resultado. Versionar lo que el equipo controla y registrar las versiones o identificadores que el proveedor expone mejora la trazabilidad, pero no convierte el entorno en completamente determinista. El plan debe indicar qué dependencias externas existen y cómo se detectarán sus cambios.

El criterio final es sencillo de expresar y exigente de aplicar: ampliar solo cuando el cambio demuestra valor suficiente dentro de límites de riesgo acordados; pausar cuando la evidencia no permite interpretar el resultado; revertir cuando se cruza un límite de daño; y conservar el paquete anterior hasta que el nuevo comportamiento esté suficientemente entendido. Así, el usuario deja de ser el mecanismo principal de descubrimiento de fallos y pasa a estar protegido por un proceso deliberado de entrega.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.