Módulo 6: Diseño de Sistemas de Búsqueda
8. Ejercicio Integrador: Diseñar un Sistema de Búsqueda
Descripción del ejercicio
Este es el ejercicio integrador del Módulo 6. Aquí vas a diseñar un sistema de búsqueda completo para un caso específico, tomando decisiones sobre chunking, embeddings, vector DB, ranking, y métricas.
El caso: Buscador académico
Contexto:
Universidad quiere un buscador interno para 100K papers científicos (PDF) en múltiples disciplinas (CS, física, biología, matemáticas).
Requisitos:
-
Queries típicas:
- Conceptuales: "métodos de optimización en machine learning"
- Exactas: "paper de Hinton 2012"
- Exploratorias: "últimos avances en quantum computing"
-
Funcionalidades:
- Búsqueda por autor, año, disciplina
- Sugerir papers relacionados (diversidad)
- Preferir papers recientes (boost temporal)
-
Restricciones:
- Latencia < 1 segundo
- Presupuesto limitado (preferir modelos locales si posible)
- Alta precision (académicos son usuarios exigentes)
Tarea: Diseña la arquitectura
Para cada componente, decide:
1. Chunking strategy
Ver solución sugerida
Estrategia: Hierarchical (por secciones)
Justificación:
- Papers tienen estructura: Abstract, Introduction, Methods, Results, Conclusion
- Cada sección es un chunk (contexto completo)
- Si sección > 1000 tokens → Dividir por párrafos
Tamaño: 800-1200 tokens por chunk
Overlap: 100 tokens (para transitions entre secciones)
Metadata por chunk:
paper_id: ID del paper originalsection: Abstract, Introduction, etc.author: Lista de autoresyear: Año de publicacióndiscipline: CS, Física, etc.
2. Embedding model
Ver solución sugerida
Modelo: Sentence-BERT local (allenai-specter, especializado en papers científicos)
Justificación:
- SPECTER: Entrenado en corpus científico (mejor que ada-002 para académicos)
- Local: $0 costo después de setup (presupuesto limitado)
- Dimensiones: 768D (menor que OpenAI pero suficiente)
Alternativa: OpenAI text-embedding-3-large (3072D) si presupuesto permite (mejor calidad).
3. Vector database
Ver solución sugerida
Database: Weaviate (self-hosted)
Justificación:
- Open-source: Sin costo de licencia
- HNSW: Rápido para 100K papers (~1M chunks)
- Filtros metadata: Soporta filtros por autor, año, disciplina
- Hybrid search: Keyword + semantic nativo
Alternativa: Qdrant (también open-source, similar features).
4. Search strategy
Ver solución sugerida
Estrategia: Híbrida (keyword + semantic) con detección de patrones
Algoritmo:
1. Detectar patrón de query:
¿Contiene "paper de [autor] [año]"?
→ Filtro exact: author + year + semantic search
¿Contiene disciplina ("en CS")?
→ Filtro: discipline=CS + semantic search
Sino:
→ Hybrid search (α=0.7, favor semantic)
2. Ejecutar búsqueda (top-100)
3. MMR (λ=0.6, diversificar por disciplina y autor)
4. Boost temporal (papers < 2 años: 1.3x)
5. Retornar top-20
5. Ranking strategy
Ver solución sugerida
Estrategias combinadas:
a. Híbrido (RRF):
Fusión keyword + semantic
→ RRF con k=60
b. MMR (diversidad):
λ = 0.6
Diversificar por:
- Disciplina (no 20 papers de CS si query es general)
- Autor (no 20 papers del mismo grupo)
c. Boost temporal:
Papers < 2 años: 1.3x
Papers 2-5 años: 1.1x
Papers > 5 años: 1.0x
6. Query processing latency
Ver solución sugerida
Breakdown:
1. Embedding de query (SPECTER local): 50ms
2. kNN search (Weaviate HNSW): 80ms
3. MMR (diversificar 100 → 20): 100ms
4. Total: ~230ms
Optimizaciones:
- Cache embeddings de queries frecuentes
- Pre-compute embeddings de papers (offline)
- Parallel execution de keyword + semantic
Latencia final esperada: 200-300ms ✅ (< 1 segundo)
7. Evaluation metrics
Ver solución sugerida
Métricas:
a. Precision@10:
De los 10 primeros resultados, ¿cuántos son relevantes?
Target: > 0.80
b. NDCG@20:
Calidad del ranking (orden importa).
Target: > 0.75
c. Diversity (disciplinas en top-20):
¿Cuántas disciplinas diferentes aparecen?
Target: ≥ 3 (si query es interdisciplinaria)
d. Latency:
Target: < 500ms (p95)
Evaluation set:
- 100 queries etiquetadas por académicos
- Cobertura de disciplinas y tipos de query
Diagrama de arquitectura (solución)
┌─────────────────────────────────────────────────┐
│ 100K PAPERS (PDF) │
└────────────┬────────────────────────────────────┘
│
v
┌────────────────┐
│ Hierarchical │ (Por secciones)
│ Chunking │
└────────┬───────┘
│
v
┌────────────────┐
│ SPECTER │ (Embeddings locales)
│ 768D │
└────────┬───────┘
│
v
┌─────────────────────────────────────┐
│ WEAVIATE (self-hosted) │
│ - HNSW index │
│ - Metadata: author, year, discipline│
└────────┬────────────────────────────┘
│
│
┌────────┴────────┐
│ │
v v
┌─────────┐ ┌──────────────┐
│ Keyword │ │ Semantic │
│ BM25 │ │ (cosine) │
└────┬────┘ └──────┬───────┘
│ │
└────────┬───────┘
│
v
┌────────────────┐
│ RRF Fusion │
└────────┬───────┘
│
v
┌────────────────┐
│ MMR │ (λ=0.6, diversidad)
└────────┬───────┘
│
v
┌────────────────┐
│ Boost Temporal │ (< 2 años: 1.3x)
└────────┬───────┘
│
v
┌────────────────┐
│ Top-20 │
└────────────────┘
Resumen del ejercicio
Lo que hiciste:
- ✅ Diseñaste chunking strategy (hierarchical)
- ✅ Elegiste embedding model (SPECTER local)
- ✅ Seleccionaste vector DB (Weaviate)
- ✅ Definiste search strategy (híbrida + MMR)
- ✅ Estableciste ranking (RRF + MMR + boost)
- ✅ Estimaste latencia (200-300ms)
- ✅ Definiste métricas (Precision, NDCG, diversity)
Intuición consolidada:
"Diseñar un sistema de búsqueda requiere decisiones informadas en cada componente: chunking, embeddings, vector DB, ranking. No hay solución única; depende de requisitos (latencia, presupuesto, precisión) y tipo de queries."
Conclusión del Módulo 6
Felicidades por completar Módulo 6: Diseño de Sistemas de Búsqueda. 🎉
Lo que lograste:
- ✅ Entiendes arquitectura end-to-end (indexación, query processing)
- ✅ Diseñas pipeline de indexación (chunking, embeddings)
- ✅ Optimizas query processing (kNN, reranking)
- ✅ Implementas ranking avanzado (RRF, MMR, boost)
- ✅ Evalúas calidad (precision, recall, MRR, NDCG)
- ✅ Analizas casos de estudio (RAG, e-commerce, soporte)
Intuición clave del módulo:
Un sistema de búsqueda efectivo integra múltiples técnicas (chunking, embeddings, ANN, ranking, filtros) en una arquitectura coherente. Las decisiones de diseño dependen de requisitos específicos: latencia, presupuesto, tipo de queries, y precisión esperada.
Próximo módulo: Módulo 7: RAG (Retrieval-Augmented Generation) — Integración completa con LLMs.