RAG (generación aumentada por recuperación) es un enfoque en el que un modelo de lenguaje fundamenta su respuesta en fragmentos recuperados de los propios documentos de una organización. Este artículo describe qué decisiones debe dejar por escrito pronto quien dirige un proyecto RAG; es mi método de trabajo, no una afirmación sobre un resultado medido.
¿Por qué un proyecto RAG es un problema de gestión?
En los proyectos RAG el modelo suele ser un servicio ya hecho; el trabajo real está en decisiones como qué documentos se usarán, quién puede ver qué y cómo se medirá la exactitud de las respuestas. Si esas decisiones no se escriben, el proyecto acaba en «la demo se ve bien, pero no es fiable en producción». Los pasos siguientes siguen el orden que uso en proyectos de IA.
1. Alcance: ¿qué preguntas responderá?
El primer paso es escribir qué preguntas de usuario responderá el sistema y cuáles no. «Consultar todos los documentos de la empresa» es un deseo, no un alcance. Se reúnen preguntas de ejemplo de usuarios; definen tanto el alcance como la evaluación posterior.
2. Documentos fuente y responsabilidad de los datos
¿Qué documentos entran en el índice? ¿Están actualizados, hay versiones contradictorias, contienen datos personales? Cada grupo de documentos necesita un responsable y se define de antemano cómo se actualiza el índice cuando un documento cambia. La base de una respuesta debe poder mostrarse: el usuario debería ver de qué sección de qué documento se construyó la respuesta.
3. Control de acceso
RAG puede filtrar el contenido de un documento confidencial a quien no tiene acceso. Por eso la regla de acceso se aplica en el momento de la consulta y se escribe en el primer plan: ¿quién puede preguntar sobre qué grupo de documentos? Es una decisión de arquitectura, no una función que se añade después.
4. El conjunto de evaluación
Se prepara un pequeño conjunto de evaluación con preguntas reales de usuarios y los documentos fuente esperados para ellas. Cada versión se compara con ese conjunto; «se ve bien» no basta. Se examinan por separado si el sistema encontró el documento correcto y si extrajo la conclusión correcta del documento encontrado.
5. Piloto, coste y latencia
El piloto se hace con un grupo limitado de usuarios. En esta fase se miden el tiempo de respuesta y el coste de uso; la decisión de ampliar se escribe tras valorar juntos exactitud, tiempo y coste.
6. Seguimiento y gestión del cambio
En producción se vigilan los comentarios de usuarios, las preguntas sin respuesta y los cambios de documentos. Cuando cambian el modelo, el prompt o el conjunto de documentos, se vuelve a ejecutar el conjunto de evaluación. Este proceso coincide con las preguntas de ciclo de vida y seguimiento de la lista de verificación ISO/IEC 42001.
Preguntas frecuentes
¿Cuál es la diferencia entre RAG y el ajuste fino?
RAG fundamenta la respuesta en fragmentos de documentos recuperados en el momento de la consulta; al cambiar los documentos se actualiza el índice. El ajuste fino entrena el propio modelo con ejemplos. Pueden combinarse; la elección depende de la actualidad de los datos, la trazabilidad y el coste.
¿Cuál es el error de gestión más común en un proyecto RAG?
Dejar el conjunto de evaluación y el control de acceso para el final. Ambos afectan a la arquitectura, así que van en el primer plan.
¿Cuánto dura un proyecto RAG?
Depende del número de documentos, la complejidad del control de acceso y las integraciones; una vez escrito el alcance se planifica la duración del piloto. No prometo una duración que no he medido.