Los sistemas RAG en producción enfrentan un problema recurrente: si la calidad de recuperación es baja, ningún LLM por potente que sea salvará las respuestas. text-embedding-3-large de OpenAI cuesta 0.00013 dólares por token, embed-english-v3.0 de Cohere 0.0001 dólares — una diferencia del 30%, pero si estás recuperando chunks incorrectos, el resultado es el mismo: alucinaciones. Reducir el costo de embedding mientras se degrada la calidad de recuperación aumenta el costo del LLM downstream en un 200% (re-ranking, padding de prompts, reintentos). Este artículo muestra cómo se priorizan la selección de embedding, chunking y setup de evaluación en pipelines RAG de producción.
Selección de Modelo de Embedding: Matriz de Latencia × Recall
Al elegir un modelo de embedding, dos métricas son críticas: recall@k de recuperación (¿está la información correcta entre los primeros k chunks?) y latencia p99. La diferencia entre Ada v2 y text-embedding-3-small no es solo precio — es granularidad semántica. Si tu dominio es estrecho y la terminología densa (por ejemplo, legal o finanzas), una variante fine-tuneada de Sentence-BERT (768 dimensiones) recuperará mejor que el modelo de 1536 dimensiones de OpenAI.
Los números de producción que hemos observado: con text-embedding-3-large obtienes un score de retrieval de 64.6 en el benchmark MTEB, pero en tu conjunto de evaluación específico del dominio (por ejemplo, documentación de productos de e-commerce) cae a 58.2. El modelo embed-multilingual-v3.0 de Cohere en contenido en español mostró un recall@5 12% más alto — porque Cohere usó más corpus no-inglés en su entrenamiento multilíngüe. No hay una única métrica: con batch size 128 la latencia de embedding es 230ms, en una solicitud individual es 45ms. Si haces búsqueda en tiempo real, la latencia es prioritaria; si indexas offline, el recall es prioritario.
En la práctica evaluamos así: tomas tu conjunto de evaluación (100-200 preguntas + chunks ground truth), indexas con 3 modelos, calculas recall@1/3/5 y MRR (mean reciprocal rank) para cada modelo. Después de elegir el ganador, decides si fine-tuning merece la pena — si recall@5 está por debajo del 75%, el ROI de fine-tuning es positivo. Los trabajos de análisis de datos de Roibase incluyen la infraestructura de métricas necesaria para construir este pipeline de evaluación.
Estrategia de Chunking: Fixed vs Semantic vs Recursive
El tamaño de chunk es el hiperparámetro más crítico de RAG. La diferencia entre un chunk de 512 tokens y uno de 2048: el pequeño permite recuperación más específica pero pierde contexto, el grande preserva contexto pero añade ruido. Además, la tasa de overlap de chunks (por ejemplo, 10%) también afecta la precisión de recuperación.
El chunking de tamaño fijo (corta cada 512 tokens) es el más simple pero rompe la integridad semántica cuando corta a mitad de un párrafo. El RecursiveCharacterTextSplitter de Langchain funciona así: primero divide por \n\n (párrafo), si no cabe divide por \n (línea), si aún no cabe divide por punto. Este método da un recall@3 18% mejor porque los límites de chunks siguen la estructura natural del texto.
El chunking semántico da un paso más: creas chunks basándote en similitud de embedding. Por ejemplo, detectas un cambio de tema en un documento (cuando la similitud coseno cae por debajo de 0.6) e inicias un nuevo chunk. El SemanticSplitterNodeParser de LlamaIndex usa este método. El tradeoff en producción: el chunking semántico aumenta el tiempo de indexing en 40% (cada oración se embebida) pero mejora la calidad de recuperación en 9%.
Overlap de Chunks: ¿Cuánto es Suficiente?
La tasa de overlap generalmente se mantiene entre 10-20%. En un chunk de 512 tokens, un overlap de 50 tokens significa que una oración podría aparecer en dos chunks. A mayor overlap, mayor tamaño del índice (costo de almacenamiento) pero mejor calidad de recuperación en edge cases. En nuestras pruebas, 15% de overlap es el punto óptimo: más overlap da retornos decrecientes.
La estrategia de overlap también importa: ¿sliding window (cada chunk se desplaza 50 tokens) o paragraph-aware overlap (overlap solo al inicio de párrafos)? El overlap consciente de párrafos produce 7% menos tamaño de índice pero mantiene la misma calidad de recuperación.
Setup de Evaluación: Las Métricas Offline Deben Representar Producción
El mayor riesgo en evaluación RAG es: tus métricas offline se ven bien pero en producción tienes una explosión de alucinaciones. La razón: tu conjunto de evaluación no representa la distribución de queries de producción. Nuestra recomendación: toma 200 queries aleatorias de los logs de producción y marca manualmente los chunks ground truth. Este trabajo de 4 horas te da dirección correcta durante 6 meses.
Las métricas que deben medirse:
| Métrica | Definición | Objetivo |
|---|---|---|
| Recall@k | ¿Está la información correcta entre los primeros k chunks? | >80% (k=5) |
| MRR | Posición promedio del chunk correcto | >0.7 |
| Context precision | ¿Qué porcentaje de chunks recuperados es relevante? | >60% |
| Answer relevancy | ¿La respuesta del LLM es relevante a la pregunta? (LLM-as-judge) | >85% |
| Faithfulness | ¿La respuesta del LLM solo se generó desde el contexto? | >90% |
Para medir context precision y faithfulness, usamos LLM-as-judge: le preguntamos a GPT-4o-mini "¿Es este chunk relevante a la pregunta?" y obtenemos un score 0-1. Este método muestra correlación del 89% con evaluación humana (en nuestra evaluación interna) y cuesta 1/50 de la evaluación humana.
En producción necesitas evaluación continua: toma 10 queries aleatorias cada 1000 queries e invierte en el pipeline de evaluación; si detectas caída en recall, dispara una alerta. Este setup se configura fácilmente con Prometheus + Grafana — latencia de recuperación, conteo de chunks, uso de tokens del LLM se monitorean en el mismo dashboard.
Búsqueda Híbrida: Combinando Recuperación Dense + Sparse
La recuperación puramente densa (solo similitud de embedding) a veces pierde coincidencias exactas de términos. Por ejemplo, cuando un usuario pregunta "Q3 2025 revenue" y tienes un chunk con "third quarter 2025 gelir" — son semánticamente cercanos pero sin término exacto coincidente — BM25 (sparse retrieval) funciona mejor aquí. La búsqueda híbrida combina ambos métodos: recuperación densa obtiene los 50 top chunks, recuperación sparse obtiene los 50 top chunks, se fusionan con RRF (reciprocal rank fusion).
Vector DBs como Weaviate y Qdrant soportan búsqueda híbrida nativamente. En nuestras pruebas, búsqueda híbrida da 6% mejor recall@10 versus pure dense pero la latencia aumenta 18% (dos queries de índice separadas). En producción puedes activar/desactivar búsqueda híbrida según complejidad de query: queries menores a 3 palabras solo sparse, mayores a 10 palabras solo dense, en medio híbrida.
El parámetro alpha (peso dense vs sparse) varía por dominio: en e-commerce, sparse es más importante (código de producto, SKU), en documentación técnica dense es más importante (similitud conceptual). Nuestro alpha por defecto es 0.7 (enfoque dense) pero debería optimizarse con A/B testing.
Re-Ranking: Aumento de Precisión Post-Recuperación
La recuperación inicial trae 50 chunks, pero pasarle todos al LLM como contexto es costoso y añade ruido. Un modelo de re-ranking (como rerank-english-v3.0 de Cohere) rescorifica esos 50 chunks según relevancia a la query, selecciona los 5-10 más relevantes. El rol del re-ranker es diferente: el modelo de embedding mide similitud semántica general, el re-ranker mide relevancia query-chunk específica.
En producción, re-ranking proporciona 15% mejor context precision pero añade 80ms de latencia. El tradeoff: si tu costo del LLM downstream es alto (usas GPT-4) el ROI de re-ranking es positivo; si usas GPT-4o-mini, el costo de latencia pesa más. En nuestro setup, queries críticas (SLA <500ms) omiten re-ranking, queries analíticas (dashboard, reportes) usan re-ranking.
La selección del re-ranker también importa: el modelo de Cohere está basado en cross-encoder, latencia alta pero precisión buena. El re-ranker de Jina AI está basado en bi-encoder, latencia baja pero precisión 4% menor. En producción debes probar ambos y decidir según el tradeoff latencia/precisión.
Perfil de Costo: La Economía de Tokens Comienza en Embedding
En un pipeline RAG, el costo se distribuye así (caso promedio de producción):
- Embedding: 8%
- Búsqueda vectorial: 2% (compute)
- Re-ranking: 5%
- Inferencia de LLM: 85%
El costo de embedding parece pequeño pero se calcula en gran volumen durante indexing. 1M documentos, promedio 1000 tokens/documento, text-embedding-3-large de OpenAI = 1B tokens = $130. Si reindexas mensualmente (no incremental, reindex completo) el costo anual de embedding es $1560. Cambiar a Cohere = $1200. Ahorro del 23%.
Pero el costo real está aquí: si la calidad de recuperación es baja, el LLM reintenta, hace padding de contexto, hace corrección de alucinaciones — eso es 200% más tokens. 1M queries/mes, promedio 2000 tokens/query, GPT-4o = $10 por 1M tokens = $20K/mes. Si la calidad de recuperación cae 10%, la tasa de reintento sube 15%, el costo sube a $23K. Intentas ahorrar $30 en embedding pero pierdes $3K downstream.
Por eso la primera pregunta al poner RAG en producción debería ser: ¿tengo setup de evaluación de recuperación? Si la respuesta es no, la selección de modelo de embedding es prematura. La arquitectura de datos first-party incluye construir la infraestructura de logs que alimenta este pipeline de evaluación — queries de producción, resultados de recuperación, respuestas de LLM deben almacenarse structured para análisis posterior.
Indexing Incremental: Cómo Reaccionar a Datos Cambiantes
En producción, el conjunto de documentos no es estático — cada día se añaden nuevos posts, páginas de producto, documentación. Full reindex es costoso y requiere downtime. El método incremental: solo reembebidas los documentos que cambiaron y los insertas en el vector DB. Qdrant y Pinecone soportan inserciones incrementales nativamente.
La dificultad: cuando un documento cambia, ¿reembebidas solo ese chunk o el documento completo? Si los límites de chunks cambian (se añadió párrafo nuevo, cambió tamaño de chunk) necesitas recalcular todos los chunks del documento. Nuestra estrategia: rastreamos versión de documento (hash), si la versión cambia eliminamos todos los chunks y reinsertamos. Este método hace 3% más reindex pero garantiza consistencia.
La estrategia de eliminación también importa: si no eliminas chunks antiguos del vector DB, el índice se ensucia y la relevancia cae. Pero añadir TTL a cada chunk también es overhead. Nuestra solución: añadimos doc_id y version a los metadatos de cada chunk, cuando un documento se actualiza hacemos bulk delete de los chunks de versión anterior usando doc_id + version. Este método toma 200ms en Qdrant, 450ms en Pinecone (para 10K chunks).
El paso más crítico para llevar un sistema RAG a producción es medir continuamente la calidad de recuperación y evaluarla. Selección de modelo de embedding, estrategia de chunking, setup de evaluación — no son independientes, afectan el pipeline completo. La optimización de costo no comienza en embedding, comienza en precisión de recuperación. Un sistema que no puede obtener el chunk correcto en el primer intento se vuelve exponencialmente costoso downstream.