Optuna en Python: Guía de Optimización de Hiperparámetros para Machine Learning (2026)

Actualizado: 25 de junio de 2026

Optuna es un framework de Python para la optimización automática de hiperparámetros que utiliza un algoritmo bayesiano llamado TPE (Tree-structured Parzen Estimator) para encontrar la mejor combinación de parámetros en menos iteraciones que Grid Search o Random Search. En esta guía práctica con Optuna 4.x, vas a aprender a definir un study, ejecutar trials, podar entrenamientos lentos con pruners, paralelizar la búsqueda y visualizar los resultados, integrándolo con scikit-learn, XGBoost y PyTorch en menos de 50 líneas de código.

• Optuna 4.x utiliza el algoritmo TPE por defecto, que converge entre 5 y 10 veces más rápido que GridSearchCV en espacios de búsqueda con más de 4 dimensiones.
• Un study agrupa múltiples trials; cada trial sugiere valores mediante trial.suggest_float, suggest_int o suggest_categorical.
• Los pruners (MedianPruner, HyperbandPruner) detienen automáticamente los trials de bajo rendimiento, ahorrando hasta el 70 % del tiempo de cómputo.
• La paralelización se activa pasando n_jobs=-1 a study.optimize() o usando un backend distribuido con almacenamiento SQLite/PostgreSQL.
• Optuna Dashboard ofrece visualizaciones interactivas en tiempo real: importancia de parámetros, historial de optimización y coordenadas paralelas.

¿Qué es Optuna y para qué sirve?

Optuna es un framework open source desarrollado originalmente por Preferred Networks que automatiza la búsqueda de hiperparámetros óptimos para modelos de machine learning. A diferencia de los métodos clásicos de búsqueda exhaustiva, Optuna utiliza optimización bayesiana (concretamente el algoritmo TPE) para concentrar el muestreo en las regiones más prometedoras del espacio de búsqueda. ¿Resultado? Necesitas muchos menos entrenamientos para llegar a una configuración competitiva.

En 2026, con la versión 4.x estable, Optuna soporta de forma nativa estudios multi-objetivo (Pareto front), restricciones (constraints), pruners agresivos basados en aprendizaje por refuerzo, y backends distribuidos sobre Redis, PostgreSQL y MySQL. Es agnóstico al framework de ML: lo mismo lo usas para ajustar un RandomForestClassifier de scikit-learn, un modelo de gradient boosting de XGBoost o LightGBM, o una red neuronal de PyTorch o JAX. La biblioteca también se integra con MLflow y Weights & Biases para tracking automático de cada trial.

El caso de uso típico va más allá de "encontrar el mejor learning_rate". Sinceramente, en mi último proyecto de scoring crediticio acabé usando Optuna para decidir si aplicar PCA, qué imputador usar para valores faltantes y entre qué tres algoritmos elegir, todo dentro de la misma función objetivo. Esa flexibilidad es la que más se echa de menos cuando vuelves a GridSearchCV.

Instalación y primer ejemplo en 10 líneas

La instalación es directa con pip. Necesitas Python 3.9 o superior; recomendamos 3.12 o 3.13 para aprovechar las mejoras del intérprete sin GIL en cargas paralelas.

pip install optuna optuna-dashboard scikit-learn

El "Hola Mundo" de Optuna minimiza una función matemática para mostrar el patrón básico. Define un study, escribe una función objective que devuelve un número, y llama a study.optimize. Eso es todo.

import optuna

def objective(trial):
    x = trial.suggest_float("x", -10, 10)
    y = trial.suggest_int("y", 0, 5)
    return (x - 2) ** 2 + (y - 3) ** 2

study = optuna.create_study(direction="minimize")
study.optimize(objective, n_trials=100, show_progress_bar=True)

print("Mejores parámetros:", study.best_params)
print("Mejor valor:", study.best_value)

Tras 100 trials deberías ver x ≈ 2 e y = 3. Observa tres detalles que se repiten en cualquier caso real: el objeto trial es quien sugiere valores, la función objetivo devuelve un escalar, y direction puede ser "minimize" o "maximize" según optimices error o accuracy.

Optuna vs GridSearchCV vs RandomizedSearchCV

Si vienes de scikit-learn probablemente has usado GridSearchCV o RandomizedSearchCV. La pregunta natural es: ¿cuándo conviene cambiar a Optuna? La tabla resume las diferencias prácticas que importan en producción.

Característica	GridSearchCV	RandomizedSearchCV	Optuna 4.x
Algoritmo de búsqueda	Exhaustivo	Aleatorio uniforme	TPE bayesiano (adaptativo)
Espacios continuos	Discretizados	Sí	Sí (con escala log opcional)
Early stopping (pruners)	No	No	Sí (Median, Hyperband, etc.)
Multi-objetivo	No	No	Sí (Pareto front)
Persistencia entre sesiones	No	No	Sí (SQLite/PostgreSQL)
Visualización integrada	Manual	Manual	Optuna Dashboard
Trials necesarios típicos	Cientos-miles	50-200	20-100

Mi regla práctica, después de bastantes proyectos: si tu espacio de búsqueda tiene 1 o 2 hiperparámetros discretos pequeños, GridSearchCV es suficiente y más simple. A partir de 3 o 4 dimensiones (o cuando aparecen parámetros continuos como learning_rate o reg_lambda), Optuna convierte en horas lo que GridSearch tarda días.

¿Cómo funciona el algoritmo TPE?

TPE significa Tree-structured Parzen Estimator. En esencia, modela dos distribuciones de probabilidad sobre los hiperparámetros: una para los trials "buenos" (los del cuantil superior según la métrica) y otra para los "malos". En cada nueva iteración, TPE samplea candidatos que maximicen el ratio entre ambas densidades. Es decir, valores que se parecen a los que han funcionado bien y poco a los que han fallado.

Este enfoque tiene tres ventajas frente a Gaussian Processes (otro método bayesiano popular): escala mejor con el número de trials, soporta de forma natural parámetros condicionales y categóricos, y no requiere ajustar un kernel. En espacios continuos puros, los Gaussian Processes pueden ser ligeramente más precisos, pero TPE gana en flexibilidad y velocidad. Si quieres profundizar en los fundamentos matemáticos, el artículo original de Bergstra et al. está enlazado desde la documentación oficial del TPESampler.

Optuna también ofrece muestreadores alternativos: CmaEsSampler (CMA-ES, excelente para parámetros continuos correlacionados), GPSampler (proceso gaussiano, ideal con menos de 200 trials), NSGAIISampler (multi-objetivo) y QMCSampler (cuasi-Monte Carlo). Cambiar de sampler es una línea de código: create_study(sampler=optuna.samplers.CmaEsSampler()).

Optimizar un pipeline de scikit-learn con Optuna

Veamos un caso real. Entrenamos un RandomForestClassifier sobre el dataset breast cancer y queremos ajustar simultáneamente la cantidad de árboles, la profundidad máxima, los criterios de split y si usar bootstrap. Fíjate que mezclamos parámetros enteros, categóricos y booleanos, algo que GridSearch maneja con tuplas bastante verbosas.

import optuna
from sklearn.datasets import load_breast_cancer
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import cross_val_score

X, y = load_breast_cancer(return_X_y=True)

def objective(trial):
    params = {
        "n_estimators": trial.suggest_int("n_estimators", 50, 500),
        "max_depth": trial.suggest_int("max_depth", 3, 30),
        "min_samples_split": trial.suggest_int("min_samples_split", 2, 20),
        "criterion": trial.suggest_categorical("criterion", ["gini", "entropy", "log_loss"]),
        "bootstrap": trial.suggest_categorical("bootstrap", [True, False]),
        "max_features": trial.suggest_float("max_features", 0.1, 1.0),
    }
    model = RandomForestClassifier(**params, random_state=42, n_jobs=-1)
    score = cross_val_score(model, X, y, cv=5, scoring="roc_auc").mean()
    return score  # maximizar AUC

study = optuna.create_study(
    direction="maximize",
    study_name="rf_breast_cancer",
    storage="sqlite:///estudios.db",
    load_if_exists=True,
)
study.optimize(objective, n_trials=80, timeout=600)

print(f"Mejor AUC: {study.best_value:.4f}")
print("Hiperparámetros óptimos:", study.best_params)

Tres elementos a destacar. El parámetro storage persiste los trials en SQLite, lo que permite reanudar el estudio en otra sesión (load_if_exists=True). El parámetro timeout detiene la búsqueda tras 600 segundos aunque no se hayan completado los 80 trials. Y al estar dentro de un pipeline, podríamos perfectamente añadir trial.suggest_categorical("scaler", ["standard", "robust", None]) y construir el preprocesado condicionalmente. Si quieres ver cómo encajar esto en un ColumnTransformer completo, revisa nuestra guía sobre pipelines de Machine Learning con scikit-learn.

Optuna con XGBoost y pruners para acelerar trials

Los pruners son la característica que más tiempo ahorra en proyectos serios. Un pruner observa la métrica intermedia de cada trial (por ejemplo, validación al final de cada boosting round) y aborta el trial si va claramente peor que los anteriores. En XGBoost esto se traduce en evitar terminar entrenamientos de 1000 árboles cuando ya en el árbol 50 sabemos que la configuración es mala.

import optuna
import xgboost as xgb
from sklearn.datasets import load_breast_cancer
from sklearn.model_selection import train_test_split

X, y = load_breast_cancer(return_X_y=True)
X_train, X_val, y_train, y_val = train_test_split(X, y, test_size=0.2, random_state=42)
dtrain = xgb.DMatrix(X_train, label=y_train)
dval = xgb.DMatrix(X_val, label=y_val)

def objective(trial):
    params = {
        "objective": "binary:logistic",
        "eval_metric": "auc",
        "learning_rate": trial.suggest_float("learning_rate", 1e-3, 0.3, log=True),
        "max_depth": trial.suggest_int("max_depth", 3, 12),
        "subsample": trial.suggest_float("subsample", 0.5, 1.0),
        "colsample_bytree": trial.suggest_float("colsample_bytree", 0.5, 1.0),
        "reg_lambda": trial.suggest_float("reg_lambda", 1e-3, 10.0, log=True),
        "reg_alpha": trial.suggest_float("reg_alpha", 1e-3, 10.0, log=True),
    }
    pruning_callback = optuna.integration.XGBoostPruningCallback(trial, "validation-auc")
    booster = xgb.train(
        params, dtrain, num_boost_round=500,
        evals=[(dval, "validation")],
        callbacks=[pruning_callback],
        verbose_eval=False,
    )
    return booster.best_score

study = optuna.create_study(
    direction="maximize",
    pruner=optuna.pruners.HyperbandPruner(min_resource=20, max_resource=500),
)
study.optimize(objective, n_trials=100, n_jobs=4)
print(study.best_params)

Tres detalles clave aquí. log=True en suggest_float indica escala logarítmica (esencial para learning_rate y términos de regularización). HyperbandPruner es más agresivo que MedianPruner y suele dar mejores resultados en gradient boosting. Y n_jobs=4 ejecuta 4 trials en paralelo dentro del mismo proceso. Importante: combina esto con XGBoost configurado para usar pocos hilos por modelo, así evitas oversubscription de CPU. Honestamente, esa última lección la aprendí a la mala cuando un servidor de 16 cores acabó saturado por contención de hilos.

¿Cómo paralelizar y distribuir Optuna?

Optuna ofrece dos niveles de paralelización. El primero es el parámetro n_jobs de study.optimize(), que usa hilos dentro del mismo proceso. Funciona bien con modelos que liberan el GIL (XGBoost, LightGBM, scikit-learn con BLAS).

El segundo es la optimización distribuida: varios procesos, incluso en máquinas distintas, atacan el mismo study apuntando a un storage compartido. El patrón es trivial. En cada worker ejecutas el mismo script con storage="postgresql://usuario:pass@host/optuna_db" y load_if_exists=True. Optuna se encarga de coordinar los trials sin colisiones.

# worker1.py, worker2.py, worker3.py — ejecuta en máquinas distintas
import optuna

study = optuna.load_study(
    study_name="rf_breast_cancer",
    storage="postgresql://user:[email protected]/optuna",
)
study.optimize(objective, n_trials=50)  # cada worker contribuye 50 trials

Para clusters Kubernetes, el paquete optuna-distributed integra con Dask y Ray. Si tus trials son muy desiguales en duración (algo típico cuando varías num_boost_round), considera un sampler asíncrono y un pruner como SuccessiveHalvingPruner para que los workers no queden ociosos.

Visualizar resultados con Optuna Dashboard

Optuna Dashboard es una aplicación web que se conecta a tu storage y muestra el progreso del estudio en vivo. Tras instalar optuna-dashboard con pip, lánzalo apuntando al SQLite:

optuna-dashboard sqlite:///estudios.db

Abre http://localhost:8080 y verás cuatro vistas esenciales: Historial de optimización (cómo mejora la métrica con cada trial), Importancia de hiperparámetros (basada en fANOVA), Coordenadas paralelas (correlación visual entre parámetros y métrica) y Contour plot (superficies de respuesta 2D). Esta última es oro puro para detectar interacciones: si ves un valle diagonal entre learning_rate y num_leaves, sabes que ambos están acoplados y conviene optimizarlos juntos.

Si prefieres generar gráficos programáticamente, las funciones de optuna.visualization devuelven figuras de Plotly listas para guardar como HTML o PNG. Para ideas de cómo presentar estos resultados en informes, mira nuestra guía sobre visualización de datos con Matplotlib y Seaborn.

Errores comunes y buenas prácticas

El error más frecuente es no fijar la semilla del sampler ni del modelo. Optuna es estocástico; sin sampler=TPESampler(seed=42) y random_state en tu estimador, no podrás reproducir el mejor trial. Segundo: olvidar el storage. Sin él, perderás todo el estudio al cerrar el proceso. Usa SQLite incluso para experimentos locales, no cuesta nada.

Otro patrón problemático es definir rangos demasiado amplios. Si pides suggest_float("learning_rate", 0.0, 1.0), gastarás trials en valores absurdos como 0.9. Acota con conocimiento de dominio: típicamente 1e-4 a 0.3 en escala log. También evita el data leakage: la métrica que devuelve objective debe venir de validación cruzada o de un set de validación held-out, nunca del set de entrenamiento.

Finalmente, no compares estudios con distinto número de trials. Para un benchmark justo, fija n_trials y timeout idénticos entre experimentos, y reporta la métrica final junto con el número de trials ejecutados. Si trabajas con datasets desbalanceados, alinea esto con buenas prácticas de evaluación como las descritas en nuestra guía de ingeniería de características con Feature-engine, donde mostramos cómo construir splits estratificados reproducibles. La página oficial de Optuna mantiene una galería de ejemplos por framework que vale la pena revisar antes de empezar un proyecto nuevo.

Preguntas frecuentes

¿Optuna es mejor que GridSearchCV?

Para espacios de búsqueda con más de 3 hiperparámetros o cualquier parámetro continuo, Optuna encuentra mejores configuraciones en menos tiempo gracias a TPE y a los pruners. Para 1-2 parámetros discretos pequeños, GridSearchCV sigue siendo más simple y suficiente.

¿Cuántos trials necesito en un estudio de Optuna?

Una regla práctica es 20 × número de hiperparámetros como mínimo, y al menos 100 para espacios con interacciones complejas. Si activas pruners, puedes lanzar muchos más trials (300-1000) sin coste de cómputo significativo porque los malos se cortan pronto.

¿Puedo usar Optuna con PyTorch o TensorFlow?

Sí. Optuna incluye callbacks de integración para PyTorch Lightning, Keras, FastAI, MXNet y Hugging Face Transformers. El patrón es idéntico: defines una función objective que entrena el modelo durante un número de epochs y devuelve la métrica de validación; el pruner correspondiente abortará trials lentos.

¿Cómo guardo y reanudo un estudio de Optuna?

Pasa storage="sqlite:///mi_study.db" y load_if_exists=True a create_study. En la siguiente ejecución, Optuna detecta el estudio existente y añade los nuevos trials a la base de datos. Para producción usa PostgreSQL en vez de SQLite.

¿Qué diferencia hay entre MedianPruner y HyperbandPruner?

MedianPruner corta un trial si, en un step determinado, su métrica está por debajo de la mediana de los trials anteriores en ese mismo step. HyperbandPruner es más sofisticado: asigna presupuestos de recursos en rondas eliminatorias estilo torneo, ideal cuando los trials varían mucho en duración óptima.