Este artículo va a ser el primero de una mini serie, donde voy a explicar y a programar sencillos scripts en Python para entender cómo funciona este mundo de la privacidad en el machine learning. Es un tema que, si os soy sincero, no sabía que existía hace un año. Lo descubrí mientras investigaba artículos de referencia para mi trabajo de fin de máster (estudio de métodos OOD). En concreto, estaba buscando algún método que fuese capaz de mejorar el prior en que se basan los modelos VAE (Variational Autoencoders), y de esa forma, poder mejorar el espacio latente para detectar mejor los datos fuera de distribución. Sé que suena a chino, ya explicaré mejor en qué consisten los VAE. El caso es que encontré este paper, que poco tiene que ver con detección. Aquí fue cuando conocí este nicho que es la privacidad en machine learning (a partir de ahora lo acortaré a ML).

A grandes rasgos, existen métodos por los cuales es posible extraer datos sensibles de un modelo. No solo eso, también se puede “envenenar” ese modelo de forma que deteriore sus predicciones. La cantidad de tipos de ataques que se pueden realizar es bastante amplia, por ello, lo trataré en otros capítulos de esta mini serie.

Datos sintéticos

Seguramente hayáis oído hablar de datos sintéticos en el ámbito de la IA moderna. Simulaciones de conversaciones con ChatGPT, imágenes generadas con algún modelo de difusión, simulaciones de entornos de conducción, etc. Todo ello con la finalidad de suplir la necesidad voraz de datos que hoy en día acucia a las grandes empresas de IA. Pues vamos a hacer algo parecido pero a menor escala, con datos tabulares, algo más cutre.

Antes he mencionado ataques capaces de extraer datos sensibles de usuarios a partir de un modelo de ML. El cómo es tema de un futuro capítulo, el porqué es obvio, a día de hoy cualquier dato de cualquier persona en conjunto con algo más de información sirve a muchos delincuentes muy creativos para poder desarrollar ataques y estafas cada vez más enrevesados y eficaces. Imaginemos un modelo entrenado para detectar enfermedades a partir de historiales médicos. Un atacante podría utilizar determinadas técnicas para intentar averiguar qué información ha visto el modelo durante su entrenamiento o, incluso, si los datos de una persona concreta formaron tiene ciertas características. Esto último puede parecer una información menor, pero pensemos en un modelo entrenado exclusivamente con pacientes que padecen una determinada enfermedad. Si conseguimos demostrar que los datos de una persona concreta fueron utilizados para entrenarlo, acabamos de obtener una pista bastante clara sobre su estado de salud, sin necesidad de acceder directamente a su historial médico.

La solución más evidente es la de entrenar con datos sintéticos, datos de personas ficticias, pero que mantengan una distribución y cierto tipo de información similar a los datos originales. La creación de este tipo de dato no es cosa menor, dicho de otra manera, es cosa mayor ~ Rajoy. Para generar datos sintéticos de calidad se necesitan los datos originales y métodos suficientemente refinados. Es una constante lucha entre mejorar la calidad y no desvelar información de los datos originales, porque prácticamente no existe ningún método que sea totalmente infalible. Mejorar una métrica, seguramente empeore otra y por tanto hay que encontrar un equilibrio.

Hoy voy a explicar algunos de los métodos más sencillos para medir la calidad de los datos sintéticos. Uno para medir si los datos son robustos frente a un tipo de ataque concreto y otro para evaluar la similitud con los datos reales. A medida que avance esta serie, iré incorporando otros más elaborados usando métricas específicas y métodos avanzados.

Generación de datos sintéticos con un CVAE

Los ya mencionados Variational Autoencoders son un tipo de red neuronal capaz de aprender la distribución de los datos y utilizarla para generar nuevas muestras. A diferencia de un autoencoder tradicional, que transforma cada entrada $x$ en un único vector latente $z$, un VAE aprende una distribución:

De esta distribución se muestrea $z$, que posteriormente utiliza el decoder para reconstruir el dato:

Durante el entrenamiento se busca que el dato reconstruido sea similar al original y, al mismo tiempo, que las distribuciones latentes se parezcan a una distribución normal. Por ello, la función de pérdida combina un término de reconstrucción (que los datos se parezcan a los originales) con la divergencia KL (digamos que es como una “"”distancia””” entre distribuciones):

Esta regularización hace que el espacio latente sea más continuo y permite muestrear nuevos puntos para generar datos. Aunque los modelos generativos actuales son mucho más complejos, los VAE siguen utilizándose como componentes de arquitecturas más grandes.

Con un modelo de este tipo, podríamos muestrear el espacio latente aprendido de forma aleatoria y reconstruir esas muestras. No son datos reales, pero deberían conservar características similares. Estos son nuestros datos sintéticos. Pero hay un problema. Si queremos usarlos para predecir algo, ¿cómo sabemos qué predecimos? Es decir, tenemos datos muy parecidos a los reales, pero no sabemos qué son. En en el conjunto original teníamos algún tipo de información extra, por ejemplo, si quisiéramos clasificar pacientes (tiene cáncer o no tiene cáncer), o clientes (de riesgo o seguros), deberíamos tener una etiqueta para poder entrenar un modelo de clasificación binario. Eso el VAE no lo ha aprendido y por tanto, solo tenemos un batiburrillo de puntos en el espacio.

Por fortuna, existe una variación capaz de aprender no solo la distribución de los datos, sino también la clase de estos. Los Conditional Variational Autoencoders o CVAE entienden también qué tipo de datos queremos generar. A partir de ahora vamos a trabajar con el conjunto de Iris, por lo que pongamos un ejemplo:

Cada flor está descrita por cuatro características numéricas y pertenece a una de tres clases. El CVAE puede aprender la distribución de estas características condicionada a la clase. Es decir, en lugar de aprender únicamente $p(x)$, buscamos aprender algo como:

donde $x$ representa las características de la flor y $c$ su clase.

Para que la red pueda utilizar esta información, primero transformamos la clase mediante one-hot encoding. Por ejemplo:

Esta representación se introduce en el encoder junto con las características de la flor. De esta forma, el encoder no recibe únicamente $x$, sino también la clase $c$:

El decoder recibe igualmente esta información para generar una muestra perteneciente a la clase indicada:

Por ejemplo, podríamos proporcionar al decoder un vector latente $z$ y la condición $c=[0,0,1]$. El modelo intentará generar entonces las características de una flor virginica. Así podemos generar nuevas muestras no solo parecidas a los datos originales, sino pertenecientes a la clase que nosotros indiquemos.

El código del CVAE es el siguiente:

class CVAE(nn.Module):
    def __init__(
        self,
        input_dim: int,
        hidden_dim: int,
        latent_dim: int,
        num_classes: int,
    ):
        super().__init__()
        self.encoder = nn.Sequential(
            nn.Linear(in_features=input_dim + num_classes, out_features=hidden_dim),
            nn.ReLU(),
        )

        self.mu = nn.Linear(in_features=hidden_dim, out_features=latent_dim)
        self.logvar = nn.Linear(in_features=hidden_dim, out_features=latent_dim)

        self.decoder = nn.Sequential(
            nn.Linear(in_features=latent_dim + num_classes, out_features=hidden_dim),
            nn.ReLU(),
            nn.Linear(in_features=hidden_dim, out_features=input_dim),
        )

    def encode(self, x: Tensor, y: Tensor):
        h = self.encoder(torch.cat([x, y], dim=1))
        return self.mu(h), self.logvar(h)

    def decode(self, z: Tensor, y: Tensor):
        return self.decoder(torch.cat([z, y], dim=1))

    def forward(self, x: Tensor, y: Tensor):
        mu, logvar = self.encode(x, y)

        std = torch.exp(0.5 * logvar)
        z = mu + std * torch.randn_like(std)

        x_hat = self.decode(z, y)

        return x_hat, mu, logvar

Para generar muestras sintéticas solo necesitamos el decoder. Muestreamos aleatoriamente un vector $z$ del espacio latente siguiendo una distribución gaussiana y lo pasamos al decoder junto con la clase que queremos generar. El decoder transforma este vector en una nueva muestra con las características correspondientes a dicha clase:

def generate_synthetic_sample(
    model: torch.nn.Module,
    sample_size: int,
    latent_dim: int,
    num_classes: int,
) -> tuple[torch.Tensor, torch.Tensor]:
    size = sample_size // num_classes
    samples = []
    sample_labels = []

    with torch.inference_mode():
        for i in range(num_classes):
            z = torch.randn(size, latent_dim, device=DEVICE)
            labels = torch.full((size,), i, dtype=torch.long, device=DEVICE)
            y = F.one_hot(labels, num_classes=num_classes).float()

            X_synth = model.decode(z, y)
            samples.append(X_synth)
            sample_labels.append(labels)

    return torch.cat(samples), torch.cat(sample_labels)

Evaluación por potencia predictiva

Ahora ya tenemos un modelo capaz de generar datos de Iris de forma infinita, generar flores ficticias que nunca han sido registradas porque no existen. Pero, ¿realmente sirven estos datos artificiales para nuestro propósito de entrenar un predictor de especies de flores? Quiero recordar que los hemos generado con un propósito. Vamos a usarlos en vez de los originales, vaya a ser que un hacker del ML filtre importantísima información privada de las flores. En estos casos, existe un protocolo llamado train synthetic, test real. Vamos a ponerlo en práctica. Usaremos los datos sintéticos para entrenar un clasificador cualquiera, y si de verdad son buenos, cuando evaluemos el modelo en un conjunto de test real con datos que nunca ha visto, debería tener un buen rendimiento.

El protocolo es el siguiente: entrenamos dos modelos, uno con los datos de entrenamiento originales y otro con los datos sintéticos. Después, evaluamos ambos modelos sobre el mismo conjunto de test real. En este caso he probado con un modelo basado en logistic regression de scikit-learn, uno de los más básicos.

Además, vamos a utilizar una técnica llamada bootstrapping para estimar la variabilidad de los resultados. En lugar de quedarnos con una única medida de rendimiento, como el accuracy obtenido sobre el conjunto de test, generamos muchas muestras mediante muestreo con reemplazo (es decir, mismos valores pueden repetirse en el muestreo) a partir de los datos de test. Evaluamos el modelo sobre cada una de estas muestras y obtenemos así una distribución de los resultados.

Esto nos permite estimar un intervalo de confianza para las métricas y comprobar hasta qué punto las diferencias entre el modelo entrenado con datos reales y el entrenado con datos sintéticos son estables o pueden deberse a la variabilidad de la muestra de test.

La base estadística del método es que, bajo condiciones bastante generales, la distribución empírica obtenida mediante estas muestras con reemplazo proporciona una buena aproximación a la distribución muestral real que obtendríamos si pudiéramos repetir el experimento muchas veces. Por eso el bootstrap resulta especialmente útil cuando no conocemos o no queremos asumir una distribución paramétrica.

Para el público general $\rightarrow$ “Si pudiera repetir este experimento muchas veces con distintos conjuntos de test extraídos de la misma población, ¿cuánto cambiaría mi resultado?”

Los resultados son los siguientes:

Como era de esperar, el clasificador entrenado con datos reales rinde mejor que el entrenado con sintéticos. En accuracy pasamos de $0.933$ a $0.833$. Aun así, el resultado del entrenamiento con los datos vomitados por el CVAE no es despreciable, ya que con una arquitectura muy simple y sin ajustar hiperparámetros, acierta $5$ de cada $6$ flores reales.

El bootstrapping apunta en la misma dirección. La diferencia ($\Delta S-R$) es negativa en las tres métricas, con IC al $95\%$ de aproximadamente $[-0.2, 0]$. Pero como el extremo superior toca el cero (los resultados son como mucho, iguales, y por ello la diferencia es cero), la evidencia es débil y no podemos descartar que la diferencia sea nula. Mejorar la arquitectura y los hiperparámetros probablemente reduzca la brecha.

¿Los datos sintéticos son realmente buenos?

Cuando queremos saber si los datos sintéticos son buenos, tenemos un amplio abanico de metodologías que nos proporcionan métricas muy interesantes para analizar. En este caso, vamos a probar con resemblance para ver lo buenos que son en similitud. Se trata de intentar distinguir si un dato es sintético o real, por lo que es una clasificación binaria. Para ello he utilizado un random forest como discriminador y he etiquetado cada muestra.

Los resultados son… ¡Una mierda! El discriminador es capaz de distinguir perfectamente entre los datos reales y los sintéticos. Desde el punto de vista de resemblance, esto indica que ambos conjuntos presentan diferencias claras que el random forest puede aprovechar para clasificarlos. De hecho, mirando las agrupaciones generadas en las imágenes anteriores, visualmente es bastante perceptible.

Sin embargo, este resultado no significa por sí mismo que los datos sintéticos sean inútiles ni que tengan una mala privacidad. Resemblance mide hasta qué punto los datos sintéticos se parecen a los reales, pero no mide directamente si existe riesgo de revelar información sobre los individuos utilizados durante el entrenamiento.

Que los datos sintéticos sean suficientemente útiles como para entrenar otro modelo no significa necesariamente que reproduzcan fielmente la distribución de los datos reales. Del mismo modo, conseguir que sean muy parecidos a los datos originales tampoco garantizaría que sean privados. Utilidad, similitud y privacidad son propiedades relacionadas, pero diferentes, y será necesario evaluarlas por separado.

¿Y qué pasa con la privacidad?

Para evaluar la privacidad necesitamos comprobar algo distinto, como por ejemplo, si es posible averiguar qué registros reales fueron utilizados para entrenar el CVAE. Para ello, realizamos un Membership Inference Attack, comparando los registros del conjunto de entrenamiento con los del conjunto de test. Para cada registro calculamos su distancia al dato sintético más cercano y utilizamos esta distancia como señal para intentar distinguir entre ambos grupos. Si el CVAE hubiera memorizado registros de entrenamiento, estos podrían quedar más cerca de los datos sintéticos generados que los registros que nunca vio.

La capacidad del ataque se mide mediante ROC-AUC, donde un valor cercano a $0.5$ indica que el ataque no consigue distinguirlos. En este experimento obtenemos un score de $0.461$, ¡buenas noticias por fin!

Esto, de nuevo, no significa que el CVAE sea completamente privado, sino únicamente que este ataque concreto no consigue extraer una señal clara de membership. Precisamente por eso, en los siguientes artículos veremos ataques y métricas más sofisticados para estudiar hasta qué punto los datos sintéticos pueden proteger realmente la información utilizada durante el entrenamiento y qué otras formas hay de generarlos.

No todos los problemas son igual de complicados. Cuando hablo de la complejidad de un problema, a lo que me refiero es a los recursos que consume una serie de pasos definidos para poder hallar una solución a ese problema. Por lo general, los recursos que utiliza un algoritmo (la serie de pasos definidos y ordenados para solucionar un problema) suelen ser dos, tiempo y espacio. El espacio es la cantidad de información que debemos guardar para poder resolver ese problema. Por ejemplo, ¿cuál es la complejidad de la codificación numérica? Si quiero escribir un número en decimal, por ejemplo $1365$, necesito $4$ caracteres (dígitos). En cambio, para $13454390$ necesito solo $8$ caracteres, pese a que el valor haya crecido enormemente, la cantidad de información para representarlo no lo ha hecho tanto. En general, ya sea en binario, decimal o con otra codificación, si el número es $x$, el número de caracteres que necesito es de orden $n = log(x)$. Esa es su complejidad en espacio definida como una función.

La complejidad temporal indica cuánto trabajo computacional necesita un algoritmo para resolver un problema. Tanto la complejidad en espacio como la temporal dependen del tamaño de entrada del problema. En el ejemplo anterior el tamaño de entrada es el valor del número en sí.

En la tabla se muestran distintos tipos de crecimientos con respecto al tamaño de la entrada. Un problema con complejidad exponencial puede resolverse de forma muy rápida para entradas pequeñas, pero en cuanto crece un poco el tiempo de resolución sale disparado. Por ello, conocer la complejidad de un problema de antemano es necesario en muchos casos para saber aterrizar las expectativas.

El hecho de que existan algoritmos exactos para algunos de estos complejísimos problemas ya es algo por lo que dar gracias. Otros problemas no tienen solución conocida (y posiblemente sea necesario aplicar algoritmos de aprendizaje para encontrar soluciones suficientemente buenas, como bien expliqué en mi primer post). Pero claro, ¿de qué sirve un programa que resuelve el problema si te dará la respuesta en unos pocos años? No es viable esperar esa cantidad de tiempo. Por ello es que existen métodos mucho más rápidos, pero que sacrifican la exactitud por la velocidad. Dentro de estos métodos están, por ejemplo, los algoritmos genéticos de los que ya hablé.

Hoy, explicaré otro de estos métodos de búsqueda. El conocido como GRASP (Greedy Randomized Adaptive Search Procedure).

Problemas combinatorios

El algoritmo de GRASP se utiliza sobre todo en resolución de problemas combinatorios. Un problema es combinatorio cuando las soluciones se construyen mediante combinaciones de elementos discretos, como por ejemplo el problema de la mochila, en el que se debe seleccionar un conjunto de objetos a guardar en una mochila, maximizando el valor total y sin pasarse del peso máximo permitido. Este tipo de problemas se pueden solucionar a lo bruto, que es lo primero que se suele intentar. En este caso, procedo a crear todas las combinaciones de objetos dada la restricción del peso máximo. Después, simplemente cojo aquella que tenga mayor valor. ¿Sencillo? Sí. ¿Eficiente? Como tengas una mochila de muchos litros quizá te pases eones esperando a la solución final…

La complejidad del problema de la mochila, resuelto por fuerza bruta, es de $O(2^n)$. Sin entrar en detalles, la $O$ de $O(n)$ viene de “Big O” y sirve para describir cómo crece el coste de un algoritmo cuando aumenta el tamaño de la entrada. En este caso significa que, por fuerza bruta, el número de pasos/operaciones crece con la función $2^n$. Puesto que cada objeto tiene dos posibilidades (cogerlo o no cogerlo) y existen $n$ objetos totales, en el peor de los casos habremos realizado un total de $2^n$ operaciones.

El problema del viajante (TSP)

El problema del viajante o Traveling Salesman Problem en inglés es el “hola mundo” de la optimización. Dada una lista de ciudades y las distancias entre cada par de ellas, ¿cuál es la ruta más corta posible que visite cada ciudad exactamente una vez y al final regrese a la ciudad de origen? El TSP, por sus siglas en inglés, tiene diversas aplicaciones en planificación y logística. Es por ello que voy a codificar en Python cómo funciona y voy a resolverlo tanto por fuerza bruta como con GRASP.

Definición formal

El TSP puede ser formulado de la siguiente forma:

• Sea $x_{ij}$ igual a $1$, si se elige un camino entre la ciudad $i$ y la ciudad $j$, $0$ en otro caso, para el conjunto de ciudades $0,…,n$. Sea $d_{ij}$ la distancia entre la ciudad $i$ y la ciudad $j$. El conjunto de todas las ciudades es $V$. Dadas estas variables se define el problema de optimización con la función objetivo:

• Es decir, se intenta minimizar la distancia total viajada. La restricción es que cada ciudad solo se debe visitar una vez. Es decir, de cada ciudad se sale una vez:

• A cada ciudad se entra solo una vez:

• Y no se puede entrar a la misma ciudad de la que se salió:

Este problema es mucho más complejo que el de la mochila. Donde antes se buscaban todas las combinaciones sin importar el orden, ahora se buscan todas las permutaciones. Ya no es lo mismo el camino $A\rightarrow B$ que el camino $B\rightarrow A$. Esa pequeña diferencia hace que el problema ya no sea exponencial, sino factorial: $O(n!)$. En términos de crecimiento es una pesadilla.

TSP en Python

Para poder resolver el problema, primero debemos representarlo. Lo que he hecho es representar en un plano $2D$ las coordenadas de cada ciudad. De esta forma es muy sencillo calcular posteriormente la distancia entre ellas y además podemos visualizar el grafo, que siempre queda muy bonito y hace que cale todo mucho mejor. La siguiente función crea una matriz $N\times 2$ de forma aleatoria donde $N$ es el número de ciudades. Cada ciudad tendrá dos valores, las coordenadas.

def create_cities(num_cities: int) -> np.ndarray:
    """Create random coordinates representing a set of cities.

    Args:
        num_cities (int): Number of cities.

    Returns:
        np.ndarray: A matrix containing the coordinates of each city.
    """

    return np.random.rand(num_cities, 2)

Ahora hay que calcular la matriz de distancias. En esta matriz, cada elemento de una fila corresponde a una ciudad y cada elemento de una columna repite las ciudades. De esta forma, codificamos en una estructura matemática las distancias entre cada par de ciudades. Obviamente, esta matriz contendrá la distancia entre una ciudad y ella misma. Estas posiciones corresponden a la diagonal de la matriz. Una forma de hacer este cálculo sería aplicar dos bucles sobre la matriz, de forma que fuese uno a uno computando las distancias. Por suerte, en Numpy existe lo que se conoce como “broadcasting”, lo cual permite hacer esta operación mucho más eficiente (todos los cálculos se hacen a la vez). En otro post, explicaré en detalle cómo funciona.

La distancia es la distancia euclídea, que en dos dimensiones es:

En Numpy tenemos la conveniente función de np.linalg.norm.

def create_distance_matrix(cities: np.ndarray) -> np.ndarray:
    """Create a symmetric distance matrix from a set of city coordinates.

    Args:
        cities (np.ndarray): Matrix containing the coordinates of each city.

    Returns:
        np.ndarray: A symmetric matrix containing the distances between cities.
    """

    diff = cities[:, None, :] - cities[None, :, :]
    return np.linalg.norm(diff, axis=-1)

Con estas dos funciones ya podemos visualizar las distintas ciudades en un gráfico y aplicar distintos algoritmos de resolución para encontrar el camino más eficiente de reparto.

Fuerza bruta

La solución de TSP por fuerza bruta no tiene misterio. Debemos crear todas las permutaciones (no combinaciones, aquí sí importa el orden) de caminos posibles dadas las restricciones de que solo se puede pasar una vez por cada ciudad, hay que pasar por todas y hay que volver a la ciudad de origen. Después, seleccionar aquella que tenga la menor distancia total recorrida.

De nuevo, en Python existe la librería itertools con funciones muy convenientes como permutations, que nos permite iterar sobre todas las permutaciones posibles de un conjunto dado.

Las siguientes funciones calculan el coste de un camino (necesitamos la matriz de distancia para ver cuánta distancia hay entre dos ciudades y la lista de ciudades que compone un camino) y el algoritmo de búsqueda del camino más corto por fuerza bruta. Es muy sencillo, vamos iterando por cada permutación y la vamos evaluando. Si es la mejor hasta ahora, la guardamos. Así hasta expresar todas las combinaciones. Existen maneras mucho más eficientes de hacer la búsqueda y asegurar que sea exacta, sin metaheurísticas y con garantías, pero hace falta aplicar algoritmos de programación dinámica y estoy bastante oxidado (hay que practicar más Leetcode).

def tsp_cost(tour: np.ndarray, distance_matrix: np.ndarray) -> float:
    """Compute the total cost of a TSP tour.

    The tour is treated as a closed cycle, including the return from the
    last city to the starting city.

    Args:
        tour (np.ndarray): Ordered array of city indices.
        distance_matrix (np.ndarray): Pairwise distance matrix.

    Returns:
        float: Total cost of the tour.
    """

    cost = 0.0

    for i in range(len(tour) - 1):
        cost += distance_matrix[tour[i], tour[i + 1]]

    cost += distance_matrix[tour[-1], tour[0]]

    return cost


def solve_tsp_brute_force(distance_matrix: np.ndarray) -> tuple[np.ndarray, float]:
    """Solve the Traveling Salesman Problem (TSP)

    Args:
        distance_matrix (np.ndarray): A square symmetric matrix of shape
            (n, n), where distance_matrix[i, j] represents the distance
            between cities i and j.

    Returns:
        tuple[np.ndarray, float]:
            - The optimal tour as a NumPy array of city indices, starting
              at city 0.
            - The total length (cost) of the optimal tour, including the
              return from the last city back to the starting city.
    """
    n = distance_matrix.shape[1]
    best_tour = None
    best_cost = np.inf

    for rest in permutations(range(1, n)):
        tour = (0,) + rest
        tour_array = np.array(tour)
        tour_cost = tsp_cost(tour_array, distance_matrix)

        if best_cost > tour_cost:
            best_cost = tour_cost
            best_tour = tour_array

    return best_tour, best_cost

GRASP

El algoritmo GRASP viene a ser una mejora del famoso algoritmo greedy o voraz, por tanto convendría programar una alternativa puramente greedy para compararla tanto con el método por fuerza bruta como con GRASP.

El método greedy, si bien es rápido y obtiene buenas soluciones, muchas veces no es suficiente. Estos tipos de búsqueda tienen una limitación importante, y es que son incapaces de explorar el espacio de búsqueda pues su naturaleza se basa en moverse al siguiente mejor estado, sin considerar nada más que el estado actual. Si el mejor movimiento es moverse de la ciudad $A$ a la ciudad $B$, lo hace. Pero puede ocurrir que, lo que a priori es un mal movimiento, termine resultando en su conjunto una mejor solución. Por ello muchas metaheurísticas incluyen procesos estocásticos, a modo de exploración. En el caso de GRASP se abordan dos fases generales:

Exploración

Empezando por la ciudad de origen, GRASP construye de forma incremental una solución seleccionando la siguiente ciudad desde una lista de candidatos restringida (RCL). Esta lista contiene a los mejores candidatos en función del criterio greedy (es decir, para TSP es la menor distancia a la ciudad actual). Desde esta lista, para romper con el determinismo de greedy, se elige el candidato al azar. Esta es la fase “exploratoria” y puede controlarse mediante el parámetro $\alpha$.

Este parámetro determina hasta qué punto se relaja el criterio greedy para construir la RCL. Para ello, se establece un umbral entre el coste del mejor y el peor candidato:

donde $C_{\min}$ y $C_{\max}$ representan, respectivamente, la menor y la mayor distancia entre los candidatos disponibles. De esta forma, $\alpha$ determina qué proporción del intervalo entre ambos extremos se considera aceptable.

Cuando $\alpha=0$, el umbral coincide con $C_{\min}$, por lo que únicamente el mejor candidato forma parte de la RCL. En consecuencia, el comportamiento es equivalente al de un algoritmo greedy. A medida que aumenta $\alpha$, el umbral se desplaza hacia $C_{\max}$ y se incorporan más candidatos a la RCL, aumentando la diversidad de las soluciones construidas. Con $\alpha=1$, todos los candidatos son aceptados y la siguiente ciudad se selecciona completamente al azar.

Explotación

Una vez se construye una solución siguiendo un método pseudo-greedy, se explota mediante una búsqueda local. Este tipo de búsqueda se basa en cambios menores sobre la solución original, cambios en su vecindario más cercano. Son métodos muy rápidos y sencillos de implementar que intentan mejorar al máximo la solución actual, por ello son algoritmos de fase de explotación. Existen muchas implementaciones, pero en mi caso he implementado una búsqueda local sencilla, basada en intercambiar pares de ciudades de posición y aceptar la primera que mejore el costo. La búsqueda termina cuando ya no mejora más.

La fase de exploración y explotación se repiten durante una serie de iteraciones definidas, hasta que no haga mejoras significativas o incluso hasta un tiempo máximo definido. El criterio de parada es muy variado. El código en Python es el siguiente:

class TSP_GRASP:
    def __init__(self, max_iterations: int = 20, alpha: float = 0.2):
        self.max_iterations = max_iterations
        self.alpha = alpha

    def build_solution(self, distance_matrix: np.ndarray) -> np.ndarray:
        """Construct a feasible TSP solution using the GRASP construction phase.

        Starting from city 0, the solution is built incrementally by selecting
        the next city from a Restricted Candidate List (RCL). The RCL contains
        the best candidates according to the greedy criterion, and one of them
        is chosen uniformly at random.

        Args:
            distance_matrix (np.ndarray): Pairwise distance matrix.

        Returns:
            np.ndarray: A feasible TSP tour represented as an ordered array of
            city indices.
        """

        n = distance_matrix.shape[1]

        unvisited = np.array([i for i in range(1, n)])
        candidates = []
        solution = np.zeros(1, dtype=np.int64)

        for _ in range(n - 1):
            for city in unvisited:
                cost = distance_matrix[solution[-1], city]

                candidates.append((city, cost))

            costs = [cost for _, cost in candidates]
            min_cost = min(costs)
            max_cost = max(costs)

            threshold = min_cost + self.alpha * (max_cost - min_cost)
            rcl = [city for city, cost in candidates if cost <= threshold]
            next_city = np.random.choice(rcl)
            solution = np.append(solution, next_city)

            unvisited = np.setdiff1d(unvisited, [next_city])
            candidates = []
        return np.array(solution)

    def local_search(
        self, solution: np.ndarray, distance_matrix: np.ndarray
    ) -> np.ndarray:
        """Improve a TSP solution using a swap-based local search.

        The algorithm iteratively swaps pairs of cities and accepts the first
        improving move. The process stops when no improving swap is found.

        Args:
            solution (np.ndarray): Initial TSP tour.
            distance_matrix (np.ndarray): Pairwise distance matrix.

        Returns:
            np.ndarray: Locally improved TSP tour.
        """

        best_solution = solution.copy()
        best_cost = tsp_cost(best_solution, distance_matrix)

        improved = True

        while improved:
            improved = False

            for i in range(1, len(solution) - 1):
                for j in range(i + 1, len(solution)):
                    candidate = best_solution.copy()
                    candidate[i], candidate[j] = candidate[j], candidate[i]

                    candidate_cost = tsp_cost(candidate, distance_matrix)

                    if candidate_cost < best_cost:
                        best_solution = candidate
                        best_cost = candidate_cost
                        improved = True
                        break

                if improved:
                    break

        return best_solution

    def optimize(self, distance_matrix: np.ndarray) -> tuple[np.ndarray, float]:
        best_solution = None
        best_cost = np.inf

        for _ in range(self.max_iterations):
            solution = self.build_solution(distance_matrix)

            solution = self.local_search(solution, distance_matrix)

            cost = tsp_cost(solution, distance_matrix)

            if cost < best_cost:
                best_solution = solution
                best_cost = cost

        return best_solution, best_cost

Resultados

Ha llegado la hora de comparar las tres opciones propuestas, la fuerza bruta, el voraz básico y GRASP. Aquí los resultados para TSP con $5, 9, 11$ y $12$ ciudades:

Como puede observarse, el algoritmo por fuerza bruta no es una opción que pueda utilizarse en la vida real. Ni paralelizándolo ni usando una versión más eficiente por programación dinámica sería usable, todas las versiones alcanzarían en algún punto tiempos imposibles. Mientras tanto, las versiones de greedy y GRASP pueden crecer y crecer y seguir siendo veloces al encontrar la solución. En estos resultados además se observa la diferencia clave entre ambos. El algoritmo voraz no encuentra nunca el óptimo global en las pruebas realizadas, mientras que GRASP lo hace siempre.

Hay que entender que GRASP no garantiza el óptimo global como sí lo hace la fuerza bruta, pero es capaz de aproximar el valor y obtener soluciones suficientemente buenas. Todo ello haciendo un simple cambio al greedy de toda la vida.

Hoy me apetece escribir. Llevo unos mesecillos un tanto ajetreados entre el trabajo, lo personal y la finalización de mi trabajo de fin de máster. Toda esa carga ha hecho que tenga menos tiempo y ganas de escribir por aquí. Además, tengo otros hobbies que atender. Seguramente empiece poco a poco a retomarlo, a escribir más, pero posts más cortos, con menos carga teórica y sin programación de por medio. Al fin y al cabo, para eso inicié este blog, para escribir más y disfrutar en el camino, no para añadirme otra carga todas las semanas, no para añadirme a la fuerza conceptos y tecnologías nuevas que aprender.

Hoy quería escribir sobre el concepto de democratización de la inteligencia, algo de lo que se ha hablado bastante desde que la masa descubrió a ChatGPT. Si no recuerdo mal, descubrí GPT (que no ChatGPT) con los vídeos de DotCSV, cuando estaba en segundo o tercero de carrera, allá por el $2020-2021$. Jugaba en un entorno de pruebas con una red neuronal capaz de generar texto. Sin embargo, a partir de los pocos párrafos dejaba de tener sentido nada de lo que ese modelo escribiera, pero el hecho de poder escribir siquiera algo con el más mínimo sentido era una bomba. Desde entonces los modelos de lenguaje han tenido una evolución exponencial en cuanto a sus capacidades. El contexto (explicado como la cantidad de información que pueden contener en una sola sesión) que manejan es gigantesco, su conocimiento abarca todo Internet y más allá. Son capaces de programar mejor que cualquier recién graduado y de generar textos casi indistinguibles de un ser humano. También se hicieron mainstream, y con ello, las grandes masas conocerían lo que era la IA.

Personalmente, como alguien que ha estudiado Ingeniería Informática, especializándose en sistemas inteligentes y computación (viene a ser la rama de IA), he de reconocer que me dio un poco de coraje. El conjunto de métodos que llamamos Inteligencia Artificial han existido desde hace décadas. Los algoritmos genéticos, los sistemas de conocimiento, algoritmos de búsqueda de caminos, el machine learning en general, han sido considerados IA desde hace mucho. Los LLMs no son más que redes neuronales entrenadas con todo el texto conocido (simplificando mucho). Pero mi desagrado con el nuevo cambio de concepto de la IA no viene del propio viraje de significado a nivel general, que como friki petardo algo sí que me molesta (pero es natural y lo entiendo). Viene más bien del auge de los expertos en IA. ¿Quiénes son estos expertos? Cantamañanas y buscavidas que, en su mayoría, descubrieron la IA ayer (con ayer me refiero a un par de meses antes que el público general). Son la evolución de los crypto bros o los pesados de los NFTs. De este tipo de personas está el mundo lleno y no es, a priori, tan malo. Lo malo es que están por doquier y no solo en los anuncios petardos de redes sociales. Antes te intentaban vender cursos, pero eran cuatro gatos. Ahora están en todos lados, en el trabajo, en la familia, en todos tus círculos.

Esas personas antes se podían ignorar, pero ahora ya no, son una masa. El mercado está lleno de personas que han hecho un giro de $180$ grados con su profesión, ahora son expertos en IA, ahora son prompt engineers. Se han formado con cursos de otros expertos en IA que en su mayoría tienen un contenido pobre, nada técnico y que en algunos casos roza lo absurdo. Muchos sectores han virado hacia la nueva IA y se habla mucho de democratización de la inteligencia, que viene a significar que ya no hace falta usar mucho el coco para hacer cosas mínimamente complicadas. ¿De verdad es así? Hablando sobre lo que sé, la informática, ¿está ocurriendo? Pues en parte sí. Al principio usábamos los LLMs para generar trozos de código, para ayudarnos y darnos un extra de velocidad, pero es que ya estamos en un punto en el que se generan proyectos en dos días, proyectos que antes podrían haber durado cuatro meses.

He vivido en mis propias carnes lo que es ir poco a poco convirtiéndote de un programador a un supervisor de la IA. Antes pensaba, planeaba, me informaba y volvía a planear, luego programaba y después corregía. Todo ese proceso me hacía sentir pleno en mi trabajo, le daba un sentido. Tenía que trabajar con un conjunto de restricciones y resolver un problema que podía ser más o menos trivial, pero todo ese proceso, aunque lento, era estimulante, gratificante. Poco a poco, te hacía mejor profesional. Ser supervisor de la IA le quita toda la gracia y creo que traerá serios problemas en el futuro. Hoy, se usan agentes potentísimos de IA que hacen que la resolución de un bug menor, la cual podía tenerte ocupado un par de horas o incluso un día, se resuelva con un prompt. Los proyectos de meses son ahora realizados en dos días. El precio a pagar es tener que sentarte a hablar con un bicho que a todas luces es un tarugo, pero que te escupe código medio funcional en segundos (eso sin contar el doloroso precio por token). Es decir, has estudiado complejos algoritmos, tienes nociones de diseño de sistemas eficientes e inteligentes, eres capaz de resolver problemas porque a eso se dedica un ingeniero informático, para terminar dándote cabezazos contra la pared porque Claude Code no te hace caso.

Pues nada, esas capacidades ya no son del todo requeridas. Obviamente sí que son importantes, pero el baremo ha bajado y ahora hay muchas más personas capaces de dedicarse a la programación. Se sigue necesitando a una persona formada, ya que no es viable desplegar proyectos enteros sin la supervisión de un experto. La IA sigue cometiendo fallos garrafales y no es seguro. De ahí viene parte de la “democratización de inteligencia”, de la bajada del baremo. Pero, ¿y los que ya se dedicaban a esto antes de los LLMs? Pues muchos, si no son la mayoría, están siendo obligados directa o indirectamente a programar con IA, ya sea porque el ritmo de entrega se ha visto acelerado, porque son adictos o porque les obligan directamente. Y con ello viene pensar menos. Ya no hay que devanarse los sesos, solo preguntarle al bicho y revisar que medio esté bien. Sinceramente, no lo veo muy mantenible en el tiempo.

…o de la estupidez

Llamadme loco, conspiranoico o hipocondríaco, pero yo noto un bajón delirante en todo lo relacionado con el software. Lo he notado en mis propias carnes al interactuar con decenas de páginas web que uso semanalmente desde hace años y con programas concretos. No solo eso, sino que la cantidad de noticias de nuevas filtraciones de datos en empresas ha crecido, o siento que ha crecido, muchísimo. No uso Windows como sistema operativo personal (dios me libre), pero claramente el vibe coding no está ayudando a que Microsoft deje de ser Microslop.

La calidad del software ha decaído y, con ella, también se degradan poco a poco las capacidades del programador. En mi caso concreto, si no fuera porque disfruto de mi trabajo y consumo contenido de informática, artículos técnicos, machine learning y otras áreas relacionadas, probablemente ya tendría la babilla caída de tanto vibe codear. Por suerte, mi trabajo ha cambiado y ahora puedo dedicarme a tareas más estimulantes, utilizando la IA como un apoyo puntual en lugar de como una muleta. Aun así, el deterioro de mis habilidades como programador fue real. Y mi caso no es aislado, le ocurre a todo el mundo en mayor o menor medida y en casi todos los sectores, no solo en programación. Es una muerte lenta. Por ello, creo que hoy se está produciendo un intercambio peligroso en el que se está sacrificando una mayor velocidad y “eficiencia” a corto plazo por una degradación lenta, pero continua, de la capacidad de análisis crítico y de la razón. Y lo de eficiencia entre comillas porque la deuda técnica se ha multiplicado por mil y a ver quien es el listo que va a mantener ese pedazo de troncho de programa que no entiende ni la propia IA que lo creó. Además, ¿a cuántos de vosotros os da miedo la página en blanco? Siempre lo ha dado, pero ahora podemos rellenarla ya de ya. La consecuencia de esto es una menor creatividad, una degradación de la calidad del trabajo realizado y una lenta castración.

Esto es algo que ocurre a niveles bajos en la jerarquía laboral, pero los CEOs, directivos, personas en general que se dediquen a la organización y gestión de otros, también sufren de esto. Los LLMs son como un psicólogo incompetente que en vez de ayudarte te autovalida. Te da la razón y encima te da argumentos falaces para justificar cada subnormalidad que uno pueda llegar a pensar. Es como la gente que se apoya en “artículos científicos” para explicarte por qué comer <inserte aquí cualquier tipo de alimento> es nocivo para la salud, pero con esteroides. Y eso, para alguien cuya responsabilidad consiste en tomar decisiones que afectan a decenas o cientos de personas, además del rumbo de la propia empresa como entidad, es peligrosísimo. El valor de una organización no está solo en ejecutar, sino en confrontar ideas, escuchar a quienes saben más que tú en cada área y dejar que tus decisiones sobrevivan al escrutinio de otros. Si sustituyes ese proceso por una conversación con un modelo cuyo objetivo principal es resultar útil y convincente, corres el riesgo de encerrarte en una cámara de eco extremadamente sofisticada. ¿Se darán cuenta de esto a la larga y a las malas? O quizá nos reorganicemos de otro modo más eficiente y todo salga genial. Yo no soy conocedor de la verdad.

Quizá no importe mucho, quizá la IA mejore tanto que estos pequeños errores ya no sean un problema y la inteligencia humana y el criterio queden en un segundo plano. Yo lo dudo. Los LLMs son uno de los mayores avances tecnológicos de los últimos años, pero tienen problemas serios inherentes a su naturaleza y eso lo están notando hasta las empresas como OpenAI y Anthropic. La escala por fuerza bruta se está acabando, por no hablar ya de otros problemas como el del autoconsumo. La IA se alimentó de la inteligencia colectiva de Internet, pero ahora corre el riesgo de alimentarse de su propio reflejo, pero eso es otro tema.

Siendo positivos, todo convergerá, como ha ocurrido siempre con todas estas cosas, a un punto medio mucho más razonable. Ocurrió con la burbuja dot-com, con las criptomonedas, los coches eléctricos o incluso el Big Data. Primero llega la euforia, después la decepción, y finalmente la adopción real. Solo necesita tiempo. Y siendo negativos, pues quizá haya que ir aprendiendo la profesión de fontanería.

Hace ya un tiempo que quería implementar lo que vengo conociendo como la técnica teacher-student. La he visto en otros blogs, en vídeos de Youtube, en foros, etc. Siempre me ha parecido muy vistosa y bastante sencilla de implementar. La idea es simple, coges una red neuronal muy grande y tratas de copiar sus salidas mientras entrenas una red mucho más pequeña. De ahí viene el nombre de teacher-student, ya que una red (profesora) muestra sus conocimientos a otra red que la imita (estudiante). Los blogs que leía en su momento hablaban sobre minimizar la divergencia Kullback-Leibler entre la distribución de los logits del profesor y del estudiante. La distancia Kullback-Leibler, a la que me voy a empezar a referir como KL por simplicidad, cuantifica la diferencia entre dos distribuciones de probabilidad. No es una distancia (matemáticamente hablando), pero como si lo fuera para nosotros.

No era tan sencillo

Pues bien, resulta que no es tan sencillo sacarle el jugo a esta técnica. Para la escritura de estos posts suelo programar algún que otro script de Python para mostrar cómo se hacen las cosas y también para desengrasarme un poco, que al final estos posts son sobre todo para mí. El tema es, que es bastante más delicado de lo que me imaginaba. Las primeras veces tiraba de un modelo como ResNet-18 o ResNet-50 para aprender a clasificar datos del problema de CIFAR (imágenes de objetos y animales de $32\times 32$ píxeles). Muchas veces la red se sobreajustaba, lo cual es muy común en redes con demasiados parámetros (algún día hablaré de ello). Cuando una red se sobreajusta, significa que memoriza los datos de entrenamiento, los cuales incluyen ruido, lo cual hace que el modelo no rinda bien en datos nunca vistos. Eso tiene fácil solución, aplicamos early stopping. Luego, entrené a dos modelos pequeños, quizá demasiado pequeños. Uno de ellos aprendería de forma tradicional a clasificar las imágenes de CIFAR-10 y el otro imitaría al modelo profesor. Ninguno rendía bien, de hecho el que peor iba era el modelo que usaba técnicas de destilación de conocimiento. Quizá son demasiado pequeñas, pensé. Procedí a aumentar los tamaños de las redes estudiante y los resultados fueron distintos. Esta vez, la red pequeña sin destilar conseguía un resultado mejor que el profesor, incluso, mientras que la destilada era peor. En este caso puede tener sentido, si la red profesor ni siquiera supera a sus propios alumnos, ¿qué narices va a enseñar?

Tras varias iteraciones sin conseguir nada hice lo que debería haber hecho en un inicio, leer el paper original para ver si se me había pasado algo. Este artículo se puede encontrar aquí.

Sobre lo aprendido

Uno de los principales conceptos que aprendí en el artículo era el de soft labels y hard labels. Las etiquetas duras son directamente las clases a predecir. Por ejemplo:

Donde la posición donde se encuentre el $1$ es la clase correcta a predecir de las cuatro que hay. En el entrenamiento más típico, con una función como la entropía cruzada, lo que se utiliza son etiquetas duras. Esta función solo se centra en maximizar la probabilidad de la clase correcta. No voy a entrar en explicar entropía cruzada, seguramente lo deje para otro post, pero para más información dejo este enlace.

Las etiquetas duras solo nos dicen qué clase es la correcta, pero no aporta mayor información. Podríamos preguntarnos, ¿cómo de similares son las clases? o ¿cuánta incertidumbre hay? Para la función de pérdida es lo mismo confundir a un perro con un lobo, que a un perro con un avión. Claramente no es un error de la misma magnitud y las etiquetas duras no nos transmiten este tipo de información.

Aquí es donde entran las soft labels o etiquetas suaves. Las soft labels son probabilidades generadas, en este caso, por el modelo profesor. Por ejemplo:

Este tipo de estructura sí permite capturar más información, más allá de si es la clase correcta o no. Aquí las clases incorrectas también aportan su granito de arena. Se pueden interpretar las probabilidades asignadas a las demás clases como una representación de las similitudes aprendidas por el modelo. Por ejemplo, si una imagen de un perro recibe también cierta probabilidad en las clases “lobo” o “zorro”, el modelo está indicando que comparte características visuales con esas categorías.

Hay un detalle importante que me dejé por el camino durante mis primeros experimentos. En la destilación de conocimiento no solemos utilizar directamente las probabilidades producidas por el profesor, sino una versión suavizada de ellas. Para ello se divide el vector de logits entre una temperatura antes de aplicar la función softmax. Cuando $T=1$ obtenemos las probabilidades normales del modelo. Sin embargo, al aumentar la temperatura, la distribución se vuelve más uniforme y aparecen relaciones entre clases que normalmente quedarían ocultas. Por ejemplo, una imagen que el profesor clasifica con un $99\%$ de confianza como “perro” podría transformarse en una distribución más suave donde también aparezcan probabilidades apreciables para “lobo” o “zorro”. Esta información adicional resulta muy valiosa para el estudiante, ya que no solo aprende cuál es la respuesta correcta, sino también qué alternativas considera plausibles el profesor. En mi implementación he aplicado un $T=4$, que suele ser bastante estándar y me ha proporcionado buenos resultados. Las soft labels del modelo profesor albergan la distribución “objetivo” que el modelo estudiante ha de aprender. Para ello se utiliza la anteriormente mencionada divergencia KL.

La combinación de ambos tipos de etiquetas produce lo que podríamos definir como sweet spot, ya que incluimos ambos tipos de codificaciones para que la optimización se nutra. No siempre más es mejor, y por supuesto podríamos usar solo las soft labels, como pensaba que funcionaba la destilación de conocimiento al principio, pero parece que funciona mejor con ambas. Para poder darle más potencia a una que a la otra, controlamos un parámetro $\alpha$, que en mi caso he dejado en $50\%$ para darle igual fuerza a las codificaciones duras que a las suaves en la función de pérdida. La función en Python es la que sigue:

def distillation_loss(student_logits, teacher_logits, labels, T=4, alpha=0.5):
    soft_student = F.log_softmax(student_logits / T, dim=1)
    soft_teacher = F.softmax(teacher_logits / T, dim=1)
    kl = F.kl_div(soft_student, soft_teacher, reduction="batchmean")
    ce = F.cross_entropy(student_logits, labels)
    return alpha * ce + (1 - alpha) * (T * T) * kl

Otra cosa que he tenido que afinar al máximo es el rendimiento del modelo profesor. Al principio probé con un modelo grande y sencillo, sin muchas complicaciones, pero si el modelo es grande, es posible que necesitemos ajustar todo el pipeline de entrenamiento al máximo para poder sacarle rendimiento y huir del temido sobreajuste. En mi caso, apliqué aumentaciones de datos sobre las imágenes (cortes aleatorios sobre la imagen y giros horizontales). Estas técnicas permiten que la red observe distintos ángulos y versiones de la misma imagen, mejorando la capacidad de generalización. También se normalizaron los datos y se aplicó early stopping para poder parar el entrenamiento cuando la red dejase de mejorar. Por supuesto, esto también ha de hacerse con los modelos estudiantes.

Resultados obtenidos

Para evaluar los resultados y comparar el modelo que usa destilación de conocimiento frente al que no, presento un par de métricas importantes. Estas son la compresión y la eficiencia:

La compresión simplemente nos muestra cómo de mucho se ha vuelto el modelo frente al original o profesor. A más grande, más pequeño es el modelo estudiante, menos parámetros. La eficiencia es un ratio entre la precisión y la compresión. Esta última es la más interesante y comparable, ya que permite ver si un modelo es bueno en dos dimensiones distintas. Es interesante reducir mucho el modelo y alcanzar una compresión lo más alta posible, pero si la precisión se ve afectada demasiado, quizá ya no merezca la pena seguir reduciendo. De otra forma, si la precisión se va conservando, quizá sea interesante seguir reduciendo el número de parámetros para obtener un modelo más eficiente.

Tras entrenar al profesor y a los estudiantes, se obtuvieron los siguientes resultados:

De base, el modelo más grande obtiene un $88\%$ de precisión con $23$ millones de parámetros. Obviamente la compresión es de $1.0$ ya que es el modelo de referencia. En el caso de los modelos estudiantes (aunque en realidad uno no es estudiante de nada, se ha entrenado solito sin profesor jeje) se obtienen ratios de compresión iguales, ya que ambos tienen la misma cantidad de parámetros. Lo interesante se observa en la métrica de accuracy y de eficiencia. El estudiante que usó la técnica de destilación de conocimiento, alcanzó un $5\%$ más de precisión que la red neuronal que se entrenó de forma tradicional. De esta forma, la eficiencia es $3$ puntos superior a la del modelo sin destilación.

Este es un caso sencillo, con redes que ya de base funcionan muy bien. Quizá podría haberse entrenado aún mejor al modelo profesor, o se podría haber utilizado un conjunto de datos más complicado para aprovechar mejor esas neuronas extra. Pese a ello pueden observarse los resultados.

Nunca había probado a implementar esta técnica, y para ser sinceros, pensaba que sería mucho más sorprendente. Después de leer un poco de literatura al respecto, depende mucho del ámbito y se aprovecha mejor en entrenamientos mucho más grandes, como los que sufren los modelos de lenguaje actuales. Además, la mejora esperada suele ser leve, de un $2\%$ o $5\%$. Esta técnica es muy usada para la compresión de modelos, sin restringir sus capacidades y partiendo de modelos inmensos y probablemente altamente sobreajustados, pero claro, ¿qué es el sobreajuste cuando puedes sobreajustar el universo?. Si bien se ha hecho muy popular estos últimos años para LLMs, creo que hay mejores opciones para otros ámbitos fuera del lenguaje, como el pruning o la cuantización. Pese a ello, siempre es interesante probarlo, compararlo y saber cuándo utilizarlo si se requiere.

Cuando nos preguntamos si una IA es capaz de reconocer aquello que no conoce, ¿a qué nos estamos refiriendo? Ya hemos visto en el post de la geometría del Perceptrón cómo comenzó el desarrollo de redes neuronales, inspirados en cómo funcionan las neuronas (de forma simplificada al menos). Con el paso del tiempo se fueron desarrollando redes más y más complejas, capaces de aprender patrones sutiles, mejores en tareas varias como el reconocimiento de voz, segmentación de objetos en imágenes, reconocimiento de objetos, clasificación, etc.

La IA basada en redes neuronales es muy potente y flexible, pero también puede ser un poco como una caja negra. Es difícil analizarla y dar respuestas simples a preguntas acerca de su comportamiento. Muchas veces es necesario prescindir de ellas por razones de seguridad, ya que métodos más fáciles de explicar e interpretables son obligatorios en ciertos sectores con alta regulación o en los que simplemente se prima ese factor por encima de la potencia. Volviendo a la pregunta, ¿sabe la IA lo que no sabe? Esta pregunta entraña un tema muy profundo, altamente estudiado y que todavía no está resuelto en su totalidad.

Cuando una red neuronal aprende, esta ajusta sus parámetros internos para minimizar una función de pérdida concreta. En la tarea de clasificación de imágenes, lo que sus parámetros ajustan es la discriminación máxima entre distintas clases de imágenes, por ejemplo reconocer gatos y perros. ¿Qué pasará cuando la red neuronal se vea expuesta a un tipo de dato distinto? Ya no obtendrá como entrada la foto de un perro o un gato, sino la de un tigre. ¿Qué respuesta dará la IA frente a esta situación totalmente nueva? Pues si no se hace nada al respecto, lo único que puede hacer la red es dar las probabilidades de que sea un gato o un perro (probablemente tienda a creer que es un gato).

La respuesta a esta pregunta es clara. La red neuronal no sabe lo que no sabe, es decir, no es capaz de ver un dato y discernir si es un nuevo concepto, algo que no ha visto nunca durante su entrenamiento.

Aquí es donde se conecta directamente con el problema de las cajas negras y la seguridad. No solo es difícil entender por qué un modelo toma una decisión, sino que además puede hacerlo con una confianza injustificada incluso cuando está completamente fuera de su ámbito de conocimiento. Este comportamiento es especialmente problemático en sistemas críticos. No detectar que un dato es desconocido implica que el modelo seguirá produciendo predicciones como si todo fuese normal

Durante la etapa de entrenamiento de la red neuronal, los datos provienen de una distribución concreta. Se establece previamente qué tarea va a resolver y eso tiene asociado unos datos concretos, posiblemente no completos. Se presupone que los datos de test, con los que evaluamos la red neuronal tras el entrenamiento, son ejemplos que provienen de la misma distribución. Estos datos nunca han sido vistos durante el entrenamiento, pero eso no significa que tengan una distribución distinta, si entrenamos con gatos y perros no podemos pretender que sepa que es un coche, ¿me explico? La detección de este tipo de datos que la red neuronal no conoce es lo que se llama detección de Out-of-Distribution, a partir de ahora abreviado como OOD.

¿Por qué queremos saber cuando un dato no pertenece a la distribución de entrenamiento?

La fiabilidad en un sistema es un factor clave al que hay que prestar atención, y muchas veces, reconocer datos anómalos o no conocidos es necesario para suplir esta necesidad. Las técnicas de aprendizaje automático han avanzado muchísimo bajo la asunción de un mundo cerrado. Pese a ello, en los problemas del mundo real, estos sistemas se ven expuestos a datos que inevitablemente no pertenecen a la misma distribución que los utilizados durante el entrenamiento de estos modelos. Este tipo de datos son los ya mencionados OOD. Estas muestras pueden ser peligrosas ya que los modelos, al no saber identificar este tipo de problemas, asignan predicciones sobreconfiadas a datos que deberían rechazarse en primer lugar. Esto da lugar a sistemas vulnerables a ataques adversarios, a fallos silenciosos en producción y, en última instancia, a una pérdida de confianza en la tecnología por parte de los usuarios finales.

Existen numerosos métodos que tratan de solucionar este problema desde distintas dimensiones, la elección de uno u otro o todos ellos depende del contexto. ¿Se requiere un modelo que vaya incorporando nueva información con el tiempo según aparezca? Estamos entonces en el campo del online learning, donde el modelo se reentrena o utiliza otras técnicas para actualizar la hipótesis inicial. ¿Queremos detectar si un dato es raro para tratarlo posteriormente? Entonces podemos aplicar detección de OOD.

Un ejemplo claro de donde es crucial que un sistema incorpore este tipo de métodos es en el médico. Un modelo que no pueda detectar muestras OOD juzgará erróneamente enfermedades desconocidas y causará graves diagnósticos erróneos, ya que las clasificará como otro tipo de enfermedad que sí conoce.

Detección por la probabilidad Softmax

El método más simple posible para detectar cuando una entrada a la red es OOD es el de Maximum Softmax Probability o MSP. Las redes neuronales necesitan pasar de los logits que producen las capas finales a una distribución de probabilidad. Para ello suelen utilizar la función softmax:

Esta función transforma ese vector final a un vector acotado entre $[0,1]$ y cuyos componentes sumen $1$, de forma que puede interpretarse como una distribución de probabilidad. Cada componente de ese vector final representa la probabilidad que tiene el dato de pertenecer a la clase $i$.

Este método se basa en la prueba empírica de que las redes neuronales tienden a producir una probabilidad máxima alta (de las probabilidades que hay, la más alta suele ser MUY alta en comparación al resto). Esto intuitivamente lo que nos viene a decir es que la red “conoce” ese ejemplo y por tanto se siente “confiada”. En los datos anómalos, fuera de distribución, las probabilidades suelen ser mucho más uniformes. Por tanto se define MSP como:

Es un método simple. Por supuesto hay mucho más, y más complejos, pero para ilustrar el problema de detección de OOD creo que es el mejor.

Ejemplo con código

Para ilustrar mejor el problema voy a escribir unas pocas líneas en Python, empezando por una red convolucional simple.

class ConvNet(nn.Module):
    def __init__(self, in_channels: int, hidden_units: int, output_channels: int):
        super().__init__()
        self.block_1 = nn.Sequential(
            nn.Conv2d(
                in_channels=in_channels,
                out_channels=hidden_units,
                kernel_size=3,
                stride=1,
                padding=1,
            ),
            nn.ReLU(),
            nn.Conv2d(
                in_channels=hidden_units,
                out_channels=hidden_units,
                kernel_size=3,
                stride=1,
                padding=1,
            ),
            nn.ReLU(),
            nn.MaxPool2d(kernel_size=2, stride=2),
        )
        self.block_2 = nn.Sequential(
            nn.Conv2d(hidden_units, hidden_units, 3, padding=1),
            nn.ReLU(),
            nn.Conv2d(hidden_units, hidden_units, 3, padding=1),
            nn.ReLU(),
            nn.MaxPool2d(2),
        )
        self.classifier = nn.Sequential(
            nn.Flatten(),
            nn.Linear(in_features=hidden_units * 7 * 7, out_features=output_channels),
        )

    def forward(self, x: torch.Tensor):
        x = self.block_1(x)
        x = self.block_2(x)
        x = self.classifier(x)
        return x

Esta red va a ser entrenada con el conjunto de datos de FashionMNIST, donde se representan varios tipos de prendas en imágenes de tamaño $28\times 28$ en escala de grises.

Procedemos a entrenar esta red unas pocas épocas y guardamos el modelo. Este modelo solo conoce datos de este conjunto y es capaz, según la partición de test, de clasificar con un $90\%$ de precisión cualquier otro tipo de imagen de prenda que le venga.

MSP en Python

El código para calcular los scores de MSP es el siguiente:

def compute_msp(model, loader, device):
    all_msp = []

    with torch.inference_mode():
        for X, _ in loader:
            X = X.to(device)
            logits = model(X)
            probs = torch.softmax(logits, dim=1)
            msp = probs.max(dim=1).values 
            all_msp.append(msp.cpu())

    return torch.cat(all_msp)

El modelo lo que devuelve en su capa final son los conocidos logits (hay métodos que trabajan directamente en este punto). Los logits, sin entrar en definiciones matemáticas que se extienden más allá de lo que quiere abarcar este post, son valores en bruto que produce la última capa de la red. La función de pérdida espera probabilidades, por ello deben ser transformados. Ahora lo que hay que hacer es pasarlo por la función softmax.

Ahora vamos a cargar los ejemplos fuera de distribución, los OOD y los ejemplos dentro de distribución, los in-distribution o ID, (ojo, los ID son ejemplos que nunca ha visto, pero sí están dentro de lo que debería conocer la red). Si el detector funciona bien, debería asignar scores mucho más altos a los datos ID.

id_test = datasets.FashionMNIST(
        root=data_dir,
        train=False,
        download=True,
        transform=ToTensor(),
    )

    ood_test = datasets.CIFAR10(
        root=data_dir,
        train=False,
        download=True,
        transform=transforms.Compose(
            [
                transforms.Grayscale(num_output_channels=1),
                transforms.Resize((28, 28)),
                transforms.ToTensor(),
            ]
        ),
    )

Ahora calculamos el valor AUROC. Para quien no lo sepa, es una muy buena forma de medir el rendimiento del detector. Para entenderlo, primero hay que entender la curva ROC. Si fijamos un umbral y clasificamos como ID todo lo que lo supere, obtenemos una tasa de muestras ID correctamente detectadas y una tasa de muestras OOD coladas por error. Si vamos moviendo ese umbral de $0$ a $1$, cada posición nos da un par de valores distinto, y la curva ROC es el trazado de todos esos pares.

El AUROC es el área bajo esa curva. Es la probabilidad de que, tomando una muestra ID y una OOD al azar, el modelo asigne una puntuación de confianza más alta a la ID. La gracia es que, al agregar todos los umbrales posibles a la vez, no nos comprometemos con ninguno en concreto (podemos medir cómo de bien funciona el detector tanto si queremos mayor sensibilidad como si preferimos un modelo más equilibrado).

Un valor de $1$ indica separación perfecta entre ambas distribuciones, mientras que $0.5$ equivale a un clasificador aleatorio, es decir, el modelo no tiene ninguna capacidad discriminativa real.

msp_id = compute_msp(model, id_loader, device)
msp_ood = compute_msp(model, ood_loader, device)

scores = torch.cat([msp_id, msp_ood]).numpy()
labels = torch.cat([torch.ones_like(msp_id), torch.zeros_like(msp_ood)]).numpy()

auroc = roc_auc_score(labels, scores)

Los resultados obtenidos son los siguientes:

Como puede observarse, la detección con MSP es bastante buena, llegando a un valor de $0.9$. Si quisiéramos, por contexto del negocio, detectar el $90\%$ de los datos OOD, sería tan sencillo como mover el umbral de probabilidad a partir del cual se decide. Con ello, al medir AUROC para ese punto, veríamos que el ratio de falsos positivos ha aumentado. Por ello, dependiendo del contexto, hay que balancear siempre entre TPR y FPR.

Si visualizamos los scores que produce la función para datos OOD y para datos ID obtenemos lo siguiente:

Efectivamente, hay una separación clara, con un poco de solapamiento. La red no es tan confiada con los datos OOD y por ello la distribución de probabilidades que les asigna es prácticamente uniforme. Por el contrario en datos dentro de distribución la máxima probabilidad es muy alta. Esta separación es una huella que aprovechamos para discriminar.

Otros métodos

Lo bueno que tienen métodos como MSP es que son agnósticos a la red. Puedes incluirlos en cualquier red neuronal ya entrenada y funcionará. Obviamente es un método muy simple, y sufre de muchos fallos que hacen que no sea el ideal hoy en día, pero para casos sencillos funciona bien. Para quien se haya quedado con ganas de más, recomiendo echar un ojo a la librería pytorch-ood. Posee una colección de métodos para detección OOD, así como muchas más técnicas y datasets claves para este problema. Merece mucho la pena.

Hace ya unos cuantos años, empecé a interesarme por la inversión. Quería capitalizar mis ahorros. Por ello comencé a investigar cuáles eran las mejores formas de invertir lo que en el momento era mi primer sueldo como ingeniero informático. No tardé mucho hasta encontrar el término de fondo indexado, así como algunas entidades que permitían comprarlos (bancos tradicionales, neobancos, roboadvisors, etc). Incluso le pregunté a un buen amigo mío que estudió economía que qué era lo mejor (saludos Miguelito). Por aquel entonces me recomendó “El pequeño libro de cómo invertir con sentido común”, de John C. Bogle, el creador del primer fondo indexado. Lo compré, lo leí un poco y lo dejé. Demasiados términos que por entonces me costaban entender y quizá poco interés por el tema. Finalmente decidí ir por la vía audiovisual y forera para intentar informarme lo mejor posible. Finalmente me decidí por Indexa Capital, un roboadvisor de renombre y de reputación impecable. Para quienes no lo sepan, un roboadvisor no es más que un gestor automático de inversiones, con nula o casi nula intervención humana, lo que da lugar a costes muy bajos. Lo elegí entre otros por su simpleza, su gestión automática y su reputación, pero he de decir que me quedé por su honestidad, educación en el proceso del usuario y fácil entendimiento de la app. Pero bueno, esto no es un anuncio de Indexa. Lo que quiero expresar es que empecé a invertir en fondos indexados y no leí el libro hasta ahora, y la verdad, es que me alegro. Este proceso más lento, de ir aprendiendo por mi cuenta, ha hecho que me empiece a interesar el área de la inversión y la economía como nunca antes lo había hecho. Gracias a ello he conseguido llegar hoy con un entendimiento básico, pero suficiente, como para entender ciertos conceptos del libro, y lo más importante, con interés real sobre la materia. No me entendáis mal, no es un libro complicado, pero si algo no te interesa, lo digieres peor.

Ideas principales del libro

Para empezar, debería explicar de forma muy resumida algunos conceptos básicos, muy básicos, para poner en contexto a todo el que esté leyendo esto. ¿Qué es un fondo indexado? ¿Qué es un índice? ¿Qué es una acción? ¿Y un dividendo? ¿Y un fondo de gestión activa? Son muchas cosas, pero las intento explicar rápidamente.

En este mundo en el que vivimos, uno puede beneficiarse de las ganancias que generan las empresas. Podemos capitalizar nuestro dinero comprando una porción de la propiedad de estas empresas, por tanto, tendremos derecho a cobrar una parte de los beneficios generados. Capitalizar se refiere a invertir tu capital (normalmente dinero) con el objetivo de que crezca con el tiempo, ya sea mediante la revalorización de los activos o la generación de ingresos como dividendos. Esas pequeñas porciones de empresas son lo que llamamos acciones. Y aquí es donde entran los dividendos: son la parte de los beneficios que una empresa decide repartir entre sus accionistas. Es decir, si eres dueño de acciones de una empresa que obtiene ganancias, es posible que recibas una pequeña cantidad de dinero de forma periódica simplemente por ser propietario de una parte de ella.

¿Cuál es el problema? Comprar acciones individuales de empresas es como buscar una aguja en un pajar. Si quieres beneficiarte de buenas rentabilidades, ya puedes buscar bien entre miles de empresas y seleccionar tu caballo ganador. Aplicando la navaja de Ockham hay una solución más sencilla y menos arriesgada, comprarlo todo. Aquí es donde entra el concepto de fondo de inversión, el cual se refiere a un conjunto de acciones de muchas empresas. Los fondos indexados hacen exactamente esto, comprar acciones de un sector, como puede ser el americano o europeo, y lo compran todo en base al índice de referencia. Este índice es un marcador de un sector y su misión es reflejar la evolución conjunta de ese conjunto de empresas, permitiendo entender cómo se comporta una parte del mercado. Si compramos un fondo que replica el Standard & Poor’s 500 estaremos invirtiendo en las $500$ empresas de mayor capitalización de Estados Unidos. También podemos comprarlas todas, o incluso comprar un fondo que replique a las mayores empresas de todo el mundo. ¿Qué beneficios tiene hacer esto? Lo primero de todo es que elimina el riesgo de elección. Ya no hay que complicarse la vida eligiendo un caballo ganador. Cómpralo todo, y las bajadas de algunas empresas se promediarán con las subidas de otras. Los fondos indexados eliminan el riesgo de las acciones individuales, los sectores de mercado, y la selección del gestor. Solo permanece el riesgo de mercado, que ya es suficiente.

Muchas personas prefieren contratar un fondo de gestión activa por medio de un gestor, con el objetivo de intentar superar al mercado, obteniendo rentabilidades superiores a este. Pero esto puede ser problemático. Explicaré primero dos conceptos clave.

• Rentabilidad de inversión: es la rentabilidad real de un negocio. Se puede estimar de forma sencilla como la suma del crecimiento de sus beneficios y la rentabilidad por dividendo. Es decir, lo que ganas como inversor proviene, por un lado, de que la empresa gane cada vez más dinero y, por otro, de los beneficios que reparte directamente entre los accionistas.

• Rentabilidad de mercado: es la rentabilidad que obtiene el inversor teniendo en cuenta no solo el negocio, sino también cómo lo valora el mercado. Se puede estimar como la suma del crecimiento de los beneficios, la rentabilidad por dividendo y los cambios en la valoración (PER). Es decir, además de lo que gana la empresa y reparte, influye cuánto están dispuestos a pagar los inversores por ella en cada momento.

El PER es el ratio de precio/beneficios, o lo que es lo mismo, lo que están dispuestos a pagar los inversores (número de dólares) por cada dólar de beneficios. El mercado está muy influenciado por las emociones en el muy corto plazo, por ello, al igual que la confianza puede subir y bajar, también lo hacen los ratio PER. Cuando hay más miedo, dominan PER bajos. Cuando la avaricia domina, el PER se incrementa.

Si observamos la gráfica, las rentabilidades obtenidas durante más de cien años en el mercado son prácticamente idénticas. Lo que el gráfico muestra es que mientras los precios que pagamos por las acciones con frecuencia pierden el vínculo con la realidad de los valores, en el largo plazo, la realidad manda. Y esa realidad es que los beneficios para el inversor provienen principalmente de los fundamentales: el crecimiento de los beneficios y los dividendos. Los movimientos de precios derivados del trading o de cambios en la valoración (como el PER) pueden influir en el corto plazo, pero no son la fuente principal de la rentabilidad a largo plazo.

Y aquí es donde entra en juego uno de los conceptos más poderosos en inversión: el interés compuesto. El interés compuesto es el proceso por el cual los rendimientos que generas se reinvierten y, a su vez, generan nuevos rendimientos. Es decir, no solo ganas dinero sobre tu inversión inicial, sino también sobre las ganancias acumuladas con el tiempo. A largo plazo, este efecto se vuelve exponencial y es el verdadero motor del crecimiento del capital. Pero hay un factor clave que puede frenar este proceso, y este factor son los costes. Cada comisión, por pequeña que parezca, reduce la base sobre la que actúa el interés compuesto (y fue una de las razones por las que no invertí en primer lugar en fondos de bancos tradicionales, tienen costes altísimos). Aunque en el corto plazo pueden parecer irrelevantes, en el largo plazo tienen un impacto enorme. No solo pagas ese coste, sino que pierdes todo el crecimiento futuro que ese dinero podría haber generado. Por ello, minimizar los costes es una de las decisiones más importantes que puede tomar un inversor a largo plazo.

Por tanto, y volviendo a la gestión activa. Sabemos que todos esos fondos están compitiendo entre ellos, sabemos que esa gestión incurre en muchos más gastos que una gestión pasiva (gastos del gestor, de los impuestos debidos a la compra/venta de acciones con una mayor rotación de cartera, etc) y sabemos por la gráfica que finalmente, el rendimiento que queda sobre la mesa es el real, el rendimiento de inversión. Por tanto, la inversión activa es un juego de suma cero. Si unos ganan, es porque otros pierden en la misma cantidad bruta. No solo es un juego de suma cero, es que luego los intermediarios quitan parte de la rentabilidad con sus honorarios, por lo que es un juego de suma negativa. Como grupo, los inversores de fondos de este tipo están condenados a perder dinero. La gestión indexada se beneficia de unas rentabilidades reales, no del trading guiado por estrategias con más o menos sentido con el objetivo de comprar bajo y vender alto. Además sus costes son infinitamente menores, lo cual importa mucho cuando invertimos a largo plazo.

El libro habla de mucho más y analiza cada detalle, defendiendo con fervor el fondo indexado, pero las ideas principales y más importantes ya han sido aquí descritas. Un resumen de lo más importante a tener en cuenta:

• Minimizar los costes de los fondos.
• Mantener una estrategia simple y consistente en el tiempo.
• Diversificar al máximo, evitando depender de una sola empresa o sector.
• Entender que la rentabilidad viene del crecimiento real de las empresas y no de intentar predecir el mercado.
• Pensar siempre a largo plazo.

No se trata de ser más listo que el mercado, sino de formar parte de él.

El aprendizaje profundo o deep learning en inglés, es una disciplina que ha traído multitud de avances en todos los aspectos de nuestras vidas. Puede que no lo sepamos y lo demos por hecho, pero TODO hoy en día tiene “IA”. Digo inteligencia artificial, porque es una palabra casi desvirtuada y usada para todo desde que redes neuronales complejísimas como GPT llegaron a nuestras vidas hace unos pocos años. Pero la IA lleva con nosotros desde siempre. Cuando quieres desbloquear el móvil con la cara, se usa IA. Cuando traducimos de un idioma a otro con DeepL o Google Translator, se usa IA. Cuando se extrae texto a partir de una imagen, se usa IA. Cuando detectan lo que estás diciendo a partir de un audio, se usa IA.

La inteligencia artificial es un conjunto muy grande, como expliqué en mi primer post. Todo lo que he mencionado anteriormente, e incluso casos mucho más simples, usan redes neuronales, que pertenecen al área del aprendizaje profundo. El aprendizaje profundo es a su vez un subconjunto del aprendizaje automático, con la diferencia de que está totalmente especializado en redes neuronales profundas, en su arquitectura y su optimización.

El origen del aprendizaje, de la propia inteligencia artificial, tiene su origen en el año $1943$, concretamente en el paper A logical calculus of the ideas immanent in nervous activity. En este paper, se describía por primera vez el concepto de una célula cerebral artificial, un análogo simplificado e inspirado por el comportamiento de las neuronas biológicas. Más tarde, en $1957$, se introduciría el perceptrón (The Perceptron — A Perceiving and Recognizing Automaton).

Un algoritmo con la característica de poder “aprender”.

El perceptrón se inspira en cómo funcionan (de forma simplificada) las neuronas biológicas. Estas reciben varias entradas en forma de señales de otras neuronas por las dendritas. Cada señal tiene un peso y la neurona se encarga de sumar todas ellas y procesarlas internamente. Cuando la señal supera un umbral, la neurona manda un impulso eléctrico llamado potencial de acción. Esto es literalmente una onda eléctrica que viaja por el axón y que envía la señal a otras neuronas.

El perceptrón usa esa inspiración y la utiliza para poder aprender. Concretamente, para poder clasificar. El perceptrón es un clasificador lineal binario por naturaleza. El hecho de que sea lineal implica que es capaz de separar los datos únicamente mediante una frontera de decisión lineal. Traza una línea (en dos dimensiones), un plano (en tres dimensiones) o un hiperplano (en dimensiones superiores) que divide el espacio en dos regiones, asignando cada una a una clase distinta.

Matemáticas del perceptrón

Definamos qué es un perceptrón a nivel matemático, de forma sencilla. El perceptrón trabaja como clasificador binario, por tanto se tienen dos clases.

Se define una función de decisión $\sigma(z)$ que combina linealmente las entradas (señales de las dendritas) con un vector de pesos $w$ (la fuerza de cada señal). Los pesos son parámetros que se irán aprendiendo a medida que el algoritmo avance de iteración en iteración:

Si esa combinación supera un umbral, clasifica como $1$, en caso contrario clasifica como $-1$.

Como ese umbral no lo conocemos, podemos integrarlo a la fórmula como otro parámetro más, otra variable aprendible. De esta forma también simplificamos el código:

Definiendo de esta forma el sesgo o bias:

Ahora, la combinación lineal quedaría como $z=w_1x_1+w_2x_2+…+w_nx_n + b$, que es, escribiéndolo en forma vectorial, $w^Tx + b$.

¿Por qué esas fórmulas?

Quizá la elección de la fórmula que usa el perceptrón parezca arbitraria, pero nada más alejado de la realidad. Se trata de un clasificador binario, como he mencionado anteriormente. Este clasificador va a tratar de discriminar los puntos del espacio (nuestros datos) en dos regiones. Para ello, ¿qué herramienta matemática nos es más adecuada? A continuación dejo la siguiente imagen:

En este sencillo ejemplo hay datos de la clase uno y la clase menos uno. Podrían ser gato y perro, crédito concedido o rechazado, apto o no apto, eso da igual. Lo importante es intentar separarlos de la mejor forma posible y creo no estar muy equivocado ni muy loco si lo intento hacer con una línea recta. Si esto lo extrapolamos al espacio $3D$, es fácil imaginar que la mejor manera (para estos datos que son linealmente separables) es usar un plano. Para todas las dimensiones ocurre lo mismo (asumiendo, y no quiero ser pesado, que son datos linealmente separables). Nuestra frontera de decisión la va a decidir un hiperplano de $N$ dimensiones. La suma ponderada descrita anteriormente coincide con la ecuación del hiperplano en $N$ dimensiones. Para el caso de la recta en el espacio $2D$ es exactamente $w_1x_1+w_2x_2+b=0$, donde el sesgo $b$ es la intersección de la recta con el eje $y$.

La combinación de pesos con entradas es sencilla de entender, igual que la función de clasificación. A la hora de simplificar la fórmula, lo único que hemos hecho es restar el umbral en ambos términos, de forma que $z-\theta$ tiene que ser mayor que cero para clasificar. Así añadimos un parámetro que era desconocido a nuestra fórmula para poder aprenderlo.

En cuanto a la forma vectorial de expresar la combinación de entradas con pesos, recordemos que un vector puede interpretarse como una matriz de una sola fila o de una sola columna. Pongamos que tenemos un vector fila, es decir, tiene dimensiones $1\times N$, donde $N$ es el número de elementos del vector. Si fuese un vector columna, tendría dimensiones $N\times 1$. El nombre columna o fila hace referencia a la forma visual de representarlos: un vector fila se escribe horizontalmente y un vector columna verticalmente.

En el perceptrón solemos considerar $x$ como vector columna de dimensión $N\times 1$ y $w$ también como vector columna de dimensión $N\times 1$. Para poder multiplicarlos y obtener un escalar, transponemos $w$, de forma que $w^T$ pasa a tener dimensión $1\times N$. Así, el producto $w^Tx$ tiene dimensiones $(1\times N)(N\times 1)$ y su resultado es un único valor (un escalar), que coincide con la suma ponderada de las entradas. Finalmente, al añadir el sesgo $b$, obtenemos la expresión completa $z = w^Tx + b$.

Multiplicación paso a paso (producto escalar) con un ejemplo básico

Sea:

Primero transponemos $w$:

La regla de multiplicación es “fila por columna”:

Si añadimos el sesgo, queda:

De hecho, podemos simplificar aún más la expresión si tratamos al sesgo como un peso extra que multiplica a una entrada fija. Añadamos el sesgo como un peso $w_0$. Para ello el vector de entradas debe tener un elemento correspondiente, para que las matemáticas funcionen. Por eso añadimos $1$ como $x_0$. Ahora $w=[w_0,w_1,\dots,w_n]$ y $x=[1,x_1,\dots,x_n]$. Ahora la combinación lineal es más simple aún:

¿Cómo aprende el perceptrón?

Para que el perceptrón aprenda a dividir el espacio en dos, comienza con unos pesos aleatorios y va iterando sobre los datos.
En cada paso busca un punto que esté mal clasificado. Si lo encuentra, ajusta los pesos para corregir ese error.

La regla de actualización es:

donde:

• $x_i$ es el punto mal clasificado,
• $y_i \in {-1, +1}$ es su etiqueta correcta.

Solo se actualiza cuando el punto está mal clasificado, es decir, cuando:

Debemos saber que el vector $w$ es perpendicular a todos los vectores contenidos en el hiperplano de decisión, o lo que es lo mismo, $w$ es el vector normal del hiperplano. Esto es así ya que el hiperplano está definido por la ecuación:

Tomemos dos puntos cualesquiera $x_1$ y $x_2$ que estén sobre el hiperplano. Entonces se cumple:

Si restamos ambas expresiones obtenemos:

El vector $(x_1 - x_2)$ es un vector contenido en el hiperplano (porque conecta dos puntos del propio plano). Y si el producto escalar entre $w$ y ese vector es cero, significa que son perpendiculares. De hecho podríamos incluso sacar el ángulo que forma $w$ con el hiperplano y veríamos que es de $90º$. Geométricamente esto es muy importante ya que cambiar la dirección de $w$ implica rotar el hiperplano. Por tanto, cambiar $w$ significa cambiar la orientación de la frontera que separa las clases.

La actualización:

lo que hace es mover ligeramente el vector $w$ en la dirección necesaria para corregir el error. Veamos los dos casos.

Si el punto es positivo ($y_i = +1$) y está mal clasificado

La actualización se convierte en:

Estamos sumando el vector del punto a los pesos. Eso hace que $w$ se mueva en dirección hacia ese punto. Como el hiperplano es perpendicular a $w$, la frontera gira ligeramente para intentar dejar ese punto en el lado correcto.

Si el punto es negativo ($y_i = -1$) y está mal clasificado

La actualización se convierte en:

Ahora estamos restando el vector del punto. Eso mueve $w$ en dirección opuesta al punto negativo, haciendo que la frontera se ajuste para empujarlo al lado correcto.

El perceptrón esconde las matemáticas base que hacen posible aprender. Obviamente los métodos se han perfeccionado iteración tras iteración, pero la base de modelos como GPT es nada más y nada menos que esa. Vincular conceptos geométricos como la ecuación del plano y de la recta a modelos de inteligencia artificial tan potentes, capaces de simular el lenguaje humano, hacen explotar muchas cabezas y silenciar muchas bocas que decían: ¿pero para qué sirven estas tonterías que aprendemos en mates?

Dejo finalmente una pequeña simulación hecha por Claude para ver cómo se ajusta la frontera de decisión:

El teorema del límite central es una idea clave y muy conveniente en la estadística. Este concepto nos permite extrapolar información a partir de muestras bien seleccionadas sobre la población. Lo que nos dice este teorema es que, si obtenemos distintas muestras para un tamaño muestral suficientemente grande y posteriormente hacemos la media de cada muestra, dichas medias se aproximan a una distribución normal. ¿Qué significa eso? Vayamos por partes. En estadística, una muestra no es más que un subconjunto aleatorio de una población. Una población es un conjunto que contiene todos los individuos, elementos u observaciones posibles. Es decir, imaginemos que queremos obtener la media del sueldo en España para todos los trabajadores en activo.

En este caso, la población recogería a todos los trabajadores de España en activo. Recoger datos de todos ellos resultaría casi imposible y muy costoso en la práctica, por eso es mejor seleccionar aleatoriamente a varios individuos que encajen en este perfil para obtener la información que buscamos. Estos individuos formarían las muestras. Supongamos que tomamos una muestra aleatoria de $50$ trabajadores de toda España. Es posible que, por azar, nuestra muestra incluya más gente de zonas con sueldos altos o bajos, y la media resultante se aleje de la media real. Esa variabilidad es natural. Cada muestra dará un resultado ligeramente distinto. Lo que nos dice el teorema del límite central es cómo se distribuyen esas medias si pudiéramos repetir el muestreo muchas veces. Si nos vamos a la Costa del Sol, seguramente estemos valorando muy positivamente lo que ganan en promedio los españoles. Lo mismo ocurriría en un barrio pobre, donde ahora estaríamos sesgando la métrica hacia abajo.

Es aquí donde el teorema del límite central hace su magia. Si cogemos las muestras y promediamos sus valores, vemos que la distribución estadística que siguen las medias de las muestras es similar a una normal. Cada media muestral es ya un estimador insesgado de la media poblacional. El teorema del límite central nos dice cómo se distribuye ese estimador cuando repetimos el experimento muchas veces. Estaríamos obteniendo información sobre el conjunto completo, pero sin haber tenido que recolectar datos de todos los trabajadores. Pero ojo, es importante que el tamaño muestral (el número de trabajadores a los que preguntamos cada vez) sea suficientemente alto. Depende de lo complicada que sea la distribución de la población, quizá sea necesario un número más alto o más bajo, pero generalmente cuanto más, mejor. De hecho, típicamente se establece el número $30$ como el límite mínimo para que la distribución de las medias empiece a asemejarse a una normal. Pero como he explicado, esto no siempre es así, depende.

Esto nos permite además tener información sobre la incertidumbre, es decir, sobre el error que podríamos estar cometiendo al estimar la media poblacional. Gracias a estar siguiendo una distribución normal, nos podemos someter a sus reglas. Y conocemos muy bien sus reglas.

Ejemplo práctico

Simulemos rápidamente en Python el teorema del límite central. La distribución de la población en este caso es uniforme discreta, es decir, vamos a generar números enteros, concretamente entre el $0$ y el $9$, y cada uno de ellos tiene las mismas probabilidades de salir en cada muestra que obtengamos. El código con NumPy quedaría tal que así:

np.mean(np.random.randint(0, 10, sample_size))

Lo que estamos haciendo es muestrear números enteros de una distribución uniforme. El parámetro sample_size indica cuantas observaciones tiene la muestra.

Ahora vamos a repetir este muestreo tantas veces como queramos. En este caso un total de $10000$ veces. Si cogemos la media de cada muestra y construimos un vector con ellas, podemos crear un histograma para ver que distribución sigue:

import numpy as np
import matplotlib.pyplot as plt
import seaborn as sns

def main():
    n_samples = 10000  
    sample_size = 1

    sample_means = [
        np.mean(np.random.randint(0, 10, sample_size))
        for _ in range(n_samples)
    ]

    sns.histplot(sample_means, bins=50, kde=True)
    plt.title("Central Limit Theorem: Distribution of Sample Means")
    plt.xlabel("Sample Mean")
    plt.ylabel("Frequency")
    plt.savefig(f"scripts/central_limit_theorem/clt_{sample_size}.png")
    plt.close()

if __name__ == "__main__":
    main()

En la siguiente imagen podemos ver, de izquierda a derecha y de arriba a abajo, las distribuciones resultantes. Con solo una observación por muestra, obtenemos la distribución original, en este caso la uniforme. La media de cada muestra es el propio valor, por tanto, cada entero ha salido casi las mismas veces que el resto de enteros. Con un tamaño muestral de dos observaciones ya empieza a tomar una forma acampanada. Si se sigue aumentando el tamaño muestral, la media muestral, que al final es una aproximación a la media poblacional o valor esperado, será cada vez más fiel.

Por supuesto podemos seguir incrementando el tamaño muestral, pero concretamente para la distribución original uniforme no tiene mucho sentido. Es una distribución sencilla, por lo que con unas muestras relativamente pequeñas es suficiente para observar la campana de Gauss.

¿Qué podemos inferir a partir de todo esto?

La verdadera potencia del teorema del límite central no está solo en que “aparezca una campana”, sino en todo lo que nos permite inferir a partir de ella. Una vez sabemos que la media muestral sigue (aproximadamente) una distribución normal, podemos empezar a cuantificar la incertidumbre de nuestras estimaciones.

En primer lugar, podemos hablar del error estándar de la media, que no es más que la desviación típica de la distribución de las medias muestrales. Este valor nos dice cuánto esperamos que varíe la media muestral alrededor de la media poblacional real. Matemáticamente, este error estándar se define como:

donde \(\sigma\) es la desviación típica de la población y \(n\) el tamaño muestral. Aquí aparece una idea clave: a mayor tamaño muestral, menor incertidumbre. No porque la media “sea mejor” por arte de magia, sino porque estamos reduciendo la variabilidad de nuestro estimador.

Gracias a esto, podemos construir intervalos de confianza. Por ejemplo, un intervalo de confianza del $95\%$ nos indica que, si repitiéramos el proceso de muestreo muchas veces, el $95\%$ de los intervalos construidos contendrían la media poblacional verdadera. Intuitivamente, no estamos diciendo que la media sea exactamente un número concreto, sino que estamos bastante seguros de que se encuentra en cierto intervalo alrededor de nuestra estimación.

Por último, todo esto nos recuerda algo importante: no solo importa el valor que estimamos, sino también el error que cometemos al estimarlo. El teorema del límite central nos da un marco matemático sólido para medir esa incertidumbre y tomar decisiones informadas, incluso cuando no conocemos la distribución real de la población.

Este truquito estadístico se usa en multitud de ámbitos y métodos, algunos de ellos muy relacionados con el machine learning, como la fórmula del error cuadrático medio o MSE. En un futuro post hablaré de ello y cómo su fórmula se puede explicar y entender mejor gracias a este concepto estadístico.

Como programador siempre he tenido en cuenta la eficiencia a la hora de crear sistemas. Los numeritos bajando, indicando poco tiempo de ejecución, nos producen cosquillas en el cerebro. Una forma de conseguir código más veloz es mediante la técnica de vectorización.

¿Qué es la vectorización entonces? Es un método por el cual aplicamos operaciones sobre un conjunto de elementos de forma simultánea, en vez de aplicarlas de una en una. Sencillo de entender y muy fácil de aplicar en Python con la librería de cálculo numérico NumPy.

Sin embargo, no todos los problemas son vectorizables. Para que una operación pueda vectorizarse, los cálculos sobre cada elemento deben ser independientes entre sí, es decir, el resultado de un elemento no puede depender del resultado de otro. Esto es así porque las operaciones se ejecutan en paralelo. Si existiera dependencia entre los resultados, sería necesario coordinar la ejecución, introduciendo un overhead que reduciría, o incluso anularía, las ventajas en rendimiento.

También es necesario estructurar los datos en arrays o matrices, es decir, estructuras homogéneas. Las GPUs y CPUs están optimizadas para operar bajo estas estructuras. NumPy está programado para aprovechar estas optimizaciones.

Vectorización de un GA

Como ya vimos en mi anterior post cómo funcionan los algoritmos genéticos, podemos aprovechar el código secuencial en Python puro para introducir unas cuantas mejoras. Todos los operadores de ese código son perfectamente vectorizables. Al realizar el cambio, veremos una mejora muy sustancial, ya que los bucles en Python son inherentemente lentos.

Empecemos por el operador de mutación:

def mutate(self, x: np.ndarray) -> np.ndarray:
        for i in range(x.size):
            if np.random.rand() < self.mutation_rate:
                x[i] = 1 - x[i]
        return x

def mutate_vectorized(self, population: np.ndarray) -> np.ndarray:
        mask = (
            np.random.rand(population.shape[0], population.shape[1])
            < self.mutation_rate
        )
        population[mask] = 1 - population[mask]
        return population

En el primer código usé un for-loop en Python (extremadamente lento si el conjunto a iterar crece mucho) para ir mutando cada gen uno a uno. Además, se realiza la operación de generación de un número aleatorio individualmente.

En el segundo código creamos una máscara del tamaño de la población total. Véase que aquí operamos no sobre un individuo $x\in X$, sino sobre toda la población $X$. Si el número generado es menor a la probabilidad de mutación, entonces se aplica mutación. Después se aplica, de forma simultánea, la máscara sobre la operación para hacer el cambio de bit.

La diferencia es abismal. Asumamos unos $800$ genes por cromosoma con $50$ cromosomas y $200$ generaciones. En el primer código estaríamos iterando unas $800$ veces por cada individuo (unas $50\times 800=40.000$ iteraciones de un bucle for). Eso multiplicado por $200$ generaciones da unas $8.000.000$ iteraciones totales. En el segundo código se muta a la población de una generación de una sola vez. Pasamos de $8$ millones de iteraciones a unas $200$ operaciones vectoriales masivas.

def crossover(
        self, x1: np.ndarray, x2: np.ndarray
    ) -> Tuple[np.ndarray, np.ndarray]:
        if np.random.rand() > self.crossover_rate:
            return x1.copy(), x2.copy()
        point = np.random.randint(1, x1.size)
        c1 = np.concatenate([x1[:point], x2[point:]])
        c2 = np.concatenate([x2[:point], x1[point:]])
        return c1, c2

def crossover_vectorized(
        self, population: np.ndarray, indices: np.ndarray
    ) -> np.ndarray:
        n_pairs = len(indices) // 2
        parents1 = population[indices[::2]]
        parents2 = population[indices[1::2]]

        offspring = np.empty((n_pairs * 2, self.num_genes), dtype=population.dtype)

        crossover_mask = np.random.rand(n_pairs) <= self.crossover_rate

        crossover_points = np.random.randint(1, self.num_genes, size=n_pairs)

        gene_indices = np.arange(self.num_genes)

        masks = gene_indices[None, :] < crossover_points[:, None]

        offspring[::2] = np.where(masks, parents1, parents2)
        offspring[1::2] = np.where(masks, parents2, parents1)

        no_crossover_mask = ~crossover_mask
        offspring[::2][no_crossover_mask] = parents1[no_crossover_mask]
        offspring[1::2][no_crossover_mask] = parents2[no_crossover_mask]

        return offspring[: self.population_size]

El operador de cruce original trabaja a nivel de un solo par de individuos. Para cada pareja de padres, primero decide si se aplica o no el cruce en función de una probabilidad. En caso afirmativo, selecciona un punto de cruce y construye dos descendientes concatenando segmentos de los cromosomas parentales. Este proceso es conceptualmente simple y fácil de entender, pero requiere un bucle externo que itere sobre todos los pares de la población, lo que introduce un coste significativo cuando el tamaño poblacional o el número de genes es elevado.

La operación propiamente vectorizada aquí es el cruce de genes de todos los pares a la vez, sin bucles explícitos en Python. La operación np.where aplica la selección elemento a elemento sobre toda la matriz en una sola llamada.

Finalmente, los pares que no debían cruzarse se gestionan sobrescribiendo los descendientes generados con copias directas de los padres originales. Esta etapa mantiene la semántica del operador de cruce clásico, pero sigue utilizando indexación booleana vectorizada. El resultado es un algoritmo que conserva exactamente el mismo comportamiento genético que la versión iterativa, pero con una implementación más adecuada para grandes poblaciones.

La función principal optimize se simplifica bastante. Quedaría así:

def optimize(self) -> np.ndarray:
        population = self.initialize_population()
        scores = self.fitness_func(population)

        idx = np.argsort(scores)[::-1]
        population = population[idx]
        scores = scores[idx]

        prev_best = scores[0]
        elite_size = int(self.elitism_rate * self.population_size)

        for it in range(self.max_iter):
            if np.sum(scores) == 0 or np.count_nonzero(scores) < 2:
                parent_indices = np.random.choice(
                    len(scores), self.population_size, replace=True
                )
            else:
                probs = scores / np.sum(scores)
                parent_indices = np.random.choice(
                    len(scores), self.population_size, replace=True, p=probs
                )

            offspring = self.crossover_vectorized(population, parent_indices)
            offspring = self.mutate_vectorized(offspring)

            elites = population[:elite_size]
            offspring = offspring[: self.population_size - elite_size]

            population = np.vstack([elites, offspring])
            scores = self.fitness_func(population)

            idx = np.argsort(scores)[::-1]
            population = population[idx]
            scores = scores[idx]

            best = scores[0]
            self.best_fitness_history.append(best)

            improvement = best - prev_best
            if 0 < improvement < self.epsilon:
                break

            prev_best = best

        return population[0]

Comprobación de la mejora

Ahora, ya tendríamos un GA mucho más optimizado. Los operadores principales se han reescrito de forma que aprovechen las ventajas de la vectorización. Ahora son capaces de aplicar operaciones masivas sobre toda la población, en vez de utilizar bucles de Python, los cuales son extremadamente lentos.

Para probar la eficacia de la vectorización, he programado un ejemplo en el que se lanzarán $5$ experimentos. Cada experimento tiene un tamaño de problema mayor que el anterior, en este caso el problema de la mochila, el cual ya expliqué en el post sobre genéticos. En cada experimento se hacen $5$ runs para minimizar el efecto de la aleatoriedad.

Antes de todo, definamos el speed-up:

Es decir, es una métrica que mide cuántas veces es una versión más rápida que la otra. Un speed-up de $\times 2$ significa que la versión vectorizada tarda la mitad de tiempo.

En el gráfico se muestra el tiempo de ejecución en términos absolutos, siendo el vectorizado mucho mejor. El valor del fitness de las mejores soluciones son prácticamente iguales. Irrelevante, pero quería mostrarlo, ya que debe quedar claro que la función y capacidad del GA queda inalterada. El speed-up crece según aumenta el tamaño del problema, es decir, es más eficiente que el secuencial según crece el problema, pero esto solo ocurre en el número limitado de ejecuciones que hemos hecho. Analicemos como escalan ambos algoritmos.

Ambas versiones muestran una tendencia de crecimiento similar en escala logarítmica, lo que indica que comparten el mismo orden de complejidad. Sin embargo, el algoritmo vectorizado presenta una constante multiplicativa mucho menor, lo que se traduce en una mejora sustancial del tiempo de ejecución para cualquier tamaño de problema.

¿El resumen de todo esto? El speed-up probablemente tope con un límite según crece el problema, pero aún así será unas $\approx\times 2$ veces mejor que el secuencial. Si aumentásemos el tamaño del problema más veces, veríamos como la tendencia alcista de la eficiencia se suaviza.

El cambio de mentalidad

La moraleja es sencilla: la vectorización es una herramienta sencilla de aplicar y muy beneficiosa.

Menos bucles en Python, más operaciones en bloque, y un GA que escala mucho mejor sin cambiar su comportamiento genético. La idea clave es cambiar el chip: dejar de pensar en individuos sueltos y empezar a pensar en poblaciones completas. Al menos en mi experiencia, una vez haces ese click mental, empiezas a ver oportunidades de vectorización por todas partes.

La optimización es un campo de estudio amplio y muy interesante. Mis primeras interacciones con este campo empezaron jugueteando con regresiones lineales y usando el clásico descenso del gradiente, programado manualmente. No solo resulta satisfactorio desde el punto de vista teórico, sino que también es extremadamente útil en la práctica. Cuando hablamos de optimización, la idea principal que suele venirnos a la cabeza es la de realizar una tarea de la mejor manera posible, utilizando la menor cantidad de recursos.

En nuestro día a día, que suele ser bastante ajetreado, todos intentamos optimizar distintos procesos cotidianos: limpiar, cocinar, desplazarnos, estudiar o trabajar, entre otros. De forma consciente o no, tomamos decisiones orientadas a ahorrar tiempo, esfuerzo o dinero, lo que constituye un ejemplo claro de optimización aplicada a la vida diaria.

En el ámbito del comercio, la optimización es un elemento casi inherente al propio sistema capitalista (al menos en su formulación teórica más ideal). Las empresas compiten entre sí tratando de ofrecer mejores bienes y servicios, y esta competencia actúa como motor para la mejora continua de los procesos. Por ejemplo, si una empresa de reparto de paquetes consigue realizar sus envíos de forma más rápida y utilizando menos combustible que otra, podrá ofrecer precios más competitivos. Al reducir el consumo de recursos, esta empresa más eficiente puede mantener (o incluso aumentar) su margen de beneficio frente a otra cuyo proceso logístico sea menos eficiente.

Este tipo de situaciones ilustran claramente problemas de optimización. En el caso del transporte, existen múltiples rutas posibles entre distintos destinos, pero no todas son igualmente buenas. El objetivo es encontrar el recorrido óptimo en función de ciertas variables, como el tráfico en un momento determinado, la existencia de obras, la distancia entre puntos de entrega o el consumo de combustible. La optimización permite modelar este problema y determinar, entre todas las alternativas posibles, aquella que minimiza el coste total o maximiza la eficiencia del proceso.

Dentro de este campo de estudio, existen multitud de herramientas matemáticas y de métodos para optimizar un problema. Como breve resumen, enumeraré algunos de los enfoques más usados:

• Algoritmos basados en gradiente: utilizan información de derivadas de la función objetivo para guiar la búsqueda hacia óptimos locales o globales. Son muy eficientes cuando la función es continua y diferenciable (por ejemplo, descenso por gradiente o métodos de Newton).
• Metaheurísticas: métodos de búsqueda aproximada inspirados en procesos naturales o estrategias probabilísticas. No garantizan el óptimo global, pero son muy útiles en problemas complejos, no lineales o discontinuos. En este blog hablaré sobre los algoritmos genéticos, el ejemplo más básico de metaheurística.
• Métodos exactos: técnicas matemáticas que garantizan encontrar la solución óptima, como la programación lineal, entera o convexa. Suelen ser computacionalmente costosos y aplicables solo a problemas con una estructura bien definida.
• Métodos heurísticos: estrategias diseñadas específicamente para un tipo de problema concreto, que priorizan la rapidez frente a la optimalidad. Son comunes en problemas de gran escala o en tiempo real.

Para poder definir un problema general como un problema de optimización, es necesario establecer ciertos elementos fundamentales que lo definan de manera clara y precisa. Matemáticamente, y de forma simplificada, un problema de optimización tiene esta forma:

De forma resumida, tenemos una función que queremos minimizar o maximizar, junto con una serie de restricciones que hay que cumplir. En el ejemplo del transportista, lo que queremos es gastar el menor combustible posible, pero con la condición de que no podemos pasar por las calles $x$ e $y$ debido a las obras, y de que hay que visitar todas las casas del recorrido.

A continuación explicaré brevemente algunos conceptos que son indispensables para entender el diseño de los métodos de optimización.

Conceptos clave

Función fitness

Esta función establece una forma de evaluar soluciones para nuestro problema. Es una forma de cuantificar el rendimiento. También puede ser vista como una forma de cuantificar un error. En ese caso, deberíamos minimizarla.

Óptimos globales y locales

Imaginemos una función como una superficie en $3D$, quizá semejante a una cadena montañosa, con picos y llena de valles y depresiones. Así es más sencillo entender estos conceptos. Encontrar el óptimo global correspondería a encontrar el punto más bajo de toda la superficie, el valle más profundo de la región. En la búsqueda por descender lo máximo posible, es posible quedarse atrapado en depresiones menos profundas que, en relación con su entorno inmediato, son las más bajas. Estos son los óptimos locales.

Un senderista que se mueve por este terreno no tiene una visión completa del paisaje. Solo percibe la pendiente inmediata que le rodea. Su estrategia es simple: avanzar siempre cuesta abajo.

Siguiendo esta regla, el senderista acabará llegando a un punto donde todas las direcciones cercanas ascienden. Desde su punto de vista, ha alcanzado el fondo del valle: cualquier paso que dé lo hará subir. Sin embargo, ese punto puede no ser el lugar más bajo de toda la región, sino solo el más bajo en su entorno inmediato. Ese punto corresponde a un óptimo local.

Algunos métodos topan con la misma problemática del senderista. Se quedan atascados en valores subóptimos.

Dentro de todos los métodos de optimización existentes, hay unos que son bastante divertidos e interesantes. Son fáciles de programar, intuitivos y generalmente funcionan muy bien. Estas son las llamadas metaheurísticas, métodos cuya principal característica es la aleatoriedad como motor principal de exploración. Y concretamente dentro de estos algoritmos, voy a hablar de los algoritmos genéticos.

Algoritmos genéticos

La premisa es básica. Esta familia de algoritmos se inspira en las ideas de Darwin sobre la evolución, más concretamente, en los mecanismos de selección natural y supervivencia del más apto, donde los individuos mejor adaptados al entorno tienen mayor probabilidad de reproducirse y transmitir sus características a la siguiente generación.

Estos sistemas (y todas las metaheurísticas) tienen dos fases generales de vital importancia y muy sensibles. La exploración y la explotación.

Exploración y explotación

Como he mencionado antes, la aleatoriedad es una parte clave de estas técnicas. Esta característica permite explorar zonas del espacio que quizá no habrían sido visitadas en primera instancia por parecer menos prometedoras. Gracias a ello, se permite una exploración más amplia y se facilita escapar de óptimos locales. Esta primera fase de búsqueda es la conocida como exploración.

La explotación viene justo después. Esta es la habilidad de refinar y ajustar lo máximo posible una zona de soluciones, encontrando la mejor solución posible dentro de esta.

El balance entre ambas fases es muy sensible y es necesario ajustarlo con finura. Si la exploración dominase, el algoritmo tardaría mucho tiempo en conseguir una solución, o incluso no convergería a ninguna. En cambio, si la explotación fuese más fuerte que la exploración, la convergencia sería muy prematura y posiblemente se encontraría una solución subóptima, cuando podría haber muchas mejores opciones sin descubrir.

Los algoritmos genéticos son capaces de explorar y explotar gracias a su variada selección de operadores. Aunque, antes de profundizar en detalles sobre estos, hay que entender el algoritmo de forma general.

Las GAs trabajan con una población de soluciones codificadas normalmente en forma binaria. Cada solución, llamada cromosoma, está compuesta por genes (bits), y el conjunto de cromosomas constituye la población. Esta población se inicializa de manera aleatoria para favorecer la exploración del espacio de soluciones y, posteriormente, cada cromosoma es evaluado según su calidad, lo que hace posible ordenar las soluciones de mejor a peor. A partir de esta evaluación comienza el proceso evolutivo, que se desarrolla en generaciones. En cada generación se seleccionan los cromosomas más aptos para reproducirse, sin eliminar completamente la diversidad.

Los operadores genéticos principales son el cruce, que combina información de dos progenitores para generar nuevas soluciones, y la mutación, que introduce cambios aleatorios para evitar la convergencia prematura. El operador de selección es también importante, pues es el encargado de indicar qué cromosomas deben cruzarse entre sí. También es posible añadir una mecánica de elitismo, para mejorar la convergencia. Con apoyo del elitismo, que preserva las mejores soluciones, este ciclo se repite hasta cumplir un criterio de parada, tomando finalmente el mejor cromosoma como solución aproximada al problema. A continuación proporciono un diagrama general del ciclo evolutivo:

graph TD
    A[Inicio] --> B[Inicializar población aleatoria]
    B --> C[Evaluar fitness de toda la población]
    C --> D[Ordenar por fitness]
    D --> E{¿Iteración < max_iter?}
    E -->|No| P[Retornar mejor solución]
    E -->|Sí| F[Seleccionar élites]
    F --> G{¿Población completa?}
    G -->|No| H[Selección por ruleta]
    H --> I[Crossover de padres]
    I --> J[Mutación de hijos]
    J --> K[Agregar hijos a nueva población]
    K --> G
    G -->|Sí| L[Evaluar fitness de nueva población]
    L --> M[Ordenar por fitness]
    M --> N[Guardar mejor fitness en historial]
    N --> O{¿Mejora < epsilon?}
    O -->|Sí| P
    O -->|No| E
    P --> Q[Fin]

De la teoría a la práctica

Dentro del diseño principal de los genéticos, hay una variedad muy grande de operadores. A lo largo de los años han ido surgiendo distintos diseños y evoluciones de los operadores básicos. Aquí implementaré los más sencillos.

La siguiente clase contiene los parámetros de inicialización del algoritmo. El parámetro fitness_func hace referencia a la función fitness. Esta es la función objetivo que vamos a maximizar. Veremos que de esta también depende la calidad de nuestra solución, pues hay múltiples formas de abordar la evaluación de un cromosoma. El resto de parámetros son evidentes: el tamaño de la población, número de genes de cada solución, probabilidad de mutación por gen, iteraciones máximas, mejora mínima por generación (cuando deja de mejorar un mínimo el algoritmo para), probabilidad de cruce, porcentaje de elitismo en función del tamaño de la población y una semilla (por reproducibilidad en experimentación).

La población se genera siguiendo una distribución discreta uniforme, pero esto es cuestión de diseño, podría utilizarse otra distribución.

class GA:
    def __init__(
        self,
        fitness_func: Callable,
        population_size: int,
        num_genes: int,
        mutation_rate: float,
        max_iter: int,
        epsilon: float,
        crossover_rate: float = 0.8,
        elitism_rate: float = 0.1,
        seed: Optional[int] = None,
    ):
        self.fitness_func = fitness_func
        self.population_size = population_size
        self.num_genes = num_genes
        self.mutation_rate = mutation_rate
        self.max_iter = max_iter
        self.epsilon = epsilon
        self.crossover_rate = crossover_rate
        self.elitism_rate = elitism_rate
        self.best_fitness_history = []
        if seed is not None:
            np.random.seed(seed)
            random.seed(seed)

    def initialize_population(self) -> np.ndarray:
        self.population = np.random.randint(
            low=0, high=2, size=(self.population_size, self.num_genes)
        )
        return self.population

El operador de cruce es sencillo. Este concretamente recibe el nombre de one-point crossover ya que se selecciona un punto al azar entre las dos soluciones padre.

Dado ese punto de corte, se mezcla la parte izquierda de un padre con la parte derecha de otro y viceversa, generando en el proceso dos soluciones hijo.

def crossover(
        self, x1: np.ndarray, x2: np.ndarray
    ) -> Tuple[np.ndarray, np.ndarray]:
        if np.random.rand() > self.crossover_rate:
            return x1.copy(), x2.copy()
        point = np.random.randint(1, x1.size)
        c1 = np.concatenate([x1[:point], x2[point:]])
        c2 = np.concatenate([x2[:point], x1[point:]])
        return c1, c2

El operador de mutación, en el caso de la mutación binaria, no tiene mucho misterio. Se recorre cada gen de un cromosoma, generando un número aleatorio por cada iteración. Con una probabilidad baja se realizará esa mutación, que consiste en un cambio del bit. Si era $0$ cambia a $1$ y viceversa. Esta probabilidad suele ser baja para evitar que el proceso se vuelva excesivamente aleatorio y se pierda la información genética acumulada por selección y cruce.

Este operador introduce aleatoriedad en el algoritmo, de forma que se favorece a la exploración del espacio de soluciones.

def mutate(self, x: np.ndarray) -> np.ndarray:
        for i in range(x.size):
            if np.random.rand() < self.mutation_rate:
                x[i] = 1 - x[i]
        return x

El operador de selección es uno de los componentes fundamentales de los algoritmos genéticos y se encarga de decidir qué individuos de la población pasan a reproducirse y, por tanto, a transmitir su información genética a la siguiente generación. Su funcionamiento se basa en el principio de la supervivencia del más apto, es decir, los que mejor evaluación tienen dada la función fitness. En este caso he implementado una ruleta, que es sencilla de programar y de entender. La probabilidad de selección de cada individuo es proporcional a su aptitud.

def roulette_wheel(self, scores: np.ndarray) -> np.ndarray:
        if np.sum(scores) == 0 or np.count_nonzero(scores) < 2:
            return np.random.choice(len(scores), 2, replace=False)
        probs = scores / np.sum(scores)
        return np.random.choice(len(scores), 2, replace=False, p=probs)

Finalmente, una vez se han explicado los operadores, queda la evolución generacional. Como he mencionado, se modifica la población completa generación tras generación siguiendo el siguiente bucle: Selección de padres, cruce de padres, mutación y reemplazo de la población. El elitismo es opcional, pero he optado por añadirlo ya que en mi experiencia no promueve una convergencia muy temprana si el número es bajo y mejora mucho la calidad de las soluciones.

def optimize(self) -> np.ndarray:
        population = self.initialize_population()
        scores = self.fitness_func(population)

        idx = np.argsort(scores)[::-1]
        population = population[idx]
        scores = scores[idx]

        prev_best = scores[0]
        elite_size = int(self.elitism_rate * self.population_size)

        for it in range(self.max_iter):
            new_population = []

            elites = population[:elite_size]
            new_population.extend(elites)

            while len(new_population) < self.population_size:
                i1, i2 = self.roulette_wheel(scores)
                p1, p2 = population[i1], population[i2]
                c1, c2 = self.crossover(p1, p2)
                c1 = self.mutate(c1)
                c2 = self.mutate(c2)
                new_population.append(c1)
                if len(new_population) < self.population_size:
                    new_population.append(c2)

            population = np.array(new_population)
            scores = self.fitness_func(population)

            idx = np.argsort(scores)[::-1]
            population = population[idx]
            scores = scores[idx]

            best = scores[0]
            self.best_fitness_history.append(best)

            improvement = best - prev_best
            if 0 < improvement < self.epsilon:
                print(
                    f"Early stopping at iteration {it + 1}: improvement ({improvement:.6f}) < epsilon ({self.epsilon})"
                )
                break

            prev_best = best

        return population[0]

El problema de la mochila

Como problema de ejemplo para optimizar y visualizar el comportamiento de este algoritmo he escogido el problema de la mochila o Knapsack Problem, un clásico.

Este consiste en seleccionar, de entre un conjunto de objetos con un peso y un valor asociados, aquellos que deben introducirse en una mochila con capacidad limitada para maximizar el valor total sin exceder dicha capacidad.

Para poder trabajar en este problema con algoritmos genéticos, la codificación de las soluciones deberá tomar la forma de un vector binario, donde cada gen representa un objeto candidato a ser introducido en la mochila: el valor $1$ indica que el objeto es seleccionado y el valor $0$ que no lo es.

En esta formulación, $\mathbf{x}$ es una solución candidata formada por $n$ objetos, $x_i$ indica la selección del objeto $i$, $w_i$ y $v_i$ representan respectivamente el peso y el valor del objeto $i$, $W(\mathbf{x})$ es el peso total de la solución, $W_{\max}$ la capacidad máxima de la mochila, y $V(\mathbf{x})$ el valor total de la solución, que se utiliza como función fitness.

Funciones de evaluación (fitness)

Vamos a probar a solucionar este problema con el algoritmo genético básico que he presentado previamente. Para ello, antes de todo, debemos escoger una función fitness. Aquí entran dos tipos de evaluaciones que podemos hacer sobre una solución. Si la solución se excede en carga, podemos penalizarla de forma drástica, añadiendo un score de $0$, por ejemplo, y dejando el valor total como score para aquellos cromosomas que no violen la restricción. Esto funciona, pero tiene problemas. Imaginemos que tenemos dos soluciones de igual valor. Una se excede por $4kg$ y otra se excede por $0.3kg$. La función de evaluación daría la misma puntuación a ambas soluciones, cuando claramente hay una peor que otra.

def fitness_knapsack_hard(
    population: np.ndarray,
    weights: np.ndarray,
    values: np.ndarray,
    max_capacity: int,
) -> np.ndarray:
    total_weights = np.sum(population * weights, axis=1)
    total_values = np.sum(population * values, axis=1)
    total_values[total_weights > max_capacity] = 0.0

    return total_values

Esto lo que le está diciendo al algoritmo es que debe darle la misma importancia a una que a otra. Podríamos estar sesgando la capacidad de exploración entre las ramificaciones de posibles soluciones hijas generadas a partir de la solución menos mala. También podría ocurrir que el algoritmo contenga una población de malas soluciones a las cuales no podría seguir evolucionando para intentar mejorar. Es una visión pesimista. La penalización binaria elimina la información sobre cómo de lejos está una solución de ser factible, reduciendo la capacidad del algoritmo para realizar mejoras graduales.

Una opción alternativa sería penalizar suavemente, teniendo en cuenta la magnitud de la violación. La función fitness_knapsack_soft evalúa cada individuo en base a su valor total. Si esa solución se excede en peso total del máximo permitido, se introduce una penalización gradual que crece de manera exponencial. El factor $\alpha$ controla si se aplica más o menos penalización.

def fitness_knapsack_soft(
    population: np.ndarray,
    weights: np.ndarray,
    values: np.ndarray,
    max_capacity: float,
    alpha: float = 0.2,
) -> np.ndarray:
    total_weights = np.sum(population * weights, axis=1)
    total_values = np.sum(population * values, axis=1)

    excess = np.maximum(0.0, total_weights - max_capacity)
    penalty = np.exp(-alpha * excess)

    return total_values * penalty

Resolución

Vamos a comparar el GA con varios tamaños de problema y distintas restricciones con la función de evaluación suave y la dura. Además vamos a compararlo con un algoritmo Greedy para analizar las diferencias en calidad de solución, tiempo de cómputo y cumplimiento de restricciones. El algoritmo Greedy es muy simple. Utiliza una heurística básica de ordenación y va escogiendo el mejor camino posible en cada paso hasta completar la solución final. Es muy rápido y, dependiendo de la heurística elegida, muy competente.

class Greedy:
    def __init__(
        self,
        weights: np.ndarray,
        values: np.ndarray,
        max_capacity: float,
        heuristic: str,
        fitness_func: Callable,
    ):
        self.weights = weights
        self.values = values
        self.max_capacity = max_capacity
        self.fitness_func = fitness_func
        self.heuristic = heuristic
        self.best_fitness_history = []

    def optimize(self) -> np.ndarray:
        n = len(self.weights)
        solution = np.zeros(n, dtype=int)

        if self.heuristic == "h1":
            ratios = self.values  
            order = np.argsort(-ratios)
        elif self.heuristic == "h2":
            ratios = self.weights  
            order = np.argsort(ratios)  
        else:
            ratios = self.values / self.weights 
            order = np.argsort(-ratios)

        remaining_capacity = self.max_capacity
        best_fitness = float("-inf")

        for i in order:
            if self.weights[i] <= remaining_capacity:
                solution[i] = 1
                remaining_capacity -= self.weights[i]

                current_fitness = self.fitness_func(solution.reshape(1, -1))[0]
                if current_fitness > best_fitness:
                    best_fitness = current_fitness
                    self.best_fitness_history.append(best_fitness)

        if not self.best_fitness_history:
            self.best_fitness_history.append(
                self.fitness_func(solution.reshape(1, -1))[0]
            )

        return solution

Para Greedy he definido tres heurísticas básicas. Ordenación de mejores objetos en función del valor, del peso y del valor relativo al peso.

Para tamaños pequeños como $50$, algoritmo Greedy con la primera heurística y una restricción generosa del $40\%$ sobre el total de número de objetos, obtenemos resultados muy decentes:

=== SOFT CONSTRAINTS ===
Best fitness score: 25.419778639697903
Total weight: 19.959887918754212
Total value: 25.419778639697903
Max capacity: 20

=== HARD CONSTRAINTS ===
Best fitness score: 25.419778639697903
Total weight: 19.959887918754212
Total value: 25.419778639697903
Max capacity: 20

=== GREEDY ===
Best fitness score: 25.367928277332897
Total weight: 19.93102578451347
Total value: 25.367928277332897
Max capacity: 20

Todos los algoritmos muestran buenas soluciones, siendo los GAs ligeramente superiores. Aun así, los tres obtienen soluciones muy buenas. Las dos funciones de fitness funcionan igual de bien. También se observa que Greedy es mucho más rápido, ya que ha tardado en converger menos de $50$ iteraciones, mientras que los genéticos han necesitado más de $100$ para igualar el score. Aunque es algo obvio, el Greedy no realiza exploración, solo explota una heurística de forma voraz.

Si probamos a cambiar la restricción y hacerla más complicada (esta vez no se podrá superar el $5\%$ del total en peso) veremos algunos cambios en los resultados:

=== SOFT CONSTRAINTS ===
Best fitness score: 6.690651548303056
Total weight: 3.7789294493745977
Total value: 9.54957977253405
Max capacity: 2

=== HARD CONSTRAINTS ===
Best fitness score: 0.0
Total weight: 12.428228685377153
Total value: 13.08190249886287
Max capacity: 2

=== GREEDY ===
Best fitness score: 3.720164332689731
Total weight: 1.9952584283072372
Total value: 3.720164332689731
Max capacity: 2

Estos resultados ya son más interesantes. El algoritmo genético es igual en las dos comparaciones, pero la forma de evaluar es totalmente distinta. Con penalizaciones suaves o relativas, el algoritmo ha sido capaz de evaluar correctamente soluciones que eran a priori malas y las ha explorado y explotado inteligentemente obteniendo una solución final. En cambio las evaluaciones duras han destrozado la convergencia del genético y ha devuelto una solución sin refinar. De todas formas, el otro método no ha sido capaz de cumplir las restricciones impuestas, pasándose por $1.7$. Depende del contexto del problema, y esto es algo a evaluar dependiendo de las necesidades, esto podrá ser factible o inadmisible. La solución del Greedy, pese a no ser muy buena, cumple a rajatabla con el peso máximo permitido.

Probemos ahora con un tamaño más desafiante, un total de $200$ objetos y solo un $10\%$ de capacidad sobre el total permitido en la mochila:

=== SOFT CONSTRAINTS ===
Best fitness score: 49.986377238685016
Total weight: 19.824506933869955
Total value: 49.986377238685016
Max capacity: 20

=== HARD CONSTRAINTS ===
Best fitness score: 0.0
Total weight: 56.058575444418665
Total value: 48.303356578426225
Max capacity: 20

=== GREEDY ===
Best fitness score: 40.175288587973824
Total weight: 19.997759251464615
Total value: 40.175288587973824
Max capacity: 20

La penalización dura sigue sin converger, mientras que el GA con fitness suave da los mejores resultados, con una convergencia suave y sin llegar a violar las restricciones impuestas. Los genéticos parecen una muy buena opción hasta ahora, pero probemos a cambiar una variable. Esta vez vamos a probar otra heurística en el algoritmo Greedy. La heurística número $3$, que ordena los objetos por el valor en relación al peso:

=== SOFT CONSTRAINTS ===
Best fitness score: 43.462952020478
Total weight: 19.97950402605357
Total value: 43.462952020478
Max capacity: 20

=== HARD CONSTRAINTS ===
Best fitness score: 0.0
Total weight: 51.83288833879617
Total value: 46.00902743825782
Max capacity: 20

=== GREEDY ===
Best fitness score: 46.28502186266642
Total weight: 19.94989976262729
Total value: 46.28502186266642
Max capacity: 20

El Greedy con la tercera heurística es no solo el más rápido, sino que es mejor, además de tener la garantía de no violar la restricción. Estos resultados ponen de manifiesto una idea clásica en optimización: una heurística sencilla, bien alineada con la estructura del problema, puede superar con facilidad a métodos mucho más complejos. En este caso, una ordenación simple basada en la eficiencia valor–peso permite al algoritmo Greedy encontrar soluciones de alta calidad de forma extremadamente rápida y sin violar las restricciones, incluso en escenarios más exigentes.

No obstante, esta ventaja depende fuertemente de la calidad de la heurística elegida. Cuando dicha heurística no captura adecuadamente la dinámica del problema, el rendimiento del enfoque voraz se degrada rápidamente. En contraste, los algoritmos genéticos muestran un comportamiento mucho más estable a lo largo de todos los escenarios analizados (sin ser esto un estudio riguroso ni de lejos). Con un diseño adecuado de la función de fitness, los GAs son capaces de explorar y explotar el espacio de soluciones de forma robusta, adaptándose a distintas restricciones y tamaños del problema sin colapsar.

Otras codificaciones

Finalmente, quería explicar que los algoritmos genéticos son en origen binarios, pero también aceptan otras codificaciones, como la continua, es decir, valores reales. Esto requiere de una adaptación sobre los operadores ya explicados para poder manejar este tipo de representación, pero la naturaleza del algoritmo es la misma. Este tipo de codificación abre la puerta a resolver problemas de optimización continua. He preparado una versión continua del GA, con ayuda de ChatGPT para crear unas animaciones, de forma que quede claro visualmente cómo converge la población hacia el máximo de la función definida. Las funciones que va a optimizar son las siguientes:

1. Sphere

   \[f(x,y) = -\left(x^2 + y^2\right)\]

2. Rastrigin

   \[f(x,y) = -\left[ 2A + \left(x^2 - A\cos(2\pi x)\right) + \left(y^2 - A\cos(2\pi y)\right) \right], \quad A = 10\]

3. Ackley

   \[f(x,y) = -\left[ -20\, e^{-0.2\sqrt{0.5(x^2 + y^2)}} - e^{0.5(\cos(2\pi x) + \cos(2\pi y))} + e + 20 \right]\]

4. Booth

   \[f(x,y) = -\left[(x + 2y - 7)^2 + (2x + y - 5)^2\right]\]

He de ser sincero, solo quería añadir estas animaciones porque molan.

Los algoritmos genéticos son uno de los muchos métodos metaheurísticos que existen. Desde luego no son los mejores, pero les tengo cariño y su diseño es inteligente a la par que sencillo. Es divertido programar GAs. Además, investigar en el camino las distintas decisiones de diseño que se pueden tomar, es enriquecedor.