Diagrama de arquitectura RAG: cómo encajan las piezas de una aplicación de generación aumentada por recuperación

La mayoría de los diagramas de arquitectura RAG tienen tres cajas: un usuario, una base de datos vectorial y un LLM. Esa imagen sirve para explicar la idea en una reunión, pero no ayuda a nadie a operar el sistema, porque faltan las decisiones que determinan la calidad y la seguridad de las respuestas: cómo se fragmentan los documentos, qué modelo de embeddings se usa, quién puede ver cada fragmento, cómo se ordenan los resultados y cómo sabe alguien que las respuestas son buenas.

Esta guía dibuja el cuadro completo de una aplicación de generación aumentada por recuperación como dos caminos alrededor de modelos y almacenes compartidos, y después repasa qué etiquetar y los errores más frecuentes.

Dos caminos, no uno

El término viene de Lewis et al. (2020), que combinaron un modelo de lenguaje con un índice vectorial denso de Wikipedia en el que un recuperador buscaba durante la generación. La mayoría de las aplicaciones RAG en producción mantienen la idea sin entrenar las piezas juntas: recuperar pasajes relevantes, ponerlos en el prompt y pedir al modelo que responda a partir de ellos.

Eso da a toda aplicación RAG dos caminos:

• La ingesta se ejecuta continuamente en segundo plano. Convierte los documentos en fragmentos, vectores y metadatos.
• La consulta se ejecuta una vez por pregunta. Convierte una pregunta en una respuesta con fuentes.

Los dos se encuentran en las piezas compartidas: el modelo de embeddings, que debe tener la misma versión en ambos caminos, el índice vectorial y el almacén de metadatos. Un diagrama que solo muestra el camino de consulta esconde la mitad del sistema y la mayoría de los bugs.

El camino de ingesta

1. Fuentes y detección de cambios. Conectores, webhooks o un rastreador detectan documentos nuevos, modificados y eliminados, y dejan trabajos en una cola. Los borrados y los cambios de permisos también son trabajos.
2. Análisis. Extrae el texto conservando la estructura: encabezados, listas, tablas y metadatos como el título, la URL, el propietario, la última actualización y la lista de control de acceso.
3. Fragmentación. Divide primero según la estructura del documento y después por tamaño. El tamaño de los fragmentos y el solapamiento son parámetros que ajustas con tus propias preguntas, no números universales. Conserva en cada fragmento la ruta de encabezados para que un párrafo se entienda por sí solo.
4. Embeddings. Llama a un único modelo de embeddings y fija su versión. Guarda el nombre y la versión del modelo con cada vector. Los vectores de modelos distintos no son comparables, así que cambiar de modelo significa recalcular los embeddings de todo el corpus.
5. Indexación. Haz un upsert de cada fragmento con su vector, el ID del documento, el número de fragmento, la versión y las etiquetas de acceso. Si piensas usar búsqueda híbrida, mantén un índice de palabras clave junto al índice vectorial.
6. Actualización y borrado. Haz que los upserts sean idempotentes, borra los fragmentos de los documentos eliminados y vigila la frescura: cuánto tarda un cambio en la fuente en llegar al índice.

El camino de consulta

1. Identifica al usuario. Resuelve los grupos del usuario antes de que empiece la recuperación.
2. Reformula la pregunta (opcional). Una pregunta de seguimiento como "¿y para los contratistas?" tiene que convertirse, con ayuda de la conversación, en una consulta independiente.
3. Recupera. La búsqueda vectorial encuentra pasajes con un significado parecido; la búsqueda por palabras clave encuentra términos exactos como códigos de error y nombres de productos. La búsqueda híbrida ejecuta las dos y fusiona las listas, a menudo con reciprocal rank fusion, que puntúa cada documento con 1/(k + posición) sumado sobre las listas. El artículo original de RRF fijó k en 60.
4. Filtra por permisos dentro de la consulta. Pasa los grupos del usuario como filtro sobre las etiquetas de acceso, para que los fragmentos que el usuario no puede ver nunca lleguen al prompt. Comprueba cómo aplica los filtros tu almacén. La documentación de pgvector advierte de que, con índices aproximados, el filtro se aplica después de recorrer el índice: con el valor por defecto de ef_search de HNSW, 40, un filtro que coincide con el 10 % de las filas devuelve unas 4 filas de media. Los recorridos iterativos, los índices parciales o el particionado lo resuelven.
5. Reordena. Recupera con generosidad, por ejemplo 50 candidatos, y deja que un modelo de reranking los puntúe respecto a la pregunta. Quédate con los mejores, por ejemplo 8.
6. Arma el prompt. Instrucciones, los fragmentos elegidos con sus IDs y títulos, y la pregunta, dentro de un presupuesto de tokens. Pide citas por ID de fragmento.
7. Genera y cita. Llama al LLM, envía la respuesta en streaming y convierte los IDs de fragmento en enlaces que el usuario pueda comprobar.

Alrededor de los dos caminos

• Trata el texto recuperado como entrada no fiable. Un documento puede contener instrucciones dirigidas al modelo. OWASP lo recoge como inyección de prompt indirecta. Limita las herramientas y los datos a los que llega el modelo al mismo acceso que tiene el usuario.
• Traza cada petición. Registra la consulta reformulada, los IDs de los fragmentos recuperados y reordenados con sus puntuaciones, la versión del prompt, las versiones de los modelos y la latencia de cada paso.
• Evalúa con un conjunto fijo de preguntas. Ejecútalo en cada cambio de fragmentación, modelos, recuperación o prompt. El artículo de RAGAS propone tres dimensiones útiles: fidelidad al contexto recuperado, relevancia de la respuesta y relevancia del contexto. Comprueba también si la fuente esperada aparece entre los primeros resultados.
• Cachea con cuidado. Cachear los embeddings de las consultas suele ser seguro. Cachear las respuestas solo es seguro por conjunto de permisos.

El diagrama

Cómo leerlo:

• A la izquierda, la ingesta. Los cambios en las fuentes se convierten en trabajos en una cola. El worker de ingesta analiza y fragmenta cada documento, llama al modelo de embeddings, hace upsert de los fragmentos y vectores con sus etiquetas de acceso en el índice vectorial y escribe los metadatos de los documentos en Postgres.
• En el centro, modelos y almacenes compartidos. El mismo modelo de embeddings, con la versión fijada, sirve a los dos caminos. El LLM también está aquí y solo lo llama el camino de consulta.
• A la derecha, la consulta. La API RAG obtiene los grupos del usuario, calcula el embedding de la pregunta, ejecuta la búsqueda híbrida con el filtro de permisos, envía 50 candidatos al reranker y llama al LLM con los 8 mejores fragmentos.
• Abajo a la izquierda. Un ejemplo de presupuesto de latencia por paso, para poder rastrear una respuesta lenta hasta el paso que se pasó de su presupuesto.

Qué etiquetar

• Las versiones de los modelos en cada nodo de modelo, incluido el modelo de embeddings.
• Los parámetros de fragmentación, en el worker de ingesta o en una nota.
• Dónde se aplican los permisos, sobre la conexión de recuperación, no en una nota al pie.
• Cuántos resultados pasan entre pasos: 50 recuperados, 8 en el prompt.
• Los objetivos de frescura y latencia: cuánto tarda un cambio en la fuente en poder buscarse y el presupuesto de cada paso de la consulta.

Errores habituales

• Una sola caja llamada "IA". La recuperación, el reranking y la generación fallan de formas distintas y necesitan cajas separadas.
• Sin camino de ingesta. Las respuestas obsoletas o ausentes suelen empezar ahí.
• Sin permisos. Si el índice contiene documentos para públicos distintos, un diagrama sin etiquetas de acceso describe una fuga de datos.
• Sin evaluación. Sin un conjunto de preguntas, cada cambio en el prompt o en el tamaño de los fragmentos es una apuesta.
• Versiones de embeddings mezcladas. Recalcular con un modelo nuevo los embeddings de la mitad del corpus rompe la búsqueda sin hacer ruido.

Cuándo RAG no es la respuesta

• La respuesta está en datos estructurados. Consulta la base de datos o una API en lugar de calcular embeddings de las filas de una tabla.
• La tarea necesita un documento entero. Resumir un contrato funciona mejor con el contrato completo en el prompt, si cabe.
• El corpus es diminuto. Unas pocas páginas pueden ir directamente en el prompt.
• Necesitas otro comportamiento, no más conocimiento. Eso es un problema de prompt o de fine-tuning.

Para una ingesta orientada a eventos con colas, consulta la guía del diagrama de arquitectura orientada a eventos.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade dos nodos Marco del pack Básico: "Ingestion path" a la izquierda y "Query path" a la derecha.
3. En el marco de ingesta, añade un Almacén de objetos del pack Datos para los documentos fuente, una Cola del pack Datos para los trabajos de ingesta y un Contenedor del pack Modelo C4 para el worker de ingesta.
4. En el centro, añade un Modelo del pack ML para el modelo de embeddings, un Índice vectorial del pack ML, un Postgres del pack Datos para los metadatos y los permisos, y un segundo Modelo para el LLM.
5. En el marco de consulta, añade una Persona del pack Modelo C4 para el usuario, un Contenedor para la API RAG y un Modelo del pack ML para el reranker.
6. Etiqueta cada conexión con lo que circula por ella, incluidos "top 50" y "top 8", y pon el presupuesto de latencia en un bloque Markdown del pack Básico.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free. Si trabajas con un agente de IA, puede dibujarte una primera versión por MCP a partir de una descripción de los dos caminos; consulta cómo crear diagramas de arquitectura con agentes de IA. Para el método general, consulta cómo dibujar un diagrama de arquitectura de software.

Preguntas frecuentes

¿Necesito una base de datos vectorial dedicada para RAG? No. Una extensión vectorial en una base de datos que ya operas, como pgvector en PostgreSQL, o un motor de búsqueda con soporte vectorial basta para muchas aplicaciones. Elige según el tamaño del corpus, tus necesidades de filtrado y lo que tu equipo opera bien.

¿Qué tamaño de fragmento debería usar? No hay un número universal. Divide por encabezados y párrafos, y luego compara varios tamaños y solapamientos con tu propio conjunto de preguntas.

¿Dónde deberían hacerse las comprobaciones de permisos? En la ingesta, copiando la lista de acceso de cada documento en sus fragmentos, y en la recuperación, filtrando por ella. Nunca confíes en el prompt para ocultar contenido.

¿Cómo evalúo una aplicación RAG? Mantén un conjunto fijo de preguntas reales con sus fuentes esperadas. Mide si la recuperación encuentra esas fuentes y si las respuestas son fieles al contexto recuperado y relevantes para la pregunta.

¿Debería el LLM llamar a herramientas en lugar de usar RAG? Para datos en vivo o estructurados, sí: una herramienta que consulta el sistema de registro es mejor que un índice de copias. Muchas aplicaciones usan las dos cosas.

Empieza gratis — un puesto, sin tarjeta de crédito.