Potenciando asistentes inteligentes de documentos basados en RAG utilizando extracción de entidades, consultas SQL y agentes con Amazon Bedrock

Optimizando asistentes inteligentes de documentos basados en RAG con extracción de entidades, consultas SQL y agentes con Amazon Bedrock

La Inteligencia Artificial Conversacional ha avanzado mucho en los últimos años gracias a los desarrollos rápidos en IA generativa, especialmente en las mejoras de rendimiento de los grandes modelos de lenguaje (LLMs) introducidos por técnicas de entrenamiento como el ajuste fino de instrucciones y el aprendizaje por refuerzo a través de retroalimentación humana. Cuando se les da una indicación correcta, estos modelos pueden llevar a cabo conversaciones coherentes sin necesidad de datos de entrenamiento específicos de una tarea. Sin embargo, no pueden generalizar bien a preguntas específicas de una empresa debido a que, para generar una respuesta, se basan en los datos públicos a los que fueron expuestos durante el pre-entrenamiento. Estos datos a menudo carecen del conocimiento especializado contenido en los documentos internos disponibles en las empresas modernas, que normalmente se necesita para obtener respuestas precisas en dominios como la investigación farmacéutica, la investigación financiera y el soporte al cliente.

Para crear asistentes de IA capaces de tener conversaciones fundamentadas en conocimientos especializados de la empresa, necesitamos conectar estos LLMs potentes pero genéricos a bases de conocimiento internas de documentos. Este método de enriquecer el contexto generativo de los LLMs con información recuperada de sus fuentes de datos internos se llama Generación Aumentada por Recuperación (RAG), y produce asistentes que son específicos de un dominio y más confiables, como se muestra en Generación Aumentada por Recuperación para Tareas de Procesamiento de Lenguaje Natural con Alto Conocimiento. Otra razón por la cual RAG se ha vuelto popular es su facilidad de implementación y la existencia de soluciones de búsqueda vectorial maduras, como las ofrecidas por Amazon Kendra (ver Amazon Kendra lanza la API de Recuperación) y Amazon OpenSearch Service (ver Búsqueda de Vecino más Cercano (k-NN) en Amazon OpenSearch Service), entre otros.

Sin embargo, el popular diseño RAG con búsqueda semántica no puede responder a todos los tipos de preguntas que son posibles sobre los documentos. Esto es especialmente cierto para las preguntas que requieren razonamiento analítico a través de varios documentos. Por ejemplo, imagina que estás planeando la estrategia del próximo año para una empresa de inversiones. Un paso esencial sería analizar y comparar los resultados financieros y los riesgos potenciales de las empresas candidatas. Esta tarea implica responder a preguntas de razonamiento analítico. Por ejemplo, la consulta “Dame las 5 principales empresas con mayores ingresos en los últimos 2 años e identifica sus principales riesgos” requiere múltiples pasos de razonamiento, algunos de los cuales pueden utilizar la recuperación de búsqueda semántica, mientras que otros requieren capacidades analíticas.

En esta publicación, mostramos cómo diseñar un asistente inteligente de documentos capaz de responder preguntas de razonamiento analítico y de múltiples pasos en tres partes. En la Parte 1, revisamos el diseño RAG y sus limitaciones en preguntas analíticas. Luego te presentamos una arquitectura más versátil que supera estas limitaciones. La Parte 2 te ayuda a adentrarte en la pipeline de extracción de entidades utilizada para preparar los datos estructurados, que es un componente clave para responder preguntas analíticas. La Parte 3 te guía en cómo utilizar Amazon Bedrock LLMs para consultar esos datos y construir un agente LLM que mejora RAG con capacidades analíticas, permitiéndote construir asistentes inteligentes de documentos capaces de responder preguntas complejas y específicas de dominio en múltiples documentos.

• Mitigar alucinaciones a través de la Generación Mejorada por Recuperación utilizando la base de datos de vectores de Pinecone y Llama-2 de Amazon SageMaker JumpStart
• SetFitABSA Análisis de Sentimiento Basado en Aspectos de Pocas Muestras utilizando SetFit
• Cómo las naciones están perdiendo una carrera global para abordar los daños de la inteligencia artificial.

Parte 1: Limitaciones de RAG y resumen de la solución

En esta sección, revisaremos el diseño RAG y discutiremos sus limitaciones en preguntas analíticas. También presentaremos una arquitectura más versátil que supera estas limitaciones.

Resumen de RAG

Las soluciones RAG están inspiradas en ideas de aprendizaje de representaciones y búsqueda semántica que se han adoptado gradualmente en problemas de clasificación (por ejemplo, recomendación y búsqueda) y tareas de procesamiento de lenguaje natural (NLP) desde el año 2010.

El enfoque popular utilizado actualmente consta de tres pasos:

1. Un trabajo de procesamiento por lotes en línea ingestiona documentos de una base de conocimiento de entrada, los divide en fragmentos, crea una representación para cada fragmento para representar su semántica utilizando un modelo de representación pre-entrenado, como los modelos de representación Amazon Titan, y luego utiliza estas representaciones como entrada para crear un índice de búsqueda semántica.
2. Cuando se responde a una nueva pregunta en tiempo real, la pregunta de entrada se convierte en una representación, que se utiliza para buscar y extraer los fragmentos de documentos más similares utilizando una métrica de similitud, como la similitud del coseno, y un algoritmo de vecinos más cercanos aproximado. La precisión de la búsqueda también se puede mejorar con filtrado de metadatos.
3. Se construye un mensaje a partir de la concatenación de un mensaje del sistema con un contexto formado por los fragmentos relevantes de documentos extraídos en el paso 2, y la pregunta de entrada en sí. Este mensaje se presenta luego a un modelo LLM para generar la respuesta final a la pregunta a partir del contexto.

Con el modelo de incrustación correcto, capaz de producir representaciones semánticas precisas de los fragmentos del documento de entrada y las preguntas de entrada, y un módulo de búsqueda semántica eficiente, esta solución es capaz de responder preguntas que requieren recuperar información existente en una base de datos de documentos. Por ejemplo, si tienes un servicio o un producto, podrías comenzar indexando su sección de preguntas frecuentes o documentación y tener una IA conversacional inicial adaptada a tu oferta específica.

Limitaciones de RAG basado en búsqueda semántica

Aunque RAG es un componente esencial en los asistentes de IA modernos específicos de dominio y un punto de partida sensato para construir una IA conversacional en torno a una base de conocimientos especializada, no puede responder preguntas que requieren escanear, comparar y razonar en todos los documentos de tu base de conocimientos simultáneamente, especialmente cuando la ampliación se basa únicamente en la búsqueda semántica.

Para comprender estas limitaciones, consideremos nuevamente el ejemplo de decidir dónde invertir basado en informes financieros. Si usáramos RAG para conversar con estos informes, podríamos hacer preguntas como “¿Cuáles son los riesgos que enfrentó la empresa X en 2022?” o “¿Cuál es el ingreso neto de la empresa Y en 2022?” Para cada una de estas preguntas, se utiliza el vector de incrustación correspondiente, que codifica el significado semántico de la pregunta, para recuperar los fragmentos de documentos más similares semánticamente disponibles en el índice de búsqueda. Esto se logra típicamente mediante el uso de una solución de vecinos más cercanos aproximada, como FAISS, NMSLIB, pgvector u otros, que se esfuerzan por lograr un equilibrio entre la velocidad de recuperación y la recuperación para lograr un rendimiento en tiempo real mientras se mantiene una precisión satisfactoria.

Sin embargo, el enfoque mencionado anteriormente no puede responder con precisión preguntas analíticas en todos los documentos, como “¿Cuáles son las 5 empresas con los mayores ingresos netos en 2022?”

Esto se debe a que la búsqueda semántica intenta encontrar los K fragmentos de documentos más similares a la pregunta de entrada. Pero como ninguno de los documentos contiene resúmenes completos de los ingresos, devolverá fragmentos de documentos que simplemente contienen menciones de “ingreso neto” y posiblemente “2022”, sin cumplir la condición esencial de centrarse en las empresas con mayores ingresos. Si presentamos estos resultados de búsqueda a un LLM como contexto para responder la pregunta de entrada, puede formular una respuesta engañosa o negarse a responder, porque falta la información correcta requerida.

Estas limitaciones están diseñadas de esta manera porque la búsqueda semántica no realiza un escaneo exhaustivo de todos los vectores de incrustación para encontrar documentos relevantes. En cambio, utiliza métodos aproximados de vecinos más cercanos para mantener una velocidad de recuperación razonable. Una estrategia clave para la eficiencia en estos métodos es segmentar el espacio de incrustación en grupos durante la indexación. Esto permite identificar rápidamente qué grupos pueden contener incrustaciones relevantes durante la recuperación, sin necesidad de comparaciones entre pares. Además, incluso técnicas tradicionales de vecinos más cercanos como KNN, que escanean todos los documentos, solo calculan métricas de distancia básicas y no son adecuadas para las comparaciones complejas necesarias para el razonamiento analítico. Por lo tanto, RAG con búsqueda semántica no está diseñado para responder preguntas que involucran razonamiento analítico en todos los documentos.

Para superar estas limitaciones, proponemos una solución que combina RAG con metadatos y extracción de entidades, consultas SQL y agentes LLM, como se describe en las siguientes secciones.

Superando las limitaciones de RAG con metadatos, SQL y agentes LLM

Examinemos más a fondo una pregunta en la que RAG falla, para que podamos rastrear el razonamiento necesario para responderla de manera efectiva. Este análisis debería apuntarnos hacia el enfoque correcto que podría complementar a RAG en la solución general.

Consideremos la pregunta: “¿Cuáles son las 5 empresas con mayores ingresos en 2022?”

Para poder responder esta pregunta, necesitaríamos:

1. Identificar los ingresos para cada empresa.
2. Filtrar para quedarnos con los ingresos de 2022 para cada una de ellas.
3. Ordenar los ingresos en orden descendente.
4. Seleccionar los 5 ingresos principales junto con los nombres de las empresas.

Típicamente, estas operaciones analíticas se realizan en datos estructurados, utilizando herramientas como pandas o motores SQL. Si tuviéramos acceso a una tabla SQL que contiene las columnas compania, ingreso y anio, podríamos responder fácilmente nuestra pregunta ejecutando una consulta SQL, similar al siguiente ejemplo:

SELECT compania, ingreso FROM nombre_tabla WHERE anio = 2022 ORDER BY ingreso DESC LIMIT 5;

Almacenar metadatos estructurados en una tabla SQL que contiene información sobre entidades relevantes te permite responder muchos tipos de preguntas analíticas escribiendo la consulta SQL correcta. Por eso complementamos RAG en nuestra solución con un módulo de consulta SQL en tiempo real contra una tabla SQL, poblada con metadatos extraídos en un proceso externo.

Pero ¿cómo podemos implementar e integrar este enfoque en una IA conversacional basada en LLM?

Hay tres pasos para poder agregar razonamiento analítico en SQL:

• Extracción de metadatos – Extraer metadatos de documentos no estructurados en una tabla SQL
• Texto a SQL – Formular consultas SQL precisas a partir de preguntas de entrada utilizando LLM
• Selección de herramienta – Identificar si una pregunta debe ser respondida usando RAG o una consulta SQL

Para implementar estos pasos, primero reconocemos que la extracción de información de documentos no estructurados es una tarea tradicional de PLN para la cual los LLM demuestran prometer lograr alta precisión a través del aprendizaje de cero o pocas muestras. Segundo, la capacidad de estos modelos para generar consultas SQL a partir de lenguaje natural ha sido comprobada durante años, como se puede ver en el lanzamiento de 2020 de Amazon QuickSight Q. Finalmente, seleccionar automáticamente la herramienta adecuada para una pregunta específica mejora la experiencia del usuario y permite responder preguntas complejas a través de razonamiento de múltiples pasos. Para implementar esta función, profundizamos en los agentes LLM en una sección posterior.

En resumen, la solución que proponemos está compuesta por los siguientes componentes principales:

• Recuperación de búsqueda semántica para aumentar el contexto de generación
• Extracción y consulta de metadatos estructurados con SQL
• Un agente capaz de utilizar las herramientas adecuadas para responder una pregunta

Resumen de la solución

El siguiente diagrama representa una arquitectura simplificada de la solución. Te ayuda a identificar y comprender el papel de los componentes principales y cómo interactúan para implementar el comportamiento completo del asistente LLM. La numeración se alinea con el orden de las operaciones al implementar esta solución.

En la práctica, implementamos esta solución como se describe en la siguiente arquitectura detallada.

Para esta arquitectura, proponemos una implementación en GitHub, con componentes estrechamente acoplados donde el backend (5), las tuberías de datos (1, 2, 3) y el frontend (4) pueden evolucionar por separado. Esto es para simplificar la colaboración entre competencias al personalizar y mejorar la solución para la producción.

Implementar la solución

Para instalar esta solución en tu cuenta de AWS, sigue los siguientes pasos:

1. Clona el repositorio en GitHub.
2. Instala el backend de AWS Cloud Development Kit (AWS CDK) app:
   1. Abre la carpeta backend.
   2. Ejecuta npm install para instalar las dependencias.
   3. Si nunca has utilizado el AWS CDK en la cuenta y región actual, ejecuta bootstrapping con npx cdk bootstrap.
   4. Ejecuta npx cdk deploy para implementar el stack.
3. Opcionalmente, ejecuta streamlit-ui de la siguiente manera:
   1. Recomendamos clonar este repositorio en un entorno de Amazon SageMaker Studio. Para obtener más información, consulta Onboard to Amazon SageMaker Domain using Quick setup.
   2. Dentro de la carpeta frontend/streamlit-ui, ejecuta bash run-streamlit-ui.sh.
   3. Elige el enlace con el siguiente formato para abrir la demostración: https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/.
4. Finalmente, puedes ejecutar el pipeline de Amazon SageMaker definido en el cuaderno data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb para procesar los documentos PDF de entrada y preparar la tabla SQL y el índice de búsqueda semántica utilizados por el asistente LLM.

En el resto de este artículo, nos centraremos en explicar los componentes más importantes y las elecciones de diseño, con la esperanza de inspirarte al diseñar tu propio asistente de IA en una base de conocimiento interna. Suponemos que los componentes 1 y 4 son fáciles de entender, y nos enfocamos en los componentes principales 2, 3 y 5.

Parte 2: Pipeline de extracción de entidades

En esta sección, profundizaremos en el pipeline de extracción de entidades utilizado para preparar datos estructurados, que es un ingrediente clave para responder preguntas analíticas.

Extracción de texto

Los documentos suelen almacenarse en formato PDF o como imágenes escaneadas. Pueden estar formados por diseños de párrafos simples o tablas complejas, y contener texto digital o escrito a mano. Para extraer la información correctamente, debemos transformar estos documentos en texto plano, preservando su estructura original. Para hacer esto, puedes utilizar Amazon Textract, que es un servicio de aprendizaje automático (ML) que proporciona APIs maduras para extraer texto, tablas y formularios de entradas digitales y escritas a mano.

En el componente 2, extraemos el texto y las tablas de la siguiente manera:

1. Para cada documento, llamamos a Amazon Textract para extraer el texto y las tablas.
2. Utilizamos el siguiente script de Python para recrear las tablas como DataFrames de pandas.
3. Consolidamos los resultados en un documento único e insertamos las tablas como markdown.

Este proceso se describe en el siguiente diagrama de flujo y se muestra concretamente en notebooks/03-pdf-document-processing.ipynb.

Extracción de entidades y consultas utilizando LLMs

Para responder preguntas analíticas de manera efectiva, necesitas extraer metadatos y entidades relevantes de la base de conocimientos de tus documentos en un formato de datos estructurado accesible. Te sugerimos utilizar SQL para almacenar esta información y recuperar respuestas debido a su popularidad, facilidad de uso y escalabilidad. Esta elección también se beneficia de la capacidad comprobada de los modelos de lenguaje para generar consultas SQL a partir de lenguaje natural.

En esta sección, profundizamos en los siguientes componentes que permiten preguntas analíticas:

• Un proceso por lotes que extrae datos estructurados de datos no estructurados utilizando LLMs
• Un módulo en tiempo real que convierte preguntas en lenguaje natural en consultas SQL y recupera resultados de una base de datos SQL

Puedes extraer los metadatos relevantes para respaldar preguntas analíticas de la siguiente manera:

1. Define un esquema JSON para la información que necesitas extraer, que contenga una descripción de cada campo y su tipo de datos, e incluya ejemplos de los valores esperados.
2. Para cada documento, solicita a un LLM con el esquema JSON que extraiga los datos relevantes con precisión.
3. Cuando la longitud del documento supera la longitud del contexto y para reducir el costo de extracción con LLMs, puedes utilizar una búsqueda semántica para recuperar y presentar fragmentos relevantes de documentos al LLM durante la extracción.
4. Analiza la salida JSON y valida la extracción del LLM.
5. Opcionalmente, haz una copia de seguridad de los resultados en Amazon S3 como archivos CSV.
6. Carga los datos en la base de datos SQL para futuras consultas.

Este proceso es administrado por la siguiente arquitectura, en la que los documentos en formato de texto se cargan con un script de Python que se ejecuta en un trabajo de Procesamiento de Amazon SageMaker para realizar la extracción.

Para cada grupo de entidades, construimos dinámicamente una solicitud que incluye una descripción clara de la tarea de extracción de información, así como un esquema JSON que define la salida esperada e incluye los fragmentos relevantes del documento como contexto. También añadimos algunos ejemplos de entrada y salida correcta para mejorar el rendimiento de extracción con aprendizaje de pocos ejemplos. Esto se demuestra en notebooks/05-entities-extraction-to-structured-metadata.ipynb.

Parte 3: Construye un asistente de documentos autónomo con Amazon Bedrock

En esta sección, demostramos cómo utilizar los modelos de lenguaje de aprendizaje a largo plazo (LLMs, por sus siglas en inglés) de Amazon Bedrock para consultar datos y construir un agente LLM que mejora RAG con capacidades analíticas, lo que te permite crear asistentes de documentos inteligentes que pueden responder preguntas complejas específicas del dominio en múltiples documentos. Puedes consultar la función Lambda en GitHub para ver la implementación concreta del agente y las herramientas descritas en esta parte.

Formula consultas SQL y responde preguntas analíticas

Ahora que tenemos un almacén de metadatos estructurado con las entidades relevantes extraídas y cargadas en una base de datos SQL que podemos consultar, la pregunta que queda es ¿cómo generar la consulta SQL correcta a partir de las preguntas en lenguaje natural de entrada?

Los LLMs modernos son buenos generando SQL. Por ejemplo, si solicitas a Anthropic Claude LLM a través de Amazon Bedrock que genere una consulta SQL, verás respuestas plausibles. Sin embargo, debemos seguir algunas reglas al escribir la instrucción para obtener consultas SQL más precisas. Estas reglas son especialmente importantes para consultas complejas, para reducir la alucinación y los errores de sintaxis:

• Describe con precisión la tarea en la instrucción
• Incluye el esquema de las tablas SQL en la instrucción, describiendo cada columna de la tabla y especificando su tipo de datos
• Dile explícitamente al LLM que solo use nombres de columna y tipos de datos existentes
• Agrega algunas filas de las tablas SQL

También puedes realizar un posprocesamiento de la consulta SQL generada utilizando un linter como sqlfluff para corregir el formato, o un analizador como sqlglot para detectar errores de sintaxis y optimizar la consulta. Además, cuando el rendimiento no cumple con los requisitos, puedes proporcionar algunos ejemplos dentro de la instrucción para orientar al modelo con el aprendizaje de pocas muestras hacia la generación de consultas SQL más precisas.

Desde una perspectiva de implementación, utilizamos una función AWS Lambda para orquestar el siguiente proceso:

1. Llamar a un modelo Anthropic Claude en Amazon Bedrock con la pregunta de entrada para obtener la consulta SQL correspondiente. Aquí, utilizamos la clase SQLDatabase de LangChain para agregar descripciones de esquema de las tablas SQL relevantes, y utilizamos una instrucción personalizada.
2. Analizar, validar y ejecutar la consulta SQL en la base de datos Amazon Aurora compatible con PostgreSQL.

La arquitectura de esta parte de la solución se muestra en el siguiente diagrama.

Consideraciones de seguridad para prevenir ataques de inyección SQL

Mientras habilitamos al asistente de IA para consultar una base de datos SQL, debemos asegurarnos de que esto no introduzca vulnerabilidades de seguridad. Para lograr esto, proponemos las siguientes medidas de seguridad para prevenir ataques de inyección SQL:

• Aplicar permisos de IAM de menor privilegio – Limitar los permisos de la función Lambda que ejecuta las consultas SQL utilizando una política y un rol de AWS Identity and Access Management (IAM) que siga el principio de menor privilegio. En este caso, otorgamos acceso solo de lectura.
• Limitar el acceso a los datos – Proporcionar acceso solo a la cantidad mínima necesaria de tablas y columnas para prevenir ataques de divulgación de información.
• Agregar una capa de moderación – Introducir una capa de moderación que detecte intentos de inyección de instrucciones tempranamente y los impida propagarse al resto del sistema. Puede tener la forma de filtros basados en reglas, coincidencia de similitud contra una base de datos de ejemplos conocidos de inyección de instrucciones, o un clasificador de aprendizaje automático.

Búsqueda semántica para mejorar el contexto de generación

La solución que proponemos utiliza RAG con búsqueda semántica en el componente 3. Puedes implementar este módulo utilizando bases de conocimiento para Amazon Bedrock. Además, existen diversas opciones para implementar RAG, como la API de recuperación de Amazon Kendra, base de datos vectorial de Amazon OpenSearch y Amazon Aurora PostgreSQL con pgvector, entre otras. El paquete de código abierto aws-genai-llm-chatbot muestra cómo utilizar muchas de estas opciones de búsqueda vectorial para implementar un chatbot impulsado por LLM.

En esta solución, debido a que necesitamos tanto consultas SQL como búsqueda vectorial, decidimos utilizar Amazon Aurora PostgreSQL con la extensión pgvector, que admite ambas características. Por lo tanto, implementamos el componente de búsqueda semántica RAG con la siguiente arquitectura.

El proceso de responder preguntas utilizando la arquitectura anterior se realiza en dos etapas principales.

Primero, un proceso de lote fuera de línea, que se ejecuta como un trabajo de procesamiento de SageMaker, crea el índice de búsqueda semántica de la siguiente manera:

1. Ya sea periódicamente o al recibir nuevos documentos, se ejecuta un trabajo de SageMaker.
2. Carga los documentos de texto desde Amazon S3 y los divide en fragmentos superpuestos.
3. Para cada fragmento, utiliza un modelo de inserción de Amazon Titan para generar un vector de inserción.
4. Utiliza la clase PGVector de LangChain para ingresar las inserciones, con sus fragmentos de documentos y metadatos, en Amazon Aurora PostgreSQL y crear un índice de búsqueda semántica en todos los vectores de inserción.

En segundo lugar, en tiempo real y para cada nueva pregunta, construimos una respuesta de la siguiente manera:

1. El coordinador recibe la pregunta en una función Lambda.
2. El coordinador inserta la pregunta utilizando el mismo modelo de inserción.
3. Recupera los fragmentos de documentos más relevantes de la búsqueda semántica en PostgreSQL. Opcionalmente, utiliza filtrado de metadatos para mejorar la precisión.
4. Estos fragmentos se insertan dinámicamente en una indicación LLM junto con la pregunta de entrada.
5. La indicación se presenta a Anthropic Claude en Amazon Bedrock, para instruirlo a responder la pregunta de entrada en función del contexto disponible.
6. Finalmente, la respuesta generada se envía de vuelta al coordinador.

Un agente capaz de utilizar herramientas para razonar y actuar

Hasta ahora en esta publicación, hemos discutido el tratamiento de preguntas que requieren RAG o razonamiento analítico por separado. Sin embargo, muchas preguntas del mundo real demandan ambas capacidades, a veces a lo largo de múltiples etapas de razonamiento, para llegar a una respuesta final. Para brindar soporte a estas preguntas más complejas, es necesario introducir la noción de un agente.

Los agentes LLM, como los agentes para Amazon Bedrock, han surgido recientemente como una solución prometedora capaz de utilizar LLM para razonar y adaptarse utilizando el contexto actual y elegir acciones apropiadas de una lista de opciones, lo que presenta un marco de solución general para problemas. Como se discute en Agentes autónomos impulsados por LLM, existen múltiples estrategias de indicación y patrones de diseño para agentes LLM que admiten razonamiento complejo.

Uno de estos patrones de diseño es el razonamiento y la acción (ReAct), introducido en ReAct: Sinergia de razonamiento y acción en modelos de lenguaje. En ReAct, el agente recibe como entrada un objetivo que puede ser una pregunta, identifica las piezas de información que faltan para responderla y propone de manera iterativa la herramienta adecuada para recopilar información en función de las descripciones de las herramientas disponibles. Después de recibir la respuesta de una herramienta determinada, el LLM evalúa si tiene toda la información necesaria para responder completamente la pregunta. Si no es así, realiza otro paso de razonamiento y utiliza la misma u otra herramienta para recopilar más información, hasta que esté listo una respuesta final o se alcance un límite.

El siguiente diagrama de secuencia explica cómo funciona un agente ReAct para responder a la pregunta “Dame las 5 empresas con mayor facturación en los últimos 2 años y identifica los riesgos asociados con la primera”.

Los detalles de implementar este enfoque en Python se describen en Agente LLM personalizado. En nuestra solución, el agente y las herramientas se implementan con la siguiente arquitectura parcial destacada.

Para responder a una pregunta de entrada, usamos los servicios de AWS de la siguiente manera:

1. Un usuario ingresa su pregunta a través de una interfaz de usuario que llama a una API en Amazon API Gateway.
2. API Gateway envía la pregunta a una función Lambda que implementa el ejecutor del agente.
3. El agente llama al LLM con una indicación que contiene una descripción de las herramientas disponibles, el formato de instrucción ReAct y la pregunta de entrada, y luego analiza la siguiente acción a completar.
4. La acción contiene qué herramienta llamar y cuál es la entrada de la acción.
5. Si la herramienta a usar es SQL, el ejecutor del agente llama a SQLQA para convertir la pregunta a SQL y ejecutarla. Luego agrega el resultado a la indicación y vuelve a llamar al LLM para ver si puede responder la pregunta original o si necesita más acciones.
6. De manera similar, si la herramienta a usar es búsqueda semántica, la entrada de la acción se analiza y se utiliza para recuperar de la búsqueda semántica de PostgreSQL. Agrega los resultados a la indicación y verifica si el LLM puede responder o necesita otra acción.
7. Una vez que toda la información para responder una pregunta está disponible, el agente LLM formula una respuesta final y la envía de vuelta al usuario.

Puede ampliar el agente con más herramientas. En la implementación disponible en GitHub, demostramos cómo puede agregar un motor de búsqueda y una calculadora como herramientas adicionales a las mencionadas herramientas de SQL y búsqueda semántica. Para almacenar el historial de conversaciones en curso, utilizamos una tabla de Amazon DynamoDB.

Según nuestra experiencia hasta ahora, los siguientes son elementos clave para un agente exitoso:

• Un LLM subyacente capaz de razonar con el formato ReAct
• Una descripción clara de las herramientas disponibles, cuándo usarlas y una descripción de sus argumentos de entrada con, potencialmente, un ejemplo de la entrada y salida esperada
• Un esquema claro del formato ReAct que debe seguir el LLM
• Las herramientas adecuadas para resolver la pregunta comercial disponibles para que el agente LLM las use
• Analizar correctamente las salidas de las respuestas del agente LLM a medida que razona

Para optimizar los costos, recomendamos almacenar en caché las preguntas más frecuentes con sus respuestas y actualizar esta caché periódicamente para reducir las llamadas al LLM subyacente. Por ejemplo, puede crear un índice de búsqueda semántica con las preguntas más comunes como se explicó anteriormente y comparar la nueva pregunta del usuario con el índice antes de llamar al LLM. Para explorar otras opciones de almacenamiento en caché, consulte las integraciones de almacenamiento en caché del LLM.

Compatibilidad con otros formatos como video, imagen, audio y archivos 3D

Puede aplicar la misma solución a varios tipos de información, como imágenes, videos, audio y archivos de diseño 3D, como archivos CAD o de malla. Esto implica el uso de técnicas de aprendizaje automático establecidas para describir el contenido del archivo en texto, que luego se puede ingresar en la solución que exploramos anteriormente. Este enfoque le permite llevar a cabo conversaciones de QA sobre estos diversos tipos de datos. Por ejemplo, puede ampliar su base de datos de documentos creando descripciones textuales de imágenes, videos o contenido de audio. También puede mejorar la tabla de metadatos identificando propiedades mediante clasificación o detección de objetos en elementos dentro de estos formatos. Después de que estos datos extraídos se indexan en la tienda de metadatos o el índice de búsqueda semántica para documentos, la arquitectura general del sistema propuesto sigue siendo en gran medida consistente.

Conclusion

En este post, mostramos cómo el uso de LLM con el patrón de diseño RAG es necesario para construir un asistente de inteligencia artificial específico del dominio, pero es insuficiente para alcanzar el nivel de confiabilidad requerido para generar valor empresarial. Por esta razón, propusimos ampliar el popular patrón de diseño RAG con los conceptos de agentes y herramientas, donde la flexibilidad de las herramientas nos permite utilizar tanto técnicas tradicionales de procesamiento del lenguaje natural como las capacidades modernas de LLM para permitir un asistente de inteligencia artificial con más opciones para buscar información y ayudar a los usuarios a resolver problemas empresariales de manera eficiente.

La solución demuestra el proceso de diseño hacia un asistente de LLM capaz de responder a varios tipos de preguntas de recuperación, razonamiento analítico y razonamiento de múltiples pasos en su base de conocimiento. También destacamos la importancia de pensar en reversa a partir de los tipos de preguntas y tareas que se espera que su asistente de LLM ayude a los usuarios. En este caso, el viaje de diseño nos condujo a una arquitectura con tres componentes: búsqueda semántica, extracción de metadatos y consultas SQL, y agente y herramientas LLM, que creemos que es genérico y lo suficientemente flexible para múltiples casos de uso. También creemos que al inspirarse en esta solución y sumergirse profundamente en las necesidades de sus usuarios, podrá ampliar aún más esta solución hacia lo que funcione mejor para usted.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!