Módulo 5: Hybrid Search — combinando keyword + semantic para queries que necesitan ambas

Cápsula 07: Decision framework — qué estrategia de hybrid search elegir

Siguiente →

Descripción de la cápsula

Cubrimos los componentes individuales: BM25 (cápsula 03), RRF (04), weighted blending (05), Elasticsearch (06). La pregunta operativa que cierra el módulo: dado un proyecto nuevo, ¿qué combinación eliges?

Esta cápsula consolida lo aprendido en un decision framework reproducible. Vas a aprender a tomar la decisión en menos de 10 minutos: ¿semantic-only? ¿hybrid simple? ¿hybrid con weighted? ¿in-memory o Elasticsearch? Cada elección tiene trade-offs concretos que vas a poder defender con datos.

Al finalizar esta cápsula serás capaz de:

  • ✅ Comparar las cuatro arquitecturas de retrieval sobre seis dimensiones
  • ✅ Aplicar un flowchart de 5 preguntas para elegir estrategia
  • ✅ Justificar la elección a un Tech Lead con argumentos numéricos
  • ✅ Diseñar un plan de evolución (empezar simple, escalar gradualmente)
  • ✅ Identificar los anti-patrones comunes al "elegir todo de una vez"
  • ✅ Decidir cuándo migrar entre estrategias mientras tu producto crece

Tiempo estimado: 25-30 minutos

Las cuatro arquitecturas posibles

Arquitectura A: Semantic-only

Query → Embedding → Vector DB → Top-K → LLM
  • Cuándo: queries puramente conceptuales, MVP, equipo sin recursos.
  • Recall típico: 85-90% en queries semánticas, 50-70% en queries con identificadores.
  • Latencia: 100-300ms.
  • Costo: $0-50/mes para 100K queries (solo embeddings).
  • Mantenimiento: mínimo.

Arquitectura B: BM25-only

Query → BM25 (rank_bm25 o ES) → Top-K → LLM
  • Cuándo: corpus puramente exact-match (error codes, code search, SKUs).
  • Recall típico: 90%+ en queries exactas, 40-50% en queries semánticas.
  • Latencia: 5-30ms.
  • Costo: $0-30/mes (compute mínimo).
  • Mantenimiento: bajo (tokenizer cuidadoso).

Arquitectura C: Hybrid simple (semantic + BM25 + RRF)

Query ──┬→ Embedding → Vector DB → Top-30 ──┐
        │                                    │→ RRF → Top-K → LLM
        └→ BM25 → Top-30 ─────────────────────┘
  • Cuándo: corpus mixto (técnico + narrativo), producción típica. Default razonable.
  • Recall típico: 88-95%.
  • Latencia: 150-400ms (paralelizable).
  • Costo: $30-100/mes para 100K queries.
  • Mantenimiento: medio (dos motores).

Arquitectura D: Hybrid avanzado (weighted + routing + ES)

Query → Detector tipo → α dinámico
        ├→ Elasticsearch BM25 (top-30)  ──┐
        └→ Vector DB (top-30)           ──┼→ Weighted blending → Top-K → LLM
                                          (después rerank opcional)
  • Cuándo: corpus a escala (>1M docs), variedad de query types, producto crítico.
  • Recall típico: 92-97%.
  • Latencia: 200-500ms.
  • Costo: $200-1000/mes.
  • Mantenimiento: alto (ES cluster, tuning de α, routing).

Comparación cuantitativa

Arquitectura          Recall@5    Latency p95    Setup time    Costo/mes (100K queries)
─────────────────────────────────────────────────────────────────────────────────────────
A: Semantic-only      85%         200ms          1 día         $20
B: BM25-only          82%         15ms           2 días        $5
C: Hybrid simple      92%         320ms          3-5 días      $50
D: Hybrid avanzado    95%         400ms          2-3 semanas   $300

Lectura: las opciones C y D dan el mejor recall, pero el "salto" más grande es de A/B a C (+10 puntos). De C a D el salto es marginal (+3 puntos) por mucho más esfuerzo.

Regla práctica: la mayoría de proyectos pueden quedarse en arquitectura C. D solo se justifica con eval set robusto que demuestre que C no alcanza.

Decision framework de 5 preguntas

1. ¿Tu corpus es 100% texto narrativo (sin identificadores, errores, comandos)?
   → Sí: Arquitectura A (semantic-only). Ahorrate la complejidad.
   → No: continuar a 2.

2. ¿Las queries de tu producto son 95%+ con identificadores exactos?
   → Sí: Arquitectura B (BM25-only). Probable que sea code search o lookup.
   → No: continuar a 3 (necesitas hybrid).

3. ¿Tu corpus es <1M documentos?
   → Sí: continuar a 4 con `rank_bm25` in-memory.
   → No: vas a necesitar Elasticsearch (cápsula 06).

4. ¿Tienes eval set ≥50 queries con ground truth?
   → No: arquitectura C (hybrid simple con RRF). Sin eval set no puedes tunear α.
   → Sí: continuar a 5.

5. ¿Tu eval set muestra que una señal es notablemente mejor (>10 pts) para algún tipo de query?
   → No: arquitectura C es suficiente.
   → Sí: arquitectura D con weighted + routing.

Aplicado a casos reales

ProyectoRecomendaciónPor qué
MVP de chatbot SaaSA: semantic-onlyIterar rápido, ya optimizar después
Buscador de Stack OverflowC: hybrid simpleMezcla de identificadores + queries semánticas
Catálogo de productos con SKUsB: BM25-onlyCódigos exactos dominan
Sistema legal con queries técnicasC: hybrid simpleVocabulario específico + queries narrativas
Buscador interno enterprise (5M docs, equipo grande)D: hybrid avanzadoEscala justifica complejidad
Asistente de papers académicosA: semantic-onlyQueries conceptuales puras
Help desk de empresa SaaSC: hybrid simpleMezcla típica

Plan de evolución gradual

No empieces con arquitectura D. Construye progresivamente:

┌─────────────────────────────────────────────────────────────────┐
│ Fase 1: MVP                                                       │
│ Arquitectura A (semantic-only)                                    │
│ Tiempo: 1 día                                                     │
│ Métricas a validar: ¿precision/recall son aceptables?            │
└────────────────────────┬─────────────────────────────────────────┘
                         │ Si recall < 80% en queries técnicas
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│ Fase 2: Hybrid simple                                             │
│ Arquitectura C (semantic + BM25 + RRF)                            │
│ Tiempo: 3-5 días adicionales                                      │
│ Métricas a validar: ¿recall sube +10 pts?                        │
└────────────────────────┬─────────────────────────────────────────┘
                         │ Si necesitas más calidad o llegaste a 1M+ docs
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│ Fase 3: ES + tuning                                               │
│ Arquitectura D parcial (ES + weighted blending)                   │
│ Tiempo: 2-3 semanas adicionales                                   │
│ Métricas a validar: ¿recall sube otros +3-5 pts?                 │
└────────────────────────┬─────────────────────────────────────────┘
                         │ Si tienes tráfico variado y queries específicas
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│ Fase 4: Routing dinámico                                          │
│ Arquitectura D completa (routing por tipo de query)               │
│ Tiempo: 1 semana adicional                                        │
│ Métricas a validar: ¿recall por tipo de query mejora?            │
└─────────────────────────────────────────────────────────────────┘

Beneficio del plan gradual:

  • Cada fase tiene una validación clara antes de pasar a la siguiente.
  • Si fase 1 funciona, no gastas tiempo en fase 2.
  • Cada fase es reversible (rollback con feature flag).

Anti-patrón: empezar con arquitectura D directamente. Triplicas el setup time, mantienes complejidad innecesaria, y a veces descubres que A o C eran suficientes.

Cuándo NO usar hybrid search

A pesar de los beneficios, hay casos donde hybrid search es overkill:

Caso¿Hybrid?Razón
Corpus puramente narrativo (literatura, periodismo)❌ NoSemantic alcanza, BM25 agrega ruido
MVP en stage early con <5K docs❌ NoEl problema dominante es otro (probablemente chunking)
Latencia ultra-estricta (<100ms total)❌ NoOverhead de paralelización + fusión rompe SLA
Equipo de 1-2 personas sin DevOps⚠️ Tal vezMantener dos motores agrega operacional overhead
Producto donde "respuesta lenta pero perfecta" gana sobre "rápida y mediocre"⚠️ Considerar más profundoEl problema puede ser de generation, no retrieval

Migrar entre arquitecturas

De A a C (agregar BM25 + RRF)

Trigger: recall@5 < 80% sobre queries con identificadores.

Esfuerzo: 3-5 días de ingeniería.

Riesgo: bajo. RRF funciona out-of-the-box, sin tuning.

Métrica de protección: precision (no debe caer >2% si BM25 está bien tokenizado).

De C a D (Elasticsearch + weighted + routing)

Trigger: recall@5 estancado en 90% y necesitas 95%+, O corpus pasó 1M docs.

Esfuerzo: 2-3 semanas de ingeniería + 1 semana de tuning.

Riesgo: medio. Requiere eval set robusto para tunear α y validar routing.

Métrica de protección: complejidad operacional. Si el equipo no tiene capacidad para mantener ES, retroceder a C.

Migrar HACIA ATRÁS (de C a A)

A veces lo correcto es simplificar. Casos:

  • El producto pivoteó a corpus puramente narrativo. BM25 ya no aporta.
  • El corpus se redujo a <50K docs. La complejidad no se justifica.
  • Detectaste que el 95% de las queries son semánticas, BM25 dispara muy poco.

Migrar a arquitectura más simple es legítimo si los datos lo justifican.

Anti-patrones comunes

Anti-patrón 1: implementar todo de una vez

El error: primer sprint del proyecto, equipo decide "vamos con hybrid avanzado desde el inicio".

Síntoma: 3 semanas de setup antes de validar siquiera que el producto tiene encaje. Se descubre que la mitad del trabajo era innecesario.

Cómo prevenir: plan gradual. Cada fase con criterio de validación.

Anti-patrón 2: copiar arquitectura de otro producto

El error: "X empresa usa hybrid con weighted blending → nosotros también".

Síntoma: la complejidad no se justifica para tu caso. Tu corpus, tu volumen, tus queries son distintas.

Cómo prevenir: justificar cada componente con datos propios. Si X empresa hace algo, descubre por qué lo hace antes de copiarlo.

Anti-patrón 3: ignorar el costo operacional

El error: elegir arquitectura D sin considerar que el equipo de 3 personas no puede mantener ES en producción.

Síntoma: ES queda mal configurado, hay outages, alguien tiene que aprender ES de cero a las 3am cuando algo se rompe.

Cómo prevenir: evaluar capacidad operacional del equipo en la decisión, no solo calidad técnica.

Anti-patrón 4: tunear α sin eval set robusto

El error: weighted blending con α elegido por intuición.

Síntoma: después de cambios sutiles en el corpus, α óptimo cambió, pero nadie se entera. Calidad degrada lentamente.

Cómo prevenir: α debe ser determinado por grid search sobre eval set. Re-evaluar trimestralmente.

Anti-patrón 5: no medir precision al agregar BM25

El error: activas BM25, recall sube 10%, deployas. Nadie miró precision.

Síntoma: BM25 agregó ruido. Top-5 ahora tiene 1-2 docs irrelevantes que el LLM no ignora bien. Calidad de respuesta empeora.

Cómo prevenir: medir precision Y recall juntos. Si precision cae >3%, BM25 está mal calibrado (probablemente tokenizer).

Ejercicio aplicado

Escenario: evalúa tres proyectos y decide qué arquitectura recomendar.

Proyecto X: SaaS de soporte técnico. 80K artículos de documentación. Queries del log:

  • 30% conceptuales ("how to deploy")
  • 50% identificadores ("kubectl get pods")
  • 20% mixtas

Stack actual: solo semantic. Recall@5 = 65%. Equipo: 4 ingenieros.

Proyecto Y: Plataforma de literatura. 500K novelas + análisis literarios. Queries: "novelas con narradores no confiables", "metáfora del agua en la literatura argentina".

Recall@5 actual con semantic = 87%. Equipo: 2 ingenieros.

Proyecto Z: E-commerce con 10M productos. Queries: 70% SKUs y modelos exactos, 30% descripciones de productos.

Recall@5 actual con semantic = 48%. Equipo: 8 ingenieros con DevOps dedicado.

Tu trabajo:

  1. Aplica el framework a cada proyecto.
  2. Justifica la decisión.
  3. Define plan de migración con orden de fases.
Solución

Proyecto X — Recomendación: Arquitectura C (hybrid simple con RRF)

Aplicación del framework:

  1. ¿Corpus 100% narrativo? No (50% son identificadores).
  2. ¿95%+ identificadores? No (solo 50%).
  3. ¿Corpus <1M? Sí (80K docs). → rank_bm25 alcanza.
  4. ¿Eval set ≥50 queries? Asumir que pueden construirlo. → fase 4 dice arquitectura C.

Justificación:

  • 50% del tráfico son queries con identificadores que semantic falla. Hybrid es necesario.
  • Corpus chico (80K) → no necesitas ES.
  • Equipo de 4 → puede mantener dos motores sin problema.

Plan:

  • Fase 1 (3 días): implementar BM25 con rank_bm25 + tokenizer técnico.
  • Fase 2 (1 día): integrar RRF (cápsula 04).
  • Fase 3 (1 semana): validar sobre eval set de 80 queries (proporcional a las % del log).
  • Fase 4 (1 semana): A/B test producción.

Mejora esperada: recall 65% → 85-90%.

Proyecto Y — Recomendación: Arquitectura A (semantic-only). NO migrar.

Aplicación del framework:

  1. ¿Corpus 100% narrativo? Sí (literatura). → arquitectura A.

Justificación:

  • Recall ya está en 87% — alto. No hay problema de exactitud que BM25 solucione.
  • Queries son puramente semánticas ("metáfora del agua") — BM25 agregaría ruido.
  • Equipo de 2 → la complejidad de hybrid no se justifica.

Plan:

  • No tocar la arquitectura. Si el equipo quiere mejorar, considerar:
    • Mejorar embeddings (text-embedding-3-large): +3-5%
    • Re-ranking con cross-encoder: +5-8%
    • Chunking semántico (M02): +3-5%

Recall esperado con esas mejoras: 87% → 92-95%. Sin necesidad de hybrid.

Proyecto Z — Recomendación: Arquitectura D (ES + weighted + routing)

Aplicación del framework:

  1. ¿Corpus 100% narrativo? No (70% son SKUs).
  2. ¿95%+ identificadores? Casi (70%). → considerar arquitectura B, pero el 30% restante es semántico → necesitas hybrid.
  3. ¿Corpus <1M? No (10M docs). → necesitas Elasticsearch.
  4. ¿Eval set robusto? Asumir que sí (equipo grande puede construirlo).
  5. ¿Una señal claramente mejor? Sí — BM25 mucho mejor para SKUs (70% del tráfico). → weighted con α=0.3 para queries con SKU.

Justificación:

  • Recall 48% es inaceptable. Necesita salto grande, no marginal.
  • 10M docs justifica ES.
  • Equipo de 8 con DevOps → puede mantener arquitectura compleja.
  • 70% queries con SKUs explícitos → weighted con α dinámico mejora notablemente.

Plan:

  • Fase 1 (1 semana): ES setup en cluster + indexar 10M docs.
  • Fase 2 (1 semana): integrar ES con pipeline (paralelo a vector DB existente).
  • Fase 3 (1 semana): RRF baseline + validar.
  • Fase 4 (2 semanas): weighted blending con grid search de α + routing por tipo de query.
  • Fase 5 (1 semana): A/B test producción.

Mejora esperada: recall 48% → 90%+. Costo extra: ~$300/mes (Elastic Cloud) + $50/mes incremental en costos de embeddings.

ROI: si el e-commerce procesa 1M queries/día, mejorar recall 40 puntos puede traducirse en mejora medible de conversión, justificando ampliamente el costo.

Resumen y siguiente paso

Lo que aprendiste:

  • Cuatro arquitecturas: semantic-only (A), BM25-only (B), hybrid simple (C), hybrid avanzado (D).
  • Decision framework de 5 preguntas resuelve la elección en <10 minutos.
  • Plan de evolución gradual: empezar con A, escalar a C cuando el problema lo justifique, escalar a D solo con eval set robusto.
  • La mayoría de proyectos pueden quedarse en arquitectura C. D solo cuando D > C es demostrable con datos.
  • Migrar HACIA ATRÁS es legítimo si la complejidad no se justifica.
  • Anti-patrones: implementar todo de una vez, copiar arquitecturas sin justificar, ignorar costo operacional, tunear sin eval set, no medir precision al agregar BM25.

Checkpoint: antes de cerrar el módulo, deberías poder:

  • Aplicar el framework a un proyecto nuevo en <10 min.
  • Justificar la elección con argumentos numéricos al Tech Lead.
  • Diseñar plan de evolución gradual con criterios de validación.

Siguiente cápsula: 08 — Proyecto integrador hybrid search engine.

Cierre del módulo: vas a construir un sistema hybrid search end-to-end con BM25 (rank_bm25 o ES) + semantic + RRF, A/B testing contra baseline, y reporte comparativo. Es el proyecto que va a tu portfolio — y lo más cercano al patrón "estado del arte" en RAG production.

Recursos

  1. Pinecone — Hybrid Search Decision Guide — Patrones aplicados
  2. LangChain — EnsembleRetriever — Implementaciones de referencia
  3. LlamaIndex — Hybrid Retrieval — Patrón en LlamaIndex
  4. BEIR Benchmark — Comparaciones empíricas
  5. Elasticsearch Hybrid Search — Implementación nativa
  6. Anthropic — Contextual Retrieval — Técnica complementaria

Tiempo estimado: 25-30 minutos Siguiente: 08-project-hybrid-search-engine.md

← AnteriorCápsula 06: Elasticsearch — hybrid search a escala de producciónSiguiente →Cápsula 08: Proyecto integrador — hybrid search engine con A/B testing