Scopri come creare e distribuire agenti LLM che utilizzano strumenti utilizzando AWS SageMaker JumpStart Foundation Models

Gli agenti LLM (Large Language Model) sono programmi che estendono le capacità dei LLM autonomi con 1) accesso a strumenti esterni (API, funzioni, webhook, plug-in e così via) e 2) la capacità di pianificare ed eseguire attività in modo autonomo -moda diretta. Spesso gli LLM devono interagire con altri software, database o API per svolgere attività complesse. Ad esempio, un chatbot amministrativo che pianifica riunioni richiederebbe l'accesso ai calendari e alla posta elettronica dei dipendenti. Con l'accesso agli strumenti, gli agenti LLM possono diventare più potenti, al costo di ulteriore complessità.

In questo post, presentiamo gli agenti LLM e dimostriamo come creare e distribuire un agente LLM per l'e-commerce utilizzando Amazon SageMaker JumpStart e AWS Lambda. L'agente utilizzerà strumenti per fornire nuove funzionalità, come rispondere a domande sui resi (“È il mio reso rtn001 elaborato?") e fornire aggiornamenti sugli ordini ("Potresti dirmi se order 123456 ha spedito?"). Queste nuove funzionalità richiedono che gli LLM recuperino dati da più origini dati (ordini, ritorna) ed eseguire il recupero della generazione aumentata (RAG).

Per alimentare l'agente LLM, utilizziamo a Flan-UL2 modello distribuito come endpoint SageMaker e utilizza strumenti di recupero dati creati con AWS Lambda. L'agente può successivamente essere integrato con Amazon Lex e utilizzato come chatbot all'interno di siti Web o AWS Connect. Concludiamo il post con gli elementi da considerare prima di distribuire gli agenti LLM in produzione. Per un'esperienza completamente gestita per la creazione di agenti LLM, AWS fornisce anche gli agenti per la funzionalità Amazon Bedrock (in anteprima).

Una breve panoramica delle architetture degli agenti LLM

Gli agenti LLM sono programmi che utilizzano LLM per decidere quando e come utilizzare gli strumenti necessari per completare attività complesse. Con strumenti e capacità di pianificazione delle attività, gli agenti LLM possono interagire con sistemi esterni e superare i limiti tradizionali dei LLM, come interruzioni della conoscenza, allucinazioni e calcoli imprecisi. Gli strumenti possono assumere diverse forme, come chiamate API, funzioni Python o plug-in basati su webhook. Ad esempio, un LLM può utilizzare un "plug-in di recupero" per recuperare il contesto pertinente ed eseguire RAG.

Allora cosa significa per un LLM scegliere strumenti e pianificare attività? Esistono numerosi approcci (es Reagire, MRKL, Strumento formatore, AbbracciandoGPT, E Agente trasformatores) all'utilizzo degli LLM con strumenti e i progressi stanno avvenendo rapidamente. Ma un modo semplice è quello di richiedere a un LLM un elenco di strumenti e chiedergli di determinare 1) se uno strumento è necessario per soddisfare la query dell'utente e, in tal caso, 2) selezionare lo strumento appropriato. Tale richiesta in genere assomiglia all'esempio seguente e può includere esempi di poche riprese per migliorare l'affidabilità di LLM nella scelta dello strumento giusto.

''' Il tuo compito è selezionare uno strumento per rispondere a una domanda dell'utente. Hai accesso ai seguenti strumenti. search: cerca una risposta nelle FAQ order: ordina gli articoli noop: non è necessario alcuno strumento {alcuni esempi di riprese} Domanda: {input} Strumento: '''

Approcci più complessi prevedono l'utilizzo di un LLM specializzato in grado di decodificare direttamente le "chiamate API" o l'"utilizzo di strumenti", ad esempio GorillaLLM. Tali LLM ottimizzati vengono addestrati sui set di dati delle specifiche API per riconoscere e prevedere le chiamate API in base alle istruzioni. Spesso, questi LLM richiedono alcuni metadati sugli strumenti disponibili (descrizioni, yaml o schema JSON per i parametri di input) per restituire le invocazioni degli strumenti. Questo approccio è adottato dagli agenti per Amazon Bedrock e Chiamate di funzione OpenAI. Si noti che i LLM generalmente devono essere sufficientemente grandi e complessi per mostrare capacità di selezione degli strumenti.

Supponendo che vengano scelti i meccanismi di pianificazione delle attività e di selezione degli strumenti, un tipico programma agente LLM funziona nella seguente sequenza:

1. Richiesta dell'utente – Il programma accetta un input dell'utente come “Dov'è il mio ordine 123456?” da alcune applicazioni client.
2. Pianifica le azioni successive e seleziona gli strumenti da utilizzare – Successivamente, il programma utilizza un prompt per fare in modo che LLM generi l'azione successiva, ad esempio "Cerca la tabella degli ordini utilizzando API degli ordini.” A LLM viene richiesto di suggerire un nome strumento come API degli ordini da un elenco predefinito di strumenti disponibili e dalle relative descrizioni. In alternativa, è possibile istruire l'LLM a generare direttamente una chiamata API con parametri di input come OrdiniAPI(12345).
   1. Tieni presente che l'azione successiva potrebbe comportare o meno l'utilizzo di uno strumento o di un'API. In caso contrario, LLM risponderebbe all'input dell'utente senza incorporare contesto aggiuntivo dagli strumenti o semplicemente restituirebbe una risposta predefinita come "Non posso rispondere a questa domanda".
3. Richiesta dello strumento di analisi – Successivamente, dobbiamo analizzare e convalidare la previsione dello strumento/azione suggerita dal LLM. La convalida è necessaria per garantire che i nomi degli strumenti, le API e i parametri della richiesta non siano allucinazioni e che gli strumenti vengano richiamati correttamente in base alle specifiche. Questa analisi potrebbe richiedere una chiamata LLM separata.
4. Strumento Richiama – Una volta assicurati i nomi e i parametri validi dello strumento, invochiamo lo strumento. Potrebbe trattarsi di una richiesta HTTP, di una chiamata di funzione e così via.
5. Analizza l'output – La risposta dello strumento potrebbe richiedere un'ulteriore elaborazione. Ad esempio, una chiamata API può comportare una lunga risposta JSON, in cui solo un sottoinsieme di campi interessa LLM. L'estrazione delle informazioni in un formato pulito e standardizzato può aiutare il LLM a interpretare il risultato in modo più affidabile.
6. Interpretare l'output – Dato l’output dello strumento, al LLM viene nuovamente chiesto di dargli un senso e decidere se può generare la risposta finale all’utente o se sono necessarie azioni aggiuntive.
7. Terminare o continuare con il passaggio 2 – Restituisce una risposta finale o una risposta predefinita in caso di errori o timeout.

Diversi framework di agenti eseguono il flusso del programma precedente in modo diverso. Per esempio, Reagire combina la selezione dello strumento e la generazione della risposta finale in un unico prompt, invece di utilizzare prompt separati per la selezione dello strumento e la generazione della risposta. Inoltre, questa logica può essere eseguita in un singolo passaggio o in un'istruzione while (il "loop dell'agente"), che termina quando viene generata la risposta finale, viene generata un'eccezione o si verifica un timeout. Ciò che rimane costante è che gli agenti utilizzano LLM come elemento centrale per orchestrare la pianificazione e le chiamate agli strumenti fino al termine dell'attività. Successivamente, mostriamo come implementare un semplice ciclo di agenti utilizzando i servizi AWS.

Panoramica della soluzione

Per questo post del blog, implementiamo un agente LLM di supporto e-commerce che fornisce due funzionalità basate su strumenti:

• Strumento di recupero dello stato del reso – Rispondi a domande sullo stato dei resi, ad esempio: “Cosa sta succedendo al mio reso rtn001?”
• Strumento di recupero dello stato dell'ordine – Tieni traccia dello stato degli ordini, ad esempio “Qual è lo stato del mio ordine 123456?”

L'agente utilizza effettivamente LLM come router di query. Data una query ("Qual è lo stato dell'ordine 123456?”), seleziona lo strumento di recupero appropriato per eseguire query su più origini dati (ovvero resi e ordini). Realizziamo l'instradamento delle query scegliendo LLM tra più strumenti di recupero, che sono responsabili dell'interazione con un'origine dati e del recupero del contesto. Ciò estende il modello RAG semplice, che presuppone un'unica origine dati.

Entrambi gli strumenti di recupero sono funzioni Lambda che accettano un id (ID ordine O returnId) come input, recupera un oggetto JSON dall'origine dati e converte il JSON in una stringa di rappresentazione intuitiva adatta per essere utilizzata da LLM. L'origine dati in uno scenario reale potrebbe essere un database NoSQL altamente scalabile come DynamoDB, ma questa soluzione utilizza Python semplice Dict con dati campione a scopo dimostrativo.

È possibile aggiungere ulteriori funzionalità all'agente aggiungendo Strumenti di recupero e modificando di conseguenza le richieste. Questo agente può essere testato come servizio autonomo che si integra con qualsiasi interfaccia utente su HTTP, operazione che può essere eseguita facilmente con Amazon Lex.

Ecco alcuni dettagli aggiuntivi sui componenti chiave:

1. Endpoint di inferenza LLM – Il nucleo di un programma agente è un LLM. Utilizzeremo l'hub del modello di base SageMaker JumpStart per distribuire facilmente il file Flan-UL2 modello. SageMaker JumpStart semplifica la distribuzione degli endpoint di inferenza LLM su istanze SageMaker dedicate.
2. Orchestratore dell'agente – L'agente di orchestrazione orchestra le interazioni tra LLM, strumenti e l'app client. Per la nostra soluzione, utilizziamo una funzione AWS Lambda per guidare questo flusso e utilizziamo le seguenti funzioni di supporto.
   • Pianificatore di attività (strumenti) – Il pianificatore di attività utilizza LLM per suggerire una tra 1) richiesta di reso, 2) richiesta di ordine o 3) nessuno strumento. Usiamo solo ingegneria tempestiva e Flan-UL2 modello così com'è senza messa a punto.
   • Analizzatore di strumenti – Il parser dello strumento garantisce che il suggerimento dello strumento dal pianificatore delle attività sia valido. In particolare, ci assicuriamo che un singolo ID ordine O returnId può essere analizzato. Altrimenti rispondiamo con un messaggio predefinito.
   • Distributore di strumenti – Il dispatcher degli strumenti richiama gli strumenti (funzioni Lambda) utilizzando i parametri validi.
   • Analizzatore di output – Il parser di output pulisce ed estrae gli elementi rilevanti da JSON in una stringa leggibile dall'uomo. Questa attività viene eseguita sia da ogni strumento di recupero sia all'interno dell'agente di orchestrazione.
   • Interprete di output – La responsabilità dell'interprete di output è 1) interpretare l'output dall'invocazione dello strumento e 2) determinare se la richiesta dell'utente può essere soddisfatta o se sono necessari passaggi aggiuntivi. In quest'ultimo caso, una risposta finale viene generata separatamente e restituita all'utente.

Ora analizziamo un po' più a fondo i componenti chiave: orchestratore dell'agente, pianificatore delle attività e dispatcher degli strumenti.

Orchestratore di agenti

Di seguito è riportata una versione abbreviata del loop dell'agente all'interno della funzione Lambda dell'agente di orchestrazione. Il ciclo utilizza funzioni di supporto come task_planner O tool_parser, per modularizzare i compiti. Il ciclo qui è progettato per essere eseguito al massimo due volte per evitare che LLM rimanga bloccato in un ciclo inutilmente lungo.

#.. 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
    }

Pianificatore di attività (previsione dello strumento)

L'agente di orchestrazione utilizza pianificatore di attività per prevedere uno strumento di recupero basato sull'input dell'utente. Per il nostro agente LLM, utilizzeremo semplicemente il prompt engineering e pochi suggerimenti per insegnare al LLM questo compito nel contesto. Agenti più sofisticati potrebbero utilizzare un LLM ottimizzato per la previsione degli strumenti, che va oltre lo scopo di questo post. La richiesta è la seguente:

tool_selection_prompt_template = """ Il tuo compito è selezionare gli strumenti appropriati per soddisfare l'input dell'utente. Se nessuno strumento è richiesto, seleziona "no_tool" Gli strumenti disponibili sono: return_inquiry: database di informazioni sullo stato di un reso specifico, se è in sospeso, elaborato, ecc. order_inquiry: informazioni sullo stato di un ordine specifico, come stato di spedizione, prodotto, importo, ecc. no_tool: non è necessario alcuno strumento per rispondere all'input dell'utente. Puoi suggerire più strumenti, separati da una virgola. Esempi: user: " Qual è il tuo orario di lavoro?" tool: no_tool user: "L'ordine 12345 è stato spedito?" tool: order_inquiry user: "È stato elaborato il reso ret812?" tool: return_inquiry user: "Quanti giorni ho prima della restituzione degli ordini?" tool: return_inquiry utente: "Qual era il totale dell'ordine per l'ordine 38745?" strumento: order_inquiry utente: "Posso restituire il mio ordine 38756 in base alla politica del negozio?" strumento: order_inquiry utente: "Ciao" strumento: no_tool utente: "Sei un'intelligenza artificiale ?" strumento: no_tool utente: "Che tempo fa?" strumento: no_tool utente: "Qual è lo stato del rimborso dell'ordine 12347?" strumento: order_inquiry utente: "Qual è lo stato del rimborso del reso ret172?" strumento: return_inquiry input dell'utente : {} attrezzo: """

Dispacciatore di strumenti

Il meccanismo di invio dello strumento funziona tramite se altro logica per chiamare le funzioni Lambda appropriate a seconda del nome dello strumento. Quello che segue è tool_dispatch implementazione della funzione di supporto. È usato all'interno del agente loop e restituisce la risposta grezza dalla funzione Lambda dello strumento, che viene quindi pulita da un file output_parser funzione.

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

Distribuisci la soluzione

Prerequisiti importanti – Per iniziare con la distribuzione, è necessario soddisfare i seguenti prerequisiti:

• Accesso alla Console di gestione AWS tramite un utente che può avviare stack AWS CloudFormation
• Familiarità con la navigazione in AWSLambda E AmazonLex console
• Flan-UL2 ne richiede uno singolo ml.g5,12xgrande per la distribuzione, che potrebbe richiedere l'aumento dei limiti delle risorse tramite un ticket di supporto. Nel nostro esempio, usiamo noi-est-1 come Regione, quindi assicurati di aumentare la quota di servizio (se necessario) in noi-est-1.

Distribuisci utilizzando CloudFormation – È possibile distribuire la soluzione a noi-est-1 cliccando il pulsante qui sotto:

La distribuzione della soluzione richiederà circa 20 minuti e creerà un file LLMAgentStack pila, che:

• distribuisce l'endpoint SageMaker utilizzando Flan-UL2 modello da SageMaker JumpStart;
• distribuisce tre funzioni Lambda: LLMAgentOrchestratore, LLMAgentReturnsTool, LLMAgentOrdersTool; E
• distribuisce un AWSLex bot che può essere utilizzato per testare l'agente: Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot.

Testare la soluzione

Lo stack distribuisce un bot Amazon Lex con il nome Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. Il bot può essere utilizzato per testare l'agente end-to-end. Ecco un'ulteriore guida completa per testare i bot AWS Amazon Lex con un'integrazione Lambda e come funziona l'integrazione ad alto livello. Ma in breve, il bot Amazon Lex è una risorsa che fornisce un'interfaccia utente rapida per chattare con l'agente LLM in esecuzione all'interno di una funzione Lambda che abbiamo creato (LLMAgentOrchestratore).

I casi di test di esempio da considerare sono i seguenti:

• Richiesta d'ordine valida (ad esempio: "Per quale articolo è stato ordinato 123456?”)
  • L'ordine "123456" è un ordine valido, quindi dovremmo aspettarci una risposta ragionevole (ad esempio "Sapone per le mani alle erbe")
• Richiesta di reso valida per un reso (ad esempio, "Quando è il mio reso rtn003 elaborato?")
  • Dovremmo aspettarci una risposta ragionevole sullo stato del reso.
• Irrilevante sia per i resi che per gli ordini (ad esempio, "Com'è il tempo in Scozia in questo momento?")
  • Una domanda irrilevante per resi o ordini, pertanto dovrebbe essere restituita una risposta predefinita ("Mi spiace, non posso rispondere a questa domanda.")
• Richiesta d'ordine non valida (ad esempio: "Per quale articolo è stato ordinato 383833?”)
  • L'ID 383832 non esiste nel set di dati degli ordini e quindi dovremmo fallire correttamente (ad esempio, "Ordine non trovato. Controlla il tuo ID ordine.")
• Richiesta di reso non valida (ad esempio: "Quando tornerò?" rtn123 elaborato?")
  • Allo stesso modo, id rtn123 non esiste nel set di dati dei rendimenti e quindi dovrebbe fallire correttamente.
• Richiesta di reso irrilevante (ad esempio: “Qual è l’impatto del rendimento? rtn001 sulla pace nel mondo?”)
  • Questa domanda, sebbene sembri riguardare un ordine valido, è irrilevante. Il LLM viene utilizzato per filtrare le domande con contesto irrilevante.

Per eseguire personalmente questi test, ecco le istruzioni.

1. Sulla console Amazon Lex (Console AWS > Amazon Lex), vai al bot intitolato Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. Questo bot è già stato configurato per chiamare il LLMAgentOrchestratore Funzione Lambda ogni volta che Intento di fallback E 'attivato.
2. Nel riquadro di navigazione, scegli Intenti.
   
3. Scegliere Costruire nell'angolo in alto a destra
   
4. 4. Attendi il completamento del processo di creazione. Al termine, riceverai un messaggio di successo, come mostrato nello screenshot seguente.
   
5. Testare il bot inserendo i casi di test.
   

Ripulire

Per evitare costi aggiuntivi, elimina le risorse create dalla nostra soluzione seguendo questi passaggi:

• Sul AWS CloudFormation console, seleziona lo stack denominato LLMAgentStack (o il nome personalizzato che hai scelto).
• Scegliere Eliminare
• Verifica che lo stack venga eliminato dalla console CloudFormation.

Importante: ricontrolla che lo stack sia stato eliminato correttamente assicurandoti che il file Flan-UL2 l'endpoint di inferenza viene rimosso.

• Per verificare, vai a Console AWS > Sagemaker > Endpoint > Inferenza pagina.
• La pagina dovrebbe elencare tutti gli endpoint attivi.
• Assicurarsi sm-jumpstart-flan-bot-endpoint non esiste come nello screenshot seguente.

Considerazioni sulla produzione

La distribuzione degli agenti LLM in produzione richiede l'adozione di misure aggiuntive per garantire affidabilità, prestazioni e manutenibilità. Di seguito sono riportate alcune considerazioni prima della distribuzione degli agenti in produzione:

• Selezione del modello LLM per alimentare il loop dell'agente: Per la soluzione discussa in questo post, abbiamo utilizzato a Flan-UL2 modello senza messa a punto per eseguire la pianificazione delle attività o la selezione degli strumenti. In pratica, l'utilizzo di un LLM ottimizzato per l'output diretto di richieste API o strumenti può aumentare l'affidabilità e le prestazioni, oltre a semplificare lo sviluppo. Potremmo mettere a punto un LLM sulle attività di selezione degli strumenti o utilizzare un modello che decodifica direttamente i token degli strumenti come Toolformer.
  • L'utilizzo di modelli ottimizzati può anche semplificare l'aggiunta, la rimozione e l'aggiornamento degli strumenti disponibili per un agente. Con approcci basati solo sui prompt, l'aggiornamento degli strumenti richiede la modifica di ogni prompt all'interno dell'agente di orchestrazione, come quelli per la pianificazione delle attività, l'analisi degli strumenti e l'invio degli strumenti. Questo può essere complicato e le prestazioni potrebbero peggiorare se vengono forniti troppi strumenti nel contesto del LLM.
• Affidabilità e prestazioni: Gli agenti LLM possono essere inaffidabili, soprattutto per attività complesse che non possono essere completate in pochi cicli. L'aggiunta di convalide di output, nuovi tentativi, la strutturazione di output da LLM in JSON o yaml e l'applicazione di timeout per fornire porte di fuga per LLM bloccati in loop possono migliorare l'affidabilità.

Conclusione

In questo post, abbiamo esplorato come creare un agente LLM in grado di utilizzare più strumenti da zero, utilizzando il prompt engineering di basso livello, le funzioni AWS Lambda e SageMaker JumpStart come elementi costitutivi. Abbiamo discusso in dettaglio l'architettura degli agenti LLM e il ciclo degli agenti. I concetti e l'architettura della soluzione introdotti in questo post del blog potrebbero essere appropriati per gli agenti che utilizzano un numero limitato di un set predefinito di strumenti. Abbiamo anche discusso diverse strategie per l'utilizzo degli agenti nella produzione. Agenti per Bedrock, disponibile in anteprima, fornisce anche un'esperienza gestita per la creazione di agenti con supporto nativo per le chiamate agli strumenti agenti.

Circa l'autore

Giovanni Hwang è un Generative AI Architect presso AWS con particolare attenzione alle applicazioni Large Language Model (LLM), ai database vettoriali e alla strategia di prodotto AI generativa. La sua passione è aiutare le aziende con lo sviluppo di prodotti AI/ML e il futuro degli agenti e dei copiloti LLM. Prima di entrare in AWS, è stato Product Manager presso Alexa, dove ha contribuito a portare l'intelligenza artificiale conversazionale sui dispositivi mobili, nonché trader di derivati presso Morgan Stanley. Ha conseguito la laurea in informatica presso la Stanford University.