Bases de datos vectoriales: una introducción técnica [pdf]

Artículo original ↗ Discusión en Hacker News ↗

Las bases de datos vectoriales están emergiendo como infraestructura central para la búsqueda semántica y la generación aumentada por recuperación, pero los ingenieros todavía están determinando cuándo vale la pena adoptarlas frente a opciones más simples como la búsqueda por fuerza bruta en SQLite o Postgres con pgvector. Los comentaristas intercambian recursos y benchmarks, debaten entre coseno y distancia euclidiana y varios esquemas de indexación (HNSW, IVF, ANNOY, PQ), y enfatizan que los embeddings los producen modelos de ML externos y no la base de datos en sí. Un tema recurrente es que las necesidades prácticas —escala de datos, latencia, costo y búsqueda híbrida léxica–vectorial— deberían guiar la elección entre bases de datos vectoriales “completas” y extensiones o bibliotecas más ligeras.

Curso y recursos adicionales

  • El hilo se centra en un manual en PDF derivado de una clase grabada, con un curso de video asociado en Udemy (con descuento).
  • Los comentaristas comparten muchos recursos complementarios: encuestas académicas sobre bases de datos vectoriales, introducciones generales a embeddings y a la búsqueda ANN, y documentación de proveedores.

Similitud del coseno vs distancia euclidiana

  • Debate prolongado sobre por qué se usa comúnmente la similitud del coseno.
  • Puntos a favor: la magnitud a menudo no es semánticamente significativa; la normalización simplifica a producto punto; ventajas de eficiencia.
  • Escepticismo: la magnitud podría importar en algunas tareas; las explicaciones sobre el coseno a menudo parecen vagas; algunos sostienen que el verdadero objetivo es maximizar el producto interno y que la normalización es sobre todo una conveniencia.
  • Otros aportan intuiciones de hiperplanos aleatorios y hashing sensible a la localidad. Consenso: la práctica favorece el coseno, pero los compromisos teóricos son matizados.

Búsqueda por fuerza bruta vs ANN / índices vectoriales

  • Varios benchmarks sugieren que la fuerza bruta sobre cientos de miles a millones de vectores es sorprendentemente viable, especialmente cuando se hace en lotes y cuando la generación de LLM domina la latencia.
  • Discusión sobre cuándo se “rompe” el escaneo lineal: depende de la cantidad de vectores, la dimensionalidad, las RPS y la RAM.
  • Las estructuras ANN (HNSW, IVF, Annoy, LSH, etc.) se vuelven importantes a mayor escala o con QPS más altos, aunque los métodos basados en grafos tienen costos de memoria y de construcción.

Bases de datos vectoriales dedicadas vs bases de datos tradicionales

  • Muchos preguntan cuándo pasar de SQLite/Postgres+pgvector a una base de datos vectorial especializada (Pinecone, Qdrant, etc.).
  • Para O(100k) vectores y poco tráfico, las soluciones simples dentro de la base de datos o en memoria suelen ser “suficientemente buenas”.
  • Algunos informan haber escalado motores personalizados o livianos hasta decenas de millones de vectores; otros destacan el costo y la complejidad de las bases de datos vectoriales alojadas y sugieren alternativas.
  • Hay demanda de una guía más clara sobre los compromisos (velocidad de indexación, latencia de consulta, costo, operaciones).

Búsqueda híbrida y RAG

  • La mayoría de los sistemas RAG actuales usan búsqueda vectorial; algunos todavía dependen de búsqueda por palabras clave/texto.
  • Varios enfatizan que la búsqueda híbrida (vector + léxica) es cada vez más estándar; las bases de datos tradicionales añaden soporte vectorial y las bases de datos vectoriales añaden funciones léxicas.

Embeddings, selección de características y semántica

  • Aclaración importante: las bases de datos vectoriales solo almacenan y buscan vectores; los embeddings se producen fuera por modelos de ML.
  • Discusión sustancial sobre la “selección de características” y el juicio humano:
    • Una postura: el aprendizaje profundo moderno junto con la atención automatiza en gran medida la extracción de características a partir de datos brutos para modalidades comunes; no se necesita un diseño manual explícito de características.
    • Postura contraria: los humanos todavía deciden representaciones (por ejemplo, FFT para audio), objetivos y qué debe significar la “similitud”; las características faltantes pueden producir resultados de “similitud” sistemáticamente erróneos.
  • Se señala que los embeddings no tienen que ser puramente semánticos; pueden codificar comportamiento (por ejemplo, sistemas de recomendación) o tiempo/contexto.

Casos de uso y alternativas

  • Las bases de datos vectoriales se usan principalmente para búsqueda por similitud/semántica, recuperación de elementos relacionados y RAG.
  • Para tareas visuales específicas (por ejemplo, reconocimiento de color de cabello/piel), los encuestados sostienen que modelos de ML especializados (CNNs, detectores de rostros, modelos multimodales) superan a la búsqueda ingenua por similitud de imágenes; las bases de datos vectoriales son un componente, no un sustituto.

Opciones incrustadas / ligeras

  • Se mencionan varias opciones incrustadas o simples: SQLite con funciones personalizadas, DuckDB, Chroma, extensiones de SQLite, pequeñas bibliotecas (Faiss, HNSWlib, usearch) y modos locales/incrustados de sistemas más grandes.

Críticas al manual

  • Varios señalan errores en las tablas (filas intercambiadas, tipos de índice invertidos).
  • Objeciones a describir las bases de datos vectoriales como “agrupadas por significado” u “optimizadas para analítica”:
    • El agrupamiento depende por completo del embedding y de la tarea.
    • Las bases de datos vectoriales se presentan como sistemas de búsqueda/recuperación, más parecidos a motores de búsqueda que a almacenes analíticos.
  • Algunos detalles técnicos menores: por ejemplo, PQ se caracteriza más como compresión que como una estrategia de indexación; la orientación sobre cuándo usar tipos de índice específicos es discutida.