¿Qué es RAG? Guía técnica

Cómo funciona

El pipeline de principio a fin

Un sistema RAG en producción son dos pipelines que se encuentran en el índice. El primero es el pipeline offline, o de ingesta: los documentos fuente se cargan, se analizan para obtener texto limpio, se dividen en fragmentos, opcionalmente se enriquecen con contexto o metadatos, se convierten en vectores mediante embeddings y se escriben en un índice junto con su texto original y sus metadatos. El segundo es el pipeline online, o de consulta: una consulta del usuario se transforma opcionalmente, se convierte en un vector con el mismo modelo utilizado en la ingesta, se usa para recuperar fragmentos candidatos, se reordena opcionalmente, se ensambla en un prompt dentro de la ventana de contexto y se pasa al generador, cuya salida se postprocesa para citas, formato y comprobaciones de seguridad.

El flujo de datos es concreto. Un documento PDF de política de 40 páginas podría analizarse en aproximadamente 12.000 palabras, dividirse en unos 60 fragmentos de 200 a 300 palabras cada uno, convertirse en 60 vectores de, digamos, 1.024 dimensiones, y almacenarse. En el momento de la consulta, la pregunta se convierte en un vector, el índice devuelve los 20 o 50 fragmentos más cercanos, un reordenador los reduce a los 5 mejores, esos 5 se concatenan en un prompt con una instrucción de responder solo a partir del texto proporcionado y de citar, y el modelo produce una respuesta con referencias. Cada flecha en ese flujo es una decisión de diseño y un punto potencial de fallo. Las subsecciones restantes los abordan uno a uno.

Procesamiento de documentos y fragmentación

La fragmentación es la palanca más infravalorada del pipeline. El recuperador solo puede devolver unidades creadas en la ingesta, de modo que si la respuesta a una pregunta está dividida entre dos fragmentos, ninguna estrategia de recuperación puede recuperarla intacta. Hay cuatro familias de estrategias de uso común. La fragmentación de tamaño fijo divide según un recuento de tokens o caracteres con superposición opcional; es simple, rápida e ignora la estructura del documento, por lo que habitualmente corta frases, tablas y cláusulas por la mitad. La fragmentación recursiva divide jerárquicamente según una lista de separadores prioritarios (párrafos, luego frases, luego palabras) hasta que los fragmentos encajan en un tamaño objetivo, lo que respeta mucho mejor los límites naturales. La fragmentación semántica coloca los límites donde la similitud de embedding entre frases adyacentes cae, agrupando el texto por significado en lugar de por longitud. La fragmentación con reconocimiento de estructura utiliza el marcado propio del documento, como encabezados Markdown, etiquetas HTML o el diseño del PDF, para dividir a lo largo de secciones, filas y elementos de lista.

La evidencia sobre cuál elegir es matizada. La fragmentación con reconocimiento de estructura tiende a ofrecer la mayor efectividad de recuperación en documentos que tienen estructura real, y con un coste computacional menor que la fragmentación semántica. La fragmentación semántica mejora la coherencia contextual, pero sus ganancias sobre las líneas base de longitud fija no siempre son suficientemente grandes para justificar su coste, y dependen en gran medida del conjunto de datos. El tamaño del fragmento y la superposición son los dos parámetros que más se ajustarán. Los fragmentos más pequeños aumentan la precisión (cada unidad está muy centrada en el tema), pero corren el riesgo de fragmentar las respuestas y perder contexto; los fragmentos más grandes preservan el contexto, pero diluyen el embedding con texto fuera del tema y desperdician el presupuesto de la ventana de contexto. La superposición, típicamente del 10 al 20 por ciento del tamaño del fragmento, reduce las pérdidas por corte en los límites al precio de la duplicación en el índice.

Las tablas, los PDF y los encabezados merecen un tratamiento específico. La extracción de texto simple de un PDF linealiza las columnas y destruye las tablas, de modo que una figura acaba junto a la etiqueta incorrecta. Los analizadores con reconocimiento de diseño, las pasadas de extracción de tablas y la conversión de tablas a formato Markdown o en forma de frases antes de la fragmentación ayudan de forma significativa. Los encabezados deben conservarse e idealmente anteponerse a cada fragmento hijo como metadatos, de modo que un fragmento extraído de lo profundo de un documento sepa a qué sección pertenece. Los metadatos capturados en la ingesta (fuente, autor, fecha, sección, tipo de documento, nivel de acceso) no son decoración: impulsan el filtrado, el control de actualidad y la recuperación con reconocimiento de permisos más adelante en el pipeline. Trate la fragmentación como un problema de investigación central con su propia evaluación, no como un paso de preprocesamiento secundario.

Embeddings en la práctica

El concepto de embeddings se trata en /what-is/embeddings; aquí la preocupación es la selección y las operaciones. Un modelo de embedding mapea texto a un vector denso de modo que el texto semánticamente similar queda cerca en el espacio vectorial. La regla operativa más importante es que el mismo modelo debe convertir en vectores tanto los fragmentos indexados como la consulta entrante. El espacio vectorial es específico del modelo; un vector de consulta de un modelo y un vector de fragmento de otro no son comparables, y las puntuaciones de similitud entre ellos carecen de sentido. Esto parece obvio y se viola constantemente, generalmente tras una actualización de modelo bien intencionada.

La elección del modelo debe basarse en evidencia más que en reputación. Ningún método de embedding domina en todas las tareas, por lo que un modelo que encabeza una clasificación de similitud semántica puede no ser el mejor para su carga de trabajo de recuperación. El Massive Text Embedding Benchmark (MTEB) existe precisamente porque el rendimiento no se transfiere limpiamente entre tareas; úselo para preseleccionar y luego evalúe los candidatos con sus propios datos. La dimensionalidad es un intercambio directo: los vectores de mayor dimensión pueden capturar más matices, pero cuestan más memoria y cómputo por comparación, y la ganancia a menudo se estabiliza. El ajuste al dominio importa más que el número bruto de dimensiones: un modelo entrenado en texto web general puede tener un rendimiento inferior al de un modelo más pequeño ajustado al dominio en corpus legales, clínicos o de código.

La realidad operativa que sorprende a los equipos es la reindexación de embeddings. Cambiar el modelo de embedding no es un cambio de configuración; invalida todos los vectores del índice. Es necesario volver a convertir en vectores todo el corpus, lo que para bases de conocimiento grandes supone un coste computacional sustancial y un problema de disponibilidad si se hace en el lugar. Planifique los cambios de modelo de embedding como migraciones: construya el nuevo índice junto al antiguo, valide la calidad de recuperación en su conjunto de evaluación y luego realice el cambio. Trate el modelo de embedding como una dependencia de larga duración, porque cambiarlo es costoso y disruptivo.

Indexación y búsqueda vectorial

El concepto de base de datos vectorial se trata en /what-is/vector-database. La pregunta de ingeniería es cómo escala la búsqueda del vecino más cercano. La búsqueda exacta del vecino más cercano sobre millones de vectores de alta dimensión es demasiado lenta para uso interactivo, por lo que los sistemas en producción utilizan métodos de vecino más cercano aproximado (ANN) que intercambian una pequeña pérdida controlable de recuperación por grandes ganancias en velocidad y memoria. Tres familias dominan. Hierarchical Navigable Small World (HNSW) construye un grafo de proximidad multicapa y navega desde una capa superior gruesa hasta capas finas, logrando una búsqueda de escala logarítmica con alta recuperación; es el predeterminado en la mayoría de los almacenes vectoriales modernos y consume mucha memoria pero es rápido. Los índices de archivo invertido (IVF) particionan el espacio en clústeres y buscan solo los clústeres más cercanos a la consulta, intercambiando recuperación por el número de clústeres explorados. La cuantización de producto (PQ) comprime los vectores en códigos cortos dividiendo cada vector en subvectores y cuantizando cada uno por separado, lo que reduce drásticamente la memoria a costa de cierta precisión; IVF y PQ se combinan frecuentemente (IVF-PQ) para corpus a escala de miles de millones.

El equilibrio fundamental es recuperación frente a latencia y memoria. HNSW expone parámetros (el grado del grafo M y la amplitud de búsqueda efSearch) que permiten aumentar la recuperación al coste del tiempo de consulta y el tiempo de construcción. No existe una configuración universalmente correcta; depende del tamaño del corpus, la dimensionalidad y el presupuesto de latencia, y debe ajustarse frente a la recuperación medida en las propias consultas. Dónde reside el índice es una decisión separada. Se puede ejecutar un almacén vectorial dedicado, o usar las funciones vectoriales cada vez más integradas en bases de datos y motores de búsqueda existentes (PostgreSQL con pgvector, OpenSearch y Elasticsearch, entre otros). Para muchos equipos, el primer paso correcto es añadir búsqueda vectorial a una base de datos que ya operan, en lugar de introducir un nuevo sistema, y luego pasar a un almacén dedicado solo cuando la escala o las necesidades de funcionalidades lo exijan.

Estrategias de recuperación

Hay dos formas fundamentalmente diferentes de encontrar texto relevante, y los sistemas más potentes utilizan ambas. La recuperación densa convierte la consulta y los documentos en el mismo espacio vectorial y encuentra los vecinos más cercanos; captura el significado y maneja bien la paráfrasis y la sinonimia, lo que supone su gran ventaja sobre la búsqueda por palabras clave. La recuperación densa de pasajes demostró que un codificador dual aprendido puede superar sustancialmente a una línea base léxica sólida en respuesta a preguntas de dominio abierto: el recuperador denso superó a un sistema Lucene-BM25 sólido en un 9 a 19 por ciento absoluto en precisión de recuperación de pasajes en el top 20, estableciendo la recuperación densa como el método semántico predeterminado. La recuperación dispersa, clásicamente BM25, puntúa los documentos según la coincidencia exacta de términos ponderados; es imbatible para tokens raros, códigos, números de producto, nombres y acrónimos que un embedding puede difuminar, y no necesita entrenamiento.

La recuperación híbrida ejecuta ambas y fusiona los resultados, porque sus modos de fallo son complementarios: la recuperación densa encuentra el fragmento conceptualmente relevante que no comparte palabras clave, la recuperación dispersa encuentra el identificador exacto que el embedding pasó por alto. El método de fusión estándar es Reciprocal Rank Fusion (RRF), que puntúa cada documento sumando los recíprocos de su posición en cada lista de resultados, con una constante k que controla la rapidez con que la influencia decae con la posición. Se demostró que RRF produce sistemáticamente mejores resultados que cualquier sistema individual y mejores resultados que el método estándar Condorcet Fuse; el valor k = 60 utilizado en el estudio original sigue siendo el predeterminado en OpenSearch, Elasticsearch, Azure AI Search y Weaviate. RRF es popular porque opera sobre posiciones, no sobre puntuaciones brutas, por lo que evita el problema de que las puntuaciones BM25 y las similitudes coseno viven en escalas incomparables, y no necesita ajuste para funcionar bien.

Más allá de los recuperadores principales, varias técnicas mejoran la recuperación y la precisión. El filtrado por metadatos restringe la búsqueda a fragmentos que coinciden con predicados estructurados (rangos de fechas, tipo de documento, nivel de acceso) y es esencial tanto para la relevancia como para los permisos. La transformación de consultas reescribe la consulta bruta del usuario en una forma que recupera mejor: la expansión añade sinónimos o términos relacionados; la consulta múltiple genera varias paráfrasis y une sus resultados para cubrir más del espacio relevante. Hypothetical Document Embeddings (HyDE) es una transformación notable que pide a un modelo que redacte una respuesta hipotética y luego convierte ese borrador en un vector para recuperar documentos reales cercanos a él, lo que puede superar a un recuperador denso no supervisado sólido en configuraciones de zero-shot. El parámetro top-k (cuántos candidatos devuelve la recuperación) es el dial de recuperación-coste: un k mayor aumenta la probabilidad de que la respuesta esté en algún lugar del conjunto, pero añade ruido y coste posterior, que es exactamente lo que la reordenación existe para resolver.

Reordenación

La recuperación y la reordenación utilizan arquitecturas de modelo diferentes por una razón. Un bi-encoder (el codificador dual utilizado para la recuperación densa) convierte la consulta y el documento en vectores por separado, lo que es lo que hace posible la indexación: se convierte cada fragmento en vector una vez, con antelación, y solo la consulta en tiempo de ejecución. El precio de esa eficiencia es que la consulta y el documento nunca interactúan hasta el producto escalar final, por lo que se pierden señales de relevancia sutiles. Un cross-encoder procesa la consulta y un documento candidato juntos a través del modelo, permitiendo que cada token de la consulta atienda a cada token del documento, lo que produce una puntuación de relevancia mucho más precisa. Un cross-encoder BERT-Large ajustado alcanzó un MRR@10 de 35,8 en el conjunto de evaluación de clasificación de pasajes MS MARCO como la entrada más alta de la clasificación, superando el estado del arte anterior en un 27 por ciento relativo en MRR@10, y aproximadamente duplicando el MRR@10 de BM25.

El inconveniente es el coste. Un cross-encoder debe ejecutarse una vez por documento candidato en el momento de la consulta, por lo que no se puede ejecutar sobre un corpus completo. Por eso el diseño establecido es de dos etapas, recuperar y luego reordenar: un bi-encoder barato o un recuperador híbrido obtiene un conjunto de candidatos (digamos los 50 a 100 primeros), y luego un cross-encoder costoso reordena ese conjunto y se conservan los mejores. Las evaluaciones zero-shot en diversas tareas de recuperación confirman el patrón: los modelos basados en reordenación logran la mayor precisión pero con un alto coste computacional, mientras que los recuperadores densos son más baratos pero a menudo menos precisos. La reordenación justifica su latencia cuando la recuperación de primera etapa devuelve los fragmentos correctos pero en el orden incorrecto, o cuando se necesita alta precisión en un contexto final pequeño. Si el recuperador ya devuelve la respuesta en la primera posición, un reordenador añade latencia con poca ganancia, por lo que conviene medir antes de añadirlo.

Ensamblaje del contexto y generación

Una vez que se tienen los fragmentos finales, hay que encajarlos en la ventana de contexto, el presupuesto fijo de tokens al que el modelo puede atender, tratado en /what-is/context-window. Concatenar ingenuamente todo lo recuperado es un error por dos razones. En primer lugar, desperdicia presupuesto y dinero en pasajes marginales. En segundo lugar, y menos obvio, el lugar donde se coloca un pasaje importa: los modelos de lenguaje utilizan la información al principio y al final de un contexto largo de forma mucho más fiable que la información enterrada en el medio, una degradación que se mantiene incluso en modelos comercializados como de contexto largo. La consecuencia práctica es colocar los pasajes recuperados más importantes al principio y al final, mantener el conjunto recuperado ajustado y no asumir que una ventana más grande significa que se puede volcar más contenido.

La construcción del prompt para respuestas fundamentadas es su propia pequeña disciplina. El prompt del sistema debe instruir al modelo para que responda solo a partir de los pasajes proporcionados, para que cite de qué pasaje proviene cada afirmación (hay que pasar identificadores de fragmento estables junto al texto para que pueda hacerlo) y, crucialmente, para que se abstenga, para que diga que no sabe, cuando los pasajes no contienen la respuesta. Esa última instrucción es lo que convierte una fabricación segura en un honesto "no encontrado", y es la línea de mayor valor en la mayoría de los prompts RAG. RAG reduce pero no elimina la alucinación, como señala el artículo no técnico; las instrucciones explícitas de abstención, los requisitos de cita y mantener el contexto enfocado son las palancas que reducen la tasa residual.

Patrones avanzados y actuales

Varios patrones amplían el pipeline básico, y vale la pena ser claros sobre qué está establecido frente a qué está emergiendo. El enrutamiento de consultas, que envía una consulta a uno de varios índices, herramientas o prompts según su tipo, está establecido y tiene bajo riesgo. La recuperación de documento padre, o de pequeño a grande, está establecida y es ampliamente utilizada: se convierte en vectores y se recupera en fragmentos hijo pequeños y precisos para mayor exactitud, y luego se alimenta al modelo con el fragmento padre más grande o la sección completa para el contexto, obteniendo lo mejor de ambas granularidades. La recuperación multi-salto, o iterativa, donde el sistema recupera, razona y luego recupera de nuevo usando lo que aprendió, es necesaria para preguntas cuya respuesta requiere encadenar hechos a través de documentos, y está pasando de la investigación a la práctica habitual.

La recuperación contextual, que antepone un breve resumen generado por el modelo que sitúa cada fragmento dentro de su documento fuente antes de la conversión en vectores y la indexación, es una técnica reciente y bien respaldada por evidencia. Añadir embeddings contextuales solos redujo la tasa de fallo de recuperación de los 20 fragmentos principales en un 35 por ciento (del 5,7 por ciento al 3,7 por ciento); combinar embeddings contextuales con BM25 contextual la redujo en un 49 por ciento (al 2,9 por ciento); y reordenar los resultados híbridos contextualizados la redujo en un 67 por ciento (al 1,9 por ciento). GraphRAG, que utiliza un modelo de lenguaje para construir un grafo de conocimiento de entidades y relaciones a partir del corpus y pregeneera resúmenes de comunidades, apunta a una debilidad específica: las preguntas globales de "comprensión del conjunto" sobre un corpus completo ("¿cuáles son los temas principales?") que la recuperación vectorial maneja mal porque ningún fragmento individual contiene la respuesta. Es potente pero costoso de construir y mantener, por lo que se justifica por el tipo de pregunta, no se adopta por defecto. El RAG agéntico, donde un agente impulsado por un modelo decide cuándo recuperar, qué recuperar y si recuperar de nuevo, y puede criticar su propio borrador, es la vanguardia; los enfoques autorreflexivos que entrenan a un modelo para recuperar bajo demanda y calificar su propia salida han mostrado ganancias significativas en factualidad y precisión de citas para la generación de formato largo, por ejemplo obteniendo un 81 por ciento en la tarea de verificación de hechos PubHealth y un 80 por ciento de factualidad en la generación de biografías frente al 71 por ciento de ChatGPT. Trate el RAG agéntico como prometedor y en rápida evolución más que como consolidado, e instrumételo ampliamente, porque cada punto de decisión añadido es otro modo de fallo.

Evaluación

La evaluación es la disciplina que separa un sistema que funciona de una demo convincente. No se puede evaluar la calidad de RAG a ojo; un sistema que responde bien diez preguntas seleccionadas puede fallar en la undécima de formas que solo se detectan con medición. La base es un conjunto dorado, o de evaluación: una colección curada de preguntas representativas emparejadas con respuestas conocidas como buenas y los pasajes que las respaldan, construida a partir de consultas reales de usuarios cuando sea posible. Sin él se está ajustando a ciegas.

La medición se divide claramente en dos capas. Las métricas de recuperación preguntan si se encontraron y clasificaron bien los fragmentos correctos: recall@k (¿apareció el fragmento relevante entre los k primeros?), precisión (¿cuántos de los fragmentos devueltos eran relevantes?), Mean Reciprocal Rank (qué tan alto clasificó el primer fragmento relevante) y Discounted Cumulative Gain normalizado (nDCG, que recompensa colocar los fragmentos más relevantes en las posiciones más altas). Estas permiten ajustar la fragmentación, los embeddings, el top-k y la reordenación de forma aislada, antes de que la generación enturbie el panorama. Las métricas de extremo a extremo y de generación preguntan si la respuesta final es buena: fidelidad o fundamentación (¿está cada afirmación respaldada por el contexto recuperado, la medida directa de alucinación?), relevancia de la respuesta (¿aborda la respuesta la pregunta?) y precisión y recuperación del contexto (¿estaba el contexto recuperado enfocado y completo?). Marcos reconocidos como RAGAS proporcionan métricas sin referencia para fidelidad, relevancia de la respuesta y relevancia del contexto, y benchmarks como BEIR (recuperación zero-shot) y MTEB (embeddings) ayudan a elegir componentes. Instrumente ambas capas, porque un fallo de extremo a extremo indica que algo falló pero no dónde; las métricas de recuperación indican si hay que buscar antes o después en el pipeline.

Modos de fallo y decisiones de arquitectura

El valor de una evaluación de dos capas es que localiza el fallo. Cuando una respuesta RAG es incorrecta, hay que aislar la etapa. Un fallo de recuperación significa que el fragmento relevante nunca estuvo en el conjunto de candidatos: compruebe la fragmentación, el modelo de embedding y si necesita recuperación híbrida o un k mayor. Un fallo de reordenación significa que el fragmento fue recuperado pero el reordenador lo expulsó del conjunto final: compruebe el reordenador y el corte final-k. Un fallo de generación significa que el fragmento correcto estaba en el prompt pero el modelo lo ignoró, lo contradijo o alucinó alrededor de él: compruebe el prompt, la instrucción de abstención y el orden del contexto. Un fallo de fuente ausente significa que la respuesta simplemente no está en el corpus, en cuyo caso el comportamiento correcto es la abstención, no la invención. Diagnosticar esto requiere registrar los artefactos intermedios (IDs de fragmentos recuperados, puntuaciones del reordenador, prompt final) para cada consulta, algo que la mayoría de los equipos añade solo después de su primer incidente en producción.

Este marco también aclara las decisiones de arquitectura más amplias, incluida la relación de RAG con el ajuste fino y los enfoques de contexto largo. La diferencia conceptual (comportamiento frente a información) está en la página no técnica; el intercambio de ingeniería es este. El ajuste fino cambia lo que el modelo es y cómo se comporta, cuesta cómputo de entrenamiento y fija el conocimiento en un momento del tiempo, por lo que es adecuado para el estilo, el formato y el comportamiento en dominios estrechos, pero no para hechos que cambian rápidamente. El prompting de contexto largo, que coloca documentos completos en la ventana, evita una capa de recuperación pero paga por token en cada llamada, escala mal en coste y latencia a medida que los documentos crecen, y se enfrenta a la degradación de perderse en el medio; una ventana más grande no es una arquitectura de memoria y no elimina la necesidad de decidir qué mostrar al modelo. RAG mantiene el conocimiento externo, actualizado y auditable, al coste de la complejidad del pipeline. Estos son complementos, no rivales: un sistema maduro puede ajustar finamente el tono, usar RAG para los hechos y reservar el contexto largo para el razonamiento sobre documentos completos en un único archivo recuperado. La decisión de construir frente a comprar sigue la misma lógica: los servicios gestionados de recuperación y RAG eliminan el trabajo pesado indiferenciado y son un punto de partida sensato para un primer sistema, mientras que el caso para construir crece con la escala, los requisitos de latencia, las restricciones de residencia de datos y la necesidad de controlar cada etapa. Presupueste la latencia y el coste en todo el pipeline (embedding, recuperación, reordenación, generación y cualquier pasada adicional de recuperación o resumen) en lugar de optimizar una sola etapa, porque la etapa más lenta o más costosa establece el límite.