Cuando un sistema de generación aumentada por recuperación (RAG) falla, el primer instinto es culpar al modelo de lenguaje. 'Ha alucinado', decimos, y corremos a ajustar el prompt, bajar la temperatura o cambiar a un modelo más grande. Pero la realidad, incómoda y sistemática, es otra: el modelo casi siempre dice la verdad sobre el contexto que recibe. El problema está aguas arriba, en la capa de recuperación. Tu RAG no alucina: tu recuperación miente.
Imagina un asistente de soporte que responde a una pregunta de facturación citando un documento interno real. La respuesta es incorrecta, pero la cita es auténtica. Esa combinación desconcierta: el modelo no inventó nada, simplemente resumió fielmente el fragmento equivocado. La capa de generación es ruidosa y legible; vemos el prompt y la salida. La recuperación, en cambio, devuelve IDs de fragmentos que nadie lee. Por eso, cuando algo se rompe, toda la atención se va a lo que podemos ver: el prompt. Pero cambiar la redacción no cambia el contexto equivocado. He visto equipos perder semanas iterando sobre el prompt cuando el verdadero error era un chunking mal configurado o un modelo de embeddings genérico para un dominio lleno de jerga interna.
Analicemos los cinco modos en que la recuperación miente, ninguno se arregla con un prompt. Primero, el chunking fijo e ingenuo: dividir documentos cada 512 tokens sin respetar la estructura. Un número cae en un fragmento, el encabezado que le da sentido en otro. El modelo recibe '4.200 €' sin saber que es un límite de reembolso. Segundo, el desajuste de embeddings: usar un modelo genérico en un dominio con siglas y nombres de producto que nunca vio en entrenamiento. El documento correcto no rankea porque el espacio de embeddings no entiende tu vocabulario. Tercero, la ausencia de un reranker: la búsqueda vectorial top-k es ruidosa; el pasaje correcto suele estar en el top 20 pero en el puesto 18, y solo alimentamos los primeros 5 al modelo. Cuarto, recuperar demasiado: para subir el recall, metemos 20 fragmentos en el contexto, y el pasaje relevante se pierde entre distractores que bajan la precisión. Quinto, y el que permite a los demás persistir, la falta de evaluación de la recuperación: sin medir si el documento correcto aparece en los resultados, cada regresión es invisible hasta que un usuario la sufre.
La solución no es un truco ingenioso, sino tratar la recuperación como el subsistema ingenieril que es y ponerle números. Dos métricas bastan: Recall@k — de las consultas etiquetadas, ¿en qué fracción apareció el documento dorado en los primeros k resultados? Si el recall@5 es 0,6, el 40% de las respuestas se generan desde un contexto que no contiene la respuesta, y ningún prompt lo arregla. MRR (mean reciprocal rank) — cuando el documento correcto se recupera, ¿qué tan arriba aparece? Un recall alto pero MRR bajo indica que la respuesta está en el top-20 pero enterrada, y un reranker de cross-encoder es la palanca más efectiva. Construir un conjunto etiquetado de pares (consulta, id_documento_dorado) — unos cientos bastan — y ejecutarlo como compuerta en la integración continua es el paso decisivo.
En Q2BSTUDIO, entendemos que la calidad de un sistema de IA no depende solo del modelo generativo, sino de toda la cadena: desde el chunking y los embeddings hasta la orquestación en cloud. Por eso, cuando desarrollamos soluciones de inteligencia artificial para nuestros clientes, integramos desde el diseño métricas de recuperación como recall@k y MRR en los pipelines de CI/CD. No esperamos a que el usuario final reporte un error; lo detectamos en el commit. Esta disciplina nos permite ofrecer aplicaciones a medida robustas, donde cada componente —desde la base de datos vectorial hasta el agente de IA— se evalúa de forma independiente. Además, combinamos la recuperación contextual con servicios de cloud AWS/Azure para escalar sin pérdida de rendimiento, integramos BI con Power BI para visualizar la calidad de la recuperación en dashboards, y blindamos cada capa con ciberseguridad para proteger los datos sensibles. Nuestros agentes de IA, entrenados con corpus propietarios, solo son fiables si la recuperación no miente.
Es tentador pensar que un prompt más restrictivo o un modelo más grande resuelven las alucinaciones. Pero la evidencia empírica muestra que, en la mayoría de los casos, el modelo es inocente. La próxima vez que tu bot RAG responda con seguridad algo incorrecto, no abras el archivo del prompt. Abre el log de recuperación. El modelo probablemente está diciendo la verdad sobre un contexto que le estaba mintiendo. Y recuerda: no puedes arreglar lo que no mides. Mide la recuperación, y verás que el culpable no era quien creías.
