RAG Application Architecture Profile

Convención y problema

Este es un Architecture Profile editorial del Atlas: reúne decisiones para una aplicación que responde sobre un corpus mediante retrieval-augmented-generation. No introduce una definición competidora del patrón ni una arquitectura universal. El patrón explica la composición retrieval/generation; el perfil examina responsabilidades, datos, autoridad, operación y consecuencias de una aplicación concreta.

El escenario de referencia es una consulta sobre manuales internos con documentos versionados y acceso distinto entre equipos. La respuesta necesita evidencia vigente y trazable. El diseño conserva una opción de abstención cuando no puede sostener una respuesta suficiente. No presupone que el modelo conozca cambios recientes ni que cada consulta deba producir una explicación definitiva.

La guía de diseño y evaluación RAG de Microsoft, consultada el 2026-11-09, separa el flujo de aplicación y el pipeline de datos y plantea evaluación de sus etapas. Es una implementación de referencia en Azure; las decisiones siguientes son síntesis editorial del Atlas y no requieren ese proveedor.

Responsabilidades y flujo lógico

flowchart LR
    D[Fuentes autoritativas] --> I[Ingesta y versionado]
    I --> S[Indice y metadata]
    U[Usuario autenticado] --> A[API y politica de acceso]
    A --> R[Recuperacion autorizada]
    S --> R
    R --> C[Seleccion y contexto]
    C --> G[Generacion]
    G --> V[Validacion y evidencia]
    V --> U

El diagrama distribuye responsabilidades lógicas, no deployments obligatorios. La ingesta transforma fuentes en unidades recuperables y conserva su procedencia. El índice ofrece acceso a candidatos; la aplicación deriva el alcance autorizado desde la identidad del usuario. La selección decide qué evidencia entra en contexto y la generación produce una propuesta de respuesta que debe verificarse según su uso.

information-retrieval conserva consulta y ranking; context-management conserva selección y ensamblaje. Un resultado cercano según una medida de similitud puede seguir siendo irrelevante, estar obsoleto o pertenecer a otro usuario. Esas propiedades requieren comprobaciones distintas.

La respuesta debería permitir recuperar las fuentes utilizadas con una revisión o referencia suficientemente precisa. Añadir un enlace no demuestra soporte: corresponde contrastar si la afirmación se deriva de la evidencia citada y si esta responde la pregunta.

Decisiones en varios ejes

Eje	Decisión del perfil y alternativas abiertas
Decomposition	Separar responsabilidades de ingesta, consulta, contexto y salida; pueden compartir un proceso o desplegarse por separado.
Data ownership	Las fuentes conservan autoridad sobre contenido y permisos; el índice mantiene una representación derivada con procedencia.
Communication	Contratos explícitos para consulta, fragmentos, referencias y errores; lexical, vector o hybrid retrieval siguen abiertos.
Tenancy	El acceso se deriva de identidad confiable y se aplica a documentos, resultados, cachés y citas.
Coordination	Actualizaciones, revocaciones y borrados deben alcanzar las representaciones derivadas bajo una política conocida.
Isolation	Separar instrucciones de evidencia externa y limitar qué datos llegan al modelo y a logs.
Deployment y scaling	Escalar ingesta y consultas según sus cargas; compartir infraestructura no demuestra aislamiento entre ellas.
Execution model	Flujo de consulta normalmente delimitado; agentes iterativos solo cuando su flexibilidad aporta valor verificable.

El perfil puede componerse con modular-monolith, microservices o serverless-architecture. Su nombre no determina número de servicios, base vectorial ni framework. llamaindex y qdrant documentan tecnologías posibles, con responsabilidades diferentes y sin convertirse en requisitos de adopción.

Permisos antes de exponer contenido

Una consulta no debe recuperar primero todos los documentos y confiar en que el modelo omita los privados. La política debe proteger el recorrido antes de entregar contenido al destinatario no autorizado, incluido el proveedor de inferencia cuando corresponda. La identidad para construir filtros procede del sistema de autenticación, no de argumentos elegidos libremente por el modelo o el usuario.

La documentación de security filters de Azure AI Search ilustra una distinción útil: un filtro que incluye o excluye resultados por una cadena de principal no autentica ni autoriza por sí mismo. La aplicación necesita una correspondencia confiable entre identidad, permisos y consulta. Ese ejemplo no prescribe la misma implementación para todos los motores.

Revisar también cachés, snippets, títulos y enlaces. Una clave de caché compartida que omite el alcance de acceso puede reutilizar una respuesta de otro equipo. semantic-caching necesita criterios de elegibilidad compatibles con esas fronteras. Las citas deben respetar permisos, aunque el documento original ya no sea accesible.

Actualidad y recuperación

La ingesta debe conservar qué revisión produjo cada fragmento y con qué transformaciones. Actualizar una fuente puede exigir reemplazar unidades, invalidar cachés y retirar resultados anteriores. Guardar únicamente vectores dificulta explicar qué cambió si falta la relación con contenido y configuración.

El diseño debe declarar qué ocurre durante retrasos de indexación y revocaciones. Para datos sensibles puede ser necesario verificar acceso actual al consultar o suspender su exposición hasta completar la actualización. La elección depende de requisitos; este perfil no promete consistencia inmediata entre todos los componentes.

La reconstrucción del índice debe preservar acceso y procedencia. Restaurar un backup antiguo puede reintroducir documentos o permisos retirados: recuperar disponibilidad y recuperar un estado autorizado son objetivos relacionados, pero diferentes.

Fallos y evidencia de aceptación

Situación	Conducta que debe diseñarse y comprobarse
No hay evidencia suficiente	Pedir aclaración, abstenerse o devolver fuentes sin una conclusión injustificada.
Hay fuentes contradictorias	Conservar revisión y procedencia; comunicar el conflicto o aplicar una regla de autoridad definida.
Aparece una instrucción dentro de un documento	Tratarla como evidencia externa; mantener límites de prompt-injection.
Se revoca acceso o elimina una fuente	Comprobar búsqueda, caché, contexto y citas posteriores a la revocación según la política elegida.
Retrieval o generación excede el presupuesto	Degradar o terminar con un error observable; no fabricar una respuesta como sustituto silencioso.

La evaluación debería distinguir recuperación de documentos relevantes, soporte de afirmaciones, vigencia y aislamiento entre usuarios. Una respuesta plausible puede fallar en cualquiera de esos ejes. evaluation-datasets permite incluir consultas sin respuesta, conflictos y documentos fuera del alcance del solicitante; ai-evaluation-fundamentals organiza la comparación entre cambios.

ai-llm-observability ayuda a correlacionar versiones, consultas y errores sin volcar contenido confidencial por defecto. Medir latencia y costo junto con calidad y abstenciones evita optimizar una sola etapa a costa del resultado completo.

Cuándo encaja y cómo componerlo

Resulta pertinente evaluar este perfil cuando el resultado debe apoyarse en un corpus externo identificable y el equipo puede mantener su acceso, actualización y evaluación. Para mostrar documentos sin generar una respuesta puede bastar una búsqueda convencional. Para ejecutar acciones de negocio, tool-using-assistant-architecture aporta otro paquete de decisiones; la recuperación puede ser una de sus herramientas.

RAG no requiere delegar al modelo todo el control. La selección del perfil depende de architectural-drivers y de la evidencia que el equipo pueda obtener. Esta descripción no constituye un despliegue probado ni una garantía de exactitud; architecture-profiles y ai-assisted-software-engineering ofrecen los recorridos de navegación.