RAG para empresas: qué es y cuándo usarlo

Qué es RAG, sin la parte mágica

RAG —retrieval augmented generation, generación aumentada por recuperación— es una idea sencilla con consecuencias grandes: en lugar de confiar en lo que el modelo sabe, se busca primero en tus documentos, se seleccionan los fragmentos relevantes y se le entregan junto con la pregunta. El modelo redacta la respuesta a partir de ese material.

Conviene decir en voz alta lo que no ocurre, porque marca el límite de lo que se le puede pedir al sistema: el modelo no aprende nada de tus documentos, no los recuerda entre una consulta y la siguiente, y no adquiere ninguna capacidad nueva. Cada respuesta se construye con el texto que se le acaba de pasar. Si ese texto no contiene la respuesta, no hay contexto que valga.

De ahí sale la consecuencia que ordena el diseño: conviene tratar un sistema RAG, ante todo, como un sistema de búsqueda. Lo que el modelo puede afirmar con fundamento está acotado por lo que la recuperación le haya puesto delante. Cambiar de modelo, con una recuperación que no encuentra el fragmento correcto, no arregla ese límite.

Las seis etapas, y las tres que deciden la calidad

Estas son las etapas que recorre una arquitectura RAG típica; los nombres cambian según la implementación. Vale la pena mirarlas por separado porque el esfuerzo de ingeniería se reparte muy mal si se piensa en el conjunto como «una llamada al modelo».

Anatomía de un sistema RAG

• Ingesta
• Troceado
• Indexación
• Recuperación
• Contexto
• Generación

• Permisos del usuario
• Frescura del índice
• Trazas y citas
• Regla de abstención

Las cuatro condiciones de abajo atraviesan las seis etapas. Si alguna se decide tarde, se rehace la arquitectura, no se ajusta un parámetro.

Ingesta. Qué documentos entran, de qué sistemas, con qué frecuencia y quién decide que un documento es válido. Es una decisión de negocio disfrazada de tarea técnica.

Troceado. Los documentos se parten en fragmentos. Cómo se parten determina si la respuesta llega entera o cortada por la mitad: una tabla partida en dos trozos deja de ser una tabla, y una cláusula separada de su encabezado pierde el contexto que la hacía interpretable.

Indexación. Los fragmentos se guardan de forma que se puedan encontrar. Aquí se decide si la búsqueda es semántica, por palabras clave o ambas. Cuando las consultas dependen de términos exactos —códigos de producto, referencias, nombres propios—, ajustar esa mezcla suele mover más la calidad que cambiar de modelo, porque el fallo está en no encontrar el fragmento, no en redactarlo.

Recuperación. Dada una pregunta, se eligen los fragmentos candidatos. Si aquí no aparece el fragmento correcto, ninguna etapa posterior puede recuperarlo; por eso conviene medirla por separado en lugar de juzgarla a través de la respuesta final.

Contexto. Los fragmentos elegidos se ordenan y se montan en la petición, con instrucciones sobre qué hacer si no bastan. Sin esa instrucción explícita, el modelo rellenará el hueco.

Generación. El modelo redacta. Con un buen contexto es la parte aburrida del sistema, y así debería ser.

Troceado, indexación y recuperación son las tres etapas donde solemos concentrar el esfuerzo de ingeniería, porque entre las tres deciden qué material llega a la generación. Cuánto pesa cada una depende del corpus y del tipo de pregunta; conviene medirlo en tu caso antes de repartir el presupuesto.

Por dónde se rompe de verdad

Estos son los modos de fallo que encontramos con más frecuencia al revisar sistemas RAG. Todos tienen algo en común: se originan fuera del modelo, así que cambiar de proveedor rara vez los resuelve por sí solo.

Dónde falla	Cómo se manifiesta ante el usuario	Causa habitual	Control que lo contiene
Recuperación	Respuesta segura y equivocada, o «no encuentro nada» sobre algo que sí está documentado	Troceado que rompe la unidad de significado; búsqueda solo semántica sin coincidencia exacta de términos, códigos o referencias	Medir la recuperación por separado de la respuesta; búsqueda híbrida; reordenación de candidatos
Permisos	Un usuario ve, resumido, contenido al que no debería tener acceso	El filtro de permisos se aplica después de recuperar, o no se aplica al índice	Filtrar por identidad antes de recuperar; el índice hereda el modelo de acceso del origen
Frescura	El sistema responde con la versión antigua de una política o un precio	Reindexación manual o por lotes lentos; borrados que no se propagan al índice	Frecuencia de reindexación acordada por tipo de documento; borrado propagado y verificado
Contradicción entre fuentes	Dos respuestas incompatibles según cómo se pregunte	El corpus contiene versiones que conviven sin jerarquía declarada	Declarar qué documento manda; retirar lo obsoleto del índice, no solo de la intranet
Atribución	Cita un documento que no dice lo que la respuesta afirma	El sistema devuelve fuentes sin comprobar que sostienen la afirmación	Citas a nivel de fragmento; revisión de fidelidad como métrica propia
Preguntas fuera del corpus	Contesta igualmente, con tono normal	No hay regla de abstención ni umbral de confianza en la recuperación	Instrucción y umbral explícitos: sin evidencia suficiente, decir que no consta y derivar

Dos de estas merecen un párrafo aparte.

Los permisos no son un filtro posterior. Si el sistema recupera primero y filtra después, ya ha construido una respuesta con material que el usuario no puede ver; basta un fallo de implementación para que se escape. El control de acceso pertenece a la consulta, no al resultado. En un despliegue interno con varios departamentos, corregirlo tarde obliga a rehacer la capa de recuperación entera, no a añadir un filtro.

La abstención es una funcionalidad, no una carencia. Si un sistema contesta con el mismo tono tanto cuando tiene evidencia como cuando no la tiene, el usuario no puede distinguir los dos casos. «Esto no consta en la documentación disponible; te paso con el equipo responsable» es una respuesta legítima, y hay que diseñarla y probarla como cualquier otra.

Cuándo compensa y cuándo no

RAG encaja bien cuando la respuesta existe por escrito en algún sitio y el problema es encontrarla, interpretarla y expresarla. No encaja cuando el problema es de otra naturaleza.

Compensa cuando:

• el conocimiento vive en documentos que cambian, y reentrenar cada vez que cambian sería absurdo;
• hace falta poder señalar de dónde salió cada afirmación;
• el acceso al contenido depende de quién pregunta;
• hay volumen real de consultas repetidas sobre el mismo corpus.

No compensa —o al menos no es lo primero— cuando:

• lo que se quiere cambiar es el formato o el tono de la salida, no el conocimiento: eso es otro problema y lo tratamos en RAG frente a fine tuning;
• la respuesta correcta requiere calcular sobre datos estructurados, no leer prosa: si el dato ya vive en una base de datos, una consulta devuelve un resultado exacto y reproducible, y recuperar prosa que habla de ese dato no mejora eso;
• la documentación de partida es escasa, contradictoria o está desactualizada. RAG amplifica el estado de tu contenido; no lo arregla;
• el volumen de preguntas es tan bajo que una persona lo atiende sin esfuerzo. Un sistema con índice, permisos y vigilancia tiene coste de mantenimiento permanente.

Ese último punto es fácil de pasar por alto. La pregunta previa no es «¿podemos montar RAG?», sino «¿qué proceso mejora, cuánto se usa hoy y con qué línea base lo vamos a comparar?». El criterio para elegir por dónde empezar es el mismo que aplicamos en qué procesos conviene automatizar primero.

Lo que RAG exige de tus datos

Un sistema RAG hereda, sin filtro, el estado del contenido que indexa. Si conviven tres versiones de la misma política, el sistema las citará las tres con la misma seguridad. Si un documento no dice cuándo se escribió, el sistema no puede preferir el reciente. Si nadie es dueño de una carpeta, nadie retirará lo obsoleto.

Antes del índice hacen falta tres acuerdos, y ninguno es técnico:

• Dueño por tipo de documento. Quién decide qué entra, qué se retira y con qué cadencia se revisa. Sin un nombre propio detrás, la revisión no llega a ocurrir.
• Jerarquía declarada. Cuando dos documentos se contradicen, cuál manda. Escrito, no sobreentendido.
• Ciclo de vida. Qué significa que un documento está obsoleto y qué pasa entonces en el índice, no solo en la carpeta compartida.

Cuando lo que falla es más profundo —fuentes que no cuadran, definiciones distintas por departamento, identidades duplicadas— el trabajo previo no es de recuperación sino de datos, y es el terreno de Datos e inteligencia. Es incómodo de oír al principio de un proyecto, y evita rehacer más tarde el índice y el conjunto de evaluación sobre un corpus que no se sostenía.

Cómo se evalúa, en dos mitades

Medir solo «si la respuesta gusta» deja fuera la información que hace falta para arreglarla. Conviene evaluar un sistema RAG en dos mitades separadas, porque se rompen por motivos distintos y se arreglan con trabajo distinto.

Mitad uno: la recuperación. Dada una pregunta y un conjunto de preguntas reales con la fuente correcta anotada por una persona, ¿aparece el fragmento correcto entre los recuperados? Esta mitad no necesita al modelo para medirse. Es diagnóstico puro: si el fragmento correcto no aparece entre los recuperados, ajustar el prompt no puede compensarlo.

Mitad dos: la respuesta. Dado el contexto recuperado, ¿lo que se afirma está sostenido por ese contexto —y solo por ese contexto—? ¿Cita el fragmento que efectivamente lo dice? ¿Se abstiene cuando el material no basta?

Las etiquetas las pone quien hoy responde esas preguntas a mano, no el equipo técnico y no otro modelo. Y el conjunto de preguntas se congela y se versiona: sin una referencia estable, el cambio del mes que viene —otro troceado, otro índice, otro modelo— no se puede comparar con nada.

Los controles que pedimos antes de conectar datos reales

Esta es la lista que aplicamos en Mellisma como condición de entrada, no un estándar del sector. Cada punto condiciona la arquitectura desde el primer diseño, así que añadirlo después suele significar rehacer algo. Si tu caso justifica saltarse alguno, que sea una decisión escrita y no un olvido.

• Identidad en la consulta. La recuperación se filtra por los permisos de quien pregunta, antes de recuperar. El índice no es un atajo para saltarse el control de acceso.
• Trazabilidad completa. De cada respuesta queda registrada la pregunta, los fragmentos recuperados y la salida. Sin eso, un fallo no se puede investigar.
• Citas a nivel de fragmento. No basta con nombrar el documento: hay que poder abrir el trozo exacto y comprobarlo.
• Regla de abstención probada. Existe un umbral y una respuesta definida para cuando la evidencia no basta, y se ha probado con preguntas fuera del corpus.
• Reindexación y borrado verificados. Hay una frecuencia acordada por tipo de documento y una prueba de que retirar un documento lo retira también del índice.
• Aislamiento entre datos e instrucciones. El contenido recuperado se trata como datos. Un documento puede contener instrucciones escritas por alguien de fuera, y el sistema debe ignorarlas.
• Límites de gasto y de volumen. Activos, con aviso antes del límite.
• Punto de escalado dimensionado. Cuando el sistema no responde, hay una persona con tiempo asignado para atender ese caso.
• Conjunto de evaluación congelado. Preguntas reales con fuente correcta anotada, versionado, ejecutable antes de cada cambio.

La penúltima casilla se marca a veces sin haberla resuelto. «Con revisión humana» no es una casilla: es capacidad de un equipo que ya tiene trabajo. Dónde entra la persona y con cuánto tiempo se decide con el marco de impacto y reversibilidad.

Y si el sistema, además de responder, va a ejecutar algo —abrir un ticket, modificar un registro, enviar un correo— deja de ser RAG y pasa a ser otra cosa, con otra superficie de riesgo: dónde tienen sentido los agentes y dónde no.

Qué no te va a dar RAG

No arregla la documentación. Un corpus contradictorio produce un asistente contradictorio, con mejor redacción. No elimina los errores: cambia la naturaleza de una parte de ellos —donde antes había afirmaciones inventadas aparecen errores de recuperación, que al menos son investigables porque dejan rastro en la traza—, y no garantiza que desaparezcan los primeros. No sustituye una consulta a la base de datos cuando la pregunta es numérica. Y no convierte el conocimiento tácito —lo que la gente sabe y nadie ha escrito— en conocimiento consultable: eso primero hay que escribirlo.

Lo que sí da, bien montado, es una respuesta atribuible, un rastro que se puede auditar y una forma de que el conocimiento escrito de la empresa deje de depender de quién esté disponible esa tarde.

Siguiente paso

Si tienes el caso identificado y lo que falta es construirlo e integrarlo con tus sistemas, ese trabajo es Productos digitales. Si al mirar el corpus la conclusión es que el problema está antes —en las fuentes y las definiciones— se empieza por Datos e inteligencia. Cuéntanos tu reto.