Naučte se, jak sestavit a nasadit nástroj pomocí LLM agentů pomocí AWS SageMaker JumpStart Foundation Models

Agenti LLM (Large Language Model) jsou programy, které rozšiřují možnosti samostatných LLM 1) přístupem k externím nástrojům (API, funkce, webhooky, pluginy atd.) a 2) schopností plánovat a provádět úkoly samostatně. - režírovaná móda. LLM často potřebují spolupracovat s jiným softwarem, databázemi nebo rozhraními API, aby mohli provádět složité úkoly. Například administrativní chatbot, který plánuje schůzky, by vyžadoval přístup ke kalendářům a e-mailu zaměstnanců. S přístupem k nástrojům se mohou agenti LLM stát výkonnějšími – za cenu další složitosti.

V tomto příspěvku představujeme agenty LLM a ukazujeme, jak vytvořit a nasadit agenta LLM pro elektronický obchod pomocí Amazon SageMaker JumpStart a AWS Lambda. Agent použije nástroje k poskytování nových možností, jako je zodpovězení otázek o vracení zboží („Je můj návrat rtn001 zpracováno?“) a poskytování aktualizací o objednávkách („Mohl byste mi říct, zda objednávka 123456 odeslal?”). Tyto nové funkce vyžadují, aby LLM získávaly data z více zdrojů dat (objednávky, se vrací) a proveďte rozšířenou generaci (RAG).

K napájení agenta LLM používáme a Flan-UL2 model nasazený jako koncový bod SageMaker a používat nástroje pro získávání dat vytvořené pomocí AWS Lambda. Agent může být následně integrován s Amazon Lex a použit jako chatbot na webových stránkách nebo v AWS Connect. Příspěvek uzavíráme položkami, které je třeba zvážit před nasazením agentů LLM do výroby. Pro plně spravované prostředí pro vytváření LLM agentů poskytuje AWS také funkci agentů pro Amazon Bedrock (v náhledu).

Stručný přehled architektur LLM agentů

Agenti LLM jsou programy, které používají LLM k rozhodování, kdy a jak použít nástroje podle potřeby k dokončení složitých úkolů. Pomocí nástrojů a schopností plánování úkolů mohou agenti LLM interagovat s vnějšími systémy a překonat tradiční omezení LLM, jako jsou limity znalostí, halucinace a nepřesné výpočty. Nástroje mohou mít různé formy, jako jsou volání API, funkce Pythonu nebo pluginy založené na webhooku. LLM může například použít „zásuvný modul pro vyhledávání“ k načtení relevantního kontextu a provedení RAG.

Co tedy pro LLM znamená vybírat nástroje a plánovat úkoly? Existuje mnoho přístupů (např Reagovat, MRKL, nástrojař, ObjímáníGPT, a Agent Transformers) k používání LLM s nástroji a pokroky probíhají rychle. Ale jedním jednoduchým způsobem je požádat LLM o seznam nástrojů a požádat ho, aby určil, 1) zda je nástroj potřebný k uspokojení uživatelského dotazu, a pokud ano, 2) vybrat vhodný nástroj. Taková výzva obvykle vypadá jako následující příklad a může obsahovat několik příkladů pro zlepšení spolehlivosti LLM při výběru správného nástroje.

''' Vaším úkolem je vybrat nástroj pro odpověď na otázku uživatele. Máte přístup k následujícím nástrojům. hledat: hledat odpověď v pořadí nejčastějších dotazů: objednávat položky noop: není potřeba žádný nástroj {příklady několika snímků} Otázka: {input} Nástroj: '''

Složitější přístupy zahrnují použití specializovaného LLM, který dokáže přímo dekódovat „volání API“ nebo „použití nástroje“, jako např GorillaLLM. Takto vyladěné LLM jsou trénovány na datových sadách specifikace API, aby rozpoznávaly a předpovídaly volání API na základě instrukcí. Tyto LLM často vyžadují určitá metadata o dostupných nástrojích (popisy, yaml nebo schéma JSON pro jejich vstupní parametry), aby mohly vyvolat vyvolání nástroje. Tento přístup uplatňují agenti společnosti Amazon Bedrock a Volání funkcí OpenAI. Všimněte si, že LLM obecně musí být dostatečně velké a složité, aby prokázaly schopnost výběru nástroje.

Za předpokladu, že jsou vybrány mechanismy plánování úkolů a výběru nástrojů, funguje typický program agenta LLM v následujícím pořadí:

1. Žádost uživatele – Program převezme uživatelský vstup, například „Kde je moje objednávka 123456?" z nějaké klientské aplikace.
2. Naplánujte si další akce a vyberte nástroje, které chcete použít – Dále program použije výzvu, aby LLM vygeneroval další akci, například „Vyhledejte tabulku objednávek pomocí OrdersAPI.“ LLM je vyzván, aby navrhl název nástroje, např OrdersAPI z předdefinovaného seznamu dostupných nástrojů a jejich popisů. Alternativně může být LLM instruován, aby přímo generoval volání API se vstupními parametry, jako je např OrdersAPI(12345).
   1. Všimněte si, že další akce může nebo nemusí zahrnovat použití nástroje nebo rozhraní API. Pokud ne, LLM by reagovala na vstup uživatele bez začlenění dalšího kontextu z nástrojů nebo by jednoduše vrátila předpřipravenou odpověď, například: „Na tuto otázku nemohu odpovědět.“
3. Požadavek na analýzu nástroje – Dále musíme analyzovat a ověřit předpověď nástroje/akce navrženou LLM. Ověření je potřeba, aby se zajistilo, že názvy nástrojů, rozhraní API a parametry požadavků nebudou halucinované a že nástroje budou správně vyvolány podle specifikace. Tato analýza může vyžadovat samostatné volání LLM.
4. Nástroj Vyvolat – Jakmile jsou zajištěny platné názvy nástrojů a parametry, spustíme nástroj. Může to být požadavek HTTP, volání funkce a tak dále.
5. Analyzujte výstup – Odpověď z nástroje může vyžadovat další zpracování. Volání API může například vést k dlouhé odpovědi JSON, kde LLM zajímá pouze podmnožinu polí. Extrahování informací v čistém, standardizovaném formátu může pomoci LLM interpretovat výsledek spolehlivěji.
6. Interpretujte výstup – Vzhledem k výstupu z nástroje je LLM znovu vyzván, aby tomu dal smysl a rozhodl, zda může vygenerovat konečnou odpověď zpět uživateli nebo zda jsou nutné další akce.
7. Ukončete nebo pokračujte krokem 2 – V případě chyb nebo vypršení časového limitu buď vraťte konečnou odpověď, nebo výchozí odpověď.

Různé rámce agentů provádějí předchozí tok programu odlišně. Například, Reagovat kombinuje výběr nástroje a generování konečných odpovědí do jediné výzvy, na rozdíl od použití samostatných výzev pro výběr nástroje a generování odpovědí. Tuto logiku lze také spustit v jediném průchodu nebo v příkazu while („smyčka agenta“), která se ukončí, když je vygenerována konečná odpověď, je vyvolána výjimka nebo dojde k vypršení časového limitu. Co zůstává neměnné, je to, že agenti používají LLM jako hlavní nástroj k organizování plánování a vyvolání nástrojů, dokud úloha neskončí. Dále si ukážeme, jak implementovat jednoduchou smyčku agentů pomocí služeb AWS.

Přehled řešení

Pro tento blogový příspěvek implementujeme LLM agenta pro podporu elektronického obchodování, který poskytuje dvě funkce poháněné nástroji:

• Nástroj pro vyhledávání stavu návratu – Odpovězte na otázky o stavu návratů, jako například: „Co se děje s mým návratem rtn001?"
• Nástroj pro vyhledávání stavu objednávky – Sledujte stav objednávek, například „Jaký je stav mé objednávky 123456?"

Agent efektivně používá LLM jako směrovač dotazů. Po zadání dotazu („Jaký je stav objednávky 123456?“), vyberte vhodný vyhledávací nástroj pro dotazování napříč více zdroji dat (tj. vratky a objednávky). Směrování dotazů dosahujeme tak, že LLM vybírá mezi více nástroji pro vyhledávání, které jsou zodpovědné za interakci se zdrojem dat a načítání kontextu. Tím se rozšiřuje jednoduchý vzor RAG, který předpokládá jeden zdroj dat.

Oba nástroje pro vyhledávání jsou funkcemi Lambda, které berou id (číslo objednávky nebo returnId) jako vstup načte objekt JSON ze zdroje dat a převede JSON na lidsky přátelský reprezentační řetězec, který je vhodný pro použití LLM. Zdrojem dat ve scénáři reálného světa by mohla být vysoce škálovatelná databáze NoSQL, jako je DynamoDB, ale toto řešení využívá jednoduchý Python. Dict s ukázkovými daty pro demo účely.

Do agenta lze přidat další funkce přidáním nástrojů pro vyhledávání a odpovídajícím upravením výzev. Tento agent může být testován jako samostatná služba, která se integruje s jakýmkoli uživatelským rozhraním přes HTTP, což lze snadno provést pomocí Amazon Lex.

Zde jsou některé další podrobnosti o klíčových komponentách:

1. LLM inferenční koncový bod – Jádrem agentského programu je LLM. Ke snadnému nasazení použijeme základ modelu SageMaker JumpStart Flan-UL2 Modelka. SageMaker JumpStart usnadňuje nasazení koncových bodů odvození LLM do vyhrazených instancí SageMaker.
2. Agent orchestrátor – Agent orchestrator organizuje interakce mezi LLM, nástroji a klientskou aplikací. Pro naše řešení používáme funkci AWS Lambda k řízení tohoto toku a jako pomocné funkce využíváme následující.
   • Plánovač úkolů (nástrojů) – Plánovač úloh používá LLM k navržení jednoho z 1) dotazu na vrácení, 2) dotazu na objednávku nebo 3) žádného nástroje. Používáme pouze rychlé inženýrství a Flan-UL2 model tak, jak je, bez jemného doladění.
   • Analyzátor nástrojů – Analyzátor nástrojů zajišťuje, že návrh nástroje z plánovače úloh je platný. Zejména zajišťujeme, že jeden číslo objednávky nebo returnId lze analyzovat. Jinak odpovíme výchozí zprávou.
   • Dispečer nářadí – Nástrojový dispečer vyvolá nástroje (funkce Lambda) pomocí platných parametrů.
   • Výstupní analyzátor – Výstupní analyzátor vyčistí a extrahuje relevantní položky z JSON do lidsky čitelného řetězce. Tento úkol je prováděn jak každým vyhledávacím nástrojem, tak i v rámci orchestrátoru.
   • Výstupní tlumočník – Zodpovědností výstupního tlumočníka je 1) interpretovat výstup z vyvolání nástroje a 2) určit, zda lze vyhovět požadavku uživatele nebo zda jsou nutné další kroky. V druhém případě je konečná odpověď vygenerována samostatně a vrácena uživateli.

Nyní se pojďme ponořit trochu hlouběji do klíčových komponent: agent orchestrátor, plánovač úloh a dispečer nástrojů.

Agent orchestrátor

Níže je zkrácená verze smyčky agenta uvnitř funkce Lambda orchestrátoru agenta. Smyčka využívá pomocné funkce jako např task_planner nebo tool_parsermodularizovat úkoly. Smyčka je zde navržena tak, aby běžela maximálně dvakrát, aby se zabránilo tomu, že LLM uvízne ve smyčce zbytečně dlouho.

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

Plánovač úloh (predikce nástroje)

Agent orchestrátor používá plánovač úkolů předvídat vyhledávací nástroj na základě vstupu uživatele. Pro našeho LLM agenta jednoduše použijeme rychlé inženýrství a několik výstřelů, abychom LLM naučili tento úkol v kontextu. Sofistikovanější agenti by mohli použít vyladěný LLM pro predikci nástrojů, což je nad rámec tohoto příspěvku. Výzva je následující:

tool_selection_prompt_template = """ Vaším úkolem je vybrat vhodné nástroje, které uspokojí vstup uživatele. Pokud není vyžadován žádný nástroj, vyberte "no_tool". Dostupné nástroje jsou: returns_inquiry: Databáze informací o stavu konkrétního vrácení, ať už je nevyřízený, zpracovaný, atd. order_inquiry: Informace o stavu konkrétní objednávky, jako je stav zásilky, produkt, množství atd. no_tool: K zodpovězení zadání uživatele není potřeba žádný nástroj. Můžete navrhnout více nástrojů oddělených čárkou. Příklady: uživatel: " Jakou máte pracovní dobu?" nástroj: no_tool user: "Byla odeslána objednávka 12345?" nástroj: order_inquiry user: "Byla zpracována vratka ret812?" nástroj: returns_inquiry user: "Kolik dní mám do vrácení objednávek?" nástroj: returns_inquiry user: "Jaká byla celková objednávka pro objednávku 38745?" nástroj: order_inquiry uživatel: "Mohu vrátit svou objednávku 38756 na základě zásad obchodu?" nástroj: order_inquiry uživatel: "Ahoj" nástroj: no_tool user: "Jste AI ?" nástroj: no_tool user: "Jaké je počasí?" nástroj: no_tool user: "Jaký je stav vrácení peněz za objednávku 12347?" nástroj: order_inquiry user: "Jaký je stav vrácení peněz za vrácení ret172?" nástroj: returns_inquiry uživatelský vstup : {} nástroj: """

Dispečer nářadí

Mechanismus expedice nástrojů funguje přes pokud/jinak logiku pro volání příslušných funkcí Lambda v závislosti na názvu nástroje. Následující je tool_dispatch implementace pomocné funkce. Používá se uvnitř činidlo smyčky a vrací nezpracovanou odpověď z funkce Lambda nástroje, která je následně vyčištěna pomocí an output_parser funkce.

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

Nasaďte řešení

Důležité předpoklady - Chcete-li začít s nasazením, musíte splnit následující předpoklady:

• Přístup k AWS Management Console prostřednictvím uživatele, který může spouštět zásobníky AWS CloudFormation
• Znalost navigace AWS Lambda a Amazon Lex konzole
• Flan-UL2 vyžaduje jeden ml.g5,12xvelký pro nasazení, což může vyžadovat zvýšení limitů zdrojů prostřednictvím lístku podpory. V našem příkladu používáme nás-východ-1 jako Region, takže se prosím ujistěte, že zvýšíte kvótu služeb (v případě potřeby) v nás-východ-1.

Nasazení pomocí CloudFormation – Řešení můžete nasadit na nás-východ-1 kliknutím na tlačítko níže:

Nasazení řešení zabere asi 20 minut a vytvoří se a LLMAgentStack zásobník, který:

• nasadí koncový bod SageMaker pomocí Flan-UL2 model od SageMaker JumpStart;
• využívá tři funkce Lambda: LLMAgentOrchestrator, Nástroj LLMAgentReturnsTool, Nástroj LLMAgentOrdersTool; a
• nasazuje an AWS Lex bot, který lze použít k testování agenta: Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot.

Otestujte řešení

Zásobník nasazuje bota Amazon Lex se jménem Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. Robot může být použit k testování agenta end-to-end. Zde je další komplexní průvodce pro testování robotů AWS Amazon Lex s integrací Lambda a jak integrace funguje na vysoké úrovni. Stručně řečeno, bot Amazon Lex je zdroj, který poskytuje rychlé uživatelské rozhraní pro chatování s agentem LLM běžícím uvnitř funkce Lambda, kterou jsme vytvořili (LLMAgentOrchestrator).

Vzorové testovací případy, které je třeba zvážit, jsou následující:

• Platný dotaz na objednávku (například „Která položka byla objednána 123456?”)
  • Objednávka „123456“ je platná, takže bychom měli očekávat rozumnou odpověď (např. „Bylinné mýdlo na ruce“).
• Platný dotaz na vrácení pro návrat (například „Kdy se vrátím rtn003 zpracováno?")
  • Měli bychom očekávat rozumnou odpověď o stavu vrácení.
• Irelevantní pro vrácené zboží nebo objednávky (například „Jaké je právě teď počasí ve Skotsku?“)
  • Irelevantní otázka pro vrácené zboží nebo objednávky, proto by měla být vrácena výchozí odpověď („Omlouvám se, na tuto otázku nemohu odpovědět.“)
• Neplatný dotaz na objednávku (například „Která položka byla objednána 383833?”)
  • ID 383832 v datové sadě objednávek neexistuje, a proto bychom měli bez problémů selhat (například „Objednávka nenalezena. Zkontrolujte prosím své ID objednávky.“).
• Neplatný dotaz na vrácení (například „Kdy se vrátím rtn123 zpracováno?")
  • Podobně id rtn123 v datové sadě vrácených položek neexistuje, a proto by měl bez problémů selhat.
• Irelevantní dotaz na vrácení (například „Jaký je dopad návratu rtn001 o světovém míru?")
  • Tato otázka, i když se zdá, že se týká platné objednávky, je irelevantní. LLM se používá k filtrování otázek s irelevantním kontextem.

Chcete-li provést tyto testy sami, zde jsou pokyny.

1. Na konzoli Amazon Lex (Konzole AWS > Amazon Lex), přejděte na robota s názvem Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. Tento robot již byl nakonfigurován k volání LLMAgentOrchestrator Funkce lambda kdykoli FallbackIntent je spuštěna.
2. V navigačním podokně vyberte Záměry.
   
3. Vybrat Stavět v pravém horním rohu
   
4. 4. Počkejte na dokončení procesu sestavení. Po dokončení se zobrazí zpráva o úspěchu, jak je znázorněno na následujícím snímku obrazovky.
   
5. Otestujte robota zadáním testovacích případů.
   

Čištění

Chcete-li se vyhnout dalším poplatkům, odstraňte prostředky vytvořené naším řešením podle následujících kroků:

• Na AWS CloudFormation konzole, vyberte zásobník s názvem LLMAgentStack (nebo vlastní název, který jste vybrali).
• Vybrat Vymazat
• Zkontrolujte, zda je zásobník odstraněn z konzoly CloudFormation.

Důležité: znovu zkontrolujte, zda byl zásobník úspěšně odstraněn tím, že zajistíte, že Flan-UL2 inferenční koncový bod je odstraněn.

• Chcete-li zkontrolovat, přejděte na Konzole AWS > Sagemaker > Koncové body > Inference strana.
• Na stránce by měly být uvedeny všechny aktivní koncové body.
• Ujisti se sm-jumpstart-flan-bot-endpoint neexistuje jako níže uvedený snímek obrazovky.

Úvahy o výrobě

Nasazení agentů LLM do výroby vyžaduje další kroky k zajištění spolehlivosti, výkonu a udržovatelnosti. Zde jsou některé úvahy před nasazením agentů do produkce:

• Výběr modelu LLM pro napájení smyčky agentů: Pro řešení popsané v tomto příspěvku jsme použili a Flan-UL2 model bez jemného ladění pro provádění plánování úloh nebo výběru nástroje. V praxi může použití LLM, které je vyladěno pro přímý výstupní nástroj nebo požadavky API, zvýšit spolehlivost a výkon a také zjednodušit vývoj. Mohli bychom doladit LLM na úkoly výběru nástrojů nebo použít model, který přímo dekóduje tokeny nástrojů, jako je Toolformer.
  • Použití vyladěných modelů může také zjednodušit přidávání, odebírání a aktualizaci nástrojů dostupných agentovi. U přístupů založených pouze na výzvě vyžaduje aktualizace nástrojů úpravu každé výzvy uvnitř orchestrátoru agenta, jako jsou například výzvy pro plánování úloh, analýzu nástrojů a odeslání nástroje. To může být těžkopádné a výkon se může snížit, pokud je v kontextu LLM poskytnuto příliš mnoho nástrojů.
• Spolehlivost a výkon: Agenti LLM mohou být nespolehliví, zejména u složitých úkolů, které nelze dokončit během několika smyček. Spolehlivost může zvýšit přidání ověřování výstupů, opakování, strukturování výstupů z LLM do JSON nebo yaml a vynucení časových limitů pro poskytnutí únikových šraf pro LLM uvízlé ve smyčkách.

Závěr

V tomto příspěvku jsme prozkoumali, jak vytvořit LLM agenta, který může využívat více nástrojů od základu, pomocí nízkoúrovňového rychlého inženýrství, funkcí AWS Lambda a SageMaker JumpStart jako stavebních bloků. Podrobně jsme probrali architekturu agentů LLM a smyčku agentů. Koncepty a architektura řešení představené v tomto příspěvku na blogu mohou být vhodné pro agenty, kteří používají malý počet předem definovaných nástrojů. Probrali jsme také několik strategií pro použití agentů ve výrobě. Agents for Bedrock, který je ve verzi Preview, také poskytuje spravované prostředí pro vytváření agentů s nativní podporou pro vyvolání agentních nástrojů.

o autorovi

John Hwang je generativní architekt AI ve společnosti AWS se zvláštním zaměřením na aplikace s velkým jazykovým modelem (LLM), vektorové databáze a generativní produktovou strategii AI. Jeho nadšením je pomáhat společnostem s vývojem produktů AI/ML a budoucností agentů a kopilotů LLM. Před nástupem do AWS byl produktovým manažerem ve společnosti Alexa, kde pomáhal přinést konverzační umělou inteligenci do mobilních zařízení, a také jako obchodník s deriváty ve společnosti Morgan Stanley. Je držitelem titulu BS v oboru počítačových věd na Stanfordské univerzitě.