Bases de datos vectoriales, embeddings y reranking: tres partes diferentes de la recuperación

Los embeddings, las bases de datos vectoriales y los rerankers son tres partes diferentes de la recuperación. Un modelo de embedding convierte texto u otros datos en representaciones numéricas; una base de datos vectorial o un índice vectorial almacena y busca esas representaciones para recuperar elementos candidatos; un reranker toma un conjunto más pequeño de candidatos y lo reordena usando un modelo de relevancia o método de puntuación más costoso. A menudo aparecen juntos en RAG, pero ninguno de ellos es lo mismo que RAG, y ninguno es obligatorio en todos los sistemas de recuperación.

Qué significa esto realmente

Los sistemas de búsqueda tienen dos objetivos en competencia: encontrar suficiente material potencialmente relevante y colocar el mejor material cerca de la parte superior. La recuperación rápida de primera etapa normalmente optimiza la generación de candidatos. Un modelo de segunda etapa más fuerte puede entonces gastar más cómputo distinguiendo los mejores candidatos.

Los embeddings, los índices vectoriales y los rerankers ocupan posiciones diferentes en ese proceso. Tratarlos como una sola característica oculta decisiones de diseño importantes sobre recall, precisión, latencia, almacenamiento, filtrado de metadatos y costo del modelo.

La distinción también evita un error común de RAG: asumir que almacenar embeddings de documentos en una base de datos vectorial crea automáticamente una recuperación de alta calidad. La calidad de la recuperación depende del modelo de embedding, el chunking, los metadatos, la construcción de la consulta, la configuración del índice, el número de candidatos, la recuperación híbrida, el reranking y la autoridad de las fuentes subyacentes.

El ejemplo más simple

Supongamos que una base de conocimiento contiene 100.000 fragmentos de documentos. Un usuario pregunta: “¿Cómo revoco un token de API?”

Primero, un modelo de embedding puede codificar la consulta en un vector. Los fragmentos de documentos pueden tener ya sus propios embeddings almacenados. Una búsqueda vectorial entonces compara el vector de la consulta con los vectores de documentos indexados y devuelve, por ejemplo, 30 candidatos probables.

Esos 30 candidatos pueden entonces pasarse a un reranker. El reranker compara la consulta más directamente con cada candidato y produce un nuevo orden de relevancia. La aplicación podría conservar los cinco mejores para el contexto del modelo.

Dónde se detiene el ejemplo simple

Los sistemas de recuperación reales no tienen que usar embeddings densos en absoluto. La búsqueda por palabras clave como BM25 puede ser el recuperador de primera etapa. La recuperación dispersa aprendida, los filtros SQL, el recorrido de grafos o las APIs de aplicación también pueden generar candidatos.

A un reranker tampoco le importa que los candidatos provengan de una base de datos vectorial. Puede reordenar resultados de BM25, resultados híbridos, documentos seleccionados manualmente o candidatos de múltiples recuperadores.

Del mismo modo, los embeddings no requieren una base de datos vectorial especializada. Los conjuntos de datos pequeños pueden compararse en memoria o con bases de datos de propósito general y extensiones vectoriales. Los sistemas vectoriales especializados resultan útiles cuando la indexación, la búsqueda aproximada de vecinos más cercanos, el filtrado, la escala, el comportamiento de actualización o los requisitos operativos lo justifican.

Embeddings: representación, no recuperación

Un embedding es una representación numérica producida por un modelo. Para la recuperación semántica, se pretende que los textos con significado relacionado ocupen posiciones útiles en un espacio vectorial para que una función de similitud o distancia pueda compararlos.

Sentence-BERT fue un paso influyente para hacer práctica la similitud semántica a nivel de oración con representaciones de estilo bi-encoder que pueden calcularse de forma independiente y compararse eficientemente. La idea general sigue siendo central para la recuperación densa moderna: precalcular las representaciones de los documentos, calcular la representación de la consulta en el momento de la búsqueda y luego compararlas.

El embedding en sí no busca en un corpus. Son datos producidos por un modelo de embedding. La recuperación comienza cuando el sistema compara la representación de la consulta con los candidatos almacenados.

El modelo de embedding define el espacio de representación

Los vectores de documentos y consultas deben ser compatibles con el modelo y la configuración utilizados para crearlos. Reemplazar un modelo de embedding puede cambiar la dimensionalidad, el comportamiento de similitud, la cobertura de idiomas y el rendimiento en el dominio.

Por eso una migración de modelo de embedding no es simplemente un cambio de nombre de API. Es posible que los documentos existentes deban volver a incrustarse y que el índice se reconstruya o se versione.

Las representaciones densas y dispersas son diferentes

Los embeddings densos suelen contener muchas dimensiones distintas de cero y se usan comúnmente para similitud semántica. Las representaciones dispersas contienen muchos ceros y pueden preservar una estructura más fuerte similar a tokens o términos.

Ambas pueden admitir recuperación semántica, y los sistemas de búsqueda modernos pueden combinar señales densas, dispersas y léxicas. Por lo tanto, “búsqueda vectorial” no siempre significa una única canalización de similitud coseno densa.

Las funciones de similitud son parte del contrato de representación

La similitud coseno, el producto punto y la distancia euclidiana no significan lo mismo. La métrica correcta depende de cómo se entrenó y normalizó el modelo de embedding.

La documentación actual de Qdrant, por ejemplo, requiere una métrica de distancia como parte de la configuración vectorial y documenta opciones de coseno, producto punto y estilo euclidiano. La regla arquitectónica importante es tratar la métrica como parte del contrato de embedding/índice en lugar de elegir una arbitrariamente.

Bases de datos vectoriales e índices: recuperación de candidatos

Una base de datos vectorial o un sistema de búsqueda con capacidad vectorial organiza las representaciones vectoriales para que la aplicación pueda recuperar candidatos cercanos de manera eficiente. Los sistemas prácticos suelen asociar vectores con IDs y metadatos de carga útil como fuente, idioma, inquilino, tipo de documento, marca de tiempo o alcance de acceso.

Qdrant, por ejemplo, organiza los datos en colecciones de puntos donde un punto contiene un vector y metadatos de carga útil opcionales. Su documentación describe la búsqueda por similitud basada en HNSW y el filtrado de metadatos como capacidades separadas de la capa de recuperación.

Esa distinción importa: el índice vectorial responde a un problema de vecino más cercano, mientras que los filtros de carga útil imponen restricciones estructurales como inquilino, clase de documento o idioma.

La búsqueda aproximada de vecinos más cercanos intercambia exactitud por eficiencia

Comparar un vector de consulta contra cada vector puede ser práctico para colecciones pequeñas pero costoso a gran escala. Los índices de vecinos más cercanos aproximados como HNSW reducen el costo de búsqueda navegando una estructura de índice en lugar de escanear exhaustivamente cada vector.

La búsqueda aproximada introduce una compensación entre exhaustividad y latencia. Una búsqueda más rápida puede omitir candidatos que la búsqueda exacta devolvería. Por lo tanto, los parámetros del índice afectan la calidad de recuperación, no solo el rendimiento de la infraestructura.

Qdrant expone tanto parámetros relacionados con HNSW como una opción de búsqueda exacta, lo que ilustra que el almacenamiento vectorial y la política de recuperación aproximada son decisiones separadas.

El filtrado de metadatos pertenece antes o durante la recuperación de candidatos

Si el usuario solo puede acceder al inquilino A, recuperar fragmentos semánticamente similares del inquilino B e intentar eliminarlos después es el límite de seguridad incorrecto. La autorización y los filtros de elegibilidad estricta deben restringir el espacio de candidatos antes de que esos candidatos puedan influir en el procesamiento posterior.

El mismo principio se aplica a la configuración regional, el estado del documento, la clase de origen, la fecha, la versión del producto y otras restricciones deterministas. La similitud debe clasificar a los candidatos elegibles; no debe anular la elegibilidad.

Una base de datos vectorial es opcional

Para un corpus pequeño, la comparación de similitud del coseno por fuerza bruta puede ser simple y suficiente. Una base de datos relacional con soporte vectorial también puede ser adecuada. Una base de datos vectorial dedicada se vuelve valiosa cuando su indexación, filtrado, almacenamiento distribuido, comportamiento de actualización o características operativas resuelven un requisito real.

Elegir una base de datos vectorial porque “RAG necesita una” invierte el proceso de arquitectura. Comience con los requisitos de recuperación y la escala, luego seleccione la tecnología de almacenamiento/índice.

Reclasificación: refinamiento de relevancia en segunda etapa

Un reclasificador recibe una consulta y un conjunto más pequeño de candidatos ya recuperados, luego asigna puntuaciones de relevancia más fuertes o un nuevo orden. Normalmente es más costoso computacionalmente que la recuperación de primera etapa, por lo que se aplica después de la generación de candidatos en lugar de a todo el corpus.

La guía actual de Elastic describe la reclasificación semántica como una técnica de etapa final sobre un pequeño conjunto top-k y señala que puede refinar la recuperación léxica, semántica o híbrida. Cohere documenta la misma arquitectura: búsqueda léxica o semántica de primera etapa seguida de una etapa de reclasificación.

Una implementación común utiliza un modelo similar a un codificador cruzado que examina la consulta y cada candidato juntos. Esa interacción más rica puede distinguir la relevancia con mayor precisión que la similitud de incrustación independiente, pero es mucho más costosa a escala de corpus.

La recuperación con bi-codificador y la reclasificación con codificador cruzado resuelven diferentes problemas de costo

Un reclasificador no puede recuperar lo que la recuperación omitió

Si el documento relevante está ausente del conjunto de candidatos, el reranking no tiene nada que promover. Esta es la razón central para evaluar la recuperación y el reranking por separado.

Un pipeline puede tener una precisión excelente en el reranker y aun así fallar porque la recuperación de la primera etapa es deficiente. Aumentar la calidad del reranker no reparará la cobertura de origen faltante, un chunking deficiente, filtros restrictivos o un recuperador de candidatos débil.

La recuperación híbrida es una decisión de diseño aparte

La recuperación semántica densa es fuerte cuando la consulta y el documento usan un vocabulario diferente pero expresan un significado relacionado. La recuperación léxica es fuerte cuando importan los términos exactos, identificadores, nombres, códigos o frases poco comunes.

La recuperación híbrida combina múltiples señales de candidatos, a menudo BM25 léxico y similitud vectorial, y luego fusiona los rankings usando un método como Reciprocal Rank Fusion o una combinación de puntuaciones ponderadas.

El reranking puede entonces operar sobre el conjunto de candidatos fusionado. La recuperación híbrida y el reranking son, por lo tanto, etapas complementarias pero distintas.

BM25 no está obsoleto porque existan los embeddings

La búsqueda por palabras clave puede superar a la recuperación densa para identificadores exactos, números de versión, mensajes de error, códigos de producto y vocabulario especializado. SQLite FTS5, por ejemplo, incluye una función de ranking BM25 para búsqueda de texto completo.

Una arquitectura de recuperación sólida puede usar la recuperación léxica como única primera etapa, la recuperación vectorial como única primera etapa, o combinar ambas según el corpus y la distribución de consultas.

El chunking cambia lo que los embeddings y los rerankers pueden ver

Si un documento se divide mal, ningún componente de recuperación posterior puede reconstruir completamente la unidad semántica faltante. Un chunk que separa una condición de su excepción puede generar un embedding engañoso y también puede ser rerankeado incorrectamente porque el texto candidato está incompleto.

El tamaño del chunk, el solapamiento, los límites estructurales y los metadatos afectan tanto la recuperación de candidatos como el juicio del reranker. La evaluación de la recuperación debe probar el pipeline completo desde la ingesta hasta el ranking, no solo el modelo de embeddings.

No compares las puntuaciones de recuperación como si fueran probabilidades universales

La similitud del coseno, las puntuaciones BM25, las puntuaciones de vectores dispersos, los rangos RRF y las puntuaciones del reranker tienen significados diferentes. Una puntuación de 0.82 de un modelo de embeddings no es automáticamente comparable con 0.82 de otro modelo ni con una puntuación de un reranker.

Los umbrales deben calibrarse para el modelo, el corpus y la tarea reales. La guía actual de Elastic también señala que las puntuaciones de similitud de embeddings pueden depender de la consulta, lo que hace arriesgados los cortes universales.

Evalúa las etapas de recuperación por separado

Esta separación es operativamente importante. Si Recall@50 es deficiente, el reranker no es el primer componente a corregir. Si Recall@50 es fuerte pero el mejor pasaje permanece en el rango 38, el reranking o la fusión de rankings se convierte en un objetivo plausible.

¿Qué capa falló realmente?

Relevancia y Fuente de Verdad son diferentes

Un reranker puede hacer que un documento obsoleto parezca extremadamente relevante. Un índice vectorial puede recuperar un resumen secundario que es semánticamente más cercano que la fuente primaria. Por lo tanto, la calidad de la recuperación no puede reemplazar las reglas de autoridad.

Donde la autoridad de la fuente importa, los filtros de metadatos, las clases de fuente, las reglas de versión y la procedencia deben restringir la recuperación antes de que el resultado se convierta en contexto del modelo.

Evidencia de implementación original

Motor de Investigación de Fuente de Verdad: la recuperación léxica y semántica están separadas

El Motor de Investigación de Fuente de Verdad contiene una ruta de recuperación léxica local usando SQLite FTS5/BM25 y una ruta de recuperación semántica opcional separada usando embeddings generados localmente.

Su implementación de búsqueda semántica calcula un vector de consulta y lo compara con vectores de fragmentos almacenados usando similitud coseno. El proyecto trata deliberadamente la similitud semántica como una señal de descubrimiento en lugar de evidencia: un candidato aún debe rastrearse hasta una fuente y localizador concretos antes de respaldar una afirmación.

Esta es evidencia de implementación útil para R01 porque el mismo corpus puede soportar ranking léxico y similitud vectorial sin confundir ninguno de los dos mecanismos con autoridad probatoria.

Cliente de IA Aaasaasa: Qdrant es un componente de infraestructura vectorial

El Cliente de IA Aaasaasa incluye Qdrant/infraestructura vectorial como un recurso local separado. La arquitectura de Electron expone los servicios de Qdrant desde el lado confiable del proceso principal en lugar de tratar la búsqueda vectorial como parte del modelo mismo.

El repositorio contiene un adaptador de cliente Qdrant, configuración de servicio Qdrant e infraestructura Qdrant basada en Docker. Esto demuestra la separación arquitectónica entre la ejecución del proveedor/modelo de IA y el almacenamiento/búsqueda vectorial.

La existencia de soporte para Qdrant no debe exagerarse como un pipeline RAG de producción completo. La evidencia aquí es más limitada: la infraestructura vectorial está implementada como su propio límite de componente.

¿Cuándo necesitas cada componente?

Una secuencia práctica de diseño de recuperación

Conceptos erróneos comunes

Casos límite y limitaciones

Algunas aplicaciones no necesitan búsqueda semántica. La búsqueda exacta en base de datos o SQL estructurado puede ser más correcta, más rápida y más fácil de auditar que la recuperación por embeddings.

Algunos corpus son tan pequeños que un escaneo vectorial completo es aceptable. La indexación aproximada añade complejidad sin un beneficio significativo.

Algunas consultas requieren un recall alto antes de cualquier optimización de precisión. La discovery legal, la investigación y la revisión de cumplimiento pueden preferir una recuperación amplia de candidatos seguida de un filtrado transparente y revisión humana.

La recuperación multilingüe y específica del dominio puede comportarse de manera muy diferente entre modelos de embedding. Las afirmaciones de benchmark de conjuntos de datos públicos no deben tratarse como prueba para un corpus privado.

La latencia del reranking crece con el número y la longitud de los candidatos. Por lo tanto, el tamaño de candidatos debe ajustarse como una variable de precisión/coste/latencia en lugar de copiarse de un tutorial.

¿Qué cambiaría esta respuesta?

Los límites de los componentes no cambiarían si un proveedor empaqueta la generación de embeddings, la indexación vectorial y el reranking detrás de una sola API. El producto puede ocultar las etapas, pero siguen siendo responsabilidades conceptualmente diferentes con modos de fallo diferentes.

Los futuros modelos de embedding o recuperación pueden reducir la necesidad de un reranking separado en algunas cargas de trabajo, mientras que métodos más fuertes de interacción tardía o dispersos aprendidos pueden difuminar las categorías tradicionales denso/léxico. La arquitectura aún debería preguntar qué etapa produce representaciones, qué etapa genera candidatos y qué etapa refina el ranking.

El mejor diseño también cambia con el tamaño del corpus, la mezcla de consultas, el idioma, la terminología del dominio, la frecuencia de actualización, la autoridad de la fuente, el presupuesto de latencia y los resultados de evaluación.

Conocimiento canónico relacionado

R01 asume que el concepto básico de RAG ya se entiende. RAG es el patrón más amplio en el que se proporciona información externa recuperada a un modelo; los embeddings, la búsqueda vectorial y el reranking son componentes de recuperación opcionales dentro de ese patrón.

Cuando la recuperación falla, diagnostica por separado la cobertura de fuentes, la recuperación, el ranking, el ensamblaje del contexto y la generación, en lugar de tratar todo el sistema como un único “fallo de RAG”.

La arquitectura de fuente de verdad es la capa de autoridad en torno a la recuperación: decide qué fuente puede establecer una afirmación, mientras que los embeddings y el ranking solo deciden qué candidatos parecen relevantes.

Preguntas frecuentes

Glosario

Conclusión

El modelo de recuperación claro es simple: los embeddings representan significado, la búsqueda vectorial recupera candidatos y los rerankers refinan el orden de los candidatos.

Una vez que esos límites son explícitos, las decisiones de arquitectura se vuelven más fáciles de diagnosticar. Los candidatos faltantes apuntan hacia la cobertura de fuentes, el chunking, los embeddings, los filtros o la recuperación de primera etapa. El mal orden apunta hacia el ranking, la fusión o el reranking. Las respuestas finales incorrectas pueden investigarse entonces por separado en las capas de contexto y generación.

El resultado más importante no es elegir el componente de recuperación más de moda. Es construir un pipeline de recuperación cuyas etapas, límites de autoridad, métricas y modos de fallo puedan medirse de forma independiente.

Fuentes primarias y evidencia de implementación

Las referencias externas a continuación documentan los mecanismos de representación, búsqueda vectorial y reranking usados en este artículo. Las secciones específicas del proyecto son evidencia de implementación original y son intencionalmente más limitadas que las afirmaciones sobre una madurez completa de RAG en producción.