¿Qué es RAG? Retrieval-Augmented Generation explicada para la mediana empresa
RAG acopla un modelo de lenguaje a sus propios documentos, para que las respuestas se mantengan comprobables y actuales.
Traducción generada automáticamente con IA. La versión alemana es el original revisado por la redacción.
Retrieval-Augmented Generation, RAG para abreviar, conecta un modelo de lenguaje con una colección buscable de sus propios documentos. En lugar de generar la respuesta solo a partir del conocimiento de entrenamiento, el sistema busca primero los pasajes adecuados en sus datos y formula la respuesta a partir de ellos. Para la mediana empresa, es la vía más práctica para aplicar un modelo de lenguaje al conocimiento propio, sin volver a entrenar un modelo y sin que la documentación interna abandone la propia infraestructura.
Este artículo explica qué es RAG, cómo se estructura una pipeline, por qué el recuperador suele ser más importante que el tamaño del modelo y cuándo merece la pena el esfuerzo.
01. El problema que resuelve RAG
Un modelo de lenguaje general no conoce sus documentos internos. Fue entrenado con datos públicos y termina con una fecha de corte. Si un empleado pregunta por el acuerdo de suministro actual con un proveedor concreto, el modelo tiene dos posibilidades: dice que no conoce la respuesta, o se inventa una que suena plausible. La segunda posibilidad es la peligrosa.
RAG cierra esa brecha. Antes de cada respuesta, el sistema busca en sus propias fuentes, por ejemplo contratos, manuales, tickets o una wiki, y entrega los pasajes relevantes al modelo. El modelo formula entonces una respuesta que se basa en esos pasajes concretos y puede citarlos. De un modelo que tiene que adivinar surge un sistema que consulta. El resto del valor de negocio lo describimos en Descubra el potencial de la IA en la empresa.
02. Cómo funciona una pipeline de RAG
Una pipeline de RAG consta de cinco pasos que se pueden separar con nitidez unos de otros.
- Indexación. Sus documentos se descomponen en pequeños pasajes y se traducen a vectores numéricos que representan su significado. Estos vectores residen en una base de datos vectorial.
- Recuperación. Ante una pregunta, el sistema calcula el vector correspondiente y extrae de la base de datos los pasajes más similares. Aquí se decide la calidad de la respuesta posterior.
- Aumentación. Los pasajes encontrados se colocan junto con la pregunta en el prompt del modelo.
- Generación. El modelo formula la respuesta a partir del contexto suministrado, no de su memoria.
- Cita de fuentes. El sistema nombra los documentos de los que procede la respuesta, de modo que una persona pueda comprobarla.
Importante es el tercer punto de la separación: puede intercambiar el modelo sin volver a preparar sus datos, y puede actualizar sus datos sin tocar el modelo.
03. Por qué el recuperador suele ser más importante que el tamaño del modelo
En la práctica, la mayor parte de la energía fluye hacia la elección del modelo. Según nuestra experiencia, la palanca está más a menudo en el retrieval. Hemos planteado la misma pregunta especializada contra un gran modelo alojado y contra un modelo local más pequeño con un recuperador cuidadosamente ajustado. Con preguntas inequívocas, ambos quedaron a la par. En los casos ambiguos, es decir, la minoría que realmente cuenta, la calidad del retrieval decidió la respuesta útil, no el tamaño del modelo.
La razón es sencilla: un modelo más grande solo formula una respuesta equivocada con más elocuencia si le falta el pasaje correcto. Un recuperador bien ajustado, en cambio, aporta el pasaje adecuado, y entonces basta un modelo más pequeño. La misma observación ya la describimos con más detalle en nuestro artículo anterior sobre Retrieval-Augmented Generation.
04. RAG, protección de datos y el caso On-Premise
RAG encaja bien con una arquitectura consciente de la protección de datos, porque todos los componentes pueden operarse en casa. El recuperador, la base de datos vectorial y el modelo pueden funcionar on-prem, de modo que ni la pregunta ni los documentos encontrados van a un servicio externo. Para empresas que trabajan con datos personales, contratos o documentación de diseño, esa es a menudo la condición para que un proyecto siquiera arranque.
Qué modelo es apto para la operación local y con qué hardware lo tratamos en LLM local en la empresa: hardware, costes, realidad. La comparación fundamental entre operación local y nube está en On-Premise vs. LLM en la nube: cuándo la IA local es la elección correcta.
05. Cuándo merece la pena RAG y cuándo no
RAG merece la pena cuando su conocimiento reside en documentos, cambia con regularidad y es consultado por muchas personas. Casos típicos son las bases de conocimiento internas, el soporte, la revisión de ofertas y la búsqueda en documentación técnica.
RAG merece menos la pena cuando la respuesta es un cálculo exacto a partir de una base de datos, pues para eso una consulta clásica es más precisa. Tampoco sustituye un mantenimiento limpio de los datos: si los documentos de origen son contradictorios o están obsoletos, incluso un buen retrieval entrega respuestas contradictorias. Por eso, el primer paso de un proyecto de RAG suele ser la revisión honesta del conocimiento existente, no la elección del modelo.
