Para buscar por significado y no por palabras clave, primero se parten los documentos en fragmentos y se convierte cada uno en un embedding: un punto en un espacio de alta dimensión donde los textos de sentido parecido quedan cerca. Esos vectores se guardan en un índice. Cuando llega una consulta, se la convierte en vector con el mismo modelo y se buscan sus vecinos más cercanos, por ejemplo con similitud coseno (Alammar y Grootendorst, 2024, pp. 228–230).
Con miles de vectores alcanza con calcular todas las distancias. Con millones, se usan bibliotecas de búsqueda aproximada de vecinos, como Annoy o FAISS, que devuelven resultados en milisegundos a cambio de no garantizar el vecino exacto. Las bases de datos vectoriales propiamente dichas (Weaviate, Pinecone y otras) agregan lo que se espera de una base de datos: añadir y borrar vectores sin reconstruir el índice, y filtrar por otros criterios (Alammar y Grootendorst, 2024, pp. 238–239). El sistema RAG original usaba un índice FAISS con 21 millones de fragmentos de Wikipedia (P. Lewis et al., 2020, sec. 3). Hoy son la infraestructura típica del aumento por recuperación y de la búsqueda semántica, con modelos como Sentence-BERT para generar los vectores.
Para un lógico, el contraste con una base de datos clásica es instructivo. Una consulta SQL es, en el fondo, una fórmula de lógica de primer orden: devuelve exactamente las filas que la satisfacen, y la respuesta es verdadera o falsa para cada una. Una consulta vectorial no tiene condiciones de verdad: devuelve lo más parecido, siempre devuelve algo, y «parecido» está definido por la geometría que aprendió un modelo. Es una teoría del significado como posición y distancia (hipótesis distribucional), con las virtudes y los riesgos de la similitud: dos textos pueden estar cerca porque dicen lo mismo o porque dicen lo contrario sobre el mismo tema.