Un sistema RAG que recupera los documentos correctos pero se los presenta mal al modelo tiene el mismo resultado que uno que recupera mal: respuestas imprecisas. El retrieval es la mitad del problema — cómo estructuras lo recuperado es la otra mitad, y es la que menos equipos cuidan.
Los modelos de lenguaje no le prestan atención uniforme a todo el contexto. La evidencia consistente en la industria es que la información al principio y al final del contexto se procesa con más fidelidad que la que queda en el medio. Si tu RAG mete 10 documentos y el dato crítico está en el documento número 6, el modelo tiene más probabilidad de perderlo que si estuviera en el 1 o el 10.
La implicación práctica: no basta con recuperar los documentos correctos por relevancia bruta — el **orden** en que los presentas importa. Pon el documento más relevante (según tu reranker) al principio y al final, no en medio de una lista larga.
La búsqueda por similitud de embeddings recupera documentos "semánticamente parecidos", pero eso no es lo mismo que "los documentos que realmente responden la pregunta". Un paso de reranking — un modelo (o incluso el mismo LLM) que reordena por relevancia real a la query específica — reduce drásticamente el ruido que llega al contexto final.
El patrón "recall amplio + reranking estrecho" es más barato y más preciso que subir el `k` del retrieval vectorial directamente, porque el reranker opera sobre un set pequeño ya pre-filtrado.
Un error común: concatenar los chunks recuperados como texto plano, sin marcar dónde empieza y termina cada fuente. Esto hace que el modelo no pueda distinguir de dónde viene cada afirmación, lo cual dificulta tanto la precisión como la capacidad de citar fuentes.
Delimitar cada fuente con XML o markdown no es cosmético — mejora medible mente la capacidad del modelo de atribuir correctamente cada dato a su origen, y hace posible pedir citas verificables.
Algunos modelos soportan un modo de citations nativo: en vez de pedirle al modelo que "cite la fuente" en texto libre (que puede alucinar la cita), el sistema devuelve automáticamente qué fragmento exacto del documento respalda cada parte de la respuesta.
Esto elimina una clase entera de alucinación: la cita "inventada" que suena plausible pero no corresponde al texto real.
Es común que el retrieval devuelva múltiples chunks que dicen esencialmente lo mismo (el mismo dato repetido en distintas secciones de un documento, o en documentos casi duplicados). Meter los tres al contexto no mejora la respuesta — infla tokens y aumenta la superficie para contradicciones si las versiones tienen matices distintos.
Una deduplicación simple por similitud entre chunks recuperados, antes de construir el prompt final, suele reducir el tamaño del contexto sin perder cobertura.
Si múltiples usuarios preguntan sobre el mismo documento base, o el mismo usuario hace varias preguntas sobre el mismo contexto recuperado en una sesión, ese bloque de contexto es candidato directo para `cache_control` — exactamente el mismo principio del artículo de prompt caching, aplicado específicamente al contenido recuperado por RAG en vez del system prompt.
El error final más común: cuando el RAG falla, se asume que es un problema del modelo generando mal la respuesta. Antes de tocar el prompt, verifica si el problema es que el retrieval nunca trajo el documento correcto en primer lugar. Un set de evaluación con preguntas cuya respuesta correcta conoces, y el documento que la contiene identificado de antemano, te permite medir por separado:
- **Recall del retrieval:** ¿el documento correcto estuvo entre los recuperados? - **Precisión de generación:** dado que el documento correcto estuvo presente, ¿el modelo lo usó bien?
Mezclar estas dos métricas es la razón número uno por la que los equipos "arreglan" el prompt cuando el problema real estaba en el índice de búsqueda.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel