Errores en RAG: 6 razones por las que falla la memoria de un agente de IA, y cómo diagnosticar el retrieval

RAG (Retrieval-Augmented Generation) conecta una base de conocimiento externa a las respuestas de un LLM, con la promesa de librar al modelo de las alucinaciones. En la práctica, el 73% de los fallos en sistemas RAG se debe a una mala búsqueda, y el 40% de los pipelines no logra recuperar los datos necesarios en absoluto. Los ingenieros suelen intentar tratar los síntomas: cambian el modelo de embeddings, aumentan el top-k, actualizan el LLM. Pero si desde el principio llegó al prompt un contexto inadecuado, lo que está roto es la capa de retrieval, y la alucinación es solo la consecuencia de ese error.

El estudio RAGGED reveló que LLaMA y Claude alcanzan su pico con apenas 5 fragmentos, y a partir de ahí la calidad cae rápidamente. Claude obtuvo su mejor resultado con un único fragmento muy preciso. Inflar el contexto al máximo resulta perjudicial.

Seis puntos de fallo

1. El chunking destruye el contexto — la división fija en bloques de 512 tokens separa una entidad de la oración que la califica, un fragmento sin su título pierde sentido, y una tabla de 200 filas se convierte en ruido. Solución: dividir según la estructura del documento, trasladar los títulos a cada fragmento y usar embeddings contextuales. Según Anthropic, esto reduce los errores un 35%, un 49% combinado con BM25 contextual, y un 67% con reranking.

2. Brecha semántica — los embeddings no captan la intención. El usuario pregunta «¿Cómo cancelo mi suscripción?», y el documento se titula «Política de terminación de cuenta». Solución: búsqueda híbrida (embeddings + BM25 mediante Reciprocal Rank Fusion con k=60), reformulación de la consulta y HyDE (búsqueda a partir de una respuesta hipotética).

3. Desajuste entre retrieval y generación — aumentar el top-k mejora el Hit@k, pero luego la calidad de la respuesta cae. El estudio de Liu et al., «Lost in the Middle», mostró que el modelo aprovecha mejor la información situada al principio y al final del contexto. El valor óptimo de top-k se ajusta de forma experimental; RAGGED demostró que el óptimo va desde k ≤ 1 hasta k ≥ 10. El umbral de recall es del 85%; por debajo de eso, hay que arreglar el retrieval.

4. Multi-hop — RAG no sabe razonar en cadena. La pregunta «¿Quién es el director general de la empresa que adquirió el proveedor de un competidor?» exige cuatro pasos de búsqueda. Solución: RAG iterativo (agéntico) o memoria basada en grafos (Neo4j, Cognee, Microsoft GraphRAG). El costo es más latencia y gasto.

5. Sin noción del tiempo — el índice no sabe que un documento quedó obsoleto. Solución: filtrado por metadatos, versionado, reindexación automática y monitoreo de la deriva de calidad.

6. Resolución de entidades — «Apple» (¿la empresa o la fruta?), «Ivanov A.V.» y «A. Ivanov» parecen entidades distintas. Solución: extraer entidades durante la indexación, construir un índice vinculado y buscar a través de un grafo.

Cuándo no hace falta RAG

Una consulta como «muéstrame todos los clientes con riesgo de abandono superior a 0,7» es SQL, no búsqueda. RAG no sabe hacer agregaciones, ordenamientos ni filtros numéricos. Para eso se necesita Text-to-SQL o una capa semántica sobre el almacén de datos. Los detectores genéricos pasan por alto el 43% de los errores de cálculo.

Diagnóstico: tres métricas

Context Relevance detecta errores de chunking y retrieval (se devolvieron los fragmentos equivocados). Context Recall detecta omisiones (el fragmento con la respuesta no se devolvió). Groundedness detecta alucinaciones a pesar de contar con el contexto correcto. La pregunta clave es: ¿está roto el retrieval o la generación? Son problemas de ingeniería distintos, con soluciones distintas.