9 min
Editar

El ruido en una evaluación

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.

Interactivo Dos versiones de un sistema, con una diferencia real que tú fijas, evaluadas trescientas veces sobre un corpus del tamaño que elijas. Arriba, cada versión ve su propia muestra; abajo, ambas ven los mismos casos y se analiza la diferencia caso a caso, lo que cancela la dificultad compartida. Las barras oscuras son las ejecuciones que concluyen el signo equivocado. Sube la dificultad desigual y las repeticiones por caso: son las dos condiciones que hacen que parear valga la pena.

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.

§

Fuentes

  1. William Sealy Gosset («Student»)The Probable Error of a MeanBiometrika 6(1)1908
  2. Bradley EfronBootstrap Methods: Another Look at the JackknifeThe Annals of Statistics 7(1)1979
  3. Jacob CohenStatistical Power Analysis for the Behavioral SciencesLawrence Erlbaum Associates, Hillsdale1988
  4. Andrew Gelman y Francis TuerlinckxType S Error Rates for Classical and Bayesian Single and Multiple Comparison ProceduresComputational Statistics 152000
  5. Mark Chen y otrosEvaluating Large Language Models Trained on CodearXiv:2107.033742021
  6. Melanie Sclar, Yejin Choi, Yulia Tsvetkov y Alane SuhrQuantifying Language Models' Sensitivity to Spurious Features in Prompt DesignInternational Conference on Learning Representations (ICLR)2024
  7. Evan MillerAdding Error Bars to Evals: A Statistical Approach to Language Model EvaluationsarXiv:2411.00640, Anthropic2024
Sarasola, Eneko (2026). "El ruido en una evaluación". Ikusmira. Recuperado de https://ikusmira.org/p/el-ruido-en-una-evaluacion/

Una errata, un dato desfasado, un párrafo que falta: edítalo y la redacción revisa tu propuesta.

Sugerir una mejora