Agenter för stora språkmodeller (LLM) är program som utökar kapaciteten hos fristående LLM:er med 1) tillgång till externa verktyg (API, funktioner, webhooks, plugins och så vidare) och 2) förmågan att planera och utföra uppgifter på egen hand -riktat mode. Ofta behöver LLM:er interagera med annan programvara, databaser eller API:er för att utföra komplexa uppgifter. Till exempel skulle en administrativ chatbot som schemalägger möten kräva tillgång till anställdas kalendrar och e-post. Med tillgång till verktyg kan LLM-agenter bli mer kraftfulla – till bekostnad av ytterligare komplexitet.
I det här inlägget introducerar vi LLM-agenter och visar hur man bygger och distribuerar en e-handels-LLM-agent med Amazon SageMaker JumpStart och AWS Lambda. Agenten kommer att använda verktyg för att tillhandahålla nya möjligheter, som att svara på frågor om returer ("Är min retur rtn001
behandlas?”) och ge uppdateringar om beställningar ("Kan du berätta för mig om beställning 123456
har skickats?"). Dessa nya funktioner kräver att LLM:er hämtar data från flera datakällor (orders
, returns
) och utför retrieval augmented generation (RAG).
För att driva LLM-agenten använder vi en Flan-UL2
modell utplacerad som en SageMaker slutpunkt och använd verktyg för datahämtning byggda med AWS Lambda. Agenten kan därefter integreras med Amazon Lex och används som chatbot på webbplatser eller AWS Connect. Vi avslutar inlägget med saker att tänka på innan vi distribuerar LLM-agenter till produktion. För en helt hanterad upplevelse för att bygga LLM-agenter tillhandahåller AWS också agenter för Amazon Bedrock-funktionen (i förhandsvisning).
En kort översikt över LLM-agentarkitekturer
LLM-agenter är program som använder LLM:er för att bestämma när och hur verktyg ska användas efter behov för att slutföra komplexa uppgifter. Med verktyg och förmåga att planera uppgiften kan LLM-agenter interagera med externa system och övervinna traditionella begränsningar hos LLM, såsom kunskapsgränser, hallucinationer och oprecisa beräkningar. Verktyg kan ta en mängd olika former, såsom API-anrop, Python-funktioner eller webhook-baserade plugins. Till exempel kan en LLM använda ett "hämtningsplugin" för att hämta relevant sammanhang och utföra RAG.
Så vad betyder det för en LLM att välja verktyg och planera uppgifter? Det finns många tillvägagångssätt (som t.ex Reagera, MRKL, Toolformer, Kramar GPToch Transformatoragents) att använda LLM med verktyg, och framsteg sker snabbt. Men ett enkelt sätt är att fråga en LLM med en lista över verktyg och be den avgöra 1) om ett verktyg behövs för att tillfredsställa användarens fråga, och i så fall 2) välja lämpligt verktyg. En sådan prompt ser vanligtvis ut som följande exempel och kan innehålla några exempel för att förbättra LLM:s tillförlitlighet när det gäller att välja rätt verktyg.
Mer komplexa tillvägagångssätt innebär att man använder en specialiserad LLM som direkt kan avkoda "API-anrop" eller "verktygsanvändning", som t.ex. GorillaLLM. Sådana finjusterade LLM:er tränas på API-specifikationsdatauppsättningar för att känna igen och förutsäga API-anrop baserat på instruktioner. Ofta kräver dessa LLM lite metadata om tillgängliga verktyg (beskrivningar, yaml eller JSON-schema för deras inmatningsparametrar) för att mata ut verktygsanrop. Detta tillvägagångssätt tas av agenter för Amazon Bedrock och OpenAI-funktionsanrop. Observera att LLM i allmänhet måste vara tillräckligt stora och komplexa för att kunna visa verktygsvalsförmåga.
Förutsatt att uppgiftsplanering och verktygsvalsmekanismer väljs, fungerar ett typiskt LLM-agentprogram i följande ordning:
- Användarförfrågan – Programmet tar en användarinput som "Var är min beställning
123456
?” från någon klientapplikation. - Planera nästa åtgärd och välj verktyg att använda – Därefter använder programmet en prompt för att få LLM att generera nästa åtgärd, till exempel "Slå upp ordertabellen med
OrdersAPI
.” LLM uppmanas att föreslå ett verktygsnamn som t.exOrdersAPI
från en fördefinierad lista över tillgängliga verktyg och deras beskrivningar. Alternativt skulle LLM kunna instrueras att direkt generera ett API-anrop med indataparametrar som t.exOrdersAPI(12345)
.- Observera att nästa åtgärd kan innebära användning av ett verktyg eller API. Om inte, skulle LLM svara på användarinput utan att införliva ytterligare sammanhang från verktyg eller helt enkelt returnera ett standardsvar som, "Jag kan inte svara på den här frågan."
- Analysera verktygsbegäran – Därefter måste vi analysera och validera verktyget/åtgärdsförutsägelsen som föreslagits av LLM. Validering behövs för att säkerställa att verktygsnamn, API:er och begärandeparametrar inte hallucineras och att verktygen anropas korrekt enligt specifikationen. Denna analys kan kräva ett separat LLM-anrop.
- Anropa verktyg – När giltiga verktygsnamn och parametrar är säkerställda anropar vi verktyget. Detta kan vara en HTTP-förfrågan, funktionsanrop och så vidare.
- Analysera utdata – Svaret från verktyget kan behöva ytterligare bearbetning. Till exempel kan ett API-anrop resultera i ett långt JSON-svar, där endast en delmängd av fält är av intresse för LLM. Att extrahera information i ett rent, standardiserat format kan hjälpa LLM att tolka resultatet mer tillförlitligt.
- Tolka utdata – Med tanke på resultatet från verktyget uppmanas LLM igen att förstå det och besluta om det kan generera det slutliga svaret tillbaka till användaren eller om ytterligare åtgärder krävs.
- Avsluta eller fortsätt till steg 2 – Antingen returnerar ett slutligt svar eller ett standardsvar vid fel eller timeouts.
Olika agentramar exekverar det tidigare programflödet på olika sätt. Till exempel, Reagera kombinerar verktygsval och slutlig svarsgenerering till en enda prompt, i motsats till att använda separata prompter för verktygsval och svarsgenerering. Den här logiken kan också köras i ett enda pass eller köras i en while-sats (”agentloopen”), som avslutas när det slutliga svaret genereras, ett undantag kastas eller timeout inträffar. Det som förblir konstant är att agenter använder LLM som mittpunkten för att organisera planering och verktygsanrop tills uppgiften avslutas. Därefter visar vi hur man implementerar en enkel agentslinga med hjälp av AWS-tjänster.
Lösningsöversikt
För det här blogginlägget implementerar vi en LLM-agent för e-handelsstöd som tillhandahåller två funktioner som drivs av verktyg:
- Verktyg för återhämtning av status – Svara på frågor om status för returer som, "Vad händer med min retur
rtn001
? " - Verktyg för att hämta beställningsstatus – Spåra status för beställningar som, "Vad är statusen för min beställning
123456
? "
Agenten använder effektivt LLM som en frågerouter. Givet en fråga ("Vad är beställningens status 123456
?”), välj lämpligt hämtningsverktyg för att fråga över flera datakällor (det vill säga returer och beställningar). Vi åstadkommer frågedirigering genom att låta LLM välja bland flera hämtningsverktyg, som är ansvariga för att interagera med en datakälla och hämta sammanhang. Detta utökar det enkla RAG-mönstret, som förutsätter en enda datakälla.
Båda hämtningsverktygen är Lambda-funktioner som tar ett id (orderId
or returnId
) som indata, hämtar ett JSON-objekt från datakällan och konverterar JSON till en människovänlig representationssträng som är lämplig att användas av LLM. Datakällan i ett verkligt scenario kan vara en mycket skalbar NoSQL-databas som t.ex DynamoDB, men den här lösningen använder enkla Python Dict
med exempeldata för demoändamål.
Ytterligare funktioner kan läggas till i agenten genom att lägga till Retrieval Tools och ändra uppmaningar i enlighet med detta. Denna agent kan testas en fristående tjänst som integreras med alla användargränssnitt över HTTP, vilket enkelt kan göras med Amazon Lex.
Här är några ytterligare detaljer om nyckelkomponenterna:
- LLM slutpunkt slutpunkt – Kärnan i ett agentprogram är en LLM. Vi kommer att använda SageMaker JumpStart foundation modell nav för att enkelt distribuera
Flan-UL2
modell. SageMaker JumpStart gör det enkelt att distribuera LLM slutpunkter till dedikerade SageMaker instanser. - Agent orkestrator – Agent orkestrator orkestrerar interaktionerna mellan LLM, verktyg och klientappen. För vår lösning använder vi en AWS Lambda-funktion för att driva detta flöde och använder följande som hjälpfunktioner.
- Uppgiftsplanerare (verktyg) – Uppgiftsplaneraren använder LLM för att föreslå något av 1) returförfrågan, 2) orderförfrågan eller 3) inget verktyg. Vi använder endast snabb teknik och
Flan-UL2
modell som den är utan finjustering. - Tool parser – Tool parser säkerställer att verktygsförslaget från uppgiftsplaneraren är giltigt. Framför allt ser vi till att en singel
orderId
orreturnId
kan analyseras. Annars svarar vi med ett standardmeddelande. - Verktygsförare – Verktygsdispatcher anropar verktyg (Lambda-funktioner) med hjälp av giltiga parametrar.
- Utdataparser – Output parser rensar och extraherar relevanta objekt från JSON till en läsbar sträng. Denna uppgift görs både av varje hämtningsverktyg och inom orkestratorn.
- Utdatatolk – Utdatatolkens ansvar är att 1) tolka utdata från verktygsanrop och 2) avgöra om användarens begäran kan tillgodoses eller om ytterligare steg behövs. Om det senare genereras ett slutligt svar separat och returneras till användaren.
- Uppgiftsplanerare (verktyg) – Uppgiftsplaneraren använder LLM för att föreslå något av 1) returförfrågan, 2) orderförfrågan eller 3) inget verktyg. Vi använder endast snabb teknik och
Låt oss nu dyka lite djupare in i nyckelkomponenterna: agent orkestrator, uppgiftsplanerare och verktygsförmedlare.
Agent orkestrator
Nedan finns en förkortad version av agentslingan inuti agentorkestratorns Lambda-funktion. Slingan använder hjälpfunktioner som t.ex task_planner
or tool_parser
, för att modularisera uppgifterna. Slingan här är designad att köras högst två gånger för att förhindra att LLM fastnar i en slinga onödigt lång.
Uppgiftsplanerare (verktygsförutsägelse)
Agent orkestratorn använder task planner
för att förutsäga ett hämtningsverktyg baserat på användarinmatning. För vår LLM-agent kommer vi helt enkelt att använda snabb ingenjörskonst och få skottuppmaning för att lära LLM denna uppgift i sitt sammanhang. Mer sofistikerade agenter skulle kunna använda en finjusterad LLM för verktygsförutsägelse, vilket ligger utanför ramen för detta inlägg. Uppmaningen är följande:
Verktygsförare
Verktygsleveransmekanismen fungerar via if/else
logik för att anropa lämpliga lambdafunktioner beroende på verktygets namn. Följande är tool_dispatch
hjälparfunktionens implementering. Den används inuti agent
loop och returnerar råsvaret från verktygets Lambda-funktion, som sedan rengörs av en output_parser
funktion.
Distribuera lösningen
Viktiga förutsättningar – För att komma igång med implementeringen måste du uppfylla följande förutsättningar:
- Tillgång till AWS Management Console via en användare som kan starta AWS CloudFormation-stackar
- Förtrogenhet med att navigera i AWS Lambda och Amazon Lex konsoler
Flan-UL2
kräver en singelml.g5.12xlarge
för utplacering, vilket kan kräva ökade resursgränser via en biljettsupport. I vårt exempel använder vius-east-1
som regionen, så se till att öka tjänstekvoten (om det behövs) ius-east-1
.
Implementera med CloudFormation – Du kan distribuera lösningen till us-east-1
genom att klicka på knappen nedan:
Att implementera lösningen tar cirka 20 minuter och skapar en LLMAgentStack
stack, som:
- distribuerar SageMaker-slutpunkten med hjälp av
Flan-UL2
modell från SageMaker JumpStart; - använder tre lambdafunktioner:
LLMAgentOrchestrator
,LLMAgentReturnsTool
,LLMAgentOrdersTool
; Och - sätter in en AWS Lex bot som kan användas för att testa agenten:
Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
.
Testa lösningen
Stacken distribuerar en Amazon Lex-bot med namnet Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
. Boten kan användas för att testa agenten från början. Här är ytterligare en omfattande guide för att testa AWS Amazon Lex-bots med en Lambda-integration och hur integrationen fungerar på hög nivå. Men kort sagt, Amazon Lex bot är en resurs som ger ett snabbt användargränssnitt för att chatta med LLM-agenten som körs i en Lambda-funktion som vi byggde (LLMAgentOrchestrator
).
Exempel på testfall att överväga är följande:
- Giltig orderförfrågan (till exempel "Vilken vara beställdes för
123456
? ”)- Beställning "123456" är en giltig beställning, så vi bör förvänta oss ett rimligt svar (t.ex. "Handtvål")
- Giltig returförfrågan för en retur (till exempel "När kommer jag tillbaka
rtn003
bearbetas?”)- Vi bör förvänta oss ett rimligt svar om returens status.
- Orelevant för både returer eller beställningar (till exempel "Hur är vädret i Skottland just nu?")
- En irrelevant fråga för returer eller beställningar, därför bör ett standardsvar returneras ("Tyvärr, jag kan inte svara på den frågan.")
- Ogiltig orderförfrågan (till exempel "Vilken vara beställdes för
383833
? ”)- ID 383832 finns inte i beställningsdataset och därför bör vi misslyckas (till exempel "Beställning hittades inte. Kontrollera ditt beställnings-ID.")
- Ogiltig returförfrågan (till exempel "När kommer jag tillbaka
rtn123
bearbetas?”)- På samma sätt, id
rtn123
existerar inte i returdatauppsättningen och bör därför misslyckas.
- På samma sätt, id
- Irrelevant returförfrågan (till exempel "Vad är effekten av avkastning
rtn001
om världsfred?”)- Denna fråga är irrelevant, även om den verkar handla om en giltig ordning. LLM används för att filtrera frågor med irrelevant kontext.
För att köra dessa tester själv, här är instruktionerna.
- På Amazon Lex-konsolen (AWS-konsol > Amazon Lex), navigera till boten med titeln
Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
. Denna bot har redan konfigurerats för att anropaLLMAgentOrchestrator
Lambdafunktion närhelstFallbackIntent
är triggad. - Välj i navigeringsfönstret Avsikter.
- Välja Bygga i det övre högra hörnet
- 4. Vänta tills byggprocessen är klar. När det är klart får du ett framgångsmeddelande, som visas i följande skärmdump.
- Testa boten genom att gå in i testfallen.
Städa
För att undvika ytterligare avgifter, radera resurserna som skapats av vår lösning genom att följa dessa steg:
- På AWS molnformation konsolen, välj den stack som heter
LLMAgentStack
(eller det anpassade namnet du valde). - Välja Radera
- Kontrollera att stacken är raderad från CloudFormation-konsolen.
Viktigt: dubbelkolla att stacken har tagits bort genom att se till att Flan-UL2
slutpunkten tas bort.
- För att kontrollera, gå till AWS-konsol > Sagemaker > Endpoints > Inferens sida.
- Sidan bör lista alla aktiva slutpunkter.
- Se till
sm-jumpstart-flan-bot-endpoint
existerar inte som skärmdumpen nedan.
Överväganden för produktion
Att distribuera LLM-agenter till produktion kräver att man vidtar extra åtgärder för att säkerställa tillförlitlighet, prestanda och underhållsbarhet. Här är några överväganden innan du distribuerar agenter i produktionen:
- Välja LLM-modellen för att driva agentslingan: För lösningen som diskuteras i det här inlägget använde vi en
Flan-UL2
modell utan finjustering för att utföra uppgiftsplanering eller verktygsval. I praktiken kan användning av en LLM som är finjusterad för att direkt mata ut verktyg eller API-förfrågningar öka tillförlitligheten och prestanda, samt förenkla utvecklingen. Vi skulle kunna finjustera en LLM på verktygsvalsuppgifter eller använda en modell som direkt avkodar verktygstokens som Toolformer.- Att använda finjusterade modeller kan också förenkla att lägga till, ta bort och uppdatera verktyg som är tillgängliga för en agent. Med tillvägagångssätt som endast är baserade på prompt kräver uppdateringsverktyg att varje prompt i agentorkestratorn ändras, till exempel de för uppgiftsplanering, verktygsanalys och verktygssändning. Detta kan vara besvärligt, och prestandan kan försämras om alltför många verktyg tillhandahålls i samband med LLM.
- Tillförlitlighet och prestanda: LLM-agenter kan vara opålitliga, särskilt för komplexa uppgifter som inte kan slutföras inom några få loopar. Att lägga till utdatavalideringar, återförsök, strukturera utdata från LLM till JSON eller yaml och genomdriva timeouts för att tillhandahålla utrymningsluckor för LLM som fastnat i loopar kan förbättra tillförlitligheten.
Slutsats
I det här inlägget utforskade vi hur man bygger en LLM-agent som kan använda flera verktyg från grunden, med hjälp av lågnivåpromptteknik, AWS Lambda-funktioner och SageMaker JumpStart som byggstenar. Vi diskuterade arkitekturen för LLM-agenter och agentslingan i detalj. Koncepten och lösningsarkitekturen som introduceras i det här blogginlägget kan vara lämpliga för agenter som använder ett litet antal av en fördefinierad uppsättning verktyg. Vi diskuterade också flera strategier för att använda agenter i produktionen. Agents for Bedrock, som är i förhandsvisning, ger också en hanterad upplevelse för att bygga agenter med inbyggt stöd för agentverktygsanrop.
Om författaren
John Hwang är en generativ AI-arkitekt på AWS med speciellt fokus på Large Language Model (LLM)-applikationer, vektordatabaser och generativ AI-produktstrategi. Han brinner för att hjälpa företag med AI/ML-produktutveckling och framtiden för LLM-agenter och co-piloter. Innan han började på AWS var han produktchef på Alexa, där han hjälpte till att föra konversations-AI till mobila enheter, samt en derivathandlare på Morgan Stanley. Han har en kandidatexamen i datavetenskap från Stanford University.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Fordon / elbilar, Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
- ChartPrime. Höj ditt handelsspel med ChartPrime. Tillgång här.
- BlockOffsets. Modernisera miljökompensation ägande. Tillgång här.
- Källa: https://aws.amazon.com/blogs/machine-learning/learn-how-to-build-and-deploy-tool-using-llm-agents-using-aws-sagemaker-jumpstart-foundation-models/
- : har
- :är
- :inte
- :var
- $UPP
- 1
- 100
- 15%
- 19
- 20
- 200
- 24
- 27
- 500
- 7
- 9
- a
- förmågor
- förmåga
- Om oss
- tillgång
- åstadkomma
- Enligt
- i enlighet med detta
- tvärs
- Handling
- åtgärder
- aktiv
- lagt till
- tillsats
- Annat
- administrativa
- framsteg
- Efter
- igen
- Recensioner
- medel
- AI
- AI / ML
- alexa
- Alla
- redan
- också
- amason
- Amazon Lex
- Amazon Web Services
- bland
- mängd
- an
- och
- svara
- vilken som helst
- api
- API: er
- app
- Ansökan
- tillämpningar
- tillvägagångssätt
- tillvägagångssätt
- lämpligt
- arkitektur
- ÄR
- AS
- be
- antar
- At
- augmented
- tillgänglig
- undvika
- AWS
- AWS Lambda
- tillbaka
- baserat
- BE
- blir
- varit
- innan
- Där vi får lov att vara utan att konstant prestera,
- nedan
- Berkeley
- Bortom
- Bit
- Block
- Blogg
- kropp
- Bot
- båda
- botar
- föra
- SLUTRESULTAT
- Byggnad
- byggt
- företag
- men
- Knappen
- by
- beräkningar
- kalendrar
- Ring
- Samtal
- KAN
- kan inte
- kapacitet
- Vid
- fall
- avgifter
- chatbot
- ta
- Välja
- valda
- klient
- kombinerar
- Företag
- fullborda
- Avslutade
- komplex
- Komplexiteten
- komponenter
- omfattande
- dator
- Datavetenskap
- Begreppen
- avslutar
- konfigurerad
- Tänk
- överväganden
- Konsol
- konstant
- sammanhang
- fortsätta
- konversera
- konversations AI
- Kärna
- Pris
- kunde
- skapa
- skapas
- besvärlig
- beställnings
- datum
- Databas
- databaser
- datauppsättningar
- Dagar
- beslutar
- dedicerad
- djupare
- Standard
- definitioner
- demo
- demonstrera
- beroende
- distribuera
- utplacerade
- utplacera
- utplacering
- vecklas ut
- Derivat
- utformade
- detalj
- detaljer
- Bestämma
- Utveckling
- enheter
- direkt
- diskuteras
- Dyk
- do
- gör
- gjort
- driv
- e
- e-handel
- varje
- lätt
- lätt
- effektivt
- antingen
- annars
- sysselsätter
- början till slut
- Slutpunkt
- driva
- Teknik
- förbättra
- säkerställa
- säker
- säkerställer
- säkerställa
- in
- med titeln
- fel
- fel
- fly
- speciellt
- etc
- händelse
- Varje
- exempel
- exempel
- Utom
- undantag
- exekvera
- existerar
- förvänta
- erfarenhet
- utforskas
- förlänga
- sträcker
- extern
- extra
- extrakt
- MISSLYCKAS
- falsk
- Mode
- Leverans
- få
- Fält
- filtrera
- slutlig
- flöda
- Fokus
- efter
- följer
- För
- format
- former
- hittade
- fundament
- ramar
- vänliga
- från
- Uppfylla
- fullständigt
- fungera
- funktionaliteter
- funktioner
- framtida
- allmänhet
- generera
- genereras
- generering
- generativ
- Generativ AI
- skaffa sig
- ges
- Go
- Marken
- styra
- Happening
- luckor
- Har
- har
- he
- hjälpa
- hjälpte
- hjälpa
- därav
- här.
- hi
- Hög
- höggradigt
- innehar
- ÖPPETTIDER
- Hur ser din drömresa ut
- How To
- html
- http
- HTTPS
- Nav
- humant
- läsbar
- i
- ID
- if
- Inverkan
- genomföra
- genomförande
- import
- förbättra
- in
- innefattar
- införlivande
- Öka
- ökande
- informationen
- ingång
- utredning
- inuti
- instruktioner
- integrerade
- integrerar
- integrering
- uppsåt
- interagera
- interagera
- interaktioner
- intresse
- in
- införa
- introducerade
- åberopas
- anropar
- engagera
- IT
- artikel
- iterationer
- sammanfogning
- jpg
- json
- Nyckel
- kunskap
- språk
- Large
- lansera
- LÄRA SIG
- Nivå
- tycka om
- begränsningar
- gränser
- Lista
- LLM
- Logiken
- Lång
- UTSEENDE
- göra
- GÖR
- förvaltade
- ledning
- chef
- många
- Maj..
- me
- betyda
- mekanism
- mekanismer
- möten
- meddelande
- metadata
- minuter
- Mobil
- Mobil enheter
- modell
- modeller
- mer
- Morgan
- Morgan Stanley
- mest
- multipel
- my
- namn
- Som heter
- namn
- nativ
- Navigera
- navigerande
- Navigering
- nödvändigt för
- Behöver
- behövs
- Nya
- Nästa
- Nej
- Ingen
- i synnerhet
- nu
- antal
- talrik
- objektet
- of
- Ofta
- on
- gång
- ONE
- endast
- motsatt
- or
- beställa
- ordrar
- Övriga
- annat
- vår
- ut
- produktion
- utanför
- över
- Övervinna
- Översikt
- sida
- panelen
- parametrar
- passera
- brinner
- Mönster
- fred
- väntan
- Utföra
- prestanda
- plocka
- plockade
- Planen
- planering
- plato
- Platon Data Intelligence
- PlatonData
- snälla du
- insticksmoduler
- policy
- Inlägg
- kraft
- drivs
- praktiken
- förutse
- förutsägelse
- förutsättningar
- förhindra
- Förhandsvisning
- föregående
- Innan
- process
- Bearbetad
- bearbetning
- Produkt
- produktutveckling
- produktchef
- Produktion
- Program
- Program
- ordentligt
- ge
- förutsatt
- ger
- tillhandahålla
- syfte
- Python
- fråga
- frågor
- Snabbt
- höja
- snabbt
- Raw
- verkliga världen
- rimlig
- känner igen
- återbetala
- region
- relevanta
- tillförlitlighet
- resterna
- avlägsnas
- bort
- representation
- begära
- förfrågningar
- kräver
- Obligatorisk
- Kräver
- resurs
- Resurser
- Svara
- respons
- ansvaret
- ansvarig
- resultera
- avkastning
- tillbaka
- återgår
- höger
- router
- routing
- Körning
- rinnande
- s
- sagemaker
- nöjd
- skalbar
- scenario
- Vetenskap
- omfattning
- Sök
- verkar
- vald
- Val
- självstyrd
- känsla
- separat
- Sekvens
- service
- Tjänster
- in
- flera
- skeppas
- Frakt & Leverans
- Kort
- skott
- skall
- show
- visas
- Enkelt
- förenkla
- helt enkelt
- enda
- Small
- So
- Mjukvara
- lösning
- några
- sofistikerade
- Källa
- Källor
- speciell
- specialiserad
- specifik
- specifikation
- stapel
- fristående
- stanford
- Stanford University
- Stanley
- starta
- igång
- .
- status
- Steg
- Steg
- Sluta
- lagra
- strategier
- Strategi
- Sträng
- strukturering
- Senare
- framgång
- Framgångsrikt
- sådana
- föreslå
- lämplig
- stödja
- säker
- System
- bord
- Ta
- tagen
- tar
- tar
- uppgift
- uppgifter
- tala
- testa
- testade
- Testning
- tester
- den där
- Smakämnen
- Framtiden
- deras
- sedan
- Där.
- Dessa
- detta
- de
- tre
- Således
- gånger
- till
- tokens
- alltför
- verktyg
- verktyg
- topp
- Totalt
- spår
- handlare
- traditionell
- tränad
- triggas
- prova
- två
- typisk
- typiskt
- ui
- universitet
- onödigt
- tills
- Uppdateringar
- uppdatering
- användning
- Begagnade
- Användare
- användningar
- med hjälp av
- utnyttja
- BEKRÄFTA
- godkännande
- mängd
- version
- via
- vänta
- var
- Sätt..
- we
- Väder
- webb
- webbservice
- webbsidor
- VÄL
- Vad
- Vad är
- när
- närhelst
- om
- som
- medan
- VEM
- kommer
- med
- inom
- utan
- fungerar
- världen
- skulle
- jaml
- Om er
- Din
- själv
- zephyrnet