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

Cuándo NO necesitas vector database

Siguiente →

Descripción de la cápsula

No todo proyecto necesita vector database. A veces numpy es suficiente. A veces SQL con pgvector es mejor. A veces no necesitas embeddings en absoluto.

Esta cápsula te salva de sobre-ingenierizar. Ver desarrolladores gastar 2 semanas aprendiendo Pinecone cuando tenían 5K vectores (numpy tardaría 8ms) es común. Esta cápsula evita ese error.

Aprenderás señales claras de que NO necesitas vector DB y qué alternativas usar en su lugar.

Señal #1: Tienes <10K vectores

El punto de inflexión

numpy performance con diferentes escalas:

    1K vectores:    2-3ms    ✅ Excelente (mejor que vector DB overhead)
    5K vectores:    8-10ms   ✅ Excelente
   10K vectores:   15-20ms   ✅ Aceptable
   50K vectores:   75-100ms  ⚠️ Zona gris
  100K vectores:  150-200ms  ❌ Lento

Decision rule:

def should_use_vector_db(n_vectors):
    if n_vectors < 10_000:
        return False, "numpy es más simple y suficientemente rápido"
    elif n_vectors < 100_000:
        return "maybe", "evaluar latency requirements"
    else:
        return True, "vector DB necesaria para performance"

Caso: Prototipo MVP con 2K documentos

Setup:

  • Startup construyendo chatbot de documentación interna
  • 2,000 docs (6,000 chunks)
  • 10 empleados usando
  • Prototipo para validar concepto

Con numpy:

import numpy as np
from openai import OpenAI

# Cargar embeddings (6K vectores)
embeddings = np.load('embeddings.npy')  # Shape: (6000, 1536)

# Query
client = OpenAI()
query_emb = client.embeddings.create(
    input="how to deploy?",
    model="text-embedding-3-small"
).data[0].embedding

# Search (brute force)
similarities = np.dot(embeddings, query_emb)
top_5 = np.argsort(similarities)[-5:][::-1]

# Latency: ~10ms ✅ Excelente

¿Por qué numpy es suficiente?

  • Scale: 6K vectores → 10ms latency (excelente)
  • Simplicidad: pip install numpy (vs aprender ChromaDB API)
  • Costo: $0 (vs Pinecone $70/mes)
  • Prototipo: Si concepto no funciona, no perdiste tiempo en setup de vector DB

Decisión: ✅ numpy es mejor opción (no sobre-ingenierices)

Señal #2: No hay requisito de latency

Batch processing vs real-time

Si tu use case es:

  • Análisis offline (no usuarios esperando)
  • ETL pipelines (procesa overnight)
  • Research (exploración sin prisa)
  • Clustering (una vez, no repetido)

→ Latency no importa. numpy es suficiente.

Caso: Clustering de 500K papers científicos

Setup:

  • Research: Agrupar 500K papers en clusters temáticos
  • No hay usuarios (análisis offline)
  • Puede tardar horas (no hay prisa)

Con numpy (brute force):

import numpy as np
from sklearn.cluster import KMeans

# Cargar embeddings (500K vectores)
embeddings = np.load('papers_embeddings.npy')  # Shape: (500000, 1536)

# Clustering (tardará ~30-60 minutos, pero solo se hace 1 vez)
kmeans = KMeans(n_clusters=100, random_state=42)
clusters = kmeans.fit_predict(embeddings)

# Analizar clusters
for cluster_id in range(100):
    papers_in_cluster = np.where(clusters == cluster_id)[0]
    print(f"Cluster {cluster_id}: {len(papers_in_cluster)} papers")

¿Por qué numpy es suficiente?

  • No hay usuarios esperando (offline)
  • Latency no importa (puede tardar 1 hora)
  • Se ejecuta 1 vez (no necesitas optimizar para repetición)

Decisión: ✅ numpy es mejor opción (vector DB sería overhead innecesario)

Señal #3: Desarrollo/experimentación local

Un solo developer iterando

Si estás:

  • Prototipando diferentes estrategias de chunking
  • Experimentando con modelos de embeddings
  • Iterando en prompt engineering
  • Desarrollo en laptop local

→ numpy es más rápido de iterar

Caso: Developer experimentando con RAG

Setup:

  • 1 developer probando diferentes estrategias
  • Dataset: 8K documentos (24K chunks)
  • Iteración rápida (cambiar, re-run, evaluar)

Con numpy:

# Ciclo de experimentación:
# 1. Generar embeddings → guardar .npy (5 minutos)
# 2. Probar retrieval → numpy search (20ms)
# 3. Evaluar resultados → ajustar strategy
# 4. Repetir

# Total iteration time: 10-15 minutos

# Con vector DB:
# 1. Generar embeddings
# 2. Setup ChromaDB/Pinecone (primera vez: 30 min)
# 3. Insert embeddings (10 minutos)
# 4. Probar retrieval
# 5. Evaluar
# 6. Cambiar strategy → re-insert embeddings (10 min)
# 7. Repetir

# Total iteration time: 25-30 minutos (2x más lento)

¿Por qué numpy es mejor para experimentación?

  • Sin overhead de setup (solo pip install)
  • Cambios rápidos (reload .npy < 1 segundo)
  • No necesitas aprender API nueva (focus en experimentación)

Decisión: ✅ numpy para desarrollo, migrar a vector DB solo cuando strategy está validada y vas a producción

Señal #4: No necesitas embeddings en absoluto

Keyword search puede ser suficiente

Casos donde keyword search >> semantic search:

  1. Búsqueda exacta de términos técnicos:

    • "ERROR-404" → keyword search perfecto
    • Semantic search: "error not found" (no exacto)

  2. Nombres propios (personas, lugares, productos):

    • "John Smith" → keyword busca exactamente eso
    • Embeddings: "John" y "Smith" se semantizan mal

  3. Códigos / IDs:

    • "ORDER-12345" → keyword search único match
    • Embeddings: vectoriza "order twelve thousand..." (inútil)

  4. SQL queries / código:

    • "SELECT * FROM users WHERE age > 30" → keyword busca sintaxis exacta
    • Semantic search: entende concepto pero pierde sintaxis

Caso: Búsqueda en base de conocimiento de soporte

Setup:

  • Artículos de troubleshooting con error codes
  • Usuarios buscan "ERROR-404", "CONNECTION-TIMEOUT", etc.
  • Necesitan match exacto, no semántico

Con keyword search (Elasticsearch):

POST /articles/_search
{
  "query": {
    "match": {
      "content": {
        "query": "ERROR-404",
        "operator": "and"
      }
    }
  }
}

Latency: 10-50ms (excelente)
Accuracy: 100% (match exacto)

Con semantic search (embeddings + vector DB):

# Query: "ERROR-404"
# Embedding: [0.12, -0.34, 0.56, ...]
# Resultados: Docs sobre "errors", "404", pero también "403", "500"
# Accuracy: 60-70% (no es exacto)

Decisión: ✅ Keyword search es mejor (NO necesitas embeddings ni vector DB)

Cuándo combinar: Hybrid search (keyword + semantic) en Módulo 3

Señal #5: Dataset estático (no crece)

Read-only datasets

Si tu dataset:

  • No cambia (histórico, archivo)
  • Se genera 1 vez (no updates)
  • No se agregan docs nuevos

→ numpy precomputado puede ser óptimo

Caso: Archive de Wikipedia (2023 snapshot)

Setup:

  • Wikipedia dump de 2023 (6M artículos)
  • Dataset estático (no cambia)
  • Solo lectura (búsqueda, no escritura)

Estrategia óptima:

# 1. Generar embeddings (1 vez, offline)
# Tarda: 10-20 horas (6M docs × 3 chunks = 18M vectores)

# 2. Guardar en formato optimizado
np.save('wikipedia_embeddings.npy', embeddings)  # 110GB

# 3. Para queries:
#    Opción A: Cargar TODO en RAM (si tienes 128GB+ RAM)
embeddings = np.load('wikipedia_embeddings.npy')  # Tarda 5-10 min, pero 1 sola vez
# Luego: queries a 50-100ms (brute force en RAM ultra-optimizado)

#    Opción B: FAISS con PQ (compresión)
import faiss
index = faiss.read_index('wikipedia_faiss.index')
# Queries: 200-300ms, memoria: 30GB (vs 110GB)

¿Vector DB o numpy?

  • Vector DB: Overhead innecesario (dataset no crece, no necesitas writes)
  • numpy/FAISS: Óptimo (1-time setup, queries rápidas)

Decisión: ✅ numpy/FAISS (especializado), NO vector DB (over-engineering)

Señal #6: Budget cero (estudiante/hobby)

Aprendizaje sin costo

Si:

  • Estudiante aprendiendo RAG
  • Hobby project (no ingresos)
  • No puedes gastar $70/mes (Pinecone)
  • Laptop local (no server)

→ numpy o ChromaDB local (gratis)

Caso: Estudiante construyendo portfolio RAG

Setup:

  • Estudiante construyendo chatbot sobre sus notas de clase
  • 3,000 notas (9,000 chunks)
  • Solo él usa (1 usuario)
  • Budget: $0

Opciones:

  1. numpy: Gratis, 15ms retrieval, suficiente para 9K vectores ✅
  2. ChromaDB local: Gratis, 5ms retrieval, más features ✅
  3. Pinecone: $70/mes, 3ms retrieval, innecesario ❌

Decisión: ✅ numpy o ChromaDB local (cero costo, suficiente para portfolio)

Cuándo migrar a Pinecone: Si proyecto se convierte en startup con funding (entonces $70/mes es razonable)

Decision tree: ¿Necesitas vector DB?

Flowchart

¿Cuántos vectores tienes?
├─ <10K → numpy suficiente ✅
├─ 10K-100K → ¿Necesitas <100ms latency?
│   ├─ NO → numpy suficiente ✅
│   └─ SÍ → Vector DB recomendada ⚠️
└─ >100K → Vector DB necesaria ✅

¿Tienes requisito de latency?
├─ NO (batch/offline) → numpy suficiente ✅
└─ SÍ (<500ms) → ¿Cuántos vectores?
    ├─ <10K → numpy suficiente ✅
    └─ >10K → Vector DB necesaria ✅

¿Múltiples usuarios concurrentes?
├─ NO (1 usuario) → numpy suficiente ✅
└─ SÍ (>10 usuarios) → ¿Cuántos vectores?
    ├─ <10K → numpy con locks ⚠️
    └─ >10K → Vector DB necesaria ✅

¿Dataset crece dinámicamente?
├─ NO (estático) → numpy/FAISS suficiente ✅
└─ SÍ (agregan docs) → ¿Con qué frecuencia?
    ├─ Raro (1 vez/mes) → numpy recargable ✅
    └─ Frecuente (diario) → Vector DB necesaria ✅

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

Resumen

Cuándo NO necesitas vector DB:

  1. ✅ <10K vectores → numpy suficiente (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 a vector DB:

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

Por qué importa:

  • No sobre-ingenierizar: Si numpy cumple requisitos, ahorra tiempo y complejidad
  • No sub-ingenierizar: Si necesitas vector DB, no pierdas tiempo con numpy inadecuado
  • Empezar simple (numpy) → Escalar cuando necesario (vector DB)

Siguiente cápsula: Trade-offs completos: simplicidad vs performance vs costo (comparación cuantitativa).

Recursos adicionales

  1. When NOT to Use Vector Databases - Anti-patterns
  2. NumPy for Semantic Search - Simple approach
  3. FAISS for Static Datasets - Offline optimization
  4. Keyword vs Semantic Search - Cuándo usar cada uno
  5. pgvector Guide - SQL alternative
  6. Cost Optimization for AI - Budget considerations

Tiempo de lectura: 6-8 minutos
Siguiente: 07-trade-offs-simplicidad-vs-performance.md

← AnteriorCuándo SÍ necesitas vector databaseSiguiente →Trade-offs: Simplicidad vs Performance vs Costo