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

Cápsula 07: Comparación HNSW vs IVF vs PQ - Decision Framework

Consolidar entendimiento de HNSW, IVF, PQ con decision framework práctico para elegir algoritmo correcto según requisitos de tu RAG system.

Al finalizar esta cápsula:

✅ Usarás decision tree para elegir algoritmo
✅ Compararás benchmarks lado a lado
✅ Conocerás configuraciones recomendadas por escenario
✅ Planificarás migration path (HNSW → IVF → IVF+PQ)

Tiempo estimado: 8-10 minutos

🎯 Decision Tree: ¿Qué algoritmo usar?

Framework de decisión

┌─────────────────────────────────────────┐
│ ¿Cuántos vectores tienes?               │
└─────────────────────────────────────────┘
                  │
       ┌──────────┴──────────┐
       │                     │
    < 1M                  > 1M
       │                     │
       │          ┌──────────┴──────────┐
       │          │                     │
       │       1M-5M                 > 5M
       │          │                     │
       │          │                     │
┌──────▼─────┐ ┌──▼────────┐ ┌─────────▼────────┐
│  HNSW      │ │  Accuracy  │ │   RAM crítico?   │
│            │ │  >95%?     │ │                  │
│ ChromaDB   │ │            │ │  Sí        No    │
│ Weaviate   │ │  Sí    No  │ │   │         │    │
│ Qdrant     │ │   │     │  │ │  IVF+PQ   IVF   │
└────────────┘ │ HNSW  IVF │ │  Faiss    Faiss  │
               │            │ │                  │
               └────────────┘ └──────────────────┘

Preguntas clave

1. ¿Cuántos vectores?

< 100K → HNSW (simple, ChromaDB)
100K - 1M → HNSW (managed, Pinecone/Weaviate)
1M - 5M → IVF o HNSW según memoria
5M → IVF + PQ

2. ¿Accuracy requerida?

95% → HNSW only
90-95% → IVF
85-90% → PQ o IVF+PQ
< 85% → Revisar embeddings (problema upstream)

3. ¿Memoria disponible?

8 GB por 1M vectores → HNSW viable
2-4 GB por 1M vectores → IVF viable
< 1 GB por 1M vectores → Requiere PQ

4. ¿Latencia requerida?

< 50ms → HNSW
< 100ms → IVF
< 200ms → IVF+PQ
200ms → Cualquiera (no crítico)

5. ¿Updates frecuentes?

Incremental (diario) → HNSW
Batch (semanal) → IVF o IVF+PQ
Batch (mensual) → Cualquiera

📊 Comparación lado a lado: Escenarios reales

Escenario 1: Customer Support Chatbot

Requisitos:

Vectores: 50K support articles
Accuracy: >95% (customer-facing)
Latency: <500ms (chatbot response)
Updates: Incremental (nuevos articles diariamente)
Budget: Moderate

Comparación:

Métrica	HNSW	IVF	IVF+PQ
Accuracy	98% ✅	93% ⚠️	88% ❌
Latency	12 ms ✅	25 ms ✅	30 ms ✅
Memoria	2 GB ✅	0.8 GB ✅	0.4 GB ✅
Build time	3 min ✅	1 min ✅	5 min ✅
Incremental	✅	❌	❌

Decisión: HNSW (ChromaDB)

Razón:

Accuracy crítica (customer-facing)
Memoria OK (2 GB razonable)
Incremental updates esencial
Latencia excelente

Setup:

# ChromaDB con HNSW
collection = client.create_collection(
    name="support_articles",
    metadata={"hnsw:space": "cosine"}
)

Escenario 2: E-commerce Product Search

Requisitos:

Vectores: 2M productos
Accuracy: 90-95% (search relevance OK)
Latency: <200ms
Updates: Batch nightly (catálogo cambia poco)
Budget: Limited (self-hosted)

Comparación:

Métrica	HNSW	IVF	IVF+PQ
Accuracy	98% ✅	93% ✅	90% ✅
Latency	25 ms ✅	45 ms ✅	55 ms ✅
Memoria	16 GB ❌	4 GB ✅	2 GB ✅
Build time	20 min ⚠️	8 min ✅	25 min ⚠️
Incremental	✅	❌ ⚠️	❌ ⚠️

Decisión: IVF (Faiss self-hosted)

Razón:

Accuracy 93% suficiente (search, no recomendaciones críticas)
Memoria crítica (16 GB HNSW muy costoso)
Batch updates OK (rebuild nightly viable)
Latencia aceptable (45ms < 200ms)

Setup:

# Faiss IVF
import faiss
dimension = 1536
nlist = 1414  # sqrt(2M) ≈ 1414
index = faiss.IndexIVFFlat(
    faiss.IndexFlatL2(dimension),
    dimension,
    nlist
)
index.nprobe = 20  # Explorar 20 clusters

Escenario 3: Internal Knowledge Base (Massive)

Requisitos:

Vectores: 20M documentos (Confluence + Slack + Jira + Docs)
Accuracy: 85-90% (internal, no crítico)
Latency: <500ms
Updates: Batch weekly (rebuild index weekend)
Budget: Limited (self-hosted, RAM limitado)

Comparación:

Métrica	HNSW	IVF	IVF+PQ
Accuracy	98% ✅	92% ✅	88% ✅
Latency	60 ms ✅	80 ms ✅	90 ms ✅
Memoria	160 GB ❌❌	40 GB ❌	12 GB ✅
Build time	180 min ❌	60 min ✅	120 min ⚠️
Incremental	✅	❌	❌

Decisión: IVF + PQ (Faiss)

Razón:

Memoria crítica (160 GB HNSW impracticable)
Accuracy 88% aceptable (internal search)
Latencia OK (90ms < 500ms)
Batch updates OK (weekly rebuild viable)
Costo: $800/month (12 GB) vs $8000/month (160 GB) → 10x savings

Setup:

# Faiss IVF+PQ
dimension = 1536
nlist = 4472  # sqrt(20M) ≈ 4472
m = 8  # Sub-vectores
nbits = 8

index = faiss.IndexIVFPQ(
    faiss.IndexFlatL2(dimension),
    dimension,
    nlist,
    m,
    nbits
)
index.nprobe = 50  # Accuracy boost

Escenario 4: Legal Document Analysis

Requisitos:

Vectores: 500K legal cases
Accuracy: >98% (crítico - legal compliance)
Latency: <1s (research, no real-time)
Updates: Batch monthly (casos archivados)
Budget: High (critical system)

Comparación:

Métrica	HNSW	IVF	IVF+PQ
Accuracy	98% ✅	93% ❌	88% ❌
Latency	20 ms ✅	40 ms ✅	50 ms ✅
Memoria	4 GB ✅	1 GB ✅	0.5 GB ✅
Build time	5 min ✅	2 min ✅	8 min ✅

Decisión: HNSW (Weaviate managed)

Razón:

Accuracy crítica (legal = zero compromise)
Budget permite (critical system)
Managed service (Weaviate) maneja scale
Latencia excelente

Setup:

# Weaviate con HNSW optimizado
collection_config = {
    "vectorIndexType": "hnsw",
    "vectorIndexConfig": {
        "maxConnections": 64,  # M alto para accuracy
        "efConstruction": 256,
        "ef": 200,  # efSearch alto
    }
}

🎨 Configuraciones recomendadas

HNSW configurations por caso de uso

Config A: High Accuracy (Legal, Medical)

{
    "hnsw:M": 64,  # Más conexiones
    "hnsw:construction_ef": 400,  # Build quality máximo
    "hnsw:search_ef": 200,  # Query quality máximo
}

# Resultado: 99% accuracy, 30ms latency, 10 GB RAM (1M vecs)

Config B: Balanced (Default)

{
    "hnsw:M": 16,  # Balance
    "hnsw:construction_ef": 200,
    "hnsw:search_ef": 100,
}

# Resultado: 98% accuracy, 18ms latency, 6 GB RAM (1M vecs)

Config C: Fast Query

{
    "hnsw:M": 8,  # Menos conexiones
    "hnsw:construction_ef": 100,
    "hnsw:search_ef": 50,
}

# Resultado: 95% accuracy, 10ms latency, 3 GB RAM (1M vecs)

IVF configurations por caso de uso

Config A: High Accuracy

nlist = int(sqrt(n) * 1.5)  # Más clusters
nprobe = int(nlist / 5)  # Explorar 20% clusters

# Ejemplo 1M vectores:
# nlist = 1500, nprobe = 300
# Resultado: 95% accuracy, 60ms latency

Config B: Balanced

nlist = int(sqrt(n))
nprobe = int(nlist / 10)

# Ejemplo 1M vectores:
# nlist = 1000, nprobe = 100
# Resultado: 93% accuracy, 40ms latency

Config C: Fast Query

nlist = int(sqrt(n) * 0.5)  # Menos clusters
nprobe = int(nlist / 20)

# Ejemplo 1M vectores:
# nlist = 500, nprobe = 25
# Resultado: 90% accuracy, 25ms latency

IVF+PQ configurations por caso de uso

Config A: High Accuracy (85-90%)

nlist = int(sqrt(n))
nprobe = int(nlist / 5)
m = 16  # Más sub-vectores
nbits = 8

# Resultado: 89% accuracy, 80ms latency, 2x compresión

Config B: Balanced

nlist = int(sqrt(n))
nprobe = int(nlist / 10)
m = 8
nbits = 8

# Resultado: 87% accuracy, 60ms latency, 6x compresión

Config C: Maximum Compression

nlist = int(sqrt(n) * 0.8)
nprobe = int(nlist / 15)
m = 8
nbits = 4  # 4 bits (16 centroids)

# Resultado: 82% accuracy, 50ms latency, 12x compresión

🚀 Migration Path: Escalar tu RAG system

Stage 1: MVP (0-100K vectores)

Recomendación: HNSW (ChromaDB local)

# Setup simple
import chromadb
client = chromadb.Client()
collection = client.create_collection("docs")

# Metrics:
# - Accuracy: 98%
# - Latency: 15ms
# - Memoria: 2 GB
# - Cost: $0 (self-hosted)

Cuándo migrar: Cuando alcances 100K vectores o 4 GB RAM.

Stage 2: Growth (100K-1M vectores)

Recomendación: HNSW (Pinecone/Weaviate managed)

# Pinecone managed
import pinecone
index = pinecone.Index("docs")

# Metrics:
# - Accuracy: 98%
# - Latency: 30ms (network)
# - Memoria: Managed (no concern)
# - Cost: $70/month

Cuándo migrar: Cuando alcances 1M vectores o latency/downtime sea crítico.

Stage 3: Scale (1M-5M vectores)

Opción A: HNSW (si budget permite)

# Weaviate managed con HNSW
# Cost: $200-500/month (16-32 GB RAM)
# Accuracy: 98%

Opción B: IVF (si budget limitado)

# Faiss self-hosted con IVF
# Cost: $50-100/month (4-8 GB RAM)
# Accuracy: 93%

Decisión: Accuracy crítica → Opción A. Cost crítico → Opción B.

Stage 4: Massive Scale (>5M vectores)

Recomendación: IVF + PQ (Faiss)

# Faiss IVF+PQ self-hosted
index = faiss.IndexIVFPQ(...)

# Metrics (10M vectores):
# - Accuracy: 88%
# - Latency: 80ms
# - Memoria: 8 GB
# - Cost: $60/month

# vs HNSW:
# - Accuracy: 98%
# - Memoria: 80 GB
# - Cost: $800/month ← 13x más costoso

Trade-off: 10% accuracy loss → 13x cost reduction.

🎯 Decision Scorecard

Matriz de decisión

Asigna puntos (1-5) a cada criterio según tu caso de uso:

Criterio	Peso	HNSW	IVF	IVF+PQ
Accuracy >95%	×3	5	3	2
Latencia <50ms	×2	5	3	3
Memoria limitada	×2	1	3	5
Incremental updates	×1	5	1	1
Build time rápido	×1	2	4	2
Scale >5M vectores	×2	2	4	5

Ejemplo cálculo (Customer Support):

HNSW:
  Accuracy: 5 × 3 = 15
  Latencia: 5 × 2 = 10
  Memoria: 1 × 2 = 2
  Incremental: 5 × 1 = 5
  Build: 2 × 1 = 2
  Scale: 2 × 2 = 4
  Total: 38 ✅ GANADOR

IVF: Total: 28
IVF+PQ: Total: 25

Usa este scorecard para evaluar tu caso específico.

✅ Checklist de comprensión

Verifica que entendiste esta cápsula:

¿Cuál algoritmo para 50K vectores, accuracy crítica?
- Respuesta: HNSW (ChromaDB). Alta accuracy (98%), setup simple, memoria razonable (2 GB).
¿Cuál algoritmo para 5M vectores, RAM limitado?
- Respuesta: IVF+PQ (Faiss). Compresión 6-8x, accuracy 88% aceptable, costo bajo.
¿Cuándo migrar de HNSW a IVF?
- Respuesta: Cuando >1M vectores, memoria >16 GB requerida, o accuracy 90-95% es suficiente.
¿Qué parámetros ajustar para mayor accuracy en IVF?
- Respuesta: Aumentar nlist (más clusters) y nprobe (explorar más clusters).
¿Trade-off principal de PQ?
- Respuesta: 4-8x menos memoria vs 10-15% accuracy loss. Viable si accuracy 85-90% suficiente.

Si respondiste 4-5/5 correctamente → ✅ Listo para Cápsula 08 (Resumen + RAG)

🚀 Siguiente paso

En última cápsula del módulo, consolidaremos todo y conectaremos con RAG systems.

Próxima cápsula: 08 - Por qué esto importa para RAG

Aprenderás:

Impact de algoritmos en performance de RAG
Impact en costos (memoria, compute, cloud)
Impact en accuracy (95% vs 100% - aceptable trade-off)
Resumen del módulo y transición a Módulo 3

Clave: Aplicar todo lo aprendido a decisiones reales de arquitectura RAG.

Tiempo de lectura: 8-10 minutos
Siguiente: 08-por-que-importa-rag.md

← AnteriorCápsula 06: PQ - Product Quantization Siguiente →Cápsula 08: Por qué esto importa para RAG - Resumen del Módulo

Cápsula 07: Comparación HNSW vs IVF vs PQ - Decision Framework

🎯 Objetivo de la cápsula

🎯 Decision Tree: ¿Qué algoritmo usar?

Framework de decisión

Preguntas clave

📊 Comparación lado a lado: Escenarios reales

Escenario 1: Customer Support Chatbot

Escenario 2: E-commerce Product Search

Escenario 3: Internal Knowledge Base (Massive)

Escenario 4: Legal Document Analysis

🎨 Configuraciones recomendadas

HNSW configurations por caso de uso

Config A: High Accuracy (Legal, Medical)

Config B: Balanced (Default)

Config C: Fast Query

IVF configurations por caso de uso

Config A: High Accuracy

Config B: Balanced

Config C: Fast Query

IVF+PQ configurations por caso de uso

Config A: High Accuracy (85-90%)

Config B: Balanced

Config C: Maximum Compression

🚀 Migration Path: Escalar tu RAG system

Stage 1: MVP (0-100K vectores)

Stage 2: Growth (100K-1M vectores)

Stage 3: Scale (1M-5M vectores)

Stage 4: Massive Scale (>5M vectores)

🎯 Decision Scorecard

Matriz de decisión

✅ Checklist de comprensión

🚀 Siguiente paso