¿Por qué es más difícil de lo que esperas?
En un software tradicional la prueba es binaria: pasa o no pasa, la salida coincide o no. En un agent cambian tres cosas a la vez: el modelo no es determinista, el entorno también cambia (un sitio web, una base de datos, un calendario) y la respuesta correcta a menudo no es un único texto.
A eso se suma una cuarta que muchos solo descubren después: el propio estándar de registro no está terminado. La parte dedicada a la IA generativa del estándar sectorial de trazas sigue marcada como «en desarrollo» en septiembre de 2026: no es estable, ni siquiera es candidata a versión. Entretanto se ha mudado además a un repositorio aparte, y su esquema de referencia sigue marcado como «pendiente» en la documentación.
Esto no es un detalle. Significa que no hay una forma asentada de registrar las ejecuciones de un agent sobre la que puedas construir a largo plazo: los proveedores trabajan con sus propios nombres de campo, y esos todavía cambian.
Las tres formas de puntuar
La documentación primaria distingue tres modos y además los ordena. Conviene tomárselo al pie de la letra, porque el orden no es el que la mayoría supondría:
| Modo | Valoración |
|---|---|
| Por código | «El más rápido y el más fiable, y escala extraordinariamente bien», a cambio de no saber matizar. |
| Humana | «La más flexible y de mejor calidad, pero lenta y cara. Evítala si puedes.» |
| Con modelo | «Rápida y flexible, escalable, apta también para juicios complejos. Comprueba antes su fiabilidad y después escálala.» |
El mensaje de ese orden: empieza por el código. En la mayoría de las tareas de agent hay mucho más comprobable por código de lo que parece: ¿se creó el fichero? ¿es válido el JSON? ¿está el campo obligatorio? ¿llamó a alguna herramienta que no debía? Son comprobaciones rápidas, gratuitas y que no se equivocan.
El juicio con modelo solo entra donde el código no puede decidir. Y, como muestra el capítulo siguiente, tampoco ahí hay que fiarse a ciegas.
El modelo como juez: medido, en los dos sentidos
Este es el capítulo más importante del artículo, porque aquí está la mayoría de los fallos mudos.
La buena noticia. Según un estudio académico de 2023, los modelos jueces fuertes alcanzan más del 80 % de coincidencia con las preferencias humanas, tanto como la que hay entre dos personas. Una tubería de juicio construida para una tipología de fallos multi-agent alcanzó un 94 % de precisión y un coeficiente de acuerdo de 0,77 frente a la anotación humana, y generalizó también a sistemas no vistos antes (0,79). Para comparar: en ese mismo trabajo el acuerdo entre anotadores humanos era de 0,88.
La mala noticia, y es la más importante.
Hay una tabla pública que mide browser agents y que publica dos columnas de resultados distintas para los mismos sistemas: una verificada por personas y otra hecha con un juez automático.
[Cálculo propio] He emparejado las dos, sobre 13 sistemas:
| Valor | |
|---|---|
| Número de sistemas | 13 |
| Diferencia media | −5,49 puntos porcentuales |
| Rango | de −0,4 a −14,0 puntos |
| Casos en los que el juez automático puntuó menos | 13 de 13 |
El juez automático no se equivoca al azar, sino de forma sistemática y en un solo sentido: infravalora. Y la diferencia no es uniforme: incluso en los mejores sistemas llegó a 14 puntos.
(Reserva metodológica: las dos series de datos no proceden necesariamente de las mismas ejecuciones, así que parte de la diferencia es ruido de medición. La constancia del sentido — 13 de 13 — no se explica por ruido, eso sí.)
La consecuencia práctica: si solo juzgas con modelo, no sabes hacia dónde ni cuánto te equivocas. Por eso conviene poner al lado, de vez en cuando — no en cada ejecución, sino por muestreo —, una comprobación humana, y mirar cuánta es la desviación. Si conoces su magnitud, el juicio con modelo sirve; si no la conoces, tus cifras no son comparables con nada.
Tres reglas que hacen más fiable al juez
La guía del fabricante es concreta:
1. UNA RÚBRICA DETALLADA Y SIN AMBIGÜEDAD
No "si la respuesta es buena", sino: "la respuesta
debe contener X en la primera frase; si no, es
automáticamente incorrecta".
2. PIDE UN NÚMERO O UNA ETIQUETA, NO UNA OPINIÓN
"correcto" / "incorrecto", o una escala de 1 a 5.
La valoración puramente textual no se puede
procesar rápido y en cantidad.
3. DÉJALO RAZONAR - Y LUEGO TIRA ESO
Pídele que razone primero y solo después dé la
puntuación; el razonamiento lo descartas. Eso
mejora de forma medible la calidad del juicio.
¿Qué medir? — la precisión por sí sola no basta
Una tabla pública que se toma en serio publica esto en cada entrada, y es un buen modelo para tu propia medición:
| Qué hay que medir | Por qué |
|---|---|
| Precisión | la pregunta básica: si salió bien |
| Intervalo de confianza | sin él no sabes si la diferencia es real |
| Número de ejecuciones | de ahí depende qué diferencia puedes detectar |
| Tasa de éxito con varios intentos | mide otra cosa que la de un solo intento |
| Tokens de entrada y salida, con la caché aparte | aquí se ve adónde va el dinero |
| Dólares por ejecución | la única cifra que le importa al negocio |
| Tiempo de ejecución | el límite de la experiencia de uso |
Entre los criterios de éxito, la documentación nombra ocho categorías, y la mayoría de las mediciones solo mira la primera: fidelidad a la tarea, consistencia, relevancia y coherencia, tono y estilo, preservación de la privacidad, uso del contexto, latencia, precio.
La «preservación de la privacidad» como criterio de evaluación es la partida que más se omite. Y eso que es fácil de automatizar: buscas en la salida patrones que no deberían estar ahí.
¿Qué muestra hace falta para detectar una regresión?
Para esto hay un ejemplo concreto y medido. Una tabla pública publica 330 ejecuciones por cada entrada, y por eso su intervalo de confianza queda entre ±2,4 y ±3,9 puntos.
Y de ahí sale la regla práctica más importante. Si hacen falta trescientas treinta ejecuciones para bajar la incertidumbre a unos tres puntos, entonces con diez ejecuciones la incertidumbre pasa de veinte puntos porcentuales — la incertidumbre cae con la raíz cuadrada del número de ejecuciones. Así que si tu agent resuelve ocho de diez casos de prueba y siete después de la actualización, eso es ruido puro.
Una ilustración concreta del mismo sitio: el mismo modelo en dos niveles de razonamiento saca 57,88 % y 58,18 % — la diferencia está dentro del margen de error, mientras que la diferencia de precio es del 43 %. Quien pagó ese 43 % por los 0,3 puntos compró ruido.
Recomendación práctica: usa menos casos de prueba, pero ejecuta cada uno varias veces. Veinte casos con cinco repeticiones valen más que cien casos una sola vez.
La actualización de modelo es la regresión muda más frecuente
Aquí está la parte más práctica del artículo, porque afecta a todo el que tenga un agent en funcionamiento.
En 2026 esto ni siquiera es opcional: los grandes proveedores retiraron una a una las generaciones anteriores de modelos. Quien montó un agent en 2025 y no lo tocó, en 2026 tuvo que cambiar de modelo por obligación. El manejo de la retirada lo recorre el post cuando retiran tu modelo , paso a paso.
Y el cambio no es neutro. La guía de migración del fabricante enumera punto por punto los cambios de comportamiento que pueden romper un agent que funcionaba:
| Cambio | Qué estropea |
|---|---|
| Respuestas por defecto más largas | se descontrola la longitud; bajar el esfuerzo acorta el razonamiento, pero no de forma fiable la respuesta visible |
| Seguimiento literal de instrucciones | el modelo nuevo no generaliza en silencio de un elemento a otro, ni deduce una petición que no dijiste |
| Doble revisión | el modelo nuevo revisa su trabajo por su cuenta, así que la instrucción de autocomprobación heredada duplica el trabajo |
| Más delegación | lanza subagents con más facilidad, lo que significa más tokens y otros modos de fallo |
| Niveles de esfuerzo con otro precio | el mismo ajuste significa otra cantidad de tokens que antes |
La tercera fila es la más traicionera. Si en tu prompt sigue habiendo una frase del tipo «revisa tu trabajo antes de responder» que metiste hace dos años, en el modelo nuevo no mejora nada, empeora: el agent revisa dos veces, y se vuelve más lento y más caro.
A esto se suma una trampa técnica: en los modelos más nuevos los parámetros que regulan la aleatoriedad (temperatura, umbrales de muestreo) han quedado obsoletos, y si los pones a un valor que no sea el predeterminado la llamada devuelve un error. Un cliente escrito en 2024 se cae ahí sin más.
La lista de comprobación de migración
AL CAMBIAR DE MODELO, EN ESTE ORDEN
1. VUELVE A MEDIR COSTE Y LATENCIA
Con tu propia carga, no con la ficha del fabricante.
Los tokens de razonamiento se facturan como
tokens de salida: lo que antes no razonaba
ahora puede producir mucha más salida.
2. QUITA LAS VIEJAS FRASES QUE LIMITAN LA LONGITUD
Mide primero la longitud natural y solo después
regúlala - no con la frase de hace dos años.
3. QUITA LAS VIEJAS FRASES DE AUTOCOMPROBACIÓN
Los modelos nuevos se revisan solos.
La instrucción olvidada provoca doble revisión.
4. HAZ UNA SERIE NUEVA DE NIVELES DE ESFUERZO
No traslades el ajuste afinado al modelo viejo.
5. LIMITA EL NÚMERO DE SUBAGENTS
O di explícitamente cuándo está justificado
delegar.
6. EJECUTA TODO EL CONJUNTO DE PRUEBAS, VARIAS VECES
Una ejecución no es una medición. Mira el
intervalo de confianza.
La comparación práctica de modelos entre sí la desarrolla con más detalle el post la cata de modelos , con su receta.
Dos trampas de medición que conviene saber de antemano
1. Los subagents estropean la segmentación. Si desglosas la estadística por modelo, cuidado: una sesión puede usar varios modelos. Si no filtras por las peticiones principales, las llamadas auxiliares y de subagents apuntan el resultado de la sesión a un modelo que ni siquiera lo hizo. Lo que los montajes multi-agent significan para la medición lo expone con más amplitud el post los sistemas multi-agent , con su propia tabla.
2. La propia medición del coste ha llegado a fallar. En un caso documentado, antes de cierta versión el cliente contaba de más los tokens y el coste cuando la respuesta llegaba en varios trozos: aproximadamente una petición completa de más por trozo. Y en palabras del propio fabricante, de todas formas: las métricas de coste son aproximaciones, y para la contabilidad oficial hay que mirar los datos de facturación.
La lección de las dos es la misma: tu sistema de medición también es software, y también tiene fallos. Por eso conviene mirar las cifras importantes desde dos fuentes independientes: telemetría y factura, juez automático y comprobación humana por muestreo.
El montaje mínimo
Si puedes dedicarle un solo día a esto, construye esto:
1. VEINTE CASOS DE PRUEBA, POR ESCRITO
Tareas reales del último mes. Para cada una:
cuál es la entrada, cuál la salida correcta,
qué cuenta como aceptable.
2. COMPROBACIÓN POR CÓDIGO EN TODO LO POSIBLE
Formato, campos obligatorios, llamada prohibida,
patrón prohibido en la salida. Esa es la base.
3. UN JUEZ MODELO PARA EL RESTO, CON RÚBRICA
Pide etiqueta, no opinión. Que razone primero
y luego tira el razonamiento.
4. CADA UNO SE EJECUTA AL MENOS CINCO VECES
Una ejecución no es una medición.
5. GUARDA SIETE CIFRAS POR EJECUCIÓN
Éxito, tokens de entrada y de salida, dólares,
segundos, número de llamadas, código de error.
6. VEINTE EJECUCIONES REVISADAS A MANO CADA MES
Esto calibra a tu juez. Sin ello no sabes de
cuánto es tu desviación.
7. ANTES DE CADA CAMBIO DE MODELO: RONDA COMPLETA
Es un día de trabajo, y a partir de ahí sabes si algo ha empeorado, en vez de intuirlo.
Malentendidos típicos
- «Tenemos registro, o sea que medimos.» El registro dice qué pasó. La evaluación dice si estuvo bien. En la encuesta, menos del 40 % de los que respondieron medía lo segundo.
- «Ya me lo dirá el juez modelo.» En una comparación de 13 sistemas, el juez automático puntuó menos en 13 casos de 13, una media de 5,5 puntos. Sirve, pero solo si conoces su desviación.
- «Con una ejecución basta para comprobar un caso.» El modelo no es determinista. Por debajo de cinco ejecuciones no distingues ruido de regresión.
- «La actualización solo puede ser mejor.» El modelo nuevo responde más largo, es más literal, se revisa solo y delega más. Las cuatro cosas pueden romper un prompt que funcionaba.
- «Lo que importa es la precisión.» La precisión sin intervalo de confianza no es una cifra. Y los dólares por ejecución exitosa importan por lo menos igual.
- «La observabilidad es un problema resuelto.» La parte de IA generativa del estándar sectorial correspondiente seguía marcada como «en desarrollo» en septiembre de 2026.
Lo que conviene llevarse
La evaluación no falta en casi todas partes porque sea difícil, sino porque no hay nada que obligue a hacerla: el agent funciona a la vista, hasta que alguien nota que no.
Tres cosas que se construyen en un día: veinte casos de prueba reales, comprobación por código en todo lo que la admita y siete cifras guardadas de cada ejecución. Esas tres cogen la mayoría de los deterioros mudos.
Y una cifra que conviene recordar: por debajo de cinco repeticiones no es medición, es impresión. La mayoría de las discusiones sobre si «el modelo ha empeorado» las decide esa diferencia. Cómo conviene leer en general las cifras de los benchmarks lo trata el post leer benchmarks , y el registro de los agents de segundo plano le toca al post los agents programados , en detalle.