Módulo 1: Por qué Vector Databases para AI Engineers

Resumen del Módulo 1 y Transición

Siguiente →

Descripción de la cápsula

Has completado el módulo más importante de esta guía: entender POR QUÉ necesitas vector databases para sistemas RAG production-ready.

Esta cápsula consolida todo lo aprendido en un framework de decisión práctico y te prepara para los siguientes módulos donde aprenderás CÓMO funcionan (Módulo 2) y CÓMO usarlas (Módulos 4-8).

Recap: Por qué Vector Databases existen

El problema (Cápsula 02)

RAG necesita:

  • Buscar 5-10 docs relevantes entre 1M+ opciones
  • En <500ms (idealmente <100ms)
  • Con múltiples usuarios concurrentes
  • Con uptime >99%

Naive search (brute force):

  • 1M vectores = 1.5s latency ❌
  • No escala

Solución: Approximate Nearest Neighbors (ANN)

  • 1M vectores = 15ms latency ✅
  • Escala a 10M+ vectores

Por qué SQL/NoSQL no sirven (Cápsula 03)

SQL (Postgres + pgvector):

  • Diseñado para tablas, no vectores
  • pgvector útil pero limitado: 50-80ms vs 10-20ms de ChromaDB
  • ✅ Usar SI: Ya tienes Postgres, <100K vectores, equipo SQL-first

NoSQL (MongoDB, Elasticsearch):

  • Diseñado para documentos/text, no vectores puros
  • Útil para hybrid search (keyword + semantic)
  • ✅ Usar SI: Ya usas MongoDB/Elastic, necesitas hybrid

Vector DBs dedicadas:

  • Arquitectura optimizada para vectores únicamente
  • 3-5x más rápidas que SQL/NoSQL con extensiones
  • ✅ Usar SI: Vector search es tu use case principal

Por qué numpy/pandas no escalan (Cápsula 04)

numpy limitaciones:

  1. Latency O(n): 1M vectores = 1.5s (126x más lento que ChromaDB)
  2. Memoria RAM: 6GB/millón (limitado por RAM física)
  3. Sin persistencia: Recarga 30-60s después de reinicio
  4. Sin concurrencia: No thread-safe para writes
  5. Sin features: No metadata filtering, monitoring, backup

numpy es suficiente SI:

  • <10K vectores (15ms latency)
  • 1 usuario (desarrollo)
  • Sin requisito de latency (batch processing)
  • Dataset estático (no crece)

Cuándo SÍ necesitas vector DB (Cápsula 05)

4 criterios de decisión:

  1. Scale: >100K vectores → vector DB necesaria
  2. Latency: <500ms → vector DB recomendada, <100ms → obligatoria
  3. Persistencia: Uptime >99% → vector DB necesaria
  4. Concurrencia: >10 usuarios → vector DB necesaria

SI cumples 3+ criterios → Vector DB es necesaria

Casos típicos:

  • Production RAG (empresa): 4/4 criterios ✅
  • SaaS multi-tenant: 4/4 criterios + features ✅
  • Chatbot interno (50 usuarios): 3-4/4 criterios ✅

Cuándo NO necesitas vector DB (Cápsula 06)

Señales de que numpy/alternatives son suficientes:

  1. ✅ <10K vectores → numpy (15ms latency)
  2. ✅ Sin requisito latency → numpy batch processing
  3. ✅ 1 usuario (desarrollo) → numpy para iteración rápida
  4. ✅ Keyword search suficiente → Elasticsearch, no embeddings
  5. ✅ Dataset estático → numpy/FAISS precomputado
  6. ✅ Budget $0 → numpy o ChromaDB local

Alternativas:

  • numpy: Prototipo, <10K vectores, desarrollo
  • SQL + pgvector: Ya usas Postgres, <100K vectores
  • Elasticsearch: Hybrid search (keyword + semantic)
  • FAISS: Dataset estático, offline processing

Trade-offs cuantitativos (Cápsula 07)

Comparación @ 1M vectores:

DimensiónnumpypgvectorChromaDBPinecone
Latency1,500ms ❌350ms ⚠️30ms ✅15ms ✅
Setup time1h ✅3h ⚠️2.5h ✅2h ✅
Cost/month$0 ✅$0-50 ✅$50-100 ✅$150-200 ⚠️
Maintenance4-8h/mes ⚠️6-10h ⚠️8-12h ⚠️0h ✅
Concurrency1 user ❌5-10 ⚠️20-50 ✅100+ ✅

Decision framework:

  • <10K vectors: numpy (simplicidad)
  • 10K-100K: ChromaDB self (balance)
  • 100K-1M: ChromaDB self o Pinecone (budget vs maintenance)
  • >1M: Pinecone managed (performance + zero maintenance)

Framework de decisión: Paso a paso

Evalúa tu proyecto en 5 minutos

Paso 1: Calcula # de vectores

docs = ???  # Cuántos documentos
chunks_per_doc = 3  # Promedio de chunks por doc
total_vectors = docs * chunks_per_doc

Paso 2: Define latency requirement

¿Qué latency necesitas para retrieval?
[ ] Sin requisito (batch processing)
[ ] <5s (exploración)
[ ] <1s (aceptable)
[ ] <500ms (standard RAG)
[ ] <100ms (critical RAG)

Paso 3: Evalúa persistencia

¿Necesitas uptime alto?
[ ] NO - Script one-off, notebook
[ ] Moderado - Servicio interno (90% uptime OK)
[ ] SÍ - Production service (99%+ uptime)

Paso 4: Evalúa concurrencia

¿Cuántos usuarios concurrentes?
[ ] 1 (desarrollo)
[ ] 2-10 (equipo pequeño)
[ ] 10-50 (departamento)
[ ] >50 (empresa)

Paso 5: Decide basado en matriz

def recommend_storage(n_vectors, latency_ms, uptime_pct, n_users):
    score = 0
    
    if n_vectors > 100_000: score += 2
    elif n_vectors > 10_000: score += 1
    
    if latency_ms < 100: score += 2
    elif latency_ms < 500: score += 1
    
    if uptime_pct > 99: score += 1
    
    if n_users > 50: score += 2
    elif n_users > 10: score += 1
    
    if score >= 6:
        return "Vector DB necesaria (Pinecone managed)"
    elif score >= 4:
        return "Vector DB recomendada (ChromaDB self-hosted)"
    elif score >= 2:
        return "Zona gris (evaluar pgvector o ChromaDB)"
    else:
        return "numpy es suficiente"

# Ejemplo
result = recommend_storage(
    n_vectors=150_000,
    latency_ms=200,
    uptime_pct=99.5,
    n_users=30
)
print(result)
# Output: "Vector DB recomendada (ChromaDB self-hosted)"

¿Qué sigue? Preview Módulo 2

Has completado el "POR QUÉ"

Ahora sabes:

  • ✅ Por qué RAG necesita vector DBs (retrieval <100ms con 1M+ vectores)
  • ✅ Por qué SQL/NoSQL no son óptimos (overhead, latency 3-5x peor)
  • ✅ Por qué numpy no escala (brute force O(n), sin persistencia, sin concurrencia)
  • ✅ Cuándo SÍ necesitas vector DB (4 criterios: scale, latency, persistencia, concurrencia)
  • ✅ Cuándo NO necesitas vector DB (<10K vectores, batch processing, desarrollo)
  • ✅ Trade-offs cuantitativos (latency, cost, maintenance)

Siguiente: Aprende el "CÓMO"

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

Aprenderás:

  • Arquitectura interna (3 capas: indexing, query, storage)
  • HNSW (Hierarchical Navigable Small World) - algoritmo dominante
  • IVF (Inverted File Index) - alternativa con trade-offs
  • PQ (Product Quantization) - compresión de vectores
  • Por qué estos algoritmos logran O(log n) vs O(n)
  • Trade-offs: accuracy vs speed vs memory

Enfoque: Conceptual riguroso SIN math avanzada (entender QUÉ hacen, no implementar)

Por qué importa: Entender arquitectura interna te permite:

  • Debuggear performance issues (por qué mi query tarda 500ms vs 50ms esperado)
  • Optimizar indexing (cuándo usar HNSW vs IVF vs PQ)
  • Tomar mejores decisiones (cuándo usar ChromaDB vs Pinecone)

Roadmap de módulos restantes

✅ Módulo 1: Por qué Vector DBs (completado)
    ↓
⏳ Módulo 2: Cómo funcionan (arquitectura, HNSW, IVF, PQ)
    ↓
⏳ Módulo 3: Features para RAG (metadata filtering, hybrid search)
    ↓
⏳ Módulo 4: ChromaDB Hands-On (código ejecutable)
    ↓
⏳ Módulo 5: Landscape de DBs (Pinecone, Weaviate, Qdrant - conceptual)
    ↓
⏳ Módulo 6: Decision Matrix (framework de decisión refinado)
    ↓
⏳ Módulo 7: Production (scaling, monitoring, migrations)
    ↓
⏳ Módulo 8: Proyecto Integrador (RAG completo con ChromaDB, API FastAPI, Docker)

Balance:

  • Módulos 1-3: Conceptual puro (entender fundamentos)
  • Módulos 4-8: Hands-on + production (implementar sistema completo)

Test de validación del módulo

Responde estas preguntas sin mirar notas:

1. ¿Por qué RAG necesita vector databases?

Solución

Respuesta correcta: RAG debe buscar 5-10 documentos relevantes entre 1M+ opciones en <500ms. Brute force (numpy) tarda 1.5s. ANN (vector DBs) tarda 15ms. 100x speedup es necesario para production.

2. ¿Por qué SQL con pgvector no es óptimo?

Solución

Respuesta correcta: SQL está diseñado para tablas, no vectores. pgvector agrega HNSW pero con overhead SQL. Resultado: 50-80ms vs 10-20ms de ChromaDB (3-4x más lento). Útil si ya usas Postgres, pero no óptimo para vector-only.

3. ¿Cuál es el punto de inflexión de numpy?

Solución

Respuesta correcta: ~10K vectores. Antes de 10K, numpy es competitivo (15ms). Después de 10K, numpy degrada rápidamente (100K = 150ms, 1M = 1500ms). Vector DB mantiene <50ms hasta 10M vectores.

4. ¿Cuándo NO necesitas vector database?

Solución

Respuesta correcta: SI tienes <10K vectores, sin requisito de latency (<500ms), 1 usuario (desarrollo), dataset estático, y budget $0 → numpy o ChromaDB local son suficientes. No sobre-ingenierices.

5. ¿Qué trade-off aceptas al elegir numpy sobre ChromaDB?

Solución

Respuesta correcta:

  • Ganas: Simplicidad (pip install numpy, 10s vs 2.5h ChromaDB learning), $0 cost
  • Pierdes: Performance con >10K vectores (150ms vs 12ms), features (metadata filtering, hybrid search), persistencia robusta, concurrencia thread-safe

Trade-off válido SI tienes <10K vectores y simplicidad > performance.

Si respondiste 4-5/5 correctamente → ✅ Módulo 1 completado exitosamente
Si respondiste 2-3/5 → ⚠️ Repasa cápsulas 02-07
Si respondiste 0-1/5 → ❌ Re-lee módulo completo

Framework de decisión final

Matriz simplificada

PREGUNTA 1: ¿Cuántos vectores tienes/tendrás?
├─ <10K → numpy ✅
├─ 10K-100K → Evalúa latency
│   ├─ >500ms OK → numpy o pgvector ✅
│   └─ <500ms → ChromaDB ✅
└─ >100K → ChromaDB o Pinecone ✅

PREGUNTA 2: ¿Cuántos usuarios concurrentes?
├─ 1 (desarrollo) → numpy ✅
├─ 2-10 → ChromaDB ✅
└─ >10 → ChromaDB o Pinecone ✅

PREGUNTA 3: ¿Budget disponible?
├─ $0 → numpy o ChromaDB local ✅
├─ $20-100/mes → ChromaDB self-hosted ✅
└─ >$100/mes → Pinecone managed ✅

Recomendación por escenario

EscenarioVectoresUsuariosBudgetRecomendación
Prototipo/MVP<10K1-5$0numpy ✅
Startup early10K-100K5-20$0-50ChromaDB local ✅
Startup growth100K-1M20-100$50-150ChromaDB self ⚠️ o Pinecone ✅
Empresa>1M100+$150+Pinecone managed ✅
SaaS multi-tenant>5M500+$500+Pinecone Enterprise ✅

Transición a Módulo 2

Has completado el "POR QUÉ", ahora viene el "CÓMO"

Módulo 1 (completado): Por qué vector databases

  • ✅ Justificación de necesidad (RAG a escala)
  • ✅ Comparación con alternativas (SQL, NoSQL, numpy)
  • ✅ Decision framework (cuándo SÍ y cuándo NO)
  • ✅ Trade-offs cuantitativos (latency, cost, maintenance)

Módulo 2 (siguiente): Cómo funcionan vector databases

  • ⏳ Arquitectura interna (3 capas: indexing, query, storage)
  • ⏳ HNSW (Hierarchical Navigable Small World) - conceptual
  • ⏳ IVF (Inverted File Index) - trade-offs
  • ⏳ PQ (Product Quantization) - compresión
  • ⏳ Por qué logran O(log n) vs O(n) brute force

Módulo 3: Features esenciales para RAG

  • ⏳ Metadata filtering (filtrar antes de semantic search)
  • ⏳ Hybrid search (keyword + semantic)
  • ⏳ Multi-tenancy (aislar datos por usuario)

Módulo 4: ChromaDB Hands-On (PRIMER CÓDIGO)

  • ⏳ Setup, CRUD, similarity search
  • ⏳ Metadata filtering aplicado
  • ⏳ Proyecto: Semantic search básico (100 docs)

Por qué Módulo 2 es conceptual (no código)

Podrías preguntarte: "¿Por qué no ir directo a ChromaDB (Módulo 4)?"

Respuesta: Porque entender CÓMO funcionan internamente te permite:

  1. Debuggear: Si query tarda 500ms vs 50ms esperado → sabes que índice HNSW no está optimizado
  2. Optimizar: Sabes cuándo usar HNSW (accuracy) vs IVF (speed) vs PQ (memory)
  3. Decidir mejor: Entiendes trade-offs de ChromaDB vs Pinecone (no solo "Pinecone es mejor")
  4. Escalar: Sabes qué pasa cuando creces de 100K a 10M vectores

Sin entender arquitectura: Eres usuario de black-box (funciona pero no sabes por qué ni cómo optimizar)

Con entender arquitectura: Eres AI Engineer competente (entiendes tool y puedes optimizarla)

Checklist de completitud

Marca todo lo que puedes hacer ahora:

  • Explicar por qué RAG necesita buscar documentos en <500ms
  • Justificar por qué SQL/NoSQL no son óptimos para semantic search
  • Calcular latency de numpy según # de vectores
  • Identificar limitaciones de numpy (memoria, persistencia, concurrencia)
  • Aplicar los 4 criterios de decisión (scale, latency, persistencia, concurrencia)
  • Decidir si tu proyecto necesita vector DB (en <5 minutos)
  • Evaluar trade-offs (simplicidad vs performance vs costo)
  • Recomendar opción específica (numpy, pgvector, ChromaDB, Pinecone) según requisitos
  • Justificar tu recomendación con datos (latency, cost, maintenance)
  • Estar preparado para Módulo 2 (arquitectura interna de vector DBs)

Si marcaste 8-10/10 → ✅ Excelente, listo para Módulo 2
Si marcaste 6-7/10 → ⚠️ Bueno, repasa cápsulas específicas
Si marcaste <6/10 → ❌ Re-lee módulo completo

Resumen ejecutivo

Lo que aprendiste en Módulo 1:

El problema:

  • RAG necesita buscar 1M+ docs en <500ms
  • Brute force (numpy) tarda 1.5s → No production-ready
  • ANN (vector DBs) tarda 15ms → Production-ready

Las alternativas:

  • numpy: Excelente para <10K vectores (prototipo, desarrollo)
  • SQL + pgvector: Útil si ya usas Postgres, <100K vectores
  • NoSQL + vectores: Útil para hybrid search (keyword + semantic)
  • Vector DB dedicada: Óptimo para >100K vectores, <100ms latency, production

Cuándo usar cada una:

  • numpy: <10K vectores, 1 usuario, batch processing, $0 budget
  • pgvector: Ya tienes Postgres, <100K vectores, equipo SQL-first
  • ChromaDB: 10K-5M vectores, $0-100/mes budget, self-hosted OK
  • Pinecone: >1M vectores, <50ms latency crítico, managed preferred

Trade-offs:

  • Simplicidad (numpy) vs Performance (vector DB)
  • Costo $0 (self-hosted) vs Zero maintenance (managed)
  • Learning curve (numpy conocido) vs Features (metadata filtering, hybrid search)

Próximos pasos

Continúa con Módulo 2:

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

Aprenderás:

  1. Arquitectura de vector DB (indexing layer, query engine, storage layer)
  2. HNSW (Hierarchical Navigable Small World) - cómo logra O(log n)
  3. IVF (Inverted File Index) - trade-off accuracy por speed
  4. PQ (Product Quantization) - compresión de vectores
  5. Por qué estos algoritmos importan para RAG performance

Duración: 60-75 minutos
Enfoque: Conceptual riguroso SIN math avanzada

¿Listo? → Módulo 2: Cómo funcionan Vector Databases

Recursos adicionales

Para profundizar decisiones:

  1. Vector Database Decision Framework - Guía completa
  2. Cost Comparison Calculator - OpenAI + embeddings cost
  3. When to Use Managed vs Self-hosted - Decision guide
  4. RAG at Scale - Production considerations

Para preparar Módulo 2:

  1. HNSW Algorithm Explained - Preview conceptual
  2. Vector Database Internals - Arquitectura
  3. ANN Benchmarks - Comparación de algoritmos

Tiempo de lectura: 4-6 minutos
Siguiente: Módulo 2: Cómo funcionan Vector Databases

🎉 ¡Felicidades!

Has completado Módulo 1: Por qué Vector Databases para AI Engineers.

Ahora tienes el framework necesario para decidir cuándo necesitas vector DB y cuándo alternatives (numpy, SQL) son suficientes. Esta habilidad te ahorrará semanas de trabajo en futuros proyectos.

Siguiente: Aprende CÓMO funcionan internamente (Módulo 2) antes de implementar código (Módulo 4).

← AnteriorTrade-offs: Simplicidad vs Performance vs CostoSiguiente →Módulo 2: Cómo funcionan Vector Databases (Conceptual)