Por qué tu pipeline RAG te está mintiendo
La mayoría de los pipelines RAG recuperan los fragmentos equivocados el 30-40% de las veces. Aquí te explico cómo detectarlo.
9 de marzo de 2026
Una verdad incómoda: tu pipeline RAG probablemente está recuperando información equivocada un tercio de las veces.
No lo suficientemente mal como para fallar. No lo suficientemente mal como para colapsar de forma obvia. Solo lo suficientemente mal como para producir respuestas que suenan seguras pero son sutilmente, peligrosamente incorrectas.
He auditado decenas de implementaciones RAG. El patrón es constante: los equipos construyen pipelines, los prueban con unos pocos ejemplos felices, declaran el éxito y los lanzan. Seis meses después, los usuarios se quejan de que el sistema "no funciona del todo" y nadie sabe por qué.
El problema no es el LLM. Es la recuperación. Y casi nadie la está midiendo.
El modo de fallo oculto
Déjame mostrarte a qué me refiero.
Escenario: RAG de soporte al cliente
Base de conocimiento: 10.000 documentos. El usuario pregunta: ¿Cómo restablezco mi contraseña?
Lo que ocurre:
- 1. La consulta se convierte en embedding
- 2. La búsqueda vectorial encuentra fragmentos "similares"
- 3. Los 5 fragmentos principales van al LLM
- 4. El LLM genera una respuesta
Lo que ves: Una respuesta con apariencia razonable sobre el restablecimiento de contraseña.
Lo que no ves:
Los fragmentos recuperados en realidad trataban sobre:
- ❌Fragmento 1: Requisitos de la política de contraseñas (no instrucciones de restablecimiento)
- ⚠️Fragmento 2: Recuperación de cuenta (parecido, pero proceso distinto)
- ✓Fragmento 3: Restablecimiento de contraseña (¡correcto!)
- ❌Fragmento 4: Configuración de autenticación de dos factores (equivocado)
- ❌Fragmento 5: Política de expiración de contraseñas (equivocado)
El LLM vio un fragmento relevante de cada cinco. Improvisó con su conocimiento paramétrico para rellenar los huecos. La respuesta parece correcta, pero contiene detalles que no están en tu base de conocimiento.
Esto ocurre el 30-40% de las veces en despliegues RAG típicos.
Por qué nadie detecta esto
Tres razones por las que este modo de fallo persiste:
Razón 1
Solo pruebas de extremo a extremo
La mayoría de los equipos prueba haciendo preguntas y comprobando si la respuesta parece razonable. Esto evalúa el pipeline completo—recuperación, aumento y generación—como una caja negra. Cuando la respuesta es incorrecta, no sabes por qué. ¿Fue mala recuperación? ¿Mal prompting? ¿Alucinación del LLM?
Necesitas probar la recuperación por separado.
Razón 2
Los LLM son buenos sonando seguros
Cuando el LLM recibe un contexto en su mayoría equivocado, no dice "no estoy seguro". Genera una respuesta plausible usando cualquier retazo de relevancia que encontró, más su conocimiento de entrenamiento.
La respuesta suena autoritaria. Los usuarios confían en ella. El fallo es invisible.
Razón 3
Las métricas de recuperación no están en tu panel
Lo que estás monitoreando:
- • Latencia de respuesta
- • Uso de tokens
- • Satisfacción del usuario (tal vez)
- • Tasas de error
Lo que NO estás monitoreando:
- • Precisión de recuperación
- • Cobertura de recuperación
- • Puntuaciones de relevancia de fragmentos
- • Utilización del contexto
Si no mides la calidad de la recuperación, no sabes cuándo está fallando.
Cómo detectarlo
Este es el marco de evaluación que uso:
Paso 1: Construye un conjunto de pruebas de recuperación
Crea un conjunto de datos de consultas emparejadas con los documentos de origen correctos.
retrieval_test_set = [
{
"query": "How do I reset my password?",
"relevant_doc_ids": ["doc_123", "doc_456"],
"relevant_chunks": ["chunk_123_2", "chunk_456_1"]
},
{
"query": "What's the refund policy for annual subscriptions?",
"relevant_doc_ids": ["doc_789"],
"relevant_chunks": ["chunk_789_3", "chunk_789_4"]
},
# 50-100 examples covering your key use cases
]Cómo crear esto
- • Toma consultas reales de usuarios de los registros
- • Haz que una persona identifique los documentos de origen correctos
- • Mapea a fragmentos específicos
Sí, este es un trabajo manual. Vale la pena. Empieza con 50 ejemplos que cubran tus consultas más importantes.
Paso 2: Mide la calidad de la recuperación
Para cada consulta de prueba, ejecuta tu recuperación y mide:
def evaluate_retrieval(test_set, retriever, k=5):
results = []
for test in test_set:
# Run retrieval
retrieved = retriever.retrieve(test["query"], top_k=k)
retrieved_ids = [chunk.id for chunk in retrieved]
# Calculate metrics
relevant_set = set(test["relevant_chunks"])
retrieved_set = set(retrieved_ids)
# Precision: What fraction of retrieved chunks are relevant?
precision = len(relevant_set & retrieved_set) / len(retrieved_set)
# Recall: What fraction of relevant chunks did we retrieve?
recall = len(relevant_set & retrieved_set) / len(relevant_set)
# Hit rate: Did we get at least one relevant chunk?
hit = len(relevant_set & retrieved_set) > 0
# MRR: Where does the first relevant chunk appear?
mrr = 0
for i, chunk_id in enumerate(retrieved_ids):
if chunk_id in relevant_set:
mrr = 1 / (i + 1)
break
results.append({
"query": test["query"],
"precision": precision,
"recall": recall,
"hit": hit,
"mrr": mrr
})
return resultsMétricas clave y objetivos
| Métrica | Qué mide | Objetivo |
|---|---|---|
| Hit Rate | % de consultas con al menos 1 fragmento relevante | >95% |
| Precision@k | % de fragmentos recuperados que son relevantes | >60% |
| Recall@k | % de fragmentos relevantes que se recuperan | >80% |
| MRR | Posición promedio del primer fragmento relevante | >0.7 |
Si tu hit rate está por debajo del 90%, tienes un problema serio. Si la precisión está por debajo del 50%, estás inundando el LLM con ruido.
Paso 3: Analiza los patrones de fallo
No solo midas—entiende por qué falla la recuperación.
Patrón 1
Confusión semántica
Una consulta sobre "restablecer contraseña" recupera fragmentos sobre "política de contraseñas"—semánticamente similares, funcionalmente distintos.
Patrón 2
Contexto faltante
La información relevante se reparte entre varios fragmentos, pero la recuperación solo obtiene una parte.
Patrón 3
Desajuste de palabras clave
El usuario dice "cancelar suscripción" pero la documentación dice "terminar servicio"—brecha semántica.
Patrón 4
Problemas de vigencia
Los fragmentos recuperados provienen de documentos desactualizados.
Patrón 5
Sesgo de popularidad
El contenido accedido con frecuencia se recupera incluso cuando no es relevante.
Los problemas más comunes (y sus soluciones)
Problema 1: Los fragmentos son demasiado pequeños
Síntoma: Cobertura alta, precisión baja. Recuperas contenido relevante, pero cada fragmento carece de contexto.
Por qué ocurre: Un particionado agresivo (200-300 tokens) divide unidades lógicas de información.
Solución: Aumenta el tamaño del fragmento a 500-800 tokens. Usa particionado semántico que respete la estructura del documento.
Problema 2: Los fragmentos son demasiado grandes
Síntoma: Precisión baja, mucho ruido. Los fragmentos recuperados contienen información relevante enterrada en contenido irrelevante.
Por qué ocurre: Los fragmentos grandes (1000+ tokens) mezclan múltiples temas.
Solución: Reduce el tamaño del fragmento. Usa recuperación jerárquica—recupera fragmentos grandes y luego reordena segmentos más pequeños.
Problema 3: Sin superposición entre fragmentos
Síntoma: La información importante en los límites de los fragmentos se pierde.
Por qué ocurre: Los fragmentos adyacentes no comparten contexto.
Solución: Añade un 10-20% de superposición entre fragmentos.
Problema 4: Desajuste del modelo de embeddings
Síntoma: Los fragmentos semánticamente relevantes no aparecen.
Por qué ocurre: Tu modelo de embeddings no fue entrenado en tu dominio. "Cancelar" y "terminar" pueden no estar cerca en el espacio de embeddings.
- • Prueba distintos modelos de embeddings (p. ej., text-embedding-3-large vs voyage-2)
- • Ajusta los embeddings en tu dominio
- • Añade búsqueda por palabras clave como respaldo (búsqueda híbrida)
Problema 5: Sin preprocesamiento de consultas
Síntoma: Las consultas conversacionales no coinciden con el lenguaje de la documentación.
Por qué ocurre: Los usuarios preguntan "¿Cómo cambio mi contraseña?" pero la documentación dice "Procedimiento de restablecimiento de contraseña".
Solución: Reescribe las consultas antes del embedding. Usa un LLM para convertirlas al lenguaje de la documentación.
Problema 6: Sin filtrado por metadatos
Síntoma: Se recupera de categorías de documentos equivocadas.
Por qué ocurre: Una pregunta sobre "precios Enterprise" recupera fragmentos de la documentación de "precios Starter"—semánticamente similares, contexto equivocado.
Solución: Añade filtros de metadatos antes de la búsqueda vectorial (categoría, versión, fecha, etc.).
Una checklist para depurar la recuperación
Cuando la calidad de la recuperación cae, revisa esto:
- □Revisa el desempeño del modelo de embeddings en tu dominio
Ejecuta las mismas consultas con distintos modelos. Busca brechas sistemáticas.
- □Analiza los límites de los fragmentos
¿Las unidades lógicas están divididas? ¿La superposición es suficiente?
- □Revisa los patrones de fallo
¿Confusión semántica? → Mejores embeddings o reescritura de consultas
¿Contexto faltante? → Fragmentos más grandes o recuperación parent
¿Categoría equivocada? → Filtrado por metadatos - □Prueba la recuperación híbrida
Añade BM25/palabras clave como respaldo. Compara los hit rates.
- □Verifica contenido obsoleto
¿Aún hay documentos desactualizados indexados? ¿La vigencia pondera en el ranking?
- □Examina los casos límite
Consultas con errores tipográficos. Preguntas de varias partes. Negaciones ("SIN incluir...").
Victorias rápidas para implementar hoy
Si no haces nada más:
1
Crea 50 consultas de prueba
con documentos relevantes etiquetados
2
Mide el hit rate y la precisión
en tu recuperación actual
3
Añade búsqueda híbrida
vectorial + palabras clave como red de seguridad
4
Registra cada recuperación
para análisis posterior
5
Revisa 10 recuperaciones aleatorias por semana
manualmente
Son unas pocas horas de trabajo. Te ahorrarán meses depurando problemas misteriosos de calidad en las respuestas.
RAG no es solo "añadir búsqueda a tu LLM". Es un problema de recuperación que resulta usar un LLM para la generación.
La comunidad de recuperación tiene décadas de investigación sobre esto. Precisión, cobertura, ranking, evaluación—son problemas resueltos. El ecosistema RAG en su mayoría los ha ignorado.
No cometas ese error.
Construye la evaluación dentro de tu pipeline desde el primer día.
Empieza a medir. Empieza a mejorar. Deja de mentir.
¿Construyes sistemas RAG y quieres ayuda para acertar la recuperación?
HablemosEste es uno de los problemas que más solucionamos.
Artículos relacionados
RAG y GraphRAG
GraphRAG en producción: lecciones de 5 despliegues
Cuando el RAG vectorial no es suficiente.
Análisis técnicos profundos
La arquitectura multi-agente que realmente escala
Patrones que descubrimos después de 5 despliegues en producción.
Realidad de producción
Por qué el 90% de los proyectos de IA nunca llegan a producción
No son los modelos. Es todo lo que rodea a los modelos.
Newsletter
Patrones RAG y optimización de recuperación—cada martes.
Únete a más de 2.500 ingenieros y líderes que reciben ideas prácticas de implementación de IA.
Suscríbete a AI That Ships