¿Cómo se "hace trampa" en un benchmark cuántico (y cómo evitarlo)?

Estado a: agosto 2026. Un benchmark cuántico puede engañar sin que nadie mienta. El número que se publica es la salida de una cadena larga de decisiones de diseño — qué instancias, cuánta afinación, qué estadístico, qué métrica, qué disparos cuentan, qué rival, qué plataforma — y cada una de esas decisiones puede mover el veredicto en silencio antes de que dispare un solo qubit. Este post es una taxonomía de las siete movidas que lo hacen, cada una con un episodio público documentado y su contramedida. Una cosa antes de la lista: "trampa" nombra aquí una propiedad del diseño del experimento, no de la intención. Ninguno de los episodios de abajo es una acusación de mala fe — cada uno es una medición corregida a la vista de todos, una regla propuesta en público o una divulgación a la que el titular le sacó ventaja. Justo por eso importa la taxonomía: estos modos de falla no necesitan un villano.

¿Por qué un equipo honesto puede publicar igual un benchmark engañoso?

Porque el género es más viejo que la computación cuántica. En 1991, David Bailey escribió "Twelve Ways to Fool the Masses When Giving Performance Results on Parallel Computers", seguido de una secuela de 1992 que catalogaba casos reales — el punto de ambos era que los claims engañosos de desempeño en supercomputación eran mayormente jugadas legales: afirmaciones verdaderas ordenadas para que el lector saque una conclusión falsa. En noviembre de 2024, Catherine McGeoch — que pasó años corriendo benchmarks dentro de un vendor cuántico — escribió la secuela cuántica, "How NOT to Fool the Masses When Giving Performance Results for Quantum Computers" (arXiv:2411.08860). Sus cuatro reglas comprimen el problema entero: no reclames desempeño superior sin mencionar runtimes; no reportes resultados optimizados sin el tiempo de afinación que costaron; no reclames velocidad contra solvers en plataformas imaginarias; nada de cherry-picking sin justificación. Cada trampa de abajo es una forma de romper una de esas reglas mientras cada frase individual del paper sigue siendo verdadera.

El baseline clásico débil — el pecado más común de todos — tiene su propio post, y no lo vamos a re-litigar acá. Este post es sobre el resto del protocolo: todo lo que puede doblar un benchmark incluso cuando el baseline es fuerte.

¿Cuáles son las siete trampas — y dónde está documentada cada una?

1. Cherry-picking de instancias. Correr sobre muchas instancias del problema; reportar aquellas donde el lado cuántico se vio bien. La demostración canónica de que esto cambia veredictos es Rønnow et al., "Defining and detecting quantum speedup" (Science 345, 420, 2014): sobre instancias aleatorias de spin-glass, analizar subconjuntos de los datos podía sugerir speedup donde el conjunto de datos completo no mostraba ninguno. La regla cuatro de McGeoch ("nada de cherry-picking sin justificación") existe porque la movida sigue siendo común. Contramedida: una suite de instancias pre-registrada que queda fija antes de conocer resultados — exactamente lo que QOBLIB provee hoy para optimización (10 clases de problema, 1.200+ instancias, baselines publicados; arXiv:2504.03832, Nature Computational Science 2026), y por lo que el playbook de benchmarking de IBM de 2026 argumenta que los claims de ventaja deben correr contra un set fijado por la comunidad y no contra instancias elegidas por el que reclama.

2. Presupuestos desparejos. Pasar semanas afinando el pipeline cuántico; correr el rival clásico out-of-the-box — o al revés. Es el gemelo, por el lado de la afinación, del problema del baseline débil: la regla dos de McGeoch ("no reportes resultados optimizados sin mencionar el tiempo de afinación") le apunta directo, y uno de sus casos de estudio anonimizados es una heurística de modelo de compuertas cuya superioridad reportada descansaba en afinación de parámetros con el tiempo de optimización sin divulgar. Contramedida: declarar el presupuesto de afinación de ambos lados, en las mismas unidades, en el paper.

3. El mejor de N versus la mediana. Correr el experimento muchas veces; publicar la mejor corrida. Por qué esto engaña no es solo intuición — está medido: las distribuciones de time-to-solution de solvers estilo annealing tienen colas pesadas de ley de potencias (Steiger, Rønnow & Troyer, arXiv:1504.07991, 2015), así que la mejor corrida, la media y la mediana pueden contar tres historias distintas sobre la misma máquina. Un único número reportado elige una en silencio. Contramedida: publicar la distribución completa con semillas, para que cualquiera recompute cualquier estadístico — la reproducibilidad radical es la infraestructura de esto.

4. Elegir la métrica que te favorece. Time-to-solution, time-to-target, calidad-a-tiempo-fijo, probabilidad de éxito, energía — métricas distintas coronan ganadores distintos sobre los mismos datos. El episodio instructivo acá es abierto y honesto: en 2015, científicos de D-Wave (King et al., arXiv:1508.05087 — McGeoch entre los autores) propusieron abiertamente una métrica nueva, time-to-target, argumentando que las métricas de estado base confunden calidad del algoritmo con ruido analógico. La propuesta fue transparente sobre su razón de ser; eso es precisamente lo que la vuelve instructiva — muestra, desde adentro del campo, que la elección de métrica es un grado de libertad que mueve resultados. La regla uno de McGeoch (sin claims de desempeño sin runtimes) es la guardia contra la versión silenciosa de la misma movida. Las guerras de métricas entre vendors tienen su propio post. Contramedida: nombrar la métrica antes de correr, y reportar el ranking también bajo las alternativas estándar.

5. Post-selección silenciosa. Descartar disparos o corridas "malas" sin decirlo. La literatura de física muestra por qué esto es potente: en Gaussian boson sampling con ruido, post-seleccionar un subconjunto de los resultados mejora de forma medible la calidad de la distribución muestreada ("part is better than whole", arXiv:2205.02586, 2022). Declarada, la post-selección es una técnica legítima con un costo que se puede contabilizar. Sin declarar, la misma operación convierte un experimento ruidoso en uno de aspecto limpio sin rastro visible. Contramedida: reportar cada descarte y la regla que lo produjo, con los conteos crudos publicados.

6. El rival clásico equivocado. Comparar contra un algoritmo clásico de la clase equivocada — un solver exacto cuando dominan las heurísticas, o un método genérico cuando existe uno especializado. El episodio público canónico es diciembre de 2015: un speedup de "100.000.000×" ampliamente reportado se sostenía contra simulated annealing, sobre instancias nativas del propio grafo de conectividad del hardware; contra quantum Monte Carlo la ventaja era de factor constante, y un algoritmo clásico hecho a medida (el de Selby) le ganaba al hardware en los mismos problemas — todo lo cual quedó expuesto públicamente en días (Aaronson, 9-dic-2015). El paper técnico divulgaba sus comparaciones; el número del titular viajó sin ellas. Contramedida: el rival clásico más fuerte conocido de la clase correcta, sobre la misma instancia — el post del baseline débil tiene el checklist completo.

7. Simulación presentada como si fuera hardware. Reportar números de simulación sin ruido — o extrapolaciones a máquinas que no existen — de un modo que deja al lector creer que lo hizo hardware. La regla tres de McGeoch las llama "plataformas imaginarias", y uno de sus casos de estudio extrapolaba desempeño a tamaños de problema que ningún dispositivo existente puede sostener. La versión honesta de la misma práctica es simplemente la etiqueta: nuestra propia serie sellada V-0012 corre su lado cuántico en simulación sin ruido, lo dice en el veredicto, y anota que la simulación favorece al lado cuántico — lo que vuelve el récord de 20 de 20 del solver clásico en su contra más informativo, no menos. Contramedida: la etiqueta de plataforma viaja con el número, a todos lados donde vaya el número.

¿En qué punto del pipeline entra cada trampa?

El mecanismo detrás de las siete trampas es el mismo y vale la pena nombrarlo: las decisiones derivan hacia la opción que halaga al resultado — salvo que estén fijadas antes de que el resultado exista. Nadie tiene que querer esto. Si las instancias, los presupuestos, la métrica y el estadístico siguen siendo preguntas abiertas cuando llegan los datos, la configuración halagadora es simplemente la que sobrevive a la redacción.

¿Cómo se ve la taxonomía como tabla?

¿Cómo se lee un benchmark, edición protocolo?

El post del baseline débil da cinco preguntas sobre el rival clásico. Estas siete son sobre todo lo demás del protocolo:

1. ¿Las instancias quedaron fijas — en público — antes de que existiera algún resultado?
2. ¿Qué gastó cada lado en afinación, y ese número está en el paper?
3. ¿El titular es una mediana sobre corridas declaradas, o una mejor corrida sobre un conteo sin declarar?
4. ¿La métrica se nombró antes de correr? ¿El ranking sobreviviría a las alternativas estándar?
5. ¿Cuántos disparos o corridas se descartaron, bajo qué regla, y hay conteos crudos disponibles?
6. ¿El rival es el método clásico más fuerte conocido de la clase correcta?
7. ¿La etiqueta de plataforma (hardware, simulación con ruido, simulación sin ruido, extrapolación) viaja con el número?

Un benchmark que responde las siete afirmativamente todavía puede estar equivocado — pero ya no puede estar equivocado en silencio.

¿Qué hacemos nosotros con esto?

La respuesta de Rosetta Q es el protocolo de sellos: para cada corrida sellada de nuestras series (V-0012 y sucesoras), la instancia, las semillas, el presupuesto de cómputo y la métrica se declaran antes de correr, y el resultado se registra caiga donde caiga — lo que, en nuestras clases chicas declaradas de optimización de portafolios, ha sido una victoria clásica 20 de 20 veces, con el lado cuántico simulado sin ruido y etiquetado como tal. Eso es las trampas 1 a 7 respondidas por construcción, a alcance chico declarado. No es un veredicto universal sobre nada — es cómo se ve la columna de contramedidas de la tabla cuando de verdad la corres.

Qué sabemos / Qué no sabemos

Qué sabemos: cada trampa de arriba tiene un episodio público documentado o una demostración medida, cada una linkeada en la tabla; los propios practicantes del campo codificaron las reglas (Bailey 1991/1992 para HPC; McGeoch 2024 para cuántica); ya existen suites pre-registradas para optimización (QOBLIB); y el marcador de ventajas end-to-end medidas en problemas útiles sigue en cero, que es el telón de fondo que vuelve decisiva la calidad del protocolo.

Qué no sabemos: qué tan prevalente es cada trampa — nadie audita sistemáticamente la literatura de benchmarking cuántico, así que los episodios de acá son los casos documentados, no una tasa medida; si el pre-registro será adoptado de verdad más allá de optimización (QOBLIB es joven y la adopción es voluntaria); si algún mecanismo va a exigir alguna vez el reporte de descartes en corridas de hardware, donde re-ejecutar cuesta plata por disparo; y si nuestro propio checklist de siete preguntas cubre movidas todavía no documentadas — las taxonomías de trampas siempre van una trampa atrás.

Nada en este post acusa de mala fe a ningún vendor, laboratorio ni autor. Cada episodio citado es una medición corregida, una regla propuesta o una divulgación completada — en público, por el propio campo. Eso es el sistema funcionando; la taxonomía existe para que funcione más temprano. Las citas de fuentes en inglés van en traducción propia.

Fuentes

• McGeoch, How NOT to Fool the Masses When Giving Performance Results for Quantum Computers (arXiv:2411.08860, 2024)
• Bailey, Misleading Performance Reporting in the Supercomputing Field (1992)
• Rønnow et al., Defining and detecting quantum speedup (Science 345, 420, 2014)
• Steiger, Rønnow & Troyer, Heavy tails in the distribution of time to solution (arXiv:1504.07991, 2015)
• King et al., Benchmarking a quantum annealing processor with the time-to-target metric (arXiv:1508.05087, 2015)
• Aaronson, Google, D-Wave, and the case of the factor-10⁸ speedup for WHAT? (9-dic-2015)
• Post-selection in noisy Gaussian boson sampling: part is better than whole (arXiv:2205.02586, 2022)
• QOBLIB — The Intractable Decathlon (arXiv:2504.03832; Nature Computational Science, 2026)
• IBM Research, A new playbook for quantum optimization benchmarking (24-jun-2026)

Rosetta Q publica veredictos con datos crudos reproducibles. Esto es contenido educativo, no un claim de producto.