Erfahren Sie, wie Sie mithilfe von AWS SageMaker JumpStart Foundation-Modellen werkzeugbasierte LLM-Agenten erstellen und bereitstellen

LLM-Agenten (Large Language Model) sind Programme, die die Fähigkeiten eigenständiger LLMs erweitern, indem sie 1) auf externe Tools (APIs, Funktionen, Webhooks, Plugins usw.) zugreifen und 2) Aufgaben selbst planen und ausführen können -gesteuerte Mode. Oftmals müssen LLMs mit anderer Software, Datenbanken oder APIs interagieren, um komplexe Aufgaben zu erfüllen. Beispielsweise würde ein administrativer Chatbot, der Besprechungen plant, Zugriff auf die Kalender und E-Mails der Mitarbeiter benötigen. Durch den Zugriff auf Tools können LLM-Agenten leistungsfähiger werden – auf Kosten zusätzlicher Komplexität.

In diesem Beitrag stellen wir LLM-Agenten vor und zeigen, wie man mit Amazon SageMaker JumpStart und AWS Lambda einen E-Commerce-LLM-Agenten erstellt und bereitstellt. Der Agent wird Tools verwenden, um neue Funktionen bereitzustellen, z. B. die Beantwortung von Fragen zu Retouren („Ist meine Retoure?“) rtn001 verarbeitet?“) und Bereitstellung von Aktualisierungen zu Bestellungen („Könnten Sie mir sagen, ob eine Bestellung vorliegt?“) 123456 wurde verschickt?"). Diese neuen Funktionen erfordern, dass LLMs Daten aus mehreren Datenquellen abrufen (Aufträge, kehrt zurück) und Retrieval Augmented Generation (RAG) durchführen.

Um den LLM-Agenten zu betreiben, verwenden wir a Flan-UL2 Modell, das als SageMaker-Endpunkt bereitgestellt wird, und verwenden Sie mit AWS Lambda erstellte Datenabruftools. Der Agent kann anschließend in Amazon Lex integriert und als Chatbot innerhalb von Websites oder AWS Connect verwendet werden. Wir schließen den Beitrag mit Punkten ab, die vor der Bereitstellung von LLM-Agenten in der Produktion zu berücksichtigen sind. Für eine vollständig verwaltete Erfahrung beim Erstellen von LLM-Agenten stellt AWS auch die Funktion „Agenten für Amazon Bedrock“ bereit (in der Vorschau).

Ein kurzer Überblick über LLM-Agent-Architekturen

LLM-Agenten sind Programme, die LLMs verwenden, um zu entscheiden, wann und wie Tools bei Bedarf zur Erledigung komplexer Aufgaben eingesetzt werden. Mithilfe von Tools und Fähigkeiten zur Aufgabenplanung können LLM-Agenten mit externen Systemen interagieren und traditionelle Einschränkungen von LLMs wie Wissenslücken, Halluzinationen und ungenaue Berechnungen überwinden. Tools können verschiedene Formen annehmen, z. B. API-Aufrufe, Python-Funktionen oder Webhook-basierte Plugins. Beispielsweise kann ein LLM ein „Abruf-Plugin“ verwenden, um relevanten Kontext abzurufen und RAG durchzuführen.

Was bedeutet es also für einen LLM, Werkzeuge auszuwählen und Aufgaben zu planen? Es gibt zahlreiche Ansätze (z Reagieren, MRKL, Werkzeugformer, UmarmenGPT, Und Transformer-Agents) zur Verwendung von LLMs mit Tools, und die Fortschritte erfolgen rasant. Eine einfache Möglichkeit besteht jedoch darin, einen LLM mit einer Liste von Tools aufzufordern und ihn zu bitten, festzustellen, 1) ob ein Tool benötigt wird, um die Benutzeranfrage zu erfüllen, und wenn ja, 2) das entsprechende Tool auszuwählen. Eine solche Eingabeaufforderung sieht normalerweise wie das folgende Beispiel aus und kann Beispiele mit wenigen Schüssen enthalten, um die Zuverlässigkeit des LLM bei der Auswahl des richtigen Werkzeugs zu verbessern.

''' Ihre Aufgabe besteht darin, ein Tool zur Beantwortung einer Benutzerfrage auszuwählen. Sie haben Zugriff auf die folgenden Tools. Suche: Suche nach einer Antwort in den FAQs. Reihenfolge: Artikel bestellen. Noop: Es wird kein Werkzeug benötigt. {ein paar Beispiele} Frage: {Eingabe} Werkzeug: '''

Komplexere Ansätze beinhalten die Verwendung eines spezialisierten LLM, das „API-Aufrufe“ oder „Tool-Nutzung“ direkt dekodieren kann, z GorillaLLM. Solche fein abgestimmten LLMs werden anhand von API-Spezifikationsdatensätzen trainiert, um API-Aufrufe basierend auf Anweisungen zu erkennen und vorherzusagen. Häufig erfordern diese LLMs einige Metadaten zu verfügbaren Tools (Beschreibungen, Yaml oder JSON-Schema für ihre Eingabeparameter), um Toolaufrufe auszugeben. Dieser Ansatz wird von Agenten für Amazon Bedrock und verfolgt OpenAI-Funktionsaufrufe. Beachten Sie, dass LLMs im Allgemeinen ausreichend groß und komplex sein müssen, um die Fähigkeit zur Werkzeugauswahl zu zeigen.

Unter der Annahme, dass Aufgabenplanungs- und Werkzeugauswahlmechanismen gewählt werden, funktioniert ein typisches LLM-Agentenprogramm in der folgenden Reihenfolge:

1. Benutzeranfrage – Das Programm nimmt eine Benutzereingabe wie „Wo ist meine Bestellung“ entgegen 123456?“ aus einer Clientanwendung.
2. Planen Sie die nächste(n) Aktion(en) und wählen Sie die zu verwendenden Tools aus – Als nächstes verwendet das Programm eine Eingabeaufforderung, damit das LLM die nächste Aktion generiert, zum Beispiel „Schauen Sie in der Auftragstabelle nach mit“. OrdersAPI.“ Das LLM wird aufgefordert, einen Werkzeugnamen vorzuschlagen, z OrdersAPI aus einer vordefinierten Liste verfügbarer Tools und deren Beschreibungen. Alternativ könnte der LLM angewiesen werden, direkt einen API-Aufruf mit Eingabeparametern zu generieren, z OrdersAPI(12345).
   1. Beachten Sie, dass die nächste Aktion die Verwendung eines Tools oder einer API beinhalten kann oder auch nicht. Wenn nicht, würde das LLM auf Benutzereingaben reagieren, ohne zusätzlichen Kontext von Tools einzubeziehen, oder einfach eine vorgefertigte Antwort zurückgeben, z. B. „Ich kann diese Frage nicht beantworten.“
3. Analysetool-Anfrage – Als nächstes müssen wir die vom LLM vorgeschlagene Werkzeug-/Aktionsvorhersage analysieren und validieren. Eine Validierung ist erforderlich, um sicherzustellen, dass Toolnamen, APIs und Anforderungsparameter nicht halluziniert werden und dass die Tools gemäß der Spezifikation ordnungsgemäß aufgerufen werden. Für diese Analyse ist möglicherweise ein separater LLM-Aufruf erforderlich.
4. Werkzeug aufrufen – Sobald gültige(r) Werkzeugname(n) und Parameter sichergestellt sind, rufen wir das Werkzeug auf. Dies kann eine HTTP-Anfrage, ein Funktionsaufruf usw. sein.
5. Ausgabe analysieren – Die Antwort des Tools erfordert möglicherweise eine zusätzliche Verarbeitung. Beispielsweise kann ein API-Aufruf zu einer langen JSON-Antwort führen, bei der nur eine Teilmenge der Felder für das LLM von Interesse ist. Das Extrahieren von Informationen in einem sauberen, standardisierten Format kann dem LLM helfen, das Ergebnis zuverlässiger zu interpretieren.
6. Ausgabe interpretieren – Angesichts der Ausgabe des Tools wird das LLM erneut aufgefordert, einen Sinn daraus zu ziehen und zu entscheiden, ob es die endgültige Antwort an den Benutzer zurückgenerieren kann oder ob zusätzliche Maßnahmen erforderlich sind.
7. Beenden Sie den Vorgang oder fahren Sie mit Schritt 2 fort – Geben Sie bei Fehlern oder Zeitüberschreitungen entweder eine endgültige Antwort oder eine Standardantwort zurück.

Verschiedene Agenten-Frameworks führen den bisherigen Programmablauf unterschiedlich aus. Zum Beispiel, Reagieren kombiniert die Werkzeugauswahl und die endgültige Antwortgenerierung in einer einzigen Eingabeaufforderung, im Gegensatz zur Verwendung separater Eingabeaufforderungen für die Werkzeugauswahl und die Antwortgenerierung. Außerdem kann diese Logik in einem einzigen Durchgang oder in einer while-Anweisung (der „Agentenschleife“) ausgeführt werden, die beendet wird, wenn die endgültige Antwort generiert wird, eine Ausnahme ausgelöst wird oder eine Zeitüberschreitung auftritt. Was immer gleich bleibt, ist, dass Agenten das LLM als Herzstück nutzen, um die Planung und Tool-Aufrufe zu orchestrieren, bis die Aufgabe beendet ist. Als Nächstes zeigen wir, wie Sie mithilfe von AWS-Diensten eine einfache Agentenschleife implementieren.

Lösungsüberblick

Für diesen Blogbeitrag implementieren wir einen E-Commerce-Support-LLM-Agenten, der zwei auf Tools basierende Funktionalitäten bereitstellt:

• Tool zum Abrufen des Rückgabestatus – Beantworten Sie Fragen zum Status der Rücksendungen, z. B. „Was passiert mit meiner Rücksendung?“ rtn001?“
• Tool zum Abrufen des Bestellstatus – Verfolgen Sie den Status von Bestellungen, z. B. „Wie ist der Status meiner Bestellung?“ 123456?“

Der Agent nutzt den LLM effektiv als Abfragerouter. Bei einer Anfrage („Wie ist der Status der Bestellung?“) 123456?“), wählen Sie das entsprechende Abruftool aus, um mehrere Datenquellen (d. h. Retouren und Bestellungen) abzufragen. Wir erreichen die Abfrageweiterleitung, indem wir den LLM zwischen mehreren Abruftools auswählen lassen, die für die Interaktion mit einer Datenquelle und das Abrufen des Kontexts verantwortlich sind. Dies erweitert das einfache RAG-Muster, das eine einzelne Datenquelle voraussetzt.

Bei beiden Abruftools handelt es sich um Lambda-Funktionen, die eine ID (Auftragsnummer oder returnId) als Eingabe, ruft ein JSON-Objekt aus der Datenquelle ab und konvertiert das JSON in eine benutzerfreundliche Darstellungszeichenfolge, die für die Verwendung durch LLM geeignet ist. Die Datenquelle in einem realen Szenario könnte eine hoch skalierbare NoSQL-Datenbank wie DynamoDB sein, aber diese Lösung verwendet einfaches Python Diktat mit Beispieldaten für Demozwecke.

Dem Agenten können zusätzliche Funktionen hinzugefügt werden, indem Abruftools hinzugefügt und Eingabeaufforderungen entsprechend geändert werden. Dieser Agent kann als eigenständiger Dienst getestet werden, der über HTTP in jede Benutzeroberfläche integriert werden kann, was mit Amazon Lex problemlos möglich ist.

Hier sind einige zusätzliche Details zu den Schlüsselkomponenten:

1. LLM-Inferenzendpunkt – Der Kern eines Agentenprogramms ist ein LLM. Wir werden den SageMaker JumpStart Foundation Model Hub verwenden, um das einfach bereitzustellen Flan-UL2 Modell. SageMaker JumpStart erleichtert die Bereitstellung von LLM-Inferenzendpunkten auf dedizierten SageMaker-Instanzen.
2. Agent-Orchestrator – Der Agent Orchestrator orchestriert die Interaktionen zwischen dem LLM, den Tools und der Client-App. Für unsere Lösung verwenden wir eine AWS Lambda-Funktion, um diesen Fluss zu steuern, und setzen die folgenden als Hilfsfunktionen ein.
   • Aufgaben-(Werkzeug-)Planer – Der Aufgabenplaner schlägt mithilfe des LLM eine der folgenden Optionen vor: 1) Rücksendeanfrage, 2) Bestellanfrage oder 3) kein Werkzeug. Wir nutzen ausschließlich Prompt Engineering und Flan-UL2 Modell im Ist-Zustand ohne Feinabstimmung.
   • Tool-Parser – Der Werkzeugparser stellt sicher, dass der Werkzeugvorschlag vom Aufgabenplaner gültig ist. Insbesondere stellen wir sicher, dass eine einzige Auftragsnummer oder returnId kann analysiert werden. Andernfalls antworten wir mit einer Standardnachricht.
   • Werkzeugdisponent – Der Tool-Dispatcher ruft Tools (Lambda-Funktionen) mit den gültigen Parametern auf.
   • Ausgabeparser – Der Ausgabeparser bereinigt und extrahiert relevante Elemente aus JSON in eine für Menschen lesbare Zeichenfolge. Diese Aufgabe wird sowohl von jedem Abruftool als auch innerhalb des Orchestrators erledigt.
   • Ausgabeinterpreter – Die Aufgabe des Ausgabeinterpreters besteht darin, 1) die Ausgabe des Toolaufrufs zu interpretieren und 2) zu bestimmen, ob die Benutzeranforderung erfüllt werden kann oder zusätzliche Schritte erforderlich sind. Im letzteren Fall wird separat eine endgültige Antwort generiert und an den Benutzer zurückgegeben.

Lassen Sie uns nun etwas tiefer in die Schlüsselkomponenten eintauchen: Agent Orchestrator, Task Planner und Tool Dispatcher.

Agent-Orchestrator

Nachfolgend finden Sie eine Kurzversion der Agentenschleife innerhalb der Lambda-Funktion des Agenten-Orchestrators. Die Schleife verwendet Hilfsfunktionen wie task_planner oder tool_parser, um die Aufgaben zu modularisieren. Die Schleife ist hier so ausgelegt, dass sie höchstens zweimal läuft, um zu verhindern, dass das LLM unnötig lange in einer Schleife hängenbleibt.

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

Aufgabenplaner (Werkzeugvorhersage)

Der Agent-Orchestrator verwendet Aufgabenplaner um ein Abruftool basierend auf Benutzereingaben vorherzusagen. Für unseren LLM-Agenten verwenden wir einfach Prompt Engineering und wenige Shot-Prompts, um dem LLM diese Aufgabe im Kontext beizubringen. Anspruchsvollere Agenten könnten ein fein abgestimmtes LLM für die Werkzeugvorhersage verwenden, was den Rahmen dieses Beitrags sprengen würde. Die Eingabeaufforderung lautet wie folgt:

tool_selection_prompt_template = „““ Ihre Aufgabe besteht darin, geeignete Tools auszuwählen, um den Benutzereingaben gerecht zu werden. Wenn kein Tool erforderlich ist, wählen Sie „no_tool“ aus. Verfügbare Tools sind: returns_inquiry: Datenbank mit Informationen über den Status einer bestimmten Retoure, ob sie aussteht, bearbeitet wird, usw. order_inquiry: Informationen über den Status einer bestimmten Bestellung, wie z. B. Versandstatus, Produkt, Menge usw. no_tool: Es wird kein Tool benötigt, um die Benutzereingabe zu beantworten. Sie können mehrere Tools vorschlagen, durch ein Komma getrennt. Beispiele: Benutzer: " Wie sind Ihre Geschäftszeiten? returns_inquiry user: „Wie hoch war die Bestellsumme für Bestellung 38745?“ Tool: order_inquiry user: „Kann ich meine Bestellung 38756 gemäß den Shop-Richtlinien zurückgeben?“ tool: order_inquiry user: „Hallo“ tool: no_tool user: „Sind Sie eine KI?“ ?" Tool: no_tool Benutzer: „Wie ist das Wetter?" Tool: no_tool Benutzer: „Wie ist der Rückerstattungsstatus der Bestellung 12347?“ Tool: order_inquiry Benutzer: „Wie ist der Rückerstattungsstatus der Rücksendung ret172?“ Tool: returns_inquiry Benutzereingabe : {} Werkzeug: """

Werkzeugdisponent

Der Werkzeugversandmechanismus funktioniert über ansonsten Logik zum Aufrufen geeigneter Lambda-Funktionen abhängig vom Namen des Tools. Das Folgende ist tool_dispatch Implementierung der Hilfsfunktion. Es wird im Inneren verwendet Agent Schleife und gibt die Rohantwort von der Lambda-Funktion des Tools zurück, die dann von einer bereinigt wird Ausgabeparser Funktion.

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

Stellen Sie die Lösung bereit

Wichtige Voraussetzungen – Um mit der Bereitstellung beginnen zu können, müssen Sie die folgenden Voraussetzungen erfüllen:

• Zugriff auf die AWS-Managementkonsole über einen Benutzer, der AWS CloudFormation-Stacks starten kann
• Vertrautheit mit der Navigation AWS Lambda Und Amazon Lex Konsolen
• Flan-UL2 erfordert eine einzelne ml.g5,12xgroß für die Bereitstellung, was möglicherweise eine Erhöhung der Ressourcenlimits über ein Support-Ticket erforderlich machen kann. In unserem Beispiel verwenden wir us-east-1 Stellen Sie daher sicher, dass Sie das Servicekontingent (falls erforderlich) erhöhen us-east-1.

Bereitstellung mit CloudFormation – Sie können die Lösung bereitstellen us-east-1 indem Sie auf die Schaltfläche unten klicken:

Die Bereitstellung der Lösung dauert etwa 20 Minuten und erstellt eine LLMAgentStack Stapel, der:

• stellt den SageMaker-Endpunkt mit bereit Flan-UL2 Modell von SageMaker JumpStart;
• stellt drei Lambda-Funktionen bereit: LLMAgentOrchestrator, LLMAgentReturnsTool, LLMAgentOrdersTool; Und
• stellt eine bereit AWS Lex Bot, mit dem der Agent getestet werden kann: Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot.

Testen Sie die Lösung

Der Stack stellt einen Amazon Lex-Bot mit dem Namen bereit Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. Mit dem Bot kann der Agent End-to-End getestet werden. Hier finden Sie eine zusätzliche umfassende Anleitung zum Testen von AWS Amazon Lex-Bots mit einer Lambda-Integration und wie die Integration auf hohem Niveau funktioniert. Aber kurz gesagt, der Amazon Lex-Bot ist eine Ressource, die eine schnelle Benutzeroberfläche zum Chatten mit dem LLM-Agenten bereitstellt, der in einer von uns erstellten Lambda-Funktion ausgeführt wird (LLMAgentOrchestrator).

Die zu berücksichtigenden Beispieltestfälle sind wie folgt:

• Gültige Bestellanfrage (z. B. „Für welchen Artikel wurde bestellt?“) 123456?)
  • Die Bestellung „123456“ ist eine gültige Bestellung, daher sollten wir mit einer angemessenen Antwort rechnen (z. B. „Kräuter-Handseife“).
• Gültige Rücksendeanfrage für eine Rückkehr (z. B. „Wann ist meine Rückkehr?“) rtn003 verarbeitet?")
  • Wir sollten eine angemessene Antwort zum Status der Rücksendung erwarten.
• Für Rücksendungen oder Bestellungen egal (zum Beispiel: „Wie ist das Wetter gerade in Schottland?“)
  • Eine irrelevante Frage zu Rücksendungen oder Bestellungen, daher sollte eine Standardantwort zurückgegeben werden („Leider kann ich diese Frage nicht beantworten.“)
• Ungültige Bestellanfrage (z. B. „Für welchen Artikel wurde bestellt?“) 383833?)
  • Die ID 383832 existiert nicht im Bestelldatensatz und daher sollten wir ordnungsgemäß fehlschlagen (z. B. „Bestellung nicht gefunden. Bitte überprüfen Sie Ihre Bestell-ID.“)
• Ungültige Rücksendeanfrage (zum Beispiel: „Wann bin ich zurück? rtn123 verarbeitet?")
  • Ebenso id rtn123 ist im Rückgabedatensatz nicht vorhanden und sollte daher ordnungsgemäß fehlschlagen.
• Irrelevante Rücksendeanfrage (zum Beispiel: „Welche Auswirkungen hat die Rückkehr?“) rtn001 zum Weltfrieden?“)
  • Diese Frage scheint sich zwar auf eine gültige Anordnung zu beziehen, ist aber irrelevant. Das LLM wird verwendet, um Fragen mit irrelevantem Kontext zu filtern.

Um diese Tests selbst durchzuführen, finden Sie hier die Anweisungen.

1. Auf der Amazon Lex-Konsole (AWS-Konsole > Amazon Lex), navigieren Sie zum Bot mit dem Titel Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. Dieser Bot wurde bereits für den Aufruf konfiguriert LLMAgentOrchestrator Lambda-Funktion, wann immer die FallbackIntent ausgelöst wird.
2. Wählen Sie im Navigationsbereich Absichten.
   
3. Wählen Bauen in der oberen rechten Ecke
   
4. 4. Warten Sie, bis der Erstellungsprozess abgeschlossen ist. Wenn der Vorgang abgeschlossen ist, erhalten Sie eine Erfolgsmeldung, wie im folgenden Screenshot dargestellt.
   
5. Testen Sie den Bot, indem Sie die Testfälle eingeben.
   

Aufräumen

Um zusätzliche Kosten zu vermeiden, löschen Sie die von unserer Lösung erstellten Ressourcen, indem Sie die folgenden Schritte ausführen:

• Auf der AWS CloudFormation Wählen Sie in der Konsole den Stapel mit dem Namen aus LLMAgentStack (oder der von Ihnen gewählte benutzerdefinierte Name).
• Wählen Löschen
• Überprüfen Sie, ob der Stack aus der CloudFormation-Konsole gelöscht wurde.

Wichtig: Überprüfen Sie noch einmal, ob der Stapel erfolgreich gelöscht wurde, indem Sie sicherstellen, dass der Flan-UL2 Der Inferenzendpunkt wird entfernt.

• Um dies zu überprüfen, gehen Sie zu AWS-Konsole > Sagemaker > Endpunkte > Inferenz Seite.
• Die Seite sollte alle aktiven Endpunkte auflisten.
• Stellen Sie sicher sm-jumpstart-flan-bot-endpoint existiert nicht wie im folgenden Screenshot.

Überlegungen zur Produktion

Die Bereitstellung von LLM-Agenten in der Produktion erfordert zusätzliche Schritte, um Zuverlässigkeit, Leistung und Wartbarkeit sicherzustellen. Hier sind einige Überlegungen vor der Bereitstellung von Agenten in der Produktion:

• Auswahl des LLM-Modells zur Stromversorgung der Agentenschleife: Für die in diesem Beitrag besprochene Lösung haben wir a verwendet Flan-UL2 Modell ohne Feinabstimmung zur Aufgabenplanung oder Werkzeugauswahl. In der Praxis kann die Verwendung eines LLM, das auf die direkte Ausgabe von Tool- oder API-Anfragen abgestimmt ist, die Zuverlässigkeit und Leistung erhöhen und die Entwicklung vereinfachen. Wir könnten ein LLM auf Werkzeugauswahlaufgaben verfeinern oder ein Modell verwenden, das Werkzeug-Tokens wie Toolformer direkt dekodiert.
  • Die Verwendung fein abgestimmter Modelle kann auch das Hinzufügen, Entfernen und Aktualisieren von Tools, die einem Agenten zur Verfügung stehen, vereinfachen. Bei Ansätzen, die nur auf Eingabeaufforderungen basieren, erfordert die Aktualisierung von Tools die Änderung aller Eingabeaufforderungen im Agent Orchestrator, z. B. für die Aufgabenplanung, Toolanalyse und Toolverteilung. Dies kann umständlich sein und die Leistung kann sich verschlechtern, wenn im Kontext des LLM zu viele Tools bereitgestellt werden.
• Zuverlässigkeit und Leistung: LLM-Agenten können unzuverlässig sein, insbesondere bei komplexen Aufgaben, die nicht innerhalb weniger Schleifen erledigt werden können. Das Hinzufügen von Ausgabevalidierungen, Wiederholungsversuchen, die Strukturierung von Ausgaben von LLMs in JSON oder Yaml und die Durchsetzung von Zeitüberschreitungen, um Notausstiege für in Schleifen hängende LLMs bereitzustellen, können die Zuverlässigkeit erhöhen.

Abschluss

In diesem Beitrag haben wir untersucht, wie man einen LLM-Agenten erstellt, der mehrere Tools von Grund auf nutzen kann, indem wir Low-Level-Prompt-Engineering, AWS Lambda-Funktionen und SageMaker JumpStart als Bausteine verwenden. Wir haben die Architektur von LLM-Agenten und die Agentenschleife ausführlich besprochen. Die in diesem Blogbeitrag vorgestellten Konzepte und Lösungsarchitekturen eignen sich möglicherweise für Agenten, die eine kleine Anzahl vordefinierter Tools verwenden. Wir haben auch verschiedene Strategien für den Einsatz von Agenten in der Produktion besprochen. Agents for Bedrock, das sich in der Vorschau befindet, bietet auch eine verwaltete Erfahrung für die Erstellung von Agenten mit nativer Unterstützung für Agenten-Tool-Aufrufe.

Über den Autor

John Hwang ist ein generativer KI-Architekt bei AWS mit besonderem Fokus auf Large Language Model (LLM)-Anwendungen, Vektordatenbanken und generative KI-Produktstrategie. Seine Leidenschaft besteht darin, Unternehmen bei der KI/ML-Produktentwicklung und der Zukunft von LLM-Agenten und Co-Piloten zu unterstützen. Bevor er zu AWS kam, war er Produktmanager bei Alexa, wo er dabei half, Konversations-KI auf mobile Geräte zu bringen, sowie Derivatehändler bei Morgan Stanley. Er hat einen Bachelor-Abschluss in Informatik von der Stanford University.