Fecha: 29 de septiembre de 2026
20 qubits, un portátil al borde del colapso y un ruido que se lo comía todo
Imagina esto: son las 2 de la mañana, tienes un portátil que suena como un secador de pelo, y acabas de lanzar una simulación de 20 qubits. Todo va bien hasta que miras los resultados y... basura. Números que no significan nada. Un histograma que parece un cuadro de Pollock. Y tú ahí, mirando la pantalla, preguntándote si has tirado tres horas de tu vida a la basura.
Bienvenido al club. Hoy te cuento cómo un colega (llamémosle Dani, que me ha dado permiso para contar su calvario) pasó de tener un simulador cuántico que mentía más que un político en campaña a conseguir resultados que aguantaban el tipo. Y todo empezó con una pregunta incómoda: ¿por qué mis resultados empeoran cuando añado más qubits?
El caso: cuando más qubits significa peores respuestas
Dani estaba trabajando en un algoritmo variacional. Nada del otro jueves: un circuito con unas cuantas puertas, un Hamiltoniano que quería minimizar, y la esperanza de que su simulación de 20 qubits le diera algo coherente.
El problema apareció rápido. Con 5 qubits, todo precioso. Con 10, empezaba a notar "cosas raras". Con 20, el desastre era absoluto: la energía que calculaba no convergía, los resultados variaban entre ejecuciones, y el estado final tenía tan poca fidelidad con el teórico que daban ganas de llorar.
Su primera reacción fue la de todos: "será el código, que va lento". Y sí, iba lento. Pero el problema no era la velocidad. Era algo mucho más traicionero: el ruido.
Paso 1: entender que el enemigo no era Python, era la física
Aquí viene la primera lección. Dani pasó dos días optimizando bucles, metiendo vectorización con NumPy, probando librerías de compilación just-in-time para acelerar las funciones numéricas. Y oye, funcionó: la simulación pasó de tardar 40 minutos a 12.
Pero los resultados seguían siendo basura.
El momento "ajá" llegó cuando se dio cuenta de que estaba simulando un sistema abierto sin decírselo al simulador. Es decir: estaba usando un backend que asumía un entorno perfecto, sin interacción con el exterior, pero luego añadía puertas y mediciones como si nada. El resultado era un híbrido Frankenstein que no representaba ni el caso ideal ni el realista.
La descoherencia, para que nos entendamos, es como intentar mantener un castillo de naipes en pie mientras alguien abre una ventana. Cada puerta que aplicas, cada medición que haces, cada instante que pasa, el sistema se va desmoronando. Y con 20 qubits, ese desmoronamiento se multiplica de forma brutal.
Paso 2: modelar el ruido (sí, de verdad, hay que hacerlo)
Aquí es donde muchos se echan atrás, porque suena a deberes. Pero es obligatorio si quieres resultados que valgan algo.
Dani construyó un modelo de ruido mínimamente decente. Nada de locuras: tasas de error de puerta de un solo qubit, de dos qubits, tiempos de relajación y de desfase, y errores de lectura. Los típicos "sospechosos habituales" que aparecen en cualquier dispositivo real.
¿El resultado? Los resultados empeoraron. Y eso, aunque parezca contradictorio, era buena señal: ahora la simulación reflejaba la realidad. El problema ya no era "mis números no tienen sentido", sino "mis números tienen sentido y son malos". Y a partir de ahí, se puede trabajar.
Paso 3: elegir bien el método de simulación
No todos los motores de simulación sirven para todo. Y aquí Dani se dio cuenta de que estaba usando el método más cómodo, no el más adecuado.
Para 20 qubits, el vector de estado completo ocupa 2^20 amplitudes complejas. Eso son unos 16 MB solo para almacenar el estado, y cada puerta implica operaciones sobre todo ese vector. Se puede hacer, pero es caro computacionalmente y, si encima añades ruido, el coste se dispara.
Existen alternativas: métodos basados en redes de tensores, en funciones de onda de matriz producto, o simulaciones de tipo Monte Carlo de trayectorias cuánticas. Cada uno tiene sus ventajas y sus límites. Dani acabó combinando un método de vector de estado para las partes críticas con un enfoque de trayectorias cuánticas para las partes con ruido.
No fue magia. Fue leer la documentación con calma y elegir la herramienta correcta para cada trabajo. Como cuando dejas de usar un martillo para todo y descubres que existe el destornillador.
Paso 4: corrección de errores básica (o cómo no tirar la toalla)
Aquí viene la parte que más me gusta, porque es donde se ve la diferencia entre "simular" y "simular bien".
Dani implementó dos técnicas sencillas pero efectivas:
- Primera: extrapolación a ruido cero. La idea es tan simple como elegante. Ejecutas tu circuito con varios niveles de ruido (por ejemplo, amplificando el ruido artificialmente), mides el observable en cada caso, y extrapolas al caso ideal. Es como si sacaras varias fotos de un objeto moviéndose y calcularas dónde estaba cuando empezó a moverse.
- Segunda: mitigación por simetría. Muchos problemas tienen simetrías conocidas (conservación de partículas, paridad, etc.). Si tus resultados las violan, sabes que hay ruido. Y puedes corregir esa violación redistribuyendo las probabilidades de forma coherente con la física del problema.
¿Funcionó? Sí, pero no de forma milagrosa. La fidelidad de los resultados pasó de un 60% a un 85%. No es perfecto, pero es la diferencia entre "esto no vale para nada" y "esto me permite sacar conclusiones".
Paso 5: medir, medir y volver a medir
La última lección de Dani fue la más importante: no te fíes de una sola ejecución. Con ruido, cada tirada es distinta. Necesitas estadísticas. Muchas.
Aumentó el número de shots, repitió experimentos, calculó intervalos de confianza. Y descubrió que algunos de sus "resultados" anteriores eran simplemente fluctuaciones estadísticas que había interpretado como señal. Eso, en ciencia, es un pecado capital. En simulación cuántica, es el pan de cada día.
La reflexión: el ruido no es tu enemigo, es tu realidad
Si algo me queda claro después de escuchar el caso de Dani, es que muchos tratamos el ruido como un estorbo. Como algo que hay que eliminar para llegar al "verdadero" resultado.
Error.
El ruido es la realidad. Los qubits reales tienen ruido. Los simuladores que ignoran el ruido te dan una fantasía que no se parece en nada a lo que pasará cuando ejecutes en hardware real. Y si tu objetivo es prepararte para el mundo real, más te vale abrazar el ruido desde el principio.
La segunda lección es que no hay atajos. Optimizar el código está bien, pero si el modelo está mal, da igual lo rápido que corras: vas en la dirección equivocada. Primero entiende la física, luego modela el ruido, después elige el método adecuado, y solo entonces preocúpate por la velocidad.
Y la tercera, quizá la más importante: la corrección de errores no es magia, es ingeniería. No convierte una simulación mala en buena. Convierte una simulación inútil en una simulación útil. Y eso, en un campo donde estamos arañando los límites de lo que podemos calcular, es oro puro.
Así que la próxima vez que tus 20 qubits te den resultados que parecen ruido blanco, no te frustres. Pregúntate: ¿estoy modelando el ruido? ¿Estoy usando el método adecuado? ¿Estoy midiendo suficiente? Porque la respuesta, casi siempre, está en esas tres preguntas.
¿Y tú? ¿Cuántas veces has culpado a tu código cuando el problema estaba en la física que no habías modelado?
Comentarios
Deja un comentario