Tu equipo montó un prototipo de RAG en dos semanas. En la demo funcionaba. En producción, los usuarios se quejan de respuestas irrelevantes, el consumo de tokens se dispara y nadie confía en las respuestas. No es un problema de LLMs. Es un problema de arquitectura de retrieval.
Retrieval-Augmented Generation prometía resolver las alucinaciones de los LLMs conectándolos con datos reales. Y lo hace, cuando la arquitectura es correcta. Pero la mayoría de implementaciones enterprise caen en los mismos tres errores que transforman RAG de una inversión en un sumidero de presupuesto.
Según datos recientes, el 80% de proyectos RAG enterprise experimentan fallos críticos en producción. El 42% de proyectos de IA fallaron en 2025, representando 13.800 millones de dólares en gasto enterprise en riesgo. Y la raíz no es tecnológica: es la brecha entre un prototipo que impresiona y un sistema que funciona a escala.
Error #1: Recuperación sin curación de datos
El primer error es el más básico y el más costoso: conectar un LLM a una base de conocimiento sin curar los datos que la alimentan. Garbage in, garbage out, pero ahora con un coste de tokens por cada consulta basura.
En la práctica, esto se manifiesta en quejas como: "Le pregunté por la política de vacaciones actualizada y me dio el borrador del Q1", o "Dice que no tenemos política de devoluciones cuando la actualizamos hace dos meses". El LLM responde con lo que encuentra. Si encuentra documentos desactualizados, duplicados o contradictorios, la respuesta refleja ese caos.
El dato crítico: El 80% de los fallos de RAG se originan en decisiones de chunking, no en el retrieval ni en la generación. Chunking naíf con tamaño fijo alcanza un faithfulness score de 0,47-0,51. Chunking semántico optimizado llega a 0,79-0,82. Esa diferencia es la que separa un sistema útil de uno que genera desconfianza.
Cómo evitarlo
- Curación activa: No indexes todo. Filtra documentos obsoletos, elimina duplicados, normaliza formatos antes de ingestar.
- Chunking semántico: Divide documentos por unidades de significado (secciones, párrafos temáticos), no por número de caracteres.
- Metadata enriquecida: Cada chunk debe llevar fecha, fuente, versión y categoría. Sin metadata, el retriever no puede priorizar el documento correcto.
Error #2: Ignorar re-ranking y validación de relevancia
El segundo error es confiar ciegamente en el retriever. Un vector search devuelve los chunks "más cercanos" semánticamente, pero cercanía semántica no es lo mismo que relevancia para la pregunta del usuario.
Sin re-ranking, el LLM recibe contexto que es vagamente relacionado pero no directamente útil. El resultado: respuestas genéricas, contexto inflado que consume tokens innecesarios y una confianza del usuario que cae rápidamente.
Arquitectura híbrida: la solución que funciona
La arquitectura que vemos funcionar en producción combina tres capas:
- Retrieval híbrido (dense + sparse): Búsqueda vectorial (embeddings) para capturar significado semántico + BM25 para coincidencia exacta de términos. Reciprocal Rank Fusion (RRF) combina ambos rankings en uno.
- Re-ranking semántico: Un modelo transformer (ColBERT, Cohere Rerank, o similar) reordena los resultados por relevancia real a la query. Filtra el ruido antes de que llegue al LLM.
- Validación de relevancia: Un score mínimo de relevancia para cada chunk. Si ningún resultado supera el umbral, el sistema responde "no tengo información suficiente" en lugar de alucinar.
Query del usuario
│
├─→ Dense retrieval (embeddings) ──→ Top 20 candidatos
│
├─→ Sparse retrieval (BM25) ──────→ Top 20 candidatos
│
└─→ Reciprocal Rank Fusion ───────→ Top 20 fusionados
│
Re-ranker (ColBERT)
│
Top 5 relevantes
│
Score > umbral?
│ │
Sí No
│ │
LLM genera "No tengo información
respuesta suficiente para responder" Error #3: RAG simple cuando el caso requiere agenticidad
El tercer error es aplicar RAG naíf a problemas que requieren razonamiento multi-paso. Preguntas como "¿Cuál es la diferencia entre nuestra política de viajes de 2024 y la de 2025?" necesitan recuperar dos documentos, compararlos y sintetizar las diferencias. Un RAG simple recupera chunks y los pasa al LLM sin capacidad de razonamiento intermedio.
Pero el error opuesto también existe: equipos que saltan directamente a Agentic RAG cuando un pipeline simple sería suficiente. Cada paso agéntico consume tokens adicionales. Cada llamada a herramientas añade latencia y coste.
El coste compuesto: En un sistema con fallos en cascada donde cada capa tiene un 95% de precisión, la fiabilidad total cae al 81%. Cada capa agéntica que añades multiplica los puntos de fallo y el consumo de tokens. En 2024, el 90% de proyectos de RAG agéntico fallaron en producción precisamente por este efecto compuesto.
Cuándo escalar de RAG simple a agéntico
| Tipo de consulta | Arquitectura | Por qué |
|---|---|---|
| Pregunta factual directa | RAG simple | Un retrieval + una generación. Sin overhead agéntico. |
| Comparación entre documentos | RAG agéntico | Necesita múltiples retrievals y razonamiento intermedio. |
| Resumen de un documento | RAG simple | El documento se recupera y se resume en un paso. |
| Análisis cruzado multi-fuente | RAG agéntico | Requiere planificar qué fuentes consultar y en qué orden. |
| FAQ sobre políticas internas | RAG simple | Respuestas directas con bajo coste por query. |
| Investigación con reasoning multi-hop | RAG agéntico | La respuesta depende de encadenar hallazgos intermedios. |
Herramientas de benchmark: medir antes de poner en producción
Uno de los patrones más costosos que vemos es equipos que despliegan RAG a producción sin un framework de evaluación. Descubren los fallos cuando los usuarios se quejan, no cuando podrían haberlos prevenido.
RAGAS (Retrieval-Augmented Generation Assessment Suite) se ha convertido en el estándar de facto para evaluación de RAG, con más de 400.000 descargas mensuales y 20 millones de evaluaciones ejecutadas. Lo relevante para equipos que quieren evitar tirar presupuesto: RAGAS evalúa calidad sin necesidad de labels manuales.
Las 4 métricas que debes medir antes de producción
- Faithfulness: ¿La respuesta se basa fielmente en el contexto recuperado o añade información inventada? Es la métrica anti-alucinaciones.
- Context Precision: ¿Los chunks recuperados son relevantes para la pregunta? Un score bajo indica que estás enviando ruido al LLM y pagando tokens por contexto inútil.
- Context Recall: ¿Se recupera toda la información necesaria para responder? Un score bajo indica que el retriever no encuentra lo que debería.
- Answer Relevance: ¿La respuesta generada realmente contesta la pregunta del usuario? Mide el gap entre intención y output.
Regla práctica: Si tu faithfulness score está por debajo de 0,75, no pongas el sistema en producción. Cada punto por debajo es una alucinación que tus usuarios encontrarán, y cada alucinación erosiona la confianza más rápido de lo que cuesta arreglarla.
ROI: cuándo RAG justifica la inversión
RAG no es siempre la respuesta correcta. A veces un fine-tuning es más eficiente. A veces una búsqueda tradicional con buena UX es suficiente. La pregunta no es "¿podemos implementar RAG?" sino "¿RAG nos da retorno sobre la inversión en este caso?"
RAG: ROI positivo vs overhead
ROI positivo
- Base de conocimiento que cambia frecuentemente (no viable con fine-tuning)
- Volumen alto de consultas repetitivas sobre documentación interna
- Necesidad de trazabilidad (saber de qué documento viene cada respuesta)
- Múltiples fuentes de datos que deben consultarse de forma unificada
Probablemente overhead
- Base de conocimiento estática y pequeña (fine-tuning es más eficiente)
- Pocas consultas al día (el coste de infraestructura no se amortiza)
- Datos no estructurados sin posibilidad de curar (garbage in permanente)
- El equipo no tiene capacidad para mantener el pipeline en producción
Conclusión: RAG funciona cuando la arquitectura es honesta
RAG no es magia. Es una arquitectura con componentes que pueden fallar independientemente y cuyo coste se acumula en cada capa. Los equipos que obtienen valor real de RAG son los que tratan cada componente con la misma rigurosidad que cualquier sistema de producción:
- Curan datos antes de indexar, no después de quejarse los usuarios.
- Implementan re-ranking en lugar de confiar ciegamente en el retriever.
- Eligen la complejidad justa para cada tipo de consulta, sin sobreingeniería agéntica cuando un RAG simple es suficiente.
- Miden antes de desplegar con RAGAS u otro framework de evaluación.
El 71% de organizaciones usa GenAI de forma regular, pero solo el 17% atribuye más del 5% de su EBIT a GenAI. La brecha entre usar IA y obtener retorno de ella se cierra con arquitectura correcta, no con más tokens.
Un RAG bien diseñado reduce costes y mejora respuestas. Un RAG mal diseñado solo multiplica la factura de tokens.