Store sprogmodel-agenter (LLM) er programmer, der udvider mulighederne for selvstændige LLM'er med 1) adgang til eksterne værktøjer (API'er, funktioner, webhooks, plugins og så videre) og 2) evnen til at planlægge og udføre opgaver på egen hånd -instrueret mode. Ofte skal LLM'er interagere med anden software, databaser eller API'er for at udføre komplekse opgaver. For eksempel vil en administrativ chatbot, der planlægger møder, kræve adgang til medarbejdernes kalendere og e-mail. Med adgang til værktøjer kan LLM-agenter blive mere kraftfulde – på bekostning af yderligere kompleksitet.
I dette indlæg introducerer vi LLM-agenter og demonstrerer, hvordan man opbygger og implementerer en e-handel LLM-agent ved hjælp af Amazon SageMaker JumpStart , AWS Lambda. Agenten vil bruge værktøjer til at give nye muligheder, såsom at besvare spørgsmål om returnering ("Er mit afkast rtn001
behandlet?") og give opdateringer om ordrer ("Kan du fortælle mig, hvis du bestiller 123456
er afsendt?"). Disse nye funktioner kræver, at LLM'er henter data fra flere datakilder (orders
, returns
) og udføre retrieval augmented generation (RAG).
Til at drive LLM-agenten bruger vi en Flan-UL2
model indsat som en SageMaker slutpunkt og brug datahentningsværktøjer bygget med AWS Lambda. Agenten kan efterfølgende integreres med Amazon Lex og bruges som chatbot inde på hjemmesider eller AWS Connect. Vi afslutter indlægget med emner, der skal overvejes, inden vi implementerer LLM-agenter til produktion. For en fuldt administreret oplevelse til at bygge LLM-agenter tilbyder AWS også agenter til Amazon Bedrock-funktionen (i forhåndsvisning).
En kort oversigt over LLM-agentarkitekturer
LLM-agenter er programmer, der bruger LLM'er til at beslutte, hvornår og hvordan de skal bruge værktøjer til at udføre komplekse opgaver. Med værktøjer og opgaveplanlægningsevner kan LLM-agenter interagere med eksterne systemer og overvinde traditionelle begrænsninger ved LLM'er, såsom vidensafbrydelser, hallucinationer og upræcise beregninger. Værktøjer kan have en række forskellige former, såsom API-kald, Python-funktioner eller webhook-baserede plugins. For eksempel kan en LLM bruge et "hentningsplugin" til at hente relevant kontekst og udføre RAG.
Så hvad betyder det for en LLM at vælge værktøjer og planlægge opgaver? Der er mange tilgange (f.eks Reagere, MRKL, Værktøjsformer, Krammer GPTog Transformer agents) at bruge LLM'er med værktøjer, og fremskridt sker hurtigt. Men en enkel måde er at bede en LLM med en liste over værktøjer og bede den om at bestemme 1) om et værktøj er nødvendigt for at tilfredsstille brugerforespørgslen, og i så fald 2) vælge det relevante værktøj. En sådan prompt ser typisk ud som det følgende eksempel og kan indeholde eksempler på få skud for at forbedre LLM's pålidelighed i at vælge det rigtige værktøj.
Mere komplekse tilgange involverer brug af en specialiseret LLM, der direkte kan afkode "API-kald" eller "værktøjsbrug", som f.eks. GorillaLLM. Sådanne finjusterede LLM'er er trænet i API-specifikationsdatasæt til at genkende og forudsige API-kald baseret på instruktion. Disse LLM'er kræver ofte nogle metadata om tilgængelige værktøjer (beskrivelser, yaml eller JSON-skema for deres inputparametre) for at udskrive værktøjsankaldelser. Denne tilgang er taget af agenter for Amazon Bedrock , OpenAI funktionskald. Bemærk, at LLM'er generelt skal være tilstrækkeligt store og komplekse for at vise evne til at vælge værktøj.
Forudsat at opgaveplanlægning og værktøjsvalgsmekanismer er valgt, fungerer et typisk LLM-agentprogram i følgende rækkefølge:
- Brugeranmodning – Programmet tager et brugerinput som "Hvor er min ordre
123456
?” fra en eller anden klientapplikation. - Planlæg næste handling(er), og vælg værktøj(er), der skal bruges – Dernæst bruger programmet en prompt for at få LLM til at generere den næste handling, for eksempel "Slå ordretabellen op ved at bruge
OrdersAPI
." LLM'en bliver bedt om at foreslå et værktøjsnavn som f.eksOrdersAPI
fra en foruddefineret liste over tilgængelige værktøjer og deres beskrivelser. Alternativt kunne LLM'en blive instrueret til direkte at generere et API-kald med inputparametre som f.eksOrdersAPI(12345)
.- Bemærk, at den næste handling muligvis involverer brug af et værktøj eller API. Hvis ikke, ville LLM reagere på brugerinput uden at inkorporere yderligere kontekst fra værktøjer eller blot returnere et standardsvar såsom, "Jeg kan ikke besvare dette spørgsmål."
- Anmodning om analyse af værktøj - Dernæst skal vi analysere og validere værktøjet/handlingsforudsigelsen foreslået af LLM. Validering er nødvendig for at sikre, at værktøjsnavne, API'er og anmodningsparametre ikke hallucineres, og at værktøjerne aktiveres korrekt i henhold til specifikationen. Denne parsing kan kræve et separat LLM-kald.
- Kald værktøj – Når gyldige værktøjsnavne og parametre er sikret, aktiverer vi værktøjet. Dette kan være en HTTP-anmodning, funktionskald og så videre.
- Parse output – Svaret fra værktøjet skal muligvis behandles yderligere. For eksempel kan et API-kald resultere i et langt JSON-svar, hvor kun et undersæt af felter er af interesse for LLM. Udtrækning af information i et rent, standardiseret format kan hjælpe LLM med at fortolke resultatet mere pålideligt.
- Fortolk output – På baggrund af outputtet fra værktøjet bliver LLM igen bedt om at give mening ud af det og beslutte, om det kan generere det endelige svar tilbage til brugeren, eller om der er behov for yderligere handlinger.
- Afslut eller fortsæt til trin 2 – Returner enten et endeligt svar eller et standardsvar i tilfælde af fejl eller timeouts.
Forskellige agentrammer udfører det tidligere programflow forskelligt. For eksempel, Reagere kombinerer værktøjsvalg og endelig svargenerering i en enkelt prompt, i modsætning til at bruge separate prompter til værktøjsvalg og svargenerering. Denne logik kan også køres i en enkelt omgang eller køres i en while-sætning ("agent-løkken"), som afsluttes, når det endelige svar genereres, en undtagelse kastes, eller timeout opstår. Det, der forbliver konstant, er, at agenter bruger LLM som omdrejningspunktet til at orkestrere planlægning og værktøjsankaldelser, indtil opgaven afsluttes. Dernæst viser vi, hvordan man implementerer en simpel agentløkke ved hjælp af AWS-tjenester.
Løsningsoversigt
Til dette blogindlæg implementerer vi en e-handelssupport LLM-agent, der giver to funktioner, der drives af værktøjer:
- Returstatussøgningsværktøj – Besvar spørgsmål om status for returneringer, såsom: "Hvad sker der med min tilbagevenden
rtn001
? " - Værktøj til hentning af ordrestatus – Spor status for ordrer, såsom "Hvad er status for min ordre
123456
? "
Agenten bruger effektivt LLM som en forespørgselsrouter. Givet en forespørgsel ("Hvad er status for ordre 123456
?”), skal du vælge det relevante genfindingsværktøj for at forespørge på tværs af flere datakilder (det vil sige returneringer og ordrer). Vi opnår forespørgselsrouting ved at lade LLM vælge blandt flere genfindingsværktøjer, som er ansvarlige for at interagere med en datakilde og hente kontekst. Dette udvider det simple RAG-mønster, som forudsætter en enkelt datakilde.
Begge genfindingsværktøjer er Lambda-funktioner, der tager et id (orderId
or returnId
) som input, henter et JSON-objekt fra datakilden og konverterer JSON til en menneskevenlig repræsentationsstreng, der er egnet til at blive brugt af LLM. Datakilden i et scenarie i den virkelige verden kunne være en meget skalerbar NoSQL-database som f.eks DynamoDB, men denne løsning bruger simple Python Dict
med eksempeldata til demoformål.
Yderligere funktionaliteter kan føjes til agenten ved at tilføje Retrieval Tools og modificere prompter i overensstemmelse hermed. Denne agent kan testes en selvstændig tjeneste, der integreres med enhver brugergrænseflade over HTTP, hvilket nemt kan gøres med Amazon Lex.
Her er nogle yderligere detaljer om nøglekomponenterne:
- LLM inferens slutpunkt – Kernen i et agentprogram er en LLM. Vi vil bruge SageMaker JumpStart foundation model hub til nemt at implementere
Flan-UL2
model. SageMaker JumpStart gør det nemt at implementere LLM-slutningsendepunkter til dedikerede SageMaker forekomster. - Agent orkestrator – Agent orkestrator orkestrerer interaktionerne mellem LLM, værktøjer og klientappen. Til vores løsning bruger vi en AWS Lambda-funktion til at drive dette flow og anvender følgende som hjælpefunktioner.
- Opgave (værktøj) planlægger – Opgaveplanlæggeren bruger LLM til at foreslå et af 1) returneringsforespørgsel, 2) ordreforespørgsel eller 3) intet værktøj. Vi bruger kun prompt ingeniørarbejde og
Flan-UL2
model som den er uden finjustering. - Værktøjsparser – Værktøjsparser sikrer, at værktøjsforslaget fra opgaveplanlæggeren er gyldigt. Især sikrer vi, at en enkelt
orderId
orreturnId
kan parses. Ellers svarer vi med en standardmeddelelse. - Værktøjssender – Værktøjsfordeleren påkalder værktøjer (Lambda-funktioner) ved hjælp af de gyldige parametre.
- Output parser – Output-parser renser og udtrækker relevante elementer fra JSON til en menneskelig læsbar streng. Denne opgave udføres både af hvert henteværktøj såvel som i orkestratoren.
- Output tolk – Outputtolkens ansvar er at 1) fortolke outputtet fra værktøjsankaldelse og 2) bestemme, om brugerens anmodning kan opfyldes, eller der er behov for yderligere trin. Hvis sidstnævnte, genereres et endeligt svar separat og returneres til brugeren.
- Opgave (værktøj) planlægger – Opgaveplanlæggeren bruger LLM til at foreslå et af 1) returneringsforespørgsel, 2) ordreforespørgsel eller 3) intet værktøj. Vi bruger kun prompt ingeniørarbejde og
Lad os nu dykke lidt dybere ned i nøglekomponenterne: agent orkestrator, opgaveplanlægger og værktøjsformidler.
Agent orkestrator
Nedenfor er en forkortet version af agentsløjfen inde i agent orkestrator Lambda-funktionen. Sløjfen bruger hjælpefunktioner som f.eks task_planner
or tool_parser
, for at modularisere opgaverne. Sløjfen her er designet til at køre højst to gange for at forhindre, at LLM'en sidder fast i en løkke unødigt lang.
Opgaveplanlægger (værktøjsforudsigelse)
Agent orkestratoren bruger task planner
at forudsige et genfindingsværktøj baseret på brugerinput. For vores LLM-agent vil vi blot bruge prompt engineering og få shot-prompts til at lære LLM denne opgave i kontekst. Mere sofistikerede agenter kunne bruge en finjusteret LLM til værktøjsforudsigelse, hvilket ligger uden for dette indlægs rammer. Prompten er som følger:
Værktøjssender
Værktøjsforsendelsesmekanismen fungerer via if/else
logik til at kalde passende Lambda-funktioner afhængigt af værktøjets navn. Følgende er tool_dispatch
hjælpefunktionens implementering. Det bruges inde i agent
loop og returnerer råsvaret fra værktøjets Lambda-funktion, som derefter renses af en output_parser
funktion.
Implementer løsningen
Vigtige forudsætninger – For at komme i gang med implementeringen skal du opfylde følgende forudsætninger:
- Adgang til AWS Management Console via en bruger, der kan starte AWS CloudFormation stakke
- Kendskab til at navigere i AWS Lambda , Amazon Lex konsoller
Flan-UL2
kræver en enkeltml.g5.12xlarge
til udrulning, hvilket kan nødvendiggøre øgede ressourcegrænser via en support billet. I vores eksempel bruger vius-east-1
som regionen, så sørg for at øge servicekvoten (hvis nødvendigt) ius-east-1
.
Implementer ved hjælp af CloudFormation – Du kan implementere løsningen til us-east-1
ved at klikke på knappen nedenfor:
Implementering af løsningen vil tage omkring 20 minutter og vil skabe en LLMAgentStack
stak, som:
- implementerer SageMaker-slutpunktet ved hjælp af
Flan-UL2
model fra SageMaker JumpStart; - implementerer tre Lambda-funktioner:
LLMAgentOrchestrator
,LLMAgentReturnsTool
,LLMAgentOrdersTool
Og - indsætter en AWS Lex bot, der kan bruges til at teste agenten:
Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
.
Test løsningen
Stakken implementerer en Amazon Lex-bot med navnet Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
. Botten kan bruges til at teste agenten ende-til-ende. Her er en yderligere omfattende guide til at teste AWS Amazon Lex-bots med en Lambda-integration, og hvordan integrationen fungerer på et højt niveau. Men kort fortalt er Amazon Lex-bot en ressource, der giver en hurtig brugergrænseflade til at chatte med LLM-agenten, der kører inde i en Lambda-funktion, som vi har bygget (LLMAgentOrchestrator
).
De eksempler på testtilfælde, der skal overvejes, er som følger:
- Gyldig ordreforespørgsel (f.eks. "Hvilken vare blev bestilt til
123456
? ”)- Ordren "123456" er en gyldig ordre, så vi bør forvente et rimeligt svar (f.eks. "Håndsæbe med urte")
- Gyldig returforespørgsel for et afkast (f.eks. "Hvornår kommer jeg tilbage
rtn003
behandlet?”)- Vi bør forvente et rimeligt svar om afkastets status.
- Irrelevant for både returnering eller ordre (f.eks. "Hvordan er vejret i Skotland lige nu?")
- Et irrelevant spørgsmål til returneringer eller ordrer, derfor bør et standardsvar returneres ("Beklager, jeg kan ikke besvare det spørgsmål.")
- Ugyldig ordreforespørgsel (f.eks. "Hvilken vare blev bestilt til
383833
? ”)- Id'et 383832 eksisterer ikke i ordredatasættet, og vi bør derfor fejle med ynde (f.eks. "Ordre ikke fundet. Tjek venligst dit ordre-id.")
- Ugyldig returforespørgsel (f.eks. "Hvornår vender jeg tilbage
rtn123
behandlet?”)- Tilsvarende har id
rtn123
eksisterer ikke i returneringsdatasættet, og bør derfor mislykkes.
- Tilsvarende har id
- Irrelevant returforespørgsel (f.eks. "Hvad er virkningen af tilbagevenden
rtn001
om verdensfred?”)- Dette spørgsmål er, selvom det ser ud til at vedrøre en gyldig ordre, irrelevant. LLM bruges til at filtrere spørgsmål med irrelevant kontekst.
For at køre disse tests selv, her er instruktionerne.
- På Amazon Lex-konsollen (AWS-konsol > Amazon Lex), naviger til botten med titlen
Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
. Denne bot er allerede konfigureret til at kaldeLLMAgentOrchestrator
Lambda-funktion, når som helstFallbackIntent
udløses. - Vælg i navigationsruden Hensigter.
- Vælg Byg i øverste højre hjørne
- 4. Vent på, at byggeprocessen er fuldført. Når det er færdigt, får du en succesmeddelelse, som vist på det følgende skærmbillede.
- Test botten ved at indtaste testcaserne.
Ryd op
For at undgå yderligere gebyrer skal du slette de ressourcer, der er oprettet af vores løsning, ved at følge disse trin:
- På AWS CloudFormation konsol, skal du vælge den navngivne stak
LLMAgentStack
(eller det brugerdefinerede navn, du valgte). - Vælg Slette
- Tjek, at stakken er slettet fra CloudFormation-konsollen.
Vigtig: dobbelttjek, at stakken er slettet, ved at sikre, at Flan-UL2
slutningsendepunkt fjernes.
- Gå til for at tjekke AWS-konsol > Sagemaker > Endpoints > Inferens .
- Siden skal vise alle aktive slutpunkter.
- Sørg
sm-jumpstart-flan-bot-endpoint
eksisterer ikke som skærmbilledet nedenfor.
Overvejelser til produktion
At implementere LLM-agenter i produktionen kræver, at der tages ekstra skridt for at sikre pålidelighed, ydeevne og vedligeholdelse. Her er nogle overvejelser før implementering af agenter i produktionen:
- Valg af LLM-modellen til at drive agentsløjfen: Til løsningen diskuteret i dette indlæg brugte vi en
Flan-UL2
model uden finjustering for at udføre opgaveplanlægning eller værktøjsvalg. I praksis kan brug af en LLM, der er finjusteret til direkte output af værktøj eller API-anmodninger, øge pålideligheden og ydeevnen samt forenkle udviklingen. Vi kunne finjustere en LLM på værktøjsvalgsopgaver eller bruge en model, der direkte afkoder værktøjstokens som Toolformer.- Brug af finjusterede modeller kan også forenkle tilføjelse, fjernelse og opdatering af værktøjer, der er tilgængelige for en agent. Med prompt-baserede tilgange kræver opdateringsværktøjer, at hver prompt i agentorkestratoren ændres, såsom dem til opgaveplanlægning, værktøjsparsing og værktøjsafsendelse. Dette kan være besværligt, og ydeevnen kan forringes, hvis der leveres for mange værktøjer i sammenhæng med LLM.
- Pålidelighed og ydeevne: LLM-agenter kan være upålidelige, især til komplekse opgaver, der ikke kan udføres inden for få sløjfer. Tilføjelse af outputvalideringer, genforsøg, strukturering af output fra LLM'er til JSON eller yaml og håndhævelse af timeouts for at give escape-luger til LLM'er, der sidder fast i sløjfer, kan øge pålideligheden.
Konklusion
I dette indlæg undersøgte vi, hvordan man opbygger en LLM-agent, der kan bruge flere værktøjer fra bunden ved hjælp af prompt-teknik på lavt niveau, AWS Lambda-funktioner og SageMaker JumpStart som byggeklodser. Vi diskuterede arkitekturen af LLM-agenter og agentsløjfen i detaljer. Koncepterne og løsningsarkitekturen introduceret i dette blogindlæg kan være passende for agenter, der bruger et lille antal af et foruddefineret sæt værktøjer. Vi diskuterede også flere strategier for brug af agenter i produktionen. Agents for Bedrock, som er i preview, giver også en administreret oplevelse til at bygge agenter med indbygget support til påkaldelser af agentværktøjer.
Om forfatteren
John Hwang er en Generativ AI-arkitekt hos AWS med særligt fokus på Large Language Model (LLM) applikationer, vektordatabaser og generativ AI-produktstrategi. Han brænder for at hjælpe virksomheder med AI/ML produktudvikling og fremtiden for LLM-agenter og co-piloter. Før han kom til AWS, var han produktchef hos Alexa, hvor han hjalp med at bringe samtale-AI til mobile enheder, samt en derivathandler hos Morgan Stanley. Han har en bachelorgrad i datalogi fra Stanford University.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
- PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
- PlatoESG. Automotive/elbiler, Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
- PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
- ChartPrime. Løft dit handelsspil med ChartPrime. Adgang her.
- BlockOffsets. Modernisering af miljømæssig offset-ejerskab. Adgang her.
- Kilde: https://aws.amazon.com/blogs/machine-learning/learn-how-to-build-and-deploy-tool-using-llm-agents-using-aws-sagemaker-jumpstart-foundation-models/
- :har
- :er
- :ikke
- :hvor
- $OP
- 1
- 100
- 15 %
- 19
- 20
- 200
- 24
- 27
- 500
- 7
- 9
- a
- evner
- evne
- Om
- adgang
- udrette
- Ifølge
- derfor
- tværs
- Handling
- aktioner
- aktiv
- tilføjet
- tilføje
- Yderligere
- administrative
- fremskridt
- Efter
- igen
- Agent
- midler
- AI
- AI / ML
- Alexa
- Alle
- allerede
- også
- Amazon
- Amazon Lex
- Amazon Web Services
- blandt
- beløb
- an
- ,
- besvare
- enhver
- api
- API'er
- app
- Anvendelse
- applikationer
- tilgang
- tilgange
- passende
- arkitektur
- ER
- AS
- spørg
- antager
- At
- augmented
- til rådighed
- undgå
- AWS
- AWS Lambda
- tilbage
- baseret
- BE
- bliver
- været
- før
- være
- jf. nedenstående
- Berkeley
- Beyond
- Bit
- Blocks
- Blog
- krop
- Bot
- både
- bots
- bringe
- bygge
- Bygning
- bygget
- virksomhed
- men
- .
- by
- beregninger
- kalendere
- ringe
- Opkald
- CAN
- kan ikke
- kapaciteter
- tilfælde
- tilfælde
- afgifter
- chatbot
- kontrollere
- Vælg
- valgt
- kunde
- kombinerer
- Virksomheder
- fuldføre
- Afsluttet
- komplekse
- kompleksitet
- komponenter
- omfattende
- computer
- Datalogi
- begreber
- konkluderer
- konfigureret
- Overvej
- overvejelser
- Konsol
- konstant
- sammenhæng
- fortsæt
- konversation
- samtale AI
- Core
- Koste
- kunne
- skabe
- oprettet
- besværlig
- skik
- data
- Database
- databaser
- datasæt
- Dage
- beslutte
- dedikeret
- dybere
- Standard
- definitioner
- demo
- demonstrere
- Afhængigt
- indsætte
- indsat
- implementering
- implementering
- udruller
- Derivater
- konstrueret
- detail
- detaljer
- Bestem
- Udvikling
- Enheder
- direkte
- drøftet
- dyk
- do
- gør
- færdig
- køre
- e
- e-handel
- hver
- nemt
- let
- effektivt
- enten
- andet
- beskæftiger
- ende til ende
- Endpoint
- håndhæve
- Engineering
- forbedre
- sikre
- sikret
- sikrer
- sikring
- indtastning
- Med titlen
- fejl
- fejl
- undslippe
- især
- etc.
- begivenhed
- Hver
- eksempel
- eksempler
- Undtagen
- undtagelse
- udføre
- eksisterer
- forvente
- erfaring
- udforsket
- udvide
- udvider
- ekstern
- ekstra
- Uddrag
- FAIL
- falsk
- Mode
- Feature
- få
- Fields
- filtrere
- endelige
- flow
- Fokus
- efter
- følger
- Til
- format
- formularer
- fundet
- Foundation
- rammer
- venlige
- fra
- Opfylde
- fuldt ud
- funktion
- funktionaliteter
- funktioner
- fremtiden
- generelt
- generere
- genereret
- generation
- generative
- Generativ AI
- få
- given
- Go
- Ground
- vejlede
- Happening
- luger
- Have
- have
- he
- hjælpe
- hjulpet
- hjælpe
- dermed
- link.
- hi
- Høj
- stærkt
- besidder
- HOURS
- Hvordan
- How To
- HTML
- http
- HTTPS
- Hub
- menneskelig
- læsbar
- i
- ID
- if
- KIMOs Succeshistorier
- gennemføre
- implementering
- import
- Forbedre
- in
- omfatter
- inkorporering
- Forøg
- stigende
- oplysninger
- indgang
- undersøgelse
- indvendig
- anvisninger
- integreret
- Integrerer
- integration
- hensigt
- interagere
- interaktion
- interaktioner
- interesse
- ind
- indføre
- introduceret
- påberåbes
- påberåber sig
- involvere
- IT
- Varer
- iterationer
- sammenføjning
- jpg
- json
- Nøgle
- viden
- Sprog
- stor
- lancere
- LÆR
- Niveau
- ligesom
- begrænsninger
- grænser
- Liste
- LLM
- logik
- Lang
- UDSEENDE
- lave
- maerker
- lykkedes
- ledelse
- leder
- mange
- Kan..
- me
- betyde
- mekanisme
- mekanismer
- møder
- besked
- Metadata
- minutter
- Mobil
- mobilenheder
- model
- modeller
- mere
- Morgan
- morgan stanley
- mest
- flere
- my
- navn
- Som hedder
- navne
- indfødte
- Naviger
- navigering
- Navigation
- nødvendig
- Behov
- behov
- Ny
- næste
- ingen
- Ingen
- især
- nu
- nummer
- talrige
- objekt
- of
- tit
- on
- engang
- ONE
- kun
- modsætning
- or
- ordrer
- ordrer
- Andet
- Ellers
- vores
- ud
- output
- uden for
- i løbet af
- Overvind
- oversigt
- side
- brød
- parametre
- passerer
- lidenskabelige
- Mønster
- fred
- verserende
- Udfør
- ydeevne
- pick
- plukket
- fly
- planlægning
- plato
- Platon Data Intelligence
- PlatoData
- Vær venlig
- Plugins
- politik
- Indlæg
- magt
- strøm
- praksis
- forudsige
- forudsigelse
- forudsætninger
- forhindre
- Eksempel
- tidligere
- Forud
- behandle
- Behandlet
- forarbejdning
- Produkt
- produktudvikling
- produktchef
- produktion
- Program
- Programmer
- korrekt
- give
- forudsat
- giver
- leverer
- formål
- Python
- spørgsmål
- Spørgsmål
- Hurtig
- rejse
- hurtigt
- Raw
- virkelige verden
- rimelige
- genkende
- tilbagebetale
- region
- relevant
- pålidelighed
- resterne
- fjernet
- fjernelse
- repræsentation
- anmode
- anmodninger
- kræver
- påkrævet
- Kræver
- ressource
- Ressourcer
- Svar
- svar
- ansvar
- ansvarlige
- resultere
- afkast
- vender tilbage
- afkast
- højre
- router
- routing
- Kør
- kører
- s
- sagemaker
- tilfreds
- skalerbar
- scenarie
- Videnskab
- rækkevidde
- Søg
- synes
- valgt
- valg
- selvstyret
- forstand
- adskille
- Sequence
- tjeneste
- Tjenester
- sæt
- flere
- afsendt
- Levering
- Kort
- shot
- bør
- Vis
- vist
- Simpelt
- forenkle
- ganske enkelt
- enkelt
- lille
- So
- Software
- løsninger
- nogle
- sofistikeret
- Kilde
- Kilder
- særligt
- specialiserede
- specifikke
- specifikation
- stable
- standalone
- Stanford
- Stanford University
- Stanley
- starte
- påbegyndt
- Statement
- Status
- Trin
- Steps
- Stands
- butik
- strategier
- Strategi
- String
- strukturering
- Efterfølgende
- succes
- Succesfuld
- sådan
- tyder
- egnede
- support
- sikker
- Systemer
- bord
- Tag
- taget
- tager
- tager
- Opgaver
- opgaver
- fortælle
- prøve
- afprøvet
- Test
- tests
- at
- Fremtiden
- deres
- derefter
- Der.
- Disse
- denne
- dem
- tre
- Dermed
- gange
- til
- Tokens
- også
- værktøj
- værktøjer
- top
- I alt
- spor
- erhvervsdrivende
- traditionelle
- uddannet
- udløst
- prøv
- to
- typisk
- typisk
- ui
- universitet
- unødigt
- indtil
- opdateringer
- opdatering
- brug
- anvendte
- Bruger
- bruger
- ved brug af
- udnytte
- VALIDATE
- validering
- række
- udgave
- via
- vente
- var
- Vej..
- we
- Vejr
- web
- webservices
- websites
- GODT
- Hvad
- Hvad er
- hvornår
- når
- hvorvidt
- som
- mens
- WHO
- vilje
- med
- inden for
- uden
- virker
- world
- ville
- yaml
- Du
- Din
- dig selv
- zephyrnet