tecnología · intermedio · 6 min de lectura

Bases de datos vectoriales

Una base de datos vectorial almacena embeddings e índices de similitud para recuperar contenido semánticamente cercano en RAG, búsqueda y memoria de aplicaciones IA.

Antes de leer esto, conviene conocer: Embeddings.

Cubre

vector databases as systems for storing embeddings and retrieving nearby vectors by similarity
indexes, metadata filters, namespaces or collections, top-k retrieval, hybrid search, and operational trade-offs at a conceptual level
practical fit for RAG, semantic search, recommendations, memory, and deduplication workflows

No cubre

implementation internals of ANN algorithms such as HNSW or IVF
vendor-specific SDK tutorials
full benchmark methodology for recall, latency, and cost

Supone

The reader understands embeddings, documents, APIs, and the high-level RAG flow.

Resumen

Una base de datos vectorial es un sistema diseñado para guardar vectores —normalmente embeddings— y encontrar rápidamente los más parecidos a una consulta. En vez de buscar solo por coincidencia exacta de palabras, compara posiciones en un espacio vectorial: documentos, preguntas o productos con significado similar quedan cerca.

Importa porque muchas aplicaciones IA necesitan recuperar contexto antes de responder. En RAG, por ejemplo, no basta con tener documentos: hay que dividirlos, convertirlos en embeddings, indexarlos, filtrar por metadata y recuperar los fragmentos correctos con baja latencia. La base vectorial es la pieza que hace esa búsqueda semántica operable.

Alcance y supuestos

Este paquete cubre bases de datos vectoriales a nivel conceptual: embeddings almacenados, índices, similitud, top-k, metadata filters, colecciones, hybrid search y trade-offs de calidad, latencia y operación.

No cubre detalles internos de algoritmos ANN como HNSW o IVF, tutoriales vendor-specific, tuning profundo de índices ni benchmarking formal. Asume que entiendes embeddings, documentos, APIs y el flujo básico de RAG.

Modelo mental

Piensa en una biblioteca donde cada libro tiene una coordenada en un mapa de temas. Los libros sobre facturación quedan cerca entre sí; los de soporte técnico quedan en otra zona; los de políticas legales en otra. Cuando haces una pregunta, también la conviertes en coordenada y buscas los libros más cercanos.

La base vectorial no "entiende" el texto como una persona. Guarda números y calcula cercanía. Su valor está en hacer esa búsqueda rápido, a escala, combinando similitud semántica con filtros estructurados: idioma, fecha, tenant, tipo de documento, permisos o versión.

Una mala base vectorial no suele fallar con un error visible. Falla trayendo contexto irrelevante, viejo o incompleto. Por eso el diseño importa tanto como la tecnología elegida.

Uso práctico

Usa una base de datos vectorial cuando necesitas recuperar elementos por significado:

✅ RAG sobre documentación, tickets, políticas internas o catálogos extensos.
✅ Búsqueda semántica donde usuarios no escriben las mismas palabras que los documentos.
✅ Recomendaciones, deduplicación o agrupación de contenido similar.
❌ No reemplaza una base relacional para transacciones, integridad referencial o consultas exactas.
❌ No arregla chunks malos, embeddings mal elegidos o documentos desactualizados.

Ejemplo trabajado: recuperar chunks para un flujo RAG

Supón que tienes documentos de soporte y quieres responder preguntas usando evidencia. El flujo mínimo separa almacenamiento semántico de generación:

type DocumentChunk = {
  id: string;
  text: string;
  embedding: number[];
  metadata: {
    product: string;
    language: "es" | "en";
    updatedAt: string;
  };
};

type VectorSearchResult = {
  chunk: DocumentChunk;
  score: number;
};

interface VectorDatabase {
  upsert(chunks: DocumentChunk[]): Promise<void>;
  search(queryEmbedding: number[], options: {
    topK: number;
    filter?: Partial<DocumentChunk["metadata"]>;
  }): Promise<VectorSearchResult[]>;
}

La ingesta convierte documentos en chunks, genera embeddings y los guarda:

async function indexSupportDocs(vectorDb: VectorDatabase, chunks: DocumentChunk[]) {
  await vectorDb.upsert(chunks);
}

La consulta convierte la pregunta en embedding y recupera vecinos cercanos:

async function retrieveContext(
  vectorDb: VectorDatabase,
  questionEmbedding: number[],
) {
  const results = await vectorDb.search(questionEmbedding, {
    topK: 5,
    filter: { product: "billing", language: "es" },
  });

  return results.map((result) => result.chunk.text).join("\n---\n");
}

Lo importante no es solo llamar search. Las decisiones críticas son:

Cómo trocear documentos para que cada chunk tenga sentido propio.
Qué modelo de embeddings usar para idioma y dominio.
Qué métrica e índice equilibran recall y latencia.
Qué filtros evitan mezclar tenants, idiomas o versiones.
Cuántos resultados recuperar antes de saturar el prompt.
Cómo medir si los chunks recuperados realmente contienen la respuesta.

Si el retrieval trae basura, el LLM probablemente redactará basura con confianza. La base vectorial es infraestructura, pero su calidad se evalúa por la evidencia que entrega al sistema.

Evidencia

Pinecone documentation, Overview describe Pinecone como una base de datos vectorial para aplicaciones IA, semantic search, retrieval y memoria a escala.
Weaviate Database documentation presenta Weaviate como una base de datos vectorial que almacena objetos de datos y sus embeddings vectoriales.
pgvector, Open-source vector similarity search for Postgres documenta una extensión para Postgres que permite almacenar vectores y hacer búsqueda por similitud junto con datos relacionales.