# El significado como coordenadas

Curso exprés sobre embeddings y búsqueda vectorial. 20 conceptos — embedding, espacio vectorial, similitud coseno, búsqueda de vecinos más cercanos, vector database, ANN, semantic search, RAG retrieval, clustering, recomendaciones, reranking, evals de embeddings y más — cada uno con su nombre en inglés, un diagrama, un ejemplo y una ficha. El significado hecho computable: «encuentra cosas como esta» se vuelve «encuentra puntos cercanos». Al final, una hoja de referencia de una página con todos los conceptos.

- **Author:** Fedor Chishchin
- **Level:** intermediate
- **Reading time:** ~35 minutos de lectura
- **Published:** 2026-06-13
- **Source:** https://fedorthinks.com/es/learn/embeddings-express

---

## 1. El significado como coordenadas

Todo el campo descansa sobre una idea elegante: si puedes situar el significado en el espacio, puedes computar con él. Compréndelo y los embeddings dejan de ser un misterio.

### El mapa: 20 conceptos en siete grupos

> Un mapa de metro: primero ves toda la red, luego la recorres estación por estación.

Primero tres **fundamentos** — por qué los caracteres no bastan para una computadora, qué es un embedding y qué es el espacio del significado. Después seis grupos, uno por capítulo: la **similitud**, la **vector database**, la **semantic search**, los usos **más allá de la búsqueda**, las **trampas** y cómo **usarlos bien**.

Cada concepto recibe después el mismo trato: su **nombre en inglés** (apréndelo — es el término), una imagen de la vida real, un **diagrama** y una **ficha** con campos: _qué es_, _cómo funciona_, _ejemplo_, _ojo_ y _relaciones_.

_Diagram: Arriba, los fundamentos; luego seis grupos — los capítulos 2–7 los siguen._

### Lexical Gap — las computadoras ven caracteres, no significado

> Una máquina capaz de distinguir que dos fotografías son diferentes píxel a píxel, pero que no tiene ni idea de que ambas muestran un perro — la superficie difiere, el significado le resulta invisible.

Para una computadora, el texto son solo caracteres. Puede comprobar si dos cadenas son idénticas, pero no tiene un sentido propio de que «car» y «automobile» significan lo mismo, o de que «the bank approved my loan» y «my mortgage was accepted» hablan del mismo hecho. Esta brecha entre las palabras y el significado es el **lexical gap**. Cotejar palabras exactas (**exact match**) se pierde el significado por completo. Para que el software trabaje con lo que el texto _significa_, en lugar de cómo se escribe, necesitas una forma de convertir el significado en algo que una computadora pueda medir.

_Diagram: Para una comparación exacta son dos cadenas distintas. Para una persona, el mismo hecho._

#### Lexical Gap (la brecha entre palabras y significado)

- **Qué es:** El mismo significado puede decirse con otras palabras — y la computadora solo compara palabras.
- **Ejemplo:** «Car» y «automobile»; «the bank approved my loan» y «my mortgage was accepted».
- **Ojo:** La búsqueda por palabras exactas pasa por alto, sin avisar, todo lo dicho de otra forma.
- **Relaciones:** Es la brecha que cierra un **embedding**.

### Embedding — el texto se convierte en un punto

> Un mapa donde cada idea tiene una ubicación, y las ideas que significan cosas parecidas quedan cerca unas de otras — «dog» cerca de «puppy», ambas lejos de «tax return».

Un **embedding** es una lista de números — un **vector** — que representa el significado de un fragmento de texto. Lo produce un **embedding model**: el modelo lee el texto y devuelve sus coordenadas. Texto parecido recibe números parecidos — y por tanto un punto cercano. El significado, que era invisible para la computadora, se ha convertido en una posición — y las posiciones son algo que el software puede comparar, ordenar y buscar.

_Diagram: Texto → embedding model → vector. El vector son las coordenadas del significado._

#### Embedding (vector)

- **Qué es:** Una lista de números (un vector) que representa el significado de un texto.
- **Cómo funciona:** Un embedding model lee el texto y devuelve coordenadas; significado parecido, números parecidos.
- **Ejemplo:** «puppy» → `[0.21, −0.83, 0.47, …]` — justo al lado del vector de «dog».
- **Ojo:** La calidad de todo el espacio depende del modelo que lo construye.
- **Relaciones:** Los puntos viven en un **vector space**; una **vector database** los guarda.

### Vector Space — un espacio donde la cercanía significa similitud

> Un mapa donde «dog», «puppy» y «cat» forman un grupo en una esquina, y «spreadsheet» y «tax return» en otra.

Todos los embeddings viven en un único **vector space** de muchas dimensiones (también llamado **embedding space**). Tiene cientos de dimensiones, pero la idea se ve fácil en una página plana: los puntos de significado parecido quedan cerca, los que no se relacionan quedan lejos. «Dog» y «puppy» quedan juntos, y ambos lejos de «spreadsheet». El espacio mismo es un mapa del significado.

_Diagram: Los significados parecidos se agrupan; los que no se relacionan acaban al otro lado del mapa._

#### Vector Space (embedding space)

- **Qué es:** Un espacio de muchas dimensiones donde cada texto tiene una ubicación.
- **Cómo funciona:** El modelo coloca los puntos de modo que la cercanía signifique similitud de significado.
- **Ejemplo:** El grupo «dog / puppy / cat» queda lejos del grupo «spreadsheet / tax return».
- **Relaciones:** La distancia en él es la **semantic similarity**.

### Meaning as Geometry — una vez que el significado tiene coordenadas, puedes computar con él

> Una vez que cada pueblo es un punto en un mapa, «encuentra el pueblo más cercano» se vuelve geometría simple — el mapa convirtió una pregunta vaga en una medible.

Este es el movimiento que hace posible todo lo demás: con el significado expresado como coordenadas, las preguntas difusas sobre el significado se vuelven preguntas precisas sobre geometría. «¿Qué documentos tratan de este tema?» se vuelve «¿qué puntos están cerca de este punto?». «¿Esto es parecido a aquello?» se vuelve «¿qué distancia hay entre ellos?». La computadora no puede entender el significado, pero puede medir la distancia a la perfección — y los embeddings le permiten responder preguntas sobre el significado midiendo distancias en su lugar. Esa traducción es todo el truco.

_Diagram: A la izquierda, preguntas difusas sobre el significado; a la derecha, las mismas preguntas como geometría precisa._

> **La pregunta de encuadre:** «¿Necesito trabajar con lo que el texto significa, no solo con cómo se escribe — porque esa es justo la brecha que cierran los embeddings, al convertir el significado en coordenadas?»

> Las computadoras ven caracteres, no significado. Un embedding convierte un fragmento de texto en un punto en el espacio, situado de modo que los significados parecidos queden cerca — y así el software puede medir el significado.

## 2. La similitud es distancia

Con el significado situado en el espacio, comparar dos cosas por su significado se reduce a medir qué tan lejos están sus puntos. Esta idea sencilla es el motor de todo lo que hacen los embeddings.

### Semantic Similarity — puntos cercanos significan cosas parecidas

> En un mapa, dos pueblos cercanos son fáciles de recorrer; dos en costas opuestas están lejos. La cercanía en el mapa refleja la cercanía en la realidad.

Como los embeddings sitúan los significados parecidos cerca unos de otros, **la distancia entre puntos mide la diferencia de significado**: cerca es parecido, lejos es sin relación. Esto es la **semantic similarity**. Para saber cuánto se parecen dos textos, conviertes ambos en embeddings y mides el espacio entre sus vectores — una distancia pequeña indica que significan casi lo mismo. Una distancia que sí puedes calcular sustituye a una similitud que no podías.

_Diagram: La consulta «get my money back» queda cerca de «refund policy» y lejos de «office hours»._

#### Semantic Similarity (similitud por significado)

- **Qué es:** Qué tan cerca están dos textos en significado.
- **Cómo funciona:** Conviertes ambos en embeddings y mides la distancia entre los vectores.
- **Ejemplo:** «How do I get my money back» está cerca de «refund policy», aunque casi no comparten palabras.
- **Ojo:** Parecido en tema no significa útil — véase **similar ≠ relevant**.
- **Relaciones:** Suele medirse con la **cosine similarity**.

### Nearest-Neighbour Search — encontrar los puntos más cercanos

> Un bibliotecario que, con un libro en la mano, te señala al instante el estante de los libros más parecidos — no por el título, sino por de qué tratan.

La operación central es la **nearest-neighbour search (k-NN)**: dado un punto, encontrar los _k_ puntos más cercanos a él. «Muéstrame cosas como esta» se vuelve «encuentra los vecinos más cercanos de este elemento en el espacio». Le das al sistema una pregunta, un producto, un documento, y devuelve los más parecidos en significado, ordenados por cercanía. Esta sola operación impulsa la semantic search, las recomendaciones y casi todo lo que viene después. Todo es alguna versión de «encuentra los puntos cercanos».

_Diagram: Alrededor de la consulta: los tres puntos más cercanos, por orden de cercanía. Todo lo demás queda lejos._

#### Nearest-Neighbour Search (k-NN)

- **Qué es:** Dado un punto, encontrar los k puntos más cercanos a él.
- **Cómo funciona:** Calcular la similitud y ordenar por cercanía — el top-k es la respuesta.
- **Ejemplo:** Una pregunta → los tres documentos más cercanos a ella en significado.
- **Ojo:** Revisar cada punto entre millones es demasiado lento — hace falta **ANN**.
- **Relaciones:** La base de la **semantic search**, las **recomendaciones** y la **clasificación**.

### Cosine Similarity — la dirección importa más que la distancia bruta

> Dos flechas que apuntan al mismo lado se parecen aunque una sea más larga — lo que importa es la dirección a la que apuntan, no su longitud.

En la práctica, la similitud suele medirse por el _ángulo_ entre vectores y no por la distancia en línea recta — una medida llamada **cosine similarity**. Dos embeddings que apuntan en la misma dirección se consideran parecidos aunque uno sea «más largo», porque la dirección capta el significado, mientras que la longitud suele reflejar cosas como el largo del texto. No necesitas las matemáticas para usar embeddings, pero conviene saber que la medida estándar de «qué tan parecido» trata de dirección, no de distancia bruta.

_Diagram: A y B apuntan al mismo lado — parecidos, pese a su distinta longitud. C apunta a otra parte._

#### Cosine Similarity (similitud basada en el ángulo)

- **Qué es:** Similitud según el ángulo entre vectores, no su longitud.
- **Por qué:** La dirección capta el significado; la longitud suele reflejar solo el largo del texto.
- **Ejemplo:** Una nota corta y un artículo largo sobre el mismo tema — ángulo pequeño, similitud alta.
- **Relaciones:** La medida estándar para la **semantic similarity** y el **k-NN**.

> **La pregunta de la similitud:** «¿Intento encontrar las cosas más parecidas en significado a un elemento dado — porque eso es simplemente encontrar sus vecinos más cercanos en el embedding space?»

> Los significados parecidos quedan cerca, así que la similitud se vuelve distancia. La operación central es la nearest-neighbour search — encontrar los puntos más cercanos — que suele medirse por dirección, con la cosine similarity.

## 3. La vector database

Encontrar vecinos más cercanos es fácil con un puñado de puntos y difícil con millones. La vector database es el motor creado para hacerlo rápido a escala — el hogar práctico de los embeddings.

### Vector Database — un almacén hecho para la búsqueda de vecinos más cercanos

> Un almacén organizado de modo que, dado cualquier artículo, pueda traerte al instante los cien más parecidos — no revisando cada estante, sino por cómo está dispuesto.

Una **vector database** guarda tus embeddings y responde rápido a consultas del tipo «encuentra los puntos más cercanos a este», incluso entre millones de vectores. Está hecha a propósito para la única operación que necesitan los embeddings: la búsqueda de vecinos más cercanos por similitud. Conviertes tus datos en embeddings una sola vez, guardas los vectores, y la base de datos se vuelve un índice de significado en el que se puede buscar. Cuando se construyen búsqueda, RAG o recomendaciones sobre embeddings, la vector database es donde viven los vectores y donde ocurre la búsqueda.

_Diagram: La app guarda vectores en la base de datos y recibe de vuelta los k más cercanos._

#### Vector Database (vector store)

- **Qué es:** Un almacén de vectores con búsqueda rápida de vecinos más cercanos.
- **Cómo funciona:** Guarda vector, id y metadatos; dado un vector de consulta, devuelve los top-k más cercanos.
- **Ejemplo:** Un millón de fragmentos de documentación; una consulta encuentra los cinco más cercanos en milisegundos.
- **Relaciones:** Un índice **ANN** por dentro; encima corren la **semantic search** y el **RAG**.

### ANN — la búsqueda aproximada hace rápida la escala

> Para encontrar el café más cercano no mides la distancia a todos los cafés de la Tierra — miras primero en tu barrio. Los atajos inteligentes ganan a revisarlo todo.

Comparar una consulta con cada vector guardado sería demasiado lento a escala. Por eso las vector databases usan la búsqueda **approximate nearest-neighbour (ANN)**: una indexación ingeniosa que encuentra los puntos más cercanos sin revisarlos todos, cambiando un poquito de precisión por una enorme ganancia de velocidad. Por eso una búsqueda vectorial entre millones de elementos responde en milisegundos. Rara vez necesitas los vecinos más cercanos exactos — «muy cerca» sirve tanto como «el más cercano».

_Diagram: Arriba: la búsqueda exacta compara con todo. Abajo: ANN va directo al vecindario correcto._

#### ANN (vecino más cercano aproximado)

- **Problema:** Comparar una consulta con cada uno de millones de vectores es demasiado lento.
- **Idea:** El índice salta a la región correcta del espacio y revisa solo esa.
- **Ejemplo:** Búsqueda entre millones de elementos — en milisegundos.
- **Coste:** De vez en cuando se le escapa el vecino más cercano real — «muy cerca» en lugar de «el más cercano».
- **Relaciones:** El motor dentro de una **vector database**; acelera el **k-NN**.

### Embed Once, Query Many — se hace el embedding una vez, se busca muchas veces

> Catalogas la biblioteca una sola vez cuando llegan los libros, y después cada consulta es instantánea — la indexación lenta ocurre al principio, la búsqueda rápida para siempre después.

La forma de un sistema de embeddings es: **convertir tus datos en embeddings una sola vez** al principio y guardar los vectores (**index time**), y luego **buscar barato** en cada consulta (**query time**). Calcular embeddings tiene un coste, pero se paga cuando se añaden los datos, no en cada búsqueda. El paso caro es la indexación única; el coste por consulta es un vector y una búsqueda rápida. Conocer esta división ayuda a razonar tanto sobre el coste como sobre la frescura de un sistema de embeddings.

_Diagram: Arriba: indexación única de todos los documentos. Abajo: el camino barato de cada consulta._

#### Embed Once, Query Many (index time vs query time)

- **Idea:** Hacer el embedding de los datos al principio, al añadirlos; en la consulta, solo el de la consulta.
- **Ejemplo:** Los documentos se convierten en embeddings al subirlos; la pregunta de un usuario es un vector y una búsqueda.
- **Ojo:** Los datos nuevos o modificados también deben convertirse en embeddings, o la búsqueda no los ve.
- **Relaciones:** Se guardan en una **vector database**; cambiar de modelo = rehacer todos los embeddings (**same model**).

> **La pregunta de la base de datos:** «¿Dónde viven mis vectores, y es la búsqueda lo bastante rápida a mi escala — uso una vector database con búsqueda aproximada, en lugar de revisarlo todo?»

> Una vector database guarda embeddings y encuentra vecinos más cercanos rápido, usando búsqueda aproximada (ANN) para llegar a millones. Haz el embedding de tus datos una vez al principio; búscalos barato en cada consulta.

## 4. La semantic search

El uso más directo de los embeddings es una búsqueda que entiende el significado. Vale la pena verla con claridad, porque es a la vez la aplicación más común y el cimiento del RAG.

### Semantic Search — buscar por significado, no por palabras coincidentes

> Un ayudante que encuentra lo que quieres aunque lo describas con tus propias palabras — «la cosa que mantiene frías las bebidas» te lleva al refrigerador, sin necesidad de coincidencia exacta.

La **semantic search** encuentra resultados por significado y no por coincidencia de palabras clave (**keyword search**). Conviertes la consulta del usuario en un embedding y buscas los fragmentos de documentos cuyos vectores estén más cerca. Así, una búsqueda de «how do I get my money back» encuentra una página titulada «refund policy», porque sus significados están cerca — aunque casi no comparten palabras. La keyword search no lo vería; la semantic search está hecha para eso. Encuentra lo que _quisiste decir_, no solo lo que escribiste literalmente.

_Diagram: La keyword search no encuentra nada. La búsqueda por significado encuentra «refund policy»._

#### Semantic Search (búsqueda por significado)

- **Problema:** Los usuarios escriben con sus propias palabras — las palabras clave no coinciden.
- **Idea:** Convertir la consulta en embedding y encontrar los vectores de documentos más cercanos.
- **Ejemplo:** «How do I get my money back» → la página «Refund policy».
- **Coste:** Necesita un modelo, una vector database y rehacer los embeddings cuando cambia el modelo.
- **Relaciones:** Funciona sobre **k-NN** y una **vector database**; es el retrieval del **RAG**.

### Same Model, Same Space — haz el embedding de la consulta igual que el de los datos

> Para comparar dos medidas hay que usar la misma regla — si mides una en pulgadas y otra en centímetros, los números no cuadran.

Para que la búsqueda funcione, la consulta y los documentos guardados deben convertirse en embeddings con el **mismo modelo**, en el mismo espacio — si no, sus coordenadas no son comparables y «el más cercano» no significa nada. Conviertes tus documentos con un modelo, y al consultar conviertes la pregunta con ese mismo modelo. Suena obvio, pero es un error común: mezclar modelos de embeddings, o cambiar de modelo sin rehacer todos los embeddings, rompe la búsqueda sin avisar porque los puntos ya no comparten espacio.

_Diagram: Izquierda: un modelo, un espacio. Derecha: modelos mezclados — las distancias no significan nada._

#### Same Model, Same Space (un modelo para la consulta y los datos)

- **Qué es:** La consulta y los documentos pasan por exactamente el mismo modelo.
- **Por qué:** Modelos distintos hacen espacios distintos; sus coordenadas no se comparan.
- **Ejemplo:** Cambiaste el modelo de la consulta pero dejaste los vectores viejos de los documentos — la búsqueda se rompió sin avisar.
- **Ojo:** No hay ningún error; los resultados simplemente empeoran.
- **Relaciones:** Cambiar de modelo = rehacer todos los embeddings (otra vez **embed once**).

### RAG Retrieval — este es el retrieval bajo el RAG

> El examen a libro abierto: la semantic search es cómo encuentras las páginas correctas antes de responder — la consulta que hace posibles las respuestas fundamentadas.

La semantic search es el paso de **retrieval** de la **retrieval-augmented generation** (el curso de RAG). Cuando un sistema RAG responde a partir de tus documentos, los embeddings son la forma en que encuentra los fragmentos relevantes para poner en el contexto del modelo. Así, la calidad de un sistema RAG depende mucho de la calidad de su búsqueda por embeddings — si los fragmentos correctos quedan cerca de la consulta, la respuesta está fundamentada; si quedan los equivocados, el modelo responde con basura.

_Diagram: Pregunta → embedding → búsqueda → mejores fragmentos al contexto → respuesta fundamentada del LLM._

#### RAG Retrieval (el paso de retrieval en el RAG)

- **Qué es:** El paso en que el RAG encuentra fragmentos para el contexto del modelo.
- **Cómo funciona:** Embedding de la pregunta → encontrar los fragmentos más cercanos → pasan al prompt.
- **Ejemplo:** Un bot de soporte encuentra tres párrafos de la documentación de ayuda y responde a partir de ellos.
- **Ojo:** Fragmentos equivocados → el modelo responde con seguridad a partir de basura.
- **Relaciones:** Es **semantic search**; la calidad depende de **garbage in** y del modelo.

> **La pregunta de la búsqueda:** «¿Estoy cotejando significado, convirtiendo la consulta y los documentos en embeddings con el mismo modelo — o espero que el usuario haya escrito las mismas palabras clave que usaron mis documentos?»

> La semantic search encuentra por significado, no por palabras clave — haz el embedding de la consulta igual que el de los datos y encuentra los vectores más cercanos. Es el motor de retrieval que hay bajo el RAG.

## 5. Más allá de la búsqueda

La búsqueda es el uso obvio, pero la misma idea de «el significado como coordenadas» impulsa en silencio una gama sorprendente de otras tareas. Verlas muestra por qué los embeddings son una herramienta tan fundamental.

### Clustering & Deduplication — agrupar por significado

> Clasificar un montón de documentos mezclados en pilas por tema — juntando los que significan cosas parecidas, sin leer cada palabra.

Como los significados parecidos se agrupan en el espacio, puedes **agrupar** datos por significado de forma automática — esto es el **clustering**: reunir comentarios de clientes en temas, organizar artículos por tema, encontrar las categorías naturales en un montón de texto. La misma idea atrapa los **duplicados y casi-duplicados (deduplication)** — dos tickets de soporte que describen el mismo problema con otras palabras quedan juntos, así que puedes detectarlos y fusionarlos. Toda tarea que en el fondo sea «¿cuáles de estos significan lo mismo?» es una tarea de embeddings.

_Diagram: Los tickets se reparten solos en temas; dos puntos casi idénticos son duplicados que fusionar._

#### Clustering & Deduplication (agrupación, detección de casi-duplicados)

- **Problema:** Un montón de texto, sin saber qué temas contiene ni qué se repite.
- **Idea:** Los puntos cercanos forman un grupo; los casi idénticos son duplicados.
- **Ejemplo:** Los comentarios de clientes se ordenan solos en temas; dos tickets sobre un mismo problema se fusionan.
- **Relaciones:** La misma cercanía que la **semantic similarity**.

### Recommendations — más de lo que te gustó

> Un vendedor que, viendo lo que compraste, te señala otras cosas que disfrutó gente con gustos parecidos — entra similitud, salen sugerencias.

Las **recomendaciones** son nearest-neighbour search disfrazada: conviertes los elementos (productos, artículos, canciones) en embeddings para que los parecidos queden cerca, y «recomienda más como esto» se vuelve «encuentra los elementos más cercanos a lo que le gustó al usuario». La misma maquinaria que encuentra documentos parecidos a una consulta encuentra productos parecidos a una compra. Cada vez que ves «también te puede gustar», hay buenas probabilidades de que detrás haya embeddings.

_Diagram: La compra hace de consulta; sus vecinos más cercanos son las recomendaciones._

#### Recommendations («también te puede gustar»)

- **Problema:** Cómo sugerir otra cosa que el usuario querrá.
- **Idea:** El elemento que gustó es la consulta; sus vecinos más cercanos son las sugerencias.
- **Ejemplo:** Compró botas de senderismo → calcetines de trail, una chaqueta de lluvia, una mochila.
- **Relaciones:** Es **k-NN** sobre productos en lugar de documentos.

### Classification & Anomaly Detection — quién pertenece y quién no

> Un guardia de seguridad que sabe cómo luce lo normal y nota a la única persona que se comporta distinto del resto — el valor atípico queda aparte en el espacio.

Los embeddings impulsan la **classification** — un elemento nuevo probablemente es de la misma categoría que los elementos etiquetados más cercanos a él — y la **anomaly detection** — algo cuyo embedding queda lejos de todo lo normal es un valor atípico que vale la pena señalar. Detectar fraude, contenido fuera de tema o entradas inusuales se vuelve «encuentra lo que está lejos del grupo». El patrón recurrente es el mismo: convertir las cosas en puntos y luego razonar sobre cercanía y distancia.

_Diagram: Izquierda: un elemento nuevo cae junto a «spam». Derecha: un punto lejos de lo normal es una anomalía._

#### Classification & Anomaly Detection (etiquetado por vecinos, detección de valores atípicos)

- **Clasificación:** Un elemento nuevo toma la etiqueta de sus vecinos etiquetados más cercanos.
- **Anomalías:** Un punto lejos de todo lo normal es un valor atípico que vale la pena señalar.
- **Ejemplo:** Un correo cae junto al spam → spam; una transacción rara → revisarla.
- **Relaciones:** La cercanía es **k-NN**; la distancia al grupo es **similarity**.

> **La pregunta de más allá de la búsqueda:** «¿Esta tarea trata en realidad de qué cosas significan lo mismo, o de cuáles no se parecen al resto — porque si es así, la resuelven los embeddings y la distancia, no solo la búsqueda?»

> Los embeddings impulsan mucho más que la búsqueda: el clustering y la deduplication agrupan por significado, la recomendación encuentra elementos parecidos, y la classification y la anomaly detection razonan sobre cercanía y distancia.

## 6. Las trampas

Los embeddings son potentes pero fáciles de usar mal, de formas que rompen los resultados sin avisar. Unas pocas trampas explican la mayoría de los sistemas de embeddings que decepcionan.

### Model Mismatch — el modelo de embeddings decide la calidad

> Un traductor que entiende un idioma solo a medias produce un mapa defectuoso de su significado — toda comparación posterior hereda esa distorsión.

Todo depende del modelo que crea los embeddings. Un buen modelo sitúa el significado con precisión, así que las cosas parecidas sí quedan cerca; uno débil o inadecuado (**model mismatch**) produce un espacio distorsionado donde las distancias te engañan. Un modelo entrenado con texto general de la web puede hacer mal los embeddings de tu dominio especializado (legal, médico, código), porque no capta las distinciones que allí importan.

_Diagram: Izquierda: el modelo conoce el dominio — los términos legales se agrupan. Derecha: un modelo genérico — todo queda disperso._

#### Model Mismatch (el modelo no encaja con el dominio)

- **Qué es:** El modelo no entiende tu dominio y construye un espacio distorsionado.
- **Ejemplo:** Un modelo genérico apenas distingue términos legales o médicos, ni código.
- **Ojo:** Sin errores — las distancias simplemente mienten en silencio.
- **Qué hacer:** Elegir el modelo con cuidado y comprobarlo con tus propios datos.
- **Relaciones:** Se arregla con la **model choice** y los **embedding evals**.

### Similar ≠ Relevant — similar no es lo mismo que relevante

> Dos pasajes pueden tratar el mismo tema y aun así responder preguntas distintas — «cómo cancelar» y «por qué la gente cancela» quedan cerca, pero solo uno es lo que se preguntó.

La similitud de embeddings capta la cercanía _temática_, que suele ser un buen sustituto de la relevancia — pero no siempre. Dos textos pueden estar cerca en significado y solo uno responde de verdad a la necesidad. Por eso la búsqueda por embeddings en bruto es una buena primera pasada pero no la última palabra: encuentra lo que trata _sobre_ lo correcto, que no es exactamente lo mismo que lo _útil_. De ahí los refinamientos como el **reranking** — un segundo paso que reordena los resultados según qué tan bien responden a la pregunta.

_Diagram: La búsqueda por similitud pone primero «why users cancel». El reranker sube lo que responde a la pregunta._

#### Similar ≠ Relevant (reranking)

- **Qué es:** «Más cercano» significa «más parecido», no «más útil».
- **Ejemplo:** Para «how do I cancel», la búsqueda devolvió «why users cancel» — mismo tema, respuesta equivocada.
- **Ojo:** Es fácil confiar demasiado en el primer resultado.
- **Qué hacer:** Tratar la búsqueda como una primera pasada; añadir **reranking** como segundo paso.
- **Relaciones:** Un límite de la **semantic similarity** y la **semantic search**.

### Garbage In — basura entra, espacio basura

> Si archivas documentos con etiquetas descuidadas e inconsistentes, ni la búsqueda perfecta en el archivador devuelve algo útil — el índice es tan bueno como lo que se metió en él.

La calidad de un sistema de embeddings está limitada por la calidad de lo que conviertes en embeddings. Un mal **chunking** (del curso de RAG), texto ruidoso o hacer el embedding del campo equivocado produce un espacio donde ni la búsqueda perfecta devuelve buenos resultados — las distancias se calculan sobre basura. Gran parte del trabajo no es la búsqueda; es preparar texto limpio y bien dividido en fragmentos. Arregla las entradas antes de culpar a la búsqueda.

_Diagram: La misma búsqueda: entrada ruidosa da basura, entrada limpia da buenos resultados._

#### Garbage In (mala entrada, mal espacio)

- **Qué es:** Texto malo que entra estropea todo el espacio.
- **Ejemplo:** Fragmentos cortados a media frase, texto ruidoso, embedding del campo equivocado.
- **Ojo:** La gente culpa a la búsqueda cuando lo roto son las entradas.
- **Qué hacer:** Limpiar y dividir bien el texto primero, y luego hacer el embedding.
- **Relaciones:** Golpea directo al **RAG retrieval**; se detecta con los **embedding evals**.

> **La pregunta de las trampas:** «¿Es mi modelo de embeddings adecuado para estos datos, trato «similar» como «relevante» con demasiada confianza, y está limpio el texto que convierto en embeddings — o estoy construyendo sobre un espacio distorsionado?»

> Los embeddings decepcionan de formas conocidas: un modelo débil o inadecuado distorsiona el espacio, «similar» no siempre es «relevante», y las entradas ruidosas hacen que hasta la búsqueda perfecta devuelva basura. Elige el modelo y limpia las entradas.

## 7. Usarlos bien

Usar bien los embeddings se reduce a elegir el modelo correcto, alimentarlo con datos limpios y medir si el espacio refleja de verdad el significado que te importa.

### Model Choice — elige el modelo de embeddings para tus datos

> Contratas a un traductor que de verdad conoce el dialecto en el que trabajas — un generalista podría pasar por alto justo las distinciones que más te importan.

La decisión de más peso es el **embedding model**, y el correcto depende de tus datos y tu tarea. Un modelo general sirve para texto general; un dominio especializado puede necesitar un modelo que lo entienda, o uno ajustado (fine-tuned) con él. Considera **el idioma, el dominio, el tamaño del vector y el coste**. No tomes simplemente el valor por defecto — elige el modelo que construya un espacio preciso para _tu_ significado, porque toda comparación que harás se apoya en él.

_Diagram: Idioma, dominio, tamaño del vector y coste → la elección del modelo → una prueba con tus propios datos._

#### Model Choice (elegir el modelo de embeddings)

- **Idea:** Elegir el modelo según tus datos en lugar de tomar el predeterminado.
- **Criterios:** Idioma, dominio, tamaño del vector, coste.
- **Ejemplo:** Para texto legal — un modelo que entienda el lenguaje jurídico, o uno ajustado con él.
- **Coste:** Cambiar de modelo más tarde = rehacer los embeddings de todos tus datos.
- **Relaciones:** Resuelve el **model mismatch**; se verifica con los **embedding evals**.

### Embedding Evals — mide si el espacio refleja el significado real

> Pruebas un mapa nuevo comprobando que los lugares que conoces y están cerca entre sí salen realmente cerca — si no, el mapa está mal.

No des por hecho que una configuración de embeddings funciona — compruébalo. Para un conjunto de casos donde sabes qué _debería_ ser parecido, verifica que la búsqueda realmente devuelva esos entre los más cercanos. Esta es la versión de los evals para embeddings (**embedding evals**): ¿el espacio pone cerca las cosas correctas, con tus datos reales? Medir esto detecta un mal modelo, un desajuste de dominio o un problema de chunking antes de que degrade en silencio todo lo construido encima. Un espacio de embeddings que no has probado es una suposición; uno que has medido es una herramienta en la que puedes confiar.

_Diagram: Casos de prueba «consulta → documento esperado»; la proporción de aciertos en el top-k es la puntuación._

#### Embedding Evals (evaluación del retrieval)

- **Idea:** Un conjunto de pares «consulta → qué debería encontrarse», comprobando que cae en el top-k.
- **Ejemplo:** 50 preguntas reales de soporte con el artículo correcto — ¿con qué frecuencia está en el top 5?
- **Qué detecta:** Un mal modelo, un desajuste de dominio, problemas de chunking.
- **Relaciones:** Comprueba la **model choice**, **garbage in** y toda la cadena.

### Cómo se conectan los conceptos

> Una cinta transportadora: entra texto, y salen búsqueda, recomendaciones y grupos. Cada trampa es un lugar donde la cinta puede fallar.

Todo el curso es una sola cadena. **Texto limpio** entra en el **embedding model**, que devuelve **vectores**, que viven en una **vector database** con un índice **ANN**. Una consulta encuentra sus **vecinos más cercanos** por **cosine similarity** — y sobre esa sola operación se apoyan la **semantic search y el RAG**, las **recomendaciones**, el **clustering** y la **classification**. Las trampas están en los eslabones: **garbage in** en la entrada, **model mismatch** en el modelo, **similar ≠ relevant** en la búsqueda. Y los **embedding evals** miden toda la cadena.

_Diagram: Texto → modelo → vectores → base de datos → vecinos más cercanos → cada uso. En rojo: dónde falla._

#### Antes de construir sobre embeddings

- **¿La tarea trata de significado** — similitud, agrupación, retrieval — algo a lo que los embeddings de verdad encajan?
- **¿Es el modelo de embeddings adecuado** para tus datos, tu dominio y tu idioma?
- **¿Consulta y documentos pasan por el mismo modelo**, al mismo espacio?
- **¿Hay una vector database** con búsqueda aproximada para tu escala?
- **¿El texto que conviertes es limpio** y está bien dividido en fragmentos, sin ruido?
- **¿Has medido** que el espacio pone cerca las cosas correctas, con casos reales?

#### Señales de que usas bien los embeddings

- Recurres a los embeddings cuando la tarea trata de **significado**, no de coincidencia exacta.
- **Elegiste el modelo de embeddings** para tus datos y conviertes consulta y documentos **de la misma forma**.
- Usas una **vector database** con **búsqueda aproximada** a escala.
- Conviertes texto **limpio y bien dividido**, y tratas «similar» como un sustituto fuerte pero imperfecto de lo relevante.
- **Mediste** que el espacio refleja significado real, en lugar de darlo por hecho.

## Hoja de referencia: los 20 conceptos

### Fundamentos

- **Lexical Gap** (palabras vs significado): Mismo significado, otras palabras; el exact match no lo ve.
- **Embedding** (vector): Una lista de números — las coordenadas del significado de un texto.
- **Vector Space** (embedding space): Un mapa del significado: los puntos cercanos significan cosas parecidas; las preguntas de significado se vuelven preguntas de distancia.

### Similitud

- **Semantic Similarity** (similitud por significado): Cerca en significado = poca distancia entre vectores.
- **Nearest-Neighbour Search** (k-NN): Encontrar los k puntos más cercanos. La operación central.
- **Cosine Similarity** (basada en el ángulo): Similitud por ángulo: importa la dirección, no la longitud.

### La vector database

- **Vector Database** (vector store): Guarda vectores y encuentra rápido los más cercanos.
- **ANN** (vecino más cercano aproximado): Milisegundos entre millones, a cambio de una pizca de precisión.
- **Embed Once, Query Many** (index time / query time): Se paga una vez por hacer el embedding al principio; se busca barato en cada consulta.

### Semantic search

- **Semantic Search** (búsqueda por significado): Encontrar por significado, no por palabras clave.
- **Same Model, Same Space** (un solo modelo): Consulta y documentos con un mismo modelo, o las distancias no significan nada.
- **RAG Retrieval** (retrieval en el RAG): Los embeddings encuentran los fragmentos sobre los que el modelo construye su respuesta.

### Más allá de la búsqueda

- **Clustering & Deduplication** (agrupación, casi-duplicados): Los puntos cercanos forman un tema; los casi idénticos son duplicados.
- **Recommendations** («también te puede gustar»): Los vecinos más cercanos de lo que le gustó al usuario.
- **Classification & Anomaly Detection** (etiquetas y valores atípicos): Tomar la etiqueta de los vecinos más cercanos; lejos de lo normal es una anomalía.

### Las trampas

- **Model Mismatch** (el modelo no conoce el dominio): Un espacio distorsionado — las distancias mienten en silencio.
- **Similar ≠ Relevant** (reranking): Lo más cercano es lo más parecido, no lo más útil. El reranking ayuda.
- **Garbage In** (mala entrada): Los malos fragmentos y el ruido estropean todo el espacio.

### Usarlos bien

- **Model Choice** (elegir el modelo): Idioma, dominio, tamaño del vector, coste — y luego una prueba con tus propios datos.
- **Embedding Evals** (evaluación del retrieval): Pares «consulta → esperado»: la proporción de aciertos en el top-k.

> Los embeddings convierten el significado en coordenadas, y así la similitud se vuelve distancia. Úsalos bien eligiendo el modelo correcto, haciendo los embeddings de forma consistente, alimentándolos con texto limpio y midiendo que el espacio de verdad pone cerca las cosas parecidas.

Fin del curso exprés · 7 capítulos · 20 conceptos

Ahora viene la práctica: toma un pequeño conjunto de tus propios textos, conviértelos en embeddings y busca — dale una consulta con tus propias palabras y mira si los resultados más cercanos son los que de verdad significan lo mismo. Luego prueba un uso que no sea de búsqueda: agrúpalos por significado, o encuentra los casi-duplicados. La idea se vuelve concreta en el momento en que una búsqueda encuentra el documento correcto pese a no compartir ninguna palabra clave con tu consulta. Pero sostén una idea por encima de las demás: los embeddings convierten el significado en coordenadas, y una vez que el significado tiene coordenadas, «encuentra lo que es parecido» es solo geometría. Esa única traducción es el motor detrás de la búsqueda, el RAG, las recomendaciones y mucho más.
