La trampa de la saturación: cuando tu línea base de evaluación es demasiado buena para medir

Una puerta de evaluación comparativa ("el nuevo sistema debe superar al antiguo en el 60% de las tareas") deja de funcionar en silencio en el momento en que tu línea base satura el criterio de evaluación. La nuestra lo hizo. Construimos una puerta de comparación directa para decidir si un pipeline más complejo de múltiples pasos merecía su lugar frente al comportamiento de un solo turno que ya habíamos implementado, lo ejecutamos y obtuvimos un veredicto que parecía un rechazo claro: una tasa de victoria del 7.1% frente a un umbral del 60%. En esta ejecución, el sistema desafiante nunca fue peor en ninguna tarea: empató en 13 de 14 y ganó en la única en la que no empató. La cifra no nos estaba diciendo que el desafiante había fallado. Nos estaba diciendo que nuestras tareas eran demasiado fáciles para diferenciar los dos sistemas y casi habíamos confundido uno con el otro.

Esa falla tiene una forma que merece un nombre, porque es invisible hasta que observas la puntuación absoluta de la línea base. La llamamos la trampa de la saturación: cuando tu línea base obtiene puntuaciones cercanas al techo, una puerta basada en la tasa de victorias ya no mide en absoluto al sistema desafiante.

La puerta que construimos

La decisión era concreta. Un pipeline de múltiples pasos (planificar, luego ejecutar y verificar) tiene un costo mayor que un solo turno de modelo, ya que realiza varias llamadas al modelo donde el sistema de un solo turno realiza una. Por lo tanto, la barrera no era "¿es bueno?", sino "¿es claramente mejor, lo suficiente como para justificar el costo adicional?". Si solo igualaba al sistema de un solo turno, implicaba un aumento de costos sin mejora en la calidad y no debería implementarse. (No estamos publicando deliberadamente la composición interna del modelo del pipeline ni ninguna economía por token; la lección aquí es sobre la evaluación, no sobre nuestro enrutamiento).

Operacionalizamos "claramente mejor" como dos líneas que ambas debían cumplirse, ya que cualquiera por sí sola es manipulable:

• Tasa de victorias de al menos el 60%. El sistema desafiante debe ganar claramente en al menos el 60% de las tareas. Los empates cuentan en su contra: un empate con mayor costo es una pérdida en términos de producto. Establecimos el umbral en el 60% en lugar del 50% para que un resultado tuviera que sobrevivir al ruido del juez en un conjunto pequeño de tareas; una victoria ajustada de 7 de 12 está a un juicio cambiado de ser un lanzamiento de moneda.
• Delta medio de puntuación estrictamente positivo. La diferencia media por tarea en la puntuación (desafiante menos línea base) debe ser superior a cero, por lo que unas pocas victorias estrechas no pueden enmascarar grandes regresiones en otros lugares.

El conjunto de tareas constaba de 14 tareas principales en un espacio de trabajo de fixture completamente sintético: un ficticio procesador SaaS de 30 personas con defectos deliberadamente insertados (una política de ISMS obsoleta que citaba la retirada ISO/IEC 27001:2013, una política de control de acceso con una regla contradictoria de MFA, un stub de respuesta a incidentes, un inventario de procesamiento parcial). Sin datos de clientes. Cada tarea incluía un criterio de evaluación con criterios binarios independientes y calificables, puntuados por un juez de modelo de lenguaje (claude-haiku-4-5, temperatura 0, un veredicto JSON por criterio). El juez solo veía los entregables liberados, nunca el plan interno del pipeline, por lo que un plan que prometía "incluir el Art. 28(3)" no podía obtener crédito si el documento final no lo incluía.

La ejecución y las dos líneas que discreparon

Aquí están los resultados completos. La línea base es el sistema de un solo turno (claude-opus-4-6); el desafiante es el pipeline de múltiples pasos, cuya composición interna del modelo mantenemos en reserva porque afecta al enrutamiento. Eso está bien aquí, porque la lección es a nivel arquitectónico y no depende de qué modelo se encuentre dentro del pipeline. Una ejecución por sistema, 11-06-2026.

Medida	Valor
Puntuación media de la línea base (14 tareas)	0.984
Puntuación media del desafiante (14 tareas)	1.000
Empates	13 de 14
Victorias del desafiante	1
Derrotas del desafiante	0
Tasa de victorias (los empates cuentan en contra del desafiante)	7.1% (1/14)
Delta medio de puntuación (desafiante menos línea base)	+0.016

Lee la puerta con estos números y las dos líneas se contradicen. La línea de delta medio pasa: el desafiante es, en promedio, muy ligeramente mejor y nunca peor. La línea de tasa de victorias falla catastróficamente: 7.1% frente a un umbral del 60%. Una sola puerta que dice tanto "el desafiante es al menos tan bueno en todas las tareas" como "el desafiante pierde el 93% de las veces" no está midiendo al desafiante. Esa contradicción es la firma de la trampa de la saturación y es la señal que debes observar.

El mecanismo es aritmético, no de juicio. La línea base obtuvo una puntuación perfecta de 1.0 en 13 de las 14 tareas. En una tarea donde la línea base ya obtiene 1.0, lo mejor que puede hacer el desafiante es empatar, porque no hay margen por encima de 1.0 para ganar. Y los empates, por nuestro propio diseño, cuentan en su contra. Por lo tanto, un criterio de evaluación que la línea base domina convierte casi todas las tareas en una pérdida estructural para el desafiante, sin importar qué tan bueno sea el desafiante. La tasa de victorias había dejado de ser una propiedad del desafiante y se había convertido en una propiedad del conjunto de tareas: específicamente, la proporción de tareas que la línea base había dejado superables. Solo había dejado una.

El único lugar donde la línea base perdió una puntuación

Observa la única tarea en la que la línea base no obtuvo una puntuación perfecta. Obtuvo 0.78, y no porque no pudiera hacer el trabajo. Era una tarea en la que hizo demasiado: se le pidió redactar el conjunto de documentación GDPR faltante con un criterio que especificaba entre tres y cinco artefactos, y el sistema de un solo turno produjo siete. Cada artefacto era competente y estaba correctamente citado. Su única pérdida de crédito en toda la ejecución fue una penalización por exceso de entrega, por no detenerse.

Esa es toda la lección en un solo dato. Cuando ambos sistemas pueden hacer la tarea, "¿puede hacer la tarea?" ya no es la pregunta que la evaluación debería estar haciendo, porque ambos responden sí y empatan. Las únicas fallas que quedan por calificar son fallas de moderación: hacer demasiado, decir demasiado, citar con demasiada confianza, afirmar cosas que no se te pidieron afirmar. Nuestro primer criterio de evaluación medía la capacidad, nuestra línea base saturó ese criterio y la única señal que sobrevivió fue una falla de moderación que casi no habíamos escrito una tarea para detectar.

"Entonces implementa la línea base"

La objeción honesta a todo esto es que una línea base con una puntuación de 0.984 te está diciendo que implementes la línea base y omitas el costoso pipeline. Si lo barato es tan bueno, ¿por qué seguir midiendo? Es un desafío justo y está medio en lo cierto: en estas tareas, lo barato era realmente bueno y eso es un hallazgo real.

Solo está medio en lo cierto porque la saturación en tareas de capacidad no dice nada sobre las tareas de moderación, y la moderación es exactamente donde un pipeline de múltiples pasos (que puede verificar su propio trabajo antes de liberarlo) podría realmente adelantarse o quedarse atrás al acumular sus propios excesos. Nuestras tareas principales nunca lo exploraron. La única que lo hizo accidentalmente (la tarea de exceso de entrega) fue la única que se movió. Por lo tanto, el 0.984 no era evidencia de que los dos sistemas fueran equivalentes. Era evidencia de que nuestras tareas no podían distinguirlos en el eje que quedaba. La saturación es una declaración sobre tu criterio de evaluación, nunca un veredicto de equivalencia entre tus sistemas.

Qué cambiamos

No volvimos a ejecutar la puerta. Reejecutar una evaluación saturada no puede elevar la tasa de victorias, porque el desafiante no puede obtener una puntuación superior a 1.0 de la línea base en las tareas en las que ya empata; una nueva ejecución solo reproduce el mismo techo a un mayor costo. En su lugar, reforzamos el conjunto de tareas, añadiendo tareas cuyos criterios de evaluación una línea base fuerte de un solo turno puede fallar genuinamente, cada una dirigida a un eje de moderación que las tareas principales ignoraban:

• Disciplina de alcance: producir exactamente tres documentos de incorporación, ni más ni menos. Califica el reflejo de exceso de entrega detrás de la única pérdida de crédito de la línea base.
• Omisión adecuada al público: un correo electrónico de seguridad para clientes más una nota de portada interna, donde el espacio de trabajo contiene un memorándum interno exclusivo para socios. Califica si el modelo mantiene el contenido privilegiado fuera del artefacto dirigido al exterior.
• Corrección en las citas: un plan de auditoría interna que debe citar el estándar correcto para la afirmación y no uno plausible pero incorrecto.
• Manejo de evidencia no verificada: un informe de estado de auditoría donde la auditoría aún está en progreso. Califica si el modelo informa lo que está verificado en lugar de afirmar una finalización que no puede respaldar.

El andamiaje anti-manipulación que hizo esto seguro de iterar merece ser declarado claramente, porque un conjunto de tareas reforzado solo es tan confiable como la disciplina en torno a él. El conjunto canónico de identificadores de tareas está congelado y hasheado (sha256 sobre los IDs de tareas, los criterios de evaluación y los documentos de fixture, junto con la versión del modelo juez y el puntuador), y solo se acepta una lectura de la puerta sobre ese conjunto exacto: sin subconjuntos, sin extras. Esto dificulta la selección silenciosa de tareas que produzcan un veredicto preferido y un informe obsoleto o editado manualmente no puede silenciosamente aprobar un lanzamiento.

Los límites de esto

Una ejecución por sistema, un modelo juez, 14 tareas. Un solo juez que califica criterios binarios tiene varianza, que es la razón completa por la que la barra de la tasa de victorias está en el 60% y no en el 50%. La línea base también se ejecutó con el prompt real del sistema de producción pero sin las memorias, habilidades guardadas ni búsqueda web que una sesión en vivo puede tener, y cada una de esas brechas hace que la línea base sea más débil que un solo turno real, lo que facilita la puerta para el desafiante, no más difícil. En otras palabras, la línea base real probablemente esté aún más saturada que 0.984. Estas cifras son puntuales a fecha de 11-06-2026. No hemos publicado una lectura de la puerta en el conjunto de tareas reforzado; el punto de esta publicación es la falla que expuso la primera ejecución, no un nuevo veredicto.

Esta no es una falla diferente de una métrica que permanece en verde mientras el producto se rompe, de la que escribimos por separado. Esa era un número que mentía. Esta es una cifra que dijo la verdad (la línea base realmente es tan fuerte en estas tareas) y aún así no pudo responder la pregunta que le hicimos. Ambas son formas en que una evaluación que parece aprobada puede ser inútil, y requieren soluciones opuestas: la primera necesita una métrica mejor, la segunda necesita tareas más difíciles.

Una lista de verificación para puertas comparativas

• Lee la puntuación absoluta de la línea base antes de confiar en la tasa de victorias. Si la línea base está cerca de tu techo, tu umbral de tasa de victorias es estructuralmente inalcanzable. Corrige las tareas, no vuelvas a ejecutar.
• Observa la tasa de empates. Una acumulación de empates es un criterio de evaluación saturado, no un empate real. Si la mayoría de las tareas empatan, tu conjunto no tiene margen para que ninguno de los dos gane.
• Decide qué significan los empates antes de leer la cifra. Cuando los empates cuentan en contra del desafiante, una línea base saturada convierte un sistema mejor en un veredicto de fallo. Eso puede ser la política correcta (la nuestra lo fue, por motivos de costo), pero reconoce que estás eligiendo eso.
• Trata las líneas contradictorias de la puerta como un diagnóstico. Si tu línea de delta medio pasa mientras que tu línea de tasa de victorias falla estrepitosamente, eso no es un resultado mixto para promediar. Es la saturación anunciándose.
• Califica la moderación, no solo la capacidad. Una vez que ambos sistemas pueden hacer la tarea, las fallas discriminantes son el exceso de entrega, las fugas de audiencia, los excesos en citas y afirmar hechos no verificados. Escribe tareas que un modelo fuerte falle por hacer demasiado.
• Diseña al menos una tarea que tu línea base perderá. Si nada separa a tus sistemas, no los has medido. Has medido tu conjunto de tareas y encontrado que era demasiado fácil.
• Congela y hashea el conjunto canónico. Así ni tú ni un lanzamiento futuro podéis seleccionar en silencio las tareas que producen la respuesta que deseabais.

La trampa no es que la línea base fuera buena. Las buenas líneas base son el objetivo. La trampa es leer una tasa de victorias como un hecho sobre el desafiante cuando se había convertido en un hecho sobre las tareas. Cuando tu comparación se satura, la evaluación ha terminado de decirte cosas sobre tus modelos y ha comenzado a decirte cosas sobre tu criterio de evaluación. El movimiento útil es escuchar ese segundo mensaje y escribir una tarea lo suficientemente difícil como para hacer que un modelo fuerte falle.

Las cifras anteriores provienen de una evaluación interna de comparación directa, ejecutada el 11-06-2026, línea base claude-opus-4-6 (un solo turno) frente a un pipeline de múltiples pasos de planificar-ejecutar-verificar, juzgado por claude-haiku-4-5, sobre 14 tareas en un espacio de trabajo de fixture completamente sintético sin contenido de clientes. Puntual a fecha de esa ejecución. Contexto normativo: ISO/IEC 27001:2022, RGPD (Art. 28, Art. 30).