Respuesta corta: un resultado de quantum machine learning solo merece llamarse útil cuando supera una comparación clásica justa, mantiene su rendimiento bajo el ruido y publica suficiente información para que otra persona pueda repetirlo. Un porcentaje de acierto aislado en un simulador no demuestra ventaja cuántica.
Esta guía propone un protocolo práctico para evaluar modelos híbridos cuántico-clásicos en 2026. Sirve para leer un artículo, diseñar un prototipo o decidir si una prueba merece pasar a hardware real. Distingue entre investigación, prototipo y disponibilidad comercial, porque esas tres etapas no tienen las mismas exigencias.
Qué debe responder un benchmark de QML
Antes de elegir un circuito hay que fijar la pregunta. “¿El modelo cuántico es mejor?” es demasiado impreciso. Un benchmark útil concreta la tarea, el conjunto de datos, el presupuesto y la métrica. Por ejemplo: “¿un quantum kernel mejora el F1 de un clasificador binario con el mismo número de características, tiempo de ajuste y presupuesto de evaluaciones que un SVM clásico?”.
También conviene separar tres afirmaciones:
- Calidad predictiva: el modelo generaliza mejor en datos no vistos.
- Coste operativo: alcanza esa calidad con menos tiempo, memoria, energía o consultas.
- Ventaja cuántica: existe una mejora atribuible al recurso cuántico y no al preprocesado, al ajuste de hiperparámetros o a una comparación desigual.
La primera puede observarse en un experimento pequeño. La tercera exige mucha más evidencia y rara vez se desprende de una sola ejecución.
El protocolo mínimo, paso a paso
1. Define la tarea y congela los datos
Especifica si se trata de clasificación, regresión, generación, detección de anomalías u optimización. Divide los datos en entrenamiento, validación y prueba antes de mirar los resultados. Si hay series temporales, usa una separación temporal; si hay grupos relacionados, evita que el mismo sujeto, usuario o dispositivo aparezca en ambos lados.
Documenta el número de muestras, las clases, el tratamiento de valores ausentes y cualquier reducción de dimensionalidad. En QML, el encoding puede convertirse en el verdadero cuello de botella: una mejora en el circuito no compensa que cargar los datos requiera una operación que el experimento no contabiliza.
2. Elige baselines fuertes y honestos
Incluye al menos un baseline sencillo y uno competitivo. Para clasificación pueden ser regresión logística, SVM, random forest o un MLP pequeño, según la naturaleza del problema. Ajusta sus hiperparámetros con el mismo protocolo usado para el modelo cuántico. No compares un circuito cuidadosamente afinado con un baseline clásico dejado en su configuración por defecto.
El baseline debe recibir la misma vista de datos. Si el circuito usa dos características seleccionadas por un método supervisado, esa selección debe aprenderse solo en entrenamiento y aplicarse igual al modelo clásico. Si el quantum kernel produce una matriz de similitud, compara también contra kernels clásicos con una escala de ajuste equivalente.
3. Igualar el presupuesto experimental
Indica el número de evaluaciones del circuito, shots por evaluación, épocas, semillas, tiempo de entrenamiento y tiempo de inferencia. En hardware real añade cola, latencia de red, compilación y repeticiones fallidas. Un modelo que necesita cien veces más consultas para ganar una fracción de punto no tiene el mismo perfil que uno que logra la misma calidad con menos coste.
La comparación debe reflejar el escenario de uso. Para un prototipo de investigación puede ser válido medir solo calidad y estabilidad. Para una decisión de producto hay que incluir coste por predicción, disponibilidad del backend, límites de cuota, mantenimiento del pipeline y posibilidad de ejecutar el modelo sin acceso privilegiado.
4. Mide más que accuracy
Reporta la métrica que corresponde al problema: F1, balanced accuracy, AUROC, MAE, RMSE, log-loss o calibración, entre otras. Añade media, dispersión e intervalos de confianza en varias semillas. En clases desbalanceadas, una accuracy alta puede ocultar que el modelo no detecta la clase importante.
Separa rendimiento de entrenamiento y prueba, y conserva un conjunto final que no se use para elegir hiperparámetros. Si el resultado depende de una sola semilla, la conclusión correcta es que el experimento es inestable, no que el modelo ha demostrado ventaja.
5. Introduce ruido de forma explícita
Un simulador ideal responde a una pregunta distinta de la que responde un dispositivo NISQ. Ejecuta, cuando sea posible, tres condiciones: circuito ideal, simulador con un modelo de ruido documentado y hardware real. No mezcles sus resultados en una única media.
Registra profundidad, puertas de dos qubits, conectividad, método de compilación, mitigación de errores y número de shots. La mitigación puede elevar la calidad, pero también puede aumentar consultas y tiempo; ambos efectos forman parte del resultado. Comprueba además si el orden de las ejecuciones, la deriva del dispositivo o la calibración cambian las métricas.
6. Haz un análisis de ablación
Retira una pieza cada vez: encoding, capas variacionales, regularización, reducción de dimensiones, mitigación o selección de características. Así se descubre si el circuito aporta algo o si la mejora procede de una etapa clásica que también podría usarse sola.
Un control especialmente valioso es sustituir el bloque cuántico por una transformación aleatoria o por un bloque clásico de capacidad parecida. Si ambos rinden igual, el experimento puede seguir siendo interesante como arquitectura híbrida, pero no respalda una afirmación de ventaja cuántica.
Cómo interpretar los resultados sin exagerar
Hay cuatro resultados razonables. Si el modelo cuántico pierde con ruido y también en el simulador ideal, la conclusión es negativa para esa configuración. Si empata, puede ser un prototipo educativo o una base para investigar, pero no una mejora demostrada. Si gana en simulación ideal y pierde al introducir ruido, existe una hipótesis de investigación que necesita hardware y técnicas de control. Si gana de forma consistente bajo presupuesto igualado, con intervalos separados y una tarea relevante, entonces hay una señal prometedora; todavía habrá que comprobar escalabilidad y coste.
La expresión “ventaja cuántica” debe reservarse para una comparación reproducible donde el recurso que explica la mejora esté identificado. “Más precisión” no equivale a “más rápido”, y “más rápido” no equivale a “más barato”. En aplicaciones comerciales la pregunta suele ser más modesta: si el pipeline híbrido resuelve una tarea concreta con una calidad, latencia y coste aceptables.
Qué publicar para que el resultado sea reproducible
Incluye versión de la biblioteca, backend, configuración de compilación, semillas, código de preprocesado, particiones de datos, hiperparámetros, número de shots, profundidad, número de qubits y criterio de parada. Guarda los resultados crudos, no solo una gráfica. Explica qué se excluyó del tiempo medido y qué partes se ejecutaron en simulación.
Las suites de benchmark específicas de QML ayudan a estandarizar esta información. El repositorio qml-benchmarks de Xanadu compara modelos cuánticos y clásicos en tareas supervisadas y generativas. El trabajo de PNNL sobre PQML muestra por qué la reproducibilidad predictiva en máquinas NISQ merece medirse por separado. Y la propuesta de suite de benchmarking estructurado organiza el flujo en representación, procesamiento y optimización.
Investigación, prototipo o producto: tres umbrales
Investigación: busca comprender un mecanismo. Puede trabajar con datasets pequeños, pero debe declarar sus límites y controles.
Prototipo: intenta resolver una tarea concreta. Necesita comparar contra baselines fuertes, incluir ruido y demostrar que el pipeline puede repetirse.
Producto: además de calidad, necesita disponibilidad comercial, soporte, latencia, coste, seguridad y un plan de sustitución si el backend cambia. En 2026, la mayoría de propuestas de QML siguen siendo investigación o prototipos híbridos; no conviene presentarlas como una capacidad comercial general.
Lista de comprobación rápida
- ¿La tarea, los datos y la métrica están definidos?
- ¿Hay baselines clásicos ajustados con la misma diligencia?
- ¿Se igualaron consultas, tiempo, shots y semillas?
- ¿Se separaron simulación ideal, ruido y hardware?
- ¿Se publicó una ablación y el coste completo?
- ¿Otra persona podría reconstruir el experimento?
Si faltan varias respuestas, el resultado puede ser una demostración interesante, pero todavía no una prueba de utilidad cuántica.
Limitaciones de este enfoque
Ningún protocolo elimina todas las decisiones subjetivas. Elegir datasets, métricas y presupuestos puede favorecer distintas arquitecturas. Además, los backends cambian, el ruido no siempre es estacionario y los tiempos de cola dependen del proveedor. Por eso conviene fechar el informe y repetirlo cuando cambien hardware o versiones de software.
Actualizado: 4 de septiembre de 2026. Esta guía es informativa y no constituye asesoramiento técnico, financiero ni profesional.
Preguntas frecuentes
¿Un accuracy mayor demuestra ventaja cuántica?
No. Hay que comprobar significación, estabilidad, coste y comparación con baselines equivalentes.
¿Es obligatorio usar hardware real?
Para una hipótesis inicial no, pero una afirmación sobre disponibilidad o utilidad práctica no debe basarse solo en un simulador ideal.
¿Qué modelo clásico conviene usar?
Depende de la tarea. Usa al menos un baseline interpretable y otro competitivo, y justifica la elección.
¿Cuándo merece la pena pasar a hardware?
Cuando el circuito es pequeño, el control idealizado es informativo y la hipótesis sigue siendo prometedora tras ruido simulado y ablaciones.