Módulo 8: Proyecto Final Integrador

4. Etapa 3: Decisiones Técnicas Detalladas

Siguiente →

Descripción

En esta etapa justificas decisiones técnicas específicas: parámetros de chunking, top-K, RRF k, MMR λ, índice ANN, etc. Cada decisión debe estar fundamentada en requisitos o trade-offs.

Decisión 1: Chunk size y overlap

Decisión:

  • Chunk size: 600 tokens
  • Overlap: 100 tokens (16.7%)
  • Estrategia: Hierarchical (por secciones de paper)

Justificación:

¿Por qué 600 tokens?

Papers académicos tienen secciones típicas:
- Abstract: ~200 tokens
- Introduction: ~800 tokens (dividir en 2 chunks)
- Methods: ~1000 tokens (dividir en 2 chunks)
- Results: ~1200 tokens (dividir en 2 chunks)
- Conclusion: ~300 tokens

600 tokens = Balance entre:
- Contexto suficiente (sección completa o subsección)
- Precisión (no mezclar temas diferentes)

¿Por qué overlap 100 tokens?

Transiciones entre secciones:
"...conclusión de la sección anterior. La siguiente sección..."
→ Overlap captura contexto de transición
→ 100 tokens = ~2-3 oraciones

Alternativas consideradas:

  • 400 tokens (menor contexto, mayor precisión) → Rechazado: Secciones quedarían fragmentadas
  • 800 tokens (mayor contexto) → Rechazado: Mezclaría temas, menor precisión

Decisión 2: Embedding model

Decisión:

  • Modelo: Sentence-BERT all-mpnet-base-v2
  • Dimensiones: 768D
  • Inference: GPU local (NVIDIA T4)

Justificación:

¿Por qué Sentence-BERT?

Benchmark (MS MARCO dataset, recall@10):
- all-mpnet-base-v2: 0.69
- OpenAI ada-002: 0.72 (+3%)
- OpenAI text-embedding-3-small: 0.75 (+6%)

Trade-off:
- 6% menor recall vs OpenAI
- Pero: $0 costo + datos privados ✅

¿Por qué all-mpnet-base-v2 vs otras variantes?

all-mpnet-base-v2: 768D, 420M params
all-MiniLM-L6-v2: 384D, 22M params (más rápido pero -10% calidad)

→ all-mpnet-base-v2 mejor balance calidad/velocidad

Throughput esperado:

GPU: NVIDIA T4 (16GB)
Batch size: 32
Latencia: 50ms/batch
→ ~640 chunks/segundo (suficiente para 50K queries/mes)

Decisión 3: Vector database e índice ANN

Decisión:

  • Vector DB: Weaviate
  • Índice: HNSW
  • Parámetros:
    • efConstruction: 256 (indexación)
    • maxConnections: 64
    • ef: 128 (query time)

Justificación:

¿Por qué HNSW vs IVF?

Dataset: 500K chunks

HNSW:
- Recall@10: 0.95
- Latency: 50-100ms
- Memory: ~4GB (768D × 500K × 8 bytes + graph)

IVF (nlist=1000):
- Recall@10: 0.90 (menor)
- Latency: 30-60ms (más rápido)
- Memory: ~2GB

→ HNSW: Mejor recall (+5%), latencia aceptable

¿Por qué ef=128?

ef = Número de candidatos evaluados durante búsqueda

Benchmark interno (esperado):
- ef=64: recall@10 = 0.92, latency = 40ms
- ef=128: recall@10 = 0.95, latency = 80ms
- ef=256: recall@10 = 0.96, latency = 150ms

→ ef=128: Balance óptimo (recall alto, latencia < 100ms)

Decisión 4: Top-K y reranking

Decisión:

  • Top-K inicial (kNN): 100
  • Reranking: NO (para mantener latencia baja)
  • Top-K final (después de MMR): 20

Justificación:

¿Por qué top-K=100?

MMR requiere suficientes candidatos para diversificar:
- top-K=50 → MMR tiene poco margen de diversidad
- top-K=100 → MMR puede elegir 20 diversos de 100
- top-K=200 → Latencia aumenta sin ganancia significativa

→ 100 es sweet spot

¿Por qué NO reranking?

Reranking (cross-encoder) agrega 200-300ms
→ Latencia total: 230ms + 300ms = 530ms (búsqueda)
→ RAG total: 1440ms + 300ms = 1740ms ✅ (aún < 2s)

Pero: Reranking no es crítico si HNSW ya tiene recall@10 = 0.95

Decisión: Omitir reranking inicialmente
→ Si precision@10 < 0.75 en producción → Agregar reranking

Decisión 5: Hybrid search (RRF k)

Decisión:

  • Método: RRF (Reciprocal Rank Fusion)
  • Parámetro k: 60

Justificación:

¿Por qué RRF vs weighted sum?

Weighted sum requiere ajustar α:
score = α × semantic + (1-α) × keyword

→ α difícil de ajustar (depende de query)

RRF:
RRF(doc) = 1/(k + rank_semantic) + 1/(k + rank_keyword)
→ No requiere ajustar α ✅
→ Documentos en ambos rankings automáticamente boosted

¿Por qué k=60?

Benchmark típico (literatura):
- k=10: Favorece rankings altos (top-5) demasiado
- k=60: Balance estándar (usado en Weaviate, Elasticsearch)
- k=100: Flattens scores (menos diferenciación)

→ k=60 es valor estándar probado

Decisión 6: MMR (diversidad)

Decisión:

  • λ (lambda): 0.6
  • Diversificar por: Department (CS, Physics, Biology, etc.)

Justificación:

¿Por qué λ=0.6?

λ = Balance entre relevancia y diversidad

λ=0.0: Solo diversidad (no recomendado)
λ=0.5: Balance 50/50
λ=0.6: 60% relevancia, 40% diversidad ← Recomendado
λ=1.0: Solo relevancia (sin diversidad)

→ λ=0.6: Prioriza relevancia pero garantiza diversidad

¿Por qué diversificar por department?

RF4: Sugerir papers relacionados de múltiples áreas

Usuario busca: "optimization algorithms"
Sin MMR:
- 20 papers todos de CS (mismo departamento)

Con MMR (diversidad por department):
- 12 papers de CS (optimization)
- 5 papers de Math (theory)
- 3 papers de Physics (applications)
→ Mayor cobertura ✅

Decisión 7: Metadata boost

Decisión:

  • Papers < 2 años: 1.2x boost
  • Papers 2-5 años: 1.0x (sin boost)
  • Papers > 5 años: 0.9x (penalización leve)

Justificación:

¿Por qué favorecer papers recientes?

Usuarios (especialmente estudiantes) prefieren papers recientes:
- Métodos más actuales
- Datasets más grandes
- Estado del arte actual

Pero: No eliminar papers antiguos (pueden ser foundational)
→ Boost moderado (1.2x, no 2x)

Fórmula:

if year >= 2022:
    boost = 1.2
elif year >= 2019:
    boost = 1.0
else:
    boost = 0.9

final_score = base_score × boost

Decisión 8: LLM para Q&A

Decisión:

  • Modelo: GPT-3.5 Turbo
  • Temperature: 0.1 (baja)
  • Max tokens output: 500
  • Streaming: Activado

Justificación:

¿Por qué GPT-3.5 vs GPT-4?

Costo/query:
- GPT-3.5: $0.0011 (2500 input + 300 output)
- GPT-4: $0.022 (20x más caro)

Latencia:
- GPT-3.5: 1-2s
- GPT-4: 2-5s

Trade-off:
- GPT-4 es mejor, pero GPT-3.5 es suficiente para Q&A académico
- Presupuesto limitado → GPT-3.5

¿Por qué temperature=0.1?

Temperature controla "creatividad":
- 0.0: Determinístico (siempre misma respuesta)
- 0.1: Casi determinístico, mínima variación
- 0.7: Default (más creativo)

Para Q&A académico:
→ Queremos respuestas consistentes y precisas
→ temperature=0.1 ✅

¿Por qué streaming?

Sin streaming:
- Usuario espera 1.5s en blanco → Respuesta aparece completa

Con streaming:
- Usuario ve respuesta mientras genera (palabra por palabra)
- Percepción de latencia menor
- Mejor UX ✅

Decisión 9: Evaluation metrics

Decisión:

  • Precision@10: Target > 0.75
  • NDCG@20: Target > 0.70
  • Diversity (departments en top-20): Target ≥ 3
  • Latency (p95): Target < 2000ms

Justificación:

¿Por qué Precision@10 (no @5)?

Usuarios típicamente revisan top-10 resultados (primera "página")
→ Precision@10 mide qué % de esos 10 son relevantes

¿Por qué NDCG@20?

NDCG penaliza resultados relevantes en posiciones bajas
→ NDCG@20 mide calidad del ranking completo (primera página)

¿Por qué diversity ≥ 3 departments?

RF4: Sugerir papers de múltiples áreas
→ Al menos 3 departamentos diferentes en top-20

Resumen de decisiones técnicas

ComponenteDecisiónJustificación
Chunk size600 tokensBalance contexto/precisión
Overlap100 tokensCaptura transiciones
EmbeddingSentence-BERT (768D)Datos privados, $0 costo
Vector DBWeaviate HNSWRecall alto, latencia baja
Top-K100 → MMR → 20Suficiente para diversidad
HybridRRF (k=60)Balance keyword+semantic
MMRλ=0.660% relevancia, 40% diversidad
Boost< 2 años: 1.2xFavorecer papers recientes
LLMGPT-3.5 (temp=0.1)Costo/latencia aceptables
MetricsP@10, NDCG@20, diversityMedir calidad y diversidad

Próxima etapa: 05-cost-estimation.md — Calcular costo mensual completo.

← Anterior3. Etapa 2: Diseño de ArquitecturaSiguiente →5. Etapa 4: Estimación de Costos