Módulo 2: Cómo funcionan Vector Databases (Conceptual)

Módulo 2: Cómo funcionan Vector Databases (Conceptual)

Siguiente →

Descripción del módulo

En el Módulo 1 quedó establecido POR QUÉ necesitás vector databases: SQL/NoSQL no entienden geometría de alta dimensión, numpy/pandas no escalan a millones de vectores, y RAG necesita retrieval en milisegundos. La conclusión cierra: necesitás herramienta especializada. Pero el siguiente paso natural es preguntar ¿CÓMO? ¿Cómo logran las vector databases responder en 15ms cuando numpy sobre los mismos datos tarda 1.5 segundos? ¿Qué hacen por dentro que las hace 100x más rápidas?

La respuesta corta: indexing algorithms — HNSW, IVF, PQ. Estos algoritmos transforman búsqueda O(n) (revisar todos los vectores) en O(log n) (saltar inteligentemente al grupo correcto). No son magia — son estructuras de datos sofisticadas con trade-offs muy concretos. Y entenderlos a nivel conceptual es la diferencia entre un AI Engineer que debugea cuando las cosas fallan y uno que mira la API como caja negra esperando que funcione.

Este módulo es 100% conceptual — sin código ejecutable. La razón pedagógica es deliberada: cuando llegues al Módulo 4 y configures hnsw:M=32 en ChromaDB, no quiero que sea copy-paste. Quiero que sepas que M=32 significa "32 conexiones por nodo en el grafo HNSW", que entiendas que más conexiones mejoran recall pero consumen más RAM, y que puedas defender la elección de ese valor frente a un Tech Lead.

Al finalizar este módulo serás capaz de:

  • ✅ Explicar la arquitectura de tres capas de una vector database (indexing, query, storage) y cómo se conectan
  • ✅ Describir HNSW conceptualmente — grafo navegable jerárquico con saltos largos → cortos, O(log n) en complejidad
  • ✅ Describir IVF conceptualmente — clustering con k-means que particiona el espacio, O(√n) aproximado
  • ✅ Describir PQ conceptualmente — compresión de vectores en sub-vectores y codebooks, 4-8x reducción de memoria
  • ✅ Comparar HNSW vs IVF vs PQ en trade-offs cuantificados: accuracy (98% vs 93% vs 88%), memoria (6 GB vs 2 GB vs 1 GB para 1M vectores)
  • ✅ Usar un decision framework para elegir algoritmo según requisitos de scale, accuracy, memoria y presupuesto
  • ✅ Conectar cada algoritmo con su impacto en RAG: por qué HNSW es default para <10M vectores, cuándo migrar a IVF+PQ

Tiempo estimado del módulo: 2-3 horas (8 cápsulas).

Por qué entender la maquinaria interna te hace mejor AI Engineer

Imaginá tres escenarios donde te van a pedir tomar decisiones:

Escenario 1: el query lento sin causa visible

Tu RAG en producción tarda 800ms en hacer retrieval. El SLA es 200ms. Todos en el equipo sospechan algo distinto:

  • Frontend dice: "es la red, agreguemos caché en el cliente".
  • Backend dice: "es el LLM, cambiemos a un modelo más rápido".
  • DevOps dice: "es la base, escalemos vertical".

Vos sabés que ninguno tocó el indexing. Sabés que ef_search=10 es el default y que con 1M vectores eso a veces da queries patológicamente lentas. Subís ef_search a 50, mide, y resuelve. Tardaste 30 minutos. La alternativa hubiera sido 2 semanas migrando a otra DB sin garantía.

Sin entender HNSW, no podés ni nombrar el parámetro que arregla el problema.

Escenario 2: la decisión de migrar (o no) cuando crece el dataset

Empresa quiere escalar de 100K vectores a 5M en 6 meses. CTO te pregunta: "¿Aguanta ChromaDB o tenemos que migrar a Pinecone?"

Si solo sabés "ChromaDB es local, Pinecone es cloud", tu respuesta va a ser intuición. Si entendés que ChromaDB usa HNSW puro y que el RAM consumido por HNSW crece linealmente con el número de vectores (~6 GB por 1M con dim=1536), podés calcular: 5M vectores × 6 GB / 1M = 30 GB de RAM solo para el índice. Una máquina de 32 GB no aguanta.

Tu respuesta deja de ser "creo que sí" y se convierte en "no, necesitamos migrar a IVF+PQ que reduce el RAM a ~5 GB para 5M, o pasar a una vector DB distribuida como Milvus/Qdrant cluster". Esa diferencia entre intuición y números es lo que separa un AI Engineer junior de uno senior.

Escenario 3: el bug de accuracy que parece azar

Recall@10 baja del 95% al 78% sin razón aparente. Las queries son las mismas, el dataset creció pero no cambió de naturaleza, el código no cambió. ¿Qué pasó?

Si entendés que cuando ef_construction (parámetro de build de HNSW) es bajo, el grafo construido es subóptimo y al insertar muchos docs nuevos la calidad del índice se degrada lentamente, sabés que rebuilding el índice con ef_construction=200 lo arregla. Tardaste 45 minutos. Sin ese conocimiento, debuggear tomó 2 sprints y se atribuyó a "raro, debe ser el modelo".

Cada uno de estos escenarios sucede. Lo único que cambia es si vos sos el que los resuelve.

Lo que NO vas a hacer en este módulo

Para calibrar expectativas: este módulo es conceptual. Vas a:

✅ Entender la idea detrás de HNSW (navegación jerárquica en grafo) ✅ Visualizar cómo se construye el índice (capas con saltos) ✅ Comparar trade-offs de los algoritmos sin matemáticas avanzadas

Lo que no vas a hacer:

❌ Implementar HNSW desde cero ❌ Derivar las ecuaciones de Navier-Stokes del clustering en IVF ❌ Calcular gradientes para Product Quantization

¿Por qué? Porque sos AI Engineer, no ML Engineer ni research scientist.

Analogía: un piloto de avión necesita entender aerodinámica conceptualmente — sustentación, arrastre, turbulencia, ángulo de ataque. Sabe que velocidad insuficiente + ángulo alto = pérdida de sustentación, y por eso evita esa combinación. No necesita derivar las ecuaciones de Navier-Stokes para volar bien.

Tu objetivo es ser piloto de vector databases. Cuando uses ChromaDB y configures HNSW, sabrás qué pasa. Cuando algo falle, sabrás dónde mirar. Cuando un compañero diga "metamos PQ", sabrás si tiene sentido para tu caso. No necesitás más que eso.

Los tres algoritmos que vas a entender

Para anclar lo que viene, acá está la vista panorámica de los tres algoritmos del módulo, en una sola tabla:

AlgoritmoIdea centralComplejidad búsquedaAccuracy típicoMemoria (1M vectores 1536-dim)Usado por
HNSW (Hierarchical Navigable Small World)Grafo en capas; saltás largo arriba, corto abajoO(log n)98%~6 GBChromaDB, Weaviate, Qdrant, Pinecone
IVF (Inverted File Index)Agrupás vectores por proximidad; buscás solo en el grupo cercanoO(√n) aprox93%~2 GBFaiss, Milvus
PQ (Product Quantization)Comprimís cada vector en pedacitos representados por códigosO(n) pero rápido88%~1 GBFaiss compresión, Milvus

Patrón a notar: los tres pelean por el mismo balance — accuracy vs memoria vs velocidad. HNSW maximiza accuracy a costa de memoria. IVF balancea. PQ minimiza memoria a costa de accuracy. No hay algoritmo "mejor" en abstracto — hay algoritmo correcto para tu caso.

Las cápsulas 04, 05 y 06 profundizan cada uno. La cápsula 07 los compara con benchmarks reales. La cápsula 08 cierra conectando todo con RAG.

Mapa del módulo

CápsulaTemaPor qué importaTiempo
01 (acá)Introducción al móduloPor qué entender la maquinaria interna y qué vas a aprender5-8 min
02Arquitectura de tres capasIndexing, query, storage — cómo se conectan25-30 min
03Indexing algorithms — overviewBrute force vs ANN; cuándo importa cada uno25-30 min
04HNSW profundoEl algoritmo más usado: grafo jerárquico, parámetros (M, ef)35-40 min
05IVF clusteringCuándo IVF gana sobre HNSW (datasets grandes, memoria limitada)25-30 min
06PQ compresiónCuándo aceptar 10% menos accuracy por 6x menos memoria30-35 min
07Comparación de algoritmosDecision framework: HNSW vs IVF vs PQ vs combinaciones25-30 min
08Por qué importa para RAGConexión con el resto de la guía15-20 min

Total estimado: 3-4 horas. Es un módulo denso conceptualmente — leelo en 2-3 sesiones para que asiente.

Conexión con el resto de la guía

Módulo 1: Por qué Vector DBs
  └─ Establecés la necesidad
       ↓
Módulo 2 (estás acá): Cómo funcionan
  └─ Entendés la maquinaria interna
       ↓
Módulo 3: Features para RAG
  └─ Aprendés qué features de la maquinaria importan para RAG
       ↓
Módulo 4: ChromaDB hands-on
  └─ Configurás HNSW informadamente (no copy-paste)
       ↓
Módulos 5-7: Landscape, decisión, producción
  └─ Comparás con criterio (HNSW vs custom de Pinecone, etc.)
       ↓
Módulo 8: Proyecto integrador
  └─ Aplicás todo en un sistema RAG real

Las decisiones que vas a tomar después dependen de lo que entiendas acá:

  • En M4 vas a configurar hnsw:M=32 y hnsw:construction_ef=200. Si entendés HNSW (cápsula 04), esos números tienen sentido. Si no, son magia.
  • En M5 vas a comparar Pinecone vs ChromaDB vs Qdrant. Cada uno usa una variante distinta del mismo familia de algoritmos. Si entendés HNSW, podés evaluar las variantes con criterio.
  • En M7 vas a optimizar costos. Si tu sistema tiene 5M vectores y cuesta $300/mes en RAM, vas a saber que migrar a IVF+PQ te baja a $50/mes a costa de 5% recall — y vas a saber si ese trade-off vale para tu caso.

Vista anticipatoria: tres algoritmos, un mismo trade-off

Antes de entrar al detalle, fijate cómo los tres algoritmos están resolviendo el mismo problema con distintos compromisos. Esta tabla la vas a ver en detalle en la cápsula 07, pero conviene tenerla en mente desde el inicio:

                    Memoria  ←——————————————→  Accuracy
                  (mínima)                     (máxima)
                     │                            │
        PQ ─────────●                             │
                     │           HNSW             │
        IVF ────────────────────────●             │
                     │                            │
       (1 GB         │           (8 GB             (12 GB
        para 1M)     │            para 1M)         para 1M)
                     │
                     └───────────────────────────────────────→
                              Velocidad
                               │
                       (HNSW > IVF > PQ
                        en latency típica)

Lo que define qué algoritmo usás no es cuál es "el mejor" sino cuál es la restricción más dura de tu sistema:

  • ¿Memoria es la restricción? PQ. Aceptás 5-10% menos accuracy a cambio de 6-8x menos RAM.
  • ¿Accuracy es la restricción? HNSW con M alto. Pagás más RAM, ganás recall casi-perfecto.
  • ¿Balance entre los dos? IVF, o HNSW con configuración media.

Cuando llegues a producción, vas a tomar esta decisión literalmente — y la respuesta correcta depende de tu hardware, tu presupuesto y tu SLA. Esa es la decisión que este módulo te prepara para tomar.

Cómo te recomiendo leer este módulo

Este es el módulo más conceptualmente denso de la guía. Algunas recomendaciones de método:

1. No lo leas todo de un tirón. Las cápsulas 02-07 son densas. Mejor:

  • Sesión 1 (1h): cápsulas 01 (esta) + 02 (arquitectura de tres capas) + 03 (overview de algoritmos)
  • Sesión 2 (1h): cápsula 04 (HNSW profundo) — la más importante
  • Sesión 3 (1h): cápsulas 05 (IVF) + 06 (PQ)
  • Sesión 4 (30min): cápsulas 07 (comparación) + 08 (conexión con RAG)

2. No memorices fórmulas. Si te encontrás copiando ecuaciones a un cuaderno, estás perdiendo el punto. Lo que importa son los modelos mentales — qué hace cada algoritmo, en qué se diferencia, cuándo usarlo.

3. Volvé a esta intro entre cápsulas. Cuando termines la cápsula 04 (HNSW), volvé acá y revisá si podés ahora explicar HNSW en 3 oraciones. Si no, releé la cápsula 04 antes de avanzar.

4. Las cápsulas de IVF y PQ son menos críticas. Si tu sistema usa ChromaDB o Pinecone, vas a usar HNSW casi siempre. IVF y PQ son útiles para datasets enormes (10M+ vectores) o restricciones extremas de memoria. Si estás en MVP con 100K vectores, podés leerlas en lectura rápida.

5. La cápsula 07 (comparación) es la más práctica. Es donde todas las piezas se juntan en un decision framework aplicable. Si solo tenés tiempo para una segunda lectura, esa es la candidata.

Lo que NO necesitás haber aprendido para empezar

A veces el miedo más grande de un módulo "conceptual" es que requiera matemáticas que no tenés. Para anclar expectativas — esto es lo que NO vas a necesitar saber para entender el módulo:

  • ❌ Álgebra lineal avanzada (eigenvectores, SVD, etc.)
  • ❌ Cálculo (gradientes, derivadas)
  • ❌ Probabilidad y estadística inferencial
  • ❌ Teoría de grafos formal
  • ❌ Análisis de algoritmos (notación O grande la usaremos pero conceptualmente)

Lo que sí vas a necesitar:

  • ✅ Concepto básico de vector y dimensiones (Módulo 1 + Guía #5 AI Semantics + Guía #6 Embeddings ya cubren esto)
  • ✅ Idea de que dos vectores pueden estar "cerca" o "lejos" en el espacio
  • ✅ Familiaridad con leer pseudo-código

Si terminás un módulo del path AI Engineering típico, tenés más que suficiente. No te trabes en la matemática — el objetivo es la intuición.

Auto-verificación antes de avanzar

Antes de continuar a la cápsula 02, asegurate de que podés responder estas preguntas (si no, releé esta intro):

  1. ¿Por qué este módulo es conceptual en vez de pedirte implementar HNSW desde cero?
  2. Mencioná tres situaciones reales donde no entender la maquinaria interna te impide tomar buenas decisiones.
  3. ¿Cuál de los tres algoritmos (HNSW, IVF, PQ) priorizaría memoria mínima sobre accuracy?
Respuestas

  1. Porque tu rol como AI Engineer es usar las herramientas con criterio, no construirlas. Implementar HNSW desde cero te tomaría meses y no te haría mejor en tu trabajo. Entender el algoritmo conceptualmente te toma 40 minutos y te permite debugear, optimizar y decidir.

  2. (a) Query lento sin causa visible — sin entender HNSW, no podés nombrar ef_search, el parámetro que típicamente arregla el caso. (b) Decisión de migrar cuando el dataset crece — sin entender el consumo de RAM de HNSW, no podés calcular si tu hardware actual aguanta el crecimiento proyectado. (c) Bug de accuracy que parece azar — sin entender el rol de ef_construction, no sabés que rebuildear el índice con un parámetro mejor lo arregla.

  3. PQ (Product Quantization). Comprimís cada vector a 1/4 a 1/8 del tamaño original a costa de ~10% accuracy. Es el algoritmo correcto cuando tu cuello de botella es RAM/storage y podés tolerar accuracy menor — típicamente datasets >10M vectores en máquinas modestas.

Próximo paso: Cápsula 02

La siguiente cápsula abre la caja: arquitectura de tres capas — indexing, query engine, storage. Antes de entrar a los algoritmos específicos (HNSW, IVF, PQ en cápsulas 04-06), necesitás el modelo mental de cómo se conectan las piezas. Es la base sobre la que se monta todo lo demás.

Tiempo estimado: 5-8 minutos Siguiente: 02-arquitectura-tres-capas.md

← AnteriorResumen del Módulo 1 y TransiciónSiguiente →Cápsula 02: Arquitectura de Vector Databases (3 Capas)