Una aplicación RAG no empieza cuando el modelo genera texto. Empieza mucho antes, al decidir qué documentos entran, cómo se dividen, qué permisos conservan y qué evidencia debe acompañar a cada respuesta. El recorrido completo va desde una fuente de información hasta un contexto seleccionado para una consulta concreta.
Seguir ese recorrido por etapas ayuda a localizar fallos. Una respuesta incorrecta puede deberse a un documento desactualizado, a un fragmento mal dividido, a una búsqueda poco precisa o a instrucciones que no dejan claro cómo usar el contexto. El modelo es solo una pieza de la arquitectura.
El punto de partida: fuentes y responsabilidad
Primero se identifican las fuentes que la aplicación podrá consultar: manuales, procedimientos, páginas internas, tickets o registros estructurados. No todas deben tratarse igual. Un documento público puede tener requisitos de actualización distintos a una política interna con datos personales.
Cada fuente necesita un responsable, una fecha de vigencia y una regla de acceso. Si una persona puede consultar únicamente la documentación de un producto, el filtro de permisos debe aplicarse antes de construir el contexto. Guardar todos los documentos en un índice común y confiar en el modelo para ocultar información sensible no es un control suficiente.
Ingesta, limpieza y versiones
La ingesta convierte los documentos originales en registros procesables. En ese paso se extrae texto, se eliminan elementos que no aportan información, se detectan duplicados y se conservan metadatos como idioma, producto, versión y origen. Un PDF con columnas, pies de página o tablas puede producir un texto desordenado si se extrae sin comprobar el resultado.
La versión importa tanto como el contenido. Si una política cambia, los fragmentos antiguos deben retirarse o marcarse como obsoletos. Una práctica útil es guardar un identificador de documento y una fecha de indexación junto al texto. Así se puede explicar por qué una respuesta se basó en una edición concreta.
Segmentación: convertir documentos en unidades recuperables
El texto completo suele ser demasiado grande para recuperarlo de una vez. La segmentación, o chunking, crea unidades manejables. El tamaño debe conservar suficiente contexto para que un fragmento tenga sentido sin mezclar varias instrucciones incompatibles. Separar cada frase puede perder relaciones; usar páginas enteras puede devolver mucho ruido.
El solapamiento entre fragmentos puede ayudar cuando una definición continúa en la siguiente unidad, aunque también aumenta almacenamiento y duplicación. La prueba debe incluir documentos cortos, tablas, listas y encabezados. Un sistema que funciona con párrafos sencillos puede fallar al procesar un procedimiento con pasos numerados.
Embeddings, índice y metadatos
Cada fragmento se transforma mediante un modelo de embeddings en una representación numérica. Esa representación permite comparar una consulta con los fragmentos del índice dentro del espacio aprendido por ese modelo. El vector no sustituye al texto original: ambos deben conservarse para poder mostrar la fuente y construir el contexto.
Los metadatos permiten filtrar antes o durante la búsqueda. Por ejemplo, una consulta sobre la versión 4 de un producto no debería recuperar instrucciones de la versión 2 solo porque comparten vocabulario. El filtro por versión, idioma o permisos puede reducir falsos positivos antes de ordenar los resultados por similitud.
De la consulta al contexto
Cuando llega una pregunta, el backend puede normalizarla, aplicar los filtros autorizados y generar su embedding. El buscador recupera un conjunto inicial de candidatos y la aplicación decide cuáles caben en el contexto disponible. Recuperar muchos fragmentos no garantiza una respuesta mejor: puede introducir contradicciones o desplazar la información relevante.
En algunas arquitecturas se añade una segunda ordenación para comparar con más detalle los candidatos. Sea cual sea el método, la aplicación debería conservar qué fragmentos se seleccionaron. Una respuesta que no puede relacionarse con sus fuentes es más difícil de revisar y de corregir.
Construcción del prompt y generación
El contexto recuperado se entrega al modelo junto con instrucciones que delimitan la tarea. Es útil indicar que la información proporcionada es una fuente de consulta, pedir que señale cuándo no hay evidencia suficiente y separar la pregunta de los documentos recuperados. El texto recuperado no debe convertirse automáticamente en una instrucción con permisos propios.
La generación produce una respuesta, pero no verifica por sí sola que cada afirmación sea correcta. En una aplicación interna puede ser preferible mostrar citas, fechas o enlaces a la fuente. Para operaciones sensibles, la respuesta debería orientar al usuario y dejar la acción en manos de un flujo autorizado.
Actualización, evaluación y observabilidad
Una arquitectura RAG necesita un proceso para detectar documentos nuevos, reindexar cambios y retirar versiones antiguas. La actualización debe poder repetirse sin crear copias infinitas del mismo fragmento. También conviene registrar la versión del índice, el modelo de embeddings y el tiempo de respuesta.
La evaluación debe usar preguntas reales o representativas, incluyendo casos en los que la respuesta correcta sea no lo sé. Mide si el fragmento pertinente aparece entre los resultados, si el contexto contiene información contradictoria y si la respuesta respeta las fuentes. Separa la calidad de recuperación de la calidad de redacción del modelo.
Dónde conviene medir antes de optimizar
Si una respuesta falla, sigue el recorrido completo: fuente original, extracción, fragmento, embedding, filtro, resultados recuperados, prompt y salida. Esa trazabilidad evita cambiar el modelo cuando el problema está en un índice que aún contiene una política retirada. RAG aporta valor cuando la información puede mantenerse y auditarse; añade complejidad cuando no existe una fuente fiable o el volumen de conocimiento no justifica otra capa.
Fallos que conviene aislar
Una fuente puede fallar por permisos, el extractor puede perder una tabla, el índice puede quedar desactualizado y el modelo puede recibir un contexto demasiado largo. Cada etapa necesita una señal distinta: errores de ingesta, número de fragmentos indexados, tasa de resultados vacíos, latencia de recuperación y respuestas sin evidencia.
En una prueba de extremo a extremo, una pregunta sobre un procedimiento retirado debería producir una respuesta que indique que la fuente no está vigente, no una mezcla de dos versiones. Registrar los identificadores recuperados permite reproducir la prueba sin almacenar innecesariamente la consulta completa.
Diseñar el contrato entre componentes
La aplicación debería definir qué devuelve el recuperador y qué espera el generador. Ese contrato puede incluir texto, fuente, versión, permisos y una puntuación orientativa, pero no debe convertir la puntuación en una decisión automática sobre la verdad. También debe establecer qué ocurre cuando no hay resultados o cuando el servicio de embeddings no está disponible.
Separar el índice de la interfaz facilita cambiar la estrategia de recuperación sin exponer credenciales ni lógica interna en el navegador. En sistemas con datos privados, la autorización se comprueba en el backend y se revisa junto con los registros de acceso.