RAG explicado sin humo: responder con tus documentos sin reentrenar nada

RAG es la respuesta corta a una pregunta que nos hacen casi todas las semanas: «queremos que la IA conozca nuestros documentos, ¿hay que entrenarla con ellos?». No. En el 95 % de los casos que vemos en empresa, la solución no es entrenar nada, sino recuperar el fragmento correcto y dárselo al modelo en el momento de responder. Eso es RAG —retrieval-augmented generation, generación aumentada por recuperación— y la diferencia entre entenderlo o no entenderlo son meses de presupuesto.

Esta guía explica qué es RAG sin metáforas de conferencia: qué hace cada pieza, cuándo conviene frente a las alternativas, cómo se mide que la respuesta es buena, qué cuesta mantenerlo y por qué la mayoría de los proyectos de RAG que no llegan a producción fallan en un sitio que no tiene nada que ver con la inteligencia artificial.

¿Qué es RAG y en qué se diferencia de entrenar un modelo?

Un modelo de lenguaje sabe lo que aprendió cuando lo entrenaron. No sabe tu convenio, tu tarifa de 2026 ni la cláusula de penalización que firmaste el martes. Hay tres formas de meterle ese conocimiento y solo una es razonable para la mayoría de empresas:

• Reentrenar o ajustar el modelo (fine-tuning). Coges el modelo y le ajustas los pesos con tus datos. Caro, lento y —aquí está el malentendido— no sirve para memorizar hechos. Sirve para cambiar el estilo, el formato de salida o el comportamiento. Si ajustas un modelo con tus 4.000 contratos y luego cambias una cláusula, tienes que volver a ajustarlo.
• Meter todo el documento en la pregunta. Funciona con un documento. Con 4.000 es inviable por coste y porque la calidad cae cuando el modelo recibe cien páginas donde el dato relevante son tres líneas.
• RAG. Para cada pregunta, un buscador selecciona los pocos fragmentos que contienen la respuesta y el modelo redacta usando solo eso, citando de dónde sale cada afirmación.

La consecuencia práctica de RAG es que el conocimiento vive fuera del modelo. Cambias un PDF, reindexas, y la respuesta cambia esa misma tarde sin tocar nada más. También significa algo menos cómodo: si el buscador no encuentra el párrafo correcto, no hay modelo que arregle la respuesta. El cuello de botella casi nunca es el generador.

RAG no hace que la IA «sepa» de tu empresa. Hace que la IA lea lo correcto justo antes de contestar. Todo el trabajo está en el «lo correcto».

¿Cuándo conviene RAG y cuándo es la herramienta equivocada?

RAG encaja cuando la respuesta está escrita en algún sitio, cambia con el tiempo y hay que poder justificarla. No encaja cuando el dato está en tablas o cuando lo que quieres es que el modelo escriba distinto.

| Necesidad | Lo que conviene | Por qué | |---|---|---| | Responder sobre normativa, contratos o manuales propios | RAG | El dato cambia y hay que citar la fuente | | Que el modelo escriba con el tono y el formato de la casa | Ajuste fino o instrucciones | Es comportamiento, no conocimiento | | «¿Cuántos pedidos vencen este mes?» | Consulta a base de datos / cuadro de mando | Es agregación, no documento | | Un único documento largo por conversación | Mandarlo entero en la pregunta | Montar un índice para un PDF es sobreingeniería | | Extraer campos de facturas o albaranes | Extracción de documentos | Es un problema de lectura estructurada, no de búsqueda | | Que el sistema además ejecute acciones (crear ticket, consultar ERP) | Agente con RAG como una de sus herramientas | RAG solo responde; no hace |

Dos avisos de obra. El primero: mucha gente pide RAG cuando lo que necesita es orden documental. Si hay tres versiones vivas de la misma política y nadie sabe cuál manda, RAG te dará una de las tres con total aplomo. El segundo: RAG y agentes no compiten. En los proyectos que llegan a producción, la recuperación es una herramienta más que el agente invoca cuando hace falta consultar la documentación, y no el centro de la arquitectura.

¿Qué piezas lleva dentro un RAG en producción?

Seis etapas, cada una con su forma propia de estropear la respuesta final. El usuario solo ve el resultado combinado, así que conviene saber dónde mirar cuando algo sale mal.

| Etapa | Qué hace | Dónde se pierde la calidad | |---|---|---| | Ingesta | Recoge ficheros del gestor documental, las carpetas o el correo | Entran borradores, copias y versiones derogadas | | Extracción | Convierte PDF, Word o escaneos en texto | Tablas que se deshacen, columnas mezcladas, OCR sin revisar | | Troceado | Parte el documento en fragmentos indexables | Cortes a mitad de cláusula que separan la condición de su excepción | | Indexado | Crea el índice semántico y el de palabra exacta | Solo semántico: falla con códigos, referencias y nombres propios | | Recuperación | Elige los fragmentos candidatos para cada pregunta | Cinco fragmentos casi idénticos del mismo documento irrelevante | | Generación | Redacta citando las fuentes recuperadas | Rellena huecos con lenguaje plausible cuando no ha recuperado lo necesario |

Tres decisiones concretas mueven más la aguja que elegir modelo:

• Trocear respetando la estructura. Partir cada 500 caracteres funciona en una wiki y destroza un contrato. Si el documento tiene título, artículo y apartado, arrastra ese contexto en cada fragmento: la respuesta pasa de «el plazo es de 30 días» a «el artículo 7.2 del contrato marco fija 30 días, salvo la excepción del 7.3».
• Búsqueda híbrida, no solo vectores. La búsqueda semántica encuentra «periodo de subsanación» cuando preguntas por «plazo de garantía». La búsqueda por palabra exacta es la única que encuentra el expediente `EXP-2026-0431`. Necesitas las dos y una reordenación posterior que elija entre lo que devuelven ambas.
• Metadatos y filtros antes de buscar. Fecha de vigencia, versión, sociedad, departamento y estado (vigente/derogado). Sin ellos, el sistema compite consigo mismo entre cinco versiones del mismo documento y gana la que más se parece literalmente a la pregunta, que casi nunca es la vigente.

Y una regla de seguridad que no es opcional: los permisos se aplican en la recuperación, no en la respuesta. Cada usuario solo puede recuperar fragmentos de documentos a los que ya tenía acceso. Filtrar después de generar es tarde: el texto ya se ha construido con información que esa persona no debía ver.

¿Cómo se evalúa que la respuesta de un RAG es buena?

Aquí se separan los pilotos que llegan a producción de los que se quedan en demo de comité. Evaluar no es preguntarle tres cosas y decir «responde bastante bien». Es montar un conjunto de preguntas de referencia con respuesta conocida y ejecutarlo entero cada vez que se toca algo.

Cómo se construye, con esfuerzo realista: reúne entre 50 y 150 preguntas reales —salen de los tickets de soporte interno y de lo que pregunta la gente nueva, no de una sala de reuniones—, anota para cada una la respuesta correcta y el documento y apartado exactos donde está, e incluye a propósito 10-15 preguntas trampa: cosas que no están en ningún documento y preguntas cuya respuesta cambió el año pasado.

| Métrica | Qué mide | Umbral orientativo | |---|---|---| | Acierto de recuperación | % de preguntas cuyo fragmento correcto está entre los recuperados | > 90 % antes de mirar nada más | | Fidelidad a la fuente | % de afirmaciones respaldadas por el fragmento citado | > 95 % | | Respuesta correcta | % de respuestas que un experto da por buenas | > 85 % para abrir a usuarios | | Abstención correcta | % de preguntas sin respuesta en el corpus donde el sistema dice «no lo sé» | > 90 % | | Frescura | % de respuestas que citan la versión vigente | 100 % en documentos normativos |

El orden importa. Si el acierto de recuperación está en el 60 %, cambiar de modelo generador es perder el tiempo y dinero. Y la abstención correcta es la métrica que más se ignora: un sistema que admite no saber el 10 % de las veces es utilizable; uno que nunca lo admite es peligroso, porque el usuario no tiene forma de distinguir la respuesta buena de la inventada. Si quieres profundizar en el producto final que sale de todo esto, lo desarrollamos en buscador interno de documentos.

¿Qué cuesta de verdad montar y mantener un RAG?

Sin cifras de catálogo, porque dependen del proveedor y del volumen, pero sí con la estructura de coste real, que es lo que suele faltar en los presupuestos que nos traen para contrastar:

• Indexar es un coste puntual y pequeño. Convertir y vectorizar unos miles de documentos cuesta poco y se hace una vez.
• Consultar es el coste recurrente. Lo marcan el número de preguntas al día y cuánto texto se le pasa al modelo en cada una. Recuperar diez fragmentos en lugar de tres multiplica la factura y casi nunca mejora la respuesta.
• El almacenamiento del índice es menor de lo que se teme, salvo con corpus muy grandes o con reindexados completos frecuentes.
• Lo que de verdad se desvía son las horas de limpieza. Marcar vigencia, decidir qué entra y qué no, arreglar extracciones de tablas. En los proyectos que hemos visto, este trabajo previo ocupa más tiempo que el desarrollo del sistema.
• Y el mantenimiento vivo. Alguien tiene que revisar el registro de fallos, reindexar lo que cambia y repasar el conjunto de evaluación cada trimestre. Es la parte de MLOps que casi nadie presupuesta y la que decide si el sistema sigue siendo fiable en el mes nueve.

El marco general para pedir presupuestos comparables está en qué cuesta un proyecto de IA. Para RAG, la pregunta que más información da a un proveedor es sencilla: «¿cómo vas a medir el acierto de recuperación y con qué conjunto de preguntas?». Si no hay respuesta clara, lo que te están vendiendo es una demo.

¿Por qué fallan la mayoría de los RAG antes de llegar a producción?

Porque el sistema hereda el desorden del repositorio y lo sirve con aspecto de autoridad. Los patrones que más veces se repiten:

1. Alcance por volumen en vez de por valor. «Indexamos todo el disco de red» garantiza ruido y garantiza un incidente de permisos. Un dominio, un departamento, unos cientos de documentos bien elegidos: eso es un primer caso. 2. Sin dueño documental. Si nadie responde de que un procedimiento está al día, el PDF correcto en 2022 y nunca revisado es información falsa con formato de información buena. Es calidad de datos aplicada al documento. 3. Sin citas visibles. La cita clicable no es un adorno: es lo que permite verificar en cinco segundos y lo que hace que el sistema se gane la confianza. Sin ella, el usuario no puede más que creer o desconfiar. 4. Sin canal de fallo. Un botón de «esta respuesta está mal» que registre la pregunta, la respuesta y los fragmentos recuperados. Sin ese registro no hay mejora posible, solo opiniones. Es el mismo mecanismo que separa los pilotos vivos de los muertos en por qué fracasan los pilotos de IA. 5. Sin decidir dónde se procesa el dato. Si vas a indexar expedientes, nóminas o historiales, hay que fijar antes dónde se procesa, qué se registra de cada consulta y qué base legal ampara el tratamiento. Está desarrollado en RGPD e IA.

Una ruta de arranque que hemos visto funcionar, sin equipo dedicado a tiempo completo:

| Semanas | Qué se hace | Entregable | |---|---|---| | 1-2 | Elegir un dominio con dolor real y dueño identificable | Alcance escrito: qué carpetas entran y cuáles no | | 3-4 | Construir el conjunto de preguntas de referencia | 50-150 preguntas con documento y apartado | | 5-6 | Ingesta, extracción y troceado respetando estructura | Índice medido con esas preguntas | | 7-8 | Recuperación híbrida, filtros por metadato y reordenación | Acierto de recuperación por encima del 90 % | | 9-10 | Generación con cita obligatoria y abstención permitida | Respuestas trazables al párrafo | | 11-12 | Piloto con 10-15 usuarios y registro de fallos | Decisión con datos: ampliar, ajustar o parar |

Preguntas frecuentes

¿RAG elimina las respuestas inventadas?

Las reduce mucho y las hace detectables, pero no las elimina. Si el sistema no recupera el fragmento adecuado y no está configurado para abstenerse, rellenará el hueco con lenguaje plausible. Se mitiga con tres medidas combinadas: cita obligatoria para cada afirmación, permiso explícito para decir «no encuentro esto» y medición de la abstención correcta en el conjunto de referencia.

¿Cuántos documentos hacen falta para que merezca la pena?

Menos de los que la gente imagina. Con 200 o 300 documentos consultados a diario por varias personas ya hay caso: el valor lo da la frecuencia de consulta y el coste de no encontrar, no el tamaño del archivo. El límite práctico es el contrario: indexar cien mil documentos sin metadatos de vigencia produce un sistema rápido y poco fiable.

¿Salen mis documentos de la empresa?

Depende de la arquitectura, y es una decisión de negocio antes que técnica. Se puede montar con proveedores que no retienen datos, en nube europea con acuerdo de tratamiento firmado, o en infraestructura propia con modelos abiertos —más control, más coste y más mantenimiento—. Lo que no es aceptable es no saber la respuesta: pregúntala por escrito antes de subir un solo fichero.

¿Hace falta ajustar el modelo además de montar RAG?

Casi nunca al principio. El ajuste fino tiene sentido cuando el problema es el formato o el tono de salida y ya has agotado las instrucciones, no cuando el problema es que el sistema no conoce un dato. Empieza por RAG, mide, y si el fallo persiste después de tener el acierto de recuperación por encima del 90 %, entonces plantéate tocar el modelo.

Si estás valorando un RAG sobre tus documentos, el primer paso útil no es una prueba de concepto con tres PDF: es mirar un dominio real y contar cuántas versiones conviven, cuántos documentos llevan fecha de vigencia y cuánto tarda hoy una persona en encontrar una respuesta. Eso es la auditoría, y sale con una estimación honesta del trabajo previo que hay antes de que la recuperación aporte algo. Si prefieres contrastarlo en media hora, hablemos y te decimos con franqueza si tu caso es de RAG, de orden documental o de las dos cosas en ese orden.