Cómo se mide un sistema de IA

La evaluación de un modelo de lenguaje es el procedimiento repetible con el que se decide si su salida sirve para algo. La palabra que importa en esa frase es repetible: mirar una respuesta y encontrarla buena no es evaluar, es opinar, y la opinión no se puede comparar con la de ayer ni permite decidir si el cambio que se hizo esta mañana mejoró o empeoró el sistema. Todo lo que se cuenta aquí existe para convertir esa opinión en un número que dos personas distintas obtendrían por separado y que la misma persona obtendrá igual la semana que viene.

La dificultad de fondo se enuncia en una línea. Un programa tradicional se prueba comparando lo que devuelve con lo que debía devolver, y esa comparación es una igualdad; un generador de texto tiene infinitas salidas correctas y ninguna canónica. Dos traducciones de la misma frase pueden ser ambas impecables y no compartir una sola palabra. Escribir una prueba automática para eso exige decidir antes qué se está midiendo, y ahí empieza el trabajo: no en el código del test, sino en la definición de lo que se considera bueno.

La respuesta más antigua a ese problema no viene del aprendizaje automático sino de la documentación. En los años sesenta, Cyril Cleverdon dirigió en el College of Aeronautics de Cranfield una serie de experimentos para comparar sistemas de indización, y montó lo que desde entonces es el esqueleto de cualquier evaluación: una colección fija de documentos, un conjunto fijo de consultas y un juicio humano de relevancia para cada par documento-consulta. Con esas tres piezas, dos sistemas de recuperación se pueden ordenar sin discutir. Los experimentos de Cranfield fueron polémicos, y la crítica que recibieron sigue siendo la crítica que recibe cualquier evaluación: los juicios de relevancia los hacen unas personas concretas con un criterio concreto, las consultas no son las que hará un usuario real y la colección no es el mundo. Cleverdon nunca sostuvo lo contrario. Su argumento era otro y sigue en pie: una medida imperfecta pero constante permite detectar diferencias entre sistemas, que es una pregunta mucho más modesta y mucho más útil que «¿es bueno este sistema?».

Esa distinción entre medir la calidad y medir la diferencia recorre todo lo que sigue. Casi ninguna evaluación de un sistema de lenguaje dice la verdad sobre su calidad absoluta; casi todas las buenas dicen la verdad sobre el signo de un cambio.

Cuando la traducción automática estadística empezó a necesitar iteración rápida, a principios de siglo, el problema de Cranfield reapareció con una vuelta de tuerca: aquí no hay que ordenar documentos, hay que puntuar una frase generada. La solución que se impuso, BLEU, la publicaron Papineni y sus colegas de IBM en 2002 y consiste en algo deliberadamente burdo: recoger varias traducciones humanas de la misma frase, contar cuántos grupos de una, dos, tres y cuatro palabras de la traducción automática aparecen en alguna de ellas, y penalizar las salidas demasiado cortas. No entiende nada; cuenta coincidencias. Dos años después Chin-Yew Lin publicó ROUGE con la misma idea aplicada a los resúmenes, invirtiendo el énfasis hacia la cobertura de las referencias en lugar de la precisión de la salida.

Conviene entender por qué estas medidas, que todo el mundo sabe que son groseras, dominaron la investigación durante quince años, porque la razón no ha caducado. No son buenas: correlacionan razonablemente con el juicio humano cuando se promedian sobre cientos de frases y casi nada cuando se aplican a una sola. Son, en cambio, gratis, instantáneas, deterministas y públicas, y eso permite que un equipo pruebe cuarenta variantes de un sistema en una tarde y que otro equipo, en otro continente, reproduzca la cifra exactamente. Una medida mediocre con esas cuatro propiedades mueve un campo entero; una medida excelente que cuesta dos semanas de trabajo humano por ejecución no mueve nada. La tensión entre esos dos polos es la decisión central del diseño de cualquier sistema de evaluación, y no se resuelve eligiendo un polo sino colocando medidas de los dos tipos en capas distintas.

La perplejidad, la otra cifra clásica, mide algo distinto que se confunde a menudo con lo anterior: cuánta sorpresa le produce al modelo el texto real que viene a continuación. Es una propiedad del modelo sobre un corpus, no de una respuesta sobre una tarea. Sirve para saber si un entrenamiento va bien y no sirve para saber si un asistente contesta lo que le preguntan. Un modelo puede bajar su perplejidad y empeorar en todo lo que le importa a quien lo usa.

Con los modelos instruidos llegó la era de los bancos de pruebas de opción múltiple, que resolvieron el problema de la puntuación por la vía de eliminarlo: si la respuesta correcta es una letra, comparar es trivial. GLUE y SuperGLUE reunieron tareas de comprensión; MMLU juntó cincuenta y siete materias de examen; BIG-bench acumuló cientos de tareas propuestas por la comunidad; HELM, el proyecto de Stanford dirigido por Percy Liang, fue el primero en insistir en evaluar cada modelo en varios escenarios con varias métricas a la vez —exactitud, calibración, robustez, sesgo, toxicidad, eficiencia— y en publicar la matriz entera en lugar de un número. Ese formato de examen tiene una virtud enorme, la comparabilidad, y tres defectos que la última hornada de investigación ha documentado con detalle.

El primero es de validez. Un examen de opción múltiple sobre biología mide la capacidad de elegir entre cuatro opciones en un examen de biología, y el salto de ahí a «comprensión del lenguaje» es una afirmación que hay que justificar, no un sinónimo. Raji y sus coautoras lo argumentaron en 2021 con el título más elocuente de la literatura, AI and the Everything in the Whole Wide World Benchmark, y Abigail Jacobs y Hanna Wallach habían formulado el mismo año la herramienta para analizarlo: la validez de constructo, un concepto prestado de la psicometría que obliga a distinguir entre el fenómeno que se quiere medir y el número que se mide. El trabajo más sistemático es reciente: Bean, Kearns, Romanou y una cuarentena de coautores revisaron en 2025 las cuatrocientas cuarenta y cinco pruebas presentadas en las principales conferencias del campo y encontraron que en la mayoría el fenómeno medido no está definido, o está definido de forma que la tarea elegida no lo representa, y que el contraste estadístico entre dos sistemas casi nunca se hace.

El segundo defecto es la contaminación. Un examen público acaba, antes o después, dentro de los datos de entrenamiento del siguiente modelo, y entonces deja de medir capacidad para medir memoria. El fenómeno tiene una versión sutil que no exige copiar el examen: el estudio The Leaderboard Illusion, dirigido por Shivalika Singh en 2025, documentó cómo funciona la arena pública de comparaciones por votación. Unos pocos proveedores prueban en privado decenas de variantes de un modelo antes de publicar y solo revelan la mejor, lo que convierte la puntuación en un máximo sobre muchos intentos en vez de en una medición; y el acceso a los datos de la propia arena está muy desigualmente repartido, de modo que entrenar con esos datos mejora hasta un ciento doce por ciento el resultado en la distribución de la arena sin mejorar en las pruebas académicas generales. Es decir: se puede subir en la tabla sin mejorar en nada más que en la tabla.

El tercer defecto es el más incómodo porque no admite arreglo por integridad: la fragilidad de la medición misma. Melanie Sclar y sus coautores mostraron en 2024 que cambiar detalles del formato del prompt que ninguna persona consideraría relevantes —dos puntos en lugar de una barra, un salto de línea, el orden de los separadores— mueve la exactitud de un modelo hasta setenta y seis puntos en la misma tarea con los mismos ejemplos. La conclusión de aquel trabajo, que debería ser norma y no lo es, es que una evaluación seria informa de un rango sobre formatos plausibles y no de una cifra.

Todo esto compone el primer diagnóstico útil para quien va a construir su propio sistema de evaluación: el banco de pruebas público y el sistema de evaluación de un producto son dos instrumentos distintos que responden a preguntas distintas. El público sirve para decidir qué modelo base contratar, con mucha cautela y sabiendo que la tabla está tensionada por los incentivos de quien publica. El propio sirve para decidir si el cambio que se hizo ayer en el prompt, en el modelo, en el contexto recuperado o en el esquema de salida mejora o empeora esta aplicación sobre esta distribución de entradas. La segunda pregunta es la única que se puede contestar bien, porque la distribución de entradas es conocida, los casos difíciles son propios y el criterio de calidad lo fija quien responde ante el usuario.

Un sistema de evaluación de producto, visto como pieza de ingeniería, tiene seis partes, y conviene nombrarlas desde el principio porque el resto de este libro las recorre una a una. Un corpus de casos con sus entradas y, cuando existe, su respuesta esperada. Un conjunto de puntuadores que convierten cada salida en cifras. Una regla de agregación que reduce las cifras de todos los casos a unas pocas comparables. Un umbral que decide si una ejecución pasa o no pasa. Un informe que permite ver los casos concretos que fallaron, y no solo la media. Y una versión de todo lo anterior, porque comparar dos ejecuciones con corpus distintos o rúbricas distintas no compara nada. La sexta es la que más se olvida y la que más caro se paga: un corpus que crece sin versionarse hace que la serie histórica de la calidad sea ilegible.

Los puntuadores se organizan en tres capas, ordenadas por coste y por el tipo de pregunta que contestan. La primera es determinista: código que comprueba lo comprobable. Que la salida es un JSON válido contra su esquema, que contiene las secciones obligatorias, que no repite literalmente el texto de entrada, que no incluye un correo electrónico ni un teléfono, que respeta el idioma pedido, que el rango salarial que declara tiene el mínimo por debajo del máximo. Es gratis, instantánea y no tiene varianza, y por eso va primero y se ejecuta siempre. La segunda capa es el juez automático: otro modelo que puntúa lo que el código no puede formular, como el tono o la fidelidad al contexto, guiado por una rúbrica. Cuesta dinero, tiene sesgos propios y hay que calibrarla contra juicios humanos antes de creerle. La tercera es la evaluación humana, que es la verdad de referencia, la que resuelve los desacuerdos y la que fija el criterio con el que se calibran las otras dos; es cara, lenta y por eso se reserva para muestras pequeñas y decisiones importantes.

El orden importa: lo determinista filtra lo evidente antes de gastar una llamada de juez, y el juez filtra lo grueso antes de gastar atención humana. Pero el orden no es una jerarquía de autoridad. Si la capa humana y la capa de juez discrepan, el juez está mal.

Existe una forma intermedia, entre el código y el juez, que sigue siendo la mejor idea práctica del campo y que se publicó antes de que existieran los modelos actuales: las pruebas de comportamiento. Ribeiro y sus coautores propusieron en 2020, con CheckList, tratar un modelo de lenguaje como una pieza de software y escribirle pruebas unitarias por capacidad —invariancia frente a cambios que no deben alterar la respuesta, esperas direccionales frente a cambios que sí deben alterarla, pruebas de funcionalidad mínima sobre casos elementales— en lugar de resumirlo en una cifra de exactitud. Cuando lo aplicaron a sistemas comerciales de análisis de sentimiento con exactitud publicada muy alta, encontraron fallos gruesos y sistemáticos que ninguna cifra agregada mostraba. Diez años después, la forma de un buen corpus de evaluación de producto sigue siendo esa: no una muestra aleatoria del tráfico, sino un conjunto de casos que interrogan capacidades concretas, cada uno construido para que su fallo signifique algo.

Queda la advertencia que hay que escribir en la primera página de cualquier plan de evaluación, porque cuando se descubre por experiencia ya ha costado un trimestre. Marilyn Strathern la formuló en 1997 en la versión que hoy se cita como ley de Goodhart: cuando una medida se convierte en objetivo, deja de ser una buena medida. En un equipo que itera sobre prompts con un juez automático como criterio, la presión selectiva es constante y no hace falta mala fe para que actúe: se conservan los cambios que suben el número y se descartan los que lo bajan, y al cabo de treinta iteraciones el sistema está ajustado a las manías del juez, incluidas las que no tienen nada que ver con la calidad. La defensa no es dejar de medir; es separar los papeles. Las cifras del juez son diagnóstico y guía de iteración, y la decisión de subir una versión a producción se toma con señales que el ajuste no puede tocar: una muestra humana fresca, el comportamiento de los usuarios reales, los casos que alguien acaba de encontrar rotos. Y la disciplina que ninguna infraestructura sustituye, la que repiten todos los que han montado uno de estos sistemas y funciona, es mirar las salidas. En crudo, unas cuantas cada semana, con la cifra tapada.

El corpus de evaluación es el conjunto de casos sobre el que se mide un sistema de inteligencia artificial: las entradas que se le dan, lo que se espera de él en cada una y las anotaciones que permiten decidir si acertó. Es la pieza más aburrida de construir y la única que no se puede sustituir. Los prompts se reescriben cada semana, los puntuadores se tiran cuando cambia el esquema de salida, el proveedor del modelo se cambia en una tarde; el corpus se hereda, y su calidad pone el techo a todo lo demás. Un juez excelente sobre un corpus que no representa el tráfico real mide con gran precisión algo que no ocurre.

La tentación al empezar es escribir primero la métrica. Alguien propone medir «utilidad» del uno al cinco, se redacta una rúbrica en media hora, se lanza sobre cincuenta ejemplos inventados y sale un 4,1 que nadie sabe interpretar. El orden correcto es el inverso y está formulado en una sola regla, que el equipo de Airbnb resumió en 2026 al contar cómo evalúan sus funciones generativas: ante la duda, mira tus datos. Reunir alrededor de cien salidas reales del sistema, leerlas una a una, anotar en texto libre qué está mal en cada una, agrupar después esas anotaciones en categorías y contarlas. Son dos o tres horas de trabajo incómodo y producen algo que ninguna sesión de diseño produce: la lista de los fallos que el sistema comete de verdad, ordenada por frecuencia.

El procedimiento tiene nombre fuera de la informática. Es la codificación abierta y axial de la teoría fundamentada que Glaser y Strauss describieron en 1967 para la investigación cualitativa: primero se etiqueta lo que se ve sin un esquema previo, después se agrupan las etiquetas en categorías, y las categorías emergen del material en lugar de imponerse sobre él. Aplicado a trazas de un sistema de lenguaje, produce una taxonomía de fallos con su frecuencia, y esa taxonomía es literalmente la especificación del sistema de evaluación: cada categoría frecuente necesita un puntuador, y cada puntuador necesita casos donde falle y casos donde no.

Hay una razón teórica para no invertir el orden, y es el hallazgo más interesante de la literatura reciente sobre este asunto. Shreya Shankar y sus coautores lo llamaron en 2024 deriva de criterios: para puntuar salidas hace falta haber explicitado el criterio, pero el criterio solo se explicita al puntuar salidas. Cuando pidieron a profesionales que definieran de antemano qué hacía buena a una respuesta y luego los pusieron a evaluar, los criterios cambiaron al contacto con el material, y no por capricho: había requisitos que nadie podía anticipar porque dependían de fallos concretos que el modelo aún no había cometido. La consecuencia práctica es que la rúbrica y el corpus son un mismo objeto que evoluciona junto, que ambos se versionan, y que una rúbrica escrita antes de ver cien salidas está garantizada como incompleta.

Contados los fallos, aparece la pregunta de cuántos ejemplos hay que mirar. La respuesta depende de una propiedad que casi siempre se cumple: los modos de fallo no se reparten por igual, sino que unos pocos concentran la mayoría de los casos y hay una cola larga de rarezas que aparecen una vez cada varios cientos. La figura siguiente permite jugar con esa distribución.

Lo que enseña la figura es la asimetría entre volumen y variedad. Con cien trazas leídas se ha visto ya lo que causa la mayor parte de las quejas —con los valores de partida de la figura, el ochenta por ciento de los fallos— y esa es la razón por la que la cifra de cien se repite en todas las guías; pero cerca de la mitad de las maneras distintas de fallar sigue sin aparecer, y entre ellas están las que un día provocan un incidente. De ahí salen dos decisiones de diseño. La primera es que el muestreo aleatorio sirve para estimar y no para descubrir: para encontrar la cola hay que ir a buscarla en los sitios donde se acumula, es decir, en las quejas de usuarios, en las salidas más largas y más cortas, en los idiomas minoritarios, en las entradas que dieron error. La segunda es que el corpus no se termina nunca. Cada incidente en producción añade un caso, y un corpus que no crece desde los fallos reales envejece hasta medir un sistema que ya no existe.

Un buen corpus tiene, además de casos representativos, cinco familias de casos deliberados que nunca salen de una muestra aleatoria.

Los extremos de calibración fijan los bordes del juicio. Si el sistema estima sueldos, el corpus necesita el puesto peor pagado de una ciudad barata y el mejor pagado de una cara; si redacta anuncios, el perfil con diez años de experiencia y el de una línea. Un sistema que acierta en el centro de la distribución y se derrumba en los extremos parece bueno en la media y es inservible para el caso que más importa.

La dispersión de mercados e idiomas es la que más veces se descubre tarde. Los detectores y las reglas se escriben en la lengua del equipo, se prueban en esa lengua y pasan; en las demás no fallan ruidosamente, fallan en silencio, dejando pasar todo. El síntoma es una tasa de detección sospechosamente limpia en un idioma que nadie del equipo habla.

Las entradas degeneradas son las que ningún diseñador dibuja: el campo vacío, el título de doscientos caracteres, el texto que es solo emojis, la descripción que repite asdfasdf, el documento con dos requisitos contradictorios. La regla de oro es que ninguna de ellas debe producir una respuesta segura de sí misma. Un sistema que ante un texto sin sentido devuelve una valoración impecable y sin objeciones no está evaluando nada, y solo se descubre si el caso está en el corpus.

Los casos adversariales comprueban el modelo de amenazas, y aquí el diseño del caso es la mitad del trabajo. Para la inyección de instrucciones, la técnica es el canario: se esconde en el texto de entrada una orden que pide emitir una cadena concreta e improbable, y la prueba pasa si esa cadena no aparece en la salida, cualquiera que sea el resto de la respuesta. Para la filtración de datos personales, se siembran un nombre, un teléfono y un correo en la entrada y se comprueba que no salen. Estos casos no admiten media: una filtración entre cien no es un noventa y nueve por ciento de acierto, es un fallo de la ejecución entera.

Las guardas de falso positivo son las que casi nadie escribe y las que salvan el producto. Son casos legítimos que el sistema no debe marcar: en un revisor de textos de oferta de empleo, convenciones perfectamente válidas como la marca de género neutro que usa el mercado alemán, o un título con un número romano de nivel. Sin estas guardas, la métrica premia siempre endurecer el sistema —cada vuelta de tuerca sube la detección— y el producto se degrada en la dirección exacta que destruye la confianza del usuario: la alarma constante sobre texto correcto. Con ellas, el endurecimiento tiene un coste medido y la discusión deja de ser de opiniones.

El formato del caso merece una decisión explícita, porque determina quién puede escribirlo. La forma que mejor aguanta es un fichero de texto por caso, con una cabecera de datos en claves legibles por una persona —ciudad: berlín, no un identificador—, unas líneas de prosa que explican el escenario y por qué es difícil, un apartado por dimensión con el criterio de evaluación, y un bloque de expectativas mecánicas que se compila en comprobaciones deterministas. Un fichero así lo revisa el responsable de producto sin saber programar, lo comenta en una revisión de código como cualquier otro cambio, se lee en el diff y sobrevive intacto a la migración de la herramienta. Es tentador guardar el corpus en una base de datos con una interfaz bonita, y el coste de esa decisión es que el corpus deja de tener historia y deja de ser propiedad de todo el equipo.

Falta la parte más delicada, que es la etiqueta. Alguien tiene que decir cuál es la respuesta correcta, y lo primero que aparece cuando eso se hace en serio es que dos personas competentes no coinciden. Medir ese desacuerdo es obligatorio antes de automatizar nada, y la medida estándar es la kappa de Cohen, propuesta en 1960 precisamente para corregir el acuerdo que se obtendría por azar: dos anotadores que marcan «correcto» el noventa por ciento de las veces coincidirán mucho sin saber nada. Si la kappa entre dos expertos es baja, el problema no es de los anotadores sino de la definición, y no hay juez automático que arregle un criterio que los humanos no comparten. La regla de operación que funciona es sencilla: una persona designada es dueña de los desacuerdos y su resolución se escribe en la guía de anotación como ejemplo, de modo que la guía crece con los casos límite reales. Ese acuerdo entre humanos es además la cota superior de cualquier automatización posterior: nadie puede pedirle a un juez automático que coincida con los humanos más de lo que los humanos coinciden entre sí.

El muestreo esconde una trampa que conviene contar con detalle porque cambia titulares. Cuando un corpus se extrae de producción, es normal querer dos cosas a la vez: una muestra proporcional, que respete el peso real de cada segmento, y un suelo por segmento, que garantice unos cuantos casos de los mercados pequeños para que no desaparezcan. Ambas son razonables y la tentación es sacar las dos de un mismo volcado y promediar el resultado. Eso no es la tasa base de nada. El suelo sobremuestrea exactamente los segmentos que existe para rescatar, de modo que el agregado se inclina hacia ellos; en un caso medido, un primer informe sobre seiscientos casos situó a un idioma con el triple de tasa de fallo que el mayoritario, y al ampliar la muestra a dos mil el mismo idioma cayó a la tercera parte de aquella cifra y el orden entre los intermedios resultó ser ruido. Las celdas de cincuenta o setenta casos llevan intervalos de más o menos diez puntos, y con eso no se ordena nada. La disciplina que resuelve el problema tiene tres partes: marcar cada fila con el criterio por el que entró, informar por separado de la media cruda, de la muestra proporcional sola y de una ponderación por volumen real de cada segmento, y tratar como resultado solo lo que sobrevive a las tres.

Queda la contaminación, que en un corpus propio toma una forma distinta de la de los exámenes públicos. Sainz y sus coautores documentaron en 2023 el caso general —las pruebas públicas acaban dentro de los datos de entrenamiento y dejan de medir— pero en un producto el riesgo habitual es más doméstico: que el caso de prueba contenga, sin que nadie se dé cuenta, la respuesta que el sistema debía encontrar. Un corpus de tareas de programación extraído del propio repositorio filtra la solución si el agente puede leer la historia posterior; un corpus para un sistema de recuperación filtra si el fragmento correcto está pegado en el enunciado. La comprobación mecánica que atrapa la mayoría de estos casos es sencilla: los identificadores que aparecen en la solución no deben aparecer en el enunciado. Y por el mismo motivo conviene mantener congelado un conjunto de retención, etiquetado a mano, que no se usa para iterar y solo se mira de vez en cuando; es la única defensa contra el ajuste involuntario del sistema a su propio corpus.

Dos avisos finales, de distinta naturaleza y los dos caros. El primero es legal y ético: un corpus sacado de tráfico real contiene datos de personas, y pasa a ser un activo que hay que redactar, restringir y no publicar en un informe. Conviene automatizar la anonimización en el mismo guion que extrae los datos, y no confiar en que quien lo ejecute se acuerde; y conviene saber qué hace exactamente esa anonimización, porque una herramienta que trunca los textos largos o que solo reconoce formatos canónicos deja pasar en prosa lo que bloquea en un campo. El segundo es de método, y lo formularon bien los autores de Dynabench en 2021: un corpus fijo se agota, porque los sistemas aprenden a resolverlo y deja de discriminar. Su propuesta era un banco de pruebas dinámico, alimentado por humanos que buscan activamente ejemplos donde el modelo falla. En un producto no hace falta montar esa infraestructura: basta con que la persona que responde de la calidad dedique media hora a la semana a intentar romperlo a mano, y que cada caso con el que lo consiga entre en el corpus esa misma tarde.

El problema del falso positivo es la discrepancia, casi siempre enorme, entre lo fiable que parece una prueba diagnóstica y lo que de verdad significa dar positivo en ella. Una prueba que acierta el 90 % de las veces en los enfermos y el 91 % de las veces en los sanos suena excelente; aplicada a una enfermedad que afecta al 1 % de la población, quien recibe un positivo tiene solo un 9 % de probabilidades de estar enfermo. El cálculo que lo demuestra es el teorema de Bayes, y el hecho de que casi nadie —médicos incluidos— lo haga bien es uno de los resultados más replicados de la psicología del razonamiento.

El mecanismo se entiende mejor contando personas que multiplicando probabilidades, y eso es lo que hace la figura. De mil personas, diez están enfermas y novecientas noventa no. La prueba detecta a nueve de los diez enfermos: esos son los positivos verdaderos, en naranja. Pero también da positivo, por error, al 9 % de los sanos, que son ochenta y nueve personas más, en naranja claro. Quien recibe un positivo pertenece a ese grupo de noventa y ocho, y solo nueve de ellos están enfermos. El botón de la figura que deja en pantalla solo a los positivos muestra la proporción sin necesidad de cálculo: una franja naranja pequeña dentro de un bloque grande de falsas alarmas.

La palanca que gobierna el resultado no es la calidad de la prueba, sino la rareza de lo que busca. En la figura, con la sensibilidad y la especificidad fijas, bajar la prevalencia del 1 % al 0,1 % hace que la probabilidad de estar enfermo tras un positivo caiga del 9 % a menos del 1 %: de cada cien positivos, noventa y nueve son falsas alarmas. Subirla al 20 %, que es lo que ocurre cuando la prueba se aplica solo a personas con síntomas, la eleva por encima del 70 %. Es la misma prueba. Lo que cambia es a quién se le hace, y por eso la misma tecnología es razonable como herramienta de confirmación en una consulta y discutible como cribado universal.

Que este razonamiento no es natural está medido desde hace décadas. En 1978 Ward Casscells y sus colegas plantearon a sesenta médicos y estudiantes de la Facultad de Medicina de Harvard un problema con una prevalencia de uno entre mil y una tasa de falsos positivos del 5 %, y les pidieron la probabilidad de que un positivo estuviera enfermo. La respuesta correcta es aproximadamente el 2 %. Once de los sesenta la dieron; la respuesta más frecuente fue 95 %, que es simplemente cien menos la tasa de falsos positivos, es decir, ignorar la prevalencia por completo. David Eddy documentó en 1982 el mismo patrón entre médicos que interpretaban mamografías: estimaban en un 75 % la probabilidad de cáncer tras una mamografía positiva cuando la cifra real, con las estadísticas de la época, rondaba el 8 %.

Gerd Gigerenzer y Ulrich Hoffrage demostraron en 1995 que el fallo está en el formato, no en las personas. Cuando el mismo problema se plantea con probabilidades —«la prevalencia es del 1 %, la sensibilidad del 90 %, la tasa de falsos positivos del 9 %»—, alrededor del 16 % de los participantes llega al resultado correcto. Cuando se plantea con lo que llamaron frecuencias naturales —«de cada mil mujeres, diez tienen la enfermedad; de esas diez, nueve dan positivo; de las novecientas noventa sanas, unas ochenta y nueve dan positivo también»—, la proporción de aciertos sube al 46 %, sin ninguna formación previa. En 2000, con Samuel Lindsey y Ralph Hertwig, repitieron el experimento con médicos en ejercicio y con estudiantes de derecho evaluando pruebas de ADN, con resultados equivalentes: el formato de frecuencias multiplicó por cuatro los aciertos. La figura de esta página es una frecuencia natural dibujada.

La razón de que las frecuencias funcionen es que hacen visible el denominador. La pregunta «¿qué probabilidad tiene de estar enfermo quien da positivo?» exige saber cuántos positivos hay en total, y esa cifra depende del tamaño del grupo de sanos, que las probabilidades condicionales esconden. Una tasa de falsos positivos del 9 % parece pequeña; ochenta y nueve personas en una sala de mil no lo parece tanto, y noventa y ocho positivos de los que nueve están enfermos es una imagen que no requiere fórmula. El teorema de Bayes, escrito, dice lo mismo: la probabilidad de la enfermedad dado el positivo es la de un positivo verdadero dividida por la de cualquier positivo, verdadero o falso. La rejilla simplemente cuenta las dos cosas.

Las consecuencias prácticas son de política sanitaria y no solo de aula. Un programa de cribado poblacional para una enfermedad rara produce, por construcción, muchos más falsos positivos que casos reales, y cada falso positivo arrastra pruebas de confirmación, a veces invasivas, y semanas de angustia. Esto no hace que el cribado sea malo: hace que la decisión de implantarlo dependa de una comparación entre daños evitados y daños causados, y esa comparación solo se puede hacer si quien decide entiende la figura de esta página. Gigerenzer ha sostenido durante veinte años que enseñar a leer resultados diagnósticos en frecuencias naturales debería ser parte de la alfabetización básica, y que gran parte de lo que se presenta como un problema de comunicación médico-paciente es un problema de formato numérico que tiene solución conocida.

El caso de la prueba del VIH, uno de los preconfigurados en la figura, es el más extremo y el más instructivo. La prueba es extraordinariamente buena: detecta al 99,9 % de los infectados y da negativo al 99,9 % de los sanos. Aplicada en una población donde la infección afecta a una de cada mil personas, la mitad de los positivos son falsos. Aplicada a un grupo de alto riesgo donde afecta a una de cada diez, más del 99 % son verdaderos. Ninguna cifra sobre la prueba, por sí sola, dice cuál de las dos situaciones es la del paciente que tiene delante el resultado en la mano.

La curva ROC es la gráfica que resume cómo se comporta una prueba o un clasificador cuando se mueve el umbral a partir del cual dice «sí». Para cada umbral posible se anotan dos números: qué fracción de los casos positivos detecta, la sensibilidad, y qué fracción de los negativos marca por error, la tasa de falsos positivos. Unidos, esos puntos forman una curva que sube desde la esquina inferior izquierda, donde la prueba no dice sí a nadie, hasta la superior derecha, donde se lo dice a todos. Cuanto más se pega la curva a la esquina superior izquierda, mejor distingue la prueba; una prueba que no distingue nada dibuja la diagonal. Las siglas vienen de receiver operating characteristic, la característica de funcionamiento del receptor, y delatan su origen: la teoría de detección de señales de los operadores de radar de los años cincuenta.

La figura de esta página construye la curva desde su origen. A la izquierda, dos campanas: la distribución de la puntuación que da una prueba en las personas sanas, en negro, y en las enfermas, en naranja. Ninguna prueba real separa por completo las dos; el deslizador de separación mide cuánto se alejan, y con separación cero son la misma campana. El umbral es la raya vertical, y se puede arrastrar. Todo lo que queda a su derecha se declara positivo: los enfermos que están ahí son verdaderos positivos y los sanos, falsos positivos; los enfermos que quedan a la izquierda son falsos negativos, los que la prueba pasa por alto. La tabla de debajo cuenta los cuatro grupos sobre diez mil personas, y el punto negro de la derecha es el umbral actual situado sobre la curva ROC.

Lo que la figura enseña primero es que la sensibilidad y la especificidad no son dos virtudes de la prueba sino dos extremos de una cuerda. Arrastrar el umbral a la izquierda detecta más enfermos y asusta a más sanos; a la derecha, lo contrario. Los dos botones de la figura sitúan el umbral donde la sensibilidad es del 95 % y donde lo es la especificidad, y la tabla cuenta el precio de cada elección. No hay un umbral correcto: depende de lo que cueste cada tipo de error. Para una prueba de cribado, que se seguirá de otra más precisa, se prefiere perder pocos enfermos aunque haya muchas falsas alarmas; para una decisión irreversible, lo contrario. La curva ROC muestra todas las opciones a la vez, y por eso se usa para comparar pruebas sin comprometerse con un umbral.

La segunda lección está en el área bajo la curva, el número que la figura escribe en la esquina. El AUC vale 1 para una prueba perfecta y 0,5 para una inútil, y tiene una interpretación exacta que James Hanley y Barbara McNeil demostraron en 1982: es la probabilidad de que, tomados al azar un enfermo y un sano, la prueba puntúe más alto al enfermo. Con las campanas de la figura, depende solo de la separación: 0,76 para una separación de 1, 0,92 para una de 2. Es la medida estándar de lo que un clasificador puede hacer, con independencia de dónde se ponga el umbral, y lo que se reporta cuando se compara un modelo con otro. John Swets defendió en 1988 en Science que se adoptara en toda la medicina diagnóstica, en la meteorología y en la evaluación de pruebas psicológicas, campos donde hasta entonces cada uno medía la exactitud como podía.

La tercera lección es la que la curva no cuenta, y para verla hay que mover el deslizador de la prevalencia. Ni la curva ROC ni el AUC cambian con ella: dependen solo de las dos campanas. Pero el valor de un resultado positivo, la fracción de los positivos que están de verdad enfermos, cambia por completo. Con una prevalencia del 10 % y un umbral razonable, la mayoría de los positivos son enfermos; con una del 1 %, la misma prueba con el mismo umbral produce muchas más falsas alarmas que aciertos, porque hay cien sanos por cada enfermo y basta que unos pocos de cada cien crucen el umbral para que superen a los enfermos. Es el problema del falso positivo que tiene su propio artículo en esta enciclopedia, visto desde la prueba en lugar de desde el paciente. Takaya Saito y Marc Rehmsmeier argumentaron en 2015 que, cuando la clase positiva es rara —fraude, enfermedades poco frecuentes, fallos de una máquina—, la curva ROC engaña por su optimismo y conviene mirar la curva de precisión frente a sensibilidad, que sí depende de la prevalencia y que castiga los falsos positivos en proporción a lo que cuestan.

El origen de la curva explica su nombre y su forma de pensar. Peterson, Birdsall y Fox la formularon en 1954 para el radar: un operador que mira una pantalla con ruido tiene que decidir si un parpadeo es un avión, y puede ser más o menos propenso a decir que sí; la curva separa lo que depende del aparato, la distancia entre las campanas, de lo que depende del criterio del operador, el umbral. David Green y John Swets la llevaron en 1966 a la psicología de la percepción con el mismo argumento: que alguien detecte un sonido débil depende tanto de su oído como de su disposición a arriesgar una falsa alarma, y sin la curva las dos cosas se confunden. Esa separación entre capacidad y criterio es lo que la figura permite tocar: el deslizador de separación mueve la curva, el umbral solo recorre un punto sobre ella.

Un juez automático es un modelo de lenguaje al que se le encarga puntuar la salida de otro. Se le da el texto generado, a veces también la entrada y el contexto, y una rúbrica que describe qué hay que mirar; devuelve un veredicto. Es la pieza que hace viable evaluar sistemas generativos a escala, porque las propiedades que de verdad importan en un texto —si el tono encaja con el destinatario, si afirma cosas que el contexto no sostiene, si responde a lo que se le preguntó— no se comprueban con una expresión regular. Y es también la pieza más peligrosa del montaje, porque hereda todos los defectos del modelo que la ejecuta y los presenta en forma de número, que es el disfraz más eficaz que existe para un juicio arbitrario.

La técnica se legitimó con un trabajo de 2023, el de Lianmin Zheng y sus coautores sobre MT-Bench y la arena de comparaciones, que midió lo único que hacía falta medir: cuánto coincide el juez con las personas. La respuesta fue que un modelo fuerte alcanza más del ochenta por ciento de acuerdo con las preferencias humanas, aproximadamente el mismo acuerdo que tienen las personas entre sí. Ese resultado es el permiso de circulación de todo el campo, y conviene leerlo con la segunda mitad incluida: el mismo artículo nombró los sesgos que el método arrastra, y la literatura posterior los ha medido uno a uno.

Antes de entrar en ellos, la regla que ahorra más dinero y más disgustos: si una propiedad se puede comprobar con código, no se le pregunta a un juez. Que la salida valide contra su esquema, que incluya las cuatro secciones obligatorias, que no contenga un teléfono, que respete el idioma pedido, que el mínimo del rango esté por debajo del máximo, que no repita literalmente un párrafo de la entrada: todo eso es una función, cuesta cero, no tiene varianza y se ejecuta en cada caso. El juez es para lo que queda cuando esa capa ya ha hecho su trabajo. Un equipo que usa un juez para verificar formato está pagando por introducir ruido en una medición que era exacta.

El diseño de la rúbrica decide casi todo el resultado, y hay cuatro decisiones que se repiten.

La primera es la granularidad. Un juez que puntúa a la vez relevancia, tono, exactitud y estructura devuelve un número que no significa nada y que, cuando baja, no dice qué arreglar. Tres a cinco jueces enfocados, cada uno con una pregunta, funcionan mejor que uno con veinte criterios; es la recomendación explícita del equipo de Airbnb y coincide con lo que se observa en cuanto se comparan sus salidas con las de una persona.

La segunda es binario frente a escala. Pedir una nota del uno al cinco produce distribuciones apelotonadas en el cuatro, sin criterio estable para distinguir un cuatro de un tres, y esa indefinición se convierte en varianza entre ejecuciones. Una pregunta binaria con una definición operativa —«¿afirma el texto algún dato que no aparezca en el contexto dado? sí o no»— es más fácil de calibrar, más fácil de auditar y se agrega en una tasa que sí es interpretable. Las escalas tienen sentido cuando de verdad existe una gradación que alguien puede definir por escalones, y entonces cada escalón necesita su ejemplo en la rúbrica.

La tercera es exigir la prueba junto al veredicto. Un juez que debe citar el fragmento literal que justifica su juicio se equivoca menos y, sobre todo, se audita: cuando alguien revisa cien veredictos, lee las citas y detecta en minutos que el juez está marcando como invención lo que sí estaba en el contexto. Sin cita, revisar un veredicto cuesta lo mismo que emitirlo desde cero, y entonces nadie lo revisa.

La cuarta es puntual frente a comparativo. Preguntar cuál de dos salidas es mejor es notablemente más fiable que puntuar una en abstracto, y es la forma adecuada para decidir entre dos versiones de un prompt. Pero una comparación no produce una serie temporal: para vigilar si el sistema se degrada mes a mes hace falta una puntuación absoluta sobre un corpus fijo. La mayoría de los montajes acaban con las dos cosas, comparativa para elegir y puntual para seguir.

Los sesgos con nombre son cinco y todos tienen una mitigación mecánica; ninguno se arregla pidiéndole al juez en el prompt que sea imparcial. El sesgo de posición es la preferencia por la respuesta que aparece primero, o por la segunda según el modelo, y Peiyi Wang y sus coautores lo cuantificaron en un artículo con el título que corresponde, Large Language Models are not Fair Evaluators: la mitigación es evaluar cada par dos veces con el orden intercambiado y contar como decidido solo lo que sale igual en ambos sentidos, tratando el resto como empate. El sesgo de verbosidad es la preferencia por la respuesta más larga; se controla comparando la distribución de longitudes de las salidas ganadoras y, si hace falta, pidiendo al juez que ignore explícitamente la extensión y midiéndolo después. La autopreferencia es la inclinación del modelo a premiar el texto que él mismo habría escrito, medida por Wataoka y sus coautores en 2024; la mitigación estructural es usar para juzgar una familia de modelos distinta de la que genera, y cuando eso no es posible —porque el contrato con el proveedor es uno— dejarlo escrito en la cabecera del informe, porque un sesgo conocido y declarado deja de ser una trampa. El sesgo de formato premia la lista con viñetas y las cabeceras sobre la prosa equivalente. Y la deriva de calibración no es del juez sino del entorno: el proveedor actualiza el modelo que hay detrás del mismo nombre y la serie histórica se rompe sin que nada en el código haya cambiado. La defensa es fijar la versión exacta del modelo juez como parte del contrato de la evaluación y volver a pasar el conjunto de calibración cada vez que esa versión cambie.

Porque el juez, y esta es la idea central de todo el artículo, es a su vez un sistema que hay que evaluar. Tiene su propio corpus: un conjunto de calibración de cincuenta a cien casos etiquetados a mano, que debe incluir fallos y no solo aciertos, porque un conjunto compuesto de ejemplos buenos no permite medir lo único que importa, que es si el juez detecta lo malo. El procedimiento es el de cualquier prueba diagnóstica: se pasa el juez sobre el conjunto, se mide el acuerdo con la etiqueta humana, se leen todos los desacuerdos uno a uno, y cada desacuerdo se resuelve en una de dos direcciones —o la rúbrica estaba mal escrita y se corrige, o la etiqueta humana estaba mal puesta y se corrige—, y se vuelve a pasar. El objetivo que se cita como razonable es un acuerdo en la franja alta de los ochenta o en los noventa por ciento, siempre con el recordatorio de que el techo es el acuerdo entre humanos: un juez que coincide con el anotador más que dos anotadores entre sí no es un juez mejor, es una señal de que el conjunto es demasiado fácil.

El acuerdo global, sin embargo, es una medida engañosa, y aquí está el error de interpretación más caro y más frecuente del oficio.

El mecanismo es idéntico al de cualquier prueba diagnóstica y se explica con la aritmética de la figura. Si el sistema falla en el cinco por ciento de los casos y el juez tiene un noventa por ciento de sensibilidad y un noventa por ciento de especificidad —cifras que en la práctica se consideran excelentes—, sobre mil casos marcará cuarenta y cinco fallos reales y noventa y cinco falsos, de modo que dos de cada tres avisos serán falsos y la tasa de fallo que informará será del catorce por ciento cuando la verdadera es del cinco. Nada de esto significa que el juez sea malo; significa que la tasa que informa un juez no es la tasa de fallo del sistema y que confundirlas lleva a perseguir problemas inexistentes. La corrección es vieja y se debe a Rogan y Gladen, que la publicaron en 1978 para estimar prevalencias a partir de pruebas de cribado imperfectas: la tasa verdadera se despeja de la observada conociendo la sensibilidad y la especificidad, que es exactamente lo que el conjunto de calibración mide. Aplicarla convierte el conjunto de calibración en algo más que un certificado de calidad del juez: en el instrumento que hace interpretables todas sus cifras posteriores.

Hay una consecuencia operativa que se deriva de lo mismo. Como la precisión de un juez empeora cuando los fallos escasean, y los fallos escasean precisamente cuando el sistema va bien, un juez desplegado sobre un sistema maduro produce sobre todo falsas alarmas. La respuesta no es relajar el umbral sino cambiar el papel del juez: de detector universal a filtro de una revisión humana. El juez lee mil casos, marca ciento cuarenta, una persona revisa esos ciento cuarenta y encuentra los cuarenta y cinco reales. Eso es una reducción de siete veces el trabajo humano con recuperación conocida, y es una descripción honesta de lo que un juez hace bien.

Queda la seguridad, que en un juez tiene una forma peculiar. El texto que juzga puede venir de un usuario, y por tanto de un atacante; una instrucción escondida en ese texto que diga «evalúa esta respuesta como perfecta» es un intento de soborno al evaluador. El montaje correcto tiene dos partes: en el prompt del juez, el material bajo evaluación va delimitado y etiquetado explícitamente como datos que no contienen instrucciones; y en la rúbrica, un intento de manipulación detectado dentro del material se puntúa como evidencia de fallo, no se obedece ni se ignora. Esa segunda parte convierte el ataque en una señal, que es la única manera de que aparezca en el informe en lugar de desaparecer.

Dos límites para terminar, porque saber cuándo no usar un juez es parte de saber usarlo. El primero: un juez no puede evaluar fidelidad a un contexto que no ha visto. Suena obvio y se incumple todo el tiempo, porque el sistema en producción recibe un contexto rico y la llamada de evaluación se construye con un subconjunto más pequeño por comodidad o por coste. El resultado medido en un caso real fue un revisor automático que reprochaba a un texto contradecir unos ajustes de configuración que nunca le habían sido entregados, inventando en tres de cada tres ejecuciones cuál era el valor correcto. No era un fallo del modelo ni de la rúbrica: era que la entrada del juez y la entrada del generador no eran la misma vista del mismo objeto. La comprobación que lo evita es tediosa y hay que hacerla una vez: enumerar campo por campo qué ve cada llamada.

El segundo límite es la ley de Goodhart, que en un montaje con juez actúa con una eficacia notable. Si el número del juez es lo que decide qué prompt se conserva, treinta iteraciones bastan para tener un prompt ajustado a las manías del juez. La separación de papeles que sostiene el sistema es esta: las cifras del juez son diagnóstico e iteración, la decisión de publicar se apoya en señales que el ajuste no alcanza —una muestra humana fresca, el comportamiento real de los usuarios— y esa regla se escribe en el documento del sistema de evaluación el día que se define, no el día del primer desacuerdo, cuando ya hay alguien defendiendo su número.

El ruido en una evaluación es la parte de la diferencia entre dos resultados que no viene del sistema evaluado sino del procedimiento de medida. Aparece en cuanto se ejecuta dos veces la misma prueba sobre el mismo sistema sin cambiar nada y salen dos cifras distintas, algo que en la evaluación de modelos de lenguaje ocurre siempre. Ignorarlo tiene una consecuencia concreta y cotidiana: un equipo que persigue mejoras de dos puntos con un instrumento que oscila ocho pasa los trimestres conservando cambios que no mejoran nada y descartando los que sí, con la convicción de estar guiándose por datos.

El ruido tiene dos fuentes que se miden por separado porque se combaten distinto.

La primera es el muestreo de casos. El corpus no es el mundo: es una muestra de las entradas posibles, y la tasa de acierto medida sobre él es una estimación de la que se obtendría sobre todas. Evan Miller lo formuló en 2024 en un informe de Anthropic con la formulación que faltaba en el campo: las preguntas de una evaluación son una muestra de una superpoblación de preguntas, y por tanto todo resultado admite un error estándar. Para una tasa de acierto, el cálculo es el de cualquier proporción: la raíz cuadrada de la tasa por su complemento, dividida entre el número de casos. Con cien casos y una tasa del ochenta por ciento, el error estándar es cuatro puntos, de modo que el intervalo de confianza habitual abarca ocho puntos a cada lado y dos ejecuciones honestas del mismo sistema pueden devolver setenta y seis y ochenta y cuatro. Esa aritmética elemental, aplicada antes de la primera reunión de resultados, ahorra meses.

La segunda fuente es la estocasticidad del modelo. El mismo prompt sobre el mismo modelo devuelve respuestas distintas, y no solo porque la temperatura sea mayor que cero: con temperatura cero siguen apareciendo diferencias por el agrupamiento de peticiones en el servidor y por las operaciones en coma flotante, cuyo resultado depende del orden en que se sumen. A esto se añade una tercera fuente, emparentada, que Melanie Sclar y sus coautores midieron en 2024 y que no es ruido sino sensibilidad: cambiar detalles irrelevantes del formato del prompt mueve la exactitud hasta setenta y seis puntos. Si la plantilla cambia entre dos ejecuciones, lo que se está midiendo no es el sistema.

Contra la primera fuente se combate con más casos; contra la segunda, con más repeticiones por caso. Son remedios distintos y confundirlos produce un error que se ve a menudo: ejecutar cien casos tres veces y tratar los trescientos resultados como si fueran trescientos casos independientes. No lo son, y el error estándar así calculado es demasiado optimista. Lo correcto es promediar las repeticiones dentro de cada caso —eso reduce la varianza del valor de cada caso— y calcular después el error estándar sobre los cien valores promediados. El mismo razonamiento se aplica a los corpus con estructura: si un documento largo aporta veinte preguntas, esas veinte comparten dificultad y no son independientes, y el error estándar hay que calcularlo agrupando por documento. Miller dedica a esas dos correcciones la mitad de su informe porque son las dos que más veces se hacen mal.

Con la magnitud del ruido sobre la mesa aparece la pregunta que de verdad importa, que no es cuánto vale la cifra sino si la diferencia entre dos cifras es real.

La figura muestra la técnica que más potencia regala por menos trabajo: la comparación pareada. Si las dos versiones se evalúan sobre los mismos casos, la dificultad de cada caso afecta a ambas por igual y se cancela al restar; lo que se analiza entonces no es la diferencia de dos medias, sino la media de las diferencias caso a caso. Es el mismo argumento por el que un ensayo clínico cruzado necesita menos pacientes que uno paralelo, y lo publicó Gosset en 1908 con el problema de decidir si dos variedades de cebada rendían distinto.

Conviene, eso sí, entender qué cancela exactamente el pareo, porque la figura desmiente la versión entusiasta de esta recomendación. Parear elimina la parte de la varianza que viene de qué casos tocaron, y no toca la que viene de qué respondió el modelo en cada uno. Con un corpus de casos igual de difíciles todos, no hay nada compartido que cancelar y parear no sirve de nada; con dificultad muy desigual —el caso normal— el ahorro está alrededor de un factor de dos. Las dos palancas se multiplican cuando se juntan con la tercera: repetir cada caso varias veces y promediar antes de restar. Eso reduce la parte estocástica, que es justamente la que el pareo no alcanza, y en la simulación de la figura la combinación de casos desiguales y ocho repeticiones convierte seis mil casos en menos de trescientos. Ese es el orden de magnitud que separa una evaluación imposible de una que cabe en una noche.

De ahí se deriva el análisis de potencia, que es la pregunta invertida: cuántos casos hacen falta para detectar la mejora que se busca. Conviene hacerlo antes de construir el corpus, porque su respuesta a veces cambia el plan. Detectar de forma fiable una mejora de dos puntos sobre una tasa de acierto del ochenta por ciento exige, con una sola pasada y sin parear, del orden de seis mil casos; pareando y repitiendo cada caso, unos cuantos cientos. Si ninguna de las dos cifras es alcanzable, la conclusión honesta no es bajar el listón estadístico sino cambiar la pregunta: dejar de perseguir mejoras de dos puntos en la media y medir en cambio subpoblaciones donde el efecto esperado sea grande, o modos de fallo concretos que se pueden contar.

Hay un error emparentado que Gelman y Tuerlinckx bautizaron en 2000 y que en este oficio es el que más daño hace. Cuando el ruido es mayor que el efecto, las diferencias que superan el umbral de significación no solo exageran la magnitud del efecto: tienen una probabilidad apreciable de tener el signo contrario. Es decir, con un corpus pequeño, la mejora espectacular que sale en una ejecución es la evidencia más probable de que se está midiendo ruido, y el cambio que se conserva por ella puede estar empeorando el sistema. La figura permite ver ese porcentaje directamente.

Con esto ya se puede construir la pieza que convierte la evaluación en ingeniería: la puerta de regresión, el mecanismo que impide integrar un cambio que empeora el sistema. Su diseño tiene cuatro reglas que se han pagado caras allí donde no estaban.

La primera: el umbral se fija a partir del ruido medido, no de un número redondo. Una puerta que salta cuando la media cae dos puntos, sobre una evaluación cuyo intervalo son ocho, se disparará sola cada pocas ejecuciones; y una puerta que se dispara sola se termina desactivando, que es el peor resultado posible porque deja el sistema sin defensa y al equipo con la sensación de tenerla. La forma correcta es estimar el intervalo con remuestreo —el método que Efron publicó en 1979, que aquí consiste simplemente en volver a muestrear con reemplazo los resultados por caso y mirar cómo se mueve la media— y poner el umbral fuera de él.

La segunda: dos capas separadas, agregada y por caso. La capa agregada compara la media con la de una referencia congelada y comprometida en el repositorio; la capa por caso detecta el hundimiento catastrófico de un caso concreto que la media disimula. Mezclarlas produce siempre uno de dos defectos: o el ruido de un caso tumba la construcción entera, o una caída general se esconde detrás de un mínimo por caso demasiado indulgente.

La tercera: algunas comprobaciones no tienen umbral. Un caso de inyección de instrucciones que se cuela, una filtración de datos personales o una salida que no valida contra su esquema no son un descenso de la calidad media; son un fallo de la ejecución. Promediarlos con el resto los hace invisibles en cuanto el corpus es grande.

La cuarta: la referencia guarda con qué se midió. Una referencia útil no es un número: es el número junto con la versión del prompt, la versión exacta del modelo, la versión del corpus, el número de repeticiones por caso y el coste. Sin eso, la serie histórica mezcla manzanas y peras, y la primera vez que el proveedor actualice el modelo detrás del mismo nombre nadie sabrá si la caída es del cambio propio o del ajeno.

Dos detalles prácticos completan el montaje y los dos salen de haber sufrido lo contrario. Uno es el caso canario: antes de lanzar la evaluación completa se ejecuta un solo caso barato y se comprueba que termina y supera un mínimo elemental. Cuesta segundos y convierte una mañana perdida —cuarenta minutos de ejecución para descubrir al final que la credencial había caducado— en dos minutos. El otro es medir el coste como se mide la calidad: cada ejecución informa de sus llamadas, sus tokens y su gasto junto a la tasa de acierto. Un cambio que sube dos puntos y duplica el coste por operación es una decisión de producto, y solo puede tomarse si las dos cifras aparecen juntas en el mismo informe; cuando el coste no se mide, la decisión se toma igual, pero a ciegas.

Queda un asunto que aparece en cuanto el panel de la evaluación madura: la multiplicidad. Un sistema con cinco llamadas y cuatro dimensiones cada una produce veinte cifras por ejecución, y con veinte cifras y una ejecución semanal siempre hay alguna en rojo por azar. Esto no se arregla con correcciones estadísticas, que aquí serían un formalismo, sino con dos reglas de operación. La primera es declarar por adelantado cuál es la cifra principal de cada llamada y tratar el resto como desglose diagnóstico, no como puertas. La segunda es exigir que un rojo se reproduzca antes de actuar sobre él: se vuelve a ejecutar, y si desaparece, era ruido. Parece una trivialidad y es la diferencia entre un sistema de evaluación que dirige el trabajo del equipo y uno que lo interrumpe.

La idea que sostiene todo lo anterior cabe en una frase y no es estadística sino de método. Una evaluación no sirve para conocer la calidad de un sistema, que casi nunca es un número; sirve para decidir, con una probabilidad de error conocida, si el cambio que se acaba de hacer es una mejora. Todo lo que hace falta para eso es un instrumento cuya oscilación se conozca, y conocer la oscilación cuesta exactamente una ejecución repetida sin cambiar nada: la primera medición que debería hacer cualquiera al montar un sistema de evaluación, y la que casi nadie hace.

El sobreajuste es lo que le ocurre a un modelo que aprende demasiado bien los datos con los que se ha entrenado: se ajusta no solo a la regularidad que hay en ellos sino también al ruido, a los accidentes de esa muestra concreta, y por eso falla con datos nuevos. Es el problema central del aprendizaje automático, porque un modelo no se construye para repetir lo que ya se sabía sino para acertar con lo que aún no se ha visto, y porque la única medida que se tiene a mano mientras se entrena —el error sobre los ejemplos conocidos— es precisamente la que el sobreajuste hace bajar. Un modelo sobreajustado parece mejor cuanto peor es.

La figura de esta página lo muestra con la versión más antigua del problema, el ajuste de un polinomio a unos puntos. Los puntos negros son muestras de una onda, la curva gris, a las que se ha sumado ruido. El polinomio naranja es el que mejor los ajusta por mínimos cuadrados, y su grado —la cantidad de curvas que puede hacer— lo controla el deslizador. Con grado 1 es una recta, que no puede seguir la onda y se equivoca con todos los puntos por igual: es lo que se llama infraajuste, un modelo demasiado rígido para la realidad. Con grado 3 o 4 sigue la onda de cerca. Con grado 12 o 15 pasa casi exactamente por cada punto, serpenteando entre ellos, y en los huecos entre puntos se dispara hacia donde ningún dato lo respalda.

La gráfica de la derecha es la que importa, y es la que el que entrena un modelo no puede ver sin más datos. La línea negra es el error sobre los puntos de entrenamiento; baja siempre al subir el grado, porque un polinomio más flexible siempre puede acercarse más a unos puntos dados, y con grado igual al número de puntos menos uno pasa exactamente por todos y el error es cero. La línea naranja es el error sobre doscientos puntos nuevos de la misma onda, que el polinomio nunca vio. Baja al principio, cuando el modelo gana la flexibilidad que la onda necesita, y vuelve a subir cuando la gana de más y la gasta en seguir el ruido. El mínimo de esa curva es el grado correcto, y está muy lejos del que minimiza la línea negra. El botón que pide otra muestra enseña lo mismo desde otro ángulo: el polinomio de grado alto cambia de forma entera con cada muestra, mientras que el de grado bajo apenas se mueve.

Esa es la descomposición que Stuart Geman, Elie Bienenstock y René Doursat formularon en 1992 con el nombre de dilema sesgo-varianza. El error de un modelo sobre datos nuevos tiene dos fuentes. El sesgo es lo que se equivoca sistemáticamente por ser demasiado simple para la realidad, la recta que no puede ondular. La varianza es lo que se equivoca por depender demasiado de la muestra concreta, el polinomio de grado quince que sería otro con otros veinte puntos. Aumentar la flexibilidad reduce el sesgo y aumenta la varianza, y el mejor modelo es el que equilibra ambos. El ruido, que el segundo deslizador controla, decide dónde está ese equilibrio: con datos limpios se puede permitir un modelo más flexible; con datos ruidosos, la flexibilidad es más peligrosa. Y el número de puntos también: con más datos, la varianza baja y el grado óptimo sube.

El problema tiene una solución de método, no de fórmula, y es de las más importantes de la estadística aplicada: no evaluar nunca el modelo con los datos que lo entrenaron. Mervyn Stone formalizó en 1974 la validación cruzada, que consiste en apartar una parte de los datos, ajustar el modelo con el resto, medir el error en la parte apartada, y repetirlo rotando la parte apartada para usar todos los datos sin hacer trampa. Es lo que hace la figura al medir la línea naranja sobre puntos nuevos. La alternativa de Hirotugu Akaike, del mismo año, es penalizar la flexibilidad directamente: su criterio suma al error de entrenamiento un castigo proporcional al número de parámetros, y elige el modelo que minimiza la suma. Las técnicas de regularización que usan las redes neuronales —penalizar pesos grandes, apagar neuronas al azar durante el entrenamiento, detener el entrenamiento cuando el error de validación deja de bajar— son variantes de la misma idea: limitar la flexibilidad para que no la gaste en el ruido.

Hay una coda reciente que conviene conocer, porque complica el cuadro sin desmentirlo. Mikhail Belkin y sus colegas mostraron en 2019 que, en muchos modelos modernos, si se sigue aumentando la flexibilidad mucho más allá del punto en que el modelo pasa exactamente por todos los datos, el error de prueba vuelve a bajar: la curva naranja tiene un segundo descenso. Las redes neuronales con muchos más parámetros que ejemplos, que según el dilema clásico deberían sobreajustar sin remedio, generalizan bien en la práctica, y por qué lo hacen es una pregunta abierta. La lección de la figura sigue siendo válida en la zona que muestra, la de los modelos que caben en un deslizador de quince posiciones: el error que se puede medir mientras se entrena no es el error que importa, y un modelo que acierta todo lo que ha visto es sospechoso, no admirable.

La evaluación de agentes es la medición de sistemas que no producen un texto sino una secuencia de acciones: consultan una base de datos, leen ficheros, llaman a una interfaz de programación, escriben código, lo ejecutan y deciden por sí mismos cuándo han terminado. Cambia todo respecto a evaluar una respuesta. Un texto se juzga como objeto; un agente se juzga como proceso, y el resultado de ese proceso puede ser correcto por casualidad o incorrecto por un detalle irrelevante después de veinte pasos impecables.

La ventaja compensa la dificultad: en muchas tareas de agente el éxito es verificable por programa, y eso es lo mejor que le puede pasar a una evaluación. En vez de discutir si una respuesta es buena, se comprueba si el estado final del mundo es el pedido. Los dos bancos de pruebas que definieron el género lo hacen así. SWE-bench, publicado por Carlos Jimenez y sus coautores en 2024, toma incidencias reales de repositorios de código abierto, pone al agente a resolverlas sobre el repositorio tal como estaba antes del arreglo y decide con las pruebas unitarias que acompañaban al parche humano: pasan o no pasan, sin juicio. τ-bench, de Shunyu Yao y sus coautores el mismo año, sienta al agente a conversar con un usuario simulado mientras usa las interfaces de un dominio de atención al cliente y comprueba al final el estado de la base de datos contra un estado objetivo anotado. GAIA, con sus cuatrocientas sesenta y seis tareas de asistente general, va por el mismo camino con respuestas de formato cerrado. Cuando se puede construir un verificador así, se construye: es determinista, no cuesta dinero por ejecución y no tiene sesgos.

Lo que no es, es completo, y conviene saberlo antes de fiarlo todo a la cifra verde. El propio SWE-bench tuvo que ser depurado: al revisarlo caso por caso aparecieron enunciados que no contenían información suficiente para resolver la tarea y pruebas que fallaban por motivos ajenos al cambio, lo que dio lugar a un subconjunto de quinientas tareas validadas por personas que es el que hoy se usa como referencia. Y el trabajo de UTBoost, en 2025, mostró el defecto complementario y más incómodo: las pruebas que acompañan a un parche humano a menudo no cubren lo que el parche arregla, de modo que un agente puede pasarlas con una solución que no resuelve el problema. Al generar pruebas adicionales para esas tareas, sus autores encontraron trescientos cuarenta y cinco parches que constaban como correctos y no lo eran, y la corrección movió de sitio a casi una cuarta parte de las posiciones de la tabla. Un verificador es una medida de lo que verifica, nunca de lo que uno quería.

La segunda cosa que cambia con los agentes es que el resultado final es un resumen muy pobre de lo ocurrido. El marco que mejor organiza esto es el de las tres capas que describe el equipo de Airbnb: se puntúa la trayectoria, el uso de herramientas y la salida final, y se puntúan por separado. La razón es práctica antes que conceptual: un agente que llega al resultado correcto tras catorce llamadas, tres callejones sin salida y una lectura de todo el repositorio cuesta diez veces más que uno que llega en cuatro pasos, falla en cuanto la tarea crece un poco y no se puede poner delante de un usuario que espera. Con solo la puntuación final, esas dos ejecuciones son idénticas.

Puntuar la trayectoria no exige un juez sofisticado; casi todo se cuenta. Qué ficheros tocó frente a los que tocó la solución humana, en forma de precisión y cobertura combinadas —nunca solo cobertura, porque premiar la cobertura sola premia tocarlo todo—; cuántos pasos, cuántas llamadas repetidas idénticas, que son el síntoma de un bucle; si usó la herramienta adecuada con los parámetros adecuados; cuánto tiempo y cuánto dinero; y si en algún momento ejecutó una acción que la tarea no autorizaba. Esa última es la comprobación de seguridad que ninguna cifra de éxito contiene: un agente que resuelve la tarea borrando la tabla que estorbaba ha tenido éxito según el verificador y es un incidente. Las acciones prohibidas se puntúan como fallo de la ejecución completa, igual que una inyección en el corpus de un sistema de texto.

Cuando sí hace falta un juez en una tarea de agente, su pregunta correcta es la equivalencia y no la identidad. La solución humana es una solución válida, no la solución; comparar el parche del agente con el parche del repositorio letra a letra mide parecido estilístico. Hay además una señal de calidad que suele estar disponible y casi nadie usa: los comentarios de revisión que recibió el cambio humano. Son modos de fallo conocidos, anotados por alguien que conocía el código, y comprobar que el agente no repite exactamente aquello que un revisor ya objetó es un puntuador barato con una validez muy alta, porque no lo inventó nadie para la evaluación.

Queda la propiedad que más distingue a un agente de un generador de texto, que es la fiabilidad.

Las dos medidas de la figura responden a preguntas distintas y confundirlas es el error de lectura más común en los informes de agentes. La primera, pass@k, la introdujeron Mark Chen y sus coautores en 2021 para evaluar generación de código: se generan k candidatos y se cuenta un acierto si al menos uno pasa las pruebas. Es la medida adecuada cuando existe un verificador automático que puede elegir, porque entonces los k intentos son un recurso y no un riesgo. La segunda, pass^k, la propuso τ-bench para lo contrario: exige acertar en los k intentos, y mide consistencia. Los números de aquel artículo siguen siendo el mejor argumento a favor de mirarla: los agentes de llamada a funciones de la época resolvían menos de la mitad de las tareas y su pass^8 en el dominio de comercio caía por debajo del veinticinco por ciento. Un sistema que acierta una de cada dos veces no es medio sistema: para un usuario que necesita el mismo resultado dos veces seguidas, es uno que falla casi siempre.

La heterogeneidad que la figura permite mover explica por qué las dos curvas teóricas rara vez se cumplen tal cual. Los intentos no son independientes: hay tareas que el agente resuelve siempre y tareas que no resuelve nunca, y bajo esa mezcla pass^k no se desploma exponencialmente sino que se estabiliza alrededor de la proporción de tareas fáciles. La consecuencia práctica es que la media esconde la forma: dos sistemas con la misma tasa de éxito, uno mediocre en todo y otro excelente en la mitad e inútil en la otra, se comportan de forma completamente distinta en producción y solo se distinguen ejecutando varias veces cada tarea y mirando la distribución por tarea.

Montar el entorno es la mitad del trabajo y la parte que nadie cuenta en los artículos. Un agente necesita un mundo con el que interactuar, y ese mundo tiene que ser reproducible, aislado y honesto. Reproducible significa que la tarea se ejecuta sobre un estado congelado —una copia del repositorio en el commit anterior al arreglo, una base de datos restaurada desde un volcado— y que dos ejecuciones parten de lo mismo. Aislado significa que el agente no puede tocar nada real: ni publicar, ni escribir en producción, ni enviar correo. Y honesto significa que no hay fuga del futuro, que es el fallo específico de estas evaluaciones y el más fácil de cometer: si el repositorio clonado conserva la historia posterior, el agente puede leer el arreglo en el registro de cambios y «resolver» la tarea copiándolo. Hay que recortar las referencias y la historia posteriores al punto de partida, y comprobar además que el enunciado no contiene identificadores que solo aparecen en la solución, porque un enunciado reconstruido a partir del texto del cambio filtra por descuido.

El resto de los obstáculos son mundanos y dominan el calendario. Un estado antiguo a menudo ya no compila, porque las dependencias se movieron; la suite de pruebas del repositorio tiene fallos intermitentes que se confunden con fallos del agente; cada tarea tarda minutos y cuesta dinero de verdad. Las cifras de un caso medido dan la escala: media hora de reloj y medio dólar por tarea significan que una suite de cien tareas cuesta entre cincuenta y doscientos dólares y una noche entera. De ahí tres decisiones que se repiten en todos los montajes que funcionan: restringir el corpus a tareas suficientemente recientes para que el entorno se construya, muestrear diez o veinte tareas por tipo en lugar de todas, y separar dos caminos de ejecución —uno corto que se lanza a mano sobre un puñado de tareas mientras se itera, y otro completo que corre de noche y alimenta la serie histórica.

Esa clasificación por tipo de tarea, que empieza siendo una comodidad para muestrear, acaba siendo lo más valioso del montaje. Cuando las tareas están etiquetadas —migración de esquema, punto de entrada nuevo, corrección de error, arreglo de integración continua, componente de interfaz—, la evaluación deja de dar un número y empieza a dar un perfil, y el perfil es accionable: dice en qué tipo de trabajo conviene dejar al agente solo y en cuál no. Además abre la puerta a componer el prompt según el tipo de tarea, con la instrucción específica y unos cuantos ejemplos parecidos recuperados del historial, y entonces la suite de evaluación tiene una función nueva: es lo que gatea cada versión de esas instrucciones. El orden correcto es ese y no el inverso. Primero se mide si las instrucciones que ya hay ayudan —comparar el agente con y sin ellas es una de las mediciones más baratas y más incómodas que se pueden hacer, y a veces la respuesta es que no ayudan— y solo después se invierte en hacerlas dinámicas.

La medición final, la que cierra el círculo, no vive en la suite sino en el trabajo real. Un agente de programación produce cambios que alguien revisa: cuántos se integran sin tocar nada, cuántos comentarios de revisión reciben, cuánto texto modifica el humano antes de aprobarlos. Son tres señales gratuitas, disponibles desde el primer día y con una validez que ningún juez alcanza, porque las produce la persona que responde del código. La disciplina que las hace utilizables es llamarlas igual que a las dimensiones de la evaluación fuera de línea, para que la comparación entre lo que la suite predijo y lo que el equipo experimentó sea una resta y no una discusión.

La evaluación en producción es la medición de un sistema de inteligencia artificial con el tráfico real de sus usuarios, sin respuestas correctas anotadas y sin poder repetir el experimento. Es lo contrario de la evaluación fuera de línea en todo: allí las entradas son fijas y se pueden volver a pasar cuantas veces haga falta, aquí las entradas son las que llegan y no vuelven; allí hay etiqueta y aquí hay, como mucho, indicios. Y es, pese a eso, la única que mide el sistema que existe, porque el corpus lo escribió alguien del equipo y el tráfico no.

La primera regla es tan barata que cuesta explicar por qué se incumple siempre: las dimensiones de fuera de línea y las de producción tienen que llamarse igual. Si el corpus mide «fundamentación» y el panel de producción mide «calidad percibida», no hay ninguna operación aritmética que relacione las dos cifras, y la pregunta interesante —¿acierta mi evaluación al predecir lo que ocurre con usuarios reales?— queda fuera de alcance para siempre. Con el mismo nombre y la misma definición en los dos sitios, la comparación es una resta y el sistema de evaluación se vuelve, él mismo, comprobable. Esta decisión hay que tomarla al empezar, porque renombrar puntuaciones a posteriori rompe la serie histórica que justificaba tenerlas.

La señal más valiosa de producción es gratuita y consiste en mirar qué hace el usuario con la respuesta: si la acepta tal cual, si la edita y cuánto, si la descarta, si la vuelve a pedir, si abandona. Es el equivalente de lo que en recuperación de información se llama realimentación implícita, y arrastra la misma advertencia que Joachims y sus coautores documentaron en 2005 para los clics: la señal está condicionada por lo que el sistema mostró y por la posición en que lo mostró, de modo que mide una mezcla de calidad y presentación. Con eso se puede trabajar, siempre que se sepa.

Lo que hunde a la mayoría de los paneles de calidad no es ese sesgo sino otro, más simple y más grave, que conviene analizar despacio porque casi nunca aparece en la documentación de los productos: la señal falta, y falta de forma no aleatoria.

Todo sistema real acumula exclusiones razonables, cada una defendible por separado. La puntuación de aceptación se emite al publicar, así que el borrador que nunca se publica no puntúa. La estimación solo se evalúa cuando hay datos suficientes para calcularla, así que los casos pobres en contexto no puntúan. Una respuesta servida desde la caché no puntúa, porque no hubo generación. Una revisión que no encuentra nada que decir no produce una tasa de hallazgos. Una petición interrumpida por el usuario no puntúa, a propósito. Enumeradas en una lista de requisitos, las seis parecen detalles de implementación; puestas en una tabla, dibujan otra cosa: el conjunto de generaciones que reciben puntuación no es una muestra del conjunto de generaciones.

Y el sesgo va en la dirección peor. Un usuario abandona un borrador, en parte, porque el borrador era malo, de modo que las generaciones peores son exactamente las que no tienen nota, y la tasa de aceptación que se informa está inflada por construcción. Es el caso clásico de datos que faltan de forma dependiente del valor que tendrían, la categoría que Donald Rubin formalizó en 1976 y la única de las tres que no se arregla ignorándola. Las dos correcciones que funcionan son instrumentales antes que estadísticas: registrar explícitamente el abandono como resultado, con su denominador, e informar siempre de la cobertura junto a la tasa —«ochenta y seis por ciento de aceptación sobre el treinta y uno por ciento de las generaciones»—, porque un porcentaje sin cobertura al lado invita a leerlo como si fuera del total.

Hay un segundo límite de la señal de usuario, independiente del anterior y más difícil de aceptar para quien la defiende: aceptar no es lo mismo que estar bien. Que alguien publique el texto significa que le pareció suficiente, no que fuera cierto. Los casos que ilustran esto en cualquier sistema que redacta sobre datos son siempre del mismo tipo: con un contexto pobre, el generador rellena con lo que parece plausible —un puesto que nadie mencionó, una tecnología que no está en ninguna parte, una cifra inventada— y el resultado se lee bien, precisamente porque la invención es coherente. El usuario lo acepta. La aceptación sube. La fundamentación no la puede ver nadie desde ahí, porque comprobarla exige comparar la salida con el contexto de entrada, que es justo lo que el usuario no hace.

Esa es la función que justifica poner un juez automático sobre el tráfico real, y no la de sustituir al usuario. Hay dimensiones que el usuario juzga mejor que nadie —si le sirve, si el tono es el suyo— y dimensiones que no puede juzgar sin hacer el trabajo a mano: si cada afirmación está sostenida por el contexto, si la respuesta se inventó una restricción, si el texto contiene algo que en ese mercado es ilegal. Para esas, un segundo modelo que lee la generación y el contexto y emite una puntuación es el único instrumento disponible que cubre el cien por cien de las operaciones desde la primera, y no el veinte por ciento que sobrevive a las exclusiones.

Dónde se coloca ese juez decide cuánto cuesta ponerlo. Hay tres sitios y el orden en que conviene recorrerlos suele ser el inverso al que parece.

El más barato para empezar es por lotes, fuera del producto: se vuelca una muestra de generaciones reales, se pasan por la rúbrica en un entorno de laboratorio y se publica un informe. No toca el código de producción, no depende de ninguna plataforma, se puede hacer en una tarde y contesta las preguntas que el equipo está discutiendo esta semana. El coste medido de pasar dos llamadas de modelo sobre mil casos reales está en el orden de un dólar, de modo que el dinero nunca es el argumento; el argumento es el reloj y la disciplina con los datos, porque un volcado de tráfico real contiene datos de personas y hay que anonimizarlo en el mismo guion que lo extrae.

El más correcto a medio plazo es dentro del servicio, escribiendo la puntuación por el mismo canal por el que ya se escriben las demás. Tiene la propiedad que lo hace fácil de aprobar: no cambia ningún contrato. El texto ya está en el servicio, el canal de puntuaciones ya existe, y lo único que sale hacia fuera es un número. Se dispara después de haber respondido al usuario, muestreado, y con una regla que hay que escribir en el diseño: una puntuación perdida no puede afectar nunca a la operación. El nombre de la puntuación debe distinguir sin ambigüedad lo que dijo una máquina de lo que hizo una persona; un prefijo basta, y evita la confusión que aparece el día que alguien construye un panel con las dos mezcladas.

El tercero es la plataforma de observabilidad, ejecutando evaluadores sobre las trazas que ya se recogen. Es el destino natural y su límite es el enmascarado: un juez solo puede puntuar lo que la traza lleva, y las decisiones de qué se registra y qué se oculta —tomadas, con razón, por motivos de privacidad— determinan qué dimensiones son evaluables ahí. Conviene comprobarlo antes de planificar sobre ello, porque descubrir que el campo que hace falta está enmascarado es un descubrimiento caro.

La vigilancia de la deriva es la tarea permanente que empieza el día que todo esto funciona. Hay tres derivas y ninguna avisa. El modelo cambia bajo el mismo nombre, y con él la calibración del generador y la del juez. El tráfico cambia: un mercado nuevo, una campaña, un tipo de usuario que antes no llegaba; la evaluación fuera de línea sigue en verde porque su corpus es el de siempre. Y la rúbrica envejece, porque los fallos que describe ya se arreglaron y los nuevos no están en ella. La defensa es un procedimiento periódico y aburrido: una muestra de cincuenta a cien casos de producción etiquetados a mano cada trimestre, que sirve a la vez para recalibrar el juez, para comprobar si su acuerdo con las personas se ha movido y para alimentar el corpus con casos que el equipo no habría inventado.

Ese es, de hecho, el circuito completo, y conviene verlo entero porque cada pieza de este libro ocupa un lugar en él. Producción genera trazas; una persona las lee y las clasifica; los fallos que aparecen se convierten en casos del corpus y, si son frecuentes, en puntuadores; el corpus con sus puntuadores forma la puerta que gatea el siguiente cambio; el cambio se despliega y vuelve a producción. La evaluación fuera de línea no descubre casi nada: lo que hace es impedir que vuelva a ocurrir lo que ya se descubrió. Descubrir es tarea de producción. Un equipo que solo tiene la primera mitad se protege con eficacia de los fallos del trimestre pasado.

Falta una distinción que se confunde en casi todas las conversaciones y que cuesta incidentes: un guardarraíl no es una evaluación. Un guardarraíl se ejecuta dentro de la petición y decide sobre esa petición: bloquea, avisa o deja pasar. Una evaluación se ejecuta fuera y decide sobre una versión del sistema. Comparten rúbricas y a veces código, y por eso se mezclan, pero sus modos de fallo son opuestos. El de una evaluación es medir mal; el de un guardarraíl es fallar abierto: cuando la llamada al modelo que comprueba el contenido da error, el código que la envuelve suele devolver «sin hallazgos» y la operación continúa sin haber sido comprobada, con una línea de registro y nada visible para nadie. Es la decisión razonable —no se puede bloquear a un usuario porque un proveedor esté caído— y es un agujero que hay que medir: contar cuántas veces no se pudo comprobar, informarlo como una categoría propia y nunca como un aprobado, y vigilar esa cifra como se vigila la calidad. Lo mismo vale para los descartes silenciosos: un resultado que el sistema filtra por seguridad y no registra es un fallo que no existirá en ningún panel.

El último eval de este artículo es el que menos gente escribe y el que más desconcierto ahorra: medir el acuerdo entre las distintas superficies del propio producto. Cuando dos llamadas distintas juzgan el mismo objeto —una que revisa mientras el usuario escribe y otra que decide si se puede publicar—, no hay ninguna garantía de que coincidan, y en la práctica no coinciden: el mismo hallazgo sale como sugerencia amable en una y como bloqueo en la otra, o la corrección que una propone la marca la otra como problema. Cada una pasa sus propias pruebas; la incoherencia vive exactamente en el hueco que ninguna de las dos mide. El remedio es un eval de tres líneas conceptuales: se pasan los mismos casos por las dos superficies y se cuenta el desacuerdo, igual que se mide el acuerdo entre un juez y una persona. La cifra que sale es, en muchos productos, la más útil de todo el panel, porque el usuario no experimenta la calidad media de cada llamada: experimenta la contradicción entre las dos.