Agenter for store språkmodeller (LLM) er programmer som utvider mulighetene til frittstående LLM-er med 1) tilgang til eksterne verktøy (APIer, funksjoner, webhooks, plugins og så videre), og 2) muligheten til å planlegge og utføre oppgaver på egen hånd -regissert mote. Ofte må LLM-er samhandle med annen programvare, databaser eller API-er for å utføre komplekse oppgaver. For eksempel vil en administrativ chatbot som planlegger møter kreve tilgang til ansattes kalendere og e-post. Med tilgang til verktøy kan LLM-agenter bli kraftigere – på bekostning av ekstra kompleksitet.
I dette innlegget introduserer vi LLM-agenter og demonstrerer hvordan du bygger og distribuerer en e-handel LLM-agent ved å bruke Amazon SageMaker JumpStart og AWS Lambda. Agenten vil bruke verktøy for å gi nye muligheter, for eksempel å svare på spørsmål om returer ("Er min retur rtn001
behandlet?") og gi oppdateringer om bestillinger ("Kan du fortelle meg om bestillingen 123456
har sendt?”). Disse nye egenskapene krever at LLM-er henter data fra flere datakilder (orders
, returns
) og utføre gjenfinning utvidet generasjon (RAG).
For å drive LLM-agenten bruker vi en Flan-UL2
modell utplassert som en SageMaker endepunkt og bruk datainnhentingsverktøy bygget med AWS Lambda. Agenten kan i ettertid integreres med Amazon Lex og brukes som chatbot inne på nettsteder eller AWS Connect. Vi avslutter innlegget med ting å vurdere før vi distribuerer LLM-agenter til produksjon. For en fullstendig administrert opplevelse for å bygge LLM-agenter, tilbyr AWS også agenter for Amazon Bedrock-funksjonen (i forhåndsvisning).
En kort oversikt over LLM-agentarkitekturer
LLM-agenter er programmer som bruker LLM-er for å bestemme når og hvordan de skal bruke verktøy etter behov for å fullføre komplekse oppgaver. Med verktøy og oppgaveplanleggingsevner kan LLM-agenter samhandle med eksterne systemer og overvinne tradisjonelle begrensninger ved LLM, for eksempel kunnskapsavbrudd, hallusinasjoner og upresise beregninger. Verktøy kan ha en rekke forskjellige former, for eksempel API-kall, Python-funksjoner eller webhook-baserte plugins. For eksempel kan en LLM bruke en "hentingsplugin" for å hente relevant kontekst og utføre RAG.
Så hva betyr det for en LLM å velge verktøy og planlegge oppgaver? Det er mange tilnærminger (som f.eks Reagere, MRKL, Verktøyformer, Klemmer GPTog Transformatoragents) å bruke LLM med verktøy, og fremskritt skjer raskt. Men en enkel måte er å spørre en LLM med en liste over verktøy og be den om å finne ut 1) om et verktøy er nødvendig for å tilfredsstille brukerspørsmålet, og i så fall 2) velge riktig verktøy. En slik melding ser vanligvis ut som det følgende eksempelet og kan inkludere eksempler på få skudd for å forbedre LLMs pålitelighet når det gjelder å velge riktig verktøy.
Mer komplekse tilnærminger innebærer bruk av en spesialisert LLM som direkte kan dekode "API-anrop" eller "verktøybruk", som f.eks. GorillaLLM. Slike finjusterte LLM-er er trent på API-spesifikasjonsdatasett for å gjenkjenne og forutsi API-kall basert på instruksjoner. Ofte krever disse LLM-ene noen metadata om tilgjengelige verktøy (beskrivelser, yaml eller JSON-skjema for inngangsparameterne deres) for å sende ut verktøyanrop. Denne tilnærmingen er tatt av agenter for Amazon Bedrock og OpenAI-funksjonsanrop. Merk at LLM-er generelt må være tilstrekkelig store og komplekse for å vise evne til verktøyvalg.
Forutsatt at oppgaveplanlegging og verktøyvalgsmekanismer er valgt, fungerer et typisk LLM-agentprogram i følgende sekvens:
- Brukerforespørsel – Programmet tar et brukerinnspill som "Hvor er bestillingen min
123456
?” fra en klientapplikasjon. - Planlegg neste handling(er) og velg verktøy(er) som skal brukes – Deretter bruker programmet en ledetekst for å få LLM til å generere neste handling, for eksempel "Søk opp ordretabellen ved å bruke
OrdersAPI
." LLM blir bedt om å foreslå et verktøynavn som f.eksOrdersAPI
fra en forhåndsdefinert liste over tilgjengelige verktøy og deres beskrivelser. Alternativt kan LLM bli bedt om å generere et API-kall direkte med inndataparametere som f.eksOrdersAPI(12345)
.- Merk at neste handling kan innebære bruk av et verktøy eller API. Hvis ikke, ville LLM svare på brukerinnspill uten å inkludere ekstra kontekst fra verktøy eller bare returnere et hermetisert svar som "Jeg kan ikke svare på dette spørsmålet."
- Forespørsel om analyseverktøy – Deretter må vi analysere og validere verktøyet/handlingsprediksjonen foreslått av LLM. Validering er nødvendig for å sikre at verktøynavn, APIer og forespørselsparametere ikke hallusineres, og at verktøyene aktiveres på riktig måte i henhold til spesifikasjonene. Denne parsingen kan kreve et separat LLM-kall.
- Påkalle verktøyet – Når gyldige verktøynavn og parameter(er) er sikret, påkaller vi verktøyet. Dette kan være en HTTP-forespørsel, funksjonskall og så videre.
- Parse utdata – Svaret fra verktøyet kan trenge ytterligere behandling. For eksempel kan et API-kall resultere i et langt JSON-svar, der bare et delsett av felt er av interesse for LLM. Å trekke ut informasjon i et rent, standardisert format kan hjelpe LLM å tolke resultatet mer pålitelig.
- Tolk utdata – Gitt resultatet fra verktøyet, blir LLM igjen bedt om å forstå det og bestemme om det kan generere det endelige svaret tilbake til brukeren eller om det er nødvendig med ytterligere handlinger.
- Avslutt eller fortsett til trinn 2 – Gi enten et endelig svar eller et standardsvar i tilfelle feil eller tidsavbrudd.
Ulike agentrammeverk utfører den forrige programflyten annerledes. For eksempel, Reagere kombinerer verktøyvalg og endelig svargenerering til én enkelt ledetekst, i motsetning til å bruke separate spørsmål for verktøyvalg og svargenerering. Denne logikken kan også kjøres i en enkelt pass eller kjøres i en while-setning ("agent loop"), som avsluttes når det endelige svaret genereres, et unntak blir kastet eller timeout oppstår. Det som forblir konstant er at agenter bruker LLM som midtpunktet for å orkestrere planlegging og verktøyanrop til oppgaven avsluttes. Deretter viser vi hvordan du implementerer en enkel agentsløyfe ved hjelp av AWS-tjenester.
Løsningsoversikt
For dette blogginnlegget implementerer vi en e-handelsstøtte LLM-agent som tilbyr to funksjoner drevet av verktøy:
- Returstatusinnhentingsverktøy – Svar på spørsmål om status for returer, for eksempel «Hva skjer med returen min
rtn001
? " - Verktøy for henting av ordrestatus – Spor statusen til bestillinger som, "Hva er statusen til bestillingen min
123456
? "
Agenten bruker effektivt LLM som en spørringsruter. Gitt en spørring ("Hva er status for ordre 123456
?”), velg det riktige gjenfinningsverktøyet for å spørre på tvers av flere datakilder (det vil si returer og bestillinger). Vi oppnår spørringsruting ved å la LLM velge blant flere gjenfinningsverktøy, som er ansvarlige for å samhandle med en datakilde og hente kontekst. Dette utvider det enkle RAG-mønsteret, som forutsetter en enkelt datakilde.
Begge gjenfinningsverktøyene er Lambda-funksjoner som tar en id (orderId
or returnId
) som input, henter et JSON-objekt fra datakilden, og konverterer JSON til en menneskevennlig representasjonsstreng som er egnet for bruk av LLM. Datakilden i et virkelighetsscenario kan være en svært skalerbar NoSQL-database som f.eks DynamoDB, men denne løsningen bruker enkel Python Dict
med eksempeldata for demoformål.
Ytterligere funksjoner kan legges til agenten ved å legge til gjenopprettingsverktøy og endre ledetekstene i henhold til dette. Denne agenten kan testes en frittstående tjeneste som integreres med ethvert brukergrensesnitt over HTTP, noe som enkelt kan gjøres med Amazon Lex.
Her er noen tilleggsdetaljer om nøkkelkomponentene:
- LLM slutningspunkt – Kjernen i et agentprogram er en LLM. Vi vil bruke SageMaker JumpStart foundation modell hub for enkelt å distribuere
Flan-UL2
modell. SageMaker JumpStart gjør det enkelt å distribuere LLM-slutningsendepunkter til dedikerte SageMaker tilfeller. - Agent orkestrator – Agent orkestrator orkestrerer interaksjonene mellom LLM, verktøy og klientappen. For vår løsning bruker vi en AWS Lambda-funksjon for å drive denne flyten og bruker følgende som hjelpefunksjoner.
- Oppgaveplanlegger (verktøy) – Oppgaveplanlegger bruker LLM til å foreslå en av 1) returforespørsel, 2) ordreforespørsel eller 3) ingen verktøy. Vi bruker kun prompt engineering og
Flan-UL2
modell som den er uten finjustering. - Verktøyparser – Verktøyparser sikrer at verktøyforslaget fra oppgaveplanleggeren er gyldig. Spesielt sikrer vi at en enkelt
orderId
orreturnId
kan analyseres. Ellers svarer vi med en standardmelding. - Verktøysender – Verktøyformidler påkaller verktøy (Lambda-funksjoner) ved å bruke de gyldige parameterne.
- Utdataparser – Output parser renser og trekker ut relevante elementer fra JSON til en menneskelig lesbar streng. Denne oppgaven gjøres både av hvert gjenfinningsverktøy så vel som i orkestratoren.
- Utgangstolk – Utdatatolkens ansvar er å 1) tolke utdata fra verktøyoppkalling og 2) avgjøre om brukerforespørselen kan tilfredsstilles eller om ytterligere trinn er nødvendig. Hvis sistnevnte, genereres et endelig svar separat og returneres til brukeren.
- Oppgaveplanlegger (verktøy) – Oppgaveplanlegger bruker LLM til å foreslå en av 1) returforespørsel, 2) ordreforespørsel eller 3) ingen verktøy. Vi bruker kun prompt engineering og
La oss nå dykke litt dypere inn i nøkkelkomponentene: agentorkestrator, oppgaveplanlegger og verktøyformidler.
Agent orkestrator
Nedenfor er en forkortet versjon av agentsløyfen inne i agent orkestrator Lambda-funksjonen. Sløyfen bruker hjelpefunksjoner som f.eks task_planner
or tool_parser
, for å modularisere oppgavene. Sløyfen her er designet for å kjøre maksimalt to ganger for å forhindre at LLM blir sittende fast i en sløyfe unødvendig lang.
Oppgaveplanlegger (verktøyprediksjon)
Agent orkestratoren bruker task planner
å forutsi et gjenfinningsverktøy basert på brukerinndata. For vår LLM-agent vil vi ganske enkelt bruke prompt engineering og få shot-prompting for å lære LLM denne oppgaven i kontekst. Mer sofistikerte agenter kan bruke en finjustert LLM for verktøyprediksjon, noe som ligger utenfor rammen av dette innlegget. Spørsmålet er som følger:
Verktøysender
Verktøyutsendelsesmekanismen fungerer via if/else
logikk for å kalle passende Lambda-funksjoner avhengig av verktøyets navn. Følgende er tool_dispatch
hjelpefunksjonens implementering. Den brukes inne i agent
loop og returnerer råresponsen fra verktøyets Lambda-funksjon, som deretter renses av en output_parser
funksjon.
Distribuere løsningen
Viktige forutsetninger – For å komme i gang med distribusjonen må du oppfylle følgende forutsetninger:
- Tilgang til AWS-administrasjonskonsoll via en bruker som kan starte AWS CloudFormation-stabler
- Kjennskap til å navigere i AWS Lambda og Amazon Lex konsoller
Flan-UL2
krever en singelml.g5.12xlarge
for utplassering, noe som kan gjøre det nødvendig å øke ressursgrensene via en billettstøtte. I vårt eksempel bruker vius-east-1
som regionen, så sørg for å øke tjenestekvoten (om nødvendig) ius-east-1
.
Distribuer med CloudFormation – Du kan distribuere løsningen til us-east-1
ved å klikke på knappen nedenfor:
Implementering av løsningen vil ta omtrent 20 minutter og vil opprette en LLMAgentStack
stabel, som:
- distribuerer SageMaker-endepunktet ved hjelp av
Flan-UL2
modell fra SageMaker JumpStart; - distribuerer tre Lambda-funksjoner:
LLMAgentOrchestrator
,LLMAgentReturnsTool
,LLMAgentOrdersTool
, Og - utplasserer en AWS Lex bot som kan brukes til å teste agenten:
Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
.
Test løsningen
Stabelen distribuerer en Amazon Lex-bot med navnet Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
. Boten kan brukes til å teste agenten ende-til-ende. Her er en ekstra omfattende guide for å teste AWS Amazon Lex-roboter med en Lambda-integrasjon og hvordan integrasjonen fungerer på et høyt nivå. Men kort fortalt er Amazon Lex-bot en ressurs som gir et raskt brukergrensesnitt for å chatte med LLM-agenten som kjører inne i en Lambda-funksjon som vi bygde (LLMAgentOrchestrator
).
Eksempler på testtilfeller å vurdere er som følger:
- Gyldig bestillingsforespørsel (for eksempel "Hvilken vare ble bestilt for
123456
? ”)- Ordren "123456" er en gyldig bestilling, så vi bør forvente et rimelig svar (f.eks. "Håndsåpe")
- Gyldig returforespørsel for en retur (for eksempel "Når kommer jeg tilbake
rtn003
Bearbeidet?")- Vi bør forvente et rimelig svar om returens status.
- Ikke relevant for både returer eller bestillinger (for eksempel "Hvordan er været i Skottland akkurat nå?")
- Et irrelevant spørsmål for returer eller bestillinger, derfor bør et standardsvar returneres ("Beklager, jeg kan ikke svare på det spørsmålet.")
- Ugyldig bestillingsforespørsel (for eksempel "Hvilken vare ble bestilt for
383833
? ”)- ID-en 383832 finnes ikke i ordredatasettet, og derfor bør vi mislykkes (for eksempel "Ordre ikke funnet. Vennligst sjekk bestillings-ID.")
- Ugyldig returforespørsel (for eksempel "Når kommer jeg tilbake
rtn123
Bearbeidet?")- På samme måte, id
rtn123
eksisterer ikke i returdatasettet, og bør derfor mislykkes.
- På samme måte, id
- Irrelevant returforespørsel (for eksempel "Hva er virkningen av avkastning
rtn001
om verdensfred?)- Dette spørsmålet, selv om det ser ut til å gjelde en gyldig ordre, er irrelevant. LLM brukes til å filtrere spørsmål med irrelevant kontekst.
For å kjøre disse testene selv, her er instruksjonene.
- På Amazon Lex-konsollen (AWS-konsoll > Amazon Lex), naviger til roboten som har tittelen
Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot
. Denne boten er allerede konfigurert til å kalleLLMAgentOrchestrator
Lambdafunksjon når som helstFallbackIntent
utløses. - Velg i navigasjonsruten hensikter.
- Velg Bygge øverst til høyre
- 4. Vent til byggeprosessen er fullført. Når det er gjort, får du en suksessmelding, som vist i følgende skjermbilde.
- Test boten ved å gå inn i testsakene.
Opprydding
For å unngå ekstra kostnader, slett ressursene som er opprettet av løsningen vår ved å følge disse trinnene:
- På AWS skyformasjon konsollen, velg stabelen som heter
LLMAgentStack
(eller det egendefinerte navnet du valgte). - Velg Delete
- Sjekk at stabelen er slettet fra CloudFormation-konsollen.
Viktig: dobbeltsjekk at stabelen er vellykket slettet ved å sikre at Flan-UL2
slutningsendepunkt fjernes.
- For å sjekke, gå til AWS-konsoll > Sagemaker > Endpoints > Inferens side.
- Siden skal vise alle aktive endepunkter.
- Sørge
sm-jumpstart-flan-bot-endpoint
eksisterer ikke som skjermbildet nedenfor.
Hensyn til produksjon
Utplassering av LLM-agenter til produksjon krever ekstra tiltak for å sikre pålitelighet, ytelse og vedlikehold. Her er noen hensyn før du distribuerer agenter i produksjonen:
- Velge LLM-modellen for å drive agentsløyfen: For løsningen diskutert i dette innlegget brukte vi en
Flan-UL2
modell uten finjustering for å utføre oppgaveplanlegging eller verktøyvalg. I praksis kan bruk av en LLM som er finjustert til direkte utdataverktøy eller API-forespørsler øke påliteligheten og ytelsen, samt forenkle utviklingen. Vi kan finjustere en LLM på verktøyvalgoppgaver eller bruke en modell som direkte dekoder verktøytokens som Toolformer.- Bruk av finjusterte modeller kan også forenkle å legge til, fjerne og oppdatere verktøy som er tilgjengelige for en agent. Med tilnærminger som kun er basert på prompt, krever oppdateringsverktøy å endre alle ledetekster inne i agentorkestratoren, for eksempel de for oppgaveplanlegging, verktøyparsing og verktøyutsendelse. Dette kan være tungvint, og ytelsen kan forringes hvis for mange verktøy leveres i sammenheng med LLM.
- Pålitelighet og ytelse: LLM-agenter kan være upålitelige, spesielt for komplekse oppgaver som ikke kan fullføres innen noen få løkker. Å legge til utdatavalideringer, gjenforsøk, strukturere utdata fra LLM-er til JSON eller yaml, og håndheve tidsavbrudd for å gi escape-luker for LLM-er som sitter fast i løkker, kan øke påliteligheten.
konklusjonen
I dette innlegget undersøkte vi hvordan man bygger en LLM-agent som kan bruke flere verktøy fra grunnen av, ved å bruke promptteknikk på lavt nivå, AWS Lambda-funksjoner og SageMaker JumpStart som byggeklosser. Vi diskuterte arkitekturen til LLM-agenter og agentsløyfen i detalj. Konseptene og løsningsarkitekturen introdusert i dette blogginnlegget kan være passende for agenter som bruker et lite antall av et forhåndsdefinert sett med verktøy. Vi diskuterte også flere strategier for bruk av agenter i produksjonen. Agents for Bedrock, som er i forhåndsvisning, gir også en administrert opplevelse for å bygge agenter med innebygd støtte for påkallinger av agentverktøy.
om forfatteren
John Hwang er en generativ AI-arkitekt ved AWS med spesielt fokus på Large Language Model (LLM)-applikasjoner, vektordatabaser og generativ AI-produktstrategi. Han brenner for å hjelpe bedrifter med AI/ML-produktutvikling, og fremtiden til LLM-agenter og co-piloter. Før han begynte i AWS, var han produktsjef hos Alexa, hvor han hjalp til med å bringe samtale-AI til mobile enheter, samt en derivathandler hos Morgan Stanley. Han har BS i informatikk fra Stanford University.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Bil / elbiler, Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- ChartPrime. Hev handelsspillet ditt med ChartPrime. Tilgang her.
- BlockOffsets. Modernisering av eierskap for miljøkompensasjon. Tilgang 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
- $OPP
- 1
- 100
- 15%
- 19
- 20
- 200
- 24
- 27
- 500
- 7
- 9
- a
- evner
- evne
- Om oss
- adgang
- utrette
- Ifølge
- tilsvar
- tvers
- Handling
- handlinger
- aktiv
- la til
- legge
- Ytterligere
- administrativ
- fremskritt
- Etter
- en gang til
- Agent
- agenter
- AI
- AI / ML
- Alexa
- Alle
- allerede
- også
- Amazon
- Amazon Lex
- Amazon Web Services
- blant
- beløp
- an
- og
- besvare
- noen
- api
- APIer
- app
- Søknad
- søknader
- tilnærming
- tilnærminger
- hensiktsmessig
- arkitektur
- ER
- AS
- spør
- antar
- At
- augmented
- tilgjengelig
- unngå
- AWS
- AWS Lambda
- tilbake
- basert
- BE
- bli
- vært
- før du
- være
- under
- Berkeley
- Beyond
- Bit
- Blocks
- Blogg
- kroppen
- Bot
- både
- roboter
- bringe
- bygge
- Bygning
- bygget
- virksomhet
- men
- knapp
- by
- beregninger
- kalendere
- ring
- Samtaler
- CAN
- kan ikke
- evner
- saken
- saker
- avgifter
- chatbot
- sjekk
- Velg
- valgt ut
- kunde
- skurtreskerne
- Selskaper
- fullføre
- Terminado
- komplekse
- kompleksitet
- komponenter
- omfattende
- datamaskin
- informatikk
- konsepter
- konkluderer
- konfigurert
- Vurder
- betraktninger
- Konsoll
- konstant
- kontekst
- fortsette
- conversational
- samtale AI
- Kjerne
- Kostnad
- kunne
- skape
- opprettet
- tungvint
- skikk
- dato
- Database
- databaser
- datasett
- Dager
- bestemme
- dedikert
- dypere
- Misligholde
- definisjoner
- demo
- demonstrere
- avhengig
- utplassere
- utplassert
- utplasserings
- distribusjon
- Distribueres
- Derivater
- designet
- detalj
- detaljer
- Bestem
- Utvikling
- Enheter
- direkte
- diskutert
- dykk
- do
- gjør
- gjort
- stasjonen
- e
- e-handel
- hver enkelt
- lett
- lett
- effektivt
- enten
- ellers
- emalje
- anvender
- ende til ende
- Endpoint
- håndheving
- Ingeniørarbeid
- forbedre
- sikre
- sikres
- sikrer
- sikrer
- går inn
- Med tittelen
- feil
- feil
- flykte
- spesielt
- etc
- Event
- Hver
- eksempel
- eksempler
- Unntatt
- unntak
- henrette
- eksisterer
- forvente
- erfaring
- utforsket
- utvide
- strekker
- utvendig
- ekstra
- ekstrakter
- FAIL
- falsk
- Mote
- Trekk
- Noen få
- Felt
- filtrere
- slutt~~POS=TRUNC
- flyten
- Fokus
- etter
- følger
- Til
- format
- skjemaer
- funnet
- Fundament
- rammer
- vennlig
- fra
- Innfri
- fullt
- funksjon
- funksjonalitet
- funksjoner
- framtid
- generelt
- generere
- generert
- generasjonen
- generative
- Generativ AI
- få
- gitt
- Go
- Ground
- veilede
- Skjer
- luker
- Ha
- å ha
- he
- hjelpe
- hjulpet
- hjelpe
- derav
- her.
- hi
- Høy
- svært
- holder
- TIMER
- Hvordan
- Hvordan
- HTML
- http
- HTTPS
- Hub
- menneskelig
- lesbar
- i
- ID
- if
- Påvirkning
- iverksette
- gjennomføring
- import
- forbedre
- in
- inkludere
- innlemme
- Øke
- økende
- informasjon
- inngang
- forespørsel
- innsiden
- instruksjoner
- integrert
- Integrerer
- integrering
- hensikt
- samhandle
- samhandler
- interaksjoner
- interesse
- inn
- introdusere
- introdusert
- påkalt
- påkaller
- involvere
- IT
- varer
- gjentakelser
- sammenføyning
- jpg
- JSON
- nøkkel
- kunnskap
- Språk
- stor
- lansere
- LÆRE
- Nivå
- i likhet med
- begrensninger
- grenser
- Liste
- LLM
- logikk
- Lang
- UTSEENDE
- gjøre
- GJØR AT
- fikk til
- ledelse
- leder
- mange
- Kan..
- me
- bety
- mekanisme
- mekanismer
- møter
- melding
- metadata
- minutter
- Mobil
- håndholdte enheter
- modell
- modeller
- mer
- Morgan
- morgan stanley
- mest
- flere
- my
- navn
- oppkalt
- navn
- innfødt
- Naviger
- navigere
- Navigasjon
- nødvendig
- Trenger
- nødvendig
- Ny
- neste
- Nei.
- none
- spesielt
- nå
- Antall
- mange
- objekt
- of
- ofte
- on
- gang
- ONE
- bare
- motsetning
- or
- rekkefølge
- ordrer
- Annen
- ellers
- vår
- ut
- produksjon
- utenfor
- enn
- Overcome
- oversikt
- side
- brød
- parametere
- passere
- lidenskapelig
- Mønster
- fred
- påvente
- Utfør
- ytelse
- plukke
- plukket
- fly
- planlegging
- plato
- Platon Data Intelligence
- PlatonData
- vær så snill
- plugins
- politikk
- Post
- makt
- powered
- praksis
- forutsi
- prediksjon
- forutsetninger
- forebygge
- Forhåndsvisning
- forrige
- Før
- prosess
- Bearbeidet
- prosessering
- Produkt
- produktutvikling
- Produktsjef
- Produksjon
- program
- programmer
- riktig
- gi
- forutsatt
- gir
- gi
- formål
- Python
- spørsmål
- spørsmål
- Rask
- heve
- raskt
- Raw
- virkelige verden
- rimelig
- gjenkjenne
- refundere
- region
- relevant
- pålitelighet
- forblir
- fjernet
- fjerne
- representasjon
- anmode
- forespørsler
- krever
- påkrevd
- Krever
- ressurs
- Ressurser
- Svare
- svar
- ansvar
- ansvarlig
- resultere
- retur
- retur
- avkastning
- ikke sant
- router
- ruting
- Kjør
- rennende
- s
- sagemaker
- fornøyd
- skalerbar
- scenario
- Vitenskap
- omfang
- Søk
- synes
- valgt
- utvalg
- selvstyrt
- forstand
- separat
- Sequence
- tjeneste
- Tjenester
- sett
- flere
- levert
- Levering
- Kort
- shot
- bør
- Vis
- vist
- Enkelt
- forenkle
- ganske enkelt
- enkelt
- liten
- So
- Software
- løsning
- noen
- sofistikert
- kilde
- Kilder
- spesiell
- spesialisert
- spesifikk
- spesifikasjon
- stable
- stående
- stanford
- Stanford University
- stanley
- Begynn
- startet
- Uttalelse
- status
- Trinn
- Steps
- Stopp
- oppbevare
- strategier
- Strategi
- String
- strukturering
- I ettertid
- suksess
- vellykket
- slik
- foreslår
- egnet
- støtte
- sikker
- Systemer
- bord
- Ta
- tatt
- tar
- ta
- Oppgave
- oppgaver
- fortelle
- test
- testet
- Testing
- tester
- Det
- De
- Fremtiden
- deres
- deretter
- Der.
- Disse
- denne
- De
- tre
- Dermed
- ganger
- til
- tokens
- også
- verktøy
- verktøy
- topp
- Totalt
- spor
- trader
- tradisjonelle
- trent
- utløst
- prøve
- to
- typisk
- typisk
- ui
- universitet
- unødvendig
- til
- oppdateringer
- oppdatering
- bruke
- brukt
- Bruker
- bruker
- ved hjelp av
- bruke
- VALIDERE
- validering
- variasjon
- versjon
- av
- vente
- var
- Vei..
- we
- Vær
- web
- webtjenester
- nettsteder
- VI VIL
- Hva
- Hva er
- når
- når som helst
- om
- hvilken
- mens
- HVEM
- vil
- med
- innenfor
- uten
- virker
- verden
- ville
- yaml
- Du
- Din
- deg selv
- zephyrnet