I dag er flertallet av kundene våre begeistret for store språkmodeller (LLMs) og tenker på hvordan generativ AI kan forandre virksomheten deres. Det er imidlertid ikke en lett oppgave å bringe slike løsninger og modeller til business-as-usual-driften. I dette innlegget diskuterer vi hvordan man operasjonaliserer generative AI-applikasjoner ved å bruke MLOps-prinsipper som fører til grunnmodelloperasjoner (FMOps). Videre dykker vi dypt i det vanligste generative AI-brukstilfellet for tekst-til-tekst-applikasjoner og LLM-operasjoner (LLMOps), en undergruppe av FMOps. Følgende figur illustrerer temaene vi diskuterer.
Spesifikt introduserer vi kort MLOps-prinsipper og fokuserer på hoveddifferensiatorene sammenlignet med FMOps og LLMOps angående prosesser, personer, modellvalg og -evaluering, datapersonvern og modellimplementering. Dette gjelder kunder som bruker dem ut av esken, lager grunnmodeller fra bunnen av eller finjusterer dem. Vår tilnærming gjelder både åpen kildekode og proprietære modeller likt.
ML operasjonaliseringsoppsummering
Som definert i innlegget MLOps foundation roadmap for bedrifter med Amazon SageMaker, ML og operasjoner (MLOps) er kombinasjonen av mennesker, prosesser og teknologi for å produsere maskinlæringsløsninger (ML) effektivt. For å oppnå dette må en kombinasjon av team og personas samarbeide, som illustrert i følgende figur.
Disse lagene er som følger:
- Avansert analyseteam (datainnsjø og datanettverk) – Dataingeniører er ansvarlige for å forberede og innta data fra flere kilder, bygge ETL (ekstrahere, transformere og laste) rørledninger for å kuratere og katalogisere dataene, og forberede de nødvendige historiske dataene for ML-brukstilfellene. Disse dataeierne er fokusert på å gi tilgang til dataene deres til flere forretningsenheter eller team.
- Datavitenskapsteam – Dataforskere må fokusere på å lage den beste modellen basert på forhåndsdefinerte nøkkelytelsesindikatorer (KPIer) som fungerer i bærbare datamaskiner. Etter at forskningsfasen er fullført, må dataforskerne samarbeide med ML-ingeniører for å lage automatiseringer for bygging (ML-rørledninger) og distribuere modeller i produksjon ved hjelp av CI/CD-rørledninger.
- Forretningsteam – En produkteier er ansvarlig for å definere forretningscase, krav og KPIer som skal brukes til å evaluere modellens ytelse. ML-forbrukerne er andre forretningsinteressenter som bruker slutningsresultatene (spådommene) for å drive beslutninger.
- Plattformteam – Arkitekter er ansvarlige for den overordnede skyarkitekturen til virksomheten og hvordan alle de ulike tjenestene henger sammen. Sikkerhet SMB vurderer arkitekturen basert på forretningssikkerhetspolicyer og behov. MLOps-ingeniører er ansvarlige for å tilby et sikkert miljø for dataforskere og ML-ingeniører for å produsere ML-brukstilfellene. Spesifikt er de ansvarlige for standardisering av CI/CD-pipelines, bruker- og tjenesteroller og containeroppretting, modellforbruk, testing og distribusjonsmetodikk basert på forretnings- og sikkerhetskrav.
- Risiko- og etterlevelsesteam – For mer restriktive miljøer er revisorer ansvarlige for å vurdere data, kode og modellartefakter og sørge for at virksomheten er i samsvar med regelverk, for eksempel personvern.
Merk at flere personas kan dekkes av samme person avhengig av skaleringen og MLOps-modenheten til virksomheten.
Disse personas trenger dedikerte miljøer for å utføre de forskjellige prosessene, som illustrert i følgende figur.
Miljøene er som følger:
- Plattformadministrasjon – Plattformadministrasjonsmiljøet er stedet der plattformteamet har tilgang til å opprette AWS-kontoer og koble de riktige brukerne og dataene
- Data – Datalaget, ofte kjent som datainnsjøen eller datanettverket, er miljøet som dataingeniører eller eiere og forretningsinteressenter bruker for å forberede, samhandle og visualisere med dataene
- eksperimentering – Dataforskerne bruker en sandkasse eller et eksperimenteringsmiljø for å teste nye biblioteker og ML-teknikker for å bevise at deres proof of concept kan løse forretningsproblemer
- Modellbygging, modelltesting, modelldistribusjon – Modellbyggings-, test- og distribusjonsmiljøet er laget av MLOps, der dataforskere og ML-ingeniører samarbeider for å automatisere og flytte forskningen til produksjon
- ML styring – Den siste brikken i puslespillet er ML-styringsmiljøet, der alle modell- og kodeartefakter lagres, gjennomgås og revideres av de tilsvarende personene
Følgende diagram illustrerer referansearkitekturen, som allerede er diskutert i MLOps foundation roadmap for bedrifter med Amazon SageMaker.
Hver forretningsenhet har hvert eget sett med utviklingskontoer (automatisert modellopplæring og -bygging), preproduksjon (automatisk testing) og produksjon (modelldistribusjon og servering) for å produsere ML-brukstilfeller, som henter data fra en sentralisert eller desentralisert datainnsjø eller data mesh, henholdsvis. Alle de produserte modellene og kodeautomatiseringen er lagret i en sentralisert verktøykonto ved å bruke funksjonen til et modellregister. Infrastrukturkoden for alle disse kontoene er versjonert i en delt tjenestekonto (advanced analytics governance-konto) som plattformteamet kan abstrahere, male, vedlikeholde og gjenbruke for onboarding til MLOps-plattformen til hvert nytt team.
Generative AI-definisjoner og forskjeller til MLOps
I klassisk ML kan den foregående kombinasjonen av mennesker, prosesser og teknologi hjelpe deg med å produktisere ML-brukssakene dine. I generativ AI krever imidlertid brukstilfellenes natur enten en utvidelse av disse egenskapene eller nye evner. En av disse nye forestillingene er grunnmodellen (FM). De kalles som sådan fordi de kan brukes til å lage en lang rekke andre AI-modeller, som illustrert i følgende figur.
FM har blitt trent basert på terabyte med data og har hundrevis av milliarder av parametere for å kunne forutsi det nest beste svaret basert på tre hovedkategorier av generative AI-brukstilfeller:
- Tekst-til-tekst – FM-ene (LLM-ene) har blitt trent basert på umerkede data (som fritekst) og er i stand til å forutsi det nest beste ordet eller rekkefølgen av ord (avsnitt eller lange essays). De viktigste brukstilfellene er rundt menneskelignende chatbots, oppsummering eller annen innholdsskaping som programmeringskode.
- Tekst-til-bilde – Merkede data, for eksempel par av , har blitt brukt til å trene FM-er, som er i stand til å forutsi den beste kombinasjonen av piksler. Eksempler på bruk er generering av klesdesign eller imaginære personlige bilder.
- Tekst-til-lyd eller video – Både merkede og umerkede data kan brukes til FM-trening. Et hovedeksempel på generativ AI-bruk er musikkkomposisjon.
For å produsere disse generative AI-brukstilfellene, må vi låne og utvide MLOps-domenet til å inkludere følgende:
- FM-operasjoner (FMOps) – Dette kan produsere generative AI-løsninger, inkludert hvilken som helst type bruk
- LLM-operasjoner (LLMOps) – Dette er en undergruppe av FMO-er som fokuserer på produksjon av LLM-baserte løsninger, for eksempel tekst-til-tekst
Følgende figur illustrerer overlappingen av disse brukstilfellene.
Sammenlignet med klassiske ML og MLOps, utsetter FMOps og LLMOps basert på fire hovedkategorier som vi dekker i følgende seksjoner: mennesker og prosess, valg og tilpasning av FM, evaluering og overvåking av FM, datapersonvern og modellimplementering, og teknologibehov. Vi vil ta for oss overvåking i et eget innlegg.
Operasjonaliseringsreise per generativ AI-brukertype
For å forenkle beskrivelsen av prosessene, må vi kategorisere de viktigste generative AI-brukertypene, som vist i følgende figur.
Brukertypene er som følger:
- tilbydere – Brukere som bygger FM-er fra bunnen av og leverer dem som et produkt til andre brukere (fintuner og forbruker). De har dyp ende-til-ende ML og naturlig språkbehandling (NLP) ekspertise og datavitenskapelige ferdigheter, og massive datamerker- og redaktørteam.
- Finjustere – Brukere som omskoler (finjusterer) FM-er fra leverandører for å passe tilpassede krav. De organiserer utrullingen av modellen som en tjeneste for bruk av forbrukere. Disse brukerne trenger sterk ende-til-ende ML og datavitenskap ekspertise og kunnskap om modellimplementering og inferens. Sterk domenekunnskap for tuning, inkludert prompt engineering, er også nødvendig.
- Forbrukere – Brukere som samhandler med generative AI-tjenester fra leverandører eller finjustere ved hjelp av tekstmeldinger eller et visuelt grensesnitt for å fullføre ønskede handlinger. Ingen ML-ekspertise kreves, men for det meste applikasjonsutviklere eller sluttbrukere med forståelse for tjenestemulighetene. Bare rask prosjektering er nødvendig for bedre resultater.
I henhold til definisjonen og den nødvendige ML-ekspertisen, kreves MLOps mest for leverandører og finjustere, mens forbrukere kan bruke applikasjonsproduksjonsprinsipper, som DevOps og AppDev for å lage generative AI-applikasjoner. Videre har vi observert en bevegelse blant brukertypene, der tilbydere kan bli finjustere for å støtte brukstilfeller basert på en spesifikk vertikal (som finanssektoren) eller forbrukere kan bli finjustere for å oppnå mer nøyaktige resultater. Men la oss observere hovedprosessene per brukertype.
Forbrukernes reise
Følgende figur illustrerer forbrukerreisen.
Som tidligere nevnt, er forbrukere pålagt å velge, teste og bruke en FM, samhandle med den ved å gi spesifikke innganger, ellers kjent som ledetekster. Forespørsler, i sammenheng med dataprogrammering og AI, refererer til input som gis til en modell eller et system for å generere et svar. Dette kan være i form av en tekst, kommando eller et spørsmål, som systemet bruker til å behandle og generere et utdata. Utgangen generert av FM kan deretter brukes av sluttbrukere, som også bør kunne vurdere disse utgangene for å forbedre modellens fremtidige responser.
Utover disse grunnleggende prosessene, har vi lagt merke til at forbrukere uttrykker et ønske om å finjustere en modell ved å utnytte funksjonaliteten som finjusteres. Ta for eksempel et nettsted som genererer bilder. Her kan sluttbrukere sette opp private kontoer, laste opp personlige bilder og deretter generere innhold relatert til disse bildene (for eksempel generere et bilde som viser sluttbrukeren på en motorsykkel som bruker et sverd eller befinner seg på et eksotisk sted). I dette scenariet må den generative AI-applikasjonen, designet av forbrukeren, samhandle med finjusterende backend via APIer for å levere denne funksjonaliteten til sluttbrukerne.
Men før vi fordyper oss i det, la oss først konsentrere oss om reisen med modellvalg, testing, bruk, input og output interaksjon og vurdering, som vist i følgende figur.
*15K tilgjengelig FM-referanse
Trinn 1. Forstå de beste FM-funksjonene
Det er mange dimensjoner som må vurderes ved valg av fundamentmodeller, avhengig av bruksområdet, tilgjengelige data, forskrifter og så videre. En god sjekkliste, selv om den ikke er fullstendig, kan være følgende:
- Proprietær eller åpen kildekode FM – Proprietære modeller har ofte en økonomisk kostnad, men de tilbyr vanligvis bedre ytelse (når det gjelder kvaliteten på den genererte teksten eller bildet), ofte utviklet og vedlikeholdt av dedikerte team av modellleverandører som sikrer optimal ytelse og pålitelighet. På den annen side ser vi også bruk av åpen kildekode-modeller som, bortsett fra å være gratis, tilbyr ytterligere fordeler ved å være tilgjengelige og fleksible (for eksempel kan hver åpen kildekode-modell finjusteres). Et eksempel på en proprietær modell er Anthropics Claude-modell, og et eksempel på en høyytende åpen kildekode-modell er Falcon-40B, fra og med juli 2023.
- Kommersiell lisens – Konsesjonshensyn er avgjørende når man skal velge en FM. Det er viktig å merke seg at noen modeller er åpen kildekode, men kan ikke brukes til kommersielle formål, på grunn av lisensieringsbegrensninger eller betingelser. Forskjellene kan være subtile: Den nylig utgitte xgen-7b-8k-base modell, for eksempel, er åpen kildekode og kommersielt brukbar (Apache-2.0-lisens), mens den instruksjonsfinjusterte versjonen av modellen xgen-7b-8k-inst utgis kun for forskningsformål. Når du velger en FM for en kommersiell applikasjon, er det viktig å verifisere lisensavtalen, forstå dens begrensninger og sikre at den stemmer overens med den tiltenkte bruken av prosjektet.
- parametere – Antall parametere, som består av vektene og skjevhetene i det nevrale nettverket, er en annen nøkkelfaktor. Flere parametere betyr generelt en mer kompleks og potensielt kraftig modell, fordi den kan fange opp mer intrikate mønstre og korrelasjoner i dataene. Avveiningen er imidlertid at det krever flere beregningsressurser og derfor koster mer å kjøre. I tillegg ser vi en trend mot mindre modeller, spesielt i åpen kildekode (modeller fra 7–40 milliarder) som gir gode resultater, spesielt når de er finjustert.
- Speed – Hastigheten til en modell påvirkes av størrelsen. Større modeller har en tendens til å behandle data langsommere (høyere latens) på grunn av den økte beregningskompleksiteten. Derfor er det avgjørende å balansere behovet for en modell med høy prediktiv kraft (ofte større modeller) med de praktiske kravene til hastighet, spesielt i applikasjoner, som chat-bots, som krever svar i sanntid eller nesten sanntid.
- Kontekstvindustørrelse (antall tokens) – Kontekstvinduet, definert av det maksimale antallet tokens som kan legges inn eller skrives ut per ledetekst, er avgjørende for å bestemme hvor mye kontekst modellen kan vurdere om gangen (et token kan grovt oversettes til 0.75 ord for engelsk). Modeller med større kontekstvinduer kan forstå og generere lengre tekstsekvenser, noe som kan være nyttig for oppgaver som involverer lengre samtaler eller dokumenter.
- Opplæringsdatasett – Det er også viktig å forstå hva slags data FM ble trent på. Noen modeller kan trenes på forskjellige tekstdatasett som internettdata, kodeskript, instruksjoner eller menneskelig tilbakemelding. Andre kan også trenes på multimodale datasett, som kombinasjoner av tekst- og bildedata. Dette kan påvirke modellens egnethet for ulike oppgaver. I tillegg kan en organisasjon ha opphavsrettsbekymringer avhengig av de eksakte kildene en modell har blitt trent på – derfor er det obligatorisk å inspisere opplæringsdatasettet nøye.
- Kvalitet – Kvaliteten på en FM kan variere basert på typen (proprietær vs. åpen kildekode), størrelse og hva den ble trent på. Kvalitet er kontekstavhengig, noe som betyr at det som anses som høy kvalitet for en applikasjon kanskje ikke er for en annen. For eksempel kan en modell trent på internettdata betraktes som høy kvalitet for å generere samtaletekst, men mindre for tekniske eller spesialiserte oppgaver.
- Finjusterbar – Evnen til å finjustere en FM ved å justere modellvektene eller -lagene kan være en avgjørende faktor. Finjustering gjør at modellen bedre tilpasser seg den spesifikke konteksten til applikasjonen, og forbedrer ytelsen på den spesifikke oppgaven. Finjustering krever imidlertid ekstra beregningsressurser og teknisk ekspertise, og ikke alle modeller støtter denne funksjonen. Åpen kildekode-modeller er (generelt) alltid finjusterbare fordi modellartefaktene er tilgjengelige for nedlasting og brukerne kan utvide og bruke dem etter eget ønske. Proprietære modeller kan noen ganger tilby muligheten for finjustering.
- Eksisterende kundekompetanse – Valget av en FM kan også påvirkes av ferdighetene og kjennskapen til kunden eller utviklingsteamet. Hvis en organisasjon ikke har noen AI/ML-eksperter i teamet sitt, kan en API-tjeneste være bedre egnet for dem. Dessuten, hvis et team har lang erfaring med en spesifikk FM, kan det være mer effektivt å fortsette å bruke det i stedet for å investere tid og ressurser for å lære og tilpasse seg en ny.
Følgende er et eksempel på to shortlister, en for proprietære modeller og en for åpen kildekode-modeller. Du kan kompilere lignende tabeller basert på dine spesifikke behov for å få en rask oversikt over de tilgjengelige alternativene. Merk at ytelsen og parameterne til disse modellene endres raskt og kan være utdaterte ved lesing, mens andre funksjoner kan være viktige for spesifikke kunder, for eksempel det støttede språket.
Følgende er et eksempel på bemerkelsesverdige proprietære FM-er tilgjengelig i AWS (juli 2023).
Følgende er et eksempel på bemerkelsesverdig åpen kildekode FM tilgjengelig i AWS (juli 2023).
Etter at du har samlet en oversikt over 10–20 potensielle kandidatmodeller, blir det nødvendig å avgrense denne kortlisten ytterligere. I denne delen foreslår vi en rask mekanisme som vil gi to eller tre levedyktige endelige modeller som kandidater for neste runde.
Følgende diagram illustrerer den innledende shortlistingsprosessen.
Vanligvis eksperimenterer raske ingeniører, som er eksperter på å lage meldinger av høy kvalitet som lar AI-modeller forstå og behandle brukerinndata, med ulike metoder for å utføre den samme oppgaven (som oppsummering) på en modell. Vi foreslår at disse ledetekstene ikke opprettes umiddelbart, men at de systematisk trekkes ut fra en ledetekstkatalog. Denne ledetekstkatalogen er et sentralt sted for lagring av forespørsler for å unngå replikasjoner, aktivere versjonskontroll og dele forespørsler i teamet for å sikre konsistens mellom forskjellige ledeteksttestere i de forskjellige utviklingsstadiene, som vi introduserer i neste avsnitt. Denne ledetekstkatalogen er analog med et Git-lager i en funksjonsbutikk. Den generative AI-utvikleren, som potensielt kan være den samme personen som den prompte ingeniøren, må deretter evaluere produksjonen for å finne ut om den passer for den generative AI-applikasjonen de søker å utvikle.
Trinn 2. Test og evaluer topp FM
Etter at shortlisten er redusert til omtrent tre FM-er, anbefaler vi et evalueringstrinn for å teste FM-enes evner og egnethet for brukssaken ytterligere. Avhengig av tilgjengeligheten og arten av evalueringsdata, foreslår vi forskjellige metoder, som illustrert i følgende figur.
Metoden du skal bruke først, avhenger av om du har merket testdata eller ikke.
Hvis du har merket data, kan du bruke den til å gjennomføre en modellevaluering, slik vi gjør med de tradisjonelle ML-modellene (legg inn noen prøver og sammenlign resultatet med etikettene). Avhengig av om testdataene har diskrete etiketter (som positiv, negativ eller nøytral sentimentanalyse) eller er ustrukturert tekst (som oppsummering), foreslår vi forskjellige metoder for evaluering:
- Nøyaktighetsmålinger – I tilfelle av diskrete utdata (som sentimentanalyse), kan vi bruke standard nøyaktighetsmålinger som presisjon, tilbakekalling og F1-score
- Likhetsberegninger – Hvis utdataene er ustrukturerte (for eksempel et sammendrag), foreslår vi likhetsberegninger som ROUGE og cosinuslikhet
Noen brukstilfeller egner seg ikke til å ha ett sant svar (for eksempel "Lag en kort barnehistorie for min 5 år gamle datter"). I slike tilfeller blir det mer utfordrende å evaluere modellene fordi man ikke har merket testdata. Vi foreslår to tilnærminger, avhengig av viktigheten av menneskelig gjennomgang av modellen versus automatisert evaluering:
- Menneske-i-løkken (HIL) – I dette tilfellet vil et team med raske testere gjennomgå svarene fra en modell. Avhengig av hvor kritisk applikasjonen er, kan testerne gjennomgå 100 % av modellutdataene eller bare et utvalg.
- LLM-drevet evaluering – I dette scenariet erstattes promptetesterne av en LLM, ideelt sett en som er kraftigere (selv om kanskje tregere og mest kostbar) enn de som testes. LLM vil gjennomgå alle modellgenererte svar og score dem. Denne metoden kan resultere i lavere kvalitet, men det er et billigere og raskere evalueringsalternativ som kan gi en god innledende måler på modellenes ytelse.
For eksempel kan vi bruke følgende eksempelmelding til en LLM, som inkluderer inndataspørringen, LLM-svaret og instruksjoner: «Vi vil gjerne be om tilbakemelding på ytelsen til en AI-assistent som svar på brukerspørsmålet som vises ovenfor . Vurder hjelpsomheten, relevansen, nøyaktigheten, detaljnivået til assistentens svar. Assistenten skal få en samlet poengsum på en skala fra 1 til 10, der en høyere poengsum indikerer bedre total ytelse.»
Denne forespørselen vil bli sendt til en annen LLM (EvalLLM) for evaluering. Følgende er et eksempel hvor responsen til Falcon-40B-modellen har blitt evaluert av en EvalLLM (i dette tilfellet Claude). Vi bruker spørsmålet "Hva om Suez-kanalen aldri hadde blitt bygget?" Svaret er som følger:
Spørsmål: Hva om Suez-kanalen aldri hadde blitt bygget?
falk-40b-instruks
Hvis Suez-kanalen aldri hadde blitt bygget, ville skip måtte reise rundt i Afrika for å navigere mellom Middelhavet og Rødehavet. Dette vil legge til betydelig tid og avstand til reisen, noe som gjør den mindre effektiv og dyrere. I tillegg, uten Suez-kanalen, ville mange land i Midtøsten og Nord-Afrika vært mye mindre knyttet til resten av verden, og hindret økonomisk og kulturell utvikling.
Anmeldelse (poengsum: 9/10)
Assistentens svar er svært relevant, nøyaktig og detaljert. Det gir et utmerket svar på brukerens hypotetiske spørsmål om Suez-kanalens ikke-eksistens. Assistenten påpeker med rette implikasjonene på maritime reiser og den økonomiske og kulturelle innvirkningen på Midtøsten og Nord-Afrika. Imidlertid kunne den ha utdypet de geopolitiske implikasjonene eller innvirkningen på globale handelsmønstre for en mer omfattende respons.
Følgende figur illustrerer ende-til-ende-eksemplet på evalueringsprosessen.
Basert på dette eksemplet, for å utføre evaluering, må vi gi eksempelmeldinger, som vi lagrer i ledetekstkatalogen, og et evalueringsmerket eller umerket datasett basert på våre spesifikke applikasjoner. For eksempel, med et merket evalueringsdatasett, kan vi gi spørsmål (inndata og spørringer) som "Gi meg det fulle navnet til Storbritannias statsminister i 2023" og utdata og svar, for eksempel "Rishi Sunak." Med et umerket datasett gir vi bare spørsmålet eller instruksjonene, for eksempel "Generer kildekoden for et nettsted for detaljhandel." Vi kaller kombinasjonen av promptkatalog og evalueringsdatasett for katalog for evalueringsspørsmål. Grunnen til at vi skiller ledetekstkatalogen og evalueringsspørsmålskatalogen er fordi sistnevnte er dedikert til et spesifikt brukstilfelle i stedet for generiske forespørsler og instruksjoner (som svar på spørsmål) som ledetekstkatalogen inneholder.
Med denne evalueringsforespørselskatalogen er neste trinn å sende evalueringsspørsmålene til de beste FM-ene. Resultatet er et evalueringsresultatdatasett som inneholder ledetekstene, utgangene fra hver FM og den merkede utgangen sammen med en poengsum (hvis den finnes). I tilfelle av en umerket evalueringsforespørselskatalog, er det et ekstra trinn for en HIL eller LLM for å gjennomgå resultatene og gi en poengsum og tilbakemelding (som vi beskrev tidligere). Det endelige resultatet vil være aggregerte resultater som kombinerer poengsummene til alle utdataene (beregn gjennomsnittlig presisjon eller menneskelig vurdering) og lar brukerne måle kvaliteten på modellene.
Etter at evalueringsresultatene er samlet, foreslår vi å velge en modell basert på flere dimensjoner. Disse kommer vanligvis ned til faktorer som presisjon, hastighet og kostnad. Følgende figur viser et eksempel.
Hver modell vil ha styrker og visse avveininger langs disse dimensjonene. Avhengig av brukstilfellet bør vi tilordne ulike prioriteringer til disse dimensjonene. I det foregående eksempelet valgte vi å prioritere kostnad som den viktigste faktoren, etterfulgt av presisjon og deretter hastighet. Selv om den er tregere og ikke like effektiv som FM1, forblir den tilstrekkelig effektiv og betydelig billigere å være vert for. Følgelig kan vi velge FM2 som det beste valget.
Trinn 3. Utvikle den generative AI-applikasjonens backend og frontend
På dette tidspunktet har de generative AI-utviklerne valgt riktig FM for den spesifikke applikasjonen sammen med hjelp av raske ingeniører og testere. Det neste trinnet er å begynne å utvikle den generative AI-applikasjonen. Vi har delt utviklingen av den generative AI-applikasjonen i to lag, en backend og en frontend, som vist i følgende figur.
På baksiden inkorporerer de generative AI-utviklerne den valgte FM-en i løsningene og jobber sammen med ingeniørene for å lage automatiseringen for å transformere sluttbrukerens input til passende FM-meldinger. Spørretesterne oppretter de nødvendige oppføringene til ledetekstkatalogen for automatisk eller manuell (HIL eller LLM) testing. Deretter oppretter de generative AI-utviklerne den umiddelbare kjede- og applikasjonsmekanismen for å gi det endelige resultatet. Rask kjeding, i denne sammenhengen, er en teknikk for å lage mer dynamiske og kontekstuelt bevisste LLM-applikasjoner. Det fungerer ved å bryte ned en kompleks oppgave i en serie med mindre, mer håndterbare underoppgaver. For eksempel, hvis vi stiller en LLM spørsmålet "Hvor ble statsministeren i Storbritannia født og hvor langt er det stedet fra London," kan oppgaven deles opp i individuelle spørsmål, der en melding kan bygges basert på svaret av en tidligere rask evaluering, for eksempel «Hvem er Storbritannias statsminister», «Hva er fødestedet deres» og «Hvor langt er det stedet fra London?» For å sikre en viss inngangs- og utdatakvalitet, må de generative AI-utviklerne også lage mekanismen for å overvåke og filtrere sluttbrukerinndata og applikasjonsutganger. Hvis, for eksempel, LLM-applikasjonen er ment å unngå giftige forespørsler og svar, kan de bruke en toksisitetsdetektor for input og output og filtrere disse ut. Til slutt må de tilby en vurderingsmekanisme som vil støtte utvidelsen av evalueringsforespørselskatalogen med gode og dårlige eksempler. En mer detaljert representasjon av disse mekanismene vil bli presentert i fremtidige innlegg.
For å gi funksjonaliteten til den generative AI-sluttbrukeren, er utviklingen av et frontend-nettsted som samhandler med backend nødvendig. Derfor må DevOps og AppDevs (applikasjonsutviklere på skyen) følge beste utviklingspraksis for å implementere funksjonaliteten til input/output og vurdering.
I tillegg til denne grunnleggende funksjonaliteten, må frontend og backend inkludere funksjonen med å opprette personlige brukerkontoer, laste opp data, starte finjustering som en svart boks og bruke den personlige modellen i stedet for den grunnleggende FM. Produksjonen av en generativ AI-applikasjon er lik en normal applikasjon. Følgende figur viser et eksempel på arkitektur.
I denne arkitekturen oppretter og tester de generative AI-utviklerne, prompteingeniørene og DevOps eller AppDevs applikasjonen manuelt ved å distribuere den via CI/CD til et utviklingsmiljø (generativ AI App Dev i den foregående figuren) ved å bruke dedikerte kodelagre og slå sammen med utviklergrenen. På dette stadiet vil de generative AI-utviklerne bruke den tilsvarende FM-en ved å kalle API-en slik den er levert av FM-leverandørene av fininnstillere. Deretter, for å teste applikasjonen omfattende, må de promotere koden til testgrenen, som vil utløse distribusjonen via CI/CD til preproduksjonsmiljøet (generativ AI App Pre-prod). I dette miljøet må spørretesterne prøve en stor mengde spørsmålskombinasjoner og gjennomgå resultatene. Kombinasjonen av forespørsler, utganger og gjennomgang må flyttes til katalogen for evalueringsspørsmål for å automatisere testprosessen i fremtiden. Etter denne omfattende testen er det siste trinnet å promotere den generative AI-applikasjonen til produksjon via CI/CD ved å slå sammen med hovedgrenen (generativ AI App Prod). Merk at alle dataene, inkludert ledetekstkatalogen, evalueringsdata og -resultater, sluttbrukerdata og metadata, og finjusterte modellmetadata, må lagres i datainnsjøen eller datanettlaget. CI/CD-rørledningene og depotene må lagres i en separat verktøykonto (lik den som er beskrevet for MLOps).
Reisen til tilbyderne
FM-leverandører må trene FM-er, for eksempel dyplæringsmodeller. For dem er ende-til-ende MLOps livssyklus og infrastruktur nødvendig. Det kreves tillegg i utarbeidelse av historiske data, modellevaluering og overvåking. Følgende figur illustrerer reisen deres.
I klassisk ML skapes de historiske dataene oftest ved å mate bakkens sannhet via ETL-rørledninger. For eksempel, i et brukstilfelle av churn-prediksjon, oppdaterer en automatisering en databasetabell basert på den nye statusen til en kunde for å churn/ikke churn automatisk. Når det gjelder FM-er, trenger de enten milliarder av merkede eller umerkede datapunkter. I tekst-til-bilde brukssaker må et team av datamerkere merke parer manuelt. Dette er en kostbar øvelse som krever et stort antall mennesker ressurser. Amazon SageMaker Ground Truth Plus kan tilby et team av etikettere til å utføre denne aktiviteten for deg. For noen brukstilfeller kan denne prosessen også delvis automatiseres, for eksempel ved å bruke CLIP-lignende modeller. Når det gjelder en LLM, for eksempel tekst-til-tekst, er dataene umerket. Imidlertid må de være forberedt og følge formatet til eksisterende historiske umerkede data. Derfor trengs dataredigerere for å utføre nødvendig dataforberedelse og sikre konsistens.
Med de historiske dataene utarbeidet, er neste trinn opplæring og produksjon av modellen. Merk at de samme evalueringsteknikkene som vi beskrev for forbrukere kan brukes.
Fintunernes reise
Fintunere tar sikte på å tilpasse en eksisterende FM til deres spesifikke kontekst. For eksempel kan en FM-modell oppsummere en generell tekst, men ikke en finansiell rapport nøyaktig, eller den kan ikke generere kildekode for et ikke-vanlig programmeringsspråk. I disse tilfellene må finjustere merke data, finjustere en modell ved å kjøre en opplæringsjobb, distribuere modellen, teste den basert på forbrukerprosessene og overvåke modellen. Følgende diagram illustrerer denne prosessen.
Foreløpig er det to finjusteringsmekanismer:
- Finjustering – Ved å bruke en FM og merkede data, beregner en treningsjobb vektene og skjevhetene til de dype læringsmodelllagene. Denne prosessen kan være beregningsintensiv og krever en representativ mengde data, men kan generere nøyaktige resultater.
- Parametereffektiv finjustering (PEFT) – I stedet for å beregne alle vektene og skjevhetene på nytt, har forskere vist at ved å legge til flere små lag til dyplæringsmodellene, kan de oppnå tilfredsstillende resultater (f.eks. LoRA). PEFT krever lavere beregningskraft enn dyp finjustering og en treningsjobb med mindre inndata. Ulempen er potensiell lavere nøyaktighet.
Følgende diagram illustrerer disse mekanismene.
Nå som vi har definert de to viktigste finjusteringsmetodene, er neste trinn å bestemme hvordan vi kan distribuere og bruke åpen kildekode og proprietær FM.
Med åpen kildekode FM-er kan fininnstillerne laste ned modellartefakten og kildekoden fra nettet, for eksempel ved å bruke Hugging Face Model Hub. Dette gir deg fleksibiliteten til å finjustere modellen, lagre den i et lokalt modellregister og distribuere den til en Amazon SageMaker endepunkt. Denne prosessen krever en internettforbindelse. For å støtte sikrere miljøer (som for kunder i finanssektoren), kan du laste ned modellen på stedet, kjøre alle nødvendige sikkerhetssjekker og laste dem opp til en lokal bøtte på en AWS-konto. Deretter bruker finstillerne FM-en fra den lokale bøtten uten internettforbindelse. Dette sikrer personvern, og dataene går ikke over internett. Følgende diagram illustrerer denne metoden.
Med proprietære FM-er er distribusjonsprosessen annerledes fordi fininnstillerne ikke har tilgang til modellartefakten eller kildekoden. Modellene er lagret i proprietære FM-leverandørens AWS-kontoer og modellregistre. For å distribuere en slik modell til et SageMaker-endepunkt, kan finjustere be om bare modellpakken som vil bli distribuert direkte til et endepunkt. Denne prosessen krever at kundedata brukes i de proprietære FM-leverandørenes kontoer, noe som reiser spørsmål angående kundesensitive data som brukes i en ekstern konto for å utføre finjustering, og modeller som er vert i et modellregister som deles mellom flere kunder . Dette fører til et problem med flere leieforhold som blir mer utfordrende hvis de proprietære FM-leverandørene trenger å betjene disse modellene. Hvis finstillerne bruker Amazonas grunnfjell, er disse utfordringene løst – dataene går ikke over internett og FM-leverandørene har ikke tilgang til fininnstillernes data. De samme utfordringene gjelder for modellene med åpen kildekode hvis finjustererne ønsker å betjene modeller fra flere kunder, som eksempelet vi ga tidligere med nettsiden som tusenvis av kunder vil laste opp personlige bilder til. Imidlertid kan disse scenariene betraktes som kontrollerbare fordi bare fininnstilleren er involvert. Følgende diagram illustrerer denne metoden.
Fra et teknologiperspektiv er arkitekturen som en fininnstiller trenger å støtte som den for MLOps (se følgende figur). Finjusteringen må utføres i dev ved å lage ML-rørledninger, for eksempel ved å bruke Amazon SageMaker-rørledninger; utføre forbehandling, finjustering (opplæringsjobb) og etterbehandling; og sende de finjusterte modellene til et lokalt modellregister i tilfelle en åpen kildekode FM (ellers vil den nye modellen bli lagret i det proprietære FM-leverandørmiljøet). Så, i pre-produksjon, må vi teste modellen slik vi beskriver for forbrukernes scenario. Til slutt vil modellen bli servert og overvåket i prod. Merk at gjeldende (finjusterte) FM krever GPU-forekomstendepunkter. Hvis vi trenger å distribuere hver finjusterte modell til et eget endepunkt, kan dette øke kostnadene for hundrevis av modeller. Derfor må vi bruke multi-modell endepunkter og løse multi-tenancy utfordringen.
Fintunerne tilpasser en FM-modell basert på en spesifikk kontekst for å bruke den til sitt forretningsformål. Det betyr at det meste av tiden, finjustere også er forbrukere som kreves for å støtte alle lagene, som vi beskrev i de forrige avsnittene, inkludert utvikling av generativ AI-applikasjon, datainnsjø og datanettverk, og MLOps.
Den følgende figuren illustrerer hele livssyklusen for FM-finjustering som fininnstillerne trenger for å gi den generative AI-sluttbrukeren.
Følgende figur illustrerer de viktigste trinnene.
De viktigste trinnene er følgende:
- Sluttbrukeren oppretter en personlig konto og laster opp private data.
- Dataene lagres i datasjøen og er forhåndsbehandlet for å følge formatet som FM forventer.
- Dette utløser en finjusterende ML-pipeline som legger modellen til modellregisteret,
- Derfra blir enten modellen distribuert til produksjon med minimumstesting eller modellen driver omfattende testing med HIL og manuelle godkjenningsporter.
- Den finjusterte modellen er gjort tilgjengelig for sluttbrukere.
Fordi denne infrastrukturen er kompleks for ikke-bedriftskunder, ga AWS ut Amazon Bedrock for å avlaste arbeidet med å lage slike arkitekturer og bringe finjusterte FM-er nærmere produksjonen.
FMOps og LLMOps personaer og prosessdifferensiatorer
Basert på de foregående brukertypereisene (forbruker, produsent og finjusterer), kreves det nye personas med spesifikke ferdigheter, som illustrert i følgende figur.
De nye personasene er som følger:
- Datamerkere og redaktører – Disse brukerne merker data, som f.eks parer, eller klargjør umerkede data, for eksempel fritekst, og utvider det avanserte analyseteamet og datainnsjømiljøene.
- Finjustere – Disse brukerne har dyp kunnskap om FM-er og vet å tune dem, og utvider datavitenskapsteamet som vil fokusere på klassisk ML.
- Generative AI-utviklere – De har dyp kunnskap om valg av FM-er, kjetting av meldinger og applikasjoner, og filtrering av innganger og utganger. De tilhører et nytt team – det generative AI-applikasjonsteamet.
- Spørre ingeniører – Disse brukerne designer inn- og utgangsspørringene for å tilpasse løsningen til konteksten og teste og lage den første versjonen av ledetekstkatalogen. Teamet deres er det generative AI-applikasjonsteamet.
- Spør testere – De tester i stor skala den generative AI-løsningen (backend og frontend) og mater resultatene sine for å utvide den raske katalogen og evalueringsdatasettet. Teamet deres er det generative AI-applikasjonsteamet.
- AppDev og DevOps – De utvikler grensesnittet (som et nettsted) til den generative AI-applikasjonen. Teamet deres er det generative AI-applikasjonsteamet.
- Generative AI-sluttbrukere – Disse brukerne bruker generative AI-applikasjoner som svarte bokser, deler data og vurderer kvaliteten på utdataene.
Den utvidede versjonen av MLOps-prosesskartet for å inkorporere generativ AI kan illustreres med følgende figur.
Et nytt applikasjonslag er miljøet der generative AI-utviklere, promptingeniører og testere, og AppDevs skapte backend og frontend av generative AI-applikasjoner. De generative AI-sluttbrukerne samhandler med den generative AI-applikasjonens grensesnitt via internett (for eksempel et nettgrensesnitt). På den andre siden må datamerkere og redaktører forhåndsbehandle dataene uten å få tilgang til bakenden av datainnsjøen eller datanettverket. Derfor er et web-UI (nettsted) med en editor nødvendig for å samhandle sikkert med dataene. SageMaker Ground Truth gir denne funksjonaliteten rett ut av esken.
konklusjonen
MLOps kan hjelpe oss med å produsere ML-modeller effektivt. For å operasjonalisere generative AI-applikasjoner trenger du imidlertid ytterligere ferdigheter, prosesser og teknologier, noe som fører til FMOps og LLMOps. I dette innlegget definerte vi hovedkonseptene til FMOps og LLMOps og beskrev nøkkeldifferensiatorene sammenlignet med MLOps-evner når det gjelder mennesker, prosesser, teknologi, FM-modellvalg og evaluering. Videre illustrerte vi tankeprosessen til en generativ AI-utvikler og utviklingslivssyklusen til en generativ AI-applikasjon.
I fremtiden vil vi fokusere på å tilby løsninger per domenet vi diskuterte, og vil gi flere detaljer om hvordan vi kan integrere FM-overvåking (som toksisitet, skjevhet og hallusinasjoner) og tredjeparts eller private datakildearkitektoniske mønstre, som f.eks. Retrieval Augmented Generation (RAG), til FMOps/LLMOps.
For å lære mer, se MLOps foundation roadmap for bedrifter med Amazon SageMaker og prøv ut ende-til-ende-løsningen i Implementering av MLOps-praksis med Amazon SageMaker JumpStart forhåndstrente modeller.
Hvis du har kommentarer eller spørsmål, kan du legge dem igjen i kommentarfeltet.
Om forfatterne
Dr. Sokratis Kartakis er en senior løsningsarkitekt for maskinlæring og operasjoner for Amazon Web Services. Sokratis fokuserer på å gjøre bedriftskunder i stand til å industrialisere sine Machine Learning-løsninger (ML) ved å utnytte AWS-tjenester og forme deres driftsmodell, dvs. MLOps-grunnlag, og transformasjonsveikart ved å utnytte beste utviklingspraksis. Han har brukt 15+ år på å finne opp, designe, lede og implementere innovative ende-til-ende produksjonsnivå ML og Internet of Things (IoT) løsninger innen energi, detaljhandel, helse, finans/bank, motorsport etc. Sokratis liker å tilbringe fritiden med familie og venner, eller å kjøre motorsykkel.
Heiko Hotz er en senior løsningsarkitekt for AI og maskinlæring med spesielt fokus på naturlig språkbehandling, store språkmodeller og generativ AI. Før denne rollen var han sjef for datavitenskap for Amazons EU-kundeservice. Heiko hjelper kundene våre med å lykkes i deres AI/ML-reise på AWS og har jobbet med organisasjoner i mange bransjer, inkludert forsikring, finansielle tjenester, media og underholdning, helsetjenester, verktøy og produksjon. På fritiden reiser Heiko så mye som mulig.
- 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/fmops-llmops-operationalize-generative-ai-and-differences-with-mlops/
- : har
- :er
- :ikke
- :hvor
- $OPP
- 1
- 10
- 100
- 2023
- 23
- 7
- 75
- a
- evne
- I stand
- Om oss
- ovenfor
- ABSTRACT
- adgang
- tilgjengelig
- Tilgang
- Logg inn
- kontoer
- nøyaktighet
- nøyaktig
- nøyaktig
- Oppnå
- handlinger
- aktivitet
- tilpasse
- tilpasning
- legge til
- legge
- tillegg
- Ytterligere
- I tillegg
- tilleggene
- Legger
- administrasjon
- Adopsjon
- avansert
- afrika
- Etter
- Avtale
- AI
- AI og maskinlæring
- AI-assistent
- AI-modeller
- AI-tjenester
- ai brukstilfeller
- AI / ML
- sikte
- Justerer
- Alle
- tillate
- tillater
- langs
- allerede
- også
- Selv
- alltid
- Amazon
- Amazon SageMaker
- Amazon SageMaker JumpStart
- Amazon Web Services
- blant
- beløp
- an
- analyse
- analytics
- og
- og infrastruktur
- En annen
- besvare
- svar
- noen
- api
- APIer
- app
- Søknad
- Applikasjonutvikling
- søknader
- Påfør
- tilnærming
- tilnærminger
- hensiktsmessig
- godkjenning
- ca
- arkitekter
- arkitektonisk
- arkitektur
- ER
- rundt
- AS
- vurdere
- Assistent
- At
- revidert
- revisorer
- augmented
- automatisere
- Automatisert
- Automatisk
- automatisk
- Automatisering
- tilgjengelighet
- tilgjengelig
- gjennomsnittlig
- unngå
- AWS
- Backend
- dårlig
- Balansere
- basert
- grunnleggende
- BE
- fordi
- bli
- blir
- vært
- før du
- være
- benchmark
- Fordeler
- BEST
- Bedre
- mellom
- Bias
- skjevheter
- Milliarder
- milliarder
- Svart
- født
- låne
- både
- roboter
- Eske
- bokser
- Branch
- Breaking
- kort
- Bringe
- Brutt
- bygge
- Bygning
- bygget
- virksomhet
- men
- by
- beregne
- ring
- som heter
- ringer
- CAN
- kandidat
- kandidater
- evner
- evne
- fangst
- saken
- saker
- katalog
- kategorier
- sentral
- sentralisert
- viss
- utfordre
- utfordringer
- utfordrende
- endring
- chatbots
- billigere
- Sjekker
- valg
- velge
- Classic
- tett
- nærmere
- Klær
- Cloud
- kode
- Koding
- samarbeide
- kombinasjon
- kombinasjoner
- kombinere
- Kom
- kommentarer
- kommersiell
- kommersielt
- Felles
- sammenligne
- sammenlignet
- fullføre
- ferdigstillelse
- komplekse
- kompleksitet
- samsvar
- kompatibel
- sammensetning
- omfattende
- regnekraft
- datamaskin
- konsentrere
- konsept
- konsepter
- bekymringer
- forhold
- Gjennomføre
- gjennomført
- tilkoblet
- tilkobling
- Følgelig
- Vurder
- betraktninger
- ansett
- forbruke
- forbruker
- Forbrukere
- forbruk
- Container
- inneholder
- innhold
- innholdsskaping
- kontekst
- fortsette
- kontroll
- conversational
- samtaler
- copyright
- Tilsvarende
- Kostnad
- kostbar
- Kostnader
- kunne
- land
- dekke
- dekket
- skape
- opprettet
- skaper
- Opprette
- skaperverket
- kritisk
- avgjørende
- kulturell
- Gjeldende
- skikk
- kunde
- kunde Data
- Kundeservice
- Kunder
- dato
- Data Lake
- datapunkter
- Dataklargjøring
- personvern
- datavitenskap
- Database
- datasett
- desentralisert
- Avgjør
- avgjørelser
- dedikert
- dyp
- dypdykk
- dyp læring
- definert
- definere
- definisjon
- definisjoner
- leverer
- dybden
- Etterspørsel
- avhengig
- avhenger
- avbilder
- utplassere
- utplassert
- utplasserings
- distribusjon
- beskrive
- beskrevet
- beskrivelse
- utforming
- designet
- utforme
- ønske
- ønsket
- detaljert
- detaljer
- Bestem
- bestemme
- dev
- utvikle
- utviklet
- Utvikler
- utviklere
- utvikle
- Utvikling
- utviklingsteam
- forskjeller
- forskjellig
- differensiere
- dimensjoner
- direkte
- diskutere
- diskutert
- vises
- avstand
- dykk
- diverse
- do
- dokumenter
- ikke
- domene
- domener
- ikke
- ned
- nedlasting
- stasjonen
- to
- dynamisk
- e
- hver enkelt
- Tidligere
- øst
- lett
- økonomisk
- redaktør
- Effektiv
- effektiv
- effektivt
- innsats
- enten
- utdypet
- valgt
- muliggjøre
- muliggjør
- slutt
- ende til ende
- Endpoint
- energi
- ingeniør
- Ingeniørarbeid
- Ingeniører
- Engelsk
- forbedre
- sikre
- sikrer
- Enterprise
- bedrifter
- Entertainment
- Miljø
- miljøer
- like
- spesielt
- avgjørende
- etc
- EU
- evaluere
- evaluert
- evaluering
- Selv
- Hver
- eksempel
- eksempler
- utmerket
- opphisset
- Øvelse
- eksisterende
- finnes
- Eksotisk
- forventer
- dyrt
- erfaring
- eksperiment
- ekspertise
- eksperter
- utnytte
- utvide
- strekker
- forlengelse
- omfattende
- Omfattende erfaring
- omfattende
- trekke ut
- f1
- Face
- faktor
- faktorer
- Familiær
- familie
- langt
- raskere
- Trekk
- tilbakemelding
- fôring
- Figur
- filtrere
- filtrering
- slutt~~POS=TRUNC
- Endelig
- finansiell
- økonomisk Rapport
- Finansiell sektor
- finansielle tjenester
- Først
- passer
- fleksibilitet
- fleksibel
- Fokus
- fokuserte
- fokuserer
- fokusering
- følge
- fulgt
- etter
- følger
- Til
- For forbrukere
- skjema
- format
- Fundament
- fire
- Gratis
- venner
- fra
- foran
- Front end
- Frontend
- fullt
- funksjonalitet
- fundamental
- videre
- Dess
- framtid
- Gates
- måler
- general
- generell
- generelt
- generere
- generert
- genererer
- genererer
- generasjonen
- generative
- Generativ AI
- geopolitiske
- få
- gå
- gitt
- gir
- Global
- global handel
- god
- styresett
- GPU
- Ground
- HAD
- hånd
- Utnyttelse
- Ha
- å ha
- he
- hode
- Helse
- helsetjenester
- hjelpe
- hjelper
- her.
- Høy
- høykvalitets
- høyere
- svært
- hans
- historisk
- hold
- vert
- vert
- Hvordan
- Hvordan
- Men
- HTML
- HTTPS
- menneskelig
- Hundrevis
- i
- ideelt sett
- if
- illustrerer
- bilde
- bilder
- innbilt
- Påvirkning
- iverksette
- implementere
- implikasjoner
- betydning
- viktig
- bedre
- in
- inkludere
- inkluderer
- Inkludert
- innlemme
- Øke
- økt
- indikerer
- indikatorer
- individuelt
- bransjer
- påvirke
- påvirket
- Infrastruktur
- innledende
- innovative
- inngang
- innganger
- f.eks
- i stedet
- instruksjoner
- forsikring
- integrere
- tiltenkt
- samhandle
- samhandler
- interaksjon
- interaktiv
- Interface
- Internet
- Internett-tilkobling
- Internett av ting
- inn
- introdusere
- investere
- involvert
- involverer
- IOT
- IT
- DET ER
- Jobb
- reise
- Journeys
- Juli
- bare
- nøkkel
- nøkkelfaktor
- Type
- Vet
- kunnskap
- kjent
- Etiketten
- etiketter
- innsjø
- Språk
- stor
- større
- Siste
- Ventetid
- lag
- lag
- ledende
- Fører
- LÆRE
- læring
- Permisjon
- låne
- mindre
- Nivå
- utnytte
- bibliotekene
- Tillatelse
- Lisensiering
- Livssyklus
- i likhet med
- liker
- begrensninger
- LINK
- LLM
- laste
- lokal
- ligger
- plassering
- London
- Lang
- lenger
- lavere
- maskin
- maskinlæring
- laget
- Hoved
- vedlikeholde
- Flertall
- Making
- overkommelig
- obligatorisk
- håndbok
- manuelt
- produksjon
- mange
- kart
- massive
- modenhet
- maksimal
- Kan..
- me
- betyr
- midler
- mekanisme
- mekanismer
- Media
- Middelhavet
- nevnt
- sammenslåing
- mesh
- metadata
- metode
- metodikk
- metoder
- Metrics
- Middle
- Midtøsten
- kunne
- minimum
- ML
- MLOps
- modell
- modeller
- Overvåke
- overvåket
- overvåking
- mer
- mer effektivt
- mest
- for det meste
- Motorsport
- flytte
- flyttet
- bevegelse
- mye
- flere
- musikk
- må
- my
- navn
- Naturlig
- Natural Language Processing
- Natur
- Naviger
- nødvendig
- Trenger
- nødvendig
- behov
- negativ
- nettverk
- nevrale nettverket
- Nøytral
- aldri
- Ny
- nylig
- neste
- nlp
- Nei.
- normal
- nord
- bemerkelsesverdig
- Antall
- observere
- of
- tilby
- tilbudt
- ofte
- on
- onboarding
- ONE
- seg
- bare
- åpen
- åpen kildekode
- drift
- Drift
- optimal
- Alternativ
- alternativer
- or
- organisasjon
- organisasjoner
- Annen
- andre
- ellers
- vår
- ut
- Utfallet
- produksjon
- enn
- samlet
- oversikt
- egen
- eieren
- eiere
- pakke
- par
- parametere
- mønstre
- Ansatte
- for
- Utfør
- ytelse
- utfører
- kanskje
- person
- personlig
- Personlig
- perspektiv
- fase
- Bilder
- brikke
- rørledning
- Sted
- plattform
- plato
- Platon Data Intelligence
- PlatonData
- vær så snill
- Point
- poeng
- Politikk
- positiv
- besitter
- mulig
- Post
- innlegg
- potensiell
- potensielt
- makt
- kraftig
- Praktisk
- praksis
- Precision
- forutsi
- prediksjon
- Spådommer
- forberedelse
- Forbered
- forberedt
- forbereder
- presentert
- forrige
- tidligere
- Prime
- statsminister
- prinsipper
- Før
- Prioriter
- privatliv
- privat
- Problem
- prosess
- Prosesser
- prosessering
- produsert
- produsent
- Produkt
- Produksjon
- Programmering
- prosjekt
- fremme
- bevis
- proof of concept
- foreslå
- proprietær
- Bevis
- gi
- forutsatt
- leverandør
- tilbydere
- gir
- gi
- formål
- formål
- skyver
- puslespillet
- kvalitet
- spørsmål
- spørsmål
- Rask
- hever
- område
- spenner
- raskt
- Sats
- heller
- vurdering
- Lesning
- sanntids
- grunnen til
- motta
- anbefaler
- Rød
- Redusert
- avgrense
- om
- registre
- registret
- forskrifter
- i slekt
- utgitt
- relevans
- relevant
- pålitelighet
- forblir
- fjernkontroll
- erstattet
- rapporterer
- Repository
- representasjon
- representant
- anmode
- forespørsler
- påkrevd
- Krav
- Krever
- forskning
- forskere
- Ressurser
- henholdsvis
- svar
- svar
- ansvarlig
- REST
- restriksjoner
- restriktiv
- resultere
- Resultater
- detaljhandel
- gjenbruk
- anmeldelse
- anmeldt
- riding
- ikke sant
- veikart
- Rolle
- roller
- omtrent
- runde
- Kjør
- rennende
- sagemaker
- samme
- sandkasse
- Skala
- skalering
- scenario
- scenarier
- Vitenskap
- forskere
- Resultat
- skraper
- skript
- SEA
- Seksjon
- seksjoner
- sektor
- sikre
- sikkert
- sikkerhet
- sikkerhetspolitikk
- se
- søker
- valgt
- velge
- utvalg
- sending
- senior
- sendt
- sentiment
- separat
- Sequence
- Serien
- betjene
- tjeneste
- Tjenester
- servering
- sett
- flere
- forme
- Del
- delt
- skip
- Kort
- bør
- vist
- Viser
- side
- signifikant
- betydelig
- lignende
- forenkle
- Størrelse
- ferdigheter
- liten
- mindre
- SMB
- So
- løsning
- Solutions
- LØSE
- noen
- kilde
- kildekoden
- Kilder
- Rom
- spesiell
- spesialist
- spesialisert
- spesifikk
- spesielt
- fart
- bruke
- brukt
- Scene
- stadier
- interessenter
- Standard
- standardisere
- Begynn
- status
- Trinn
- Steps
- oppbevare
- lagret
- lagring
- Story
- styrker
- sterk
- I ettertid
- vellykket
- slik
- foreslår
- egnethet
- egnet
- oppsummere
- SAMMENDRAG
- støtte
- Støttes
- ment
- sikker
- SWIFT
- system
- bord
- Ta
- Oppgave
- oppgaver
- lag
- lag
- Teknisk
- teknikker
- Technologies
- Teknologi
- vilkår
- test
- testet
- testere
- Testing
- enn
- Det
- De
- Fremtiden
- Kilden
- Storbritannia
- verden
- deres
- Dem
- seg
- deretter
- Der.
- derfor
- Disse
- de
- ting
- tenker
- tredjeparts
- denne
- De
- selv om?
- trodde
- tusener
- tre
- tid
- til
- sammen
- token
- tokens
- topp
- temaer
- mot
- handel
- tradisjonelle
- Tog
- trent
- Kurs
- Transform
- Transformation
- reiser
- reiser
- Trend
- utløse
- sant
- Sannhet
- prøve
- to
- typen
- typer
- typisk
- ui
- Uk
- forstå
- forståelse
- enhet
- lomper
- oppdateringer
- Opplasting
- us
- bruk
- bruk
- bruke
- bruk sak
- brukt
- Bruker
- Brukere
- bruker
- ved hjelp av
- verktøy
- benyttes
- ulike
- verifisere
- versjon
- Versus
- vertikal
- av
- levedyktig
- visualisere
- vs
- ønsker
- var
- we
- web
- webtjenester
- Nettsted
- VI VIL
- Hva
- Hva er
- når
- mens
- om
- hvilken
- mens
- HVEM
- bred
- Bred rekkevidde
- vil
- vindu
- vinduer
- med
- innenfor
- uten
- ord
- ord
- Arbeid
- arbeide sammen
- arbeidet
- arbeid
- virker
- verden
- ville
- år
- Utbytte
- Du
- Din
- zephyrnet