La nota de su agente puede cambiar sin que el agente cambie. El cambio de juez de Snowflake explica por qué

Imagine un dashboard que sigue semana a semana la corrección de las respuestas de un agente. El miércoles la línea se mueve. Nadie ha publicado un cambio de prompt, el modelo del agente es el mismo y los datos no han cambiado. Lo que cambió fue la vara de medir.

Es la situación que describe Snowflake en un cambio pendiente de las evaluaciones de Cortex Agent y Cortex Analyst. El modelo juez de las métricas originales, Claude 4 Sonnet, “llega al final de su vida útil el 14 de octubre de 2026”. Por eso Snowflake prevé cambiar los valores por defecto a partir del 13 de octubre, con la salvedad habitual de que las fechas pueden variar.

Qué cambia y a quién afecta

El cambio se aplica a las métricas que dejan sin definir la versión o el modelo juez, o los fijan en auto:

• Las métricas de sistema (corrección de la respuesta, coherencia lógica, acierto en la elección de herramientas y acierto en la ejecución de herramientas para agentes, y corrección del SQL para Analyst) pasan de la versión de métrica v1 a la v3.
• Las métricas personalizadas pasan de claude-4-sonnet a claude-sonnet-4-6 como juez, con openai-gpt-5.4 como alternativa si el modelo preferido no está permitido o disponible para la cuenta.

Snowflake es explícita sobre la consecuencia: “Las puntuaciones de distintas versiones de métricas no son directamente comparables.” Las puntuaciones basadas en juez pueden desplazarse, y el costo de las evaluaciones puede variar porque cada modelo juez tiene una tarifa de créditos distinta. Una métrica no se ve afectada: el acierto en la elección de herramientas no usa modelo juez.

Las configuraciones fijadas no se mueven. Pero fijarse en el juez que se retira no es refugio: “Las métricas fijadas en v1 o claude-4-sonnet dejan de funcionar al final de su vida útil.” Las cuentas que no habían usado v1 antes del 12 de agosto, cuando pasó a estado heredado, ya no podían ejecutarla.

Qué ocurre con cada configuración

Se rompeUsted decide

1. Fijada en v1Deja de funcionar al final de su vida útil
2. Sin definir o autoPasa a v3 y al nuevo juez sin aviso
3. Fijada en v2Estable hasta que usted decida cambiar
4. Fijada en v3Nuevo valor por defecto, con umbrales recalibrados

La evaluación es una dependencia, no una constante

La mayoría de los equipos versiona su agente: prompt, modelo, herramientas, configuración de búsqueda. Muchos menos versionan lo que pone nota al agente. Sin embargo, una métrica de LLM como juez tiene su propio modelo, su propio prompt y su propia definición de buena respuesta, y cualquiera de ellos puede cambiar sin que usted lo note. Cuando cambia, tres cosas se rompen en silencio:

• Las tendencias. Un gráfico de calidad que abarca el cambio compara dos mediciones distintas. Cualquier mejora o empeoramiento en esa fecha es imposible de interpretar.
• Los controles. Una comprobación de CI/CD que bloquea una versión por debajo de una puntuación puede empezar a frenar versiones buenas o a dejar pasar malas, porque el umbral se calibró con el juez anterior.
• Las comparaciones. Los resultados de dos equipos, o de dos plataformas, solo son comparables si ambos usaron el mismo juez y la misma versión de métrica, el problema que planteamos cuando Collibra empezó a mostrar métricas de agentes de cuatro plataformas en un solo dashboard.

Es la cara evaluativa de un patrón que describimos en la retirada de modelos es la nueva obsolescencia de API: cuando se retira un modelo, el comportamiento cambia aunque no cambie el código. Aquí el modelo que se retira es el que califica.

Lo que recomienda Snowflake, y lo que conviene añadir

Los pasos de preparación de Snowflake son sensatos: probar las métricas de sistema con version: "v3" y recalibrar los umbrales de dashboards, alertas y CI/CD; fijar una versión de métrica (por ejemplo v2) o un modelo juez personalizado si se quiere controlar el momento del cambio; y confirmar que los nuevos modelos juez están permitidos para la cuenta y para el rol que ejecuta las evaluaciones, y accesibles con su configuración de inferencia entre regiones. Los nuevos jueces tienen ventanas de contexto de alrededor de un millón de tokens, lo que según Snowflake reduce fallos en trazas largas de agentes.

Más allá de este cambio concreto, la práctica general merece adoptarse en cualquier plataforma:

1. Fije explícitamente la configuración de evaluación y guarde la versión de la métrica y el modelo juez junto a cada puntuación.
2. Ejecute el antiguo y el nuevo en paralelo sobre un conjunto de evaluación fijo antes de cambiar, y registre la diferencia entre ambos.
3. Marque el cambio en cada gráfico, para que nadie lea un cambio de medición como un cambio de calidad.
4. Recalibre con personas. Un juez nuevo debe contrastarse con ejemplos etiquetados por humanos, el paso de calibración que, como defendimos, convierte la evaluación en la superficie de control y no en decoración.

Si la puntuación de su agente se mueve esta semana, revise el juez antes de revisar el agente.