¿Qué es la generación aumentada por recuperación (RAG)?

La generación aumentada de recuperación proporciona datos contextuales y actualizados para que los LLM sean útiles.

La generación aumentada de recuperación es una técnica que aborda las limitaciones de los LLM, al porporcionarles acceso a datos contextuales y actualizados. Las implementaciones RAG, a veces conocidas como modelos o patrones RAG, funcionan combinando una LLM previamente entrenada con un sistema de recuperación de información de fácil acceso. El sistema de recuperación es responsable de encontrar información relevante en una biblioteca de conocimientos, como una base de datos. Los modelos RAG permiten que el LLM, o modelo de base, genere una respuesta más precisa con un contexto actualizado y relevante para la tarea en cuestión.

Los modelos RAG han demostrado su eficacia en diversas tareas intensivas de conocimiento, entre ellas:

• Tareas de generación de lenguaje, como responder a preguntas de forma exhaustiva e informativa, o generar distintos formatos creativos de contenido textual, como poemas, guiones, piezas musicales, correo electrónico, cartas, etc.
• Tareas de PNL, como proporcionar resúmenes de conversaciones, grabaciones de audio y videollamadas.
• Tareas que requieren clasificación, como la ciberseguridad y el cumplimiento o el razonamiento para cosas como la planificación empresarial

La generación aumentada de recuperación también se puede utilizar para permitir que una aplicación impulsada por AI generativa observe algún estado de fondo y adapte sus generaciones en consecuencia. Un ejemplo sería la capacidad de escribir código basado en el código que está escribiendo un usuario. Otros ejemplos incluyen:

• Contexto de aplicación. Supongamos que está creando un asistente de Excel impulsado por IA: le sería útil saber los nombres de sus hojas, nombre de archivo, rangos de celdas seleccionados, etc. RAG provee esta "información de actividad de fondo" en el aviso para que el LLM pueda adaptar su ayuda a su hoja.
• Datos personales (p. ej. chatbot de asistencia al agente). Supongamos que está creando un bot de atención al cliente. El bot puede extraer conversaciones anteriores y el historial de CRM de ese cliente específico para ayudar a adaptar la conversación (no solo saludar, sino personalizar las opciones, etc.). Sin este historial, el LLM no podrá realizar la personalización de manera efectiva ni ayudar con los problemas existentes.
• Números brutos, métricas, datos tabulares (p. ej. CSV, Parquet, JSON, etc.). RAG no se limita a trabajar con contexto textual, sino también con información cuantitativa. Un chatbot de business intelligence (BI) sin duda estaría haciendo RAG con datos tabulares brutos.
• Otros tipos de datos multimodales como imágenes, video y audio. Muchos modelos, como DALL-E 2, pueden aprovechar el texto para crear o aumentar imágenes. Por el contrario, pueden sintetizar imágenes o videos en lenguaje natural. Al tener contexto para ciertas imágenes o factores de forma de diseño, RAG puede hacer que las aplicaciones de IA generativa sean más potentes a la hora de crear activos de marketing o generar resúmenes y traducciones de vídeos que contienen información muy específica y contextualizada.

La generación aumentada de recuperación también es útil para los datos que no se pueden incorporar como datos de entrenamiento

• Datos altamente volátiles/sensibles al tiempo: los datos como las noticias del mercado de valores se vuelven obsoletos rápidamente. Por lo tanto, tiene más sentido mejorar el LLM sólo con la información más reciente, idealmente en cada solicitud durante el tiempo de inferencia, en lugar de intentar volver a entrenar los LLM con este corpus.
• Datos sensibles: muchos de los LLM de mayor rendimiento (como GPT de OpenAI o Claude de Anthropic) se pagar para usar y son propiedad de esas empresas. El uso de información personal y sensible de los datos de entrenamiento para mejorar esos LLMS puede conducir a la filtración de datos privados y es potencialmente peligroso. Por lo tanto, a veces RAG es la única opción segura.

Casos de uso principales de RAG.

De acuerdo a lo anterior, los casos de uso más adecuados de RAG incluyen:

• Respuesta a preguntas sobre cualquier conocimiento de dominio extrínseco, como documentación y bases de conocimiento específicas de la empresa, sistemas operativos en vivo, sistemas de back office, etc.: por definición, el uso de LLM con cualquier dato fuera del límite de conocimiento de LLM requiere de la RAG. Además, las preguntas y respuestas sobre contextos muy sensibles al tiempo y que cambian con rapidez, datos que se desactualizan rápidamente, son imposibles de integrar en los LLM mediante un ajuste fino.
• Para reducir las alucinaciones y aumentar la precisión basada en los hechos: en términos generales, la RAG puede mejorar la precisión basada en hechos incluso para responder a preguntas sobre información contenida en el corpus de entrenamiento del LLM. Esto se debe a que la RAG convierte la tarea de responder preguntas en una tarea de "cuestionario de libro abierto", que es más fácil que la tarea de responder preguntas sin límites.
• La personalización es un caso de uso canónico para RAG. En esta situación, el mensaje se aumenta con datos de usuario. Opcionalmente, cualquier dato PII se puede borrar antes de insertarlo en el mensaje.
• Proporcionar respuestas contextuales (dentro de Copilot). Como demuestra el copiloto de Github, las generaciones de LLM pueden ser más relevantes cuando se basan en el estado de la aplicación (el documento actual, los metadatos generales del proyecto, qué URL o página se está visitando actualmente, etc.)
• Cualquier aplicación de IA generativa que funcione con contextos altamente específicos de dominio. Entre los ejemplos se incluyen atención médica, servicios financieros, descubrimiento legal, ciencia e ingeniería. En este tipo de dominios, los datos de entrenamiento suelen ser escasos, por lo que RAG es esencial para crear aplicaciones útiles de IA generativa.

¿Por qué generación aumentada de recuperación? ¿Cuáles son las alternativas a RAG cuando hablamos de crear aplicaciones de IA generativa?

Hay varias alternativas a RAG para crear aplicaciones de IA generativa. Algunas de las alternativas más populares son:

• Entrena tu propio LLM: aunque podría justificarse que entrene su propio LLM, es probable que sea demasiado caro y le lleve demasiado tiempo crear algo competitivo con tantos modelos comerciales (GPT de OpenAI) y de código abierto (LLaMa de Meta) disponibles.
• Ajuste fino de un LLM existente: una técnica en la que un LLM preentrenado se vuelve a entrenar en un conjunto de datos más pequeño de datos específicos de la tarea. El ajuste puede ser eficaz para mejorar el rendimiento de un LLM en una tarea específica, pero también puede llevar mucho tiempo y resultar caro. El ajuste nunca termina: a medida que aparecen nuevos datos, el modelo debe ajustarse nuevamente. Cuando su aplicación de IA generativa requiere acceso a datos operativos en vivo, el ajuste no funcionará para usted.

¡Por qué la generación aumentada de recuperaciñon supera el ajusto de un LLM?

• El ajuste es otra forma de usar los LLM con "datos de clientes", pero a diferencia de RAG que es como darle un cuestionario de libro abierto al LLM, el ajuste es como si le diera memorias completamente nuevas, como una especie de lobotomía. El ajuste adapta el modelo para que pueda cambiar su rendimiento, comportamiento, perfil de costos, etc. Es un proceso que requiere mucho tiempo y recursos y, por lo general, no es viable para basar los LLM en un contexto específico.

Los componentes básicos de una arquitectura RAG básica.

Una arquitectura básica de generación aumentada de recuperación consta de tres componentes principales:

• Un LLM pre-entrenado: el LLM es responsable de generar texto, imágenes, audio y video.
• Búsqueda vectorial (o búsqueda semántica): el sistema de recuperación se encarga de encontrar información relevante de una base de conocimiento externa al LLM. Existe una gran variedad de bases de datos de propósito general o bases de datos vectoriales de propósito único entre las que elegir y que pueden almacenar incrustaciones vectoriales y ejecutar consultas de búsqueda aproximada de vecinos más cercanos contra ellas. La búsqueda de vectores es fundamental para poder aumentar con precisión el conocimiento propio proporcionado a un LLM de propósito general.
• Incrustaciones de vectores: a veces denominadas simplemente "vectores" o "incrustaciones", las incrustaciones de vectores son esencialmente representaciones numéricas que capturan el significado semántico o subyacente de un dato. En términos generales, son una matriz de flotantes, donde cada flotante representa una sola dimensión de las representaciones numéricas.
• Orquestación: El mecanismo de fusión se encarga de combinar la salida del LLM con la información del sistema de recuperación para generar la salida final.

El siguiente diagrama muestra una arquitectura RAG básica con el mismo ejemplo de venta minorista que antes:

Como solución a esta falta de contexto específico del dominio, la generación aumentada de recuperación se realiza de la siguiente manera:

• Obtenemos las descripciones de producto más relevantes de una base de datos (a menudo una base de datos con búsqueda vectorial) que contiene el catálogo de productos más reciente
• A continuación, insertamos (aumentamos) estas descripciones en la consulta del LLM
• Por último, ordenamos al LLM que "haga referencia" a esta información de producto actualizada al responder a la pregunta

Tres cosas a tener en cuenta de lo anterior:

• La generación aumentada por recuperación es una técnica puramente de tiempo de inferencia (no requiere reentrenamiento). Los pasos 1-3 anteriores se realizan en tiempo de inferencia. No se requieren cambios en el modelo (p. ej. modificar los pesos del modelo).
• La generación aumentada de recuperación es muy adecuada para personalizaciones en tiempo real de generaciones de LLM. Como no hay que reentrenar y todo se hace mediante aprendizaje en contexto, la inferencia basada en RAG es rápida (latencia inferior a 100 m) y muy adecuada para su uso en aplicaciones operativas en tiempo real.
• La generación aumentada de recuperación hace que las generaciones LLM sean más precisas y útiles. Cada vez que cambie el contexto, el LLM generará una respuesta diferente. Por lo tanto, RAG hace que las generaciones LLM dependan de cualquier contexto que se haya recuperado.

Hacer que RAG sea simple con una complejidad mínima, pero sofisticada para funcionar de manera confiable a escala.

Para lograr una arquitectura RAG eficaz pero mínimamente compleja, hay que empezar por elegir los sistemas adecuados. A la hora de elegir los sistemas, o tecnologías, para la implantación de una RAG, es importante elegir sistemas, o un sistema, que pueda lograr lo siguiente:

• soportar los nuevos requisitos de datos vectoriales sin añadir una enorme expansión, costo y complejidad a sus operaciones de TI.
• Asegúrese de que las experiencias de IA generativa creadas tengan acceso a datos en vivo con una latencia mínima.
• Tener la flexibilidad para adaptarse a nuevos requisitos de datos y aplicaciones y permitir que los equipos de desarrollo se mantengan ágiles mientras lo hacen.
• Equipar mejor a los equipos de desarrollo para llevar todo el ecosistema de IA a sus datos, no al revés.

Las opciones van desde bases de datos vectoriales de un solo propósito hasta bases de datos documentales y relacionales con capacidades vectoriales nativas, y almacenes de datos y lakehouses. Sin embargo, las bases de datos vectoriales de propósito único añadirán dispersión y complejidad de inmediato. Los almacenes de datos y los lakehouses están diseñados inherentemente para consultas de tipo analítico de larga duración sobre datos históricos, a diferencia de los requisitos de alto volumen, baja latencia y datos frescos de las aplicaciones de IA generativa que impulsa RAG. Además, las bases de datos relacionales aportan esquemas rígidos que limitan la flexibilidad de agregar nuevos datos y requisitos de aplicaciones fácilmente. Quedan las bases de datos de documentos con funciones vectoriales nativas o integradas. En particular, MongoDB se basa en el modelo de documento flexible y tiene búsqueda vectorial nativa, lo que la convierte en una base de datos vectorial para RAG, además de la base de datos líder en la industria para cualquier aplicación moderna.

Cómo llevar la potencia de las LLM al siguiente nivel con capacidades adicionales en su implementación de RAG.

Además de los componentes centrales, hay varias capacidades adicionales que se pueden agregar a una implementación RAG para llevar el poder de LLM al siguiente nivel. Algunas de estas capacidades adicionales son:

• Multimodalidad: los modelos RAG multimodales pueden generar texto basado en datos textuales y no textuales, como imágenes, vídeos y audio. Estos datos multimodales almacenados junto a los datos operativos en tiempo real facilitan el diseño y el manejo de la implementation de RAG.
• Definición de filtros adicionales en la consulta de búsqueda vectorial: la capacidad de agregar búsqueda de palabras clave, búsqueda geoespacial y filtros de punto y rango en la misma consulta vectorial puede aportar precisión y velocidad al contexto proporcionado al LLM.
• Especificidad de dominio: los modelos RAG específicos de un dominio pueden entrenarse con datos de un dominio concreto, como la salud o las finanzas. Esto permite que el modelo RAG genere texto más preciso y relevante para ese dominio.

Cómo garantizar que su aplicación basada en IA generativa sea segura, eficiente, fiable y escalable cuando se globalice.

Hay una serie de cosas que se pueden hacer para garantizar que una aplicación impulsada por GenAI y construida con una RAG sea segura, eficiente, fiable y escalable cuando se globalice. Algunas de estas cosas son:

• Utilizar una plataforma que sea segura y tenga las capacidades adecuadas de manejo de datos: el manejo de datos es un término amplio que abarca todo lo que se hace para garantizar que los datos sean seguros, privados, precisos, disponibles y utilizables. Incluye los procesos, las políticas, las medidas, la tecnología, las herramientas y los controles en torno al ciclo de vida de los datos. Así pues, la plataforma debe ser segura por defecto, disponer de cifrado de extremo a extremo y haber alcanzado los niveles más altos de cumplimiento.
• Utilizar una plataforma basada en la cloud: además de las características de seguridad y escalabilidad que ofrecen las plataformas basadas en la cloud, los principales proveedores de cloud son algunos de los principales innovadores para la infraestructura de IA. La elección de una plataforma que sea independiente de la cloud permite a los equipos aprovechar las innovaciones de IA dondequiera que lleguen.
• Utilizar una plataforma que pueda aislar la infraestructura de la carga de trabajo vectorial de otra infraestructura de base de datos: es importante que las cargas de trabajo OLTP normales y las cargas de trabajo vectoriales no compartan infraestructura para que las dos cargas de trabajo puedan ejecutarse en hardware optimizado para cada una y para que no compitan por los recursos sin dejar de aprovechar los mismos datos.
• Utilizar una plataforma que haya demostrado su eficacia a gran escala: una cosa es que un proveedor diga que puede escalar, pero ¿tiene un historial y una trayectoria con clientes empresariales globales? ¿Tiene tolerancia a fallas críticas y capacidad de escalar horizontalmente, y puede demostrarlo con ejemplos de clientes?

Siguiendo estos consejos, es posible crear aplicaciones impulsadas por IA generativa con arquitecturas RAG que sean seguras, eficientes, confiables y escalables.

Con la introducción de Atlas Vector Search, La plataforma de datos para desarrolladores líder de MongoDB proporciona a los equipos una base de datos vectorial que permite crear arquitecturas RAG sofisticadas y de alto rendimiento que pueden funcionar a escala. Todo ello manteniendo los más altos niveles de seguridad y agnosticismo de la cloud y, lo que es más importante, sin agregar complejidad ni costos innecesarios.