¿Qué es el RAG? La generación aumentada por recuperación explicada para empresas

La generación aumentada por recuperación, universalmente abreviada como RAG, es el patrón más desplegado de la inteligencia artificial empresarial. Casi todo sistema que responde preguntas sobre los documentos, las políticas, los productos o los expedientes de una organización usa alguna versión de él.

La idea es sencilla, y entenderla bien marca la diferencia entre un sistema en el que la gente confía y otro que abandona en silencio.

El problema que resuelve el RAG:

Un modelo de lenguaje solo conoce lo que había en sus datos de entrenamiento, que se detuvieron en una fecha fija y nunca incluyeron sus documentos internos. Pregúntele por su política de devoluciones y producirá algo que suena a política de devoluciones, inventado a partir de patrones en lugar de extraído de su política real.

Podría reentrenar el modelo con sus documentos, pero eso es caro, lento, hay que repetirlo cada vez que algo cambia y aun así no garantiza que el modelo reproduzca el texto con fidelidad.

El RAG toma otro camino. En lugar de enseñarle su información al modelo, usted localiza los pasajes pertinentes en el momento en que se hace la pregunta y los coloca directamente en su contexto. El modelo responde entonces con un texto que puede ver de verdad, no con patrones a medio recordar. Convierte un problema de memoria en un problema de comprensión lectora, que es en lo que estos modelos son genuinamente buenos.

Cómo funciona la recuperación:

El sistema tiene dos fases: la preparación, que se hace una vez y se actualiza cuando cambia el contenido, y la recuperación, que ocurre en cada pregunta.

En la preparación, los documentos se dividen en fragmentos de unos cientos de palabras. Cada fragmento pasa por un modelo de embedding, que convierte el texto en una lista de números, un vector, situado de modo que los pasajes de significado parecido queden cerca unos de otros. Esos vectores se guardan en una base de datos pensada para encontrar vecinos próximos con rapidez.

En el momento de la pregunta, esta se codifica del mismo modo. El sistema encuentra los fragmentos más cercanos, toma los mejores y construye una instrucción: aquí está la pregunta, aquí los pasajes pertinentes, responde usando solo este material y di si la respuesta no aparece.

Como se compara significado y no palabras clave, una pregunta sobre «tiempo libre» puede recuperar una política que solo habla de «vacaciones anuales».

Por qué la búsqueda híbrida suele ganar:

La búsqueda puramente semántica tiene una debilidad previsible: los identificadores exactos. Códigos de producto, números de error, referencias de factura y apellidos son justo donde flaquea el emparejamiento por significado, porque el vector de «SKU-88421» apenas lleva señal semántica.

Por eso los sistemas en producción ejecutan a la vez búsqueda semántica y búsqueda clásica por palabras clave, y luego fusionan los resultados. La búsqueda por palabras clave clava los términos exactos; la semántica atrapa las paráfrasis. Combinarlas supera de forma constante a cualquiera por separado, y los casos de fallo que cubren son en buena medida complementarios.

Una segunda etapa, el reordenamiento, mejora aún más los resultados. Una búsqueda barata devuelve, digamos, cincuenta fragmentos candidatos, y después un modelo más lento y más preciso puntúa esos cincuenta por pertinencia real y se queda con los cinco mejores. Este enfoque en dos etapas es mucho más exacto que recuperar cinco directamente, y cuesta poco, porque el modelo caro solo ve una lista corta.

La fragmentación decide más de lo que la gente cree:

Cómo se dividen los documentos tiene un efecto desproporcionado sobre la calidad, y es donde se tuercen casi todos los sistemas decepcionantes.

Los fragmentos demasiado pequeños pierden el contexto: un pasaje que dice «esto no se aplica a los contratistas» es peligroso separado de aquello a lo que «esto» se refiere. Los fragmentos demasiado grandes diluyen el significado, de modo que el embedding representa un promedio vago de varios temas y no encaja con nada con precisión.

Dividir por estructura, por sección y encabezado en vez de por un número fijo de caracteres, funciona mucho mejor que la división mecánica. Solapar ligeramente los fragmentos evita que las respuestas caigan entre dos límites. Adjuntar metadatos, el título del documento, el encabezado de sección, la fecha y la fuente, permite filtrar por actualidad o por departamento y, sobre todo, citar de dónde salió una respuesta.

Las citas no son opcionales:

La decisión de diseño más importante en un sistema RAG es exigir que el modelo indique qué pasaje recuperado respalda cada afirmación, con un enlace al documento de origen.

Las citas hacen tres cosas a la vez. Permiten a los usuarios verificar las respuestas en lugar de confiar en ellas, que es lo que hace utilizable el sistema para cualquier cosa con consecuencias. Hacen visible la alucinación, porque una afirmación sin respaldo no tiene cita. Y convierten la herramienta de oráculo en asistente de investigación, una posición mucho más defendible.

Los sistemas que responden con aplomo sin una fuente rastreable son los que pierden la confianza del usuario tras el primer error serio.

Dónde fallan los sistemas RAG:

El fallo más común no está en el modelo en absoluto. Está en la recuperación. Si el pasaje correcto nunca se trajo, ningún modelo puede producir una respuesta correcta. Cuando un sistema RAG decepciona, examine los fragmentos recuperados antes de culpar al modelo; el fallo suele estar ahí.

El segundo es el contenido caducado. Si los documentos de base se contradicen porque nunca se retiraron versiones obsoletas, el sistema sacará con aplomo una política superada. El RAG hereda exactamente la calidad del material de origen.

El tercero son las preguntas que exigen sintetizar muchos documentos. La recuperación encuentra pasajes parecidos a una pregunta, lo que funciona bien para «cuál es nuestra política sobre X» y mal para «resume todas las reclamaciones de este trimestre e identifica patrones». Eso es un problema de análisis disfrazado de interfaz de chat.

RAG, ajuste fino o un contexto más largo:

Se presentan a menudo como rivales. Resuelven problemas distintos.

El RAG aporta conocimiento: hechos, documentos, información actual. El ajuste fino moldea el comportamiento: tono, formato, vocabulario del dominio, estructura constante. Si la queja es que el modelo no sabe algo, eso es RAG. Si lo sabe pero responde con el estilo equivocado, eso es ajuste fino.

Las ventanas de contexto muy largas han llevado a algunos a sugerir que basta con pegarlo todo dentro. Para un conjunto moderado de documentos eso es hoy realmente viable y mucho más simple. Pero cuesta más por consulta, se vuelve más lento a medida que crece el contenido, y los modelos siguen atendiendo de forma desigual al material enterrado en medio de entradas muy largas. A escala, la recuperación sigue siendo la opción práctica, y ambas combinan bien: recuperar en amplitud y luego dejar que una ventana grande sostenga más de lo encontrado.

Construir uno que funcione:

Empiece estrecho. Un sistema que cubra un conjunto documental bien mantenido para un grupo de usuarios claramente definido triunfará donde fracasará el intento de indexarlo todo a la vez.

Mida la recuperación por separado de la generación, con un conjunto fijo de preguntas reales cuyas fuentes correctas se conocen. La mayor parte de la mejora viene de una mejor fragmentación, de la búsqueda híbrida y del reordenamiento, no de cambiar de modelo.

Sobre todo, mantenga limpia la fuente de verdad. El RAG no arregla un repositorio documental desordenado. Lo deja al descubierto.