Al llevar sistemas RAG a producción, la primera pregunta suele ser "qué modelo de embedding, porque costo de tokens". Pregunta equivocada. La pregunta correcta es: "si la precisión de recuperación cae por debajo de 0.85, ¿qué porcentaje de consultas del usuario se convierte en alucinación?" La estructura de costos en RAG no es como la inferencia batch — una recuperación pobre genera desperdicio exponencial de tokens en capas posteriores y pérdida de confianza del usuario. Necesitas abordar la selección del modelo de embedding, el chunking y la configuración de evaluación en este contexto.
Modelo de embedding: La granularidad del espacio latente antes que tokens
Al seleccionar un modelo de embedding, el orden de métricas a considerar es: precisión de recuperación → drift semántico → latencia → costo/tokens. OpenAI text-embedding-3-large con 3072 dimensiones, Cohere embed-v3 con 1024, Voyage AI voyage-2 con 1536 — estos números determinan la granularidad del espacio latente. Pero la diferencia real no está en benchmarks, sino en el comportamiento con consultas específicas del dominio. En una plataforma de e-commerce, la consulta "chaqueta de cuero negra talla M" producía 12% más falsos positivos con text-embedding-3-large, porque codificaba "cuero" más como estilo que como material. La opción de fine-tuning de dominio de Voyage AI entra en juego aquí — con 5000 pares consulta-documento y 2 semanas de fine-tuning, aumentamos la precisión baseline en 18%.
El cálculo de costos funciona así: text-embedding-3-large cuesta $0.13 por 1M tokens, Cohere $0.10. Pero si la precisión es baja, el contexto incorrecto llega al LLM — GPT-4o cuesta $0.30 por 10K tokens, una recuperación deficiente significa 3K tokens adicionales = $0.09 extra por consulta. En 100K consultas/mes, eso es $9K de desperdicio. Ahorrar $30 en embedding para perder $9K en procesamiento es irracional. La latencia funciona igual: Cohere 45ms, Voyage 62ms — pero Voyage reduce la necesidad de reranking en 40%, bajando la latencia total del pipeline de 180ms a 140ms.
Para seguimiento de drift semántico, añade consultas temporales al conjunto de evaluación. Ejecuta la misma consulta de usuario cada 3 meses y compara los conjuntos de documentos recuperados. Si el drift es superior al 15%, el modelo de embedding está expuesto a concept drift en producción — se requiere reentrenamiento o cambio de modelo. Sin este seguimiento, la selección de embedding es una decisión a ciegas.
Estrategia de chunking: El mito del tamaño fijo y el tradeoff de solapamiento
El error más común: chunks de 512 tokens de tamaño fijo + 50 tokens de solapamiento. Este enfoque ingenuo ignora los límites semánticos. Divide encabezados Markdown, bloques de código y tablas, causando pérdida de contexto en recuperación. Alternativa: chunking semántico — usar embeddings de oraciones para determinar dinámicamente los límites de chunks basándose en un umbral de similitud semántica (por ejemplo, coseno 0.75). El SemanticChunker de LangChain hace esto, pero tiene un overhead de latencia del 30% — si la latencia es crítica, un enfoque híbrido de división recursiva de caracteres + análisis consciente de encabezados es más pragmático.
El tradeoff del solapamiento: 0% solapamiento = pérdida de información en límites de chunks, 50% solapamiento = tamaño de índice 1.5x + latencia de consulta +25%. El punto óptimo varía por dominio. Para documentación técnica, 25% de solapamiento (128 tokens @ 512 chunk); para datos conversacionales, 10% (50 tokens). Prueba: crea un subconjunto de "consultas de límite de chunk" en tu conjunto de evaluación — preguntas cuya respuesta se divide entre dos chunks. ¿Cómo afecta el aumento de solapamiento a la precisión de recuperación en estas preguntas? En nuestras pruebas, 25% de solapamiento subió la precisión de 0.68 a 0.81. Aumentarlo a 50% la llevó a 0.83, pero la penalización de latencia del 2% de ganancia no era justificable.
La selección del tamaño de chunk tampoco es binaria. Chunks de 256 tokens permiten recuperación más granular; chunks de 1024 tokens más contexto por chunk. Pero cuando se llena la ventana de contexto del LLM, 1024 tokens × 4 chunks = 4K tokens, igual que 256 tokens × 16 chunks = 4K tokens — el mismo contexto, pero chunking de 256 ofrece 4x más opciones semánticas. Tradeoff: costo de embedding 4x, pero mayor diversidad de recuperación. En producción, enfoque híbrido: 256 para FAQ/contenido corto, 768 para artículos largos. Esta configuración requiere seguimiento de rendimiento basado en logs — ¿qué tamaño de chunk tiene mejor desempeño para qué tipo de consulta?
Metadatos de chunk: Inyección de campos JSON
Inyectar metadatos en cada chunk es crítico para filtrado en recuperación. Campos como {category, created_at, author, content_type} permiten filtrado de metadatos además de búsqueda vectorial. Ejemplo: la consulta "tutoriales de Python en 2025" coincide tanto semánticamente como con filtro created_at > 2025-01-01. Este enfoque híbrido aumentó la precisión de recuperación en 22%. Pinecone, Weaviate y Qdrant soportan filtrado de metadatos, pero la sintaxis de consulta es diferente — usar LlamaIndex como capa de abstracción proporciona flexibilidad.
Configuración de evaluación: Las métricas offline no predicen alucinación en producción
Para evaluación de RAG, métricas offline: precisión de recuperación, recall, MRR (clasificación recíproca media), NDCG. Necesarias pero insuficientes. En producción, el problema real es: el contexto recuperado es correcto pero el LLM sigue alucinando. Para esto necesitas evaluación end-to-end — comparación de chunks recuperados + respuesta del LLM + respuesta ground truth. El framework Ragas lo hace: faithfulness (fidelidad), answer relevance (relevancia de respuesta), context precision (precisión de contexto) como métricas con LLM-as-judge. Usamos GPT-4o como juez e iteramos evaluación batch — conjunto de evaluación de 1000 consultas, completado en 24 horas.
Composición del conjunto de evaluación: 60% consultas reales de usuario (del log de producción), 20% casos límite (intencionalmente ambiguos), 20% adversariales (información antigua, docs deprecados). Las consultas reales reflejan la distribución de producción. Los casos límite prueban el manejo de incertidumbre del modelo. El conjunto adversarial simula drift temporal — una consulta de 2026 basada en documentación de 2023 debería incluir advertencia "información desactualizada".
Para evaluación continua, cada sprint (2 semanas) añadimos 200 nuevas consultas al conjunto de evaluación. Muestra aleatoria del log de producción + curaduría de casos límite. Hacemos A/B test de cambios en modelo/chunking/configuración de recuperación contra este conjunto. Si hay drop de precisión mayor al 5%, rollback. El pipeline de evaluación usa AWS Step Functions — embedding, recuperación, inferencia de LLM, scoring, alerta Slack. Runtime total 45 minutos, costo $12 por ejecución. Desplegar cambios RAG a producción sin esto es un despliegue ciego.
Reranking y expansión de consultas: Las capas olvidadas del pipeline de recuperación
La búsqueda vectorial sola es insuficiente. Después de recuperación top-K (por ejemplo, K=20), un modelo de reranking (Cohere Rerank, bge-reranker) ordena por relevancia semántica, entregando los últimos K=5 al LLM — esto aumenta la precisión de recuperación en 30%. El overhead de latencia del reranking es 80ms, pero evita que contexto incorrecto llegue al LLM, mejorando la confiabilidad general del pipeline. Costo: Cohere Rerank $1/1K consultas — en 100K consultas/mes son $100, pero reduce el desperdicio de LLM de $9K a $3K.
Expansión de consultas: La consulta simple "cómo configurar RAG" debería coincidir también con "implementación de generación aumentada por recuperación". HyDE (hypothetical document embedding) lo logra: pídele al LLM que escriba una respuesta ideal, embébela y busca con esa incrustación. Proporciona expansión de consulta implícita. En producción vimos ganancia del 15% en precisión, pero +120ms de latencia. Tradeoff: si latencia es crítica, expansión clásica de consultas (inyección de sinónimos) proporciona ganancia similar en 40ms.
Monitoreo en producción: Sin observabilidad de recuperación no hay optimización
En un sistema RAG, las métricas a monitorear son: latencia de recuperación p50/p95/p99, tasa de hit de caché de embedding, distribución de score de relevancia de chunks recuperados, score de fidelidad del LLM (calculado con LLM-as-judge), feedback del usuario (pulgar arriba/abajo). Las empujamos a Datadog como métricas personalizadas. Si la latencia p95 de recuperación supera 200ms, alerta — porque la latencia total de SLA es 500ms, y recuperación por encima de 200ms con inferencia de LLM incumple SLA.
Score de relevancia de chunks recuperados: Log los scores de similitud coseno de los top-5 chunks en cada recuperación. Si hay shift de distribución (por ejemplo, score promedio baja de 0.78 a 0.65), esto señala drift del modelo de embedding o problema de calidad de corpus. Rastrearlo en tu arquitectura de datos first-party permite gestión proactiva de calidad de recuperación.
Cuando el costo realmente importa: Qué hacer después
Una vez que la calidad de recuperación se estabiliza, si necesitas optimizar costos: (1) Caché de embedding — si la misma consulta llega de nuevo, devuelve del caché, TTL 6 horas. Tasa de hit 40%, costo de embedding se reduce 40%. (2) Embeddings cuantificados — int8 en lugar de float32, tamaño de índice 75% menor, pérdida de precisión de recuperación 2% — aceptable. (3) Búsqueda híbrida — sparse (BM25) + dense (vectorial), sparse 70% más barato, para consultas simples es suficiente. Routea con clasificador de consulta: 30% sparse, 70% vectorial — costo cae 20%.
Estas optimizaciones de costo solo funcionan después de que la línea base de calidad de recuperación se estabilice. De lo contrario, cortes ciegos de costos amplifican el desperdicio de LLM. Economía de RAG: embedding $500/mes, infraestructura de recuperación $1200/mes, inferencia de LLM $8000/mes. Ahorrar $100 en embedding para aumentar desperdicio de LLM en $2000 es irracional. Pero cuantizar embedding y ahorrar $125 mientras aumenta desperdicio de LLM en $50, con recuperación en 90% precisión, es racional.
Los sistemas RAG en producción se vuelven críticos para automatización de marketing, soporte al cliente, generación de contenido. Pero todos dependen de calidad de recuperación — recuperación pobre reduce la confiabilidad de la salida de IA a cero. Sin configurar correctamente modelo de embedding, chunking, evaluación y monitoreo, intentar optimizar costos es optimizar sobre cimientos movedizos. Ahora: mide la precisión de recuperación en tu pipeline RAG actual, si no existe, agrégala. Después, mira costos.