Embeddings: el significado como coordenadas

Empecemos por la palabra que vas a oír en todo lo que sigue. Un vector es una lista ordenada de números. Por ejemplo:

• (4, 3) es un vector con 2 números.
• (0.12, −0.80, 0.33) es un vector con 3 números.
• Un vector de 512 números es lo mismo, solo que más largo.

La cantidad de números se llama la dimensión del vector. (4, 3) tiene dimensión 2. El orden importa: (4, 3) y (3, 4) son vectores distintos.

¿Por qué llamarle «vector» y no «lista»? Porque un vector se puede dibujar. Con 2 números, el primero dice cuántos pasos ir a la derecha y el segundo cuántos hacia arriba. El vector (4, 3) es el punto que queda 4 a la derecha y 3 arriba del origen (el punto (0, 0), donde se cruzan los ejes). También se dibuja como una flecha que sale del origen y llega a ese punto: el punto dice dónde; la flecha, además, hacia dónde apunta. Las dos ideas nos van a servir.

Con 3 números ya es un punto en el espacio: derecha, arriba y hacia el frente. Con 512 números ya no lo puedes imaginar, pero las cuentas son exactamente las mismas que en 2D. Por eso en esta lección todo se explica en 2D y luego se dice qué cambia al crecer.

Un mapa de productos

Imagina que tomamos cuatro productos del marketplace de C01 y los colocamos en un plano, de modo que los que se parecen queden juntos. Una forma posible:

Los dos calzados quedan a la derecha, muy juntos. La playera y la bolsa (ropa y accesorios) quedan a la izquierda, también juntas. Entre los dos grupos hay un buen espacio.

Fíjate en algo importante: los ejes no tienen nombre. No dijimos «el eje x es qué tan deportivo es». Solo pedimos que lo parecido quede cerca, y estas coordenadas lo cumplen. Esa es exactamente la situación de un embedding real.

Qué es un embedding

Un embedding es el vector que un modelo produce para una cosa (una foto, una frase, un producto, un usuario) con una propiedad muy especial: cosas parecidas producen vectores cercanos.

¿De dónde sale? De una red neuronal ya entrenada. En la lección de redes viste que una red es una pila de capas, y que cada capa transforma los números que recibe. Las primeras capas detectan cosas simples (bordes, colores); las de más adentro, cosas más abstractas (una suela, unas agujetas). La última capa convierte todo eso en la respuesta final, por ejemplo las 500 categorías de C01.

Si cortas la red justo antes de esa última capa, lo que sale es un vector que resume la foto. Ese vector es un embedding. En la ResNet-50 de C01, justo antes de la última capa, sale un vector de 2,048 números.

También hay modelos entrenados a propósito para producir embeddings. Se llaman encoders (codificadores): entran datos, sale un vector. Muchos se entrenan con aprendizaje contrastivo: se les muestran pares que deben quedar juntos, como una foto y su título, y se les corrige cada vez que un par queda lejos o que quedan cerca cosas que no son pareja. Lo ves a fondo en una sección extra, más adelante.

¿Por qué no basta con un número por producto?

Cada producto ya tiene un id. ¿Para qué 512 números? Porque un id no dice nada de parecido. Si tenis = 7, botas = 8 y bolsa = 9, parecería que las botas están «entre» los tenis y la bolsa, y eso no significa nada: los números se pusieron en orden de llegada.

La siguiente idea es el one-hot: un vector con un 1 en la posición de su categoría y 0 en las demás. Con 3 categorías, tenis = (1, 0, 0), botas = (0, 1, 0) y bolsa = (0, 0, 1). Ya no hay un orden falso, pero tampoco hay parecido: cada producto es una esquina distinta, y todas las esquinas están a la misma distancia entre sí. Los tenis quedan igual de lejos de las botas que de la bolsa.

Un embedding resuelve justo eso: la distancia entre dos vectores significa algo. Y gana otra cosa: una publicación nueva, que el modelo nunca vio, recibe su vector igual, porque el modelo lo calcula a partir de su foto.

Tamaños reales

Un embedding real no tiene 2 números, tiene cientos o miles. Algunos que vas a oír:

Cada número se guarda normalmente como float32, que ocupa 4 bytes. Un embedding de 512 números ocupa entonces 512 × 4 bytes = 2,048 bytes ≈ 2 KB. Parece nada. Guarda esa cifra: cuando sean 100 millones de productos, va a decidir la arquitectura.

Texto e imágenes en el mismo espacio

Un embedding multimodal pone cosas de distinto tipo, como fotos y textos, en el mismo espacio, para compararlas directamente. El más conocido es CLIP, que OpenAI publicó en 2021: dos redes, una para fotos y otra para texto, entrenadas juntas para que una foto quede cerca de su descripción. El vector del texto «unos tenis blancos» queda cerca del vector de una foto de unos tenis blancos. Así puedes buscar fotos con texto, texto con fotos o fotos con fotos, con la misma búsqueda. La versión CLIP ViT-B/32 (su red de fotos es un ViT, un transformer que parte la foto en cuadritos de 32 × 32 píxeles) produce 512 números para las dos cosas.

Para comparar dos embeddings hace falta una cuenta. La más importante de toda la lección, y una de las más repetidas de todo ML, es el producto punto (dot product): multiplicas coordenada por coordenada y sumas todo. Se escribe a · b, y el resultado es un solo número, no otro vector.

No es una cuenta rara de matemáticos. La haces cada vez que pagas en una tienda: compras 2 playeras de $50, 1 gorra de $120 y 3 pares de calcetines de $15. Las cantidades son el vector (2, 1, 3) y los precios, (50, 120, 15). El total es su producto punto: 2 × 50 + 1 × 120 + 3 × 15 = 100 + 120 + 45 = $265. Cada cantidad se «pesa» con su precio y todo se suma.

Y ya lo viste en la lección de redes: una neurona multiplica cada entrada por su peso y suma. Eso es el producto punto entre las entradas y los pesos, más el sesgo. La última capa de la ResNet-50 de C01 hace 500 productos punto, uno por categoría, de 2,048 números cada uno: 2,048 × 500 = 1,024,000 multiplicaciones para sacar los 500 logits.

Lo que significa en el dibujo

El signo dice hacia qué lado apuntan las dos flechas:

• Positivo si apuntan hacia el mismo lado, es decir, si forman menos de 90°: tenis y botas, 24.
• Cero si son perpendiculares, a 90°: tenis y playera, 0.
• Negativo si apuntan hacia lados opuestos, a más de 90°: tenis y bolsa, −7.

El tamaño también se lee. Primero, el producto punto de un vector consigo mismo da su largo al cuadrado: (4, 3) · (4, 3) = 16 + 9 = 25, y √25 = 5. Es el teorema de Pitágoras: la flecha de los tenis mide 5. Las botas también miden 5.

Segundo, el producto punto es una sombra. Desde la punta de los tenis baja una línea perpendicular hasta la línea que apunta hacia las botas. El pedazo de esa línea que va del origen al punto donde cae mide 4.8: es lo que los tenis avanzan en la dirección de las botas, su «sombra» sobre ellas. Multiplica esa sombra por el largo de las botas: 4.8 × 5 = 24. Es el producto punto.

¿De qué depende el largo de esa sombra? Del largo de los tenis y del ángulo entre las dos flechas. Con el ángulo muy cerrado, la sombra es casi tan larga como la flecha; a 90°, desaparece; si el ángulo pasa de 90°, cae del lado contrario y cuenta como negativa. Esa fracción de la flecha que queda como sombra tiene un nombre que seguramente viste en la prepa: el coseno del ángulo, una función que vale 1 a 0°, 0 a 90° y −1 a 180°. Para tenis y botas el ángulo es de unos 16° y su coseno, 0.96: la sombra mide 5 × 0.96 = 4.8. Juntando todo:

a · b = (largo de a) × (largo de b) × (coseno del ángulo entre a y b)

Con tenis y botas: 5 × 5 × 0.96 = 24.

¿Por qué el producto punto está en todas partes? Porque es la forma más barata de medir «qué tanto apuntan juntos» dos vectores: si cada uno tiene d números (d es su dimensión), son d multiplicaciones y d − 1 sumas, sin nada más. Y muchos productos punto juntos son una multiplicación de matrices, la operación para la que están hechas las GPUs; lo ves en la lección de matrices y FLOPs. En la lección de transformers vas a ver que la atención compara palabras exactamente así.

Si «parecido» significa «cerca», necesitamos medir qué tan cerca están dos vectores. Hay dos medidas que se usan muchísimo, y una forma de preparar los vectores que hace que las dos digan lo mismo.

Distancia euclidiana: la de la regla

La distancia euclidiana es la distancia en línea recta, la que medirías con una regla. Es el teorema de Pitágoras: restas coordenada por coordenada, elevas al cuadrado, sumas y sacas raíz.

Con 512 números es lo mismo, solo que restas, elevas y sumas 512 veces.

Similitud coseno: hacia dónde apuntan

La similitud coseno no mide la distancia entre las puntas, sino el ángulo entre las dos flechas. Si apuntan en la misma dirección, vale 1. Si son perpendiculares (90°), vale 0. Si apuntan en direcciones opuestas, vale −1. Se calcula con la fórmula de la sección anterior, despejada: el producto punto dividido entre los dos largos.

coseno = (a · b) ÷ (largo de a × largo de b)

¿Por qué ignorar el largo?

Imagina una publicación de tenis con una descripción larguísima, y que el modelo le da el vector (8, 6) en vez de (4, 3). Es la misma dirección, solo el doble de larga. La distancia euclidiana entre (4, 3) y (8, 6) es 5, más lejos que la playera de su bolsa (√2 ≈ 1.41). El coseno, en cambio, es (32 + 18) ÷ (5 × 10) = 50 ÷ 50 = 1: idénticos en dirección.

Muchas veces lo que importa es la dirección (de qué se trata) y no el largo. Para eso sirve normalizar.

Normalización L2: que todos midan 1

Normalizar un vector es dividir cada uno de sus números entre su largo, para que el vector mida exactamente 1. Se llama normalización L2 porque «norma L2» es el nombre técnico del largo de Pitágoras (la raíz de la suma de los cuadrados).

Con todos los vectores normalizados pasan dos cosas muy útiles:

1. El coseno es solo el producto punto, porque los largos valen 1 y dividir entre 1 no cambia nada: (0.8, 0.6) · (0.6, 0.8) = 0.48 + 0.48 = 0.96. Una cuenta menos en cada comparación, y son millones de comparaciones.
2. La distancia y el coseno ordenan igual a los vecinos. Con vectores de largo 1, la distancia al cuadrado es exactamente 2 − 2 × coseno. Mientras más alto el coseno, más chica la distancia.

Por eso la Ronda dice que el encoder de C07 entrega vectores de 512 números «L2-normalizados»: el índice puede comparar con el producto punto, la cuenta más barata. Y cuando una publicación junta su foto y su título en un solo vector, se promedian los dos y el resultado se vuelve a normalizar, porque el promedio de dos flechas de largo 1 casi nunca mide 1 (lo calculas en los ejercicios).

Así se ve todo en Python, sin instalar nada:

import math

def punto(a, b):
    return sum(x * y for x, y in zip(a, b))

def largo(a):
    return math.sqrt(punto(a, a))

def coseno(a, b):
    return punto(a, b) / (largo(a) * largo(b))

def normalizar(a):
    n = largo(a)
    return [x / n for x in a]

tenis = [4, 3]
otros = {"botas": [3, 4], "playera": [-3, 4], "bolsa": [-4, 3], "tenis × 2": [8, 6]}
for nombre, v in otros.items():
    print(f"{nombre:10} punto = {punto(tenis, v):3}   coseno = {coseno(tenis, v):5.2f}")

t, b = normalizar(tenis), normalizar([3, 4])
print("tenis normalizado:", t, "  largo:", largo(t))
print("punto de los dos normalizados:", round(punto(t, b), 2))

botas      punto =  24   coseno =  0.96
playera    punto =   0   coseno =  0.00
bolsa      punto =  -7   coseno = -0.28
tenis × 2  punto =  50   coseno =  1.00
tenis normalizado: [0.8, 0.6]   largo: 1.0
punto de los dos normalizados: 0.96

Con lo anterior ya puedes construir una búsqueda semántica, una búsqueda por significado: calculas el embedding de lo que el usuario busca y encuentras los productos cuyo embedding está más cerca. Encontrar los k más cercanos se llama búsqueda de vecinos más cercanos (nearest neighbors). Si k = 30, quieres los 30 más parecidos.

La forma más obvia es la búsqueda exacta, también llamada fuerza bruta (brute force): comparas el vector de la búsqueda contra todos los del catálogo, uno por uno, y te quedas con los mejores. Así se ve con un catálogo de juguete de 6 productos, con vectores inventados de 3 números:

import math

def normalizar(v):
    n = math.sqrt(sum(x * x for x in v))
    return [x / n for x in v]

catalogo = {                      # vectores inventados de 3 números
    "tenis blancos":  [0.9, 0.3, 0.1],
    "tenis negros":   [0.8, 0.5, 0.0],
    "botas cafés":    [0.5, 0.8, 0.2],
    "sandalias":      [0.6, 0.1, 0.7],
    "playera blanca": [0.1, 0.2, 0.9],
    "bolsa de piel":  [-0.2, 0.9, 0.3],
}
indice = {nombre: normalizar(v) for nombre, v in catalogo.items()}   # una sola vez

def buscar(consulta, k):
    q = normalizar(consulta)
    puntajes = []
    for nombre, v in indice.items():                 # fuerza bruta: contra todos
        puntajes.append((sum(a * b for a, b in zip(q, v)), nombre))
    puntajes.sort(reverse=True)
    return puntajes[:k]

for coseno, nombre in buscar([0.85, 0.35, 0.15], k=3):
    print(f"{coseno:.3f}  {nombre}")

0.996  tenis blancos
0.973  tenis negros
0.818  botas cafés

Fíjate en dos cosas. Los vectores del catálogo se normalizan una vez, al armar el índice; la consulta se normaliza en cada búsqueda. Y el ciclo for recorre todo el catálogo. Con 6 productos es instantáneo. Veamos con un catálogo de verdad.

Las cuentas de C07

En la Ronda, el caso C07 es una búsqueda por texto y por foto sobre el mismo marketplace de C01. Tiene ≈ 100 millones de publicaciones activas, cada una con un embedding de 512 números, y en la hora pico llegan ≈ 1,750 búsquedas por segundo.

La memoria de un servidor grande entrega del orden de unos cientos de GB por segundo. A 200 GB por segundo, solo leer los vectores tomaría ≈ 1 segundo por búsqueda; aun al doble de velocidad, medio segundo. Y C07 se compromete a que 99 de cada 100 búsquedas de texto respondan en menos de 300 ms.

La búsqueda exacta es perfecta en calidad e imposible en costo. Hace falta otra idea.

Búsqueda aproximada: no mirarlo todo

Casi siempre no necesitas los 30 vecinos exactos. Te basta con 30 que sean muy buenos, aunque de vez en cuando se te escape alguno de los verdaderos. Esa renuncia es la que abre la puerta: buscar los vecinos más cercanos aproximados, en inglés approximate nearest neighbors, o ANN.

Un ANN no compara contra todo el catálogo. Antes de que llegue cualquier búsqueda, organiza los vectores para que, cuando llegue una, solo tenga que revisar una parte pequeña y bien elegida. Esa organización guardada se llama índice vectorial.

Estantes: la idea más simple

Velocidad contra recall

¿Qué tanto se pierde? Se mide comparando el ANN contra la búsqueda exacta en una muestra de búsquedas. Si la búsqueda exacta dice que estos son los 100 vecinos verdaderos y el ANN encontró 95 de ellos, su recall@100 es 95 ÷ 100 = 0.95. Es el mismo recall de la lección «¿Aprendió de verdad?»: de lo que había que encontrar, cuánto encontraste.

La perilla es cuánto del catálogo revisar. En un índice por estantes, cuántos estantes. En HNSW, el índice que elige C07, el tamaño de la lista de candidatos que mantiene al buscar, que se llama ef_search. HNSW une los vectores en una red de caminos y busca saltando de vecino en vecino; lo ves por dentro en la sección siguiente.

No existe el índice rápido y perfecto: existe el punto de la perilla que tu sistema puede pagar. En C07 se pide recall@100 ≥ 0.95, y se vigila en producción con un job (un programa que corre solo, termina y vuelve a correr) que cada hora lanza un set fijo de unas 1,000 búsquedas contra el ANN y contra la búsqueda exacta sobre los mismos vectores, y compara.

Casi todos los errores con embeddings tienen algo en común: nada truena. La búsqueda responde, con el formato correcto, y solo baja la calidad. Estos son los que más se repiten.

Comparar vectores sin normalizar

Qué pasa: el índice usa producto punto y los vectores no miden 1. Los vectores largos salen arriba en todas las búsquedas, no porque se parezcan más, sino porque son largos. Pasa también cuando se promedian vectores (foto y título) y se olvida volver a normalizar.

Cómo evitarlo: normaliza al guardar y al consultar, o usa la métrica coseno. Antes de llenar el índice, revisa que el largo de una muestra de vectores dé 1. Y usa la métrica con la que se entrenó el modelo.

Mezclar versiones del modelo

Qué pasa: se actualiza el encoder a la versión 8, pero el índice todavía tiene vectores de la versión 7, o la mitad del catálogo se recalculó y la otra mitad no. Las cuentas salen, pero comparan coordenadas de dos mapas distintos.

Cómo evitarlo: un índice = una versión del modelo. Guarda la versión junto con cada vector, verifica en cada consulta que el encoder y el índice coincidan, y al cambiar de modelo recalcula todo el catálogo en un índice nuevo antes de cambiar el tráfico (en la Ronda, con blue/green: dos índices completos y un cambio de un solo golpe).

Creer que un coseno de 0.9 quiere decir «idéntico»

Qué pasa: se decide «son el mismo producto» porque el coseno es 0.9. Pero en otro modelo 0.9 es normal entre cosas distintas, y «iPhone 13 Pro 128» y «iPhone 12 Pro 256» pueden quedar así de cerca.

Cómo evitarlo: un umbral se mide con pares revisados por personas, para ese modelo y ese uso, y se vuelve a medir cuando cambia el modelo. Lo que tiene que ser exacto (modelo, talla, código) se compara con filtros o con BM25, no con un coseno.

Olvidar el recall del ANN

Qué pasa: el equipo de modelos mide la calidad con una búsqueda exacta sobre un catálogo chico, y en producción el mismo modelo va a un índice aproximado sobre 100 millones, con int8 y filtros. El número que aprobaste no es el que la gente ve.

Cómo evitarlo: mide el recall@k del índice contra la búsqueda exacta sobre los mismos vectores, con un set fijo de consultas que corre solo (en C07, cada hora, con un mínimo de 0.95), y evalúa los modelos nuevos sobre el índice real.

Filtrar después de buscar

Qué pasa: pides los 100 más cercanos y después quitas los que no son de la ciudad que pidió el usuario. Si esa ciudad tiene el 0.1 % del catálogo, de 100 resultados sobreviven en promedio 0.1: casi siempre la página sale vacía.

Cómo evitarlo: el filtro va dentro de la búsqueda. Los motores de índices vectoriales lo permiten; si el filtro deja muy pocos vectores, incluso conviene una búsqueda exacta sobre ese pedacito, que ahí sí es barata.

Usar solo embeddings para lo exacto

Qué pasa: la búsqueda semántica reemplaza a BM25 y empiezan a fallar las búsquedas de marcas, modelos, tallas y códigos de error, que antes funcionaban.

Cómo evitarlo: búsqueda híbrida: BM25 en paralelo, fusión con RRF, y BM25 solo como respaldo si lo semántico falla.

Calcular la memoria solo con los vectores

Qué pasa: «100 millones × 512 × 1 byte = 51.2 GB, cabe en una máquina de 64 GB». Falta el grafo de HNSW (≈ 25.6 GB más si cada vector guarda hasta 64 vecinos), lo que agrega el motor, las copias para no caerse y el índice nuevo que se construye al lado cuando cambia el modelo.

Cómo evitarlo: suma todo: vectores + grafo + ≈ 10 % del motor, por el número de copias, más espacio para el índice nuevo. Con eso decides en cuántos pedazos partirlo.

Resuélvelos con lápiz antes de abrir la solución. Los primeros cuatro son directos; los últimos dos piden juntar varias ideas.

1. 1Fácil

   Calcula el producto punto de (2, −1, 3) y (4, 0, −2). ¿Las dos flechas apuntan hacia el mismo lado?

   Ver la solución paso a paso

   Multiplica coordenada por coordenada y suma: 2 × 4 + (−1) × 0 + 3 × (−2) = 8 + 0 − 6 = 2.

   Es positivo, así que forman menos de 90°: apuntan hacia el mismo lado, aunque apenas. Su coseno lo confirma: los largos son √(4 + 1 + 9) = √14 ≈ 3.74 y √(16 + 0 + 4) = √20 ≈ 4.47, y 2 ÷ (3.74 × 4.47) ≈ 0.12, muy cerca de 0.

2. 2Fácil

   Normaliza el vector (6, 8) y comprueba que el resultado mide 1.

   Ver la solución paso a paso

   Largo: √(6² + 8²) = √(36 + 64) = √100 = 10.

   Normalizado: (6 ÷ 10, 8 ÷ 10) = (0.6, 0.8).

   Comprobación: 0.6² + 0.8² = 0.36 + 0.64 = 1, y √1 = 1. Es la misma dirección que las botas (3, 4).

3. 3Fácil

   ¿Cuál es la similitud coseno entre (1, 2) y (3, 6)? ¿Y su distancia euclidiana? ¿Qué te dice la diferencia?

   Ver la solución paso a paso

   Producto punto: 1 × 3 + 2 × 6 = 15. Largos: √(1 + 4) = √5 ≈ 2.24 y √(9 + 36) = √45 ≈ 6.71. Coseno: 15 ÷ (2.24 × 6.71) = 15 ÷ 15 = 1. (Exacto: √5 × √45 = √225 = 15.)

   Distancia: √((3 − 1)² + (6 − 2)²) = √(4 + 16) = √20 ≈ 4.47.

   (3, 6) es (1, 2) multiplicado por 3: la misma dirección, el triple de largo. El coseno dice «idénticos»; la distancia dice «lejos». Si el largo no significa nada para tu modelo, el coseno (o normalizar antes) es la medida correcta.

4. 4Fácil

   Un catálogo tiene 10 millones de embeddings de 768 números. ¿Cuánta memoria ocupan en float32? ¿Y en float16?

   Ver la solución paso a paso

   float32: 10,000,000 × 768 × 4 bytes = 30,720,000,000 bytes ≈ 30.7 GB.

   float16 usa 2 bytes por número, la mitad: ≈ 15.4 GB.

5. 5Medio

   Para una consulta, la búsqueda exacta dice que los 10 vecinos verdaderos son A, B, C, D, E, F, G, H, I y J. El índice ANN devolvió A, B, C, D, E, F, G, H, X y Y. ¿Cuál es su recall@10? Si te piden 0.95, ¿qué mueves y qué pagas?

   Ver la solución paso a paso

   De los 10 verdaderos, el ANN encontró 8 (de la A a la H). Recall@10 = 8 ÷ 10 = 0.8.

   Para subirlo hay que revisar más del catálogo: en HNSW, una lista de candidatos más larga (ef_search); en un índice por estantes, más estantes. Se paga en latencia y en CPU por búsqueda, y por lo tanto en máquinas para atender el mismo tráfico. Y una consulta no basta para decidir: el recall se mide sobre un set de cientos o miles de consultas.

6. 6Medio

   Junta con RRF (k = 60: cada lista le da a cada publicación 1 ÷ (60 + su posición), y se suman) tres publicaciones. P está 1.ª en BM25 y no aparece en la lista semántica. Q está 4.ª en BM25 y 2.ª en la semántica. R está 10.ª en las dos. ¿En qué orden quedan?

   Ver la solución paso a paso

   Psolo en BM25

   1/61

   ≈ 0.0164

   Qen las dos

   1/64 + 1/62 ≈ 0.0156 + 0.0161

   ≈ 0.0318

   Ren las dos

   1/70 + 1/70

   ≈ 0.0286

   Resultado

   Orden: Q, R, P.

   P fue la primera de una lista, pero solo de una. Q y R aparecen en las dos, y RRF premia ese acuerdo.

7. 7Medio

   En C07, el vector de una publicación es el promedio del vector de su foto y el de su título. Si la foto da f = (1, 0) y el título t = (0, 1), los dos normalizados, ¿cuánto mide el promedio? ¿Qué hay que hacer y por qué?

   Ver la solución paso a paso

   Promedio: ((1 + 0) ÷ 2, (0 + 1) ÷ 2) = (0.5, 0.5). Largo: √(0.25 + 0.25) = √0.5 ≈ 0.71. No mide 1.

   Hay que normalizarlo otra vez: (0.5 ÷ 0.71, 0.5 ÷ 0.71) ≈ (0.71, 0.71).

   Si no se normaliza y el índice compara con producto punto, todos los puntajes de esa publicación salen multiplicados por 0.71: quedaría castigada en cada búsqueda frente a las publicaciones bien normalizadas, sin ninguna razón.

8. 8Medio

   Con los 8 pares revisados del ejemplo de deduplicación, ¿qué precision y recall da un umbral de 0.92? ¿Lo usarías para limpiar un dataset antes de repartirlo? ¿Y para moderar?

   Ver la solución paso a paso

   Con 0.92 se marcan los pares con coseno de 0.92 o más: 1, 2, 3, 4 y 5, o sea 5 pares. De esos, son duplicados de verdad 1, 2, 3 y 5: 4 aciertos.

   • Precision: 4 ÷ 5 = 0.8.
   • Recall: encontró los 4 duplicados que había: 4 ÷ 4 = 1.0.

   Para limpiar un dataset antes de repartirlo es una buena opción: no se escapa ningún duplicado, y el error (el par 4, dos fotos distintas de los mismos tenis) solo hace que dos fotos caigan del mismo lado. Para moderar, donde una decisión se aplica a todo el grupo, es demasiado laxo: juntaría el par 4 y castigaría una foto que es otra.

9. 9Reto

   C11 tiene 12 millones de pedazos de documentos, cada uno con un embedding de 1,024 números. (a) ¿Cuánta memoria ocupan en float32 y en float16? (b) ¿Cuántas multiplicaciones haría una búsqueda exacta? (c) Si la memoria entrega 200 GB por segundo, ¿cuánto tarda solo en leer los vectores float32 en cada búsqueda? ¿Cabe en los ≈ 50 a 150 ms que C11 estima para toda esa etapa de búsqueda?

   Ver la solución paso a paso

   (a) 12,000,000 × 1,024 × 4 bytes = 49,152,000,000 bytes ≈ 49.2 GB en float32. En float16, la mitad: ≈ 24.6 GB.

   (b) Un producto punto de 1,024 números por cada pedazo: 12,000,000 × 1,024 = 12,288,000,000 ≈ 12.3 mil millones de multiplicaciones por pregunta.

   (c) 49.2 GB ÷ 200 GB por segundo ≈ 0.25 s = ≈ 250 ms, solo para leer. No cabe: es más que toda la etapa. En float16 serían ≈ 123 ms: casi toda la etapa se iría solo en leer, sin contar las multiplicaciones. Por eso C11 usa un índice HNSW, aunque reciba solo ≈ 2 preguntas por segundo: el problema no es el volumen, es la latencia de cada pregunta.

   Un matiz: si un filtro de permisos deja solo unos miles de pedazos (los que una persona puede ver), la búsqueda exacta sobre ese pedacito sí es barata, y los motores la usan en ese caso.

10. 10Reto

    Demuestra que, si a y b miden 1, la distancia euclidiana al cuadrado entre ellos es 2 − 2 × coseno. Pista: la distancia al cuadrado es (a − b) · (a − b), y el producto punto se puede repartir como una multiplicación normal.

    Ver la solución paso a paso

    La distancia al cuadrado es la suma de las diferencias al cuadrado, que es el producto punto de (a − b) consigo mismo:

    distancia² = (a − b) · (a − b) = a · a − 2 (a · b) + b · b

    Ahora usa lo que sabes:

    • a · a es el largo de a al cuadrado: 1² = 1. Igual b · b = 1.
    • Como los dos miden 1, a · b es exactamente su coseno.

    Entonces: distancia² = 1 − 2 × coseno + 1 = 2 − 2 × coseno.

    Comprobación con tenis y botas normalizados: coseno 0.96, así que 2 − 1.92 = 0.08, y la cuenta directa (0.8 − 0.6)² + (0.6 − 0.8)² = 0.04 + 0.04 = 0.08. La consecuencia práctica: con vectores normalizados, ordenar por distancia o por coseno da los mismos vecinos, así que cualquiera de las dos métricas sirve.

En la Ronda:

• M02 · Patrones de inferencia usa la búsqueda por embeddings como ejemplo del patrón híbrido: los embeddings del catálogo se calculan en lote; el de la consulta, en cada request. Ahí también está la cascada: un modelo barato revisa todo y uno caro, solo lo que queda en duda.
• M07 · Servidores de modelos sirve los encoders y los re-rankers (en Triton, o en vLLM; son programas que ponen modelos a responder) y menciona /v1/embeddings, la dirección de la API a la que se le piden embeddings.
• M09 · Datos y features deduplica por hash y por casi duplicados antes de repartir el dataset. Cita un estudio sobre CIFAR-10 y CIFAR-100, dos datasets públicos de fotos chiquitas muy usados en investigación: el 3.3 % de las fotos de examen del primero y el 10 % de las del segundo tienen un casi duplicado en el entrenamiento.
• M12 · Monitoreo detecta drift en imágenes comparando embeddings de hoy contra una referencia, desde la distancia entre los promedios hasta métodos más finos.
• Los casos C07 (búsqueda), C11 (RAG), C06 (moderación) y C08 (recomendación) hacen las cuentas de esta lección en grande: 205 GB en float32 y 51.2 GB en int8, el grafo de 25.6 GB, recall@100 ≥ 0.95, RRF con k = 60, el re-ranker de 30 contra 100 candidatos y las dos torres de 128 números.

En el Dojo: la estación 1 (Datos y etiquetas) cruza huellas de contenido contra el golden set para que ninguna foto del examen se cuele al entrenamiento. Es deduplicación de copias exactas; los casi duplicados son el siguiente paso, con lo que viste aquí.

En Sensei: la siguiente lección, Transformers y LLMs, convierte cada token en un embedding, compara palabras con productos punto en la atención y usa todo lo de esta lección en RAG. Después, «Cómo guarda números una computadora» explica int8 y la cuantización; «Matrices, FLOPs y qué tan rápido calcula una GPU», por qué miles de productos punto juntos son una multiplicación de matrices, y «Comparar distribuciones», cómo se mide el drift con más cuidado que un promedio.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Qué es un embedding y por qué sirve para buscar cosas parecidas?Ver respuesta

   Es el vector que un modelo produce para una cosa, de forma que cosas parecidas reciben vectores cercanos. Así, «buscar algo parecido» se vuelve «buscar el vector más cercano», que es una cuenta.

2. 2Calcula la similitud coseno entre (1, 0) y (0, 2). ¿Qué significa?Ver respuesta

   Producto punto: 1 × 0 + 0 × 2 = 0. El coseno es 0 ÷ (1 × 2) = 0. Son perpendiculares: para el modelo, no tienen nada que ver. (El largo distinto no importa: el coseno solo mira la dirección.)

3. 3¿Por qué se guardan los embeddings normalizados?Ver respuesta

   Porque con largo 1 el coseno es solo el producto punto, una cuenta más barata, y la distancia y el coseno ordenan igual a los vecinos. Además, ningún vector «gana» solo por ser largo.

4. 4¿Por qué no se hace la búsqueda exacta sobre 100 millones de vectores?Ver respuesta

   Porque cada búsqueda tendría que comparar contra todos: 100 M × 512 = 51.2 mil millones de multiplicaciones, y leer ≈ 205 GB de memoria. Con cientos o miles de búsquedas por segundo no hay forma de pagarlo. Un ANN revisa solo una parte bien elegida, a cambio de perder de vez en cuando algún vecino verdadero.

5. 5Un índice ANN tiene recall@100 = 0.90 y te piden 0.95. ¿Qué perilla mueves y qué pagas?Ver respuesta

   Revisar más del catálogo: más estantes en un índice por grupos, una lista de candidatos más larga (ef_search) en HNSW. Sube el recall, pero cada búsqueda tarda más y necesitas más máquinas para la misma cantidad de búsquedas por segundo.

6. 6¿Por qué C07 no usa solo búsqueda semántica?Ver respuesta

   Porque los embeddings confunden lo exacto: «iPhone 13 Pro 128» queda cerca de «iPhone 12 Pro 256». BM25 encuentra marcas, modelos y tallas; los embeddings, sinónimos y descripciones vagas. Juntas, con RRF, cada una tapa los huecos de la otra, y BM25 queda de respaldo.

7. 7¿Por qué el re-ranker solo mira los primeros candidatos y no todo el catálogo?Ver respuesta

   Porque es caro por candidato: lee la búsqueda y cada candidato juntos. Sobre decenas de candidatos es pagable; sobre millones, imposible. El retrieval barato trae los candidatos y el re-ranker caro ordena bien los primeros.