Explicación de un pipeline básico RAG: desde documentos en bruto hasta respuestas fundamentadas.
Cómo funciona un pipeline básico de generación mejorada por recuperación de información: limpieza, fragmentación, embeddings, búsqueda vectorial, formulación de preguntas, evaluación y los puntos habituales de fallo.
Fuentes: Building a Basic RAG Pipeline: A Practical Guide to Retrieval-Augmented Generation
Los modelos de lenguaje tienen un hábito problemático: suenan seguros de sí mismos incluso cuando no cuentan con la información necesaria. Pregúntales sobre una política interna de la empresa, el manual de un producto lanzado el mes pasado, un documento legal poco conocido o un ticket de soporte de ayer, y es posible que simplemente no lo sepan. Peor aún, pueden generar algo que suene creíble para tapar esa laguna.
La generación reforzada por recuperación de información, abreviada habitualmente como RAG, es la solución estándar. Un proceso RAG permite que el modelo consulte conocimientos externos en el momento en que los necesita. No todo tiene que estar almacenado en la memoria del modelo, ya que el sistema busca en una base de conocimientos fiable, extrae los pasajes más relevantes y elabora una respuesta basada en ellos. En pocas palabras, un asistente que funciona como si tuviera información limitada se convierte en uno que puede acceder a información amplia.
Este enfoque llamó la atención gracias a un artículo de investigación de 2020 sobre generación mejorada mediante recuperación de información para tareas de procesamiento del lenguaje natural intensivas en conocimiento, el cual combinó un modelo generativo con un sistema de recuperación que buscaba en una colección de documentos externos. La observación central fue que el conocimiento incorporado en el modelo y la información externa pueden complementarse mutuamente: el modelo aporta la capacidad lingüística, mientras que el sistema de recuperación proporciona detalles actuales y específicos.
Un pipeline básico se ejecuta en dos fases. El indexado prepara los documentos para la búsqueda. La respuesta toma la pregunta del usuario, obtiene el material relevante y se lo entrega al modelo como contexto. Parece sencillo, pero cada etapa oculta decisiones que determinan el resultado. Un sistema débil rara vez falla debido a que el propio modelo es deficiente; con mucha más frecuencia recupera los documentos incorrectos, los fragmentos son desordenados, la instrucción es vaga o el sistema no puede admitir que no tiene la respuesta.
Las secciones siguientes desarrollan esta idea desde cero.
Qué hace RAG en la práctica
El ciclo básico consta de cuatro pasos: el usuario hace una pregunta, el sistema busca en la base de conocimientos, los fragmentos que mejor se ajustan se incluyen en la instrucción del modelo y el modelo responde utilizando ese contexto recuperado.
Imagínese a un cliente que quiere saber si una computadora portátil reacondicionada aún puede ser devuelta después de 20 días. Un chatbot simple podría hacer conjeturas basadas en hábitos comerciales generales. Un chatbot RAG puede buscar la política real de devoluciones, encontrar la sección sobre productos reacondicionados y responder a partir de ella. Si la política establece un plazo de 14 días para las computadoras portátiles reacondicionadas, el bot puede confirmarlo. Si la política no menciona nada sobre las computadoras portátiles reacondicionadas, el bot no debe inventar una regla.
Ese es el principio fundamental: primero la recuperación de información, luego su generación. La recuperación reduce el abanico de opciones a unas pocas pruebas útiles, y la generación las convierte en una respuesta útil. Cuando se hace bien, RAG mejora la precisión factual, facilita la verificación de las respuestas y permite actualizar lo que sabe el sistema sin tener que volver a entrenar un modelo.
Elegir la fuente de conocimiento
Cada pipeline comienza con un conjunto de material del cual se debe obtener la información. Los candidatos típicos son la documentación corporativa, los manuales de productos, los artículos del centro de ayuda, los archivos PDF, los contratos, los artículos de investigación, las notas de reuniones, los registros de la base de datos, la documentación del código y los tickets de soporte.
La fuente más grande no siempre es la mejor. Un conjunto de documentos bien organizado, actualizado y enfocado suele ser mejor que un montón grande de archivos obsoletos. RAG no puede corregir material de origen deficiente, por lo que los documentos desactualizados, poco claros o contradictorios generan respuestas igualmente obsoletas, poco claras o contradictorias.
Antes de indexar cualquier cosa, es útil hacerse algunas preguntas prácticas:
- ¿Es la información precisa y actualizada?
- ¿Quién es el responsable de ella?
- ¿Tiene acceso a ella todo el usuario?
- ¿Existen versiones duplicadas o contradictorias?
- ¿Las tablas, imágenes, notas al pie o cláusulas legales requieren un tratamiento especial?
Una base de conocimientos pequeña y bien mantenida es un buen punto de partida. Para el primer proyecto, elija un caso de uso claro, como preguntas sobre un manual de empleados o una sección de Preguntas Frecuentes de un producto, y amplíela una vez que funcione.
Limpieza y preparación de documentos
Los archivos en bruto rara vez están listos para su consulta. Los PDF pueden tener saltos de línea dañados. Las páginas web incluyen menús, banners de cookies, anuncios y pies de página que se repiten en cada página. Los documentos internos pueden tener encabezados con poco contexto, y las hojas de cálculo pueden ocultar detalles importantes en columnas que resultan difíciles de leer como texto plano.
La limpieza convierte ese desorden en texto buscable. Puede implicar eliminar texto genérico, conservar los títulos, extraer tablas, convertir todo a un formato consistente y añadir metadatos. Los metadatos son especialmente útiles, ya que un fragmento gana mucho valor al contener campos como el título del documento, el autor, la fecha, el departamento responsable, la versión del producto, un enlace, el nivel de acceso o el título de la sección.
Compare un fragmento simple como “Las devoluciones deben solicitarse dentro de 14 días” con uno que está etiquetado: el título es la política de devoluciones de laptops reacondicionadas, la sección corresponde al plazo de devolución, fue actualizado por última vez en marzo de 2026, y el texto indica que la devolución de una laptop reacondicionada debe solicitarse dentro de 14 días desde su recepción. Esa segunda forma proporciona más información tanto al sistema de búsqueda como al modelo, y facilita las citaciones y el filtrado posteriormente.
Dividir documentos en fragmentos
Los modelos de lenguaje y los sistemas de recuperación generalmente no manejan libros completos, manuales o bibliotecas de políticas como un todo. Funcionan mejor con pasajes más pequeños llamados fragmentos.
La división en fragmentos es una de las partes más importantes del proceso, ya que la recuperación se realiza a nivel de fragmentos. Si los fragmentos son demasiado grandes, la respuesta puede quedar oculta entre texto irrelevante. Si son demasiado pequeños, el sistema podría recuperar fragmentos sin suficiente contexto para responder adecuadamente. Un buen fragmento es lo suficientemente grande como para contener una idea completa y lo suficientemente pequeño como para mantener la concentración.
En los sistemas con mucho texto, los desarrolladores suelen comenzar con fragmentos de unas pocascientas palabras y ajustarlos según los resultados. Algunos utilizan fragmentos superpuestos para que el contexto no se pierda en los límites, por ejemplo donde un encabezado cierra un fragmento y el texto de la política que introduce abre el siguiente.
La división en fragmentos debe seguir, siempre que sea posible, la estructura del documento. Separar el texto por secciones, encabezados, párrafos o pares de preguntas y respuestas suele ser mejor que hacerlo según un número fijo de caracteres, y diferentes tipos de documentos, como políticas de reembolso, guías de solución de problemas y artículos científicos, pueden requerir un enfoque propio.
Aquí es donde muchos sistemas básicos tienen éxito o fracasan silenciosamente. El modelo solo puede responder a partir de lo que recibe, por lo que un fragmento sin contexto puede dificultar incluso el funcionamiento de un modelo potente.
Creación de embeddings
Después de limpiar y dividir el texto en fragmentos, cada uno se convierte en un embedding, una representación numérica del significado. Técnicamente se trata de un vector, una lista de números que capturan información semántica sobre el texto. Los textos con significados similares tienden a encontrarse cerca entre sí en el espacio vectorial, lo que permite a un sistema buscar por significado y no solo por palabras clave exactas.
Supongamos ahora que la pregunta es cuánto tiempo se tiene para devolver una computadora reacondicionada, mientras que el documento indica que las laptops reacondicionadas pueden ser devueltas si se solicita dentro de 14 días después de la entrega. Una búsqueda tradicional por palabras clave podría pasar por alto la relación entre “devolver” y “devoluciones”, o entre “computadora” y “laptop”. La búsqueda basada en incrustación tiene más probabilidades de detectar esa relación.
Ese tipo de coincidencia semántica explica por qué la recuperación densa se volvió importante en la respuesta a preguntas de dominio abierto. El trabajo sobre recuperación de pasajes densos del año 2020 demostró que las representaciones densas aprendidas podían superar a un sólido modelo de referencia BM25 en varios benchmarks de recuperación para la respuesta a preguntas de dominio abierto.
En una tubería básica, se incrusta cada fragmento en la base de conocimientos. Cuando un usuario hace una pregunta, también se incrusta esta, se compara con las incrustaciones de los fragmentos almacenados y se obtienen las coincidencias más cercanas.
Almacenamiento de incrustaciones en una base de datos vectorial
Las incrustaciones necesitan un lugar que permita realizar búsquedas, y ese es el papel de una base de datos vectorial o almacén vectorial. Este tipo de base de datos guarda la incrustación de cada fragmento, su texto original y cualquier metadato útil. Al momento de formular una pregunta, encuentra los fragmentos cuyas incrustaciones están más cerca de las de la pregunta.
Para un prototipo, basta con un almacén local o en memoria. En entornos de producción, podría ser necesario utilizar una base de datos vectorial gestionada, un motor de búsqueda que soporte vectores o una extensión de base de datos que añada funcionalidades de búsqueda vectorial. La elección debe basarse en factores como la escalabilidad, la velocidad, el costo, las necesidades de filtrado, la seguridad y la frecuencia con que cambian los documentos.
Considérelo como parte del motor de recuperación y no simplemente como una caja de almacenamiento. Un buen filtrado de metadatos puede marcar una gran diferencia. Una pregunta sobre la política de reembolsos europea no debería hacer que se obtenga una política de otra región. Si un usuario solo puede ver los documentos de recursos humanos de su propio departamento, el sistema de recuperación debe asegurarse de ello antes de que nada llegue al modelo.
Eso es importante porque RAG puede filtrar información cuando el control de acceso es laxo. No se debe confiar en que el modelo oculte contenido restringido después de la recuperación, y es más seguro evitar que el material restringido sea recuperado en absoluto.
Recuperación de los fragmentos relevantes
La respuesta comienza cuando un usuario hace una pregunta. El sistema incrusta la pregunta, busca en el almacén vectorial y devuelve los fragmentos que mejor se ajustan. Los especialistas denominan esto recuperación top-k, donde k indica cuántos fragmentos se devuelven; top-5 significa los cinco más cercanos.
Elegir el valor de k es un equilibrio delicado. Si se obtiene poca información, la respuesta podría omitir detalles importantes. Si se obtiene demasiada, la consulta se vuelve ruidosa, costosa o confusa. Más contexto no siempre es mejor, pero un mejor contexto sí lo es.
Muchos sistemas básicos comienzan con búsquedas de similitud vectorial, que manejan bien las preguntas relacionadas con el significado, pero no son perfectas. Algunas consultas dependen de palabras exactas, códigos de identificación, nombres, fechas, códigos de error o frases legales, y en esos casos la búsqueda por palabras clave puede superar a la búsqueda vectorial por sí sola.
Por esa razón, la búsqueda híbrida es muy popular. Combina la búsqueda vectorial con la búsqueda por palabras clave de texto completo y fusiona los resultados. Por ejemplo, Azure AI Search describe la búsqueda híbrida como una única consulta que ejecuta ambos tipos de búsquedas al mismo tiempo y fusiona los resultados clasificados mediante la técnica de Fusión de Rangos Recíprocos. En términos sencillos, el sistema cuenta con dos vías para encontrar la respuesta: por el significado y por la redacción exacta.
La búsqueda vectorial es un primer paso sensato. Si el público escribe con frecuencia códigos de producto, títulos de políticas, textos legales o mensajes de error, planifique incorporar el enfoque híbrido.
Creación del prompt
Una vez recuperados los fragmentos, estos se incluyen en el prompt del modelo, el cual debe indicar claramente el contexto, la pregunta del usuario y qué se espera que haga el modelo. Un prompt RAG sencillo puede indicarle al modelo que responda utilizando el contexto proporcionado, que se base únicamente en la información allí contenida, que indique que no sabe responder cuando el contexto carezca de la respuesta, y que cite el título o sección de origen siempre que sea posible. A continuación vienen los fragmentos recuperados y la pregunta.
Estas instrucciones son importantes porque el modelo posee conocimientos generales propios. Sin una guía clara, podría mezclar hechos obtenidos con sus propias suposiciones. Eso a veces es aceptable, pero para un bot de soporte, asistente legal, herramienta médica o ayudante en la elaboración de políticas, el modelo debe ceñirse a las pruebas que se le han proporcionado.
La documentación de ingeniería de prompts de OpenAI describe a RAG como la adición de contexto relevante, extraído de una base de datos vectorial o de búsquedas en archivos, a la solicitud de generación. La forma en que se redacta el prompt es crucial: determina si el texto obtenido se presenta como la fuente en la que debe basarse el modelo.
Un prompt bien redactado también aborda la incertidumbre, permitiendo que el modelo indique que los documentos proporcionados no responden a la pregunta. Esa respuesta es menos arriesgada que una suposición segura y mucho más útil.
Generación de la respuesta
Ahora el modelo de lenguaje escribe la respuesta final, la parte que realmente ven los usuarios. Debe ser clara, fundamentada y lo suficientemente específica. No debe presentar texto bruto recuperado a menos que se le pida. Debe explicar en lenguaje natural, mencionar los límites importantes y citar fuentes cuando sea posible.
Un buen ejemplo: “Los portátiles reacondicionados deben devolverse dentro de los 14 días posteriores a la entrega. La política no menciona excepciones para devoluciones de 20 días, por lo que, según dicha política, una devolución solicitada después de 20 días no sería aceptable”. Esto funciona porque establece la regla, la aplica a la situación del usuario y no finge que existe una excepción cuando la fuente no la indica.
Las citaciones también aportan valor, ya que permiten a los usuarios verificar una respuesta en lugar de confiar únicamente en el modelo. Hacer que las respuestas de la IA sean rastreables es uno de los mayores beneficios prácticos del RAG.
Evaluación del proceso
Un sistema RAG debe probarse antes de que alguien confíe en él. Un error común es examinar solo la respuesta final. Es mejor evaluar la recuperación de información y la generación por separado: primero averiguar si el sistema de recuperación encontró los fragmentos adecuados, y luego si el modelo los utilizó correctamente.
Un conjunto de evaluación sencillo combina preguntas reales de usuarios con los pasajes de origen correctos y las respuestas esperadas. Para cada pregunta, se debe verificar que el documento adecuado aparezca entre los resultados recuperados. Cuando el pasaje correcto nunca llega al modelo, es poco probable que se obtengan respuestas fiables.
Luego, se debe revisar la respuesta generada. ¿Se mantiene fiel al contexto? ¿Ha añadido afirmaciones que nadie respalda? ¿Aborda la pregunta real y cita la fuente correcta? Cuando los documentos no son suficientes, ¿lo admite?
El libro de recetas de Claude RAG recomienda evaluar por separado el pipeline de recuperación y el sistema de extremo a extremo, en lugar de basarse en impresiones vagas sobre la calidad de la respuesta, un consejo que vale la pena seguir incluso en proyectos pequeños.
Un ciclo de evaluación básico puede hacer seguimiento de:
- Exactitud de la recuperación, es decir, si se encontró el pasaje correcto.
- Fidelidad, es decir, si la respuesta está respaldada por el contexto recuperado.
- Completitud, es decir, si están presentes los detalles importantes.
- Calidad de las citaciones, es decir, si las fuentes citadas son realmente relevantes.
- Latencia, el tiempo que tarda una respuesta.
- Costo, los tokens y las llamadas de recuperación utilizados.
- Satisfacción del usuario, es decir, si el problema se resolvió.
RAG rara vez es perfecto desde la primera vez. La evaluación muestra dónde se pueden mejorar aspectos como el particionamiento, los metadatos, la recuperación de información, las instrucciones dadas, el reordenamiento o los propios documentos de origen.
Dónde fallan los pipelines básicos
La primera versión de un pipeline suele funcionar lo suficientemente bien como para resultar emocionante, pero también lo suficientemente mal como para ser humillante. Problemas típicos:
- Particionamiento deficiente. Se obtiene un fragmento relevante, pero la respuesta completa no está en él.
- Ruido en la recuperación de información. Se devuelven fragmentos que parecen relacionados pero que no responden a la pregunta, especialmente cuando la consulta es amplia, ambigua o contiene términos presentes en muchos documentos.
- Información desactualizada. Actualizar es más sencillo que volver a entrenar el modelo, pero solo si la base de conocimientos se mantiene actualizada. Los documentos antiguos que permanecen en el índice aún pueden ser recuperados.
Una arquitectura sencilla
Diseñado para principiantes, el proceso se desarrolla en dos fases. En la fase de indexación, los documentos se recopilan, se limpian, se dividen en fragmentos, se incrustan y se almacenan en un repositorio vectorial junto con el texto original y los metadatos. En la fase de respuesta, se incrusta la pregunta del usuario, se recuperan los fragmentos más relevantes y, opcionalmente, se filtran o se reordenan, para luego incluirlos en una instrucción que el modelo de lenguaje utiliza como contexto para responder.
En resumen: los documentos se convierten en fragmentos, luego en incrustaciones y finalmente en un repositorio vectorial; una pregunta se convierte en una incrustación de consulta, pasa por el sistema de recuperación para generar contexto, y el modelo de lenguaje lo transforma en una respuesta.
Frameworks como LangChain y LlamaIndex ofrecen herramientas para cargar documentos, crear índices y recuperadores, así como para conectar esos recuperadores con modelos de lenguaje. La documentación de LangChain presenta la recuperación de información como el uso de bases de conocimiento propias a través de cargadores y almacenes vectoriales. LlamaIndex entiende el RAG como un proceso de indexación previa de los datos, de modo que cada consulta pueda obtener el contexto relevante antes de realizar la llamada al modelo de lenguaje grande.
No se necesita un sistema complejo para aprender esto. Un pequeño prototipo solo requiere cinco componentes: algunos documentos en una carpeta, un modelo de embedding, un lugar donde almacenar los vectores, un recuperador y un modelo de chat. Lo importante es comprender cada paso y no tratar el proceso como una caja negra.
Qué distingue a un buen pipeline
Un buen pipeline hace más que recuperar texto. Encuentra el texto correcto, lo presenta al modelo en una forma utilizable y genera una respuesta fiel a las pruebas disponibles. Los mejores sistemas comparten algunas características: fuentes limpias y actualizadas, particionamiento cuidadoso del contenido, metadatos bien mantenidos, recuperación tanto por significado como por precisión cuando es necesario, instrucciones claras, citas, evaluación separada de la recuperación y la generación, protección de datos sensibles antes de que lleguen al modelo, y la capacidad de admitir la ignorancia.
Por lo tanto, un buen RAG es algo más que una función de inteligencia artificial. Combina gestión del conocimiento, búsqueda, diseño de productos y seguridad.
Siguiente paso
Una vez que funcione un pipeline simple, existen varias mejoras disponibles:
- Agregar una búsqueda híbrida para recuperar información tanto por significado como por términos exactos.
- Incluir un paso de reclasificación en el que un segundo modelo revise y ordene los fragmentos recuperados.
Las configuraciones avanzadas permiten utilizar agentes, recuperación en varios pasos o a través de gráficos, consultas contra bases de datos estructuradas, recuperación entre imágenes y texto, o sistemas de reclasificación adaptados a un dominio específico. Encuestas recientes indican que el campo está pasando de los sistemas RAG simples a sistemas modulares, en los cuales la recuperación, la generación y el aumento de información son componentes separados y flexibles, y no un proceso único e fijo. Aun así, el flujo básico sigue siendo la base: localizar pruebas relevantes, pasarlas al modelo y verificar que la respuesta esté respaldada por dichas pruebas.
Por qué vale la pena aprenderlo
RAG se ha popularizado porque resuelve una necesidad práctica. Las empresas, los investigadores, los desarrolladores y los equipos ya almacenan conocimientos valiosos en documentos, bases de datos, manuales, tickets y notas, y un modelo de lenguaje por sí solo no puede conocerlos de manera fiable. RAG le brinda al modelo una forma de buscar información.
La receta en sí es sencilla: preparar documentos, dividirlos, incrustar y almacenar sus partes, recuperar las adecuadas y luego hacer que el modelo responda a partir de ellas. La verdadera habilidad radica en los detalles, donde la calidad de las fuentes, el procesamiento en fragmentos, la recuperación de información, el diseño de los prompts, la evaluación y la seguridad son todos factores importantes. Un flujo básico no constituye la forma definitiva de un asistente inteligente, pero sigue siendo uno de los caminos más sencillos hacia una IA que sea más útil, actualizada y bien fundamentada. En lugar de pedirle al modelo que sea un oráculo omnisciente, RAG le entrega una tarjeta de biblioteca y le enseña a utilizarla adecuadamente.
Lecturas relacionadas
- Construyendo un pipeline ETL de producción para RAG con LangChain y FAISS — Diseño de procesos de fragmentación, incrustación e indexación vectorial para 40,000 PDFs relacionados con cumplimiento normativo, incluyendo mecanismos de reintentos, colas de mensajes no procesados, métricas de Prometheus y pruebas de rendimiento cuantificables.
- Notas prácticas: Construyendo un pipeline ISR moderno para la modalidad código en proyectos grandes — Guía paso a paso de las Notas prácticas: Construyendo un pipeline ISR moderno para la modalidad código en proyectos grandes: contratos, verificaciones y espacios de código listos para integrar para los equipos que implementan este patrón.