Módulo 4: Búsqueda por Proximidad

7. Ejercicio Integrador: Diseñar Estrategia de Búsqueda

Siguiente →

Descripción del ejercicio

Este es el ejercicio integrador del Módulo 4. Aquí vas a aplicar todo lo visto: dado un caso de uso (tamaño de dataset, requisitos de latencia y precisión), decidirás qué índice usar, qué parámetros configurar, y justificarás tus decisiones.

Parte 1: Casos de uso

Para cada caso, decide:

  1. ¿Qué índice usar? (Brute force, HNSW, IVF, IVF-PQ)
  2. ¿Qué parámetros configurar?
  3. ¿Qué precisión y latencia esperas?

Caso 1: Blog personal

Contexto:

  • 1,000 artículos
  • Búsqueda semántica en el blog
  • Tráfico bajo (10 queries/día)

Requisitos:

  • Latencia: < 500ms aceptable
  • Precisión: Alta preferida
  • Budget: Mínimo (hosting barato)
Ver solución

Índice: Brute force

Justificación:

  • 1,000 vectores → Brute force es ~10ms (muy rápido)
  • Sin inversión en índice complejo
  • Precisión 100% garantizada
  • Tráfico bajo → No necesita optimización extrema

Implementación: Vector database simple o incluso cálculos in-memory.

Caso 2: E-commerce con catálogo mediano

Contexto:

  • 200,000 productos
  • Búsqueda semántica de productos
  • Tráfico medio (1,000 queries/día)

Requisitos:

  • Latencia: < 100ms
  • Precisión: ~98%
  • Budget: Medio
Ver solución

Índice: HNSW

Parámetros:

ef_construction = 200
M = 32
ef_search = 100

Esperado:

  • Latencia: ~20-30ms
  • Precisión: ~98%
  • Memoria: ~600K vectores equivalentes (3x)

Justificación:

  • 200K vectores → Sweet spot para HNSW
  • Latencia y precisión cumplen requisitos
  • Costo moderado de infraestructura

Vector database: Weaviate o Qdrant (HNSW por defecto)

Caso 3: Empresa con documentación masiva

Contexto:

  • 50 millones de documentos internos
  • Búsqueda semántica para empleados
  • Tráfico alto (100,000 queries/día)

Requisitos:

  • Latencia: < 50ms
  • Precisión: ~95% aceptable
  • Budget memoria: Limitado
Ver solución

Índice: IVF con Product Quantization (IVF-PQ)

Parámetros:

nlist = 7000 (sqrt(50M) aprox)
nprobe = 15
PQ compression = 8x

Esperado:

  • Latencia: ~30-40ms
  • Precisión: ~94-96%
  • Memoria: ~6.25M vectores equivalentes (compresión 8x)

Justificación:

  • 50M vectores → HNSW sería costosísimo en memoria
  • IVF-PQ comprime 8x → Viable económicamente
  • Precisión ~95% es aceptable (los "perdidos" son marginales)

Vector database: FAISS o Milvus (soporte completo IVF-PQ)

Parte 2: Ajustar parámetros

Escenario:

Tienes un sistema HNSW con:

Dataset: 5M vectores
ef_construction = 200
M = 32
ef_search = 100

Resultados actuales:

  • Latencia: 25ms (promedio)
  • Precisión: 98%

Pregunta 2.1:

Usuario se queja de que búsqueda es "lenta" (espera < 15ms). ¿Qué ajustas?

Ver solución

Ajuste: Reducir ef_search

ef_search = 50  (de 100)

Esperado:

  • Latencia: ~15ms ✅
  • Precisión: ~96% (ligera caída)

Justificación: Menos nodos explorados → Más rápido, ligeramente menos preciso. Trade-off aceptable si 96% es suficiente.

Pregunta 2.2:

Usuario reporta que algunos resultados relevantes no aparecen. ¿Qué ajustas?

Ver solución

Ajuste: Aumentar ef_search

ef_search = 200  (de 100)

Esperado:

  • Latencia: ~40ms (más lento)
  • Precisión: ~99% ✅

Justificación: Más nodos explorados → Mayor probabilidad de encontrar todos los top-K. Usuario prefiere precisión sobre velocidad.

Parte 3: Escalabilidad

Pregunta 3.1:

Tu sistema tiene actualmente 1M vectores con HNSW. Estimas crecer a 10M en 6 meses. ¿Qué planeas?

Ver reflexión

Opción A: Mantener HNSW

  • Ventaja: Misma precisión (~99%)
  • Desventaja: Memoria crece 10x (costoso)
  • Requiere: Upgrade de infraestructura

Opción B: Migrar a IVF-PQ

  • Ventaja: Memoria crece menos (compresión)
  • Desventaja: Precisión cae a ~95%
  • Requiere: Rebuild completo del índice

Decisión: Depende de presupuesto vs requisitos de precisión.

Recomendación: Empezar planificación de migración a IVF si presupuesto es limitado.

Pregunta 3.2:

Actualmente insertas 10,000 vectores nuevos/día. ¿Cómo manejas inserciones?

Ver reflexión

Con HNSW:

Opción 1 (incremental): Insertar directamente
- Problema: Calidad del grafo degrada con el tiempo
- Solución: Rebuild periódico (ej: cada semana)

Opción 2 (batch): Acumular inserciones, rebuild 1x/semana
- Ventaja: Calidad del grafo óptima
- Desventaja: Nuevos vectores no disponibles inmediatamente

Con IVF:

Insertar directamente (reasignar a cluster)
- Más fácil que HNSW
- Re-clustering periódico (ej: cada mes)

Decisión típica: Batch semanal con HNSW (balance calidad-frecuencia).

Parte 4: Debugging

Problema: Latencia alta (200ms vs esperado 30ms)

Posibles causas:

  1. ef_search demasiado alto
  2. Dataset mucho más grande de lo esperado
  3. Cold start (primer query después de deployment)
  4. Índice no cargado en memoria (leyendo de disco)

¿Cómo investigas?

Ver guía

Paso 1: Verificar tamaño de dataset

Si dataset creció de 1M a 10M → Esperado que sea más lento

Paso 2: Revisar configuración

ef_search = 500 → Demasiado alto, reducir a 100

Paso 3: Warm-up

Hacer queries dummy después de deployment

Paso 4: Monitorear memoria

Si índice no cabe en RAM → Swap to disk → Lento
Solución: Upgrade RAM o usar IVF-PQ (compresión)

Resumen del ejercicio

Lo que hiciste:

  1. ✅ Decidiste índices para 3 casos de uso
  2. ✅ Ajustaste parámetros según requisitos
  3. ✅ Planeaste escalabilidad (1M → 10M)
  4. ✅ Debuggeaste problemas comunes

Intuición consolidada:

"No hay un índice perfecto para todo. La decisión depende de tamaño, latencia, precisión y presupuesto. HNSW es el sweet spot para mayoría de casos (100K-10M); IVF-PQ para escala masiva."

Conclusión del Módulo 4

Felicidades por completar el Módulo 4: Búsqueda por Proximidad. 🎉

Lo que lograste:

  1. ✅ Entiendes el problema de búsqueda en millones de vectores
  2. ✅ Conoces kNN conceptualmente
  3. ✅ Comparas índices (exactos vs aproximados)
  4. ✅ Entiendes HNSW (grafos jerárquicos)
  5. ✅ Entiendes IVF (clustering)
  6. ✅ Decides qué índice usar según caso
  7. ✅ Ajustas parámetros para optimizar

Intuición clave del módulo:

Vector databases no hacen búsqueda exhaustiva (lenta). Usan índices aproximados (HNSW, IVF) que son 1000x más rápidos con ~95-99% precisión. El trade-off (velocidad vs perfección) es aceptable en producción.

Próximo módulo: Módulo 5: Keyword vs Semantic Search — Comparar búsqueda tradicional vs vectorial, cuándo usar cada una.

← Anterior6. Trade-offs y Decisiones: Elegir el Índice CorrectoSiguiente →1. Introducción al Módulo: Keyword vs Semantic Search