RAG en la empresa: cuando tu documentación vale más que el modelo

El 19 de septiembre Anthropic publicó una técnica llamada recuperación contextual. Consiste en añadir a cada fragmento de documento, antes de indexarlo, una breve explicación de dónde procede y de qué trata. Según sus pruebas, combinada con búsqueda léxica reduce en un 49 % los fallos de recuperación, y en un 67 % si se añade una fase de reordenación de resultados.

La cifra es interesante, pero lo más revelador es dónde está la mejora: no en el modelo que redacta la respuesta, sino en cómo se prepara y se recupera la documentación. Es una confirmación de algo que vemos en cada proyecto de implantación: en un sistema de RAG, la calidad de la documentación interna pesa más que la elección del modelo.

Qué es RAG, sin tecnicismos

La generación aumentada por recuperación, descrita en 2020 por investigadores de Facebook AI, combina dos piezas. Un buscador localiza los fragmentos de documentos más relevantes para una pregunta, y un modelo de lenguaje redacta la respuesta usando solo esos fragmentos. Bien hecho, permite que el sistema responda con información propia y actualizada, y que cite de dónde la ha sacado.

Para una ingeniería o un estudio de arquitectura, los candidatos naturales son evidentes: el archivo de proyectos anteriores, las memorias tipo, los pliegos de licitaciones pasadas, los procedimientos internos de calidad, las fichas de soluciones constructivas, las respuestas a requerimientos de ayuntamientos y colegios.

Cuatro decisiones que deciden el resultado

1. Permisos

Un sistema de RAG que ignora los permisos del archivo original es un problema de seguridad. Si un técnico no puede abrir la carpeta de ofertas económicas, tampoco debe recibir fragmentos de ella en una respuesta. Los permisos deben replicarse en el índice, documento a documento, y revisarse cuando cambian en origen.

2. Vigencia

Esta es la decisión más olvidada. Un archivo técnico acumula versiones: memorias redactadas con el DB-HE de 2013, procedimientos sustituidos, detalles constructivos que el estudio ya no recomienda. Si todo se indexa por igual, el sistema responderá con lo que encuentre, no con lo que esté vigente.

Hace falta un criterio explícito: qué se indexa, con qué fecha, qué se marca como histórico y quién decide retirarlo. Es una tarea de gestión documental, no de programación.

3. Citas

Toda respuesta debe indicar de qué documento, apartado y fecha procede. Sin cita, el usuario no puede verificar, y un sistema no verificable acaba siendo ignorado o, peor, creído sin control.

Un sistema de RAG no es más fiable que el archivo que lo alimenta. Si el archivo está desordenado, el sistema lo estará con mejor redacción.

4. Evaluación

Hay que medir antes de desplegar y seguir midiendo después. Lo práctico es construir un conjunto de cincuenta a cien preguntas reales con su respuesta correcta y su documento de origen, redactado por los técnicos que conocen el archivo. Cada cambio en el sistema se prueba contra ese conjunto.

Conviene medir dos cosas por separado. Primero, si el buscador ha recuperado el fragmento correcto. Después, si la respuesta redactada es fiel a ese fragmento. Cuando una respuesta falla, saber cuál de las dos piezas ha fallado ahorra semanas de pruebas a ciegas: casi siempre el problema está en la recuperación, no en la redacción.

Lo que RAG no sustituye

RAG no convierte un archivo en conocimiento validado. Si el estudio resolvió mal una evacuación en un proyecto de 2016, el sistema puede proponer esa misma solución con total aplomo. Por eso el responsable del archivo no es un perfil informático, sino técnico: alguien con criterio para decidir qué documentos representan buena práctica y cuáles deben quedar fuera.

Un ejemplo compuesto

Lo que sigue es un escenario tipo, construido a partir de varios proyectos similares y anonimizado; las cifras son estimaciones orientativas.

Una ingeniería de unas sesenta personas, especializada en instalaciones de edificios terciarios, quería que sus técnicos consultaran el archivo de proyectos antes de empezar uno nuevo. El archivo tenía unos quince años de documentos en una unidad de red, con una estructura de carpetas que había cambiado tres veces.

La primera versión indexó todo. Los resultados fueron decepcionantes: respuestas basadas en el antiguo reglamento de instalaciones térmicas anterior a su revisión, mezcla de criterios de distintos clientes y fragmentos de ofertas económicas visibles para todo el personal.

La segunda versión cambió el enfoque:

• Se acotó el alcance a proyectos de los últimos cinco años y a los procedimientos de calidad vigentes.
• Se etiquetó cada documento con tipo, fecha, proyecto y nivel de confidencialidad.
• Se excluyeron las carpetas económicas y contractuales.
• Se construyó un conjunto de ochenta preguntas de prueba con los jefes de departamento.

En la estimación interna, la proporción de respuestas aceptadas sin corrección pasó de menos de la mitad a una amplia mayoría. Pero el trabajo de mayor peso no fue técnico: fueron unas seis semanas de dedicación parcial de dos técnicos senior para clasificar documentos y escribir las preguntas de prueba.

Mi recomendación

Antes de hablar de modelos, una empresa que quiere implantar RAG debería contestar cuatro preguntas: quién puede ver qué, qué documentos están vigentes, cómo se citará cada respuesta y cómo sabremos si funciona.

Si las respuestas no existen, el proyecto empieza por ahí. El modelo se puede cambiar en una tarde. Ordenar quince años de archivo, no. Y es precisamente ese archivo ordenado el activo que diferencia a una empresa de su competencia.