7. Casos de Estudio de Sistemas de Búsqueda

Descripción

Aquí analizas 3 casos de estudio reales: RAG (Retrieval-Augmented Generation), e-commerce search, y soporte técnico. Cada uno con arquitectura, decisiones de diseño, y métricas.

---

Caso 1: RAG (Retrieval-Augmented Generation)

Contexto:

Sistema de Q&A sobre documentación técnica (10K páginas de docs).

Requisitos:

• Usuario hace pregunta → Sistema busca docs relevantes → LLM genera respuesta
• Latencia < 2 segundos
• Alta precisión (respuestas incorrectas son críticas)

---

Arquitectura:

User Query: "cómo configurar Pinecone"
    ↓
1. Query embedding (OpenAI ada-002)
    ↓
2. kNN search (Pinecone, top-100)
    ↓
3. Reranking (Cohere Rerank, top-5)
    ↓
4. Context injection (5 chunks al LLM)
    ↓
5. LLM generation (GPT-4)
    ↓
Response: "Para configurar Pinecone..."

---

Decisiones de diseño:

1. Chunking:

• Estrategia: Paragraph-based (respeta estructura)
• Tamaño: 600 tokens (balance contexto/precisión)
• Overlap: 100 tokens

2. Embeddings:

• Modelo: OpenAI text-embedding-3-small (1536D)
• Costo: ~$0.01 por re-indexación completa

3. Vector DB:

• Pinecone (managed, HNSW)
• 1 índice, 30K chunks

4. Reranking:

• Cohere Rerank API
• Top-100 → Top-5 (precisión crítica)

5. LLM:

• GPT-4 Turbo
• Context: Top-5 chunks (3000 tokens)

---

Métricas:

Precision@5: 0.85 (85% de top-5 son relevantes)
Latency: 1.2s promedio
Cost per query: $0.003 (embedding + rerank + LLM)

---

Optimizaciones:

1. Cache de queries frecuentes:
   "qué es Pinecone" → Respuesta pre-generada → 0 latencia

2. Streaming de respuesta LLM:
   Usuario ve respuesta mientras se genera → Percepción de menor latencia

3. Metadata filtering:
   Si usuario especifica sección (ej: "en la guía de setup") → Filtrar chunks por metadata

---

Caso 2: E-commerce Search

Contexto:

Catálogo de 500K productos (ropa, electrónica, hogar).

Requisitos:

• Queries mixtas: exactas ("iPhone 15 Pro") y conceptuales ("celular con buena cámara")
• Latencia < 300ms
• Personalización (historial de usuario)

---

Arquitectura:

User Query: "laptop para gaming"
    ↓
1. Ejecutar en paralelo:
   a. Keyword search (Elasticsearch, BM25)
   b. Semantic search (Weaviate, embeddings)
    ↓
2. Fusión híbrida (RRF, k=60)
    ↓
3. Personalización (boost productos vistos)
    ↓
4. Filtros (precio, marca, rating)
    ↓
Top-20 productos

---

Decisiones de diseño:

1. Índice dual:

• Elasticsearch: Nombres, descripciones (keyword)
• Weaviate: Embeddings de descripciones (semantic)

2. Embeddings:

• Modelo: Sentence-BERT (768D, local)
• Costo: $0 (después de setup)

3. Fusión:

• RRF (k=60)
• Balance automático (no ajustar α manualmente)

4. Personalización:

final_score = base_score × (1 + history_boost)

history_boost:
- Producto visto: 1.2x
- Producto en carrito: 1.5x
- Producto comprado: 0.8x (ya lo tienen)

---

Métricas:

Precision@10: 0.72
CTR (Click-Through Rate): 18%
Conversion rate: 4.2%
Latency: 180ms promedio

---

Optimizaciones:

1. Pre-compute embeddings:
   Embeddings de productos generados offline (no en cada query)

2. Edge caching:
   Queries frecuentes ("iPhone 15") cacheadas en CDN

3. A/B testing:
   Probar diferentes valores de RRF k (50, 60, 70)

---

Caso 3: Sistema de Soporte Técnico

Contexto:

Base de conocimiento con 50K tickets históricos + 5K artículos de ayuda.

Requisitos:

• Queries mixtas: IDs exactos ("Ticket #12345") y descripciones ("problema con pago")
• Sugerir tickets similares (para agentes de soporte)
• Latencia < 500ms

---

Arquitectura:

User Query: "problema con pago usando tarjeta"
    ↓
1. Detectar patrón:
   ¿Contiene "Ticket #"? → Keyword exact match
   Sino → Semantic search
    ↓
2. Semantic search (Qdrant, HNSW)
    ↓
3. MMR (diversificar resultados)
    ↓
4. Agrupar por categoría (pago, login, técnico)
    ↓
Top-10 tickets similares

---

Decisiones de diseño:

1. Detección de IDs:

Regex: /Ticket #[0-9]+/
Si match → Búsqueda exacta en DB relacional (PostgreSQL)
Sino → Búsqueda semántica

2. Embeddings:

• Modelo: OpenAI text-embedding-3-small
• Campo: Título + descripción del ticket

3. MMR:

• λ = 0.6 (60% relevancia, 40% diversidad)
• Evitar 10 tickets casi idénticos

4. Agrupación:

Top-10 tickets:
- Categoría "Pago": 4 tickets
- Categoría "Tarjeta": 3 tickets
- Categoría "General": 3 tickets

---

Métricas:

MRR: 0.68 (primer resultado relevante en posición 1-2)
Ticket resolution time: -25% (agentes encuentran soluciones más rápido)
Latency: 320ms promedio

---

Optimizaciones:

1. Auto-tagging:
   LLM etiqueta tickets con categorías (pago, login, técnico) → Metadata para filtros

2. Feedback loop:
   Agente marca ticket como "útil" o "no útil" → Re-entrenar embeddings

3. Preload common issues:
   Top-20 problemas frecuentes pre-cargados (latencia: 0ms)

---

Comparación de casos

Aspecto	RAG	E-commerce	Soporte
Dataset	10K docs	500K productos	50K tickets
Queries	Conceptuales	Mixtas	Mixtas
Latencia	1.2s	180ms	320ms
Método	Semantic + rerank	Híbrido (RRF)	Semantic + MMR
Personalización	No	Sí (historial)	Sí (feedback)

---

Resumen

Puntos clave:

• RAG: Semantic + reranking (precisión crítica)
• E-commerce: Híbrido (keyword + semantic, personalización)
• Soporte: Detección de IDs + semantic + MMR (diversidad)
• Optimizaciones comunes: Cache, feedback loop, metadata

---

Próxima cápsula: 08-capstone-exercise-6.md — Diseñar arquitectura para caso.