Vector databases: guía para principiantes

Son el componente clave de RAG, búsqueda semántica, sistemas de recomendación y cualquier aplicación que necesite encontrar información "parecida" en lugar de "idéntica".

Embeddings: de texto a números

Para que una máquina entienda la similitud entre textos, necesitamos convertir texto en números. Eso son los embeddings: vectores de 256 a 3072 dimensiones que capturan el significado semántico.

Ejemplo simplificado: "gato" → [0.8, 0.2, 0.1], "felino" → [0.79, 0.21, 0.12], "coche" → [0.1, 0.9, 0.3]. "Gato" y "felino" están cerca en el espacio vectorial. "Coche" está lejos.

# Generar embeddings con OpenAI
from openai import OpenAI
client = OpenAI()

response = client.embeddings.create(
 model="text-embedding-3-small",
 input=["IA para recursos humanos",
 "inteligencia artificial en RRHH",
 "receta de paella valenciana"]
)

# Los 2 primeros vectores estarán cerca
# El tercero estará lejos
for i, emb in enumerate(response.data):
 print(f"Texto {i}: vector de {len(emb.embedding)} dimensiones")

Cómo funcionan los embeddings (explicación simple)

Imagina un mapa de tu ciudad. Cada punto del mapa representa una dirección. Los sitios que están cerca en el mapa también están cerca en la realidad. Los embeddings hacen lo mismo, pero con significados en lugar de ubicaciones.

Un modelo de embedding (como text-embedding-3-small de OpenAI o BGE-M3 open source) lee un texto y lo convierte en una lista de números. Esa lista es un punto en un espacio de muchas dimensiones. Textos con significados similares producen puntos cercanos.

El proceso concreto funciona así:

1. Tokenización: el texto se divide en tokens (fragmentos de palabras). "Inteligencia artificial" puede ser 3-4 tokens.
2. Encoding: cada token pasa por las capas del modelo transformer, que capturan relaciones entre palabras.
3. Pooling: la última capa se comprime en un solo vector que representa todo el texto. Esto es el embedding.
4. Normalización: el vector se normaliza para que las comparaciones por distancia sean consistentes.

La "magia" está en el paso 2. El transformer ha sido entrenado con millones de textos para aprender que "IA en recursos humanos" e "inteligencia artificial aplicada a RRHH" significan lo mismo, aunque las palabras sean diferentes.

Dimensiones: cuántas y por qué. Un embedding de 1536 dimensiones significa que cada texto se representa como una lista de 1536 números. Más dimensiones capturan más matices, pero consumen más memoria y son más lentos de comparar. Para la mayoría de aplicaciones, 768-1536 dimensiones es el punto óptimo.

Búsqueda semántica vs keyword

Con búsqueda por keyword, si buscas "automatizar procesos" no encontrarás un documento que dice "optimizar flujos de trabajo con IA". Son palabras diferentes. Con búsqueda semántica, sí lo encuentras, porque el significado es similar.

La búsqueda semántica entiende sinónimos, paráfrasis e incluso conceptos relacionados. No es perfecta (a veces el keyword search es más preciso para términos técnicos exactos), pero para la mayoría de casos de uso es superior.

Hybrid search: lo mejor de ambos mundos. La búsqueda híbrida combina vectores (semántica) con BM25 (keywords). Cuando un usuario busca "error 503 nginx", la búsqueda semántica puede devolver documentos sobre errores HTTP genéricos. La búsqueda por keyword encuentra exactamente "error 503 nginx". Hybrid search combina ambas señales para el mejor resultado. Qdrant y Weaviate lo soportan nativamente con sparse vectors.

Casos de uso

RAG: el caso de uso principal. Almacenas tus documentos como vectores y recuperas los más relevantes para cada pregunta. Lee la guía completa de RAG.

Búsqueda interna: un buscador para tu documentación, wiki o base de conocimiento que entiende preguntas en lenguaje natural.

Recomendaciones: "productos similares a este", "artículos relacionados", "candidatos con perfil parecido".

Deduplicación: encontrar documentos duplicados o casi-duplicados sin comparación exacta de texto.

Detección de anomalías: identificar textos que no encajan con el patrón general (fraude, spam, contenido fuera de tema).

Comparativa de opciones

Qdrant: open source, self-hosted o cloud. Mejor rendimiento en benchmarks, filtros avanzados, soporte nativo de sparse vectors (hybrid search). Cloud desde 25 USD/mes. Self-hosted: gratis.

Pinecone: solo cloud (managed). El más fácil de empezar. Free tier (100K vectores). Starter 70 USD/mes. Sin opción self-hosted.

ChromaDB: open source, embeddable. Ideal para prototipos y desarrollo. Funciona en memoria o con persistencia local. Sin cloud managed.

Weaviate: open source + cloud. Vectorización integrada (no necesitas generar embeddings aparte). Cloud desde 25 USD/mes.

pgvector: extensión de PostgreSQL. Si ya usas Postgres (Supabase, por ejemplo), añades búsqueda vectorial sin nueva infraestructura. Rendimiento inferior para millones de vectores.

Cuándo usar cuál: guía de decisión

La elección depende de tres factores: volumen de datos, requisitos de infraestructura y fase del proyecto.

Prototipo o MVP (menos de 100K documentos)

Usa ChromaDB. Cero configuración, funciona en memoria, instalación con pip. Cuando el prototipo funcione y necesites escalar, migras. El esfuerzo de migración es mínimo porque la interfaz de LangChain/LlamaIndex abstrae la base de datos.

Ya usas PostgreSQL (Supabase, RDS, etc.)

Empieza con pgvector. No añades infraestructura nueva, tus vectores viven junto a tus datos relacionales, y las queries pueden combinar filtros SQL con búsqueda semántica. Funciona bien hasta 1-2 millones de vectores. Si llegas ahí, ya tienes ingresos para pagar una base vectorial dedicada.

Producción con escala (millones de vectores)

Elige entre Qdrant (self-hosted si quieres control total, cloud si prefieres managed) y Pinecone (si priorizas simplicidad sobre control). Qdrant gana en rendimiento y coste. Pinecone gana en facilidad operativa.

Datos sensibles o soberanía

Si tus datos no pueden salir de tu infraestructura (regulación, compliance, política interna), la opción es Qdrant self-hosted o pgvector. Pinecone no tiene opción self-hosted. Weaviate sí, pero Qdrant tiene mejor rendimiento en benchmarks independientes.

Necesitas hybrid search

Qdrant con sparse vectors o Weaviate con BM25 integrado. ChromaDB y pgvector no soportan hybrid search nativo (tendrías que implementarlo a mano).

Ejemplo práctico

# RAG mínimo con Qdrant + LangChain
from langchain_community.vectorstores import Qdrant
from langchain_openai import OpenAIEmbeddings
from langchain_core.documents import Document

# Documentos de ejemplo
docs = [
 Document(page_content="La IA en RRHH automatiza "
 "el screening de CVs y mejora la selección."),
 Document(page_content="Los agentes de IA ejecutan "
 "tareas de forma autónoma usando herramientas."),
 Document(page_content="RAG combina búsqueda "
 "y generación para respuestas precisas."),
]

# Crear vector store
vectorstore = Qdrant.from_documents(
 docs,
 OpenAIEmbeddings(),
 location=":memory:", # Para desarrollo
 collection_name="mi_coleccion",
)

# Buscar
resultados = vectorstore.similarity_search(
 "¿Cómo seleccionar candidatos con inteligencia artificial?",
 k=2
)
for doc in resultados:
 print(doc.page_content)

Setup práctico: de cero a búsqueda semántica en 15 minutos

Este tutorial usa ChromaDB (cero dependencias externas) para que puedas tener una búsqueda semántica funcionando en tu máquina en 15 minutos.

Paso 1: Instalación

# Instalar ChromaDB y un modelo de embeddings local
pip install chromadb sentence-transformers

Paso 2: Crear la colección e indexar documentos

import chromadb
from chromadb.utils import embedding_functions

# Usar modelo de embeddings local (gratis, sin API key)
ef = embedding_functions.SentenceTransformerEmbeddingFunction(
    model_name="all-MiniLM-L6-v2"
)

# Crear cliente con persistencia local
client = chromadb.PersistentClient(path="./mi_vector_db")
collection = client.get_or_create_collection(
    name="documentos",
    embedding_function=ef
)

# Indexar documentos
collection.add(
    documents=[
        "La IA generativa crea texto, imágenes y código a partir de instrucciones.",
        "RAG combina búsqueda en documentos con generación de texto por LLM.",
        "Los agentes de IA pueden ejecutar tareas complejas de forma autónoma.",
        "Fine-tuning ajusta un modelo preentrenado con datos específicos de tu dominio.",
        "Los embeddings convierten texto en vectores numéricos para búsqueda semántica.",
    ],
    ids=["doc1", "doc2", "doc3", "doc4", "doc5"],
    metadatas=[
        {"categoria": "fundamentos"},
        {"categoria": "rag"},
        {"categoria": "agentes"},
        {"categoria": "entrenamiento"},
        {"categoria": "vectores"},
    ]
)

Paso 3: Buscar por significado

# Búsqueda semántica
resultados = collection.query(
    query_texts=["¿Cómo personalizar un modelo de lenguaje?"],
    n_results=2
)

for doc, dist in zip(resultados["documents"][0], resultados["distances"][0]):
    print(f"Distancia: {dist:.4f} | {doc}")

# Output esperado:
# Distancia: 0.8234 | Fine-tuning ajusta un modelo preentrenado...
# Distancia: 1.1456 | RAG combina búsqueda en documentos...

La búsqueda por "personalizar un modelo de lenguaje" encuentra el documento sobre fine-tuning (personalización de modelos) sin que las palabras coincidan. Eso es búsqueda semántica.

Paso 4: Filtrar con metadatos

# Buscar solo en documentos de una categoría
resultados = collection.query(
    query_texts=["automatización de tareas"],
    n_results=2,
    where={"categoria": "agentes"}
)

# Solo devuelve documentos con categoria="agentes"

Los metadatos son esenciales en producción. Te permiten filtrar por fecha, autor, tipo de documento, idioma, o cualquier atributo antes de la búsqueda semántica. Esto reduce el espacio de búsqueda y mejora la relevancia.

Integración con RAG: el flujo completo

La vector database es solo una pieza del pipeline de RAG. El flujo completo tiene 4 fases:

Fase 1: Ingesta (una vez)

1. Cargar documentos (PDFs, markdown, HTML, CSV)
2. Dividirlos en chunks (fragmentos de 200-500 tokens)
3. Generar embeddings de cada chunk
4. Almacenar vectores + metadatos en la vector database

El chunking es la decisión más crítica. Chunks demasiado pequeños pierden contexto. Chunks demasiado grandes incluyen información irrelevante. El tamaño óptimo depende del tipo de documento: 300 tokens para FAQs, 500 tokens para documentación técnica, 200 tokens para código.

Fase 2: Retrieval (cada consulta)

1. El usuario hace una pregunta
2. Se genera el embedding de la pregunta
3. Se buscan los K chunks más similares en la vector database
4. Se aplican filtros de metadatos si aplica

Fase 3: Augmentation

Los chunks recuperados se inyectan en el prompt del LLM como contexto. El prompt típico:

Responde la pregunta basándote SOLO en el contexto proporcionado.
Si la respuesta no está en el contexto, di "No tengo información sobre eso."

Contexto:
{chunks_recuperados}

Pregunta: {pregunta_del_usuario}

Fase 4: Generation

El LLM genera la respuesta usando el contexto. Al tener información específica y actualizada, reduce las alucinaciones y produce respuestas más precisas que un LLM solo.

Siguiente paso

Si es tu primer proyecto con vectores, usa ChromaDB (cero setup). Cuando necesites producción, migra a Qdrant (mejor rendimiento) o pgvector (si ya usas Postgres). Para el tutorial completo de integración, revisa el tutorial de LangChain.

Preguntas frecuentes

Cómo funcionan los embeddings?

Un modelo de embedding (un transformer entrenado para esta tarea) lee un texto y produce una lista de números (el vector). Textos con significados similares producen vectores cercanos en el espacio matemático. La distancia entre vectores se mide con coseno o producto escalar. No necesitas entender la matemática para usarlos: las bibliotecas lo abstraen.

Puedo usar pgvector en lugar de una base de datos vectorial dedicada?

Sí, si ya usas PostgreSQL y tu volumen es menor a 1-2 millones de vectores. pgvector simplifica tu infraestructura al no añadir un servicio nuevo. Con Supabase, activar pgvector es un solo comando. La migración a una base dedicada es sencilla si llegas a necesitarla, porque la interfaz de búsqueda es similar.

Qué es hybrid search y cuándo usarlo?

Hybrid search combina búsqueda semántica (vectores) con búsqueda por keywords (BM25). Úsalo cuando tu contenido tenga términos técnicos específicos (códigos de error, nombres de producto, identificadores) donde la coincidencia exacta importa, pero también quieras encontrar sinónimos y conceptos relacionados. Qdrant soporta hybrid search con sparse vectors. Weaviate lo soporta con BM25 integrado.

Cuánto cuesta mantener una vector database en producción?

ChromaDB y pgvector son gratis (self-hosted). Qdrant cloud empieza en 25 USD/mes para clusters pequeños. Pinecone en 70 USD/mes (Starter). El coste principal no es la base de datos, sino los embeddings: text-embedding-3-small de OpenAI cuesta 0.02 USD por millón de tokens. Para 100K documentos de tamaño medio, la indexación inicial cuesta menos de 5 USD. Los modelos open source (BGE-M3, all-MiniLM) son gratis si los ejecutas en tu infraestructura.