Cambiar el modelo base de IA sin perder calidad: Evals, Canary y Rollback

Un nuevo modelo base de IA promete a menudo mejores respuestas, menores costes o tiempos de reacción más breves. Sin embargo, para un chatbot de sitio web en producción, el cambio no es una simple sustitución de un paquete de software cualquiera. Incluso una nueva versión del modelo puede sopesar las instrucciones de forma diferente, formular respuestas más detalladas, generar datos estructurados de otro modo o llamar a herramientas en una secuencia distinta. Por lo tanto, una migración solo tiene éxito cuando el chatbot realiza sus tareas concretas al menos con la misma fiabilidad que antes, y cuando el equipo puede revertir los cambios en cuestión de minutos si surgen problemas.

Los proveedores retiran modelos de forma periódica. La documentación de OpenAI sobre retiradas incluye fechas de desactivación y modelos de sustitución recomendados; Anthropic distingue en su ciclo de vida del modelo los estados «Active», «Legacy», «Deprecated» y «Retired». Tales plazos son el motivo de la migración, pero no la prueba de su calidad. Esta solo la proporciona un procedimiento de prueba y despliegue adaptado al propio chatbot.

Lo que realmente cambia al sustituir el modelo base

Este proceso debe distinguirse claramente de una migración del modelo de embeddings . Al cambiar de embeddings, es necesario volver a vectorizar los documentos y mantener la compatibilidad de los índices de búsqueda. En el cambio de modelo base, el índice de recuperación (retrieval) suele mantenerse igual; lo que cambia es el modelo que genera la respuesta a partir de las instrucciones del sistema, la conversación, las fuentes encontradas y los resultados de las herramientas. Por tanto, se evalúan el comportamiento de respuesta, la fidelidad a las fuentes, el formato, el uso de herramientas, la seguridad, la latencia y los costes.

Asimismo, una prueba general en Shadow Mode previa al lanzamiento en la web solo resuelve una parte del desafío. El tráfico en la sombra puede alimentar dos modelos con las mismas entradas sin entregar la nueva respuesta. El cambio de modelo base descrito aquí va más allá: define previamente una matriz de aceptación, dirige una pequeña porción del tráfico real hacia el candidato, monitoriza las señales del usuario y del sistema, y mantiene lista una reversión probada.

Antes de la prueba: definir un contrato de migración unívoco

Las comparaciones carecen de valor si cambian varias cosas al mismo tiempo. Por ello, en la primera ronda, mantenga constantes y compatibles las instrucciones del sistema (prompt), la configuración de retrieval, los esquemas de herramientas, la temperatura, la longitud máxima de salida y las reglas de seguridad, y documente los cambios de parámetros inevitables (como opciones de muestreo no admitidas). Documente el modelo actual como base y el nuevo modelo como candidato. Siempre que sea posible, utilice versiones explícitas del modelo en lugar de un alias dinámico. Un alias puede señalar más adelante a una captura (snapshot) diferente y alterar la comparación presuntamente reproducible.

El contrato de migración también especifica los grupos de usuarios y las funciones que quedan excluidos inicialmente. Por ejemplo, un chatbot de preguntas frecuentes puede pasar temprano a Canary, mientras que los accesos de escritura a pedidos, las consultas de contratos o los casos de soporte especialmente sensibles permanecen durante más tiempo en el modelo base. De este modo, el riesgo se limita en función del impacto empresarial y no solo por la complejidad técnica.

El conjunto de pruebas debe reflejar el tráfico real

Un Golden Set no debe contener únicamente preguntas estándar limpias. Recopile casos anonimizados o sintetizados a partir de las intenciones más importantes: preguntas unívocas, formulaciones ambiguas, preguntas de seguimiento, documentos faltantes, fuentes contradictorias, errores de herramientas y entradas que deban ser transferidas a una persona. Desglose los casos por idioma, dispositivo, tipo de cliente y clase de riesgo. Esto permite detectar si una buena puntuación global oculta subgrupos pequeños pero críticos para el negocio.

La guía oficial de Anthropic sobre criterios de éxito y evals recomienda criterios específicos, medibles y adaptados al caso de uso, así como casos límite realistas. Del mismo modo, la guía de OpenAI sobre evals describe las pruebas como un componente esencial para aplicaciones fiables, especialmente al actualizar o probar nuevos modelos. Puesto que OpenAI anuncia en esa misma página la retirada de su plataforma anterior de Evals, conviene almacenar el Golden Set propio en un formato portable y no vincularlo a un único panel de control.

Una matriz de evaluación en lugar de un solo valor medio

Los siguientes valores límite son un ejemplo y no una pauta universal. Establézcalos a partir del rendimiento previo en producción y del perjuicio de un error. Un candidato no debe compensar un precio de token más económico con una peor fidelidad a las fuentes.

Las verificaciones automáticas son adecuadas para esquemas JSON, formulaciones obligatorias, destinos de enlaces, argumentos de herramientas y reglas de negocio deterministas. Para el tono, la exhaustividad y las explicaciones útiles, se requiere además una rúbrica clara; las revisiones por muestreo a cargo de especialistas permiten calibrar un evaluador basado en LLM. Los resultados deben guardarse por intención y clase de riesgo, no solo como una puntuación única. La estructura fundamental de este tipo de conjuntos se detalla también en nuestra guía sobre calidad de respuesta con Golden Set.

Ejemplo concreto: cambio de modelo en soporte B2B

Supongamos que un proveedor de software B2B gestiona un chatbot para consultas de productos, administración de cuentas y preparación de tickets de soporte. El equipo crea 240 casos de prueba: 120 preguntas de conocimiento frecuentes, 40 preguntas de seguimiento ambiguas, 30 casos con falta de fuentes, 25 simulaciones de herramientas y 25 casos de seguridad o transferencia. Ambos modelos reciben exactamente las mismas instrucciones, fragmentos de documentos recuperados y respuestas simuladas de herramientas.

El candidato responde a las preguntas estándar de forma más rápida y económica, pero pierde la referencia al mensaje anterior en cinco preguntas de seguimiento. La puntuación global seguiría siendo superior. Sin embargo, la evaluación por segmentos muestra un deterioro claro de la calidad. En lugar de añadir una excepción arbitraria, el equipo precisa la regla de conversación, amplía el conjunto de pruebas con casos similares y vuelve a evaluar ambos modelos. Solo cuando el candidato supera todas las barreras estrictas, comienza el Canary en producción.

Para comenzar, se asigna el dos por ciento de las nuevas conversaciones elegibles al candidato. La asignación se deriva al inicio de la conversación, por ejemplo a partir del hash del ID de conversación, y se mantiene persistente durante toda la interacción; los niveles superiores de Canary solo se aplican a nuevas conversaciones. Las llamadas a herramientas con permisos de escritura y las intenciones de alto riesgo permanecen inicialmente en el modelo base. Tras un período de observación suficientemente amplio, se pasa al 10, 25, 50 y finalmente 100 por ciento, pero solo si cada control sigue en verde. Los niveles y los tamaños mínimos de muestra se fijan previamente para evitar que las prisas modifiquen las reglas sobre la marcha.

Señales online que realmente importan

Durante la fase Canary, no basta con monitorizar los errores HTTP y la latencia media. Observe la tasa de falta de respuesta, los abandonos tras la primera respuesta, las preguntas repetidas, la tasa de transferencia a agentes (handoff), los clics en fuentes, los errores de esquema y las interrupciones de herramientas de forma separada para la base y el candidato. Una traza unificada vincula la versión del modelo, la versión del prompt, los aciertos de retrieval y los pasos de herramientas, sin almacenar datos personales innecesarios. Nuestra publicación sobre observabilidad en chatbots explica en detalle este registro de auditoría.

Compare también los costes por caso resuelto con éxito en lugar de limitarse al coste por millón de tokens. Un modelo más económico que genere aclaraciones frecuentes o trabajo manual adicional puede resultar operativamente más costoso. Por el contrario, un ligero incremento en la latencia puede ser aceptable si viene acompañado de respuestas demostrablemente más precisas en una categoría de riesgo crítica.

El rollback es una función, no un documento

La vía de retorno debe probarse técnicamente antes de la primera fase Canary. El ID del modelo y sus parámetros asociados pertenecen a una configuración con control de versiones o a una feature flag controlada. Mientras el proveedor siga admitiendo la versión previa, esta permanecerá disponible como destino de retorno durante el Canary; antes de su fecha de desactivación se necesita, además, una alternativa respaldada. Las conversaciones en curso deben permanecer de forma coherente en su modelo original o cambiar según una regla probada explícitamente.

Defina detonantes estrictos: por ejemplo, un error de esquema en una acción de escritura, el empeoramiento de una intención relevante para la seguridad, un pico notable en la tasa de errores o la superación del presupuesto de latencia. Ante una señal de este tipo, el sistema se revierte de forma automática o mediante una persona de guardia claramente designada. Tras la reversión, se conservan los registros, la versión del candidato y la muestra afectada para poder analizar la causa raíz. Un procedimiento preparado es sustancialmente más sólido que un despliegue de código improvisado; de forma complementaria, resulta útil contar con un manual completo de respuesta ante incidentes.

Lista de comprobación para la aprobación

• Registrar la fecha de desactivación, el modelo de sustitución y los endpoints afectados a partir de la documentación oficial del proveedor.
• Fijar el modelo base y el candidato con configuraciones idénticas de prompts, retrieval y herramientas.
• Dividir el Golden Set por intención, idioma y clase de riesgo; añadir casos límite y patrones de error reales.
• Definir barreras estrictas para la fidelidad a las fuentes, salidas estructuradas, herramientas, seguridad y transferencia.
• Medir latencia, tasa de errores, tokens y costes por caso resuelto.
• Mantener estable la asignación de Canary para conversaciones completas y excluir inicialmente las funciones sensibles.
• Documentar las fases, la muestra mínima, la duración de observación y los límites de cancelación antes del despliegue.
• Probar técnicamente el rollback, asignar responsables y mantener disponible un destino de retorno compatible con el proveedor.
• Tras alcanzar el 100 %, continuar la monitorización y ampliar el Golden Set con nuevos casos detectados en producción.

Conclusión: El nombre del modelo es solo el comienzo

Un cambio controlado de modelo base une la calidad del producto y la seguridad operativa. Los avisos oficiales del ciclo de vida aportan el plazo, las evals aportan evidencias sobre la idoneidad, el tráfico en Canary limita el impacto de errores desconocidos y un rollback probado reduce el tiempo de respuesta. Quien establece estos cuatro pilares como un proceso repetible puede aprovechar los nuevos modelos sin convertir el chatbot de su sitio web en un experimento para los usuarios.

¿Desea planificar de forma estructurada la versión del modelo, las barreras de calidad y el despliegue del chatbot de su sitio web? ChatReact le ayuda a configurar su base de conocimiento, el comportamiento de respuesta y las transferencias para que los cambios se mantengan medibles y bajo control.