Metrología: qué significa que esto funciona

Un sistema agéntico se defiende con números. El de ALLAN dice que un candidato puntuó 0,86 sobre un umbral de 0,8 y que por tanto puede publicarse; que la misión de referencia consume unos 141 WU —el ejemplo trabajado del que cuelgan todos los presupuestos de capacidad (Economics/economics/domain/capacity.py:85)—; y que un agente es supervised, y que por eso sus automatizaciones necesitan aprobación humana. Los tres enunciados tienen la misma gramática y no el mismo estatuto. Uno es una convención con una identidad aritmética que la fija; otro es una cadena de texto en un YAML que nadie ha comparado nunca con el comportamiento del agente; el tercero, la puntuación, es el único que se presenta como medición y el único que no lo es.

La pregunta no es si ALLAN funciona, sino qué tendría que ser verdad para que la frase «esto funciona» significase algo comprobable, y cuánto de eso está hoy escrito en código.

Qué mide una puntuación de eval

La pregunta parece de ingeniería y es de psicometría. Cuando el motor emite score: 0.86, ¿de qué magnitud es esa cifra la medida? No de la corrección de una respuesta: no hay respuesta correcta con la que compararla. No de una tasa de éxito: no hay una población de tareas de la que los escenarios sean muestra definida. La magnitud pretendida es algo parecido a «este paquete está listo para usuarios reales», y no está definida operacionalmente en ningún fichero.

La disciplina que nombró este problema lo hizo hace setenta años. Cronbach y Meehl escribieron que la validación de constructo interviene siempre que un test se interpreta como medida de un atributo que no está definido operacionalmente, y fijaron la condición que la obliga: hay que investigarla siempre que ningún criterio ni universo de contenido se acepte como enteramente adecuado para definir la cualidad que se quiere medir. Ése es el caso de un eval de agente. La consecuencia es la incómoda: para que un constructo sea científicamente admisible tiene que aparecer en una red nomológica de la que al menos algunas leyes involucren observables. Un número que no se relaciona con nada más observable no es la medida de nada.

La puntuación de eval de ALLAN no está hoy en ninguna red. No se compara con la tasa de fallos posteriores, ni con las intervenciones humanas que el agente provoca, ni con el coste de sus misiones, ni con nada que ocurra después de la publicación. El paquete declarativo tiene un campo pensado para cerrar ese círculo: success_metrics, cuyo comentario de esquema promete que se compararán «against real UsageEvent data post-deployment» (Platform Server/internal/agents/agent_schema.yaml:74-76). Se generan, se serializan en el agent.yaml y se editan desde la API del Registry (Agent Registry/agent_registry/services/agents.py:219-223); ahí termina su vida, porque no hay en los nueve repositorios un solo consumidor que las calcule contra uso real. La red nomológica está declarada y vacía.

Que esto no sea un escrúpulo académico lo confirma la literatura reciente sobre modelos fundacionales, que ha importado el vocabulario entero: König y colaboradores evalúan las estrategias de investigación mediante los cuatro tipos de validez de las ciencias sociales empíricas —estadística, interna, externa y de constructo— y advierten que el ahorro de cómputo se paga en supuestos ocultos, a veces no comprobables, que al violarse invalidan la afirmación. Los atajos de medición no se pagan en precisión: se pagan en que la afirmación deja de estar sostenida.

El examen lo escribe quien va a ser examinado

La segunda dificultad es estructural y peor que la primera. En ALLAN, el agente candidato, la rúbrica con la que se le juzga, los escenarios que se le plantean, el juez que puntúa cada uno, el revisor adversarial y el guardián final son todos salidas del mismo proveedor de modelos, y todos reciben en su prompt el mismo texto: el contexto de ejecución del propio agente.

Esto no es una inferencia sobre el diseño; es la firma de cinco funciones. designEval recibe agentContext y produce la rúbrica y su umbral (internal/agents/eval_engine.go:486-501); generateScenarios recibe agentContext y la rúbrica (:504-519); judgeScenario, además, el escenario y la salida del agente (:521-544); redTeamEval recibe agentContext (:546-561); y gatekeeper, agentContext más el informe completo serializado (:563-580). Los evals de los que todo parte los escribió antes el propio pipeline de creación, por inferencia desde la misma solicitud en lenguaje natural que produjo el agente.

Hay una salvaguarda real y conviene reconocerla: el agente bajo prueba no recibe sus propios evals en el contexto. LoadExecutionContext carga agent.yaml, AGENT.md, habilidades, prompts, hooks y memoria, y evals/ sólo entra con IncludeEvals (internal/agents/package_context.go:21-25,76), opción que ningún llamador de producción activa. El examinado no ve el examen. Pero los examinadores sí ven al examinado, y ésa es la mitad que sigue abierta.

La literatura sobre jueces-modelo describe con precisión esa configuración. Zheng y colaboradores, al proponer el método, enumeraron sus sesgos: de posición, de verbosidad y de auto-preferencia. Panickssery, Bowman y Feng midieron el mecanismo del tercero: una correlación lineal entre capacidad de auto-reconocimiento y fuerza del sesgo de auto-preferencia. Un juez que reconoce su propia escritura la puntúa mejor, y aquí lo que juzga es literalmente suyo. Shankar y colaboradores añaden el problema de la rúbrica generada —los evaluadores generados por un modelo heredan todos los problemas de los modelos que evalúan— y la circularidad que ALLAN reproduce entera: hacen falta criterios para calificar salidas, pero calificar salidas es lo que ayuda a definirlos.

Y hay un detalle del código que agrava el diagnóstico más allá de cualquier sesgo conocido: el umbral no lo fija la plataforma. El informe se inicializa con Threshold: 0.8 (eval_engine.go:248), pero el guardián devuelve en el mismo objeto JSON su puntuación y su umbral, y si el umbral devuelto es mayor que cero se instala en el informe (:357-360). El veredicto es una conjunción de cuatro términos —gate.Pass && report.Score >= report.Threshold && evalArtifactsPassed(report.EvalArtifacts) && !artifacts.HasErrors(issues) (:361)—, y sólo el último de los cuatro es del motor: los dos primeros los emitió una sola llamada al guardián y el tercero se resuelve un nivel más abajo contra Design.PassThreshold, que escribió el diseñador de rúbricas (:730-733). El 0,8 de reserva sólo sobrevive si el modelo declina responder. Descontando los defectos estructurales del paquete, en toda la cadena numérica no queda un valor fijado fuera del modelo.

Dos puertas con el mismo nombre y dos reglas de decisión distintas

El mismo informe alimenta dos compuertas que no deciden igual, y la diferencia determina qué se publica.

La última fila es la más importante y la menos evidente. En Forge la puntuación no decide nada: se transporta (validation_report.go:505-509) y el veredicto se calcula contando hallazgos bloqueantes. Cada required_fix que el guardián escribe se convierte en un blocker con independencia de si dijo pass (:514-523), mientras que las correcciones de los jueces de rúbrica y del equipo rojo se degradan a risk y no bloquean nunca (:557, :571). La variable de decisión efectiva de Forge es si el guardián se molestó en redactar prosa en un campo de lista. En el Registry, en cambio, el booleano sí depende de la desigualdad entre dos números que emitió la misma llamada.

La puerta que gobierna la publicación es, además, más débil que la que gobierna la creación, y lo es en la dimensión que el propio diseño identificó como crítica: lo que el documento de Forge llama un agente amputado es la configuración en la que corre el gate del Registry hoy.

Y hay un escalón más abajo: los gates de publicación son opcionales y el predeterminado no exige evals en ningún ámbito. PublicationGates inicializa require_evals = False (Agent Registry/agent_registry/domain/policy.py:17-20) y default_policy activa require_validation y require_approval para tenant y global, pero nunca require_evals (:48-63); el gate sólo corre si un administrador lo activa (services/lifecycle.py:707-708), cosa que el README desaconseja mientras el aislamiento sea de sistema de ficheros y no de tenant. En un despliegue por defecto, ninguna puntuación de eval bloquea nada.

Lo que ALLAN descartó, y por qué

El corpus de diseño contiene descartes que, leídos juntos, son una teoría implícita de la medición honesta, y merecen citarse con su motivo textual.

El primero es el registro de herramientas vacío, rechazado por invalidez de constructo aunque el documento no use esas palabras: «Antes recibía un registro de herramientas vacío (mcp.NewRegistry()), de modo que juzgaba a un agente amputado y todo defecto de selección de herramientas quedaba invisible hasta producción» (docs/agentes/agent-forge-design.md:227). El mismo párrafo rechaza fabricar resultados para las llamadas retenidas, con la razón correcta: «un juez puntuando datos falsos puntúa ruido».

El segundo es la ceguera del reparador. Cuando la validación falla y el autor pide refine, el cirujano recibe hallazgos y correcciones, nunca la nota: «El cirujano recibe hallazgos y correcciones; ni puntuación, ni umbral, ni rúbrica, ni transcripción del juez. Es estructural: BundleEditInstructions no tiene dónde poner una puntuación. Un reparador que puede leer el examen optimiza contra el examinador» (:270). La restricción vive en el tipo, no en el prompt (internal/forge/repair.go:34-39), y un test comprueba que ninguna instrucción contenga score, threshold, rubric ni los valores numéricos del informe (repair_test.go:80-107). Es la aplicación más limpia de Goodhart del repositorio.

El tercero es la guarda anti-Goodhart del Mejorador: «Un run del Mejorador o edita artefactos del agente contra evals congelados, o propone cambios de evals — nunca ambos» (docs/agentes/agent-improvement-design.md:193). El documento afirma que se aplica en código. No hay código: internal/improver no existe en el árbol.

El cuarto está fuera del ciclo de vida del agente y es el más importante porque sí se implementó: el plan de superficies económicas rechaza tratar la ausencia de medición como una medición buena (docs/economics-surfaces-implementation-plan.md:26-29). Se sustituye el booleano launchable por un estado —not_measured, insufficient, out_of_model, not_launchable, launchable— y «jamás se pinta en verde lo no medido».

La única disciplina metrológica que existe hoy

Ese descarte produjo el módulo más riguroso de los nueve repositorios, y está en Economics. economics/domain/evidence.py define un Calibrated[T] que transporta el valor junto con su procedencia —measured, modelled, insufficient, not_measured—, las muestras, los sujetos distintos detrás de ellas y los que la afirmación requeriría; la distinción entre muestras y sujetos está justificada en el código: «Thirty months of one customer is one customer's opinion thirty times, not thirty observations of the population» (evidence.py:60-61). Sólo measured y modelled habilitan una decisión (:68-70), y un valor modelado se reporta como modelado aunque el ledger coincida, porque «the two answer different questions and only one of them survives a customer disputing it» (:131).

El tamaño de muestra tampoco se elige: se deriva. required_sample_for resuelve por búsqueda entera el menor n tal que q^n ≤ 1 − c (:84-113), que es la familia de intervalos de tolerancia por estadísticos de orden —el manual del NIST la introduce con la propiedad que aquí importa: valen para una distribución de cualquier forma—. Con los ajustes por defecto salen 59 sujetos distintos, y el comentario dice de quién es la decisión: «lowering either number lowers the bar for calling a plan launchable, so both are deliberate commercial decisions rather than tuning» (config.py:112-118).

La misma capa trata sus propias constantes como objetos falsables. K, la denominación del Work Credit, vale 10 y está congelada: UNIT-001 rechaza como BLOCKING cualquier escritura que la mueva (domain/lint.py:394-411). n_anchor no es un parámetro libre sino la solución de una ecuación —la llamada ancla debe ratear exactamente 1000 milliWU— y ANCHOR-001 lo comprueba ejecutando el rater auténtico (lint.py:443-467). Y kappa, el multiplicador por clase de ejecución que se aplica sólo a la entrada, puede cambiarse, pero si el cambio mueve el conjunto de llamadas de referencia más de 5 por mil salta ANCHOR-002 y obliga a reexpresar la capacidad mensual de todos los planes en el mismo cambio (lint.py:477-500, config.py:103-105): un umbral de deriva declarado, con unidades, y una consecuencia explícita al cruzarlo. El validador vive dentro del escritor y no admite interruptor: «There is deliberately no switch to disable it: a validator that can be turned off is a validator that will be turned off on the day it would have mattered» (config.py:92-95).

Falta lo esencial, y el propio código lo dice: los valores concretos de kappa no están calibrados contra nada. El fichero de perfiles admite que «the STRUCTURE is stable; the NUMBERS are calibrated against real traffic in shadow-rating before launch — treat them as a starting point to be measured, not as settled truth» (domain/capacity.py:80-82), y el comentario de la clase embeddings explica que su kappa es 1000 no porque se haya medido, sino porque era el valor que el camino de reserva le daba de hecho: «Naming the class and repricing it are two different acts» (domain/rating.py:134-142). Mientras el shadow-rating no corra sobre tráfico real, esos multiplicadores son una hipótesis sobre el coste relativo del razonamiento, no una medida de él. Es la deuda más honesta del repositorio: Economics no sabe si sus constantes son correctas y ha construido la maquinaria para enterarse; el resto de la plataforma ni siquiera la tiene.

Fiabilidad, potencia y tamaño de efecto: lo que falta entero

Cada escenario se ejecuta una vez y se juzga una vez. Con entre tres y seis escenarios por artefacto y sin repeticiones, la diferencia entre 0,79 y 0,81 no es interpretable, y decirlo no requiere experimento alguno: sin repeticiones no hay varianza estimable; sin varianza, ni error estándar, ni tamaño de efecto, ni cálculo de potencia. ALLAN no declara ninguna diferencia mínima detectable porque no podría calcularla.

Miller parte de que las evaluaciones son experimentos y de que su literatura ha ignorado la de otras ciencias sobre análisis y planificación experimental, y propone cinco medidas: errores estándar de la media por el teorema central del límite; errores estándar agrupados cuando las preguntas vienen en grupos relacionados; reducción de varianza remuestreando respuestas y analizando probabilidades del siguiente token; inferencia sobre diferencias pareadas a nivel de pregunta al comparar dos modelos; y análisis de potencia para decidir si un eval es siquiera capaz de contrastar la hipótesis de interés. Ninguna está implementada. La segunda es especialmente pertinente: los escenarios de un mismo artefacto los generó una sola llamada a partir de una sola rúbrica, luego están correlacionados por construcción, y tratarlos como observaciones independientes infla la confianza de forma sistemática.

Cuánto importa la repetición está medido. Alvarado Gonzalez y colaboradores reevaluaron ocho modelos con tres corridas independientes: 10 de 12 cortes invierten al menos un orden por pares respecto a la mayoría de tres corridas, y recomiendan tratar la evaluación como un experimento, reportar incertidumbre y usar al menos dos repeticiones bajo decodificación estocástica. Mustahsan y colaboradores traen de la ciencia de la medición el coeficiente de correlación intraclase, que descompone la varianza observada entre dificultad de la tarea e inconsistencia del agente, y encuentran que converge hacia las 8-16 repeticiones en tareas estructuradas y necesita 32 o más en razonamiento complejo. Frente a esas cifras, una corrida única por escenario no es una aproximación barata: es otra cantidad.

Repetir tampoco bastaría sin controlar el entorno. Yuan y colaboradores muestran que la reproducibilidad del rendimiento de un LLM es frágil, y que cambiar la configuración del sistema —tamaño de lote, número y versión de GPU— puede introducir diferencias significativas en las respuestas, con la causa trazada a la no asociatividad de la aritmética en coma flotante bajo precisión limitada. Para ALLAN la implicación es directa: el informe no registra proveedor, modelo ni versión de configuración. La respuesta que el motor devuelve al Registry tiene seis campos —agent_id, version, passed, issues, summary, score (registry_validate.go:33-40)— y ninguno identifica al aparato de medida. Dos informes del mismo paquete no son comparables ni siquiera en principio.

Queda el juez mismo. Lee y colaboradores muestran que su sensibilidad y especificidad imperfectas sesgan las puntuaciones ingenuas, y corrigen el sesgo con intervalos que incorporan la incertidumbre del conjunto de prueba y la de un conjunto de calibración etiquetado por humanos. ALLAN no tiene ese conjunto: no hay muestra de paquetes con veredicto humano contra la que medir el acuerdo del guardián, luego no hay forma de saber si es estricto, laxo o ruidoso.

Contaminación, o el problema contrario

La contaminación clásica —el solapamiento no intencionado entre los datos de entrenamiento y los de prueba, que según Cheng, Chang y Wu puede inflar artificialmente el rendimiento— apenas se deja aplicar aquí, porque los escenarios se generan frescos en cada corrida. Eso elimina un problema y crea otro peor: sin conjunto fijo no hay comparación entre versiones, entre agentes ni entre fechas. Cada agente se examina de un examen distinto, escrito para él, por un modelo que acaba de leer su descripción. Es lo contrario de la sobreadaptación que Kapoor y colaboradores diagnostican —muchos benchmarks de agentes tienen conjuntos de retención inadecuados, y a veces ninguno, lo que ha producido agentes frágiles que toman atajos—, y comparte con ella la consecuencia final: el número no informa sobre el mundo.

La crítica metodológica reciente añade una razón para no envidiar la alternativa. Zhu y colaboradores muestran que los defectos de diseño de tarea o de recompensa pueden llevar a sub- o sobreestimar el rendimiento hasta en un 100 % en términos relativos: SWE-bench Verified usa casos de prueba insuficientes y TAU-bench cuenta respuestas vacías como exitosas. Wang, Bianchi y colaboradores, auditando 168 benchmarks, encuentran problemas críticos en más del 25,7 % de las tareas. Y Wang, Li, Mang, Cheung, Sen y Song sintetizan exploits que puntúan casi perfecto sin resolver una sola tarea.

Ese último hallazgo tiene una lectura específica para ALLAN. El reward hacking que describen requiere un objetivo estable contra el que optimizar, y el examen regenerado lo dificulta: en eso el diseño está por encima de la media. Pero aquí quien podría explotarlo no es un atacante externo sino el propio proveedor de modelos, que escribe a la vez la respuesta y el criterio, y contra eso la regeneración no protege.

Invariantes que el sistema sí garantiza

Enunciados de forma que puedan refutarse leyendo el código.

Ningún reparador automático puede leer una puntuación, un umbral o una rúbrica: la estructura que se le pasa no tiene campos para ellos (internal/forge/repair.go:34-39), y un test falla si aparecen en el texto de una instrucción (repair_test.go:80-107).

Ninguna herramienta que no declare readOnlyHint en sus anotaciones MCP se ejecuta durante una validación de Forge, y ninguna llamada retenida recibe un resultado inventado: se responde con un aviso explícito y se registra como evidencia (internal/agents/eval_sandbox.go:30-45).

Forge nunca produce un agente autonomous —la petición es un techo y la misma normalización se reaplica en los checkpoints (internal/forge/brief.go:120-140)— y un nivel desconocido nunca cumple un umbral: cualquier fallo al resolverlo deja la automatización pendiente de aprobación humana (internal/forge/types.go:76-82, internal/app/events_tools.go:484-486).

Ninguna escritura económica puede mover la denominación del Work Credit ni dejar la llamada ancla rateando algo distinto de 1 WU, y no hay interruptor para desactivar esas comprobaciones (Economics/economics/config.py:92-95, domain/lint.py:394-467); ninguna cifra marcada not_measured o insufficient puede conducir una decisión (domain/evidence.py:68-70).

Lo que está roto, sin terminar o sin evidencia

La medida de convergencia entre intentos no es estable. La huella de un hallazgo se calcula sobre (check, path, field, source, título, corrección) (internal/forge/validation_report.go:148-152), y para los hallazgos del guardián título y corrección son el texto libre que el modelo generó en esa pasada (:514-523). Entre dos intentos el juez redacta de nuevo; un mismo defecto descrito con otras palabras produce otra huella y cuenta como resuelto. El flag converging es len(resolved) > 0 (internal/forge/repair.go:298), luego será verdadero casi siempre, incluso cuando el segundo intento no haya arreglado nada: mide la variabilidad de la prosa del juez y se presenta al autor como progreso.

Los pesos de la rúbrica se piden y se ignoran. El prompt del diseñador exige que los pesos de los criterios sumen aproximadamente 1,0 (eval_engine.go:500) y la estructura los transporta (:148), pero la agregación es una media aritmética sin pesos de las puntuaciones de los jueces más la del equipo rojo (:711-744). El campo Weight no lo lee nadie.

La normalización de la escala infiere la unidad de la magnitud. normalizeScore divide entre 100 cualquier valor en el intervalo (1, 100] (eval_engine.go:762-764). Un juez que devuelva 85 queriendo decir 85 % obtiene 0,85, que es lo correcto; uno que devuelva 1,2 por error obtiene 0,012, y esa puntuación entra en la media sin señal de anomalía. Inferir la unidad del tamaño del número es lo que una unidad bien definida evita.

Las correcciones de los jueces que fallan se pierden. scoreArtifactReport recibe el informe por valor y le añade RequiredFixes a Findings (eval_engine.go:711-718); el llamador sólo usa los dos valores devueltos (:348). Forge los recupera desde Judgements (validation_report.go:549-565), pero el informe del gate del Registry sale con ese campo vacío.

El umbral de autonomía no está anclado a ninguna evidencia. El diseño dice que la promoción a autonomous es «una decisión posterior, respaldada por evidencia acumulada de evals en producción» (agent-forge-design.md:250), y ese camino no existe: el nivel se resuelve por una tabla determinista en la creación (internal/forge/blueprint.go:56-73), el editor del Registry deja la clave level deliberadamente intacta (services/agents.py:400-403) y en tiempo de disparo el motor la relee del agent.yaml (internal/app/events_tools.go:77-100). La cadena es consistente y en ningún punto consulta una medición.

Qué exigiría admitir un número al corpus

De lo anterior se deduce un criterio, y su mérito es que hoy casi ninguna cifra de ALLAN lo cumple. Una cifra puede entrar en la documentación, en una pantalla o en una compuerta si, y sólo si, se sabe qué la produjo —proveedor, modelo, versión de configuración, número de escenarios—, cuántas observaciones y cuántos sujetos distintos hay detrás, con qué dispersión entre repeticiones, contra qué referencia fija se compara, y qué otra cosa observable predice. Si falta lo último, la cifra puede publicarse como diagnóstico para una persona, nunca como umbral para una máquina. Si faltan los dos primeros, no se publica.

El tipo que implementa ese criterio ya existe en la casa: Calibrated[T] transporta procedencia, muestras, sujetos y requisito, y su is_actionable es una línea que niega la acción a lo no medido. No hay razón técnica para que un AgentEvalReport no lo lleve; la razón por la que no lo lleva es que las dos disciplinas se desarrollaron en repositorios distintos y nunca se hablaron.

Mientras tanto, la lectura defendible del informe de validación es la que el propio diseño defiende para el informe del autor: una lista de hallazgos con su evidencia, útil porque nombra defectos concretos y auditable porque cada hallazgo apunta a un artefacto. Esa parte sostiene lo que afirma. La puntuación que la acompaña, no; y que en Forge ya no decida nada es más una casualidad afortunada que una decisión.

Queda la advertencia de fondo. Manheim y Garrabrant definen la sobreoptimización como lo que ocurre cuando una métrica que sirve para mejorar un sistema se usa hasta el punto en que seguir optimizando es inútil o dañino; la formulación breve que circula —cuando una medida se convierte en objetivo, deja de ser una buena medida— se atribuye a Marilyn Strathern. ALLAN se protegió del caso obvio, el reparador que no ve el marcador, y dejó abierto el difícil: el examinador escribe el examen leyendo al examinado y fija el aprobado en la misma llamada en la que pone la nota. La ceguera del reparador es una buena idea aplicada al único sitio donde no era suficiente.

Referencias

• Cronbach, L. J. y Meehl, P. E. (1955). Construct Validity in Psychological Tests. Psychological Bulletin 52, 281–302. Texto recuperado en Classics in the History of Psychology, York University. https://psychclassics.yorku.ca/Cronbach/construct.htm — «Construct validation is involved whenever a test is to be interpreted as a measure of some attribute or quality which is not "operationally defined."»; «Construct validity must be investigated whenever no criterion or universe of content is accepted as entirely adequate to define the quality to be measured.»; «A necessary condition for a construct to be scientifically admissible is that it occur in a nomological net, at least some of whose laws involve observables.»; «A construct is some postulated attribute of people, assumed to be reflected in test performance.»

• Zheng, L., Chiang, W.-L., Sheng, Y. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv:2306.05685. https://arxiv.org/abs/2306.05685 — «We examine the usage and limitations of LLM-as-a-judge, including position, verbosity, and self-enhancement biases, as well as limited reasoning ability, and propose solutions to mitigate some of them.»

• Panickssery, A., Bowman, S. R. y Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076. https://arxiv.org/abs/2404.13076 — «By fine-tuning LLMs, we discover a linear correlation between self-recognition capability and the strength of self-preference bias; using controlled experiments, we show that the causal explanation resists straightforward confounders.»

• Shankar, S., Zamfirescu-Pereira, J. D., Hartmann, B., Parameswaran, A. G. y Arawjo, I. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. arXiv:2404.12272. https://arxiv.org/abs/2404.12272 — «Yet LLM-generated evaluators simply inherit all the problems of the LLMs they evaluate, requiring further human validation.»; «users need criteria to grade outputs, but grading outputs helps users define criteria».

• Kapoor, S., Stroebl, B., Siegel, Z. S., Nadgir, N. y Narayanan, A. (2024). AI Agents That Matter. arXiv:2407.01502. https://arxiv.org/abs/2407.01502 — «Third, many agent benchmarks have inadequate holdout sets, and sometimes none at all. This has led to agents that are fragile because they take shortcuts and overfit to the benchmark in various ways.»; «First, there is a narrow focus on accuracy without attention to other metrics. As a result, SOTA agents are needlessly complex and costly, and the community has reached mistaken conclusions about the sources of accuracy gains.»

• Miller, E. (2024). Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations. arXiv:2411.00640. https://arxiv.org/abs/2411.00640 — «Fundamentally, evaluations are experiments; but the literature on evaluations has largely ignored the literature from other sciences on experiment analysis and planning.» Las cinco recomendaciones se recuperaron de https://arxiv.org/html/2411.00640v1 : «Computing standard errors of the mean using the Central Limit Theorem»; «When questions are drawn in related groups, computing clustered standard errors»; «Reducing variance by resampling answers and by analyzing next-token probabilities»; «When two models are being compared, conducting statistical inference on the question-level paired differences, rather than the population-level summary statistics»; «Using power analysis to determine whether an eval (or a random subsample) is capable of testing a hypothesis of interest». Sobre potencia: «Power refers to the ability of an experiment to make a measurement of interest in the presence of statistical noise.»

• Cheng, Y., Chang, Y. y Wu, Y. (2025). A Survey on Data Contamination for Large Language Models. arXiv:2502.14425. https://arxiv.org/abs/2502.14425 — «the reliability of performance evaluation has come under scrutiny due to data contamination—the unintended overlap between training and test datasets. This overlap has the potential to artificially inflate model performance».

• Yuan, J., Li, H., Ding, X. et al. (2025). Understanding and Mitigating Numerical Sources of Nondeterminism in LLM Inference. arXiv:2506.09501. https://arxiv.org/abs/2506.09501 — «We demonstrate that the reproducibility of LLM performance is fragile: changing system configuration, such as evaluation batch size, GPU count, and GPU version, can introduce significant differences in the generated responses.»; «We trace the root cause of this variability to the non-associative nature of floating-point arithmetic under limited numerical precision.» La cifra concreta que da el artículo —«For instance, under bfloat16 precision with greedy decoding, a reasoning model like DeepSeek-R1-Distill- Qwen-7B can exhibit up to 9% variation in accuracy and 9,000 tokens difference in response length due to differences in GPU count, type, and evaluation batch size.»— está acotada en la propia fuente a un modelo, una precisión y un modo de decodificación, y por eso no se usa en el cuerpo como propiedad general.

• Zhu, Y., Jin, T., Pruksachatkun, Y. et al. (2025). Establishing Best Practices for Building Rigorous Agentic Benchmarks. arXiv:2507.02825. https://arxiv.org/abs/2507.02825 — «For example, SWE-bench Verified uses insufficient test cases, while TAU-bench counts empty responses as successful. Such issues can lead to under- or overestimation of agents' performance by up to 100% in relative terms.»

• Alvarado Gonzalez, M. A., Bruno Hernandez, M., Peñaloza Perez, M. A., Lopez Orozco, B., Cruz Soto, J. T. y Malagon, S. (2025). Do Repetitions Matter? Strengthening Reliability in LLM Evaluations. arXiv:2509.24086. https://arxiv.org/abs/2509.24086 — «Our findings shows that Single-run leaderboards are brittle: 10/12 slices (83%) invert at least one pairwise rank relative to the three-run majority»; «treat evaluation as an experiment, report uncertainty, and use ≥2 repetitions under stochastic decoding».

• Mustahsan, Z., Lim, A., Anand, M., Jain, S. y McCann, B. (2025). Stochasticity in Agentic Evaluations: Quantifying Inconsistency with Intraclass Correlation. arXiv:2512.06710. https://arxiv.org/abs/2512.06710 — «Yet current evaluation practice, reporting a single accuracy number from a single run, obscures the variance underlying these results, making it impossible to distinguish genuine capability improvements from lucky sampling.»; «We demonstrate that ICC converges by n=8-16 trials for structured tasks and n>=32 for complex reasoning, enabling practitioners to set evidence-based resampling budgets.»

• Lee, C., Zeng, T., Jeong, J., Sohn, J. y Lee, K. (2025). How to Correctly Report LLM-as-a-Judge Evaluations. arXiv:2511.21140. https://arxiv.org/abs/2511.21140 — «However, imperfect sensitivity and specificity of the LLM judges induce bias in naive evaluation scores.»; «Our framework constructs confidence intervals that account for uncertainty from both the test dataset and a human-labeled calibration dataset.»

• Wang, H., Li, H., Mang, Q., Cheung, A., Sen, K. y Song, D. (2026). Do Androids Dream of Breaking the Game? Systematically Auditing AI Agent Benchmarks with BenchJack. arXiv:2605.12673. https://arxiv.org/abs/2605.12673 — «BenchJack synthesizes reward-hacking exploits that achieve near-perfect scores on most of the benchmarks without solving a single task, surfacing 219 distinct flaws across the eight classes.»; «Our results show that evaluation pipelines have not internalized an adversarial mindset, and that proactive auditing could help close the security gap for the fast-paced benchmarking space.»

• Wang, J., Bianchi, F., Zhu, S., Nie, F., Kwon, Y., Dhingra, B. y Zou, J. (2026). Automated Benchmark Auditing for AI Agents and Large Language Models. arXiv:2605.26079. https://arxiv.org/abs/2605.26079 — «Across this corpus, ABA identifies critical issues including ambiguous task design, execution environment conflicts, and incorrect ground truths in over 25.7% of the evaluated tasks.»; «filtering out these tasks with issues shifts model rankings and increases average performance on SWE-bench Verified and Terminal-Bench 2 by 9.9% and 9.6%, respectively».

• König, G., Pawelczyk, M., von Luxburg, U. y Bordt, S. (2026). Validity Threats for Foundation Model Research. arXiv:2606.05029. https://arxiv.org/abs/2606.05029 — «savings in compute come at the cost of validity threats -- hidden and sometimes untestable assumptions that, when violated, can invalidate research claims»; «we evaluate different research strategies through four types of validity adapted from the empirical social sciences -- statistical, internal, external, and construct validity».

• Manheim, D. y Garrabrant, S. (2018). Categorizing Variants of Goodhart's Law. arXiv:1803.04585. https://arxiv.org/abs/1803.04585 — «This occurs when a metric which can be used to improve a system is used to an extent that further optimization is ineffective or harmful, and is sometimes termed Goodhart's Law.»

• Strathern, M. (1997). 'Improving ratings': audit in the British University system. European Review 5, 305–321. Original NO VERIFICADO: el PDF accesible (archive.org, gwern.net) es un escaneado en compresión de fax del que no se pudo extraer texto en esta sesión, de modo que la frase no se ha leído en la fuente primaria. Se cita a través de una fuente secundaria sí recuperada: M. E. McIntyre, Goodhart's Law, DAMTP, University of Cambridge, https://www.damtp.cam.ac.uk/user/mem2//papers/LHCE/goodhart.html — «Professor Marilyn Strathern FBA, following Hoskin (1996, see below), has re-stated Goodhart's Law more succinctly and more generally: `When a measure becomes a target, it ceases to be a good measure.'» Nótese que la atribución de la página es a Strathern «siguiendo a Hoskin (1996)», y que remite a su artículo de 1997 sin dar número de página.

• NIST/SEMATECH. e-Handbook of Statistical Methods, §7.2.6.4, «Tolerance intervals based on the largest and smallest observations». https://www.itl.nist.gov/div898/handbook/prc/section2/prc264.htm — «Tolerance intervals can be constructed for a distribution of any form»; «One obvious choice for a two-sided tolerance interval for an unknown distribution is the interval between the smallest and largest observations from a sample». Se cita como referencia de la familia de métodos por estadísticos de orden; la variante unilateral que implementa required_sample_for (q^n ≤ 1 − c) no aparece en esa página, que trata el caso bilateral.