RAG en Producción: La Calidad de Recuperación Antes que el Costo

Los sistemas RAG se han popularizado en producción desde 2024. Las empresas construyen stacks de embedding + vector DB para alimentar sus corpus de documentos al LLM. Sin embargo, la mayoría de los proyectos piloto enfrentan el mismo problema: calidad de recuperación baja, respuestas inconsistentes, costos fuera de control. La culpa suele estar en decisiones apresuradas: elección del modelo de embedding, estrategia de chunking y setup de evaluación. En este artículo mostramos qué decisiones no tienen vuelta atrás antes de llevar tu pipeline RAG a producción.

Modelo de Embedding: Alineación de Dominio, no Solo Dimensión

El primer reflejo al elegir un modelo de embedding es "¿cuál tiene la puntuación más alta en MTEB?". Pero el ranking en benchmarks no garantiza rendimiento en producción. Lo que importa es cuán bien se adapta el modelo a tu tipo de documentos y patrón de consultas.

Cuando comparamos OpenAI text-embedding-3-large (3072 dim) con Cohere embed-v3 (1024 dim): Cohere mostró recall@10 más consistente en documentos de marketing (blogs, case studies, landing pages), porque su dataset de entrenamiento tiene contenido empresarial dominante. El modelo más grande de OpenAI rinde bien en benchmarks generales, pero la distribución de consultas domain-específicas es distinta.

Otro ejemplo: bge-large-en-v1.5 (1024 dim, auto-hosted) es suficiente para documentos legales. Pero en un corpus multilingüe, multilingual-e5-large (1024 dim) es claramente superior. El tamaño del modelo no siempre es señal de calidad — la superposición entre los datos de entrenamiento y tu dominio es más crítica.

Criterios de selección:

1. No la puntuación de MTEB, sino recall@5 / MRR en tu propio eval set
2. Latencia (API vs auto-hosted) — tiempo de batch embedding para 512 documentos
3. Costo por 1M tokens — OpenAI 3-large $0.13, Cohere v3 $0.10, auto-hosted $0 pero hay infra

Si tu corpus contiene jerga domain-específica (farmacéutica, finanzas, legal), fine-tunear un modelo de embedding o entrenar sentence transformers en tus datos aumenta la calidad de recuperación 15-20%. Esto entra en análisis de datos e ingeniería de perspectivas — necesitas construir un pipeline de entrenamiento y monitorear la calidad de los datos.

Estrategia de Chunking: El Tamaño Fijo No Funciona

La mayoría de las implementaciones RAG comienzan con "ventana de 512 tokens con solapamiento". Esto es aceptable para blogs en markdown pero se rompe inmediatamente en corpus mixtos (PDF, HTML, JSON).

Problemas del chunking de tamaño fijo:

• Los títulos se fragmentan, se pierde la integridad semántica
• Las tablas y bloques de código se dividen por la mitad
• La estrategia de solapamiento duplica contexto, aumentando ruido de recuperación

Alternativa: semantic chunking. Dividir en chunks respetando límites de oraciones, jerarquía de títulos. Usar MarkdownTextSplitter en lugar del RecursiveCharacterTextSplitter de langchain, o parseadores custom. En PDFs, usar pdfplumber para separar tablas de texto y aplicar estrategias de chunking diferentes.

Para una empresa de e-commerce, dividimos documentos de productos en 3 tipos de chunk:

• Título + descripción corta: 128 tokens, ligero para recuperación
• Especificaciones técnicas + tabla: 256 tokens, datos estructurados
• Contenido largo (blog, guía): 512 tokens, división semántica

Agregamos metadatos a cada chunk (chunk_type, source_page). Durante la recuperación, aplicamos filtros de chunk_type según el tipo de consulta. Por ejemplo, las consultas "comparación de productos" solo miran chunks de technical_specs. Esto aumentó precision@3 en 18%.

Estrategia de Solapamiento: ¿Cuánto es Suficiente?

El solapamiento generalmente se recomienda en 10-20%, pero esto es arbitrario. Resultado de pruebas: 50 tokens de solapamiento en chunks de 512 tokens preserva continuidad semántica. 100 tokens de solapamiento aumenta la latencia de recuperación 12% pero sin ganancia de calidad. El punto óptimo varía según el dominio — pruébalo con tu propio eval set.

Setup de Evaluación: Debe Estar Listo Antes de Producción

La mayoría de los sistemas RAG llegan a producción con el test de "se ve bien visualmente". Pero sin un setup de evaluación estructurado, el sistema no será confiable en las primeras 1000 consultas.

Pipeline de evaluación mínimo:

# eval_set.json — dataset de oro
[
  {
    "query": "¿Cómo obtener consentimiento de usuario compatible con GDPR?",
    "expected_docs": ["doc_42", "doc_89"],
    "expected_answer_contains": ["notificación de cookies", "consentimiento explícito"]
  },
  ...
]

# métricas de evaluación
def evaluate_retrieval(query, retrieved_docs, expected_docs):
    recall_at_k = len(set(retrieved_docs[:5]) & set(expected_docs)) / len(expected_docs)
    mrr = 1 / (retrieved_docs.index(expected_docs[0]) + 1) if expected_docs[0] in retrieved_docs else 0
    return {"recall@5": recall_at_k, "mrr": mrr}

def evaluate_generation(generated_answer, expected_contains):
    # LLM-as-judge: pregunta a Claude "¿la respuesta contiene lo esperado?"
    prompt = f"Expected: {expected_contains}\nGenerated: {generated_answer}\nScore 0-1:"
    score = claude_api(prompt)
    return float(score)

Frecuencia de evaluación: Después de cada cambio de modelo de embedding, ajuste de estrategia de chunking. Debe correr automáticamente en CI/CD. Si recall@5 < 0.7, el deploy se bloquea.

En un escenario real: preparamos un eval set de 200 consultas para un cliente. El pipeline de evaluación se ejecutaba automáticamente en cada commit. Un cambio en chunking aumentó recall@5 de 0.68 a 0.81 pero la latencia p95 subió de 340ms a 520ms. Ver este tradeoff en el dashboard nos hizo revertir el chunking y probar otro camino. Sin evaluación, este tradeoff sería invisible.

Búsqueda Híbrida: Recuperación Sparse + Dense

Depender solo de similitud vectorial falla en casos específicos. Por ejemplo, las consultas que requieren coincidencia exacta de palabras clave (código de producto, nombre de endpoint API) pueden obtener puntuaciones bajas en búsqueda vectorial. Aquí entra en juego la búsqueda híbrida: combina puntuaciones BM25 (sparse) + embedding (dense).

# Ejemplo de recuperación híbrida
bm25_results = bm25_index.search(query, top_k=20)
vector_results = vector_db.search(query_embedding, top_k=20)

# RRF (Reciprocal Rank Fusion)
def rrf_score(rank, k=60):
    return 1 / (k + rank)

combined_scores = {}
for rank, doc in enumerate(bm25_results):
    combined_scores[doc.id] = combined_scores.get(doc.id, 0) + rrf_score(rank)
for rank, doc in enumerate(vector_results):
    combined_scores[doc.id] = combined_scores.get(doc.id, 0) + rrf_score(rank)

final_results = sorted(combined_scores.items(), key=lambda x: x[1], reverse=True)[:5]

Resultado de pruebas: búsqueda híbrida aumentó recall@5 en 22% para consultas técnicas. Pero la latencia se duplicó porque haces dos solicitudes a índices separados. Si este tradeoff es aceptable (por ejemplo, herramienta interna con <500ms suficiente), la búsqueda híbrida funciona en producción.

Reranking: Filtrado de Segunda Etapa

La primera etapa de recuperación (BM25 + vector) devuelve 20-50 documentos. Pero no todos caben en el contexto del LLM (costo + límite de tokens). Aquí entra el modelo reranker: recalcula la puntuación de relevancia entre la consulta y cada documento, seleccionando los top-5.

Se usan modelos como Cohere rerank-english-v2.0 o bge-reranker-large. El reranker usa arquitectura cross-encoder — codifica consulta + documento juntos, por lo que es más caro que embedding pero más preciso.

Benchmark: al aplicar reranking sobre 50 documentos:

• Recall@5: 0.73 → 0.89
• Latencia: +180ms (aceptable)
• Costo: +$0.002 por recuperación (API de Cohere)

Si el presupuesto es limitado, puedes usar un reranker auto-hosted pero requiere inferencia en GPU. En este punto, haz el cálculo de costo de infra vs costo de API.

Optimización de Context Window: Menos Documentos, Mejor Respuesta

Enviar 20 documentos al LLM no siempre produce mejores respuestas. Contexto largo causa el problema "perdido en el medio" — el modelo ignora información en el medio. Resultado de pruebas: enviar 5 documentos a GPT-4 Turbo produce mejores respuestas que 15 documentos (diferencia de 11% en puntuación BLEU).

Estrategia de optimización:

1. Selecciona top-5 con el reranker
2. Descarta documentos con puntuación de relevancia < 0.6
3. Envía los 3-5 documentos restantes al contexto del LLM

Este enfoque reduce costos de tokens (entrada 70% menos) y mejora la calidad de respuesta. En producción, necesitas encontrar el punto óptimo en el triángulo costo/latencia/calidad — el pipeline de evaluación lo hace visible.

Monitoreo en Producción: Drift de Recuperación

La calidad de recuperación puede degradarse con el tiempo — a medida que agregas nuevos documentos y la distribución de consultas cambia. Para monitorear el drift de recuperación, configura un dashboard:

Si observas drift de recall:

1. Actualiza el eval set (agrega nuevos patrones de consultas)
2. Fine-tunea el modelo de embedding o cámbialo
3. Revisa la estrategia de chunking

Este monitoreo entra en datos first-party y arquitectura de medición — tu sistema RAG también es un data pipeline, debe ser observable.

Tradeoff Costo vs Calidad: Decisiones Pragmáticas

En RAG de producción, cada decisión implica un tradeoff costo/calidad/latencia. Algunas decisiones pragmáticas:

• Modelo de embedding: OpenAI 3-large → Cohere v3 = reducción de 30% en costo, pérdida de 2% en calidad (aceptable)
• Reranking: Reranking en cada consulta → solo en consultas ambiguas = 40% menos latencia
• Búsqueda híbrida: BM25 + vector → solo vector (si no importa coincidencia exacta) = 50% menos latencia
• Context window: 10 documentos → 5 documentos = 60% menos costo de tokens, 8% ganancia en calidad

Ver estos tradeoffs requiere pipeline de evaluación. Sin él, dices "cambié el modelo de embedding, es más barato" pero no ves que la calidad de recuperación cayó 15%.

Antes de llevar tu sistema RAG a producción, toma en serio: modelo de embedding, estrategia de chunking y setup de evaluación. La optimización de costo es el segundo paso — primero estabiliza la calidad de recuperación, luego reduce costos. Si no, la confiabilidad se reflejará en el usuario y la adopción caerá.