La idea que mueve todo esto
Imagina un mapa en el que en vez de ciudades hay significados. Los puntos cercanos entre sí significan cosas parecidas.
El embedding es la operación que le da a un fragmento de texto sus coordenadas en ese mapa. La coordenada no son dos números, como en un mapa de verdad, sino varios cientos o unos miles — pero el principio es el mismo: los textos de significado parecido acaban cerca unos de otros.
A partir de ahí es sencillo. Cuando buscas algo, tu expresión de búsqueda se coloca en el mismo mapa y miras qué hay cerca. Eso es el vector search.
¿Por qué es mejor que la búsqueda por palabras clave?
Porque compara significados en lugar de palabras.
A la pregunta «cómo puedo rescindir el contrato», el buscador por palabras clave trae los párrafos que contienen la palabra «rescindir». El vector search encuentra además el que empieza «La declaración de voluntad dirigida a extinguir el acuerdo…» — aunque no comparta ni una sola palabra.
En una base de conocimiento de empresa esa diferencia no es un matiz, es la base entera del asunto. Tus documentos están escritos en el idioma del abogado, del ingeniero y del comercial; las preguntas las hacen los clientes, en el suyo.
¿Qué aspecto tiene en la práctica?
Cuatro pasos, y en los cuatro se puede fallar.
1. Troceado. Divides los documentos en fragmentos más pequeños. Un contrato de 40 páginas no tiene un único significado — el plazo de preaviso y la garantía son dos puntos distintos del mapa.
2. Incrustación. Pasas un modelo de embedding por cada fragmento y guardas la fila de números resultante.
3. Almacenamiento. Metes esas filas en una base de datos capaz de encontrar rápido los puntos más cercanos. Esa es la vector database.
4. Búsqueda. Calculas el embedding de la pregunta con el mismo modelo y recuperas los pocos fragmentos más cercanos.
Las cuatro trampas
1. El troceado lo decide todo
Es la fuente de fallo más frecuente y la menos visible. Si una misma idea se parte en dos fragmentos, ninguno de los dos será una buena respuesta — y el buscador considerará flojos a los dos.
Regla práctica: que los límites del fragmento sigan la estructura del documento — un párrafo, un título de sección, un elemento de lista — y no un número fijo de caracteres. Y que los fragmentos vecinos se solapen, para que la frase que queda en el límite sobreviva en los dos.
2. La búsqueda y el almacenamiento necesitan el mismo modelo
Si llenaste la base de datos con un modelo de embedding, la pregunta hay que incrustarla con ese mismo modelo. Dos modelos distintos dibujan dos mapas distintos, y las coordenadas no tienen nada que ver entre sí.
De ahí sale una consecuencia de explotación: si cambias de modelo de embedding, hay que reconstruir toda la base de datos. Conviene preverlo, porque no es un trabajo pequeño.
3. Fuera del inglés no funciona solo
No todos los modelos de embedding son multilingües, y los que lo son no son igual de fuertes en todos los idiomas. Antes de construir nada, pruébalo con texto en tu idioma: coge veinte pares de pregunta y párrafo donde sepas la respuesta correcta y mira si los encuentra.
Puede perfectamente ocurrir que un modelo pensado para el inglés rinda peor en tu idioma que otro más pequeño pero explícitamente multilingüe. Esto no va de tamaño.
4. El significado por sí solo no basta
El vector search busca por significado, y eso lo hace malo con los identificadores exactos: números de artículo, números de pedido, referencias normativas, fechas. Para eso la vieja búsqueda por palabras clave es más precisa.
La solución no es elegir, sino sumar: hybrid search — búsqueda por palabras clave y por significado a la vez, fusionando los resultados. En la mayoría de los sistemas ese único cambio es el que más mejora.
¿Dónde conecta todo esto con la IA?
El embedding y el vector search no son tecnología generativa — no escriben nada, solo encuentran. El modelo de lenguaje entra cuando redacta una respuesta a partir de los fragmentos recuperados. A esa pareja la llamamos RAG, y tiene artículo propio: Fine-tuning, RAG o mejor prompt
Conviene tenerlos separados en la cabeza, porque la mayoría de las respuestas malas no son culpa del modelo, sino de la búsqueda. Si le das el párrafo equivocado, ni el mejor modelo puede sacar de ahí una buena respuesta.
Una prueba de media jornada antes de construir nada
Coge treinta preguntas reales que hayan hecho de verdad tus clientes o tus compañeros. Anota para cada una en qué documento y en qué párrafo está la respuesta.
Después monta un índice sencillo y comprueba: ¿en cuántos casos está el párrafo correcto entre los cinco primeros?
Si esa cifra está por debajo del ochenta por ciento, no sigas hacia el modelo de lenguaje — primero hay que arreglar la búsqueda. Si está por encima, lo difícil ya ha pasado.
Qué llevarte
El embedding convierte el significado en números y el vector search busca dentro de eso. El ochenta por ciento de la calidad de un sistema RAG depende del troceado y de la recuperación, no de la generación — y por eso es en esos dos pasos donde hay que invertir el tiempo.