Recuperación de generación aumentada (RAG) en Azure Databricks

Importante

Esta característica está en versión preliminar pública.

El marco del agente consta de un conjunto de herramientas en Databricks diseñadas para ayudar a los desarrolladores a crear, implementar y evaluar agentes de IA de calidad de producción, como aplicaciones de generación aumentada de recuperación (RAG).

En este artículo se describe qué es RAG y las ventajas de desarrollar aplicaciones RAG en Azure Databricks.

El marco del agente permite a los desarrolladores iterar rápidamente en todos los aspectos del desarrollo de RAG mediante un flujo de trabajo LLMOps de un extremo a otro.

Requisitos

• Las funciones de asistente de IA con tecnología de IA de Azure deben estar habilitadas para el área de trabajo.
• Todos los componentes de una aplicación agente deben estar en una sola área de trabajo. Por ejemplo, en el caso de una aplicación RAG, el modelo de servicio y la instancia de búsqueda vectorial deben estar en la misma área de trabajo.

¿Qué es RAG?

RAG es una técnica de diseño de IA generativa que mejora los modelos de lenguaje grandes (LLM) con conocimientos externos. Esta técnica mejora los LLM de las siguientes maneras:

• Conocimientos propietarios: RAG puede incluir información propietaria que no se usa inicialmente para entrenar el LLM, como las demostraciones, los correos electrónicos y los documentos para responder a preguntas específicas del dominio.
• Información actualizada: una aplicación RAG puede proporcionar al LLM información de orígenes de datos actualizados.
• Citar orígenes: RAG permite a los LLM citar fuentes específicas, lo que permite a los usuarios comprobar la precisión fáctica de las respuestas.
• Seguridad de datos y listas de control de acceso (ACL): el paso de recuperación se puede diseñar para recuperar de manera selectiva información personal o propietaria basada en las credenciales del usuario.

Sistemas compuestos de inteligencia artificial

Una aplicación RAG es un ejemplo de un sistema de inteligencia artificial compuesto: se expande en las funcionalidades de lenguaje del LLM al combinarla con otras herramientas y procedimientos.

En su forma más sencilla, una aplicación RAG hace lo siguiente:

1. Recuperación: la solicitud del usuario se usa para consultar un almacén de datos externo, como un almacén vectorial, una búsqueda de palabras clave de texto o una base de datos SQL. El objetivo es obtener datos auxiliares para la respuesta del LLM.
2. Aumento: los datos recuperados se combinan con la solicitud del usuario, a menudo mediante una plantilla con formato e instrucciones adicionales, para crear una indicación.
3. Generación: la indicación se pasa al LLM, que luego genera una respuesta a la consulta.

Datos RAG no estructurados frente a estructurados

La arquitectura RAG puede funcionar con datos auxiliares no estructurados o estructurados. Los datos que use con RAG dependen de su caso de uso.

Datos no estructurados: datos sin una estructura u organización específicas. Documentos que incluyen texto e imágenes o contenido multimedia, como audio o vídeos.

• PDF
• Documentos de Google/Office
• Wikis
• Imágenes
• Vídeos

Datos estructurados: datos tabulares organizados en filas y columnas con un esquema específico, como tablas de una base de datos.

• Registros de clientes en un sistema de BI o Almacenamiento de datos
• Datos de transacción de una base de datos SQL
• Datos de las API de aplicación (por ejemplo, SAP, Salesforce, etc.)

En las secciones siguientes se describe una aplicación RAG para datos no estructurados.

Canalización de datos RAG

La canalización de datos RAG realiza un procesamiento previo de los procesos e indexa documentos para una recuperación rápida y precisa.

En el diagrama siguiente se muestra una canalización de datos de ejemplo para un conjunto de datos no estructurado mediante un algoritmo de búsqueda semántica. Los trabajos de Databricks orquestan cada paso.

1. Ingesta de datos: ingiere datos del origen propietario. Almacene estos datos en una tabla Delta o en un volumen de Unity Catalog.
2. procesamiento de documentos: puede realizar estas tareas mediante trabajos de Databricks, cuadernos de Databricks y tablas dinámicas delta.
   • Analizar documentos sin procesar: transforme los datos sin procesar en un formato utilizable. Por ejemplo, extraer texto, tablas e imágenes de una colección de archivos PDF o usar técnicas de reconocimiento óptico de caracteres para extraer texto de imágenes.
   • Extraer metadatos: extraiga metadatos de documentos como títulos de documento, números de página y direcciones URL para ayudar a la consulta del paso de recuperación con mayor precisión.
   • Fragmentar documentos: divida los datos en fragmentos que se ajusten a la ventana de contexto de LLM. La recuperación de estos fragmentos centrados, en lugar de documentos completos, proporciona al LLM contenido más dirigido para generar respuestas.
3. Insertar fragmentos: un modelo de inserción consume los fragmentos para crear representaciones numéricas de la información denominada incrustaciones vectoriales. Los vectores representan el significado semántico del texto, no solo palabras clave de nivel de superficie. En este escenario, calculará las inserciones y usará Model Serving para atender el modelo de inserción.
4. Almacenamiento de las inserciones: almacene las inserciones vectoriales y el texto del fragmento en una tabla Delta sincronizada con el vector de búsqueda.
5. Base de datos vectorial: como parte del vector de búsqueda, las inserciones y los metadatos se indexan y almacenan en una base de datos vectorial para facilitar la consulta por parte del agente RAG. Cuando un usuario realiza una consulta, su solicitud se inserta en un vector. A continuación, la base de datos usa el índice vectorial para buscar y devolver los fragmentos más similares.

Cada paso implica decisiones de ingeniería que afectan a la calidad de la aplicación RAG. Por ejemplo, elegir el tamaño correcto del fragmento en el paso (3) garantiza que el LLM recibe información específica pero contextualizada, mientras que la selección de un modelo de inserción adecuado en el paso (4) determina la precisión de los fragmentos devueltos durante la recuperación.

Vector de búsqueda de Databricks

La similitud informática suele ser costosa a nivel computacional, pero los índices vectoriales como Databricks Vector Search optimizan esto mediante la organización eficaz de las inserciones. Los vectores de búsqueda clasifican rápidamente los resultados más relevantes sin comparar cada inserción con la consulta del usuario individualmente.

El vector de búsqueda sincroniza automáticamente las nuevas inserciones que se agregan a su tabla Delta y actualiza el índice de vectores de búsqueda.

¿Qué es un agente RAG?

Un agente de generación aumentada de recuperación (RAG) es una parte clave de una aplicación RAG que mejora las funcionalidades de los modelos de lenguaje grandes (LLM) mediante la integración de la recuperación de datos externos. El agente RAG procesa las consultas del usuario, recupera los datos pertinentes de una base de datos vectorial y pasa estos datos a un LLM para generar una respuesta.

Herramientas como LangChain o Pyfunc vinculan estos pasos mediante la conexión de sus entradas y salidas.

En el diagrama siguiente se muestra un agente RAG para un bot de chat y las características de Databricks que se usan para compilar cada agente.

1. Preprocesamiento de consultas: un usuario envía una consulta, que luego se preprocesa para que sea adecuada para consultar la base de datos vectorial. Esto puede implicar la colocación de la solicitud en una plantilla o la extracción de palabras clave.
2. Vectorización de consultas: use Model Serving para insertar la solicitud con el mismo modelo de inserción que se usa para insertar los fragmentos en la canalización de datos. Estas inserciones permiten comparar la similitud semántica entre la solicitud y los fragmentos preprocesados.
3. Fase de recuperación: el recuperador, una aplicación responsable de capturar información relevante, toma la consulta vectorizada y realiza una búsqueda de similitud vectorial mediante un vector de búsqueda. Los fragmentos de datos más relevantes se clasifican y recuperan en función de su similitud con la consulta.
4. Aumento de las indicaciones: el recuperador combina los fragmentos de datos recuperados con la consulta original para proporcionar contexto adicional al LLM. La solicitud está cuidadosamente estructurada para asegurarse de que el LLM comprende el contexto de la consulta. A menudo, el LLM tiene una plantilla para dar formato a la respuesta. Este proceso de ajuste de la indicación se conoce como ingeniería de indicaciones.
5. Fase de generación del LLM: el LLM genera una respuesta mediante la consulta aumentada enriquecida por los resultados de la recuperación. El LLM puede ser un modelo personalizado o un modelo fundacional.
6. Posprocesamiento: la respuesta del LLM se puede procesar para aplicar lógica de negocios adicional, agregar citas o refinar el texto generado en función de las reglas o restricciones predefinidas.

Se pueden aplicar varios límites de protección a lo largo de este proceso para garantizar el cumplimiento de las directivas empresariales. Esto puede implicar el filtrado de solicitudes adecuadas, la comprobación de los permisos de usuario antes de acceder a los orígenes de datos y el uso de técnicas de moderación de contenido en las respuestas generadas.

Desarrollo de agentes de RAG de nivel de producción

Iteración rápida en el desarrollo del agente mediante las siguientes características:

Cree y registre agentes mediante cualquier biblioteca y MLflow. Parametrice los agentes para experimentar e iterar rápidamente en el desarrollo del agente.

Implemente agentes en producción con compatibilidad nativa con el registro de solicitudes y respuestas y el streaming de tokens, además de una aplicación de revisión integrada para obtener comentarios de los usuarios sobre el agente.

El seguimiento del agente le permite registrar, analizar y comparar seguimientos en el código del agente para depurar y comprender cómo responde el agente a las solicitudes.

Evaluación y supervisión

La evaluación y la supervisión ayudan a determinar si la aplicación RAG cumple los requisitos de calidad, costo y latencia. La evaluación se produce durante el desarrollo, mientras que la supervisión se produce una vez que la aplicación se implementa en producción.

El RAG sobre datos no estructurados tiene muchos componentes que afectan a la calidad. Por ejemplo, los cambios en el formato de los datos pueden influir en los fragmentos recuperados y la capacidad del LLM para generar respuestas pertinentes. Por lo tanto, es importante evaluar los componentes individuales además de la aplicación general.

Para obtener más información, consulte ¿Qué es la evaluación del agente de Mosaic AI?.

Disponibilidad regional

Para más información sobre la disponibilidad regional del marco del agente, consulte Características con disponibilidad regional limitada