Los sistemas RAG en producción viven dos destinos posibles: se cierran en 3 semanas por alucinaciones, o alcanzan F1>90% en recuperación y se convierten en pipeline crítico. La diferencia está en la elección de embedding, estrategia de chunking y configuración de evaluación. La optimización de costo es secundaria — si no resuelves entregar el documento correcto, un modelo económico solo produce errores baratos.
Modelo de Embedding: Dimensión ≠ Ajuste al Dominio
El primer reflejo es "el modelo más grande embebe mejor". text-embedding-3-large (3072 dim) no siempre supera a text-embedding-3-small (1536 dim). MTEB benchmark mide corpus generales — si tu dominio es finanzas, medicina o e-commerce, esas puntuaciones engañan.
En producción vimos: un modelo de 768 dimensiones ajustado al dominio (sentence-transformers/all-mpnet-base-v2 fine-tuned) entregó 12% mejor recall@10 que uno genérico de 3072 dimensiones. La razón es directa: el espacio embedding no entiende la jerga de tu sector. "Conversion rate optimization" vs "CRO" tienen distancia semántica 0.68 en modelos genéricos, 0.91 en ajustados al dominio.
El trade-off de dimensionalidad es claro: 3072 dim produce índice de 4.2GB, 768 dim de 1.1GB. Latencia de query: 47ms vs 18ms (FAISS HNSW, m=16). Si pierdes menos del 5% en recall, el modelo pequeño gana — costo y velocidad. Decidir sin medir es ingeniería especulativa.
Decisión de Fine-Tuning
Fine-tuning de embedding es obligatorio en dos casos: (1) vocabulario extremadamente específico (términos médicos, nombres de tokens crypto), (2) distribución asimétrica query-documento (preguntas cortas, documentos largos). OpenAI Embedding API no acepta fine-tuning; usa sentence-transformers o Cohere embed-v3. Comienza con 500-1000 pares etiquetados — más produce ganancia marginal.
Chunking: Tamaño ≠ Coherencia Semántica
No existe regla "chunk size 512 tokens es óptimo". Evaluamos 3 estrategias: (1) fixed 512 tokens, (2) basada en headers markdown (corta en H2/H3), (3) chunking semántico (LLM lee contexto de párrafo, divide en transiciones semánticas). Resultado: markdown-based entrega 18% mejor NDCG@5, pero cuesta 2.3x más tiempo en indexación.
El problema del chunking fijo es cortar en mitad de oración. "Si integras tracking server-side con arquitectura de datos first-party..." se divide en token 510, el siguiente chunk comienza "...arquitectura, la precisión de attribution aumenta" — contexto perdido. El retriever encuentra este chunk para query "attribution", pero sin contexto el LLM no puede generar respuesta. La alucinación comienza aquí.
Chunking semántico (no RecursiveCharacterTextSplitter de LangChain — preguntar a gpt-4o-mini "¿este párrafo cambia a una idea nueva?") es superior pero costoso: procesar 10K páginas de base de conocimiento cuesta $47 (0.15$/1M input tokens). Trade-off: indexación es one-time cost, calidad de recuperación es valor continuo. Elegimos semántico, pero si actualizas documentos dinámicamente (semanalmente), fixed chunking es más viable.
| Estrategia | Tamaño Promedio | NDCG@5 | Tiempo Build (10K doc) | Costo |
|---|---|---|---|---|
| Fixed 512 | 489 tokens | 0.71 | 4 min | $0 |
| Basada en Markdown | 680 tokens | 0.84 | 9 min | $0 |
| Semántico (LLM) | 520 tokens | 0.81 | 22 min | $47 |
Estrategia de Solapamiento
Solapar chunks incrementa recall de recuperación — pero aumenta índice 1.4-1.8x. Con 50 tokens de solapamiento vimos 6% de mejora en recall (recall@10: 0.78 → 0.83). Puedes activar solapamiento condicional solo en documentos largos (>2000 tokens) y desactivarlo en contenido corto.
Setup de Evaluación: Métrica Offline → A/B Online
Antes de llevar RAG a producción es obligatorio armar pipeline de evaluación. "La salida del LLM se ve bien" no es suficiente — precision/recall de recuperación y factualidad del LLM se miden por separado.
Medimos dos capas:
- Capa de recuperación: Precision@k, Recall@k, NDCG@k, MRR. Ground truth: pares query-documento etiquetados manualmente (320 en nuestro caso). La métrica
context_precisionde librería Ragas funciona sin LLM, permite iteración rápida. - Capa de generación: Consistencia factual (¿la salida se entaila con el documento?), tasa de alucinación (¿qué % de respuesta sale del documento?), precisión de citación (¿el LLM cita correctamente?). Usamos patrón LLM-as-judge — preguntamos a gpt-4o "¿esta respuesta se basa en el documento?", acuerdo 0.89 (vs evaluación humana).
Evaluación offline corre diariamente (CI/CD integrado). Nueva estrategia de chunking, embedding, reranker: deben pasar métricas verdes antes de commit. A/B testing es aparte: 10% tráfico a versión nueva, monitorear feedback usuario + métricas sesión (task completion, tasa de reformulación query). Si NDCG offline sube 0.02 pero online task completion no cambia, no desplegamos.
Confiabilidad de LLM-as-Judge
No confíes ciegamente en LLM-as-judge. GPT-4o se marcó como alucinante en 6% de casos (falso positivo), perdió 4% de alucinaciones reales (falso negativo). Solución: evaluación human-in-the-loop para casos críticos — audita random 5% de samples, calcula calibration score del judge en ese subset. Si calibration <0.85, revisa prompt del judge.
Reranker: Poder del Segundo Paso
Primera recuperación trae 20-50 chunks (recall-oriented), reranker reduce a 3-5 (precision-oriented). Con Cohere rerank-v3 vimos 14% mejora en precision (P@5: 0.68 → 0.78). Costo: $2 por 1M tokens reranked (10x más caro que embedding), pero pasar 50 chunks al LLM vs 5 reduce tokens y riesgo de alucinación.
El trade-off del reranker es latencia: búsqueda embedding 18ms, agregando rerank llega a 95ms. Con pipeline async es tolerable — mientras usuario envía query, backend corre retrieval+rerank, cuando LLM comienza streaming, latencia total es 400-500ms. Síncrono degrada experiencia.
Sistemas RAG sin reranker asumen "top-k embedding es correcto". Eso aplica solo si hay alto overlap lexical query-chunk. En queries semánticas (¿cómo integro arquitectura first-party con medición server-side?), embedding devuelve 4 chunks irrelevantes en top 10. El reranker usa cross-attention query-documento, limpia ese ruido. Sin reranker en producción, accuracy de citación cae 18%.
Búsqueda Híbrida: BM25 + Embedding
Retrieval solo con embedding falla en dos escenarios: (1) búsquedas de coincidencia exacta (nombre marca, código producto), (2) términos raros (embedding los ha visto poco). BM25 (basado keywords) cierra ese gap. En Weaviate o Qdrant: búsqueda híbrida con 0.7 peso embedding + 0.3 BM25. Recall@10: solo embedding 0.76, híbrido 0.83.
Índice BM25 es 5-8x más pequeño que embedding (inverted index structure). Sin latencia adicional (corre en paralelo). Único costo: query planning — qué ponderación es óptima por tipo de query, lo encuentras con A/B test. En nuestro caso: queries generales usan 0.8 embedding, queries con menciones de marca/producto usan 0.5 embedding.
Monitoreo en Producción
60% del deployment RAG es monitoring — evitar degradación silenciosa. Métricas observadas:
- Cobertura de recuperación: % de queries donde encuentra documento (target >95%)
- Relevancia promedio de contexto: % de chunks entregados al LLM realmente relevantes (target >0.8)
- Tasa de alucinación: % respuesta LLM fuera del documento (target <5%)
- Latencia p95: 95% de queries termina en X tiempo (target <800ms)
- Costo por query: embedding + rerank + LLM (target <$0.02)
Estas métricas se envían a Datadog, alertas Slack si threshold se excede. Si cobertura cae 2 días bajo 92%, hay gap en base de conocimiento — content team actúa. Si alucinación sube, revisa prompt LLM o tamaño chunk. Spike de latencia → sharding de vector database.
Análisis de Datos e Ingeniería de Insights requiere vincular métricas RAG a business outcomes — ¿cuando sube calidad recuperación, sube satisfacción usuario en survey? ¿o es solo métrica técnica inflada? Correlación analysis lo revela.
Balance Costo vs Calidad
Costo mensual RAG en producción: 1M queries, promedio 3 chunks retrieved, generación con gpt-4o-mini = ~$420 (embedding $80, rerank $40, LLM $300). Sin reranker: $380, pero alucinación sube 5% → 11% — más tickets soporte, indirect cost $600+.
Reducción costo correcta: (1) cache layer (query repetida en 24h toma cache, 23% queries son repetidas), (2) embedding model pequeño ajustado dominio (768 dim), (3) rerank async (queries no críticas sin rerank). Resultado: $280, pérdida calidad <2%.
Aproximación equivocada: reemplazar embedding por keyword search, LLM por templates rule-based. Produces sistema que no es realmente "AI" — precision recuperación cae 40%. Optimizar costo nunca debe sabotear calidad de recuperación.
Llevar RAG a producción es más que elegir modelos — requiere disciplina en evaluación, monitoring e iteración. Puedes reducir dimensión embedding y ganar velocidad, pero si recall cae, LLM alucina y pierdes confianza usuario. Primero: recuperación a F1>0.85, después: optimiza costo. Sino, construyes máquina de alucinaciones económica.