Aprenda a crear e implementar agentes LLM que utilicen herramientas utilizando los modelos de AWS SageMaker JumpStart Foundation.

Los agentes de modelo de lenguaje grande (LLM) son programas que amplían las capacidades de los LLM independientes con 1) acceso a herramientas externas (API, funciones, webhooks, complementos, etc.) y 2) la capacidad de planificar y ejecutar tareas de forma independiente. -Moda dirigida. A menudo, los LLM necesitan interactuar con otro software, bases de datos o API para realizar tareas complejas. Por ejemplo, un chatbot administrativo que programe reuniones requeriría acceso a los calendarios y al correo electrónico de los empleados. Con acceso a herramientas, los agentes de LLM pueden volverse más poderosos, a costa de una complejidad adicional.

En esta publicación, presentamos los agentes LLM y demostramos cómo crear e implementar un agente LLM de comercio electrónico utilizando Amazon SageMaker JumpStart y AWS Lambda. El agente utilizará herramientas para brindar nuevas capacidades, como responder preguntas sobre devoluciones (“¿Mi devolución rtn001 ¿procesado?”) y proporcionando actualizaciones sobre los pedidos (“¿Podría decirme si el pedido 123456 ¿se ha enviado?"). Estas nuevas capacidades requieren que los LLM obtengan datos de múltiples fuentes de datos (pedidos, devoluciones) y realizar recuperación de generación aumentada (RAG).

Para alimentar el agente LLM, utilizamos un Flan-UL2 modelo implementado como un punto final de SageMaker y utilice herramientas de recuperación de datos creadas con AWS Lambda. Posteriormente, el agente puede integrarse con Amazon Lex y utilizarse como chatbot dentro de sitios web o AWS Connect. Concluimos la publicación con elementos a considerar antes de implementar agentes de LLM en producción. Para disfrutar de una experiencia totalmente administrada para crear agentes LLM, AWS también proporciona la función agentes para Amazon Bedrock (en versión preliminar).

Una breve descripción general de las arquitecturas de agentes LLM

Los agentes LLM son programas que utilizan LLM para decidir cuándo y cómo utilizar las herramientas necesarias para completar tareas complejas. Con herramientas y capacidades de planificación de tareas, los agentes de LLM pueden interactuar con sistemas externos y superar las limitaciones tradicionales de los LLM, como límites de conocimiento, alucinaciones y cálculos imprecisos. Las herramientas pueden adoptar diversas formas, como llamadas API, funciones de Python o complementos basados en webhooks. Por ejemplo, un LLM puede utilizar un "complemento de recuperación" para buscar contexto relevante y realizar RAG.

Entonces, ¿qué significa para un LLM elegir herramientas y planificar tareas? Existen numerosos enfoques (como Reaccionar, MRKL, formador de herramientas, AbrazandoGPT, y Agente transformadors) al uso de LLM con herramientas, y los avances se están produciendo rápidamente. Pero una forma sencilla es solicitar a un LLM una lista de herramientas y pedirle que determine 1) si se necesita una herramienta para satisfacer la consulta del usuario y, de ser así, 2) seleccione la herramienta adecuada. Un mensaje de este tipo normalmente se parece al siguiente ejemplo y puede incluir ejemplos breves para mejorar la confiabilidad del LLM a la hora de elegir la herramienta adecuada.

''' Su tarea es seleccionar una herramienta para responder a la pregunta de un usuario. Tienes acceso a las siguientes herramientas. buscar: buscar una respuesta en las preguntas frecuentes orden: pedir artículos noop: no se necesita ninguna herramienta {algunos ejemplos de tomas} Pregunta: {entrada} Herramienta: '''

Los enfoques más complejos implican el uso de un LLM especializado que pueda decodificar directamente "llamadas API" o "uso de herramientas", como GorilaLLM. Estos LLM optimizados están capacitados en conjuntos de datos de especificaciones de API para reconocer y predecir llamadas de API según las instrucciones. A menudo, estos LLM requieren algunos metadatos sobre las herramientas disponibles (descripciones, yaml o esquema JSON para sus parámetros de entrada) para generar invocaciones de herramientas. Este enfoque lo adoptan los agentes de Amazon Bedrock y Llamadas a funciones OpenAI. Tenga en cuenta que los LLM generalmente deben ser lo suficientemente grandes y complejos para mostrar la capacidad de selección de herramientas.

Suponiendo que se eligen los mecanismos de planificación de tareas y selección de herramientas, un programa de agente LLM típico funciona en la siguiente secuencia:

1. Solicitud del usuario – El programa toma una entrada del usuario como "¿Dónde está mi pedido?" 123456?” desde alguna aplicación cliente.
2. Planifique las próximas acciones y seleccione las herramientas a utilizar – A continuación, el programa utiliza un mensaje para que el LLM genere la siguiente acción, por ejemplo, “Buscar la tabla de pedidos usando API de pedidos.” Se solicita al LLM que sugiera un nombre de herramienta como API de pedidos de una lista predefinida de herramientas disponibles y sus descripciones. Alternativamente, se podría indicar al LLM que genere directamente una llamada API con parámetros de entrada como PedidosAPI(12345).
   1. Tenga en cuenta que la siguiente acción puede implicar o no el uso de una herramienta o API. De lo contrario, el LLM respondería a las aportaciones del usuario sin incorporar contexto adicional de las herramientas o simplemente devolvería una respuesta predeterminada como "No puedo responder a esta pregunta".
3. Solicitud de herramienta de análisis – A continuación, debemos analizar y validar la herramienta/predicción de acción sugerida por el LLM. Se necesita validación para garantizar que los nombres de las herramientas, las API y los parámetros de solicitud no sean alucinantes y que las herramientas se invoquen correctamente de acuerdo con las especificaciones. Este análisis puede requerir una llamada LLM por separado.
4. Herramienta de invocación – Una vez que se garantizan los nombres y parámetros de la herramienta válidos, invocamos la herramienta. Podría ser una solicitud HTTP, una llamada a una función, etc.
5. Analizar salida – La respuesta de la herramienta puede necesitar procesamiento adicional. Por ejemplo, una llamada API puede dar como resultado una respuesta JSON larga, donde solo un subconjunto de campos son de interés para el LLM. Extraer información en un formato limpio y estandarizado puede ayudar al LLM a interpretar el resultado de manera más confiable.
6. Interpretar la salida – Dado el resultado de la herramienta, se solicita nuevamente al LLM que le dé sentido y decida si puede generar la respuesta final para el usuario o si se requieren acciones adicionales.
7. Terminar o continuar con el paso 2 – Devuelve una respuesta final o una respuesta predeterminada en caso de errores o tiempos de espera.

Diferentes marcos de agentes ejecutan el flujo del programa anterior de manera diferente. Por ejemplo, Reaccionar combina la selección de herramientas y la generación de respuestas finales en un solo mensaje, en lugar de utilizar mensajes separados para la selección de herramientas y la generación de respuestas. Además, esta lógica se puede ejecutar en una sola pasada o en una instrucción while (el "bucle del agente"), que termina cuando se genera la respuesta final, se lanza una excepción o se agota el tiempo de espera. Lo que permanece constante es que los agentes utilizan el LLM como pieza central para orquestar la planificación y la invocación de herramientas hasta que finaliza la tarea. A continuación, mostramos cómo implementar un bucle de agente simple utilizando los servicios de AWS.

Descripción general de la solución

Para esta publicación de blog, implementamos un agente LLM de soporte de comercio electrónico que proporciona dos funcionalidades impulsadas por herramientas:

• Herramienta de recuperación del estado de devolución – Responder preguntas sobre el estado de las devoluciones como, “¿Qué está pasando con mi devolución? rtn001?”
• Herramienta de recuperación del estado del pedido – Realizar un seguimiento del estado de los pedidos, como "¿Cuál es el estado de mi pedido?" 123456?”

El agente utiliza efectivamente el LLM como enrutador de consultas. Ante una consulta (“¿Cuál es el estado del pedido? 123456?”), seleccione la herramienta de recuperación adecuada para realizar consultas en múltiples fuentes de datos (es decir, devoluciones y pedidos). Logramos el enrutamiento de consultas haciendo que el LLM elija entre múltiples herramientas de recuperación, que son responsables de interactuar con una fuente de datos y buscar el contexto. Esto amplía el patrón RAG simple, que supone una única fuente de datos.

Ambas herramientas de recuperación son funciones Lambda que toman una identificación (Solicitar ID o ID de retorno) como entrada, recupera un objeto JSON de la fuente de datos y convierte el JSON en una cadena de representación amigable para los humanos que es adecuada para ser utilizada por LLM. La fuente de datos en un escenario del mundo real podría ser una base de datos NoSQL altamente escalable como DynamoDB, pero esta solución emplea Python simple. dictar con datos de muestra para fines de demostración.

Se pueden agregar funcionalidades adicionales al agente agregando herramientas de recuperación y modificando las indicaciones en consecuencia. Este agente se puede probar como un servicio independiente que se integra con cualquier interfaz de usuario a través de HTTP, lo que se puede hacer fácilmente con Amazon Lex.

Aquí hay algunos detalles adicionales sobre los componentes clave:

1. Punto final de inferencia de LLM – El núcleo de un programa de agentes es un LLM. Usaremos el centro de modelos básicos SageMaker JumpStart para implementar fácilmente el Flan-UL2 modelo. SageMaker JumpStart facilita la implementación de puntos finales de inferencia LLM en instancias dedicadas de SageMaker.
2. Agente orquestador – El orquestador de agentes organiza las interacciones entre el LLM, las herramientas y la aplicación cliente. Para nuestra solución, utilizamos una función AWS Lambda para impulsar este flujo y empleamos las siguientes funciones auxiliares.
   • Planificador de tareas (herramientas) – El planificador de tareas utiliza el LLM para sugerir uno de 1) consulta de devolución, 2) consulta de pedido o 3) ninguna herramienta. Utilizamos ingeniería rápida únicamente y Flan-UL2 modelo tal como está sin ajustes finos.
   • Analizador de herramientas – El analizador de herramientas garantiza que la sugerencia de herramienta del planificador de tareas sea válida. En particular, nos aseguramos de que un único Solicitar ID o ID de retorno se puede analizar. De lo contrario, respondemos con un mensaje predeterminado.
   • Despachador de herramientas – El despachador de herramientas invoca herramientas (funciones Lambda) utilizando los parámetros válidos.
   • Analizador de salida – El analizador de salida limpia y extrae elementos relevantes de JSON en una cadena legible por humanos. Esta tarea la realiza tanto cada herramienta de recuperación como dentro del orquestador.
   • Intérprete de salida – La responsabilidad del intérprete de resultados es 1) interpretar el resultado de la invocación de la herramienta y 2) determinar si se puede satisfacer la solicitud del usuario o si se necesitan pasos adicionales. En este último caso, se genera una respuesta final por separado y se devuelve al usuario.

Ahora, profundicemos un poco más en los componentes clave: orquestador de agentes, planificador de tareas y distribuidor de herramientas.

Agente orquestador

A continuación se muestra una versión abreviada del bucle del agente dentro de la función Lambda del orquestador del agente. El bucle utiliza funciones auxiliares como planificador_de_tareas o analizador_herramienta, para modularizar las tareas. El bucle aquí está diseñado para ejecutarse como máximo dos veces para evitar que el LLM quede atrapado en un bucle innecesariamente largo.

#.. imports ..
MAX_LOOP_COUNT = 2 # stop the agent loop after up to 2 iterations
# ... helper function definitions ...
def agent_handler(event):
    user_input = event["query"]
    print(f"user input: {user_input}") 
    
    final_generation = ""
    is_task_complete = False
    loop_count = 0 

    # start of agent loop
    while not is_task_complete and loop_count < MAX_LOOP_COUNT:
        tool_prediction = task_planner(user_input)
        print(f"tool_prediction: {tool_prediction}")  
        
        tool_name, tool_input, tool_output, error_msg = None, None, "", ""

        try:
            tool_name, tool_input = tool_parser(tool_prediction, user_input)
            print(f"tool name: {tool_name}") 
            print(f"tool input: {tool_input}") 
        except Exception as e:
            error_msg = str(e)
            print(f"tool parse error: {error_msg}")  
    
        if tool_name is not None: # if a valid tool is selected and parsed 
            raw_tool_output = tool_dispatch(tool_name, tool_input)
            tool_status, tool_output = output_parser(raw_tool_output)
            print(f"tool status: {tool_status}")  

            if tool_status == 200:
                is_task_complete, final_generation = output_interpreter(user_input, tool_output) 
            else:
                final_generation = tool_output
        else: # if no valid tool was selected and parsed, either return the default msg or error msg
            final_generation = DEFAULT_RESPONSES.NO_TOOL_FEEDBACK if error_msg == "" else error_msg
    
        loop_count += 1

    return {
        'statusCode': 200,
        'body': final_generation
    }

Planificador de tareas (predicción de herramientas)

El orquestador de agentes utiliza planificador de tareas para predecir una herramienta de recuperación basada en la entrada del usuario. Para nuestro agente de LLM, simplemente usaremos ingeniería rápida y algunas indicaciones para enseñarle al LLM esta tarea en contexto. Agentes más sofisticados podrían utilizar un LLM optimizado para la predicción de herramientas, lo cual está más allá del alcance de esta publicación. El mensaje es el siguiente:

tool_selection_prompt_template = """ Su tarea es seleccionar las herramientas apropiadas para satisfacer la entrada del usuario. Si no se requiere ninguna herramienta, elija "no_tool" Las herramientas disponibles son: return_inquiry: base de datos de información sobre el estado de una devolución específica, ya sea pendiente, procesada o etc. order_inquiry: Información sobre el estado de un pedido específico, como estado de envío, producto, monto, etc. no_tool: No se necesita ninguna herramienta para responder a la entrada del usuario. Puede sugerir varias herramientas, separadas por una coma. Ejemplos: usuario: " ¿Cuál es su horario comercial?" herramienta: no_tool usuario: "¿Se ha enviado el pedido 12345?" herramienta: order_inquiry usuario: "¿Se ha procesado la devolución ret812?" herramienta: return_inquiry usuario: "¿Cuántos días tengo hasta devolver los pedidos?" herramienta: return_inquiry usuario: "¿Cuál fue el total del pedido 38745?" herramienta: order_inquiry usuario: "¿Puedo devolver mi pedido 38756 según la política de la tienda?" herramienta: order_inquiry usuario: "Hola" herramienta: no_tool usuario: "¿Eres una IA? ?" herramienta: no_tool usuario: "¿Cómo está el clima?" herramienta: no_tool usuario: "¿Cuál es el estado del reembolso del pedido 12347?" herramienta: order_inquiry usuario: "¿Cuál es el estado del reembolso de la devolución ret172?" herramienta: return_inquiry entrada del usuario : {} herramienta: """

Despachador de herramientas

El mecanismo de envío de herramientas funciona a través de si/si no Lógica para llamar a funciones Lambda apropiadas según el nombre de la herramienta. Lo siguiente es envío_herramienta Implementación de la función auxiliar. Se utiliza dentro del agente bucle y devuelve la respuesta sin procesar de la función Lambda de la herramienta, que luego se limpia mediante un analizador_salida función.

def tool_dispatch(tool_name, tool_input):
    #...
     
    tool_response = None 

    if tool_name == "returns_inquiry":
        tool_response = lambda_client.invoke(
            FunctionName=RETURNS_DB_TOOL_LAMBDA,
            InvocationType="RequestResponse",
            Payload=json.dumps({
              "returnId": tool_input  
            })
        )
    elif tool_name == "order_inquiry":
        tool_response = lambda_client.invoke(
            FunctionName=ORDERS_DB_TOOL_LAMBDA,
            InvocationType="RequestResponse",
            Payload=json.dumps({
                "orderId": tool_input
            })
        )
    else:
        raise ValueError("Invalid tool invocation")
        
    return tool_response

Implementar la solución

Requisitos previos importantes – Para comenzar con la implementación, debe cumplir los siguientes requisitos previos:

• Acceso a la Consola de administración de AWS a través de un usuario que puede iniciar pilas de AWS CloudFormation
• Familiaridad con la navegación por el AWS Lambda y Amazon Lex consolas
• Flan-UL2 requiere un solo ml.g5.12xgrande para la implementación, lo que puede requerir aumentar los límites de recursos a través de un ticket de soporte. En nuestro ejemplo, utilizamos nosotros-este-1 como Región, así que asegúrese de aumentar la cuota de servicio (si es necesario) en nosotros-este-1.

Implementar usando CloudFormation – Puede implementar la solución en nosotros-este-1 haciendo clic en el botón de abajo:

La implementación de la solución tardará unos 20 minutos y creará una LLMAgentStack pila, que:

• implementa el punto final de SageMaker usando Flan-UL2 modelo de SageMaker JumpStart;
• implementa tres funciones Lambda: LLMAgenteOrquestador, LLMAgentReturnsHerramienta, Herramienta LLMAgentOrders; y
• despliega un AWS Lex bot que se puede utilizar para probar el agente: Sagemaker-Jumpstart-Flan-LLM-Agente-Fallback-Bot.

Prueba la solución

La pila implementa un bot de Amazon Lex con el nombre Sagemaker-Jumpstart-Flan-LLM-Agente-Fallback-Bot. El bot se puede utilizar para probar el agente de un extremo a otro. Aquí hay una guía completa adicional para probar los bots de AWS Amazon Lex con una integración Lambda y cómo funciona la integración a alto nivel. Pero en resumen, el bot de Amazon Lex es un recurso que proporciona una interfaz de usuario rápida para chatear con el agente LLM que se ejecuta dentro de una función Lambda que creamos (LLMAgenteOrquestador).

Los casos de prueba de muestra a considerar son los siguientes:

• Consulta de pedido válido (por ejemplo, "¿Qué artículo se pidió para 123456?”)
  • El pedido "123456" es un pedido válido, por lo que debemos esperar una respuesta razonable (por ejemplo, "Jabón de manos a base de hierbas")
• Consulta de devolución válida para una devolución (por ejemplo, "¿Cuándo es mi devolución?" rtn003 ¿procesada?")
  • Debemos esperar una respuesta razonable sobre el estado de la devolución.
• Irrelevante tanto para devoluciones como para pedidos. (por ejemplo, “¿Cómo está el clima en Escocia ahora mismo?”)
  • Una pregunta irrelevante para devoluciones o pedidos, por lo que se debe devolver una respuesta predeterminada (“Lo siento, no puedo responder esa pregunta”).
• Consulta de pedido no válido (por ejemplo, "¿Qué artículo se pidió para 383833?”)
  • El ID 383832 no existe en el conjunto de datos de pedidos y, por lo tanto, deberíamos fallar sin problemas (por ejemplo, "Pedido no encontrado. Verifique su ID de pedido").
• Consulta de devolución no válida (por ejemplo, "¿Cuándo es mi regreso?" rtn123 ¿procesada?")
  • De manera similar, identificación rtn123 no existe en el conjunto de datos de rentabilidad y, por lo tanto, debería fallar sin problemas.
• Consulta de devolución irrelevante (por ejemplo, “¿Cuál es el impacto del retorno rtn001 ¿Sobre la paz mundial?”)
  • Esta pregunta, si bien parece pertenecer a un orden válido, es irrelevante. El LLM se utiliza para filtrar preguntas con contexto irrelevante.

Para ejecutar estas pruebas usted mismo, aquí están las instrucciones.

1. En la consola de Amazon Lex (Consola de AWS > Amazon Lex), navega hasta el bot titulado Sagemaker-Jumpstart-Flan-LLM-Agente-Fallback-Bot. Este bot ya ha sido configurado para llamar al LLMAgenteOrquestador Función Lambda siempre que el Intención alternativa se desencadena.
2. En el panel de navegación, elija Intenciones.
   
3. Elegir Construir en la esquina superior derecha
   
4. 4. Espere a que se complete el proceso de compilación. Cuando termine, recibirá un mensaje de éxito, como se muestra en la siguiente captura de pantalla.
   
5. Pruebe el bot ingresando los casos de prueba.
   

Limpiar

Para evitar cargos adicionales, elimine los recursos creados por nuestra solución siguiendo estos pasos:

• Sobre el Formación en la nube de AWS consola, seleccione la pila llamada LLMAgentStack (o el nombre personalizado que haya elegido).
• Elegir Borrar
• Verifique que la pila se elimine de la consola de CloudFormation.

Importante: Vuelva a verificar que la pila se haya eliminado correctamente asegurándose de que el Flan-UL2 Se elimina el punto final de inferencia.

• Para comprobarlo, vaya a Consola de AWS > Sagemaker > Puntos finales > Inferencia página.
• La página debe enumerar todos los puntos finales activos.
• Cerciorarse sm-jumpstart-flan-bot-punto final no existe como en la siguiente captura de pantalla.

Consideraciones para la producción

La implementación de agentes LLM en producción requiere tomar medidas adicionales para garantizar la confiabilidad, el rendimiento y la mantenibilidad. A continuación se presentan algunas consideraciones antes de implementar agentes en producción:

• Seleccionar el modelo LLM para alimentar el bucle del agente: Para la solución discutida en esta publicación, utilizamos un Flan-UL2 modelo sin realizar ajustes para realizar la planificación de tareas o la selección de herramientas. En la práctica, el uso de un LLM que esté ajustado para generar directamente solicitudes de herramientas o API puede aumentar la confiabilidad y el rendimiento, así como simplificar el desarrollo. Podríamos ajustar un LLM en tareas de selección de herramientas o usar un modelo que decodifique directamente tokens de herramientas como Toolformer.
  • El uso de modelos optimizados también puede simplificar la adición, eliminación y actualización de herramientas disponibles para un agente. Con enfoques basados únicamente en mensajes, la actualización de herramientas requiere modificar cada mensaje dentro del orquestador del agente, como los de planificación de tareas, análisis de herramientas y envío de herramientas. Esto puede resultar engorroso y el rendimiento puede degradarse si se proporcionan demasiadas herramientas en el contexto del LLM.
• Fiabilidad y rendimiento: Los agentes LLM pueden ser poco confiables, especialmente para tareas complejas que no se pueden completar en unos pocos ciclos. Agregar validaciones de salida, reintentos, estructurar salidas de LLM en JSON o yaml y aplicar tiempos de espera para proporcionar vías de escape para los LLM atrapados en bucles puede mejorar la confiabilidad.

Conclusión

En esta publicación, exploramos cómo crear un agente LLM que pueda utilizar múltiples herramientas desde cero, utilizando ingeniería de avisos de bajo nivel, funciones de AWS Lambda y SageMaker JumpStart como componentes básicos. Discutimos en detalle la arquitectura de los agentes LLM y el bucle de agentes. Los conceptos y la arquitectura de la solución presentados en esta publicación de blog pueden ser apropiados para agentes que utilizan una pequeña cantidad de un conjunto predefinido de herramientas. También discutimos varias estrategias para usar agentes en producción. Agents for Bedrock, que está en versión preliminar, también proporciona una experiencia administrada para crear agentes con soporte nativo para invocaciones de herramientas de agentes.

Sobre el Autor

Juan Hwang es un arquitecto de IA generativa en AWS con especial énfasis en aplicaciones de modelos de lenguaje grande (LLM), bases de datos vectoriales y estrategias de productos de IA generativa. Le apasiona ayudar a las empresas con el desarrollo de productos de IA/ML y el futuro de los agentes y copilotos de LLM. Antes de unirse a AWS, fue gerente de producto en Alexa, donde ayudó a llevar la IA conversacional a dispositivos móviles, además de operador de derivados en Morgan Stanley. Tiene una licenciatura en informática de la Universidad de Stanford.