I dag er størstedelen af vores kunder begejstrede for store sprogmodeller (LLM'er) og tænker på, hvordan generativ kunstig intelligens kan transformere deres forretning. Det er dog ikke en nem opgave at bringe sådanne løsninger og modeller til business-as-usual-driften. I dette indlæg diskuterer vi, hvordan man operationaliserer generative AI-applikationer ved hjælp af MLOps-principper, der fører til fundamentmodeloperationer (FMOps). Desuden dykker vi i dybden med det mest almindelige generative AI-brugstilfælde af tekst-til-tekst-applikationer og LLM-operationer (LLMOps), en undergruppe af FMOps. Følgende figur illustrerer de emner, vi diskuterer.
Specifikt introducerer vi kort MLOps principper og fokuserer på de vigtigste differentiatorer sammenlignet med FMOps og LLMOps vedrørende processer, mennesker, modelvalg og -evaluering, databeskyttelse og modelimplementering. Det gælder kunder, der bruger dem ud af boksen, skaber fundamentmodeller fra bunden eller finjusterer dem. Vores tilgang gælder både open source og proprietære modeller lige meget.
ML operationaliseringsoversigt
Som defineret i indlægget MLOps fundament køreplan for virksomheder med Amazon SageMaker, ML and operations (MLOps) er kombinationen af mennesker, processer og teknologi til at producere maskinlæringsløsninger (ML) effektivt. For at opnå dette skal en kombination af teams og personas samarbejde, som illustreret i den følgende figur.
Disse hold er som følger:
- Avanceret analyseteam (datasø og datamesh) – Dataingeniører er ansvarlige for at forberede og indtage data fra flere kilder, bygge ETL-pipelines (ekstrahere, transformere og indlæse) for at kurere og katalogisere dataene og forberede de nødvendige historiske data til ML-brugssager. Disse dataejere er fokuseret på at give adgang til deres data til flere forretningsenheder eller teams.
- Data science team – Dataforskere skal fokusere på at skabe den bedste model baseret på foruddefinerede nøglepræstationsindikatorer (KPI'er), der arbejder i notebooks. Efter afslutningen af forskningsfasen skal dataforskerne samarbejde med ML-ingeniører for at skabe automatiseringer til bygning (ML-pipelines) og implementering af modeller i produktion ved hjælp af CI/CD-pipelines.
- Business team – En produktejer er ansvarlig for at definere business case, krav og KPI'er, der skal bruges til at evaluere modellens ydeevne. ML-forbrugerne er andre forretningsinteressenter, der bruger slutningsresultaterne (forudsigelser) til at drive beslutninger.
- Platform team – Arkitekter er ansvarlige for virksomhedens overordnede cloud-arkitektur, og hvordan alle de forskellige tjenester hænger sammen. Sikkerhed SMV'er gennemgår arkitekturen baseret på virksomhedens sikkerhedspolitikker og behov. MLOps-ingeniører er ansvarlige for at levere et sikkert miljø for datavidenskabsmænd og ML-ingeniører til at producere ML-brugssager. Specifikt er de ansvarlige for standardisering af CI/CD-pipelines, bruger- og serviceroller og containeroprettelse, modelforbrug, testning og implementeringsmetoder baseret på forretnings- og sikkerhedskrav.
- Risiko- og compliance-team – I mere restriktive miljøer er revisorer ansvarlige for at vurdere data, kode og modelartefakter og sikre, at virksomheden overholder regler, såsom databeskyttelse.
Bemærk, at flere personer kan dækkes af den samme person afhængigt af virksomhedens skalering og MLOps-modenhed.
Disse personas har brug for dedikerede miljøer til at udføre de forskellige processer, som illustreret i den følgende figur.
Miljøerne er som følger:
- Platform administration – Platformadministrationsmiljøet er stedet, hvor platformsteamet har adgang til at oprette AWS-konti og linke de rigtige brugere og data
- data – Datalaget, ofte kendt som datasøen eller datanettet, er det miljø, som dataingeniører eller ejere og forretningsinteressenter bruger til at forberede, interagere og visualisere med dataene
- eksperimenter – Dataforskerne bruger en sandkasse eller et eksperimenteringsmiljø til at teste nye biblioteker og ML-teknikker for at bevise, at deres proof of concept kan løse forretningsproblemer
- Modelbygning, modeltest, modelimplementering – Modelbygnings-, test- og implementeringsmiljøet er laget af MLOps, hvor datavidenskabsmænd og ML-ingeniører samarbejder om at automatisere og flytte forskningen til produktion
- ML governance – Den sidste brik i puslespillet er ML-styringsmiljøet, hvor alle model- og kodeartefakter gemmes, gennemgås og revideres af de tilsvarende personer
Følgende diagram illustrerer referencearkitekturen, som allerede er blevet diskuteret i MLOps fundament køreplan for virksomheder med Amazon SageMaker.
Hver forretningsenhed har hvert eget sæt udviklingskonti (automatiseret modeltræning og -bygning), præproduktion (automatisk test) og produktion (modelimplementering og betjening) for at producere ML use cases, som henter data fra en centraliseret eller decentraliseret datasø eller data hhv. Alle de producerede modeller og kodeautomatisering er gemt i en centraliseret værktøjskonto ved hjælp af muligheden for et modelregister. Infrastrukturkoden for alle disse konti er versioneret i en delt servicekonto (advanced analytics governance-konto), som platformsteamet kan abstrahere, skabeloner, vedligeholde og genbruge til onboarding til MLOps-platformen for hvert nyt team.
Generative AI definitioner og forskelle til MLOps
I klassisk ML kan den foregående kombination af mennesker, processer og teknologi hjælpe dig med at produktisere dine ML use cases. I generativ AI kræver karakteren af use cases enten en udvidelse af disse muligheder eller nye muligheder. En af disse nye begreber er fundamentmodellen (FM). De kaldes som sådan, fordi de kan bruges til at skabe en lang række andre AI-modeller, som illustreret i den følgende figur.
FM er blevet trænet baseret på terabyte af data og har hundredvis af milliarder af parametre for at være i stand til at forudsige det næstbedste svar baseret på tre hovedkategorier af generative AI use cases:
- Tekst-til-tekst – FM'erne (LLM'erne) er blevet trænet baseret på umærkede data (såsom fri tekst) og er i stand til at forudsige det næstbedste ord eller rækkefølge af ord (afsnit eller lange essays). De vigtigste brugssager er omkring menneskelignende chatbots, opsummering eller anden indholdsskabelse såsom programmeringskode.
- Tekst-til-billede – Mærkede data, såsom par af , er blevet brugt til at træne FM'er, som er i stand til at forudsige den bedste kombination af pixels. Eksempler på brug er generering af tøjdesign eller imaginære personlige billeder.
- Tekst-til-lyd eller video – Både mærkede og umærkede data kan bruges til FM-træning. Et hovedeksempel på generativ AI-brug er musikkomposition.
For at producere disse generative AI-brugstilfælde er vi nødt til at låne og udvide MLOps-domænet til at omfatte følgende:
- FM-operationer (FMOps) – Dette kan producere generative AI-løsninger, inklusive enhver use case-type
- LLM operationer (LLMOps) – Dette er en undergruppe af FMO'er, der fokuserer på produktion af LLM-baserede løsninger, såsom tekst-til-tekst
Den følgende figur illustrerer overlapningen af disse use cases.
Sammenlignet med klassiske ML og MLOps udskyder FMOps og LLMOps baseret på fire hovedkategorier, som vi dækker i følgende afsnit: mennesker og proces, udvælgelse og tilpasning af FM, evaluering og overvågning af FM, databeskyttelse og modelimplementering og teknologibehov. Vi vil dække overvågning i et separat indlæg.
Operationaliseringsrejse pr. generativ AI-brugertype
For at forenkle beskrivelsen af processerne er vi nødt til at kategorisere de vigtigste generative AI-brugertyper, som vist i den følgende figur.
Brugertyperne er som følger:
- udbydere – Brugere, der bygger FM'er fra bunden og leverer dem som et produkt til andre brugere (fintuner og forbruger). De har dyb ende-til-ende ML og naturlig sprogbehandling (NLP) ekspertise og datavidenskabelige færdigheder og massive dataetiketterings- og redaktørteams.
- Fin-tunere – Brugere, der omskoler (finjusterer) FM'er fra udbydere, så de passer til tilpassede krav. De orkestrerer implementeringen af modellen som en service til brug for forbrugerne. Disse brugere har brug for stærk end-to-end ML og datavidenskabsekspertise og viden om modelimplementering og inferens. Stærk domænekendskab til tuning, herunder hurtig ingeniørarbejde, er også påkrævet.
- Forbrugere – Brugere, der interagerer med generative AI-tjenester fra udbydere eller finjustere ved hjælp af tekstbeskeder eller en visuel grænseflade for at fuldføre ønskede handlinger. Der kræves ingen ML-ekspertise, men for det meste applikationsudviklere eller slutbrugere med forståelse for servicemulighederne. Kun hurtig konstruktion er nødvendig for bedre resultater.
I henhold til definitionen og den påkrævede ML-ekspertise kræves MLOps mest for udbydere og finjustere, mens forbrugere kan bruge applikationsproduktionsprincipper, såsom DevOps og AppDev til at skabe de generative AI-applikationer. Desuden har vi observeret en bevægelse blandt brugertyperne, hvor udbydere kan blive finjustere til at understøtte use cases baseret på en specifik vertikal (såsom finanssektoren), eller forbrugere kan blive finjustere for at opnå mere præcise resultater. Men lad os observere hovedprocesserne pr. brugertype.
Forbrugernes rejse
Følgende figur illustrerer forbrugerrejsen.
Som tidligere nævnt er forbrugerne forpligtet til at vælge, teste og bruge en FM og interagere med den ved at levere specifikke input, også kendt som prompter. Forespørgsler, i forbindelse med computerprogrammering og AI, henviser til det input, der gives til en model eller et system for at generere et svar. Dette kan være i form af en tekst, kommando eller et spørgsmål, som systemet bruger til at behandle og generere et output. Det output, der genereres af FM, kan derefter udnyttes af slutbrugere, som også bør være i stand til at vurdere disse output for at forbedre modellens fremtidige svar.
Ud over disse grundlæggende processer har vi bemærket, at forbrugere udtrykker et ønske om at finjustere en model ved at udnytte den funktionalitet, som finjusteres. Tag for eksempel et websted, der genererer billeder. Her kan slutbrugere oprette private konti, uploade personlige billeder og efterfølgende generere indhold relateret til disse billeder (for eksempel generere et billede, der forestiller slutbrugeren på en motorcykel, der svinger et sværd eller befinder sig på et eksotisk sted). I dette scenarie skal den generative AI-applikation, der er designet af forbrugeren, interagere med finjusterende backend via API'er for at levere denne funktionalitet til slutbrugerne.
Men før vi dykker ned i det, lad os først koncentrere os om rejsen med modelvalg, test, brug, input og output interaktion og vurdering, som vist i den følgende figur.
Trin 1. Forstå de bedste FM-funktioner
Der er mange dimensioner, der skal tages i betragtning ved valg af fundamentmodeller, afhængigt af anvendelsesområdet, de tilgængelige data, regler og så videre. En god tjekliste, selvom den ikke er udtømmende, kan være følgende:
- Proprietær eller open source FM – Proprietære modeller har ofte en økonomisk omkostning, men de tilbyder typisk bedre ydeevne (med hensyn til kvaliteten af den genererede tekst eller billede), som ofte udvikles og vedligeholdes af dedikerede teams af modeludbydere, som sikrer optimal ydeevne og pålidelighed. På den anden side ser vi også adoption af open source-modeller, der ud over at være gratis tilbyder yderligere fordele ved at være tilgængelige og fleksible (for eksempel er enhver open source-model finjusterbar). Et eksempel på en proprietær model er Anthropics Claude-model, og et eksempel på en højtydende open source-model er Falcon-40B fra juli 2023.
- Kommerciel licens – Licensovervejelser er afgørende, når man skal beslutte sig for en FM. Det er vigtigt at bemærke, at nogle modeller er open source, men ikke kan bruges til kommercielle formål på grund af licensbegrænsninger eller betingelser. Forskellene kan være subtile: Den nyudgivne xgen-7b-8k-base model, for eksempel, er open source og kommercielt anvendelig (Apache-2.0 licens), hvorimod instruktions finjusteret version af modellen xgen-7b-8k-inst udgives kun til forskningsformål. Når du vælger en FM til en kommerciel applikation, er det vigtigt at verificere licensaftalen, forstå dens begrænsninger og sikre, at den stemmer overens med den tilsigtede brug af projektet.
- parametre – Antallet af parametre, som består af vægte og skævheder i det neurale netværk, er en anden nøglefaktor. Flere parametre betyder generelt en mere kompleks og potentielt kraftfuld model, fordi den kan fange mere indviklede mønstre og sammenhænge i dataene. Men afvejningen er, at det kræver flere beregningsressourcer og derfor koster mere at køre. Derudover ser vi en tendens til mindre modeller, især i open source-området (modeller fra 7-40 milliarder), der klarer sig godt, især når de er finjusteret.
- Speed – En models hastighed er påvirket af dens størrelse. Større modeller har en tendens til at behandle data langsommere (højere latency) på grund af den øgede beregningskompleksitet. Derfor er det afgørende at balancere behovet for en model med høj forudsigelseskraft (ofte større modeller) med de praktiske krav til hastighed, især i applikationer som chatbots, der kræver svar i realtid eller næsten i realtid.
- Kontekstvinduesstørrelse (antal tokens) – Kontekstvinduet, defineret af det maksimale antal tokens, der kan indtastes eller udlæses pr. prompt, er afgørende for at bestemme, hvor meget kontekst modellen kan overveje ad gangen (et token oversættes groft til 0.75 ord for engelsk). Modeller med større kontekstvinduer kan forstå og generere længere sekvenser af tekst, hvilket kan være nyttigt til opgaver, der involverer længere samtaler eller dokumenter.
- Træningsdatasæt – Det er også vigtigt at forstå, hvilken slags data FM blev trænet på. Nogle modeller kan trænes i forskellige tekstdatasæt som internetdata, kodningsscripts, instruktioner eller menneskelig feedback. Andre kan også trænes i multimodale datasæt, såsom kombinationer af tekst- og billeddata. Dette kan påvirke modellens egnethed til forskellige opgaver. Derudover kan en organisation have ophavsretlige bekymringer afhængigt af de nøjagtige kilder, en model er blevet trænet i - derfor er det obligatorisk at inspicere træningsdatasættet nøje.
- Kvalitet – Kvaliteten af en FM kan variere baseret på dens type (proprietær vs. open source), størrelse og hvad den er trænet i. Kvalitet er kontekstafhængig, hvilket betyder, at det, der anses for høj kvalitet for én applikation, måske ikke er for en anden. For eksempel kan en model, der er trænet på internetdata, betragtes som høj kvalitet til generering af samtaletekst, men mindre til tekniske eller specialiserede opgaver.
- Finjusterbar – Evnen til at finjustere en FM ved at justere dens modelvægte eller lag kan være en afgørende faktor. Finjustering gør det muligt for modellen bedre at tilpasse sig den specifikke kontekst af applikationen, hvilket forbedrer ydeevnen på den specifikke opgave. Finjustering kræver dog yderligere beregningsressourcer og teknisk ekspertise, og ikke alle modeller understøtter denne funktion. Open source-modeller er (generelt) altid finjusterbare, fordi modelartefakterne er tilgængelige til download, og brugerne er i stand til at udvide og bruge dem efter ønske. Proprietære modeller kan nogle gange tilbyde muligheden for finjustering.
- Eksisterende kundekompetencer – Valget af en FM kan også påvirkes af kundens eller udviklingsteamets færdigheder og kendskab. Hvis en organisation ikke har nogen AI/ML-eksperter i deres team, er en API-tjeneste måske bedre egnet til dem. Også, hvis et team har stor erfaring med en specifik FM, kan det være mere effektivt at fortsætte med at bruge det i stedet for at investere tid og ressourcer på at lære og tilpasse sig en ny.
Det følgende er et eksempel på to shortlister, en for proprietære modeller og en for open source-modeller. Du kan sammensætte lignende tabeller baseret på dine specifikke behov for at få et hurtigt overblik over de tilgængelige muligheder. Bemærk, at ydeevnen og parametrene for disse modeller ændrer sig hurtigt og kan være forældede på tidspunktet for læsning, mens andre funktioner kan være vigtige for specifikke kunder, såsom det understøttede sprog.
Det følgende er et eksempel på bemærkelsesværdige proprietære FM'er, der er tilgængelige i AWS (juli 2023).
Følgende er et eksempel på bemærkelsesværdig open source FM tilgængelig i AWS (juli 2023).
Når du har samlet en oversigt over 10-20 potentielle kandidatmodeller, bliver det nødvendigt at forfine denne shortliste yderligere. I dette afsnit foreslår vi en hurtig mekanisme, der vil give to eller tre levedygtige endelige modeller som kandidater til næste runde.
Følgende diagram illustrerer den indledende shortlisting-proces.
Typisk eksperimenterer prompte ingeniører, som er eksperter i at skabe højkvalitets prompter, der gør det muligt for AI-modeller at forstå og behandle brugerinput, med forskellige metoder til at udføre den samme opgave (såsom opsummering) på en model. Vi foreslår, at disse prompter ikke oprettes direkte, men systematisk uddrages fra et promptkatalog. Dette promptkatalog er en central placering til lagring af prompter for at undgå replikationer, aktivere versionskontrol og dele prompter inden for teamet for at sikre overensstemmelse mellem forskellige prompttestere i de forskellige udviklingsstadier, som vi introducerer i næste afsnit. Dette promptkatalog er analogt med et Git-lager i en funktionsbutik. Den generative AI-udvikler, som potentielt kan være den samme person som den prompte ingeniør, skal derefter evaluere outputtet for at afgøre, om det ville være egnet til den generative AI-applikation, de søger at udvikle.
Trin 2. Test og evaluer den øverste FM
Efter at shortlisten er reduceret til cirka tre FM'er, anbefaler vi et evalueringstrin for yderligere at teste FM'ernes kapacitet og egnethed til brugssagen. Afhængigt af tilgængeligheden og arten af evalueringsdata foreslår vi forskellige metoder, som illustreret i den følgende figur.
Metoden, der skal bruges først, afhænger af, om du har mærket testdata eller ej.
Hvis du har mærket data, kan du bruge det til at udføre en modelevaluering, som vi gør med de traditionelle ML-modeller (indtast nogle prøver og sammenlign output med etiketterne). Afhængigt af om testdataene har diskrete etiketter (såsom positiv, negativ eller neutral sentimentanalyse) eller er ustruktureret tekst (såsom opsummering), foreslår vi forskellige metoder til evaluering:
- Nøjagtighedsmålinger – I tilfælde af diskrete output (såsom sentimentanalyse) kan vi bruge standard nøjagtighedsmålinger såsom præcision, genkaldelse og F1-score
- Lighedsmålinger – Hvis outputtet er ustruktureret (såsom et resumé), foreslår vi lighedsmetrikker som ROUGE og cosinus-lighed
Nogle use cases egner sig ikke til at have ét rigtigt svar (f.eks. "Lav en kort børnehistorie til min 5-årige datter"). I sådanne tilfælde bliver det mere udfordrende at evaluere modellerne, fordi du ikke har mærkede testdata. Vi foreslår to tilgange, afhængigt af vigtigheden af menneskelig gennemgang af modellen versus automatiseret evaluering:
- Human-in-the-Loop (HIL) – I dette tilfælde vil et team af prompte testere gennemgå svarene fra en model. Afhængigt af hvor kritisk applikationen er, kan de hurtige testere gennemgå 100 % af modellens output eller blot en prøve.
- LLM-drevet evaluering – I dette scenarie erstattes de hurtige testere af en LLM, ideelt set en, der er mere kraftfuld (selv om den måske er langsommere og dyrest) end dem, der testes. LLM vil gennemgå alle modelgenererede svar og score dem. Denne metode kan resultere i lavere kvalitet, men det er en billigere og hurtigere evalueringsmulighed, der kan give en god indledende målestok for modellernes ydeevne.
For eksempel kan vi bruge følgende eksempelprompt til en LLM, som inkluderer inputforespørgslen, LLM-svaret og instruktioner: "Vi vil gerne anmode om din feedback om en AI-assistents ydeevne som svar på brugerspørgsmålet vist ovenfor . Bedøm venligst hjælpsomheden, relevansen, nøjagtigheden og detaljeringsgraden af assistentens svar. Assistenten skal modtage en samlet score på en skala fra 1 til 10, hvor en højere score indikerer bedre samlet præstation."
Denne prompt vil blive sendt til en anden LLM (EvalLLM) til evaluering. Det følgende er et eksempel, hvor responsen fra Falcon-40B-modellen er blevet evalueret af en EvalLLM (i dette tilfælde Claude). Vi bruger spørgsmålet "Hvad hvis Suez-kanalen aldrig var blevet bygget?" Svaret er som følger:
Spørgsmål: Hvad hvis Suez-kanalen aldrig var blevet bygget?
falcon-40b-instruktion
Hvis Suez-kanalen aldrig var blevet bygget, ville skibe skulle rejse rundt i Afrika for at navigere mellem Middelhavet og Det Røde Hav. Dette ville tilføje betydelig tid og afstand til rejsen, hvilket gør den mindre effektiv og dyrere. Derudover ville mange lande i Mellemøsten og Nordafrika uden Suez-kanalen have været meget mindre forbundet med resten af verden, hvilket hindrede økonomisk og kulturel udvikling.
Anmeldelse (score: 9/10)
Assistentens svar er yderst relevant, præcist og detaljeret. Det giver et glimrende svar på brugerens hypotetiske spørgsmål om Suez-kanalens ikke-eksistens. Assistenten påpeger korrekt implikationerne for maritime rejser og den økonomiske og kulturelle indvirkning på Mellemøsten og Nordafrika. Den kunne dog have uddybet de geopolitiske implikationer eller indvirkningen på globale handelsmønstre for en mere omfattende reaktion.
Følgende figur illustrerer ende-til-ende-evalueringsprocesseksemplet.
Baseret på dette eksempel skal vi, for at udføre evaluering, levere de eksempelprompter, som vi gemmer i promptkataloget, og et evalueringsmærket eller umærket datasæt baseret på vores specifikke applikationer. For eksempel kan vi med et mærket evalueringsdatasæt give prompter (input og forespørgsel) såsom "Giv mig det fulde navn på den britiske premierminister i 2023" og output og svar, såsom "Rishi Sunak." Med et umærket datasæt giver vi kun spørgsmålet eller instruktionen, såsom "Generer kildekoden til et detailwebsted." Vi kalder kombinationen af promptkatalog og evalueringsdatasæt for katalog med evalueringsprompt. Grunden til, at vi skelner mellem promptkataloget og evalueringspromptkataloget, er, at sidstnævnte er dedikeret til en specifik use case i stedet for generiske prompter og instruktioner (såsom spørgsmålssvar), som promptkataloget indeholder.
Med dette evalueringspromptkatalog er næste trin at sende evalueringsprompterne til de bedste FM'er. Resultatet er et evalueringsresultatdatasæt, der indeholder meddelelser, output fra hver FM og det mærkede output sammen med en score (hvis den findes). I tilfælde af et umærket evalueringspromptkatalog er der et ekstra trin for en HIL eller LLM at gennemgå resultaterne og give en score og feedback (som vi beskrev tidligere). Det endelige resultat vil være aggregerede resultater, der kombinerer scorerne for alle output (beregn den gennemsnitlige præcision eller menneskelig vurdering) og giver brugerne mulighed for at benchmarke kvaliteten af modellerne.
Efter at evalueringsresultaterne er indsamlet, foreslår vi at vælge en model baseret på flere dimensioner. Disse kommer typisk ned til faktorer som præcision, hastighed og omkostninger. Følgende figur viser et eksempel.
Hver model vil besidde styrker og visse afvejninger langs disse dimensioner. Afhængigt af brugssituationen bør vi tildele disse dimensioner forskellige prioriteter. I det foregående eksempel valgte vi at prioritere omkostninger som den vigtigste faktor, efterfulgt af præcision og derefter hastighed. Selvom det er langsommere og ikke så effektivt som FM1, forbliver det tilstrækkeligt effektivt og betydeligt billigere at hoste. Derfor kan vi vælge FM2 som det bedste valg.
Trin 3. Udvikl den generative AI-applikations backend og frontend
På dette tidspunkt har de generative AI-udviklere valgt den rigtige FM til den specifikke applikation sammen med hjælp fra hurtige ingeniører og testere. Det næste skridt er at begynde at udvikle den generative AI-applikation. Vi har adskilt udviklingen af den generative AI-applikation i to lag, en backend og frontend, som vist i den følgende figur.
På backend inkorporerer de generative AI-udviklere den valgte FM i løsningerne og arbejder sammen med de hurtige ingeniører for at skabe automatiseringen for at transformere slutbrugerinput til passende FM-prompter. Prompttesterne opretter de nødvendige indgange til promptkataloget til automatisk eller manuel (HIL eller LLM) test. Derefter skaber de generative AI-udviklere den hurtige kæde- og anvendelsesmekanisme for at levere det endelige output. Prompt chaining er i denne sammenhæng en teknik til at skabe mere dynamiske og kontekstuelt bevidste LLM-applikationer. Det fungerer ved at opdele en kompleks opgave i en række mindre, mere overskuelige underopgaver. For eksempel, hvis vi stiller en LLM spørgsmålet "Hvor blev Storbritanniens premierminister født, og hvor langt er det sted fra London", kan opgaven opdeles i individuelle prompter, hvor en prompt kan bygges baseret på svaret af en tidligere hurtig evaluering, såsom "Hvem er Storbritanniens premierminister", "Hvad er deres fødested" og "Hvor langt er det sted fra London?" For at sikre en vis input- og outputkvalitet skal de generative AI-udviklere også skabe mekanismen til at overvåge og filtrere slutbrugerinput og applikationsoutput. Hvis det for eksempel er meningen, at LLM-applikationen skal undgå giftige anmodninger og svar, kan de anvende en toksicitetsdetektor til input og output og filtrere dem fra. Endelig er de nødt til at levere en vurderingsmekanisme, som vil understøtte udvidelsen af evalueringspromptkataloget med gode og dårlige eksempler. En mere detaljeret repræsentation af disse mekanismer vil blive præsenteret i fremtidige indlæg.
For at levere funktionaliteten til den generative AI-slutbruger er udviklingen af et frontend-websted, der interagerer med backend, nødvendigt. Derfor skal DevOps og AppDevs (applikationsudviklere i skyen) følge bedste udviklingspraksis for at implementere funktionaliteten af input/output og rating.
Ud over denne grundlæggende funktionalitet skal frontend og backend inkorporere funktionen med at oprette personlige brugerkonti, uploade data, starte finjustering som en sort boks og bruge den personlige model i stedet for den grundlæggende FM. Produktionen af en generativ AI-applikation ligner en normal applikation. Følgende figur viser et eksempel på arkitektur.
I denne arkitektur opretter og tester de generative AI-udviklere, promptingeniører og DevOps eller AppDevs applikationen manuelt ved at implementere den via CI/CD til et udviklingsmiljø (generativ AI App Dev i den foregående figur) ved hjælp af dedikerede kodelagre og flette med dev-grenen. På dette stadium vil de generative AI-udviklere bruge den tilsvarende FM ved at kalde API'en, som er leveret af FM-udbyderne af fintunere. Derefter, for at teste applikationen grundigt, skal de promovere koden til testgrenen, hvilket vil udløse implementeringen via CI/CD til præproduktionsmiljøet (generativ AI App Pre-prod). I dette miljø skal prompttesterne prøve en stor mængde promptkombinationer og gennemgå resultaterne. Kombinationen af prompter, output og gennemgang skal flyttes til evalueringspromptkataloget for at automatisere testprocessen i fremtiden. Efter denne omfattende test er det sidste trin at fremme den generative AI-applikation til produktion via CI/CD ved at fusionere med hovedgrenen (generativ AI App Prod). Bemærk, at alle data, inklusive promptkataloget, evalueringsdata og -resultater, slutbrugerdata og metadata og finjusterede modelmetadata, skal gemmes i datasøen eller datamaskelaget. CI/CD-pipelines og repositories skal gemmes i en separat værktøjskonto (svarende til den, der er beskrevet for MLOps).
Udbydernes rejse
FM-udbydere skal træne FM'er, såsom deep learning-modeller. For dem er ende-til-ende MLOps livscyklus og infrastruktur nødvendig. Tilføjelser er påkrævet i forberedelse af historiske data, modelevaluering og overvågning. Følgende figur illustrerer deres rejse.
I klassisk ML skabes de historiske data oftest ved at fodre jordens sandhed via ETL-rørledninger. For eksempel, i et tilfælde af churn-forudsigelse, opdaterer en automatisering en databasetabel baseret på den nye status for en kunde til at churn/ikke churn automatisk. I tilfælde af FM'er har de brug for enten milliarder af mærkede eller umærkede datapunkter. I tilfælde af tekst-til-billede skal et team af dataetikettere mærke parrer manuelt. Dette er en dyr øvelse, der kræver et stort antal menneskers ressourcer. Amazon SageMaker Ground Truth Plus kan stille et team af etikettere til rådighed til at udføre denne aktivitet for dig. I nogle tilfælde kan denne proces også automatiseres delvist, for eksempel ved at bruge CLIP-lignende modeller. I tilfælde af en LLM, såsom tekst-til-tekst, er dataene umærkede. De skal dog forberedes og følge formatet for de eksisterende historiske umærkede data. Derfor er der behov for dataeditorer til at udføre nødvendig dataforberedelse og sikre konsistens.
Med de historiske data udarbejdet, er næste skridt træning og produktion af modellen. Bemærk, at de samme evalueringsteknikker, som vi beskrev for forbrugere, kan bruges.
Fintunernes rejse
Fintunere sigter efter at tilpasse en eksisterende FM til deres specifikke kontekst. For eksempel kan en FM-model opsummere en tekst til generelle formål, men ikke en finansiel rapport nøjagtigt, eller den kan ikke generere kildekode til et ikke-fælles programmeringssprog. I disse tilfælde skal finjustererne mærke data, finjustere en model ved at køre et træningsjob, implementere modellen, teste den baseret på forbrugerprocesserne og overvåge modellen. Følgende diagram illustrerer denne proces.
For øjeblikket er der to finjusteringsmekanismer:
- Finjustering – Ved at bruge en FM og mærkede data genberegner et træningsjob vægten og skævhederne i de dybe læringsmodellag. Denne proces kan være beregningsintensiv og kræver en repræsentativ mængde data, men kan generere nøjagtige resultater.
- Parametereffektiv finjustering (PEFT) – I stedet for at genberegne alle vægte og skævheder har forskere vist, at ved at tilføje yderligere små lag til deep learning-modellerne kan de opnå tilfredsstillende resultater (f.eks. LoRA). PEFT kræver lavere beregningskraft end dyb finjustering og et træningsjob med færre inputdata. Ulempen er potentiel lavere nøjagtighed.
Følgende diagram illustrerer disse mekanismer.
Nu hvor vi har defineret de to primære finjusteringsmetoder, er næste trin at bestemme, hvordan vi kan implementere og bruge open source og proprietære FM.
Med open source FM'er kan fintunerne downloade modelartefakten og kildekoden fra nettet, for eksempel ved at bruge Hugging Face Model Hub. Dette giver dig fleksibiliteten til at finjustere modellen i dybden, gemme den i et lokalt modelregister og implementere den til en Amazon SageMaker endepunkt. Denne proces kræver en internetforbindelse. For at understøtte mere sikre miljøer (såsom for kunder i den finansielle sektor), kan du downloade modellen på stedet, køre alle nødvendige sikkerhedstjek og uploade dem til en lokal bucket på en AWS-konto. Derefter bruger finindstillerne FM'en fra den lokale bøtte uden internetforbindelse. Dette sikrer databeskyttelse, og dataene rejser ikke over internettet. Følgende diagram illustrerer denne metode.
Med proprietære FM'er er implementeringsprocessen anderledes, fordi finjusteringerne ikke har adgang til modelartefakten eller kildekoden. Modellerne er gemt i proprietære FM-udbyderens AWS-konti og modelregistre. For at implementere en sådan model til et SageMaker-endepunkt, kan finjusteringerne kun anmode om den modelpakke, der vil blive implementeret direkte til et slutpunkt. Denne proces kræver, at kundedata bruges i de proprietære FM-udbyderes konti, hvilket rejser spørgsmål vedrørende kundefølsomme data, der bruges på en fjernkonto til at udføre finjustering, og modeller, der hostes i et modelregister, der deles mellem flere kunder . Dette fører til et problem med flere lejemål, der bliver mere udfordrende, hvis de proprietære FM-udbydere skal betjene disse modeller. Hvis fin-tunerne bruger Amazonas grundfjeld, er disse udfordringer løst – dataene rejser ikke over internettet, og FM-udbyderne har ikke adgang til finindstillernes data. De samme udfordringer gælder for open source-modellerne, hvis finjustererne ønsker at betjene modeller fra flere kunder, som det eksempel, vi gav tidligere med hjemmesiden, som tusindvis af kunder vil uploade personlige billeder til. Disse scenarier kan dog betragtes som kontrollerbare, fordi kun finjusteringen er involveret. Følgende diagram illustrerer denne metode.
Fra et teknologisk perspektiv er arkitekturen, som en fintuner skal understøtte, som den for MLOps (se følgende figur). Finjusteringen skal udføres i dev ved at skabe ML-pipelines, som f.eks Amazon SageMaker Pipelines; udføre forbehandling, finjustering (træningsjob) og efterbehandling; og afsendelse af de finjusterede modeller til et lokalt modelregister i tilfælde af en open source FM (ellers vil den nye model blive gemt i det proprietære FM-forsyningsmiljø). Derefter skal vi i præproduktionen teste modellen, som vi beskriver for forbrugernes scenarie. Endelig vil modellen blive serveret og overvåget i prod. Bemærk, at den nuværende (finjusterede) FM kræver GPU-instansslutpunkter. Hvis vi har brug for at implementere hver finjusteret model til et separat slutpunkt, kan dette øge omkostningerne i tilfælde af hundredvis af modeller. Derfor er vi nødt til at bruge multi-model endpoints og løse multi-lejemålsudfordringen.
Fintunerne tilpasser en FM-model ud fra en specifik kontekst for at bruge den til deres forretningsformål. Det betyder, at fintunerne for det meste også er forbrugere, der skal understøtte alle lagene, som vi beskrev i de foregående sektioner, herunder generativ AI-applikationsudvikling, data lake og data mesh og MLOps.
Følgende figur illustrerer den komplette FM-finindstillingslivscyklus, som finjusteringerne har brug for for at levere den generative AI-slutbruger.
Følgende figur illustrerer de vigtigste trin.
De vigtigste trin er følgende:
- Slutbrugeren opretter en personlig konto og uploader private data.
- Dataene lagres i datasøen og er forbehandlet til at følge det format, som FM forventer.
- Dette udløser en finjusterende ML-pipeline, der føjer modellen til modelregistret,
- Derfra bliver modellen enten implementeret til produktion med minimumstest, eller modellen skubber omfattende test med HIL og manuelle godkendelsesporte.
- Den finjusterede model er gjort tilgængelig for slutbrugere.
Fordi denne infrastruktur er kompleks for ikke-virksomhedskunder, frigav AWS Amazon Bedrock for at aflaste indsatsen med at skabe sådanne arkitekturer og bringe finjusterede FM'er tættere på produktionen.
FMOps og LLMOps personaer og processer differentiatorer
Baseret på de foregående brugertyperejser (forbruger, producent og finjusterer), er der behov for nye personas med specifikke færdigheder, som illustreret i den følgende figur.
De nye personas er som følger:
- Datamærkere og redaktører – Disse brugere mærker data, som f.eks par, eller forberede umærkede data, såsom fritekst, og udvide det avancerede analyseteam og datasømiljøer.
- Fin-tunere – Disse brugere har dyb viden om FM'er og ved at tune dem, hvilket udvider datavidenskabsteamet, der vil fokusere på klassisk ML.
- Generative AI-udviklere – De har dyb viden om valg af FM'er, kæde prompter og applikationer og filtrering af input og output. De tilhører et nyt team – det generative AI-applikationsteam.
- Hurtige ingeniører – Disse brugere designer input- og outputprompts for at tilpasse løsningen til konteksten og teste og oprette den første version af promptkataloget. Deres team er det generative AI-applikationsteam.
- Spørg testere – De tester i stor skala den generative AI-løsning (backend og frontend) og feeder deres resultater for at udvide det hurtige katalog og evalueringsdatasættet. Deres team er det generative AI-applikationsteam.
- AppDev og DevOps – De udvikler frontend (såsom et websted) af den generative AI-applikation. Deres team er det generative AI-applikationsteam.
- Generative AI-slutbrugere – Disse brugere bruger generative AI-applikationer som sorte bokse, deler data og vurderer kvaliteten af outputtet.
Den udvidede version af MLOps-proceskortet til at inkorporere generativ AI kan illustreres med følgende figur.
Et nyt applikationslag er miljøet, hvor generative AI-udviklere, promptingeniører og testere og AppDevs skabte backend og frontend af generative AI-applikationer. De generative AI-slutbrugere interagerer med den generative AI-applikations frontend via internettet (såsom en web-UI). På den anden side skal dataetikettere og editorer forbehandle dataene uden at få adgang til backend af datasøen eller datanettet. Derfor er en web-UI (hjemmeside) med en editor nødvendig for at kunne interagere sikkert med dataene. SageMaker Ground Truth giver denne funktionalitet ud af æsken.
Konklusion
MLOps kan hjælpe os med at producere ML-modeller effektivt. Men for at operationalisere generative AI-applikationer har du brug for yderligere færdigheder, processer og teknologier, hvilket fører til FMOps og LLMOps. I dette indlæg definerede vi hovedkoncepterne for FMOps og LLMOps og beskrev de vigtigste differentiatorer sammenlignet med MLOps-kapaciteter med hensyn til mennesker, processer, teknologi, FM-modelvalg og evaluering. Desuden illustrerede vi tankeprocessen for en generativ AI-udvikler og udviklingslivscyklussen for en generativ AI-applikation.
I fremtiden vil vi fokusere på at levere løsninger til det domæne, vi diskuterede, og vil give flere detaljer om, hvordan man integrerer FM-overvågning (såsom toksicitet, bias og hallucination) og tredjeparts eller private datakildearkitektoniske mønstre, som f.eks. Retrieval Augmented Generation (RAG), til FMOps/LLMOps.
For at lære mere, se MLOps fundament køreplan for virksomheder med Amazon SageMaker og prøv ende-til-ende-løsningen i Implementering af MLOps-praksis med Amazon SageMaker JumpStart-foruddannede modeller.
Hvis du har kommentarer eller spørgsmål, bedes du efterlade dem i kommentarfeltet.
Om forfatterne
Dr. Sokratis Kartakis er Senior Machine Learning and Operations Specialist Solutions Architect for Amazon Web Services. Sokratis fokuserer på at gøre det muligt for virksomhedskunder at industrialisere deres Machine Learning-løsninger (ML) ved at udnytte AWS-tjenester og forme deres driftsmodel, dvs. MLOps-fundament, og transformations-køreplan, der udnytter bedste udviklingspraksis. Han har brugt 15+ år på at opfinde, designe, lede og implementere innovative end-to-end produktionsniveau ML og Internet of Things (IoT) løsninger inden for områderne energi, detailhandel, sundhed, finans/bank, motorsport osv. Sokratis kan lide at bruge sin fritid sammen med familie og venner, eller at køre på motorcykler.
Heiko Hotz er en Senior Solutions Architect for AI & Machine Learning med særligt fokus på naturlig sprogbehandling, store sprogmodeller og generativ AI. Før denne rolle var han chef for datavidenskab for Amazons EU-kundeservice. Heiko hjælper vores kunder med at få succes i deres AI/ML-rejse på AWS og har arbejdet med organisationer i mange brancher, herunder forsikring, finansielle tjenester, medier og underholdning, sundhedspleje, forsyningsselskaber og fremstilling. I sin fritid rejser Heiko så meget som muligt.
- 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/fmops-llmops-operationalize-generative-ai-and-differences-with-mlops/
- :har
- :er
- :ikke
- :hvor
- $OP
- 1
- 10
- 100
- 2023
- 23
- 7
- 75
- a
- evne
- I stand
- Om
- over
- ABSTRACT
- adgang
- tilgængelig
- Adgang
- Konto
- Konti
- nøjagtighed
- præcis
- præcist
- opnå
- aktioner
- aktivitet
- tilpasse
- tilpasning
- tilføje
- tilføje
- Desuden
- Yderligere
- Derudover
- tilføjelser
- Tilføjer
- administration
- Vedtagelse
- fremskreden
- afrika
- Efter
- Aftale
- AI
- AI og maskinindlæring
- AI assistent
- AI modeller
- AI-tjenester
- ai use cases
- AI / ML
- sigte
- Justerer
- Alle
- tillade
- tillader
- sammen
- allerede
- også
- Skønt
- altid
- Amazon
- Amazon SageMaker
- Amazon SageMaker JumpStart
- Amazon Web Services
- blandt
- beløb
- an
- analyse
- analytics
- ,
- og infrastruktur
- En anden
- besvare
- svar
- enhver
- api
- API'er
- app
- Anvendelse
- Application Development
- applikationer
- Indløs
- tilgang
- tilgange
- passende
- godkendelse
- cirka
- arkitekter
- arkitektonisk
- arkitektur
- ER
- omkring
- AS
- Vurdering
- Assistant
- At
- revideres
- revisorer
- augmented
- automatisere
- Automatiseret
- Automatisk Ur
- automatisk
- Automation
- tilgængelighed
- til rådighed
- gennemsnit
- undgå
- AWS
- Bagende
- Bad
- Balance
- baseret
- grundlæggende
- BE
- fordi
- bliver
- bliver
- været
- før
- være
- benchmark
- fordele
- BEDSTE
- Bedre
- mellem
- skævhed
- fordomme
- Billion
- milliarder
- Sort
- født
- låne
- både
- bots
- Boks
- kasser
- Branch
- Breaking
- kortvarigt
- Bringe
- Broken
- bygge
- Bygning
- bygget
- virksomhed
- men
- by
- beregne
- ringe
- kaldet
- ringer
- CAN
- kandidat
- kandidater
- kapaciteter
- kapacitet
- fange
- tilfælde
- tilfælde
- katalog
- kategorier
- central
- centraliseret
- vis
- udfordre
- udfordringer
- udfordrende
- lave om
- chatbots
- billigere
- Kontrol
- valg
- vælge
- Classic
- nøje
- tættere
- Tøj
- Cloud
- kode
- Kodning
- samarbejde
- kombination
- kombinationer
- kombinerer
- Kom
- kommentarer
- kommerciel
- kommercielt
- Fælles
- sammenligne
- sammenlignet
- fuldføre
- færdiggørelse
- komplekse
- kompleksitet
- Compliance
- kompatibel
- sammensætning
- omfattende
- computerkraft
- computer
- koncentrere
- Konceptet
- begreber
- Bekymringer
- betingelser
- Adfærd
- gennemført
- tilsluttet
- tilslutning
- følgelig
- Overvej
- overvejelser
- betragtes
- forbruge
- forbruger
- Forbrugere
- forbrug
- Container
- indeholder
- indhold
- indholdsskabelse
- sammenhæng
- fortsæt
- kontrol
- konversation
- samtaler
- ophavsret
- Tilsvarende
- Koste
- kostbar
- Omkostninger
- kunne
- lande
- dæksel
- dækket
- skabe
- oprettet
- skaber
- Oprettelse af
- skabelse
- kritisk
- afgørende
- kulturelle
- Nuværende
- skik
- kunde
- kundedata
- Kundeservice
- Kunder
- data
- Data Lake
- datapunkter
- Dataforberedelse
- databeskyttelse
- datalogi
- Database
- datasæt
- decentral
- Beslutter
- afgørelser
- dedikeret
- dyb
- dyb dykke
- dyb læring
- definerede
- definere
- definition
- definitioner
- levere
- dykke
- Efterspørgsel
- Afhængigt
- afhænger
- forestillende
- indsætte
- indsat
- implementering
- implementering
- beskrive
- beskrevet
- beskrivelse
- Design
- konstrueret
- designe
- ønske
- ønskes
- detaljeret
- detaljer
- Bestem
- bestemmelse
- dev
- udvikle
- udviklet
- Udvikler
- udviklere
- udvikling
- Udvikling
- udviklingsteam
- forskelle
- forskellige
- differentiere
- størrelse
- direkte
- diskutere
- drøftet
- vises
- afstand
- dyk
- forskelligartede
- do
- dokumenter
- Er ikke
- domæne
- Domæner
- Dont
- ned
- downloade
- køre
- grund
- dynamisk
- e
- hver
- tidligere
- Øst
- let
- Økonomisk
- editor
- Effektiv
- effektiv
- effektivt
- indsats
- enten
- uddybet
- valgt
- muliggøre
- muliggør
- ende
- ende til ende
- Endpoint
- energi
- ingeniør
- Engineering
- Ingeniører
- Engelsk
- forbedre
- sikre
- sikrer
- Enterprise
- virksomheder
- Underholdning
- Miljø
- miljøer
- lige
- især
- væsentlig
- etc.
- EU
- evaluere
- evalueret
- evaluering
- Endog
- Hver
- eksempel
- eksempler
- fremragende
- ophidset
- Dyrke motion
- eksisterende
- eksisterer
- Exotic
- forventer
- dyrt
- erfaring
- eksperiment
- ekspertise
- eksperter
- udnytte
- udvide
- strækker
- udvidelse
- omfattende
- Omfattende oplevelse
- ekstensivt
- ekstrakt
- f1
- Ansigtet
- faktor
- faktorer
- Kendskab
- familie
- langt
- hurtigere
- Feature
- tilbagemeldinger
- fodring
- Figur
- filtrere
- filtrering
- endelige
- Endelig
- finansielle
- finansiel rapport
- Finansiel sektor
- finansielle tjenesteydelser
- Fornavn
- passer
- Fleksibilitet
- fleksibel
- Fokus
- fokuserede
- fokuserer
- fokusering
- følger
- efterfulgt
- efter
- følger
- Til
- For forbrugere
- formular
- format
- Foundation
- fire
- Gratis
- venner
- fra
- forsiden
- forreste ende
- frontend
- fuld
- funktionalitet
- fundamental
- yderligere
- Endvidere
- fremtiden
- Gates
- Målestok
- Generelt
- generelle formål
- generelt
- generere
- genereret
- genererer
- generere
- generation
- generative
- Generativ AI
- geopolitiske
- få
- Git
- given
- giver
- Global
- global handel
- godt
- regeringsførelse
- GPU
- Ground
- havde
- hånd
- udnyttelse
- Have
- have
- he
- hoved
- Helse
- sundhedspleje
- hjælpe
- hjælper
- link.
- Høj
- høj kvalitet
- højere
- stærkt
- hans
- historisk
- hold
- host
- hostede
- Hvordan
- How To
- Men
- HTML
- HTTPS
- menneskelig
- Hundreder
- i
- ideelt
- if
- illustrerer
- billede
- billeder
- imaginær
- KIMOs Succeshistorier
- gennemføre
- gennemføre
- implikationer
- betydning
- vigtigt
- forbedring
- in
- omfatter
- omfatter
- Herunder
- indarbejde
- Forøg
- øget
- angiver
- Indikatorer
- individuel
- industrier
- indflydelse
- påvirket
- Infrastruktur
- initial
- innovativ
- indgang
- indgange
- instans
- i stedet
- anvisninger
- forsikring
- integrere
- beregnet
- interagere
- interaktion
- interaktion
- interagerer
- grænseflade
- Internet
- internetforbindelse
- tingenes internet
- ind
- indføre
- investere
- involverede
- involverer
- tingenes internet
- IT
- ITS
- Job
- rejse
- Journeys
- juli
- lige
- Nøgle
- nøglefaktor
- Venlig
- Kend
- viden
- kendt
- etiket
- Etiketter
- sø
- Sprog
- stor
- større
- Efternavn
- Latency
- lag
- lag
- førende
- Leads
- LÆR
- læring
- Forlade
- låne
- mindre
- Niveau
- løftestang
- biblioteker
- Licens
- Licenser
- livscyklus
- ligesom
- synes godt om
- begrænsninger
- LINK
- LLM
- belastning
- lokale
- placeret
- placering
- London
- Lang
- længere
- lavere
- maskine
- machine learning
- lavet
- Main
- vedligeholde
- Flertal
- Making
- håndterbar
- obligatorisk
- manuel
- manuelt
- Produktion
- mange
- kort
- massive
- modenhed
- maksimal
- Kan..
- me
- betyder
- midler
- mekanisme
- mekanismer
- Medier
- Middelhavet
- nævnte
- sammenlægning
- mesh
- Metadata
- metode
- Metode
- metoder
- Metrics
- Mellemøsten
- Middle East
- måske
- minimum
- ML
- MLOps
- model
- modeller
- Overvåg
- overvåges
- overvågning
- mere
- mere effektiv
- mest
- for det meste
- Motorsport
- bevæge sig
- flyttet
- bevægelse
- meget
- flere
- Musik
- skal
- my
- navn
- Natural
- Natural Language Processing
- Natur
- Naviger
- nødvendig
- Behov
- behov
- behov
- negativ
- netværk
- neurale netværk
- Neutral
- aldrig
- Ny
- nyligt
- næste
- NLP
- ingen
- normal
- Nord
- bemærkelsesværdig
- nummer
- observere
- of
- tilbyde
- tilbydes
- tit
- on
- onboarding
- ONE
- dem
- kun
- åbent
- open source
- drift
- Produktion
- optimal
- Option
- Indstillinger
- or
- organisation
- organisationer
- Andet
- Andre
- Ellers
- vores
- ud
- Resultat
- output
- i løbet af
- samlet
- oversigt
- egen
- ejer
- ejere
- pakke
- par
- parametre
- mønstre
- Mennesker
- per
- Udfør
- ydeevne
- udfører
- måske
- person,
- personale
- Personlig
- perspektiv
- fase
- pics
- stykke
- pipeline
- Place
- perron
- plato
- Platon Data Intelligence
- PlatoData
- Vær venlig
- Punkt
- punkter
- politikker
- positiv
- have
- mulig
- Indlæg
- Indlæg
- potentiale
- potentielt
- magt
- vigtigste
- Praktisk
- praksis
- Precision
- forudsige
- forudsigelse
- Forudsigelser
- forberedelse
- Forbered
- forberedt
- forberede
- forelagt
- tidligere
- tidligere
- Prime
- statsminister
- principper
- Forud
- Prioriter
- Beskyttelse af personlige oplysninger
- private
- Problem
- behandle
- Processer
- forarbejdning
- produceret
- producent
- Produkt
- produktion
- Programmering
- projekt
- fremme
- bevis
- Bevis for koncept
- foreslå
- proprietære
- Bevise
- give
- forudsat
- udbyder
- udbydere
- giver
- leverer
- formål
- formål
- skubber
- puslespil
- kvalitet
- spørgsmål
- Spørgsmål
- Hurtig
- rejser
- rækkevidde
- spænder
- hurtigt
- Sats
- hellere
- bedømmelse
- Læsning
- realtid
- grund
- modtage
- anbefaler
- Rød
- Reduceret
- raffinere
- om
- registre
- register
- regler
- relaterede
- frigivet
- relevans
- relevant
- pålidelighed
- resterne
- fjern
- udskiftes
- indberette
- Repository
- repræsentation
- repræsentativt
- anmode
- anmodninger
- påkrævet
- Krav
- Kræver
- forskning
- forskere
- Ressourcer
- henholdsvis
- svar
- reaktioner
- ansvarlige
- REST
- restriktioner
- restriktiv
- resultere
- Resultater
- detail
- genbruge
- gennemgå
- revideret
- ridning
- højre
- køreplan
- roller
- roller
- groft
- rundt
- Kør
- kører
- sagemaker
- samme
- sandkasse
- Scale
- skalering
- scenarie
- scenarier
- Videnskab
- forskere
- score
- ridse
- scripts
- HAV
- Sektion
- sektioner
- sektor
- sikker
- sikkert
- sikkerhed
- sikkerhedspolitikker
- se
- søger
- valgt
- udvælgelse
- valg
- afsendelse
- senior
- sendt
- stemningen
- adskille
- Sequence
- Series
- tjener
- tjeneste
- Tjenester
- servering
- sæt
- flere
- forme
- Del
- delt
- skibe
- Kort
- bør
- vist
- Shows
- side
- signifikant
- betydeligt
- lignende
- forenkle
- Størrelse
- færdigheder
- lille
- mindre
- SMV'er
- So
- løsninger
- Løsninger
- SOLVE
- nogle
- Kilde
- kildekode
- Kilder
- Space
- særligt
- specialist
- specialiserede
- specifikke
- specifikt
- hastighed
- tilbringe
- brugt
- Stage
- etaper
- interessenter
- standard
- standardisering
- starte
- Status
- Trin
- Steps
- butik
- opbevaret
- lagring
- Story
- styrker
- stærk
- Efterfølgende
- vellykket
- sådan
- tyder
- egnethed
- egnede
- opsummere
- RESUMÉ
- support
- Understøttet
- formodes
- sikker
- SWIFT
- systemet
- bord
- Tag
- Opgaver
- opgaver
- hold
- hold
- Teknisk
- teknikker
- Teknologier
- Teknologier
- vilkår
- prøve
- afprøvet
- testere
- Test
- end
- at
- Fremtiden
- The Source
- UK
- verdenen
- deres
- Them
- selv
- derefter
- Der.
- derfor
- Disse
- de
- ting
- Tænker
- tredjepart
- denne
- dem
- selvom?
- tænkte
- tusinder
- tre
- tid
- til
- sammen
- token
- Tokens
- top
- Emner
- mod
- handle
- traditionelle
- Tog
- uddannet
- Kurser
- Transform
- Transformation
- rejse
- rejser
- Trend
- udløse
- sand
- Sandheden
- prøv
- to
- typen
- typer
- typisk
- ui
- Uk
- forstå
- forståelse
- enhed
- enheder
- opdateringer
- Uploading
- us
- brugbar
- Brug
- brug
- brug tilfælde
- anvendte
- Bruger
- brugere
- bruger
- ved brug af
- forsyningsselskaber
- udnyttet
- forskellige
- verificere
- udgave
- versus
- lodret
- via
- levedygtig
- Visualiser
- vs
- ønsker
- var
- we
- web
- webservices
- Hjemmeside
- GODT
- Hvad
- Hvad er
- hvornår
- ud fra følgende betragtninger
- hvorvidt
- som
- mens
- WHO
- bred
- Bred rækkevidde
- vilje
- vindue
- vinduer
- med
- inden for
- uden
- ord
- ord
- Arbejde
- arbejde sammen
- arbejdede
- arbejder
- virker
- world
- ville
- år
- Udbytte
- Du
- Din
- zephyrnet