Hágale a un sistema de generación aumentada por recuperación (RAG) una pregunta cuya respuesta no está en su base de documentos, y no le va a decir “no encontrado”. Va a recuperar los k pasajes más similares — siempre existen k pasajes más similares —, se los va a entregar a un modelo de lenguaje, y va a generar una respuesta fluida, segura y bien estructurada con lo que sea que recibió. Ninguna etapa falla. Ninguna etapa siquiera lo nota.

Ese no-error es el tema de este post. Esta es la parte 3 de nuestra serie técnica: la parte 1 cubrió qué rompe de verdad al OCR, y la parte 2 cubrió cómo funcionan de verdad la inferencia y la interpretabilidad. Esta trata sobre RAG — qué pasa realmente entre la pregunta y la respuesta, etapa por etapa, y los mecanismos específicos por los que el pipeline produce algo plausible en vez de algo verdadero. “RAG puede alucinar” es un lugar común. Los mecanismos no lo son.

La arquitectura, etapa por etapa

RAG como idea es simple, y vale la pena enunciar la formulación original con precisión: Lewis et al. (NeurIPS 2020) emparejaron un modelo generativo preentrenado con un recuperador denso sobre un índice externo, de modo que el conocimiento viva en un almacén consultable e intercambiable en vez de quedar congelado en los pesos del modelo — y mostraron que la combinación genera salida más factual que la misma clase de modelo dependiendo solo de sus pesos. Esa es la promesa. Un sistema RAG de producción en 2026 es un pipeline de unas seis etapas construido sobre esa promesa — ingerir, segmentar, generar embeddings e indexar en tiempo de construcción; recuperar, re-rankear, ensamblar y generar en tiempo de consulta — y cada una tiene su propia manera de fallar sin levantar un error.

La segmentación decide qué puede encontrarse, antes de que nada busque

Los documentos se parten en fragmentos (chunks), y el fragmento — no el documento — es la unidad de recuperación. Eso convierte la segmentación en una decisión sobre qué hechos son encontrables en absoluto, tomada en tiempo de indexado, invisible en tiempo de consulta. Una regla y su excepción que caen en fragmentos distintos son, para el recuperador, dos hechos sin relación entre sí.

El arreglo intuitivo es la “segmentación semántica” — cortar en fronteras de significado en vez de en un conteo fijo de tokens. Intuitivo, y no claramente respaldado: Qu, Tu y Bao (2024) compararon segmentación semántica contra segmentación de tamaño fijo en recuperación de documentos, recuperación de evidencia y generación de respuestas basada en recuperación, y encontraron que el costo computacional de la segmentación semántica no se justifica con ganancias consistentes de desempeño. La conclusión honesta es que la segmentación es una decisión de ingeniería específica de cada corpus que usted tiene que medir, no un default resuelto que pueda importar. El tamaño del fragmento, el solapamiento, y si se respetan las fronteras estructurales (secciones, cláusulas, páginas) interactúan con sus documentos y sus consultas; la ablación de otro no se transfiere limpiamente.

Los embeddings capturan de qué trata un texto, no sus condiciones de verdad

Un modelo de embeddings mapea texto a un vector de modo que los textos “que tratan de lo mismo” queden cerca entre sí. Lea esa definición literalmente, porque la falla está adentro: “la apelación debe presentarse dentro de cinco días” y “la apelación no necesita presentarse dentro de cinco días” tratan exactamente de lo mismo. Son bolsas de temas casi idénticas apuntando a desenlaces jurídicos opuestos. La similitud es tematicidad — no es acuerdo, no es implicación lógica, y no es relevancia para su pregunta específica.

Hay una segunda limitación, mejor medida: el cambio de dominio. Thakur et al. (BEIR, NeurIPS 2021 Datasets and Benchmarks) evaluaron modelos de recuperación en modo zero-shot sobre 18 datasets heterogéneos y encontraron que los recuperadores densos — con toda su eficiencia — a menudo rinden por debajo fuera de su dominio de entrenamiento, mientras que BM25, la línea base léxica con décadas de edad, se sostiene como una base robusta a través de dominios. Un modelo de embeddings afinado sobre preguntas de la web nunca vio la distribución de vocabulario de su dominio, y su noción de “similar” se degrada en silencio exactamente donde usted no puede verlo.

Recuperación: densa, dispersa, y por qué los sistemas serios corren ambas

La recuperación dispersa (BM25 y su familia) empareja términos exactos, ponderados por rareza. Es imbatible en los tokens que más importan en dominios especializados — números de artículo, roles de causa, términos técnicos que no aparecen en ningún otro lado. No sabe nada de sinónimos. La recuperación densa es la imagen especular: encuentra la paráfrasis y la reformulación, y puede perderse un identificador exacto porque “significado similar” nunca fue igualdad de cadenas. La recuperación híbrida — correr ambas y fusionar las listas ordenadas — no es una cobertura para indecisos; los resultados zero-shot de BEIR son la razón medida por la que se volvió el default serio. Cada método cubre el punto ciego del otro, y los puntos ciegos son reales.

El re-ranking es donde la relevancia se juzga de verdad

La primera etapa de recuperación es rápida porque es superficial: la consulta y cada pasaje se convierten en embeddings por separado, y nunca llegan a leerse mutuamente. Un re-ranker de tipo cross-encoder lee la consulta y un pasaje candidato juntos, en una sola pasada, y puntúa el par — un juicio fundamentalmente más expresivo, y en la misma medida demasiado caro para correrlo sobre el corpus completo. Así que la arquitectura que funciona es cobertura-y-luego-precisión: una primera etapa barata trae un conjunto amplio de candidatos, una segunda etapa cara reordena la parte alta. En la evaluación entre dominios de BEIR, los modelos de re-ranking y de interacción tardía fueron los de mejor desempeño — a mayor costo computacional. Si su pipeline no tiene etapa de re-ranking, la relevancia en su sistema la está juzgando por completo el componente menos expresivo que hay en él.

El ensamblado de contexto: la posición no es neutral

Los fragmentos mejor rankeados se concatenan en el prompt, y es tentador tratar ese paso como plomería trivial. No lo es. Liu et al. (Lost in the Middle, TACL 2024) midieron cómo los modelos usan entradas largas y encontraron una curva en U: el desempeño es más alto cuando la información relevante está al principio o al final del contexto, y se degrada significativamente cuando queda en el medio — incluso en modelos construidos explícitamente para contextos largos. Dos consecuencias directas. El orden en que usted pega los fragmentos recuperados cambia la calidad de la respuesta, con independencia de la calidad de la recuperación. Y “use una ventana de contexto más grande y recupere más” no es gratis: cada fragmento extra que mete empuja algún otro hacia el medio.

Dónde falla en silencio

Una caída del sistema es un regalo: usted la ve. Lo que sigue son cinco mecanismos que producen, cada uno, una respuesta fluida, plausible y equivocada — y la razón para separarlos es que tienen arreglos distintos, y un número de exactitud de extremo a extremo no puede decirle cuál de ellos tiene usted.

1. El fallo de recuperación que no parece un fallo. La recuperación top-k devuelve k resultados por construcción. Los puntajes de similitud son relativos, no calibrados: la mejor coincidencia para una pregunta que su corpus no puede responder igual vuelve con un puntaje de aspecto respetable, porque “lo mejor disponible” y “bueno” son afirmaciones distintas y la similitud de coseno solo hace la primera. El generador recibe k pasajes temáticamente adyacentes y hace lo que hacen los generadores. Nada en el pipeline representa el concepto “la respuesta no está acá”.

2. Similitud que no es relevancia. El pasaje que comparte más vocabulario con su pregunta es con frecuencia el que replantea la pregunta, no el que la responde — el escrito que plantea el asunto, no la resolución que lo zanja; la cláusula que menciona el plazo, no la cláusula que lo fija. La cercanía en el espacio de embeddings es tematicidad (véase arriba), y los resultados de cambio de dominio de BEIR dicen que la brecha entre tematicidad y relevancia se ensancha precisamente en los corpus especializados donde más importa.

3. La frontera de fragmento que partió el hecho. La regla general cierra el fragmento 41; la excepción que la revierte para su caso abre el fragmento 42. El recuperador devuelve el fragmento 41 — legítimamente, porque la regla comparte más términos con la consulta que la excepción — y el generador resume con fidelidad lo que recibió. La respuesta enuncia la regla, con seguridad, menos la excepción. Note lo que esta falla no es: no es una alucinación. Es generación fiel sobre evidencia truncada, y cada métrica de fidelidad que usted corra le va a poner puntaje perfecto.

4. El generador que ignora el contexto que recibió. La recuperación funcionó. El pasaje correcto está en el prompt — rankeado séptimo de diez, sentado a mitad del contexto, exactamente donde Lost in the Middle midió el valle. O está bien posicionado, y el prior paramétrico del modelo — lo que sus pesos ya creen sobre la pregunta — le gana a la evidencia que tiene enfrente. La respuesta llega envuelta en un marco que suena fundamentado (“según los documentos provistos…”) que ninguna parte del sistema verificó.

5. El corpus estaba mal antes de que nada de esto corriera. Esta es la falla que tenemos razones directas para tomarnos como algo personal. Zhang et al. (OHRBench, ICCV 2025) — que citamos en la parte 1 y volvimos a verificar para este post — evaluaron soluciones de OCR actuales específicamente por cómo sus errores se propagan en cascada hacia RAG, sobre más de 8.500 imágenes de documentos y pares de pregunta-respuesta de siete dominios de aplicación, y concluyeron que ninguna de las soluciones de OCR evaluadas era competente para construir bases de conocimiento de alta calidad para sistemas RAG. Distinguen el ruido semántico (contenido equivocado) del ruido de formato (estructura equivocada) y muestran el desempeño de RAG degradándose a medida que cualquiera de los dos crece. Ahora conecte eso con el hallazgo central de la parte 1: un pipeline de OCR puede perder una línea completa de texto con 98% de confianza reportada. Ese párrafo no está en su índice. Ningún algoritmo de recuperación — denso, disperso, híbrido, re-rankeado, perfectamente afinado — puede devolver un fragmento que nunca se indexó, y a diferencia de un re-ranker malo, nada observable en tiempo de consulta siquiera insinúa la ausencia. Es una falla de calidad de recuperación que no tiene absolutamente nada que ver con el algoritmo de recuperación.

Qué puede decirle la evaluación, y qué no

“La respuesta se ve bien” es la métrica con la que todos empiezan, y funde los cinco mecanismos de arriba en un solo número. La respuesta del campo a eso es la evaluación por componentes: Es et al. (RAGAS, 2023) proponen evaluación sin referencia de un pipeline RAG a lo largo de dimensiones separadas — la capacidad del sistema de recuperación de encontrar contexto relevante y enfocado; la fidelidad del generador al usar ese contexto; y la calidad de la respuesta misma — sin requerir verdad de referencia anotada por humanos. Esa separación es la parte genuinamente útil: le dice qué etapa está sangrando.

Sea honesto con los límites, eso sí. Los puntajes sin referencia son aproximaciones calculadas por otro LLM, lo que le pone un techo a cuánto puede confiar en ellos en el margen — un modelo evaluador tiene sus propios modos de falla y nadie está evaluando al evaluador sobre su dominio. Y ninguna métrica sin referencia, por construcción, puede ver el mecanismo 5: la fidelidad a un contexto corrupto puntúa perfecto. Si al índice le falta el párrafo, cada métrica aguas abajo mide contenta qué tan bien usó usted la evidencia equivocada.

Lo que de verdad le diríamos que mida, si está construyendo o comprando uno de estos sistemas:

• Mida la recuperación por separado de la generación. Etiquete a mano un conjunto de pares (pregunta, pasaje correcto) de su propio corpus — la lección de la parte 1 sobre construir conjuntos de evaluación desde su propio material más difícil aplica sin cambios — y registre si el pasaje correcto aparece en el top-k, y en qué posición. El recall de recuperación es barato de calcular y localiza fallas que las métricas a nivel de respuesta emborronan.
• Ponga preguntas sin respuesta en el conjunto de evaluación, a propósito. Mida con qué frecuencia el sistema dice “no encontrado” cuando no-encontrado es la respuesta correcta. Un sistema que responde todo no es impresionante; le falta la única señal que usted más necesita (mecanismo 1).
• Audite el índice, no solo las respuestas. Muestree fragmentos y léalos contra las páginas de origen. Los hechos partidos por una frontera (mecanismo 3) y el texto corrompido por OCR (mecanismo 5) se ven en cinco minutos de lectura y son invisibles en cualquier puntaje de extremo a extremo.
• Registre dónde cae el fragmento correcto en el prompt ensamblado, no solo si fue recuperado. La posición 7 de 10 es una posición de mitad de contexto, y el resultado de Lost in the Middle dice que esa posición está haciendo daño real.
• Corra la prueba de borrado. Tome una pregunta que el sistema responde bien, saque el documento correcto del índice, y vuelva a preguntar. Si la respuesta sigue fluida y segura, usted acaba de medir — barato, sobre su propio sistema — exactamente cómo se va a comportar ante cada pregunta cuya respuesta nunca estuvo ahí. Una prueba que nunca vio fallar al sistema no prueba nada sobre la falla.

La arquitectura de RAG es ingeniería genuinamente buena, y la literatura detrás de cada etapa es real. Pero cada etapa está construida para devolver su mejor salida disponible, y ninguna está construida para decir “mi mejor salida disponible no alcanza”. Esa propiedad no se promedia a lo largo de seis etapas — se compone. Un sistema de recuperación no se mide por qué tan fluidas son sus respuestas. Se mide por si usted puede distinguir, desde afuera, entre una respuesta que encontró y una respuesta que armó.